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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Wed, Feb 18, 2009 at 5:11 PM, Alexandre Bergel
<[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Damien Cassou
> On Wed, Feb 18, 2009 at 5:11 PM, Alexandre Bergel > <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Damien Cassou
>> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
+ 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by David Röthlisberger-2
On Thu, Feb 19, 2009 at 10:16 AM, David Röthlisberger
<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Thu, Feb 19, 2009 at 10:38 AM, David Röthlisberger
<[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Thu, Feb 19, 2009 at 11:59 AM, Lukas Renggli <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Lukas Renggli
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Alexandre Bergel-4
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 <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Lukas Renggli
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). > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by keith1y
> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by keith1y
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |