- Pharo-dev - lists.pharo.org

Re: Polymorph Vistary skin bug (was:Re: [Pharo-project] New pharo-devbased on latest version)

by Gary Chambers

In 3.9 blocks do respond appropriately... Regards, Gary. ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, November 11, 2008 3:58 PM Subject: Polymorph Vistary skin bug (was:Re: [Pharo-project] New pharo-devbased on latest version) > Found a solution to make it work in Pharo: > The three messages > createCloseBoxFor: > createCollapseBoxFor: > createExpandBoxFor: > in UIThemeVistary > needs the block argument of addUpAction: in each replaced by: > (MessageSend receiver: aSystemWindow selector: > #correspondingMethodInBlock). > > (If changing Polymorph isn't the right thing to do, BlockContext needs > to conform to the same protocol as MessageSend, it seems like) > > Cheers, > Henry > > Henrik Johansen wrote: >> Yes. >> It seems related to a Pharo fix, overrides in Polymorph packages weren't >> loaded in 101, but they are in 144. >> One of these overrides include SystemWindow>>createCollapseBox to make >> the theme handle how it should be created, in the vistary look this >> method (createCollapseBoxFor: ) calls addUpAction: of >> MultistateButtonMorph with a block as argument, which somehow gets added >> to a WeakActionSequence (I'm not familiar with neither squeak nor >> morphic really). >> This causes an MNU since the block does not respond to isValid used by >> the Sequence to clean up it's items. >> >> I've not really dabbled much in Squeak nor Morphic, seems to me there's >> three alternatives: >> 1. - Bug in Polymorph (a block shouldn't be allowed as an action, sounds >> weird though) >> 2. - Overly zealous cleansing of methods (removal of isValid for blocks) >> 3. -A messy implementation of ActionSequence requiring isValid methods >> spread everywhere. >> >> Henry >> >> StÃ©phane Ducasse wrote: >> >>> Hi henrik >>> >>> thanks for the report. >>> Is the vistary look broken in 144? >>> >>> Stef >>> >>> On Nov 11, 2008, at 3:11 PM, Henrik Johansen wrote: >>> >>> >>>> I've loaded Polymorph successfully (following the instructions at >>>> http://wiki.squeak.org/squeak/6005, the basicLoad override seems to be >>>> mandatory) quite a few time in the released dev images. >>>> TaskbarIcons can not be loaded without a proceed, since it includes an >>>> icon for PackagePaneBrowser, which is not in the pharo dev image. >>>> Vistary look is also broken due to a MNU, worked in 101, but broke >>>> somewhere before133 when I tried loading it next. >>>> Latest I've done it with is the 142 dev image, updated to 144 before >>>> loading Polymorph. >>>> >>>> Cheers, >>>> Henry >>>> >>>> StÃ©phane Ducasse wrote: >>>> >>>>> I hope :) >>>>> we want it in the first version of pharo :) >>>>> >>>>> Stef >>>>> >>>>> On Nov 11, 2008, at 1:45 PM, Igor Stasenko wrote: >>>>> >>>>> >>>>>> 2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>> >>>>>>> Polymorph fixed the menu gradient oddity a long time ago... :-) >>>>>>> >>>>>>> >>>>>> btw, can it be loaded into dev image w/o problems? >>>>>> I'm missing the taskbar, because when you open many browsers >>>>>> overlapping each other, its hard to find needed one. >>>>>> >>>>>> >>>>>>> Regards, Gary. >>>>>>> >>>>>>> ----- Original Message ----- From: "Igor Stasenko" >>>>>>> <siguctua(a)gmail.com> >>>>>>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>>>>> Sent: Monday, November 10, 2008 6:08 PM >>>>>>> Subject: Re: [Pharo-project] New pharo-dev based on latest version >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Some of my observations of glitches found: >>>>>>>> >>>>>>>> - open world menu System->About. Now instead of clicking Ok, try >>>>>>>> drag >>>>>>>> the window. Leads to DNU when you release a mouse button. >>>>>>>> >>>>>>>> - a submenu gradient in OB (maybe not only in OB) is sporadically >>>>>>>> loses its colors: >>>>>>>> when you first open a context menu, and first open a submenu in it, >>>>>>>> all is drawn ok. But then try hover over different menu items to >>>>>>>> force >>>>>>>> hiding/showing submenus, you will notice that newly opened submenus >>>>>>>> start losing gradient background, until finally background becomes >>>>>>>> completely white. >>>>>>>> >>>>>>>> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>>>>>>> >>>>>>>>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> always available at: >>>>>>>>> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Damien Cassou >>>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 11, 2008

[Pharo-project] Re: Polymorph Vistary skin bug

by Henrik Johansen

On a related topic, isValid looks to me like it could use some disambiguation... At the moment, as far as I can see, the implementors could imply the receiver is any of the below: - a valid method name - a valid method reference - a valid socket - a valid action - a valid MC repository - a valid connection queue Henrik Johansen wrote: > Found a solution to make it work in Pharo: > The three messages > createCloseBoxFor: > createCollapseBoxFor: > createExpandBoxFor: > in UIThemeVistary > needs the block argument of addUpAction: in each replaced by: > (MessageSend receiver: aSystemWindow selector: #correspondingMethodInBlock). > > (If changing Polymorph isn't the right thing to do, BlockContext needs > to conform to the same protocol as MessageSend, it seems like) > > Cheers, > Henry > > Henrik Johansen wrote: > >> Yes. >> It seems related to a Pharo fix, overrides in Polymorph packages weren't >> loaded in 101, but they are in 144. >> One of these overrides include SystemWindow>>createCollapseBox to make >> the theme handle how it should be created, in the vistary look this >> method (createCollapseBoxFor: ) calls addUpAction: of >> MultistateButtonMorph with a block as argument, which somehow gets added >> to a WeakActionSequence (I'm not familiar with neither squeak nor >> morphic really). >> This causes an MNU since the block does not respond to isValid used by >> the Sequence to clean up it's items. >> >> I've not really dabbled much in Squeak nor Morphic, seems to me there's >> three alternatives: >> 1. - Bug in Polymorph (a block shouldn't be allowed as an action, sounds >> weird though) >> 2. - Overly zealous cleansing of methods (removal of isValid for blocks) >> 3. -A messy implementation of ActionSequence requiring isValid methods >> spread everywhere. >> >> Henry >> >> StÃ©phane Ducasse wrote: >> >> >>> Hi henrik >>> >>> thanks for the report. >>> Is the vistary look broken in 144? >>> >>> Stef >>> >>> On Nov 11, 2008, at 3:11 PM, Henrik Johansen wrote: >>> >>> >>> >>>> I've loaded Polymorph successfully (following the instructions at >>>> http://wiki.squeak.org/squeak/6005, the basicLoad override seems to be >>>> mandatory) quite a few time in the released dev images. >>>> TaskbarIcons can not be loaded without a proceed, since it includes an >>>> icon for PackagePaneBrowser, which is not in the pharo dev image. >>>> Vistary look is also broken due to a MNU, worked in 101, but broke >>>> somewhere before133 when I tried loading it next. >>>> Latest I've done it with is the 142 dev image, updated to 144 before >>>> loading Polymorph. >>>> >>>> Cheers, >>>> Henry >>>> >>>> StÃ©phane Ducasse wrote: >>>> >>>> >>>>> I hope :) >>>>> we want it in the first version of pharo :) >>>>> >>>>> Stef >>>>> >>>>> On Nov 11, 2008, at 1:45 PM, Igor Stasenko wrote: >>>>> >>>>> >>>>> >>>>>> 2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>> >>>>>> >>>>>>> Polymorph fixed the menu gradient oddity a long time ago... :-) >>>>>>> >>>>>>> >>>>>>> >>>>>> btw, can it be loaded into dev image w/o problems? >>>>>> I'm missing the taskbar, because when you open many browsers >>>>>> overlapping each other, its hard to find needed one. >>>>>> >>>>>> >>>>>> >>>>>>> Regards, Gary. >>>>>>> >>>>>>> ----- Original Message ----- From: "Igor Stasenko" >>>>>>> <siguctua(a)gmail.com> >>>>>>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>>>>> Sent: Monday, November 10, 2008 6:08 PM >>>>>>> Subject: Re: [Pharo-project] New pharo-dev based on latest version >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Some of my observations of glitches found: >>>>>>>> >>>>>>>> - open world menu System->About. Now instead of clicking Ok, try >>>>>>>> drag >>>>>>>> the window. Leads to DNU when you release a mouse button. >>>>>>>> >>>>>>>> - a submenu gradient in OB (maybe not only in OB) is sporadically >>>>>>>> loses its colors: >>>>>>>> when you first open a context menu, and first open a submenu in it, >>>>>>>> all is drawn ok. But then try hover over different menu items to >>>>>>>> force >>>>>>>> hiding/showing submenus, you will notice that newly opened submenus >>>>>>>> start losing gradient background, until finally background becomes >>>>>>>> completely white. >>>>>>>> >>>>>>>> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>>>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> always available at: >>>>>>>>> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Damien Cassou >>>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Nov. 11, 2008

Polymorph Vistary skin bug (was:Re: [Pharo-project] New pharo-dev based on latest version)

by Henrik Johansen

Found a solution to make it work in Pharo: The three messages createCloseBoxFor: createCollapseBoxFor: createExpandBoxFor: in UIThemeVistary needs the block argument of addUpAction: in each replaced by: (MessageSend receiver: aSystemWindow selector: #correspondingMethodInBlock). (If changing Polymorph isn't the right thing to do, BlockContext needs to conform to the same protocol as MessageSend, it seems like) Cheers, Henry Henrik Johansen wrote: > Yes. > It seems related to a Pharo fix, overrides in Polymorph packages weren't > loaded in 101, but they are in 144. > One of these overrides include SystemWindow>>createCollapseBox to make > the theme handle how it should be created, in the vistary look this > method (createCollapseBoxFor: ) calls addUpAction: of > MultistateButtonMorph with a block as argument, which somehow gets added > to a WeakActionSequence (I'm not familiar with neither squeak nor > morphic really). > This causes an MNU since the block does not respond to isValid used by > the Sequence to clean up it's items. > > I've not really dabbled much in Squeak nor Morphic, seems to me there's > three alternatives: > 1. - Bug in Polymorph (a block shouldn't be allowed as an action, sounds > weird though) > 2. - Overly zealous cleansing of methods (removal of isValid for blocks) > 3. -A messy implementation of ActionSequence requiring isValid methods > spread everywhere. > > Henry > > StÃ©phane Ducasse wrote: > >> Hi henrik >> >> thanks for the report. >> Is the vistary look broken in 144? >> >> Stef >> >> On Nov 11, 2008, at 3:11 PM, Henrik Johansen wrote: >> >> >>> I've loaded Polymorph successfully (following the instructions at >>> http://wiki.squeak.org/squeak/6005, the basicLoad override seems to be >>> mandatory) quite a few time in the released dev images. >>> TaskbarIcons can not be loaded without a proceed, since it includes an >>> icon for PackagePaneBrowser, which is not in the pharo dev image. >>> Vistary look is also broken due to a MNU, worked in 101, but broke >>> somewhere before133 when I tried loading it next. >>> Latest I've done it with is the 142 dev image, updated to 144 before >>> loading Polymorph. >>> >>> Cheers, >>> Henry >>> >>> StÃ©phane Ducasse wrote: >>> >>>> I hope :) >>>> we want it in the first version of pharo :) >>>> >>>> Stef >>>> >>>> On Nov 11, 2008, at 1:45 PM, Igor Stasenko wrote: >>>> >>>> >>>>> 2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>> >>>>>> Polymorph fixed the menu gradient oddity a long time ago... :-) >>>>>> >>>>>> >>>>> btw, can it be loaded into dev image w/o problems? >>>>> I'm missing the taskbar, because when you open many browsers >>>>> overlapping each other, its hard to find needed one. >>>>> >>>>> >>>>>> Regards, Gary. >>>>>> >>>>>> ----- Original Message ----- From: "Igor Stasenko" >>>>>> <siguctua(a)gmail.com> >>>>>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>>>> Sent: Monday, November 10, 2008 6:08 PM >>>>>> Subject: Re: [Pharo-project] New pharo-dev based on latest version >>>>>> >>>>>> >>>>>> >>>>>>> Some of my observations of glitches found: >>>>>>> >>>>>>> - open world menu System->About. Now instead of clicking Ok, try >>>>>>> drag >>>>>>> the window. Leads to DNU when you release a mouse button. >>>>>>> >>>>>>> - a submenu gradient in OB (maybe not only in OB) is sporadically >>>>>>> loses its colors: >>>>>>> when you first open a context menu, and first open a submenu in it, >>>>>>> all is drawn ok. But then try hover over different menu items to >>>>>>> force >>>>>>> hiding/showing submenus, you will notice that newly opened submenus >>>>>>> start losing gradient background, until finally background becomes >>>>>>> completely white. >>>>>>> >>>>>>> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>>>>>> >>>>>>>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> always available at: >>>>>>>> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>>>>>>> >>>>>>>> -- >>>>>>>> Damien Cassou >>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Nov. 11, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by Gary Chambers

I'll take a look. I assume based on Polymorph-Widgets-gvc.15.mcz on SqueakSource... There was a transitional problem with a few earlier version. Regards, Gary. ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, November 11, 2008 3:35 PM Subject: Re: [Pharo-project] New pharo-dev based on latest version > Yes. > It seems related to a Pharo fix, overrides in Polymorph packages weren't > loaded in 101, but they are in 144. > One of these overrides include SystemWindow>>createCollapseBox to make > the theme handle how it should be created, in the vistary look this > method (createCollapseBoxFor: ) calls addUpAction: of > MultistateButtonMorph with a block as argument, which somehow gets added > to a WeakActionSequence (I'm not familiar with neither squeak nor > morphic really). > This causes an MNU since the block does not respond to isValid used by > the Sequence to clean up it's items. > > I've not really dabbled much in Squeak nor Morphic, seems to me there's > three alternatives: > 1. - Bug in Polymorph (a block shouldn't be allowed as an action, sounds > weird though) > 2. - Overly zealous cleansing of methods (removal of isValid for blocks) > 3. -A messy implementation of ActionSequence requiring isValid methods > spread everywhere. > > Henry > > StÃ©phane Ducasse wrote: >> Hi henrik >> >> thanks for the report. >> Is the vistary look broken in 144? >> >> Stef >> >> On Nov 11, 2008, at 3:11 PM, Henrik Johansen wrote: >> >>> I've loaded Polymorph successfully (following the instructions at >>> http://wiki.squeak.org/squeak/6005, the basicLoad override seems to be >>> mandatory) quite a few time in the released dev images. >>> TaskbarIcons can not be loaded without a proceed, since it includes an >>> icon for PackagePaneBrowser, which is not in the pharo dev image. >>> Vistary look is also broken due to a MNU, worked in 101, but broke >>> somewhere before133 when I tried loading it next. >>> Latest I've done it with is the 142 dev image, updated to 144 before >>> loading Polymorph. >>> >>> Cheers, >>> Henry >>> >>> StÃ©phane Ducasse wrote: >>>> I hope :) >>>> we want it in the first version of pharo :) >>>> >>>> Stef >>>> >>>> On Nov 11, 2008, at 1:45 PM, Igor Stasenko wrote: >>>> >>>>> 2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>> Polymorph fixed the menu gradient oddity a long time ago... :-) >>>>>> >>>>> >>>>> btw, can it be loaded into dev image w/o problems? >>>>> I'm missing the taskbar, because when you open many browsers >>>>> overlapping each other, its hard to find needed one. >>>>> >>>>>> Regards, Gary. >>>>>> >>>>>> ----- Original Message ----- From: "Igor Stasenko" >>>>>> <siguctua(a)gmail.com> >>>>>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>>>> Sent: Monday, November 10, 2008 6:08 PM >>>>>> Subject: Re: [Pharo-project] New pharo-dev based on latest version >>>>>> >>>>>> >>>>>>> Some of my observations of glitches found: >>>>>>> >>>>>>> - open world menu System->About. Now instead of clicking Ok, try >>>>>>> drag >>>>>>> the window. Leads to DNU when you release a mouse button. >>>>>>> >>>>>>> - a submenu gradient in OB (maybe not only in OB) is sporadically >>>>>>> loses its colors: >>>>>>> when you first open a context menu, and first open a submenu in it, >>>>>>> all is drawn ok. But then try hover over different menu items to >>>>>>> force >>>>>>> hiding/showing submenus, you will notice that newly opened submenus >>>>>>> start losing gradient background, until finally background becomes >>>>>>> completely white. >>>>>>> >>>>>>> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> always available at: >>>>>>>> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>>>>>>> >>>>>>>> -- >>>>>>>> Damien Cassou >>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 11, 2008

Re: [Pharo-project] Sake Basic Documentation

by Keith Hodges

StÃ©phane Ducasse wrote: >> > > I should really use Sake to understand it further. > Now what is clear to me is that I like the idea. We need something to > write build script. > > Now for the classTasks, I'm a bit worried that we can do this kind of > actions > becuse it means that depending on the task used to create a given > distribution > we can have a side effect method removed, added, class added .... > I dont understand your objection... action blocks can contain any code. Class tasks are simply short hand for (Smalltalk at: #Cup ifAbsent: [ nil ]) ifNotNil: [ :c | c ... do something ] and all that jazz. Having a task requiring a class to exist, is no different to having a task requiring a file or directory to exist in a non image based environment. regards Keith

Nov. 11, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by Henrik Johansen

Yes. It seems related to a Pharo fix, overrides in Polymorph packages weren't loaded in 101, but they are in 144. One of these overrides include SystemWindow>>createCollapseBox to make the theme handle how it should be created, in the vistary look this method (createCollapseBoxFor: ) calls addUpAction: of MultistateButtonMorph with a block as argument, which somehow gets added to a WeakActionSequence (I'm not familiar with neither squeak nor morphic really). This causes an MNU since the block does not respond to isValid used by the Sequence to clean up it's items. I've not really dabbled much in Squeak nor Morphic, seems to me there's three alternatives: 1. - Bug in Polymorph (a block shouldn't be allowed as an action, sounds weird though) 2. - Overly zealous cleansing of methods (removal of isValid for blocks) 3. -A messy implementation of ActionSequence requiring isValid methods spread everywhere. Henry StÃ©phane Ducasse wrote: > Hi henrik > > thanks for the report. > Is the vistary look broken in 144? > > Stef > > On Nov 11, 2008, at 3:11 PM, Henrik Johansen wrote: > >> I've loaded Polymorph successfully (following the instructions at >> http://wiki.squeak.org/squeak/6005, the basicLoad override seems to be >> mandatory) quite a few time in the released dev images. >> TaskbarIcons can not be loaded without a proceed, since it includes an >> icon for PackagePaneBrowser, which is not in the pharo dev image. >> Vistary look is also broken due to a MNU, worked in 101, but broke >> somewhere before133 when I tried loading it next. >> Latest I've done it with is the 142 dev image, updated to 144 before >> loading Polymorph. >> >> Cheers, >> Henry >> >> StÃ©phane Ducasse wrote: >>> I hope :) >>> we want it in the first version of pharo :) >>> >>> Stef >>> >>> On Nov 11, 2008, at 1:45 PM, Igor Stasenko wrote: >>> >>>> 2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>> Polymorph fixed the menu gradient oddity a long time ago... :-) >>>>> >>>> >>>> btw, can it be loaded into dev image w/o problems? >>>> I'm missing the taskbar, because when you open many browsers >>>> overlapping each other, its hard to find needed one. >>>> >>>>> Regards, Gary. >>>>> >>>>> ----- Original Message ----- From: "Igor Stasenko" >>>>> <siguctua(a)gmail.com> >>>>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Monday, November 10, 2008 6:08 PM >>>>> Subject: Re: [Pharo-project] New pharo-dev based on latest version >>>>> >>>>> >>>>>> Some of my observations of glitches found: >>>>>> >>>>>> - open world menu System->About. Now instead of clicking Ok, try >>>>>> drag >>>>>> the window. Leads to DNU when you release a mouse button. >>>>>> >>>>>> - a submenu gradient in OB (maybe not only in OB) is sporadically >>>>>> loses its colors: >>>>>> when you first open a context menu, and first open a submenu in it, >>>>>> all is drawn ok. But then try hover over different menu items to >>>>>> force >>>>>> hiding/showing submenus, you will notice that newly opened submenus >>>>>> start losing gradient background, until finally background becomes >>>>>> completely white. >>>>>> >>>>>> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>>>>>> >>>>>>> >>>>>>> >>>>>>> always available at: >>>>>>> http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>>>>>> >>>>>>> -- >>>>>>> Damien Cassou >>>>>>> http://damiencassou.seasidehosting.st >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Nov. 11, 2008

Re: [Pharo-project] Sake Basic Documentation

by StÃ©phane Ducasse

> I should really use Sake to understand it further. Now what is clear to me is that I like the idea. We need something to write build script. Now for the classTasks, I'm a bit worried that we can do this kind of actions becuse it means that depending on the task used to create a given distribution we can have a side effect method removed, added, class added .... > Class Tasks > =========== > > In the following examples #Cup is used where the class Cup, is not > guaranteed to exist. > > task dependsOn:{ (SakeTask class: #Cup) exists } > > > "create a needed class" > task dependsOn:{ (SakeTask class: Object) subclass: #Cup } > > "create a needed class" > task dependsOn:{ (SakeTask class: Object) > subclass: #Cup category:'Demo'} > > task dependsOn:{ (SakeTask class: #Cup) > removeSelector: #tmp } > > task dependsOn:{ (SakeTask class: #Cup) > removeSelectorsMatching: '*' } > task dependsOn:{ (SakeTask class: #Cup) > removeSelectorsMatching: '*' } > > task dependsOn:{ (SakeTask class: #Cup) ifExistsDo: [ :c | c rename: > #Glass ] } > > MetaData > ======== > > Each Sake task contains a dictionary, SakeInfo that can be used simply > to store any arbitrary metadata. > > task info someField: someValue. > > Sake-Packages uses metadata extensively, in this case the typical use > pattern is begin with a subclass of SakeTask and to define the generic > task on the class side and the metadata on the instance side. > > SakeTask subclass: MakeADrink. > > MakeADrink classSide >> #taskPourADrink: aDrink > > self define: [ :task | > task perform: aDrink. > > task if: [ Bar containsBottle: task info name ]. > > task action: [ Glass add: (task info name). ]. > ]. > > Documentation Methods > ===================== > > Subclasses of SakeTask, utilise a specialised compiler, which allows > raw > text to be stored in instance side methods following six quotes. > """""" > > aTaskClass at: selector category: cat putMethod: code doc: content > > aTaskClass docAt: selector. > > This is used by the Mantis package to pull raw data from mantis, so > that > subsequent tasks can process that data. > > > SakeSignal and trace: > ===================== > > If a task needs to communicate with the outside context, it can > sends a > SakeSignal, a utility method is provided for this. > > task lookup: #aSelector. > > The outside context can return a value, by defining an exception > handler > for SakeSignal. > > The default implementation of #trace: is used in Sake-Tests for a task > to signal to the outside testing context what it is doing. Tasks send > #trace: and the SakeTaskTest runCaseWith: block, defines an exception > handler to collect the signalled values so as to record the actions of > the tasks. For the tests to pass all of the required actions must have > been signalled. > > > SakeStep and SakeStop > ===================== > > task step: 'Are you Sure'. > > Signals a notifier to request confirmation. > > task stop: 'It Broke'. > > Finishes processing. > > Task Extensions > =============== > > In the same manner as magritte. A class side task definition may be > extended by another package. > > #taskDoThis, may be extended by adding the extension method, > > #taskDoThisAndAlso: task. > task addDependency: [ ... ]. > task addAction: [...]. > > Answering Notifications > ======================= > > Tasks are wrapped in notification handlers, to use them: > > task answer: '*password*' with: 'secret'. > > > ================================ > > > > > > > > > > > > > > > > > > Sake. > > Below is a SakeTask as generated from the universes package > definition. > What follows is a "method", in the class PackagesSqueak310U. > > So here is a Sake Task Definition for Seaside.... (info is simply a > dictionary for non-essential meta information) > > ---------- > > PackagesSqueak310U -i- Seaside > > self name: 'Seaside'. > info category: 'Web Development'. > info description: > 'A framework for building sophisticated web applications in Squeak. > Develop for the web using reusable, embeddable components and unique > call/return semantics for moving between pages.'. > info maintainer: 'Lukas Renggli <renggli(a)gmail.com>'. > info homepage: 'http://www.seaside.st/'. > info squeakMapID: ''. > info url: 'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz' > . > info version: '2.8.522'. > info provides: #(). > > self dependsOn: #('KomHttpServer'). > > self load: [ > Installer > installUrl:'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz' > . > ]. > > self unloadDependsOn: { self taskUnloadDependants }. > self unload: [ > Installer unload: 'Seaside'. > ]. > > ------------- > > Notice that we have an unload block as well as a load block! This is a > new and very experimental feature, we can now define unload scripts > for > each package, and Sake/Packages provides a way to capture and publish > them for some or all image versions. Indeed this feature is barely > tested, I mention it here simply to intoduce the concept. > > usage: > > PackagesSqueak310 new Seaside load. or, (PackagesSqueak310 > named:'Seaside') load. > PackagesSqueak310 new Seaside unload. or, (PackagesSqueak310 > named:'Seaside') unload. > > Packages/Sake is also supported by Installer in a manner similar to > universes support, e.g. > > Installer sake addPackage: 'PackagesA'; addPackage: 'PackageB'; > install. > > enjoy... > > best regards > > Keith > > p.s. to load > > Installer install: 'Packages'. > > ========== > > Addendum: Sake/Packages no longer uses blocks as standard, but the > principle is the same. > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 11, 2008

[Pharo-project] Sake Basic Documentation

by Keith Hodges

Introduction ============ Sake-Core -- is an attempt to provide similar functionality to Make and Rake, only using Smalltalk as the DSL. Sake-Packages -- is a reimplementation of Universes functionality, using Sake. It allows the metadata, load script, and unload script for a package to be defined as a Task. Sake-Scheduler -- provides the ability to register tasks to be performed periodically. Sake-Bob -- is a tool for building and testing images. (wip) Basics ====== Tasks are typically defined class side, but can be added to any class in the image. A typical task definition follows. MakeTheTea classSide >> #taskMakeTea SakeTask define: [ :task | task dependsOn: { MakeTheTea taskBoilWater. }. task if: [ Cup isEmpty ]. task action: [ Cup add: 'tea'; add: 'water'. ]. ]. To run the task: MakeTheTea taskMakeTea run. Alternatively #runStepping, or #runLogging are available for debugging. The main structure of a sake task is defined by #dependsOn: (or #addDependency:) , #if: , #action: (or #addAction:). These can all take either blocks, or lists of tasks, or lists of blocks. To see the heirarchy of tasks that will be traversed. MakeTheTea taskMakeTea what explore. Run Order ========= There are two algorithms available for determining task run order. (Further algorithms could be defined in order to support parallelism in processing.) Given a single top level task, standard Rake ordering, simply runs all the dependancies first, for every task. However Sake-Bob, when given a list of things to do, has to analyse the dependencies to determine which needs to go first. (Universes does this) Parameters ========== Unlike Rake, tasks can be defined in terms of parameters. The typical unparametized tasks found in Rake, #taskCreateMyStartingDirectory, can be written more generically as: #taskCreateStartingDirectory: name. e.g. task dependsOn: { self taskCreateStartingDirectory: 'wip' }. Class Tasks =========== In the following examples #Cup is used where the class Cup, is not guaranteed to exist. task dependsOn:{ (SakeTask class: #Cup) exists } "create a needed class" task dependsOn:{ (SakeTask class: Object) subclass: #Cup } "create a needed class" task dependsOn:{ (SakeTask class: Object) subclass: #Cup category:'Demo'} task dependsOn:{ (SakeTask class: #Cup) removeSelector: #tmp } task dependsOn:{ (SakeTask class: #Cup) removeSelectorsMatching: '*' } task dependsOn:{ (SakeTask class: #Cup) removeSelectorsMatching: '*' } task dependsOn:{ (SakeTask class: #Cup) ifExistsDo: [ :c | c rename: #Glass ] } MetaData ======== Each Sake task contains a dictionary, SakeInfo that can be used simply to store any arbitrary metadata. task info someField: someValue. Sake-Packages uses metadata extensively, in this case the typical use pattern is begin with a subclass of SakeTask and to define the generic task on the class side and the metadata on the instance side. SakeTask subclass: MakeADrink. MakeADrink classSide >> #taskPourADrink: aDrink self define: [ :task | task perform: aDrink. task if: [ Bar containsBottle: task info name ]. task action: [ Glass add: (task info name). ]. ]. Documentation Methods ===================== Subclasses of SakeTask, utilise a specialised compiler, which allows raw text to be stored in instance side methods following six quotes. """""" aTaskClass at: selector category: cat putMethod: code doc: content aTaskClass docAt: selector. This is used by the Mantis package to pull raw data from mantis, so that subsequent tasks can process that data. SakeSignal and trace: ===================== If a task needs to communicate with the outside context, it can sends a SakeSignal, a utility method is provided for this. task lookup: #aSelector. The outside context can return a value, by defining an exception handler for SakeSignal. The default implementation of #trace: is used in Sake-Tests for a task to signal to the outside testing context what it is doing. Tasks send #trace: and the SakeTaskTest runCaseWith: block, defines an exception handler to collect the signalled values so as to record the actions of the tasks. For the tests to pass all of the required actions must have been signalled. SakeStep and SakeStop ===================== task step: 'Are you Sure'. Signals a notifier to request confirmation. task stop: 'It Broke'. Finishes processing. Task Extensions =============== In the same manner as magritte. A class side task definition may be extended by another package. #taskDoThis, may be extended by adding the extension method, #taskDoThisAndAlso: task. task addDependency: [ ... ]. task addAction: [...]. Answering Notifications ======================= Tasks are wrapped in notification handlers, to use them: task answer: '*password*' with: 'secret'. ================================ Sake. Below is a SakeTask as generated from the universes package definition. What follows is a "method", in the class PackagesSqueak310U. So here is a Sake Task Definition for Seaside.... (info is simply a dictionary for non-essential meta information) ---------- PackagesSqueak310U -i- Seaside self name: 'Seaside'. info category: 'Web Development'. info description: 'A framework for building sophisticated web applications in Squeak. Develop for the web using reusable, embeddable components and unique call/return semantics for moving between pages.'. info maintainer: 'Lukas Renggli <renggli(a)gmail.com>'. info homepage: 'http://www.seaside.st/'. info squeakMapID: ''. info url: 'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'. info version: '2.8.522'. info provides: #(). self dependsOn: #('KomHttpServer'). self load: [ Installer installUrl:'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'. ]. self unloadDependsOn: { self taskUnloadDependants }. self unload: [ Installer unload: 'Seaside'. ]. ------------- Notice that we have an unload block as well as a load block! This is a new and very experimental feature, we can now define unload scripts for each package, and Sake/Packages provides a way to capture and publish them for some or all image versions. Indeed this feature is barely tested, I mention it here simply to intoduce the concept. usage: PackagesSqueak310 new Seaside load. or, (PackagesSqueak310 named:'Seaside') load. PackagesSqueak310 new Seaside unload. or, (PackagesSqueak310 named:'Seaside') unload. Packages/Sake is also supported by Installer in a manner similar to universes support, e.g. Installer sake addPackage: 'PackagesA'; addPackage: 'PackageB'; install. enjoy... best regards Keith p.s. to load Installer install: 'Packages'. ========== Addendum: Sake/Packages no longer uses blocks as standard, but the principle is the same.

Nov. 11, 2008

Re: [Pharo-project] Installer Bug ?

by jannik.laval.gmail

I have another bug, with Installer monticello. When I do : "Installer mc open" The method open does not understand message "morphicOpen:" Does Anyone know what is the substitute method ? Jannik Le 11 nov. 08 Ã 15:25, StÃ©phane Ducasse a Ã©crit : > I will let keith reply. > Now explore really violates encapsulation, so most of the time users > wont use it or need it. > > Stef > > On Nov 11, 2008, at 3:21 PM, jannik.laval.gmail wrote: > >> Hi all, >> >> I'm testing Installer, and I have a problem. >> When I do this : >> (Installer sm package: 'Labby & Walker'; versions) explore. >> I have a list of 3 elements (there are three versions), it is ok. >> But these elements are InstallerSqueakMap which contain a list of >> packages with the first is the name 'Labby & Walker' and the others >> elements are the three versions. >> >> I think it is strange to have this structure. >> >> I think a good result would be : >> - just one InstallerSqueakMap with the three versions inside (in >> the variable 'packages') >> - or an orderedCollection with each version. >> >> Anybody could test and help me? maybe we could correct this? >> >> Thanks >> >> Jannik >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 11, 2008

Re: [Pharo-project] Installer Bug ?

by StÃ©phane Ducasse

I will let keith reply. Now explore really violates encapsulation, so most of the time users wont use it or need it. Stef On Nov 11, 2008, at 3:21 PM, jannik.laval.gmail wrote: > Hi all, > > I'm testing Installer, and I have a problem. > When I do this : > (Installer sm package: 'Labby & Walker'; versions) explore. > I have a list of 3 elements (there are three versions), it is ok. > But these elements are InstallerSqueakMap which contain a list of > packages with the first is the name 'Labby & Walker' and the others > elements are the three versions. > > I think it is strange to have this structure. > > I think a good result would be : > - just one InstallerSqueakMap with the three versions inside (in > the variable 'packages') > - or an orderedCollection with each version. > > Anybody could test and help me? maybe we could correct this? > > Thanks > > Jannik > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 11, 2008