Smalltalk › Instantiations

Methods sending unimplemented messages

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 2 messages Options
Richard Sargent
Reply | Threaded
Open this post in threaded view
♦
♦
|

Methods sending unimplemented messages

Richard Sargent
Administrator
In the stock image deployed with 8.5.2, Behavior includes a method called #stsAllMethodsHavingReferenceToMissingMethods:. Unfortunately, it is not called from anywhere and nor does it have a presence in the Tools menu. I wish it did!

Consequently, I implemented a method on EmSystemConfiguration to call it and display the methods meeting this requirement. Imagine my surprise to find that a clean abt.icx from the newimage directory should have over 100 such methods! Many of them are Abt classes, but one is a seemingly unused method in DbgDebugSession, a number of others are in Em classes, Ep classes, Es classes, Et classes, Nls classes, and Sts classes. Many of these uses are guarded by #respondsTo: and other similar tests, but it isn't obvious that all are protected.


It would be good if the various method were checked and cleaned up, with any unused (and *meant* to be unused) methods removed.


Here is the method source for EmSystemConfiguration>>#stsAllMethodsReferenceToMissingMethods. Please add it, and to the Tools menu, too.


> stsAllMethodsReferenceToMissingMethods

>     "Open a browser on the methods which include unimplemented message sends."
>         "System stsAllMethodsReferenceToMissingMethods"
>
>     | methods |
>     methods := OrderedCollection new.
>     Transcript
>             execLongOperation: [:dialog |
>                 self classHierarchyRoots do: [:cl |
>                     methods addAll: (cl stsAllMethodsHavingReferenceToMissingMethods: dialog)]]
>             message: 'Searching for unimplemented message sends (0 found)     '
>             allowCancel: true
>             showProgress: true.
>     methods isEmpty
>         ifTrue: [self message: 'No methods include unimplemented message sends']
>         ifFalse: [
>             ((EtTools browser: #methods)
>                 on: (methods asSet asSortedCollection: CompiledMethod sortBlock)
>                 labeled: 'Methods with unimplemented message sends')
>                     owningImage: self; 
>                     open]

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Richard Sargent
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Methods sending unimplemented messages

Richard Sargent
Administrator
It turns out the missing method logic was being fooled by Atoms. Their parse nodes answered a selector that wasn't implemented in the system, so methods with an Atom were flagged if the method literals included a Symbol that was not an existing method. Many Symbol literals used to signal events meet that criterion.

So, EsParseNode>>#stsHasReferenceToMissingMethod also needed a change:

> stsHasReferenceToMissingMethod
>
>     self allNodesDo: [:node | | selector |
>         ((selector := node selector) notNil
>             and: [selector ~= #CompileTimeConstant
>             and: [(StsPowerTools methodSelectorExists: selector) not]])
>             ifTrue: [^true]].
>     ^false


It is also worth noting that CompiledMethod>>#stsHasReferenceToMissingMethod is inefficient when a method has multiple Symbol literals which are not message selectors being sent from the compiled method.



On Fri, Aug 30, 2013 at 9:27 AM, Richard Sargent <[hidden email]> wrote:
In the stock image deployed with 8.5.2, Behavior includes a method called #stsAllMethodsHavingReferenceToMissingMethods:. Unfortunately, it is not called from anywhere and nor does it have a presence in the Tools menu. I wish it did!

Consequently, I implemented a method on EmSystemConfiguration to call it and display the methods meeting this requirement. Imagine my surprise to find that a clean abt.icx from the newimage directory should have over 100 such methods! Many of them are Abt classes, but one is a seemingly unused method in DbgDebugSession, a number of others are in Em classes, Ep classes, Es classes, Et classes, Nls classes, and Sts classes. Many of these uses are guarded by #respondsTo: and other similar tests, but it isn't obvious that all are protected.


It would be good if the various method were checked and cleaned up, with any unused (and *meant* to be unused) methods removed.


Here is the method source for EmSystemConfiguration>>#stsAllMethodsReferenceToMissingMethods. Please add it, and to the Tools menu, too.


> stsAllMethodsReferenceToMissingMethods
>     "Open a browser on the methods which include unimplemented message sends."
>         "System stsAllMethodsReferenceToMissingMethods"
>
>     | methods |
>     methods := OrderedCollection new.
>     Transcript
>             execLongOperation: [:dialog |
>                 self classHierarchyRoots do: [:cl |
>                     methods addAll: (cl stsAllMethodsHavingReferenceToMissingMethods: dialog)]]
>             message: 'Searching for unimplemented message sends (0 found)     '
>             allowCancel: true
>             showProgress: true.
>     methods isEmpty
>         ifTrue: [self message: 'No methods include unimplemented message sends']
>         ifFalse: [
>             ((EtTools browser: #methods)
>                 on: (methods asSet asSortedCollection: CompiledMethod sortBlock)
>                 labeled: 'Methods with unimplemented message sends')
>                     owningImage: self; 
>                     open]

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/5oPZEOWgh9g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.



--
Richard Sargent
Business Development Manager
[hidden email]		 GemTalk Systems
15220 NW Greenbrier Parkway #240
Beaverton, OR 97006

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Free forum by Nabble Edit this page