Hi
I tried loading Glamour using the instructions at <http://www.moosetechnology.org/tools/glamour> Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamour'; load. (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault However, in the process of loading, I get this warning: This package depends on the following classes: SubscriptionRegistry You must resolve these dependencies before you will be able to load these definitions: SubscriptionRegistry>>glmSubscriptions Select Proceed to continue, or close this window to cancel the operation. If I hit proceed, I then get another warning: This package depends on the following classes: SubscriptionRegistry You must resolve these dependencies before you will be able to load these definitions: SubscriptionRegistry>>hasHandlerFor: SubscriptionRegistry>>lookFor: SubscriptionRegistry>>lookFor:ifNone: SubscriptionRegistry>>unsubscribeForEvent: Select Proceed to continue, or close this window to cancel the operation. I selected Proceed and when I do: GLMBasicExamples open I get a MNU in GLMAnnouncer>>resetAnnouncer registry reset "since registry is not defined" I compared the methods in GLMAnnouncer to the Moose-4.4 image <http://www.moosetechnology.org/download/4.4> and found out that the methods are different from what ConfigurationOfGlamour loads – which might explain the problem. Is it still possible to load Glamour on its own? I only need it for creating some simple browsers and I don't need everything else in Moose. I've already built the browser in the Moose-4.4 image and just want to run in inside a Pharo-1.2 image. Thanks! -- Nick |
Hi Nick,
The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. Cheers, Doru On 23 May 2011, at 20:47, Nick Chen wrote: > Hi > > I tried loading Glamour using the instructions at > <http://www.moosetechnology.org/tools/glamour> > > > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamour'; > load. > (Smalltalk at: #ConfigurationOfGlamour) > perform: #loadDefault > > > However, in the process of loading, I get this warning: > > > This package depends on the following classes: > SubscriptionRegistry > You must resolve these dependencies before you will be able to load these > definitions: > SubscriptionRegistry>>glmSubscriptions > > > Select Proceed to continue, or close this window to cancel the operation. > > > If I hit proceed, I then get another warning: > > > This package depends on the following classes: > SubscriptionRegistry > You must resolve these dependencies before you will be able to load these > definitions: > SubscriptionRegistry>>hasHandlerFor: > SubscriptionRegistry>>lookFor: > SubscriptionRegistry>>lookFor:ifNone: > SubscriptionRegistry>>unsubscribeForEvent: > > > Select Proceed to continue, or close this window to cancel the operation. > > > I selected Proceed and when I do: > > > GLMBasicExamples open > > > I get a MNU in > > GLMAnnouncer>>resetAnnouncer > registry reset "since registry is not defined" > > > I compared the methods in GLMAnnouncer to the Moose-4.4 image > <http://www.moosetechnology.org/download/4.4> and found out that the > methods are > different from what ConfigurationOfGlamour loads – which might explain the > problem. > > Is it still possible to load Glamour on its own? I only need it for creating > some simple browsers and I don't need everything else in Moose. I've already > built the browser in the Moose-4.4 image and just want to run in inside a > Pharo-1.2 image. > > Thanks! > > -- > Nick > > -- > View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html > Sent from the Moose mailing list archive at Nabble.com. > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
I haven't check, but I guess there is a version of Glamour that works on 1.2 right?
Cheers, Alexandre On 23 May 2011, at 14:59, Tudor Girba wrote: > Hi Nick, > > The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. > > We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. > > Cheers, > Doru > > > On 23 May 2011, at 20:47, Nick Chen wrote: > >> Hi >> >> I tried loading Glamour using the instructions at >> <http://www.moosetechnology.org/tools/glamour> >> >> >> Gofer new >> squeaksource: 'Glamour'; >> package: 'ConfigurationOfGlamour'; >> load. >> (Smalltalk at: #ConfigurationOfGlamour) >> perform: #loadDefault >> >> >> However, in the process of loading, I get this warning: >> >> >> This package depends on the following classes: >> SubscriptionRegistry >> You must resolve these dependencies before you will be able to load these >> definitions: >> SubscriptionRegistry>>glmSubscriptions >> >> >> Select Proceed to continue, or close this window to cancel the operation. >> >> >> If I hit proceed, I then get another warning: >> >> >> This package depends on the following classes: >> SubscriptionRegistry >> You must resolve these dependencies before you will be able to load these >> definitions: >> SubscriptionRegistry>>hasHandlerFor: >> SubscriptionRegistry>>lookFor: >> SubscriptionRegistry>>lookFor:ifNone: >> SubscriptionRegistry>>unsubscribeForEvent: >> >> >> Select Proceed to continue, or close this window to cancel the operation. >> >> >> I selected Proceed and when I do: >> >> >> GLMBasicExamples open >> >> >> I get a MNU in >> >> GLMAnnouncer>>resetAnnouncer >> registry reset "since registry is not defined" >> >> >> I compared the methods in GLMAnnouncer to the Moose-4.4 image >> <http://www.moosetechnology.org/download/4.4> and found out that the >> methods are >> different from what ConfigurationOfGlamour loads – which might explain the >> problem. >> >> Is it still possible to load Glamour on its own? I only need it for creating >> some simple browsers and I don't need everything else in Moose. I've already >> built the browser in the Moose-4.4 image and just want to run in inside a >> Pharo-1.2 image. >> >> Thanks! >> >> -- >> Nick >> >> -- >> View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html >> Sent from the Moose mailing list archive at Nabble.com. >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
There is no configuration version that loads and works in 1.2 as far as I know.
Cheers, Doru On 23 May 2011, at 21:52, Alexandre Bergel wrote: > I haven't check, but I guess there is a version of Glamour that works on 1.2 right? > > Cheers, > Alexandre > > > > On 23 May 2011, at 14:59, Tudor Girba wrote: > >> Hi Nick, >> >> The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. >> >> We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. >> >> Cheers, >> Doru >> >> >> On 23 May 2011, at 20:47, Nick Chen wrote: >> >>> Hi >>> >>> I tried loading Glamour using the instructions at >>> <http://www.moosetechnology.org/tools/glamour> >>> >>> >>> Gofer new >>> squeaksource: 'Glamour'; >>> package: 'ConfigurationOfGlamour'; >>> load. >>> (Smalltalk at: #ConfigurationOfGlamour) >>> perform: #loadDefault >>> >>> >>> However, in the process of loading, I get this warning: >>> >>> >>> This package depends on the following classes: >>> SubscriptionRegistry >>> You must resolve these dependencies before you will be able to load these >>> definitions: >>> SubscriptionRegistry>>glmSubscriptions >>> >>> >>> Select Proceed to continue, or close this window to cancel the operation. >>> >>> >>> If I hit proceed, I then get another warning: >>> >>> >>> This package depends on the following classes: >>> SubscriptionRegistry >>> You must resolve these dependencies before you will be able to load these >>> definitions: >>> SubscriptionRegistry>>hasHandlerFor: >>> SubscriptionRegistry>>lookFor: >>> SubscriptionRegistry>>lookFor:ifNone: >>> SubscriptionRegistry>>unsubscribeForEvent: >>> >>> >>> Select Proceed to continue, or close this window to cancel the operation. >>> >>> >>> I selected Proceed and when I do: >>> >>> >>> GLMBasicExamples open >>> >>> >>> I get a MNU in >>> >>> GLMAnnouncer>>resetAnnouncer >>> registry reset "since registry is not defined" >>> >>> >>> I compared the methods in GLMAnnouncer to the Moose-4.4 image >>> <http://www.moosetechnology.org/download/4.4> and found out that the >>> methods are >>> different from what ConfigurationOfGlamour loads – which might explain the >>> problem. >>> >>> Is it still possible to load Glamour on its own? I only need it for creating >>> some simple browsers and I don't need everything else in Moose. I've already >>> built the browser in the Moose-4.4 image and just want to run in inside a >>> Pharo-1.2 image. >>> >>> Thanks! >>> >>> -- >>> Nick >>> >>> -- >>> View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html >>> Sent from the Moose mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "There are no old things, there are only old ways of looking at them." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Beauty is where we see it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
I notice this problem too. It left me puzzled why we have to deal with
all these configurations if we then can't even load an old version? I always thought that it was one of the main arguments of Metacello to have a specification that we can use to load old versions in 10 years from now :-/ Lukas On 23 May 2011 22:03, Tudor Girba <[hidden email]> wrote: > There is no configuration version that loads and works in 1.2 as far as I know. > > Cheers, > Doru > > > On 23 May 2011, at 21:52, Alexandre Bergel wrote: > >> I haven't check, but I guess there is a version of Glamour that works on 1.2 right? >> >> Cheers, >> Alexandre >> >> >> >> On 23 May 2011, at 14:59, Tudor Girba wrote: >> >>> Hi Nick, >>> >>> The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. >>> >>> We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. >>> >>> Cheers, >>> Doru >>> >>> >>> On 23 May 2011, at 20:47, Nick Chen wrote: >>> >>>> Hi >>>> >>>> I tried loading Glamour using the instructions at >>>> <http://www.moosetechnology.org/tools/glamour> >>>> >>>> >>>> Gofer new >>>> squeaksource: 'Glamour'; >>>> package: 'ConfigurationOfGlamour'; >>>> load. >>>> (Smalltalk at: #ConfigurationOfGlamour) >>>> perform: #loadDefault >>>> >>>> >>>> However, in the process of loading, I get this warning: >>>> >>>> >>>> This package depends on the following classes: >>>> SubscriptionRegistry >>>> You must resolve these dependencies before you will be able to load these >>>> definitions: >>>> SubscriptionRegistry>>glmSubscriptions >>>> >>>> >>>> Select Proceed to continue, or close this window to cancel the operation. >>>> >>>> >>>> If I hit proceed, I then get another warning: >>>> >>>> >>>> This package depends on the following classes: >>>> SubscriptionRegistry >>>> You must resolve these dependencies before you will be able to load these >>>> definitions: >>>> SubscriptionRegistry>>hasHandlerFor: >>>> SubscriptionRegistry>>lookFor: >>>> SubscriptionRegistry>>lookFor:ifNone: >>>> SubscriptionRegistry>>unsubscribeForEvent: >>>> >>>> >>>> Select Proceed to continue, or close this window to cancel the operation. >>>> >>>> >>>> I selected Proceed and when I do: >>>> >>>> >>>> GLMBasicExamples open >>>> >>>> >>>> I get a MNU in >>>> >>>> GLMAnnouncer>>resetAnnouncer >>>> registry reset "since registry is not defined" >>>> >>>> >>>> I compared the methods in GLMAnnouncer to the Moose-4.4 image >>>> <http://www.moosetechnology.org/download/4.4> and found out that the >>>> methods are >>>> different from what ConfigurationOfGlamour loads – which might explain the >>>> problem. >>>> >>>> Is it still possible to load Glamour on its own? I only need it for creating >>>> some simple browsers and I don't need everything else in Moose. I've already >>>> built the browser in the Moose-4.4 image and just want to run in inside a >>>> Pharo-1.2 image. >>>> >>>> Thanks! >>>> >>>> -- >>>> Nick >>>> >>>> -- >>>> View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html >>>> Sent from the Moose mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "There are no old things, there are only old ways of looking at them." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Lukas
If doru specifies that you always load the lastest bleeding edge then how the system would magically know what do load when you go back to use an old image? Tell me because I'm curious to know. Now I can take my configuration and load them in old versions without problems. Now with the symbolic version this is even simpler. Then finally without configurations to manage complex dependencies there is no way that we will scale and not end up in a group of guys having fun with our old little image. If we cannot control what is loadable together, then better stop to try to build a better smalltalk. Especially at the speed of change we are. Stef On May 23, 2011, at 10:26 PM, Lukas Renggli wrote: > I notice this problem too. It left me puzzled why we have to deal with > all these configurations if we then can't even load an old version? I > always thought that it was one of the main arguments of Metacello to > have a specification that we can use to load old versions in 10 years > from now :-/ > > Lukas > > On 23 May 2011 22:03, Tudor Girba <[hidden email]> wrote: >> There is no configuration version that loads and works in 1.2 as far as I know. >> >> Cheers, >> Doru >> >> >> On 23 May 2011, at 21:52, Alexandre Bergel wrote: >> >>> I haven't check, but I guess there is a version of Glamour that works on 1.2 right? >>> >>> Cheers, >>> Alexandre >>> >>> >>> >>> On 23 May 2011, at 14:59, Tudor Girba wrote: >>> >>>> Hi Nick, >>>> >>>> The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. >>>> >>>> We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 23 May 2011, at 20:47, Nick Chen wrote: >>>> >>>>> Hi >>>>> >>>>> I tried loading Glamour using the instructions at >>>>> <http://www.moosetechnology.org/tools/glamour> >>>>> >>>>> >>>>> Gofer new >>>>> squeaksource: 'Glamour'; >>>>> package: 'ConfigurationOfGlamour'; >>>>> load. >>>>> (Smalltalk at: #ConfigurationOfGlamour) >>>>> perform: #loadDefault >>>>> >>>>> >>>>> However, in the process of loading, I get this warning: >>>>> >>>>> >>>>> This package depends on the following classes: >>>>> SubscriptionRegistry >>>>> You must resolve these dependencies before you will be able to load these >>>>> definitions: >>>>> SubscriptionRegistry>>glmSubscriptions >>>>> >>>>> >>>>> Select Proceed to continue, or close this window to cancel the operation. >>>>> >>>>> >>>>> If I hit proceed, I then get another warning: >>>>> >>>>> >>>>> This package depends on the following classes: >>>>> SubscriptionRegistry >>>>> You must resolve these dependencies before you will be able to load these >>>>> definitions: >>>>> SubscriptionRegistry>>hasHandlerFor: >>>>> SubscriptionRegistry>>lookFor: >>>>> SubscriptionRegistry>>lookFor:ifNone: >>>>> SubscriptionRegistry>>unsubscribeForEvent: >>>>> >>>>> >>>>> Select Proceed to continue, or close this window to cancel the operation. >>>>> >>>>> >>>>> I selected Proceed and when I do: >>>>> >>>>> >>>>> GLMBasicExamples open >>>>> >>>>> >>>>> I get a MNU in >>>>> >>>>> GLMAnnouncer>>resetAnnouncer >>>>> registry reset "since registry is not defined" >>>>> >>>>> >>>>> I compared the methods in GLMAnnouncer to the Moose-4.4 image >>>>> <http://www.moosetechnology.org/download/4.4> and found out that the >>>>> methods are >>>>> different from what ConfigurationOfGlamour loads – which might explain the >>>>> problem. >>>>> >>>>> Is it still possible to load Glamour on its own? I only need it for creating >>>>> some simple browsers and I don't need everything else in Moose. I've already >>>>> built the browser in the Moose-4.4 image and just want to run in inside a >>>>> Pharo-1.2 image. >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Nick >>>>> >>>>> -- >>>>> View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html >>>>> Sent from the Moose mailing list archive at Nabble.com. >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "There are no old things, there are only old ways of looking at them." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi,
Let's not mix things :). @Lukas: If you specify the hard-coded versions with Metacello, it works as expected. We just do not have the version for Glamour. @Stef: Having the continuous integration server stress the baseline (this is what default is) does not impede in any way having hardcoded versions. However, the problem is that when you have a nested configurations like we have with Moose, it is basically not really possible, or at least I do not know how to create a configuration version automatically. The issue is how to version the nested configuration and how to propagate these versions upwards. In fact, we do have a #stable symbolic version build that happens to be red since a while. So, the issue is with our ability of working with Metacello. The other issue is that I did not have time to take care of manually versioning Moose (Alex tried with 4.3 and it ended up in a mess). But, it is true that we should find a solution. Positive efforts are welcome as always :). Cheers, Doru On 23 May 2011, at 23:14, Stéphane Ducasse wrote: > Lukas > > If doru specifies that you always load the lastest bleeding edge then how the system would magically know what do load when you go back to use > an old image? Tell me because I'm curious to know. > > Now I can take my configuration and load them in old versions without problems. > Now with the symbolic version this is even simpler. > > Then finally without configurations to manage complex dependencies there is no way that we will scale and not end up > in a group of guys having fun with our old little image. If we cannot control what is loadable together, then better stop > to try to build a better smalltalk. Especially at the speed of change we are. > > Stef > > > On May 23, 2011, at 10:26 PM, Lukas Renggli wrote: > >> I notice this problem too. It left me puzzled why we have to deal with >> all these configurations if we then can't even load an old version? I >> always thought that it was one of the main arguments of Metacello to >> have a specification that we can use to load old versions in 10 years >> from now :-/ >> >> Lukas >> >> On 23 May 2011 22:03, Tudor Girba <[hidden email]> wrote: >>> There is no configuration version that loads and works in 1.2 as far as I know. >>> >>> Cheers, >>> Doru >>> >>> >>> On 23 May 2011, at 21:52, Alexandre Bergel wrote: >>> >>>> I haven't check, but I guess there is a version of Glamour that works on 1.2 right? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> >>>> On 23 May 2011, at 14:59, Tudor Girba wrote: >>>> >>>>> Hi Nick, >>>>> >>>>> The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. >>>>> >>>>> We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 23 May 2011, at 20:47, Nick Chen wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I tried loading Glamour using the instructions at >>>>>> <http://www.moosetechnology.org/tools/glamour> >>>>>> >>>>>> >>>>>> Gofer new >>>>>> squeaksource: 'Glamour'; >>>>>> package: 'ConfigurationOfGlamour'; >>>>>> load. >>>>>> (Smalltalk at: #ConfigurationOfGlamour) >>>>>> perform: #loadDefault >>>>>> >>>>>> >>>>>> However, in the process of loading, I get this warning: >>>>>> >>>>>> >>>>>> This package depends on the following classes: >>>>>> SubscriptionRegistry >>>>>> You must resolve these dependencies before you will be able to load these >>>>>> definitions: >>>>>> SubscriptionRegistry>>glmSubscriptions >>>>>> >>>>>> >>>>>> Select Proceed to continue, or close this window to cancel the operation. >>>>>> >>>>>> >>>>>> If I hit proceed, I then get another warning: >>>>>> >>>>>> >>>>>> This package depends on the following classes: >>>>>> SubscriptionRegistry >>>>>> You must resolve these dependencies before you will be able to load these >>>>>> definitions: >>>>>> SubscriptionRegistry>>hasHandlerFor: >>>>>> SubscriptionRegistry>>lookFor: >>>>>> SubscriptionRegistry>>lookFor:ifNone: >>>>>> SubscriptionRegistry>>unsubscribeForEvent: >>>>>> >>>>>> >>>>>> Select Proceed to continue, or close this window to cancel the operation. >>>>>> >>>>>> >>>>>> I selected Proceed and when I do: >>>>>> >>>>>> >>>>>> GLMBasicExamples open >>>>>> >>>>>> >>>>>> I get a MNU in >>>>>> >>>>>> GLMAnnouncer>>resetAnnouncer >>>>>> registry reset "since registry is not defined" >>>>>> >>>>>> >>>>>> I compared the methods in GLMAnnouncer to the Moose-4.4 image >>>>>> <http://www.moosetechnology.org/download/4.4> and found out that the >>>>>> methods are >>>>>> different from what ConfigurationOfGlamour loads – which might explain the >>>>>> problem. >>>>>> >>>>>> Is it still possible to load Glamour on its own? I only need it for creating >>>>>> some simple browsers and I don't need everything else in Moose. I've already >>>>>> built the browser in the Moose-4.4 image and just want to run in inside a >>>>>> Pharo-1.2 image. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> Nick >>>>>> >>>>>> -- >>>>>> View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html >>>>>> Sent from the Moose mailing list archive at Nabble.com. >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "There are no old things, there are only old ways of looking at them." >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Beauty is where we see it." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We are all great at making mistakes." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
> So, the issue is with our ability of working with Metacello. The other issue is that I did not have time to take care of manually versioning Moose (Alex tried with 4.3 and it ended up in a mess).
Sad. This was due to some bug in the metacello toolbox Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Stéphane Ducasse
I think both Stef and Lukas are right.
Yes configuration management is crucial to be able to evolve and manage the dependencies. But Metacello does not seem to offer the right trade-offs between the effort of setting up / maintaining configurations and the 'guarantees' of being able to load old/specific versions of X . The latter is my interpretation of lukas' point, colored by my recent explorations with confgurations. Please forgive me if I am wrong. I wish I had an answer to the problem, but I dont, sorry :-( On 23 May 2011, at 17:14, Stéphane Ducasse wrote: > Lukas > > If doru specifies that you always load the lastest bleeding edge then how the system would magically know what do load when you go back to use > an old image? Tell me because I'm curious to know. > > Now I can take my configuration and load them in old versions without problems. > Now with the symbolic version this is even simpler. > > Then finally without configurations to manage complex dependencies there is no way that we will scale and not end up > in a group of guys having fun with our old little image. If we cannot control what is loadable together, then better stop > to try to build a better smalltalk. Especially at the speed of change we are. > > Stef > > > On May 23, 2011, at 10:26 PM, Lukas Renggli wrote: > >> I notice this problem too. It left me puzzled why we have to deal with >> all these configurations if we then can't even load an old version? I >> always thought that it was one of the main arguments of Metacello to >> have a specification that we can use to load old versions in 10 years >> from now :-/ >> >> Lukas -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Tudor Girba-2
On 23 May 2011, at 17:42, Tudor Girba wrote: > So, the issue is with our ability of working with Metacello. The other issue is that I did not have time to take care of manually versioning Moose (Alex tried with 4.3 and it ended up in a mess). Having no 4.3 that can be loaded from source is sad :-( > But, it is true that we should find a solution. Positive efforts are welcome as always :). I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello? -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
> I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello?
Not sure if I understood correctly. Does the following line helps you? ConfigurationOfAutotest project lastVersion packages Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On 23 May 2011, at 18:11, Alexandre Bergel wrote: >> I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello? > > > Not sure if I understood correctly. Does the following line helps you? > ConfigurationOfAutotest project lastVersion packages Does this tell me in what order those packages need to be loaded? Because package foo requires package bar, bar needs to be loaded first. I am looking for a way to build a partial (loading) order for a given list of packages. -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Best is to ask Dale.
Alexandre On 23 May 2011, at 18:30, Johan Fabry wrote: > > On 23 May 2011, at 18:11, Alexandre Bergel wrote: > >>> I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello? >> >> >> Not sure if I understood correctly. Does the following line helps you? >> ConfigurationOfAutotest project lastVersion packages > > > Does this tell me in what order those packages need to be loaded? Because package foo requires package bar, bar needs to be loaded first. I am looking for a way to build a partial (loading) order for a given list of packages. > > -- > Johan Fabry > [hidden email] - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Tudor Girba-2
On May 23, 2011, at 11:42 PM, Tudor Girba wrote: > Hi, > > Let's not mix things :). > > @Lukas: If you specify the hard-coded versions with Metacello, it works as expected. We just do not have the version for Glamour. > > @Stef: Having the continuous integration server stress the baseline (this is what default is) does not impede in any way having hardcoded versions. Yes I know :) > However, the problem is that when you have a nested configurations like we have with Moose, it is basically not really possible, or at least I do not know how to create a configuration version automatically. The issue is how to version the nested configuration and how to propagate these versions upwards. I see. Did you check the metacello toolbox because I think that tis is in the api > In fact, we do have a #stable symbolic version build that happens to be red since a while. > > So, the issue is with our ability of working with Metacello. The other issue is that I did not have time to take care of manually versioning Moose (Alex tried with 4.3 and it ended up in a mess). > > But, it is true that we should find a solution. Positive efforts are welcome as always :). > > Cheers, > Doru > > > > On 23 May 2011, at 23:14, Stéphane Ducasse wrote: > >> Lukas >> >> If doru specifies that you always load the lastest bleeding edge then how the system would magically know what do load when you go back to use >> an old image? Tell me because I'm curious to know. >> >> Now I can take my configuration and load them in old versions without problems. >> Now with the symbolic version this is even simpler. >> >> Then finally without configurations to manage complex dependencies there is no way that we will scale and not end up >> in a group of guys having fun with our old little image. If we cannot control what is loadable together, then better stop >> to try to build a better smalltalk. Especially at the speed of change we are. >> >> Stef >> >> >> On May 23, 2011, at 10:26 PM, Lukas Renggli wrote: >> >>> I notice this problem too. It left me puzzled why we have to deal with >>> all these configurations if we then can't even load an old version? I >>> always thought that it was one of the main arguments of Metacello to >>> have a specification that we can use to load old versions in 10 years >>> from now :-/ >>> >>> Lukas >>> >>> On 23 May 2011 22:03, Tudor Girba <[hidden email]> wrote: >>>> There is no configuration version that loads and works in 1.2 as far as I know. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 23 May 2011, at 21:52, Alexandre Bergel wrote: >>>> >>>>> I haven't check, but I guess there is a version of Glamour that works on 1.2 right? >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> >>>>> On 23 May 2011, at 14:59, Tudor Girba wrote: >>>>> >>>>>> Hi Nick, >>>>>> >>>>>> The default configuration of Glamour does not work in Pharo 1.2 anymore, only in 1.3. The differences are related to changes in the Announcements framework, and a couple of Morphic-related issues. >>>>>> >>>>>> We are still looking to get someone to produce a working configuration version based on what is in the Moose 4.4 image. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 23 May 2011, at 20:47, Nick Chen wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I tried loading Glamour using the instructions at >>>>>>> <http://www.moosetechnology.org/tools/glamour> >>>>>>> >>>>>>> >>>>>>> Gofer new >>>>>>> squeaksource: 'Glamour'; >>>>>>> package: 'ConfigurationOfGlamour'; >>>>>>> load. >>>>>>> (Smalltalk at: #ConfigurationOfGlamour) >>>>>>> perform: #loadDefault >>>>>>> >>>>>>> >>>>>>> However, in the process of loading, I get this warning: >>>>>>> >>>>>>> >>>>>>> This package depends on the following classes: >>>>>>> SubscriptionRegistry >>>>>>> You must resolve these dependencies before you will be able to load these >>>>>>> definitions: >>>>>>> SubscriptionRegistry>>glmSubscriptions >>>>>>> >>>>>>> >>>>>>> Select Proceed to continue, or close this window to cancel the operation. >>>>>>> >>>>>>> >>>>>>> If I hit proceed, I then get another warning: >>>>>>> >>>>>>> >>>>>>> This package depends on the following classes: >>>>>>> SubscriptionRegistry >>>>>>> You must resolve these dependencies before you will be able to load these >>>>>>> definitions: >>>>>>> SubscriptionRegistry>>hasHandlerFor: >>>>>>> SubscriptionRegistry>>lookFor: >>>>>>> SubscriptionRegistry>>lookFor:ifNone: >>>>>>> SubscriptionRegistry>>unsubscribeForEvent: >>>>>>> >>>>>>> >>>>>>> Select Proceed to continue, or close this window to cancel the operation. >>>>>>> >>>>>>> >>>>>>> I selected Proceed and when I do: >>>>>>> >>>>>>> >>>>>>> GLMBasicExamples open >>>>>>> >>>>>>> >>>>>>> I get a MNU in >>>>>>> >>>>>>> GLMAnnouncer>>resetAnnouncer >>>>>>> registry reset "since registry is not defined" >>>>>>> >>>>>>> >>>>>>> I compared the methods in GLMAnnouncer to the Moose-4.4 image >>>>>>> <http://www.moosetechnology.org/download/4.4> and found out that the >>>>>>> methods are >>>>>>> different from what ConfigurationOfGlamour loads – which might explain the >>>>>>> problem. >>>>>>> >>>>>>> Is it still possible to load Glamour on its own? I only need it for creating >>>>>>> some simple browsers and I don't need everything else in Moose. I've already >>>>>>> built the browser in the Moose-4.4 image and just want to run in inside a >>>>>>> Pharo-1.2 image. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Nick >>>>>>> >>>>>>> -- >>>>>>> View this message in context: http://forum.world.st/Problem-loading-ConfigurationOfGlamour-in-Pharo-1-2-SubscriptionRegistry-dependency-tp3544954p3544954.html >>>>>>> Sent from the Moose mailing list archive at Nabble.com. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "There are no old things, there are only old ways of looking at them." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Beauty is where we see it." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by jfabry
Here is the script that Dale provided:
| version directive pkgs | version := ConfigurationOfGlamour new project version: 'default'. version ignoreImage: true. directive := version record loadDirective. pkgs := OrderedCollection new. directive packageDirectivesDo: [:pkgDirective | pkgs add: pkgDirective file ]. pkgs Cheers, Doru On 24 May 2011, at 00:30, Johan Fabry wrote: > > On 23 May 2011, at 18:11, Alexandre Bergel wrote: > >>> I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello? >> >> >> Not sure if I understood correctly. Does the following line helps you? >> ConfigurationOfAutotest project lastVersion packages > > > Does this tell me in what order those packages need to be loaded? Because package foo requires package bar, bar needs to be loaded first. I am looking for a way to build a partial (loading) order for a given list of packages. > > -- > Johan Fabry > [hidden email] - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Thanks, Doru, will have a look at this later this week, need to get some other projects up and running first. However, one question: given a ConfigurationOfX, how do I know which version of this configuration was loaded? On 24 May 2011, at 03:50, Tudor Girba wrote: > Here is the script that Dale provided: > > > | version directive pkgs | > version := ConfigurationOfGlamour new project version: 'default'. > version ignoreImage: true. > directive := version record loadDirective. > pkgs := OrderedCollection new. > directive packageDirectivesDo: [:pkgDirective | > pkgs add: pkgDirective file ]. > pkgs > > Cheers, > Doru > > > On 24 May 2011, at 00:30, Johan Fabry wrote: > >> >> On 23 May 2011, at 18:11, Alexandre Bergel wrote: >> >>>> I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello? >>> >>> >>> Not sure if I understood correctly. Does the following line helps you? >>> ConfigurationOfAutotest project lastVersion packages >> >> >> Does this tell me in what order those packages need to be loaded? Because package foo requires package bar, bar needs to be loaded first. I am looking for a way to build a partial (loading) order for a given list of packages. >> >> -- >> Johan Fabry >> [hidden email] - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry [hidden email] - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi,
On 26 May 2011, at 17:22, Johan Fabry wrote: > > Thanks, Doru, will have a look at this later this week, need to get some other projects up and running first. > > However, one question: given a ConfigurationOfX, how do I know which version of this configuration was loaded? There is a way, but I do not know it from on top of my head. Also, I am not sure how accurate it is. In any case, in the case of Moose, you know that it was 'default' :) Cheers, Doru > On 24 May 2011, at 03:50, Tudor Girba wrote: > >> Here is the script that Dale provided: >> >> >> | version directive pkgs | >> version := ConfigurationOfGlamour new project version: 'default'. >> version ignoreImage: true. >> directive := version record loadDirective. >> pkgs := OrderedCollection new. >> directive packageDirectivesDo: [:pkgDirective | >> pkgs add: pkgDirective file ]. >> pkgs >> >> Cheers, >> Doru >> >> >> On 24 May 2011, at 00:30, Johan Fabry wrote: >> >>> >>> On 23 May 2011, at 18:11, Alexandre Bergel wrote: >>> >>>>> I'm trying to get something working but got stuck, see my mail of a few days ago, now condensed in a 2-line question on pharo-users: Given a specific MCPackage that was loaded because of an unknown Metacello config, how can I obtain the list of required packages from Metacello? >>>> >>>> >>>> Not sure if I understood correctly. Does the following line helps you? >>>> ConfigurationOfAutotest project lastVersion packages >>> >>> >>> Does this tell me in what order those packages need to be loaded? Because package foo requires package bar, bar needs to be loaded first. I am looking for a way to build a partial (loading) order for a given list of packages. >>> >>> -- >>> Johan Fabry >>> [hidden email] - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > [hidden email] - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |