hi, I would modify SmalltalkImporter to enable importing all methods/ classes (as stubs) which do references to the appropriate model. Actually I am stopping in SmalltalkImporter>>#importClass: and my question is: do you know how to know in VW which are the methods/classes that do reference t8888°°°8o a method/class? I know that we can get such information through the Browser but really I do not think that this is a good idea to make Moose dependent on VW browser.
bests, Hani
Hi hnai
I got the following answer from the vwnc mailing-list:
BrowserEnvironment new referencesTo: (LiteralBindingReference pathString: List fullName) binding
mc := MethodCollector new. bindingToSearch := OrderedCollection fullyQualifiedReference binding. filter := mc referencesTo: bindingToSearch. result := mc select: filter.
and from john.
You need to ask for references to the binding for the class:
(BrowserEnvironment new referencesTo: (Core bindingFor: #OrderedCollection)) classes
You can use either the #classesAndSelectorsDo: or #methodsDo: instead of #classes if you wish to enumerate the methods. You can also combine the environments to narrow or broaden your query. For example, this returns the classes that have methods that reference both Array and OrderedCollection classes:
((BrowserEnvironment new referencesTo: (Core bindingFor: #OrderedCollection)) & (BrowserEnvironment new referencesTo: (Core bindingFor: #Array))) classes
You can rewrite this as: ((BrowserEnvironment new referencesTo: (Core bindingFor: #OrderedCollection)) referencesTo: (Core bindingFor: #Array)) classes
If you wish to find methods that reference OrderedCollection, but not Array:
((BrowserEnvironment new referencesTo: (Core bindingFor: #OrderedCollection)) & (BrowserEnvironment new referencesTo: (Core bindingFor: #Array)) not)
On 20 Dec 2007, at 21:16 , Stéphane Ducasse wrote:
mc := MethodCollector new. bindingToSearch := OrderedCollection fullyQualifiedReference binding. filter := mc referencesTo: bindingToSearch. result := mc select: filter.
If you are looking for the non-RB version, go for this one. More see: MethodCollector comment.
However, Smalltalk's senders of yields tons of false positives. In RBCrawler, what I do is a type inference at byte code level to get better data.
AA
On 20 déc. 07, at 22:13, Adrian Kuhn wrote:
On 20 Dec 2007, at 21:16 , Stéphane Ducasse wrote:
mc := MethodCollector new. bindingToSearch := OrderedCollection fullyQualifiedReference binding. filter := mc referencesTo: bindingToSearch. result := mc select: filter.
If you are looking for the non-RB version, go for this one. More see: MethodCollector comment.
there was no example in the comments about finding reference to a class.
However, Smalltalk's senders of yields tons of false positives. In RBCrawler, what I do is a type inference at byte code level to get better data.
We want just class references for now.
AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 21 Dec 2007, at 9:02 , Stéphane Ducasse wrote:
However, Smalltalk's senders of yields tons of false positives. In RBCrawler, what I do is a type inference at byte code level to get better data.
We want just class references for now.
Oops, I misunderstood senders-of.
Well it should be very straight forward to write a MethodCollector that collects references to classes: references to classes are stored in the literal array of compiled methods, as BindingReferences.
NB, I have a custom collector somewhere in CodeFoo or VisualWorksFoo.
cheers, AA
this has been proposed by Reinout Heeck:
mc := MethodCollector new. bindingToSearch := OrderedCollection fullyQualifiedReference binding. filter := mc referencesTo: bindingToSearch. result := mc select: filter.
and it work very well.
Now the question for moose developers is: do you have an opposite idea about the modification of SmaltalkImporter. Note that, in moose, smalltalk models will be bigger than before.
bests, Hani
On Dec 21, 2007, at 11:50 AM, Adrian Kuhn wrote:
On 21 Dec 2007, at 9:02 , Stéphane Ducasse wrote:
However, Smalltalk's senders of yields tons of false positives. In RBCrawler, what I do is a type inference at byte code level to get better data.
We want just class references for now.
Oops, I misunderstood senders-of.
Well it should be very straight forward to write a MethodCollector that collects references to classes: references to classes are stored in the literal array of compiled methods, as BindingReferences.
NB, I have a custom collector somewhere in CodeFoo or VisualWorksFoo.
cheers, AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 21 Dec 2007, at 12:29 , Hani ABDEEN wrote:
Now the question for moose developers is: do you have an opposite idea about the modification of SmaltalkImporter. Note that, in moose, smalltalk models will be bigger than before.
Hook into SmalltalkMethodImporter >> acceptLiteralNode:
AA
Hani
what would be good is: add a preference to the importingContext so that we can control if we want to get referencing classes
this way we should be able to write Importer new importingContext extractReferencingClasses ....
then write one or two tests that you put in the importer tests.
stef
On 21 déc. 07, at 12:29, Hani ABDEEN wrote:
this has been proposed by Reinout Heeck:
mc := MethodCollector new. bindingToSearch := OrderedCollection fullyQualifiedReference binding. filter := mc referencesTo: bindingToSearch. result := mc select: filter.
and it work very well.
Now the question for moose developers is: do you have an opposite idea about the modification of SmaltalkImporter. Note that, in moose, smalltalk models will be bigger than before.
bests, Hani
On Dec 21, 2007, at 11:50 AM, Adrian Kuhn wrote:
On 21 Dec 2007, at 9:02 , Stéphane Ducasse wrote:
However, Smalltalk's senders of yields tons of false positives. In RBCrawler, what I do is a type inference at byte code level to get better data.
We want just class references for now.
Oops, I misunderstood senders-of.
Well it should be very straight forward to write a MethodCollector that collects references to classes: references to classes are stored in the literal array of compiled methods, as BindingReferences.
NB, I have a custom collector somewhere in CodeFoo or VisualWorksFoo.
cheers, AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stef and Hani,
please do not use below code fragment in the importer for each class you visit, this would perform O(n^2). Rather follow my suggestion to visit each literal node each method, which performs linear.
cheers, AA
On 22 Dec 2007, at 16:13 , Stéphane Ducasse wrote:
mc := MethodCollector new. bindingToSearch := OrderedCollection fullyQualifiedReference binding. filter := mc referencesTo: bindingToSearch. result := mc select: filter.
Stef and Hani,
please do not use below code fragment in the importer for each class you visit, this would perform O(n^2). Rather follow my suggestion to visit each literal node each method, which performs linear.
You mean by going over all the methods of the **image**? Then in that case we would have to change the logic of the importer because right we only iterate on a subset of the image (visit their AST). and now we would have to perform something extra because we are interested in the references that are even outside of the subset under analysis.
BTW hani you should not mark as stub all the references you would get because some of them can be in the program under extraction.
So may be we should add a postExtraction phase to the importer -to check all the methods of the image -check that there are doing a reference to one of the classes we already imported
Adrian is it what you had in mind?
Stef
On 23 Dec 2007, at 12:18 , Stéphane Ducasse wrote:
and now we would have to perform something extra because we are interested in the references that are even outside of the subset under analysis.
So may be we should add a postExtraction phase to the importer -to check all the methods of the image -check that there are doing a reference to one of the classes we already imported
Adrian is it what you had in mind?
Yes, and you are right! it requires a post extraction phase that iterates over the remainder of the image (not only for references to classes, we could also try to catch all references to methods, ie method sends, there).
I have a byte code interpreter in RBCrawler, to eliminate false positives in senders-of, maybe you want reuse that.
cheers, AA
ok for now we just want to get static class references.
stef On 23 déc. 07, at 15:12, Adrian Kuhn wrote:
On 23 Dec 2007, at 12:18 , Stéphane Ducasse wrote:
and now we would have to perform something extra because we are interested in the references that are even outside of the subset under analysis.
So may be we should add a postExtraction phase to the importer -to check all the methods of the image -check that there are doing a reference to one of the classes we already imported
Adrian is it what you had in mind?
Yes, and you are right! it requires a post extraction phase that iterates over the remainder of the image (not only for references to classes, we could also try to catch all references to methods, ie method sends, there).
I have a byte code interpreter in RBCrawler, to eliminate false positives in senders-of, maybe you want reuse that.
cheers, AA _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 23, 2007, at 12:18 PM, Stéphane Ducasse wrote:
Stef and Hani,
please do not use below code fragment in the importer for each class you visit, this would perform O(n^2). Rather follow my suggestion to visit each literal node each method, which performs linear.
You mean by going over all the methods of the **image**? Then in that case we would have to change the logic of the importer because right we only iterate on a subset of the image (visit their AST). and now we would have to perform something extra because we are interested in the references that are even outside of the subset under analysis.
BTW hani you should not mark as stub all the references you would get because some of them can be in the program under extraction.
So may be we should add a postExtraction phase to the importer -to check all the methods of the image -check that there are doing a reference to one of the classes we already imported
I will see what I can do there.
Adrian is it what you had in mind?
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Hani ABDEEN -
Stéphane Ducasse