20 Dec
2007
20 Dec
'07
4:39 p.m.
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
20 Dec
20 Dec
9:16 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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)
10:13 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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
21 Dec
21 Dec
9:02 a.m.
New subject: importing all methods/classes which do references to the model methods/classes
On 20 déc. 07, at 22:13, Adrian Kuhn wrote:
On 20 Dec 2007, at 21:16 , Stéphane Ducasse wrote:
there was no example in the comments about finding reference to a class.
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.
We want just class references for now.
AA
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:50 a.m.
New subject: importing all methods/classes which do references to the model methods/classes
On 21 Dec 2007, at 9:02 , Stéphane Ducasse wrote:
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
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.
12:29 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
6:45 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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
22 Dec
22 Dec
4:13 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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:
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
8:56 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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.
>
23 Dec
23 Dec
12:18 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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
3:12 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
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
24 Dec
24 Dec
8:15 a.m.
New subject: importing all methods/classes which do references to the model methods/classes
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
27 Dec
27 Dec
7:40 p.m.
New subject: importing all methods/classes which do references to the model methods/classes
On Dec 23, 2007, at 12:18 PM, Stéphane Ducasse wrote:
I will see what I can do there.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5965
days inactive
5972
days old
12 comments
3 participants
participants (3)
-
Adrian Kuhn -
Hani ABDEEN -
Stéphane Ducasse