October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Mariano Martinez Peck

On Fri, Oct 14, 2016 at 1:26 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I serialized an object graph with lots of Chinese characters in Pharo 4.0. > I > have been able to rematerialize it back into Pharo 4.0. However, when I try > to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive > #value: in Character class failed" from `Character class>>#value: > 1310876005`. The only difference immediately apparent is the VM (both via > Launcher; details below). > > More generally, I'm interested in debugging techniques for Fuel. How would > I > drill down and isolate the problem? > > There is some info here: http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging?_… > Thanks! > > 5.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > > VS. > > 4.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/Resources/vm/40/ > Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM- > Bug-for-Chinese-Characters-tp4918883.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Oct. 15, 2016

Re: [Pharo-dev] [squeak-dev] Re: large images

by David T. Lewis

Hi, Let's measure where the time is going before we fix it. I have saved V3 images of that size and more, and it takes a very long time to write the image file independent of any GC or finalization actions that need to happen. We should measure this on a large Spur image save, but I suspect that the dominant factor will turn out to be the time that it takes to flush all those gigabytes out to storage. Garbage collection and finalization actions might be just round-off error. Dave On Fri, Oct 14, 2016 at 08:29:13AM -0700, Eliot Miranda wrote: > Hi Both, > > let me try again :-/ > > > On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Nice! > > > > I put Eliot in CC :). > > > > @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). > > > > Doru > > > > > >> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: > >> > >> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. > > Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. > > I guess the scan could be folded into the gc. This is a long time to wait! > > The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. > > Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. > > Both squeak and pharo communities could do well to discuss this and agree on an approach. > > > >> > >> > >> John Brant > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Every thing has its own flow." > > > > > > > > > >

Oct. 14, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Martin Dias

Hi Sean, You can debug the answer of #serialize:, which has information. If you suspect of certain objects you could configure the serializer before serialization with #when:substituteBy: to filter them or something like that. Martin On Fri, Oct 14, 2016 at 1:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Sean, > > > > On Fri, Oct 14, 2016 at 9:26 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> I serialized an object graph with lots of Chinese characters in Pharo >> 4.0. I >> have been able to rematerialize it back into Pharo 4.0. However, when I >> try >> to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive >> #value: in Character class failed" from `Character class>>#value: >> 1310876005`. The only difference immediately apparent is the VM (both via >> Launcher; details below). >> > > Spur allows 30-bit unsigned character codes, so the max character code is > 1073741823, or 16r3FFFFFFF. So your character value is out of range. > Character class>>#value: reds better commentary. The limit cannot be > raised; there are only 30 bits available for immediate character values. > Is that character code legal unicode? > > More generally, I'm interested in debugging techniques for Fuel. How would >> I >> drill down and isolate the problem? >> >> Thanks! >> >> 5.0 VM: >> Virtual Machine >> --------------- >> /Applications/Pharo.app/Contents/MacOS/Pharo >> CoInterpreter VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> https://github.com/pharo-project/pharo-vm.git Commit: >> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >> >> Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< >> VMMaker versionString https://github.com/pharo-project/pharo-vm.git >> Commit: >> b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 >> CoInterpreter VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: >> d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 >> >> VS. >> >> 4.0 VM: >> Virtual Machine >> --------------- >> /Applications/Pharo.app/Contents/Resources/vm/40/Pharo.app/ >> Contents/MacOS/Pharo >> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> https://github.com/pharo-project/pharo-vm.git Commit: >> 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 >> >> Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< >> VMMaker versionString https://github.com/pharo-project/pharo-vm.git >> Commit: >> 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 >> By: >> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 >> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: >> 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spur-VM- >> Bug-for-Chinese-Characters-tp4918883.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Oct. 14, 2016

Re: [Pharo-dev] Spur VM Bug for Chinese Characters?

by Eliot Miranda

Hi Sean, On Fri, Oct 14, 2016 at 9:26 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I serialized an object graph with lots of Chinese characters in Pharo 4.0. > I > have been able to rematerialize it back into Pharo 4.0. However, when I try > to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive > #value: in Character class failed" from `Character class>>#value: > 1310876005`. The only difference immediately apparent is the VM (both via > Launcher; details below). > Spur allows 30-bit unsigned character codes, so the max character code is 1073741823, or 16r3FFFFFFF. So your character value is out of range. Character class>>#value: reds better commentary. The limit cannot be raised; there are only 30 bits available for immediate character values. Is that character code legal unicode? More generally, I'm interested in debugging techniques for Fuel. How would I > drill down and isolate the problem? > > Thanks! > > 5.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > > VS. > > 4.0 VM: > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/Resources/vm/40/ > Pharo.app/Contents/MacOS/Pharo > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > https://github.com/pharo-project/pharo-vm.git Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git > Commit: > 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 > By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: > 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Spur-VM- > Bug-for-Chinese-Characters-tp4918883.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- _,,,^..^,,,_ best, Eliot

Oct. 14, 2016

Spur VM Bug for Chinese Characters?

by Sean P. DeNigris

I serialized an object graph with lots of Chinese characters in Pharo 4.0. I have been able to rematerialize it back into Pharo 4.0. However, when I try to materialize into a Pharo 5.0 image, I get "PrimitiveFailed: primitive #value: in Character class failed" from `Character class>>#value: 1310876005`. The only difference immediately apparent is the VM (both via Launcher; details below). More generally, I'm interested in debugging techniques for Fuel. How would I drill down and isolate the problem? Thanks! 5.0 VM: Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 VS. 4.0 VM: Virtual Machine --------------- /Applications/Pharo.app/Contents/Resources/vm/40/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 32d18ba0f2db9bee7f3bdbf16bdb24fe4801cfc5 Date: 2015-03-24 11:08:14 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spur-VM-Bug-for-Chinese-Characters-tp4918883.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 14, 2016

Re: [Pharo-dev] large images

by Eliot Miranda

Hi Both, let me try again :-/ > On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Nice! > > I put Eliot in CC :). > > @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). > > Doru > > >> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: >> >> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. I guess the scan could be folded into the gc. This is a long time to wait! The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. Both squeak and pharo communities could do well to discuss this and agree on an approach. >> >> >> John Brant > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Esteban Lorenzano

> On 14 Oct 2016, at 16:26, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the image. I call them ânormalisation methodsâ: they are meant to translate names into something we can interpretâ¦ there is also some like that in the menu building if I remember well :P > > And here idea to slowly remove ~Icon or ~Form suffix from icons names? yes :)

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yes, that was me providing a compatibility/traduction layer :) > you will find a couple more of them in the image. I call them > ânormalisation methodsâ: they are meant to translate names into something > we can interpretâ¦ there is also some like that in the menu building if I > remember well :P > And here idea to slowly remove ~Icon or ~Form suffix from icons names?

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Esteban Lorenzano

yes, that was me providing a compatibility/traduction layer :) you will find a couple more of them in the image. I call them ânormalisation methodsâ: they are meant to translate names into something we can interpretâ¦ there is also some like that in the menu building if I remember well :P Esteban > On 14 Oct 2016, at 15:34, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Oh!!! I just found this method: > > iconNamed: aSymbol ifNone: aBlock > > self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. > "Trying the old way" > > ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ > self icons > at: (aSymbol allButLast: 4) asSymbol > ifPresent: [ :icon | ^ icon ] > ]. > > ^ aBlock value > > > > 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > Denis > You can have a look the changes I did. There is more work to be done but I started. > https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 <https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4> > Done. New slice committed >

Oct. 14, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

Oh!!! I just found this method: iconNamed: aSymbol ifNone: aBlock self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. "Trying the old way" ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ self icons at: (aSymbol allButLast: 4) asSymbol ifPresent: [ :icon | ^ icon ] ]. ^ aBlock value 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-10-13 20:27 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Denis >> >> You can have a look the changes I did. There is more work to be done but >> I started. >> >> https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 >> > > Done. New slice committed >

Oct. 14, 2016