[Pharo-project] Question about Universes
Dear Universe Lover and other Fans, When I doit this: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Installer universe addPackage: 'ShoutOmniBrowser'; addPackage: 'eCompletion'; addPackage: 'eCompletionOmniBrowser'; addPackage: 'eCompletion-Traits'; install. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Omnibrowser gets installed, where it should not. Where is the definition of this Universe stored? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Wed, Feb 18, 2009 at 5:11 PM, Alexandre Bergel <Alexandre.Bergel@inria.fr> wrote:
Omnibrowser gets installed, where it should not. Where is the definition of this Universe stored?
Without thinking and checking: ShoutOmnibrowser depends on Omnibrowser, that's why OB is installed. -- Damien Cassou http://damiencassou.seasidehosting.st
How can I guess that there is a dependency ? ScriptLoader>>loadOBAlpha does not work anymore because of this... Alexandre On 18 Feb 2009, at 17:15, Damien Cassou wrote:
On Wed, Feb 18, 2009 at 5:11 PM, Alexandre Bergel <Alexandre.Bergel@inria.fr> wrote:
Omnibrowser gets installed, where it should not. Where is the definition of this Universe stored?
Without thinking and checking: ShoutOmnibrowser depends on Omnibrowser, that's why OB is installed.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Wed, Feb 18, 2009 at 5:11 PM, Alexandre Bergel <Alexandre.Bergel@inria.fr> wrote:
Omnibrowser gets installed, where it should not. Where is the definition of this Universe stored?
Without thinking and checking: ShoutOmnibrowser depends on Omnibrowser, that's why OB is installed.
yes, but obviously this dependency did get loaded in older Pharo versions, but now in the very latest version it does - why, what got changed? Does anyone know? David
Omnibrowser gets installed, where it should not. Where is the definition of this Universe stored?
Without thinking and checking: ShoutOmnibrowser depends on Omnibrowser, that's why OB is installed.
What I don't understand: Why does Universe load the OmniBrowser dependency when there is already a newer version of OmniBrowser installed in this image? I think it shouldn't do that. Does Universe not check whether the version number installed is higher than the latest one defined in Universe? Wouldn't it make sense to do this? David
+ 1 Alexandre On 19 Feb 2009, at 10:16, David Röthlisberger wrote:
Omnibrowser gets installed, where it should not. Where is the definition of this Universe stored?
Without thinking and checking: ShoutOmnibrowser depends on Omnibrowser, that's why OB is installed.
What I don't understand: Why does Universe load the OmniBrowser dependency when there is already a newer version of OmniBrowser installed in this image? I think it shouldn't do that. Does Universe not check whether the version number installed is higher than the latest one defined in Universe? Wouldn't it make sense to do this?
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Thu, Feb 19, 2009 at 10:16 AM, David Röthlisberger <squeak@webcitas.ch> wrote:
What I don't understand: Why does Universe load the OmniBrowser dependency when there is already a newer version of OmniBrowser installed in this image? I think it shouldn't do that. Does Universe not check whether the version number installed is higher than the latest one defined in Universe? Wouldn't it make sense to do this?
Universe knows what it installed. If you install OB through squeaksource, Universe will reinstall its own version. -- Damien Cassou http://damiencassou.seasidehosting.st
What I don't understand: Why does Universe load the OmniBrowser dependency when there is already a newer version of OmniBrowser installed in this image? I think it shouldn't do that. Does Universe not check whether the version number installed is higher than the latest one defined in Universe? Wouldn't it make sense to do this?
Universe knows what it installed. If you install OB through squeaksource, Universe will reinstall its own version.
ok, I understand. Maybe we could introduce a dialog asking whether the user really wants to downgrade his newer version of a package to the one Universe is suggesting to load, instead of just always overwriting the already installed version? David
On Thu, Feb 19, 2009 at 10:38 AM, David Röthlisberger <squeak@webcitas.ch> wrote:
Maybe we could introduce a dialog asking whether the user really wants to downgrade his newer version of a package to the one Universe is suggesting to load, instead of just always overwriting the already installed version?
How does the universe knows OB is already in the image? As soon as Pharo switches to Sake and MC1.5, that will fix the problem because everything uses PackageInfo to know what is installed. I don't want to fix Universes knowing that a better system exists. -- Damien Cassou http://damiencassou.seasidehosting.st
How does the universe knows OB is already in the image?
Universe could easily find out if a newer version is loaded, but from what I know about Universe it deliberately doesn't do so. Universes is supposed to provide working sets of packages. If Universe would not insist on loading the older version, compatibility could not be guaranteed anymore. I think that behavior makes sense. Maybe a warning could be shown, that an older version will be loaded?
As soon as Pharo switches to Sake and MC1.5, that will fix the problem because everything uses PackageInfo to know what is installed. I don't want to fix Universes knowing that a better system exists.
Has this been decided yet? I hope there will be some discussion about this. I don't think Sake is better than Universe. It is just different. - Universes is declarative system, it declares the exact versions that are known to work together. No exceptions here, it loads the specified configuration with the specified dependencies. - Sake is an imperative system, it uses Installer to load versions. Installer either loads specific versions, or some version based on a query string. I agree that this is much more powerful, however there is no guarantee that all the packages that Installer thinks are the right versions also work together. In the end random versions of random packages from random repositories will be loaded in random order into your image. Does this solve the problem? I don't think so. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Thu, Feb 19, 2009 at 11:59 AM, Lukas Renggli <renggli@gmail.com> wrote:
- Sake is an imperative system, it uses Installer to load versions. Installer either loads specific versions, or some version based on a query string. I agree that this is much more powerful, however there is no guarantee that all the packages that Installer thinks are the right versions also work together. In the end random versions of random packages from random repositories will be loaded in random order into your image. Does this solve the problem? I don't think so.
You are wrong about Sake I think. Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe. -- Damien Cassou http://damiencassou.seasidehosting.st
You are wrong about Sake I think.
I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder.
Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe.
Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself). I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are not implemented anywhere. Of course there is not a single test. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Thanks Lukas for sharing your experience with us. I have a naive question. Personally, I like the way packages get installed using class side methods on ScriptLoader. I have similar scripts for Mondrian and other projects. Is there something not convenient in that? Cheers, Alexandre On 19 Feb 2009, at 14:38, Lukas Renggli wrote:
You are wrong about Sake I think.
I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder.
Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe.
Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself).
I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are not implemented anywhere. Of course there is not a single test. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
The only problem i see is that it is not cleanly possible to support dependencies. If you want to install A and B that both depend on C, C will presumabely loaded twice. This does not happen with Sake and Universes. On 2/19/09, Alexandre Bergel <Alexandre.Bergel@inria.fr> wrote:
Thanks Lukas for sharing your experience with us. I have a naive question. Personally, I like the way packages get installed using class side methods on ScriptLoader. I have similar scripts for Mondrian and other projects. Is there something not convenient in that?
Cheers, Alexandre
On 19 Feb 2009, at 14:38, Lukas Renggli wrote:
You are wrong about Sake I think.
I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder.
Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe.
Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself).
I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are not implemented anywhere. Of course there is not a single test. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ 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
thanks lukas Stef On Feb 19, 2009, at 2:38 PM, Lukas Renggli wrote:
You are wrong about Sake I think.
I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder.
Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe.
Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself).
I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are not implemented anywhere. Of course there is not a single test. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct.
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
Lukas Renggli wrote:
You are wrong about Sake I think.
I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder.
Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe.
Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself).
Why? They are "mostly" declarative, following feedback from Andreas. If the default script is used it simply analyses the url data given, which is the case for 99% of packages.
I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. No it doesnt.
It doesn't depend upon that compiler hack. That hack provides the ability to put textual data in as an appendix to a method. It is an entirely independent facility that could be perhaps better included as a trait for those that want it. I use it when I want to use methods to be a mini database, in the Mantis package, and for Bob to be able to manages build scripts in the image without having to enclose in quotes and escape quotes.
In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are
I don't think it is fair to use code critics as an argument. To me it appears that you have developed all of these tools for your own use. I have never even seen you announce their existence to squeak-dev. Where is the documentation?
not implemented anywhere. Of course there is not a single test. What are you talking about: Sake-Tests. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct.
Again, what do you mean? There are two algorithms in use. The first is lifted directly from rake. The second is stolen directly from universes. Keith
I don't think it is fair to use code critics as an argument.
I think it's perfectly fair, be it code critic or lint, if it finds bad code then it finds bad code. It's not like you don't know about code critics and Lint is already in Squeak, so it's your choice if you choose not to avail yourself of tools that point out badly written code. He writes about the tools he's working on at his blog http://www.lukas-renggli.ch/blog which is easily subscribed to. There's no reason anyone can say they're unaware of what he's doing unless they're choosing to be unaware. Ramon Leon http://onsmalltalk.com
and the spelling rules is definitively colo :) On Feb 19, 2009, at 8:22 PM, Ramon Leon wrote:
I don't think it is fair to use code critics as an argument.
I think it's perfectly fair, be it code critic or lint, if it finds bad code then it finds bad code. It's not like you don't know about code critics and Lint is already in Squeak, so it's your choice if you choose not to avail yourself of tools that point out badly written code. He writes about the tools he's working on at his blog http://www.lukas-renggli.ch/blog which is easily subscribed to. There's no reason anyone can say they're unaware of what he's doing unless they're choosing to be unaware.
Ramon Leon http://onsmalltalk.com _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ramon Leon wrote:
I don't think it is fair to use code critics as an argument.
I think it's perfectly fair, be it code critic or lint, if it finds bad code then it finds bad code. It's not like you don't know about code critics and Lint is already in Squeak, No it is not.
I have seen one passing comment about something called SwaLint, on the mailing list that is about all.
so it's your choice if you choose not to avail yourself of tools that point out badly written code. He writes about the tools he's working on at his blog http://www.lukas-renggli.ch/blog which is easily subscribed to. Thanks, I didnt know There's no reason anyone can say they're unaware of what he's doing unless they're choosing to be unaware. Well clearly that is not true.
Keith
It doesn't depend upon that compiler hack. That hack provides the ability to put textual data in as an appendix to a method. It is an entirely independent facility that could be perhaps better included as a trait for those that want it.
I do not get that? I use it when I want to use methods to be a mini database, in the Mantis
package, and for Bob to be able to manages build scripts in the image without having to enclose in quotes and escape quotes.
In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are
I don't think it is fair to use code critics as an argument. To me it appears that you have developed all of these tools for your own use. I have never even seen you announce their existence to squeak-dev. Where is the documentation?
not implemented anywhere. Of course there is not a single test. What are you talking about: Sake-Tests. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct.
Again, what do you mean? There are two algorithms in use. The first is lifted directly from rake. The second is stolen directly from universes.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi keith I will let lukas answers your questions. And I like this discussion because at the end we should all get a better understanding. I like the idea of an integration build server we all need that. Lukas can from time to time build too complex software :) (I know he will smile) but he showed with Seaside that he has a sense of code responsibility. So continue to discuss not argue :) Stef On Feb 19, 2009, at 6:11 PM, Keith Hodges wrote:
Lukas Renggli wrote:
You are wrong about Sake I think.
I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder.
Sake can declare a universe of known-to-work-together packages. Just take a class, declare the sake tasks you know work together in the image you target and things will be as in universe.
Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself).
Why?
They are "mostly" declarative, following feedback from Andreas. If the default script is used it simply analyses the url data given, which is the case for 99% of packages.
I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. No it doesnt.
It doesn't depend upon that compiler hack. That hack provides the ability to put textual data in as an appendix to a method. It is an entirely independent facility that could be perhaps better included as a trait for those that want it.
I use it when I want to use methods to be a mini database, in the Mantis package, and for Bob to be able to manages build scripts in the image without having to enclose in quotes and escape quotes.
In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are
I don't think it is fair to use code critics as an argument. To me it appears that you have developed all of these tools for your own use. I have never even seen you announce their existence to squeak-dev. Where is the documentation?
not implemented anywhere. Of course there is not a single test. What are you talking about: Sake-Tests. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct.
Again, what do you mean? There are two algorithms in use. The first is lifted directly from rake. The second is stolen directly from universes.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It doesn't depend upon that compiler hack. That hack provides the ability to put textual data in as an appendix to a method. It is an entirely independent facility that could be perhaps better included as a trait for those that want it.
The version I found in the latest Pharo-Dev images has the compiler hack loaded and depends on it (or the package definitions).
I don't think it is fair to use code critics as an argument.
You can't deny that references to variables and classes that do not exist in the system are not a serious bug.
To me it appears that you have developed all of these tools for your own use.
Code Critics is part of the refactoring browser by Don Roberts and John Brant. The refactoring browser is one of the most amazing pieces of Smalltalk code I have ever seen. I am maintaining the code-base in Pharo (and previously in Squeak), because it makes me much more productive in my daily work. Code critics provides a huge set of high quality tests for free that can quickly point out flaws in code. It is not always correct, but it is usually very good to find the problematic parts of a system.
not implemented anywhere. Of course there is not a single test. What are you talking about: Sake-Tests.
I am sorry. I was not aware of that package. I should have checked online. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
It doesn't depend upon that compiler hack. That hack provides the ability to put textual data in as an appendix to a method. It is an entirely independent facility that could be perhaps better included as a trait for those that want it.
The version I found in the latest Pharo-Dev images has the compiler hack loaded and depends on it (or the package definitions).
The package definitions do not depend on it, it allows the compiler to ignore code after 6 quote marks. myMethod ^ self """""" Some text here as documentation. Bob will also use this facility, because it provides a place to put scripts verbatim without having to escape quotes. Again you dont have to use it.
I don't think it is fair to use code critics as an argument.
You can't deny that references to variables and classes that do not exist in the system are not a serious bug.
Yes I can, because plainly it hasnt effected use for while. If the tests run then its not a serious bug. These sot of artifacts are unwanted side effects in a rapidly evolving code base, they are not a big deal in the grand scheme of things.
To me it appears that you have developed all of these tools for your own use.
Code Critics is part of the refactoring browser by Don Roberts and John Brant.
The refactoring browser is one of the most amazing pieces of Smalltalk code I have ever seen. I am maintaining the code-base in Pharo (and
Well I never liked it, when I used it last I only had a 700Mhz machine to work on, it was slow, buggy, menu items I used frequently were missing. In short it was impossible to actually use.
previously in Squeak), because it makes me much more productive in my daily work. Code critics provides a huge set of high quality tests for free that can quickly point out flaws in code. It is not always correct, but it is usually very good to find the problematic parts of a system ok
Keith
But we do not want hacks. :) and hidden dependencies. Frankly I do not understand why this is not possible to use a method (since a method is a script with a name).
Well I never liked it, when I used it last I only had a 700Mhz machine to work on, it was slow, buggy, menu items I used frequently were missing. In short it was impossible to actually use.
But it is working since years now. I never understood why some Squeakers did not the value of it. For Pharo I would like to have deeper integration of RB engine. Stef
Stéphane Ducasse wrote:
But we do not want hacks. :) and hidden dependencies. Frankly I do not understand why this is not possible to use a method (since a method is a script with a name).
Because methods have to compile, or they are not accepted. In bob's case these are scripts that will run in a different image, so do not necessarily compile in Bob's image. In mantis's case these are the bug reports downloaded for searching and reference purposes. I dont regard this as a hack since Smalltalk is designed to have this flexibility of supporting differnnt languages, and syntaxes. If you dont like it then why not remove #compilerClass altogether. If you call this a hack then what is WAFileDirectory? You would think that using methods to store data in the image has never been done before. Keith
On Feb 20, 2009, at 8:44 AM, Keith Hodges wrote:
Stéphane Ducasse wrote:
But we do not want hacks. :) and hidden dependencies. Frankly I do not understand why this is not possible to use a method (since a method is a script with a name).
Because methods have to compile, or they are not accepted.
In bob's case these are scripts that will run in a different image, so do not necessarily compile in Bob's image.
In mantis's case these are the bug reports downloaded for searching and reference purposes.
I dont regard this as a hack since Smalltalk is designed to have this flexibility of supporting differnnt languages, and syntaxes. If you dont like it then why not remove #compilerClass altogether.
If you call this a hack then what is WAFileDirectory? You would think that using methods to store data in the image has never been done before.
but these images do not require to extend the compiler. What I do not understand is how the browse also shows you this extra code at the end of methods. My gut feeling is that there is certainly a clean way to do that.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
but these images do not require to extend the compiler.
There is no extension to the compiler. All it does is give the compiler the source up to the marker. The compiler is not changed at all. Matthew just felt that it was cleaner to subclass the compiler, than to put the methods in the class itself, as I used to do. Keith
Where is the documentation?
http://www.refactory.com/RefactoringBrowser/BrowserPagesLint.html For an overview of RB: http://www.refactory.com/RefactoringBrowser/index.html Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (8)
-
Alexandre Bergel -
Alexandre Bergel -
Damien Cassou -
David Röthlisberger -
Keith Hodges -
Lukas Renggli -
Ramon Leon -
Stéphane Ducasse