[Pharo-project] Roeltyper
I added a little blurb w. link to the collaborative book - http://book.pharo-project.org/book/PharoTools/roeltyper/ -- View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Does it actually work? I haven't seen a version that correctly works in recent closure images. Lukas On 26 December 2011 05:18, Sean P. DeNigris <sean@clipperadams.com> wrote:
I added a little blurb w. link to the collaborative book - http://book.pharo-project.org/book/PharoTools/roeltyper/
-- View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Lukas Renggli www.lukas-renggli.ch
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. Cheers, Doru On 26 Dec 2011, at 09:40, Lukas Renggli wrote:
Does it actually work? I haven't seen a version that correctly works in recent closure images.
Lukas
On 26 December 2011 05:18, Sean P. DeNigris <sean@clipperadams.com> wrote:
I added a little blurb w. link to the collaborative book - http://book.pharo-project.org/book/PharoTools/roeltyper/
-- View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."
Did you publish the patch? What is wrong? What would be good is to remove the VW compliant classes and layers because like that it should be really simple. Stef
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly.
Cheers, Doru
On 26 Dec 2011, at 09:40, Lukas Renggli wrote:
Does it actually work? I haven't seen a version that correctly works in recent closure images.
Lukas
On 26 December 2011 05:18, Sean P. DeNigris <sean@clipperadams.com> wrote:
I added a little blurb w. link to the collaborative book - http://book.pharo-project.org/book/PharoTools/roeltyper/
-- View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Hi, Cyrille published it in the method: TypeCollector>>handleAssignment: val forTmp: index There is a guard condition with a comment. Cheers, Doru On 28 Dec 2011, at 11:10, Stéphane Ducasse wrote:
Did you publish the patch? What is wrong? What would be good is to remove the VW compliant classes and layers because like that it should be really simple.
Stef
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly.
Cheers, Doru
On 26 Dec 2011, at 09:40, Lukas Renggli wrote:
Does it actually work? I haven't seen a version that correctly works in recent closure images.
Lukas
On 26 December 2011 05:18, Sean P. DeNigris <sean@clipperadams.com> wrote:
I added a little blurb w. link to the collaborative book - http://book.pharo-project.org/book/PharoTools/roeltyper/
-- View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Lukas Renggli www.lukas-renggli.ch
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
Did you publish the patch?
I guess that was fixed a long time ago. At least it does not crash my image, it just produces wrong results.
What is wrong? What would be good is to remove the VW compliant classes and layers because like that it should be really simple.
It is highly complex, because it does an abstract interpretation of the bytecodes and getting the offsets of the variables right is not trivial. In fact in the past 2 years several people have tried to fix (including me) and didn't get it to work.
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly.
Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Dec 28, 2011, at 11:56 AM, Lukas Renggli wrote:
Did you publish the patch?
I guess that was fixed a long time ago. At least it does not crash my image, it just produces wrong results.
What is wrong? What would be good is to remove the VW compliant classes and layers because like that it should be really simple.
It is highly complex, because it does an abstract interpretation of the bytecodes and getting the offsets of the variables right is not trivial. In fact in the past 2 years several people have tried to fix (including me) and didn't get it to work.
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly.
Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm.
This is true that roel only checked within a method (from my memory) so with short method this is difficult to get really good result. I wonder if he compared with RBtyper. I know that he did manual verification and build a system for doing that in VW.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly.
Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm.
This is true that roel only checked within a method (from my memory) so with short method this is difficult to get really good result.
RoelTyper and RBRefactoryTyper do essentially the same: For class- and inst-vars they look at all the compiled methods that refer to these variables. RoelType does an abstract byte-code interpretation to figure out the assignments and the messages sent to the variables; RBRefactoryTyper parses the methods and figures out the assignments and messages sent using the AST. Then they both run a very similar algorithm to figure out the most likely kind of object hold in the variables. They do not necessarily report the same classes in the end, because the heuristics are different. Also RBRefactoryTyper goes a step further and tries to figure out type of elements inside collection types. For method arguments and temporaries they both only look at a single method (there are obviously no other references to the temporaries and arguments). Consequently they both deliver bad results for arguments and temporaries. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Dec 28, 2011, at 6:07 PM, Lukas Renggli wrote:
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly.
Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm.
This is true that roel only checked within a method (from my memory) so with short method this is difficult to get really good result.
RoelTyper and RBRefactoryTyper do essentially the same: For class- and inst-vars they look at all the compiled methods that refer to these variables. RoelType does an abstract byte-code interpretation to figure out the assignments and the messages sent to the variables; RBRefactoryTyper parses the methods and figures out the assignments and messages sent using the AST. Then they both run a very similar algorithm to figure out the most likely kind of object hold in the variables. They do not necessarily report the same classes in the end, because the heuristics are different. Also RBRefactoryTyper goes a step further and tries to figure out type of elements inside collection types.
For method arguments and temporaries they both only look at a single method (there are obviously no other references to the temporaries and arguments). Consequently they both deliver bad results for arguments and temporaries.
Yes when I looked at RB (in 99) I guess that they also used existing instances to try to get more information but mainly for instance variables. I would really like to see more work around practical tools that can help us. I have the work on type inference from francisco garau on my hard-disc. But this is a pity that nobody build on top of that. Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Yes when I looked at RB (in 99) I guess that they also used existing instances to try to get more information but mainly for instance variables.
I am not aware of such code. RBRefactoryTyper is part of the refactoring engine since I first looked at it around ESUG 2002. It is relatively hidden, and only used by a few refactorings to provide better default suggestions (i.e. extract to component). It is also used in OB to provide a better default class comment template. And in ECompletion for better suggestions since RoelTyper is not useable anymore.
I would really like to see more work around practical tools that can help us. I have the work on type inference from francisco garau on my hard-disc. But this is a pity that nobody build on top of that.
Never heard of that code. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Dec 28, 2011, at 7:24 PM, Lukas Renggli wrote:
Yes when I looked at RB (in 99) I guess that they also used existing instances to try to get more information but mainly for instance variables.
I am not aware of such code. RBRefactoryTyper is part of the refactoring engine since I first looked at it around ESUG 2002.
May be it was mentioned in their ecoop paper or in some workshop. I had fun with it when I wrote the message passing control paper in 98 after may be john told me that t was experimental.
It is relatively hidden, and only used by a few refactorings to provide better default suggestions (i.e. extract to component). It is also used in OB to provide a better default class comment template. And in ECompletion for better suggestions since RoelTyper is not useable anymore.
I would really like to see more work around practical tools that can help us. I have the work on type inference from francisco garau on my hard-disc. But this is a pity that nobody build on top of that.
Never heard of that code.
I can put it on a server. This was the master thesis of Francisco Garau.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
participants (4)
-
Lukas Renggli -
Sean P. DeNigris -
Stéphane Ducasse -
Tudor Girba