[Pharo-project] (no subject)
I get a #dnu on RBParser>>#initializeParserWith:type:, called by OR2Command>>requestMethodFor: Do I need to load/fix something myself, or is this a bug? -- Henrik Jegbjerg Hansen
OR2 depends on the old Refactoring Engine from 1999. I recently ported some newer code of John Brant that avoids unnecessary reformatting. It looks like O2 hasn't been updated yet. The refactoring tools should work well in the default OmniBrowser. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli <renggli@gmail.com> writes:
OR2 depends on the old Refactoring Engine from 1999. I recently ported some newer code of John Brant that avoids unnecessary reformatting. It looks like O2 hasn't been updated yet. The refactoring tools should work well in the default OmniBrowser.
Lukas
Is formatting when refactoring removed altogether? If so, that is great news! However, I get the same error with OBSystemBrowser. (I assume this is the "default OmniBrowser")? -- Henrik Jegbjerg Hansen
I still have issues with not preserving code formatting in the latest pharo-dev. Particularly, method renaming cause code to be reformatted.
Lukas Renggli <renggli@gmail.com> writes:
OR2 depends on the old Refactoring Engine from 1999. I recently ported some newer code of John Brant that avoids unnecessary reformatting. It looks like O2 hasn't been updated yet. The refactoring tools should work well in the default OmniBrowser.
Lukas
I still have issues with not preserving code formatting in the latest pharo-dev. Particularly, method renaming cause code to be reformatted.
The formatting cannot be preserved in all cases. For example, if the renamed method has many arguments or is sent with complex arguments (block, nested message sends, ...) the code is still reformatted. For the cases where an automatic formatting is not avoidable, the class RBConfigurableFormatter can be configured to produce something that is more to your likings. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Thanks for the explanation. But I have just a test method without any arguments which isn't referenced from anywhere. And this very method loses its formatting after renaming. I've tried to rename some other methods without parameters but the result is the same. 2009/11/22 Lukas Renggli <renggli@gmail.com>:
I still have issues with not preserving code formatting in the latest pharo-dev. Particularly, method renaming cause code to be reformatted.
The formatting cannot be preserved in all cases. For example, if the renamed method has many arguments or is sent with complex arguments (block, nested message sends, ...) the code is still reformatted. For the cases where an automatic formatting is not avoidable, the class RBConfigurableFormatter can be configured to produce something that is more to your likings.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks for the explanation. But I have just a test method without any arguments which isn't referenced from anywhere. And this very method loses its formatting after renaming. I've tried to rename some other methods without parameters but the result is the same.
Are you sure you have the latest code, e.g. AST-Core-lr.27, Refactoring-Core-lr.77 and OB-Refactory-lr.170? Lukas
2009/11/22 Lukas Renggli <renggli@gmail.com>:
I still have issues with not preserving code formatting in the latest pharo-dev. Particularly, method renaming cause code to be reformatted.
The formatting cannot be preserved in all cases. For example, if the renamed method has many arguments or is sent with complex arguments (block, nested message sends, ...) the code is still reformatted. For the cases where an automatic formatting is not avoidable, the class RBConfigurableFormatter can be configured to produce something that is more to your likings.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Yes. 2009/11/22 Lukas Renggli <renggli@gmail.com>:
Thanks for the explanation. But I have just a test method without any arguments which isn't referenced from anywhere. And this very method loses its formatting after renaming. I've tried to rename some other methods without parameters but the result is the same.
Are you sure you have the latest code, e.g. AST-Core-lr.27, Refactoring-Core-lr.77 and OB-Refactory-lr.170?
Lukas
Lukas, What about the handling of comments? The RB or its parser, etc. made *no* attempt to get them in the correct position as presented to the formatter, making the effort of creating a formatter fairly pointless. If that has improved, I will take another look, but my instinct is to ask for the RB to make a list what it would need to reformat so I can take care of it myself - it was that bad. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, November 22, 2009 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject)
I still have issues with not preserving code formatting in the latest pharo-dev. Particularly, method renaming cause code to be reformatted.
The formatting cannot be preserved in all cases. For example, if the renamed method has many arguments or is sent with complex arguments (block, nested message sends, ...) the code is still reformatted. For the cases where an automatic formatting is not avoidable, the class RBConfigurableFormatter can be configured to produce something that is more to your likings. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
at one point gwenael changed the parser to handle comments but apparently the code could not be loaded and it was never integrated. I imagine that now it is too divergent. Stef On Nov 22, 2009, at 2:44 PM, Schwab,Wilhelm K wrote:
Lukas,
What about the handling of comments? The RB or its parser, etc. made *no* attempt to get them in the correct position as presented to the formatter, making the effort of creating a formatter fairly pointless. If that has improved, I will take another look, but my instinct is to ask for the RB to make a list what it would need to reformat so I can take care of it myself - it was that bad.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, November 22, 2009 7:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject)
I still have issues with not preserving code formatting in the latest pharo-dev. Particularly, method renaming cause code to be reformatted.
The formatting cannot be preserved in all cases. For example, if the renamed method has many arguments or is sent with complex arguments (block, nested message sends, ...) the code is still reformatted. For the cases where an automatic formatting is not avoidable, the class RBConfigurableFormatter can be configured to produce something that is more to your likings.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
at one point gwenael changed the parser to handle comments but apparently the code could not be loaded and it was never integrated. I imagine that now it is too divergent.
The code never worked for me. It broke most parts of the Refactoring Engine. The new code is a fresh port from John's repository. There existing port was a total mess, partly broken, partly incomplete, very inefficient and polluted with code from other projects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Without looking at RB code, this is how I would handle it: 1) Reify Smalltalk tokens, and create a SpaceToken (can include various separators character and comments) the tokens just include a copy of corresponding source text. 2) Scanner creates a linked list of tokens including SpaceTokens 3) Parser parses the stream of tokens and build an AST that retain pointers to the links (firstLink and lastLink) The advantage of storing links rather than position is that we can add/remove links easily without recomputing positions 4) refactoring operates on AST and replaces links content, eventually if it add or remove links, then some special care of intersticial SpaceToken has to happen. 5) printing refactored source code is printing the tokens verbatim (that is just nextPutAll: their contents) Nicolas 2009/11/22 Lukas Renggli <renggli@gmail.com>:
at one point gwenael changed the parser to handle comments but apparently the code could not be loaded and it was never integrated. I imagine that now it is too divergent.
The code never worked for me. It broke most parts of the Refactoring Engine.
The new code is a fresh port from John's repository. There existing port was a total mess, partly broken, partly incomplete, very inefficient and polluted with code from other projects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If anyone builds this, I can easily clone one of my images and give it torture test with comments littering method bodies. If it can keep the "data collector" code in tact, it works. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Sunday, November 22, 2009 9:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject) Without looking at RB code, this is how I would handle it: 1) Reify Smalltalk tokens, and create a SpaceToken (can include various separators character and comments) the tokens just include a copy of corresponding source text. 2) Scanner creates a linked list of tokens including SpaceTokens 3) Parser parses the stream of tokens and build an AST that retain pointers to the links (firstLink and lastLink) The advantage of storing links rather than position is that we can add/remove links easily without recomputing positions 4) refactoring operates on AST and replaces links content, eventually if it add or remove links, then some special care of intersticial SpaceToken has to happen. 5) printing refactored source code is printing the tokens verbatim (that is just nextPutAll: their contents) Nicolas 2009/11/22 Lukas Renggli <renggli@gmail.com>:
at one point gwenael changed the parser to handle comments but apparently the code could not be loaded and it was never integrated. I imagine that now it is too divergent.
The code never worked for me. It broke most parts of the Refactoring Engine.
The new code is a fresh port from John's repository. There existing port was a total mess, partly broken, partly incomplete, very inefficient and polluted with code from other projects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You might want to try and pretty print the complete image and see if you loose any comments or if comments are moved at the wrong place.
From within a green browser press "refactor > pretty print" and get a coffee (it takes a long time).
Note that you might want to disable pretty-printing in the refactoring changes. The diff looks better with pretty printing enabled, but then this is not what you get afterwards. Lukas 2009/11/22 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
If anyone builds this, I can easily clone one of my images and give it torture test with comments littering method bodies. Â If it can keep the "data collector" code in tact, it works.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Sunday, November 22, 2009 9:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject)
Without looking at RB code, this is how I would handle it: 1) Reify Smalltalk tokens, and create a SpaceToken (can include various separators character and comments) Â the tokens just include a copy of corresponding source text. 2) Scanner creates a linked list of tokens including SpaceTokens 3) Parser parses the stream of tokens and build an AST that retain pointers to the links (firstLink and lastLink) Â The advantage of storing links rather than position is that we can add/remove links easily without recomputing positions 4) refactoring operates on AST and replaces links content, Â eventually if it add or remove links, then some special care of intersticial SpaceToken has to happen. 5) printing refactored source code is printing the tokens verbatim (that is just nextPutAll: their contents)
Nicolas
2009/11/22 Lukas Renggli <renggli@gmail.com>:
at one point gwenael changed the parser to handle comments but apparently the code could not be loaded and it was never integrated. I imagine that now it is too divergent.
The code never worked for me. It broke most parts of the Refactoring Engine.
The new code is a fresh port from John's repository. There existing port was a total mess, partly broken, partly incomplete, very inefficient and polluted with code from other projects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
2009/11/22 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Without looking at RB code, this is how I would handle it: 1) Reify Smalltalk tokens, and create a SpaceToken (can include various separators character and comments) Â the tokens just include a copy of corresponding source text.
As far as I know this is what Gwenael did.
2) Scanner creates a linked list of tokens including SpaceTokens
This approach works very well for instance variable or class renames, because a single identifier token is replace with a different one. Most refactorings however replace complex node trees being generated from code, coming from a rewrite expression or another method. This typically involves several nested replacements, inserting/removing parenthesis, inserting/removing statement separators, wrapping/unwrapping into blocks, changing indention, etc. Furthermore the code needs to decide if the space/comments between two adjacent nodes belong to the node before or after the tokens.
3) Parser parses the stream of tokens and build an AST that retain pointers to the links (firstLink and lastLink) Â The advantage of storing links rather than position is that we can add/remove links easily without recomputing positions
Yes, but at the same time the engine has to ensure that all the transformations are performed correctly. As soon as you have to keep the two data-structures (the token-list and the AST) in sync, this becomes highly non-trivial for anything more complex than a simple rename.
4) refactoring operates on AST and replaces links content, Â eventually if it add or remove links, then some special care of intersticial SpaceToken has to happen. 5) printing refactored source code is printing the tokens verbatim (that is just nextPutAll: their contents)
The current code does a much more conservative approach, that is very simple and ensures correctness at each step. Whenever a node is replaced, at the same time change-objects on the original source string are created. The new source code is then validated against the transformed AST nodes to ensure no bugs were introduced. If there is a problem, pretty printing kicks in. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
What about the handling of comments? Â The RB or its parser, etc. made *no* attempt to get them in the correct position as presented to the formatter, making the effort of creating a formatter fairly pointless.
The new RB has a better representation of where comments are put. Since I personally almost never put comments within the method body, I cannot comment if the formatting of comments has improved. For tools the Smalltalk syntax is a nightmare. A parser can only use heuristics to assign a comment to the right statement. Writing a formatter is even more difficult, because about everything can be nested in everything else.
If that has improved, I will take another look, but my instinct is to ask for the RB to make a list what it would need to reformat so I can take care of it myself - it was that bad.
That's what RB does (and always did) when you enabled the preference #promptOnRefactoring (which is the default in OB-Refactory). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas, Interesting news about #promptOnRefactoring. However, you are the first person involved with the RB to ever mention it to me. Previously, I was simply told that commenting methods is a waste of time and I would be happier and healthier if I would change my misguided ways. Obviously, I take a different view of it, and all the more so having recently ported a lot of aging code to Pharo; comments saved my skin yet again. If the RB can be made to respect them, I will eagerly use it. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, November 22, 2009 9:05 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject)
What about the handling of comments? Â The RB or its parser, etc. made *no* attempt to get them in the correct position as presented to the formatter, making the effort of creating a formatter fairly pointless.
The new RB has a better representation of where comments are put. Since I personally almost never put comments within the method body, I cannot comment if the formatting of comments has improved. For tools the Smalltalk syntax is a nightmare. A parser can only use heuristics to assign a comment to the right statement. Writing a formatter is even more difficult, because about everything can be nested in everything else.
If that has improved, I will take another look, but my instinct is to ask for the RB to make a list what it would need to reformat so I can take care of it myself - it was that bad.
That's what RB does (and always did) when you enabled the preference #promptOnRefactoring (which is the default in OB-Refactory). Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Interesting news about #promptOnRefactoring. However, you are the first person involved with the RB to ever mention it to me. Â Previously, I was simply told that commenting methods is a waste of time and I would be happier and healthier if I would change my misguided ways.
Don Roberts and John Brant improved the refactoring engine a lot in 2002. I assume that there was some pressure from the VisualWorks and Dolphin folks. Unfortunately Squeak and Pharo people were stuck with the refactoring code from the last century.
 Obviously, I take a different view of it, and all the more so having recently ported a lot of aging code to Pharo; comments saved my skin yet again.  If the RB can be made to respect them, I will eagerly use it.
I think the situation is much better now, but you cannot expect magic. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lucas, I do not expect magic, but I do expect it to work, and failing that, candor re limitations. IMHO, the real problem has been a sort of XP snobbery: it appears that those building or integrating what would otherwise be a wonderful tool, have zero interest in preserving comments, and even some contempt for those of who write them. It is far easier to impugn those suggesting improvements than to make it work or to inetegrate fixes. I will spare you second-hand comments about what has been done in other languages and editors, as I have never encountered an RB anywhere but Smalltalk. I am perfectly happy using the RB only for things where it does not reformat. If it turns out that #promptOnRefactoring meets my needs and/or if format-preservation works, I will extend my use accordingly. Thanks for working on it. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, November 22, 2009 10:55 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject)
Interesting news about #promptOnRefactoring. However, you are the first person involved with the RB to ever mention it to me. Â Previously, I was simply told that commenting methods is a waste of time and I would be happier and healthier if I would change my misguided ways.
Don Roberts and John Brant improved the refactoring engine a lot in 2002. I assume that there was some pressure from the VisualWorks and Dolphin folks. Unfortunately Squeak and Pharo people were stuck with the refactoring code from the last century.
 Obviously, I take a different view of it, and all the more so having recently ported a lot of aging code to Pharo; comments saved my skin yet again.  If the RB can be made to respect them, I will eagerly use it.
I think the situation is much better now, but you cannot expect magic. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
IMHO, the real problem has been a sort of XP snobbery: it appears that those building or integrating what would otherwise be a wonderful tool, have zero interest in preserving comments, and even some contempt for those of who write them.
This has nothing to do with snobbery, it is a technical issue.
I will spare you second-hand comments about what has been done in other languages and editors, as I have never encountered an RB anywhere but Smalltalk.
I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk. When saying that one must keep in mind that printing Java code so that it preserves the formatting is easier than to do the same with Smalltalk. Even if they have to handle 100+ AST node types individually, they all have a very strict structure and are rarely nested in unpredictable ways. Furthermore since the editor expands, completes, indents and formats a lot of code automatically anyway, people don't even notice when their code gets reformatted. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas, I'm not accusing you of snobbery, but it has been _obvious_ elsewhere, and it certainly has not helped advance the cause. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, November 22, 2009 1:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] (no subject)
IMHO, the real problem has been a sort of XP snobbery: it appears that those building or integrating what would otherwise be a wonderful tool, have zero interest in preserving comments, and even some contempt for those of who write them.
This has nothing to do with snobbery, it is a technical issue.
I will spare you second-hand comments about what has been done in other languages and editors, as I have never encountered an RB anywhere but Smalltalk.
I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk. When saying that one must keep in mind that printing Java code so that it preserves the formatting is easier than to do the same with Smalltalk. Even if they have to handle 100+ AST node types individually, they all have a very strict structure and are rarely nested in unpredictable ways. Furthermore since the editor expands, completes, indents and formats a lot of code automatically anyway, people don't even notice when their code gets reformatted. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Nov 22, 2009, at 7:31 PM, Lukas Renggli wrote:
IMHO, the real problem has been a sort of XP snobbery: it appears that those building or integrating what would otherwise be a wonderful tool, have zero interest in preserving comments, and even some contempt for those of who write them.
This has nothing to do with snobbery, it is a technical issue.
I will spare you second-hand comments about what has been done in other languages and editors, as I have never encountered an RB anywhere but Smalltalk.
I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk.
Not sure because it is full of bugs because Java is complex. Now if you give me one engineering for 6 months I guess we can catch up and what you are doing is cool. At Smalltalk diego "gneffer" show a realy extension to RB (and really simple to implement) where you could select a couple of methods and it would check duplicated code and extract the methods automatically.
When saying that one must keep in mind that printing Java code so that it preserves the formatting is easier than to do the same with Smalltalk. Even if they have to handle 100+ AST node types individually, they all have a very strict structure and are rarely nested in unpredictable ways. Furthermore since the editor expands, completes, indents and formats a lot of code automatically anyway, people don't even notice when their code gets reformatted.
I know that we discuss the placement of comment with gwenael too. I think that some heuristics may help. And probably with the simple pretty printer of damien. Stef
Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Nov 23, 2009 at 7:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk.
Not sure because it is full of bugs because Java is complex.
I use Eclipse and its refactorings everyday. They work quite well. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs? I wonder where are they 20 years ahead?! Em 24/11/2009 15:08, Damien Cassou <damien.cassou@gmail.com> escreveu: On Mon, Nov 23, 2009 at 7:53 PM, Stéphane Ducasse wrote:
I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk.
Not sure because it is full of bugs because Java is complex.
I use Eclipse and its refactorings everyday. They work quite well. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs?
I was not talking about feature completeness, I was more talking about the usability of the editor and how the different tools integrate. It is impressive that you see the renaming happening live in Eclipse while you type a new class/variable/method name. I don't know of a single refactoring in Eclipse that is not available in Smalltalk, of course excluding some of the refactorings that mangle with types, packages or inner-class and that do not make sense in the context of Smalltalk. Furthermore the Smalltalk refactoring engine provides an universal code transformation engine that allows one to script new transformations (refactorings) within seconds. This is something that I have not yet seen in any other language with that sophistication. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
OK, So it is the 'ergonomics' of the tool that makes you feel it is years ahead... Usability is a very difficult thing to measure and/or evaluate. Regards, -- Cesar Rabak Em 24/11/2009 15:55, Lukas Renggli <renggli@gmail.com> escreveu:
Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs?
I was not talking about feature completeness, I was more talking about the usability of the editor and how the different tools integrate. It is impressive that you see the renaming happening live in Eclipse while you type a new class/variable/method name. I don't know of a single refactoring in Eclipse that is not available in Smalltalk, of course excluding some of the refactorings that mangle with types, packages or inner-class and that do not make sense in the context of Smalltalk. Furthermore the Smalltalk refactoring engine provides an universal code transformation engine that allows one to script new transformations (refactorings) within seconds. This is something that I have not yet seen in any other language with that sophistication. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Nov 24, 2009, at 6:55 PM, Lukas Renggli wrote:
Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs?
I was not talking about feature completeness, I was more talking about the usability of the editor and how the different tools integrate. It is impressive that you see the renaming happening live in Eclipse while you type a new class/variable/method name.
yes the usability is clearly not the best aspect of smalltalk right now.
I don't know of a single refactoring in Eclipse that is not available in Smalltalk, of course excluding some of the refactorings that mangle with types, packages or inner-class and that do not make sense in the context of Smalltalk. Furthermore the Smalltalk refactoring engine provides an universal code transformation engine that allows one to script new transformations (refactorings) within seconds. This is something that I have not yet seen in any other language with that sophistication.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There are least two papers from ECOOP that points to some problems. But probably they are not frequent. Stef On Nov 24, 2009, at 6:08 PM, Damien Cassou wrote:
On Mon, Nov 23, 2009 at 7:53 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I know the refactoring engine of Eclipse. It must be 20 years ahead of Smalltalk.
Not sure because it is full of bugs because Java is complex.
I use Eclipse and its refactorings everyday. They work quite well.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
"Lukas" == Lukas Renggli <renggli@gmail.com> writes:
Lukas> I know the refactoring engine of Eclipse. It must be 20 years ahead of Lukas> Smalltalk. Ironic, since Eclipse was originally written in Smalltalk. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
OR2 depends on the old Refactoring Engine from 1999. I recently ported some newer code of John Brant that avoids unnecessary reformatting. It looks like O2 hasn't been updated yet. The refactoring tools should work well in the default OmniBrowser.
Lukas
Is formatting when refactoring removed altogether? Â If so, that is great news!
However, I get the same error with OBSystemBrowser. Â (I assume this is the "default OmniBrowser")?
The problem is that O2 overrides methods in the system and therefor breaks also the default system browser. I am afraid that you need to start from a core image and only load the default browser to get a working configuration (http://code.google.com/p/pharo/wiki/ImageBuildScripts). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Nov 22, 2009, at 13:28 , Lukas Renggli wrote:
OR2 depends on the old Refactoring Engine from 1999. I recently ported some newer code of John Brant that avoids unnecessary reformatting. It looks like O2 hasn't been updated yet. The refactoring tools should work well in the default OmniBrowser.
Lukas
Is formatting when refactoring removed altogether? If so, that is great news!
However, I get the same error with OBSystemBrowser. (I assume this is the "default OmniBrowser")?
The problem is that O2 overrides methods in the system and therefor breaks also the default system browser. I am afraid that you need to start from a core image and only load the default browser to get a working configuration (http://code.google.com/p/pharo/wiki/ImageBuildScripts).
Do we have a ticket for this already? Adrian
participants (10)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Damien Cassou -
George Herolyants -
Henrik Jegbjerg Hansen -
Lukas Renggli -
merlyn＠stonehenge.com -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse