Morph extension

>
> Whilst on the subject I am wondering on everyone's opinion on  
> merging the behaviour of color/borderColor/borderWidth with that of  
> fillStyle... sure to be some gains there!
>
> Regards, Gary
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>
>> After some experimenting I can get over 10% perfromance improvement
>> with
>> window operations when fillStyle; borderStyle; hResizing; vResizing
>> are
>> made as instance variables of Morph, rather than going through
>> extension.
>
> this is a lot.
> You really mean Morph or we could get them in subclasses too.
>
>>  I thought Marcus has mentioned this some time ago, but no progress?
>
> No progress just playing with it at esug last year.
>
>>  There is obviously an issue with name collision/shadowing but not
>> many methods in core need changing to accomodate.
>
>
>
>
>>
>> Whilst on the subject I am wondering on everyone's opinion on
>> merging the behaviour of color/borderColor/borderWidth with that of
>> fillStyle... sure to be some gains there!
>>
>> Regards, Gary
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>
>  
>> After some experimenting I can get over 10% perfromance improvement  
>> with
>> window operations when fillStyle; borderStyle; hResizing; vResizing  
>> are
>> made as instance variables of Morph, rather than going through  
>> extension.
>>    
>
> this is a lot.
> You really mean Morph or we could get them in subclasses too.
>
>  

> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>
>
>> After some experimenting I can get over 10% perfromance improvement
>> with
>> window operations when fillStyle; borderStyle; hResizing; vResizing
>> are
>> made as instance variables of Morph, rather than going through
>> extension.
>>
>
> this is a lot.
> You really mean Morph or we could get them in subclasses too.
>
>

> I get a different "top offenders" list of course.
> I've managed to refactor the worst offenders.
>
> Benchmarks for the "opening system browser" below show an improvement.
>
> Going from patched to unpatched shows that the unpatched takes  
> between 15%
> and 20% longer to complete depending on fonts/theme.
>
> (Benchmark code)
>
> | saveMorphs time |
> [saveMorphs := World submorphs.
>  World removeAllMorphs."heh, heh"
>  time := [1 to: 10 do: [:i |
> MorphicToolBuilder new open:
>           (Browser new setClass: SystemDictionary selector: nil).
> World doOneCycleNow].
> World submorphs do: [:m | m delete. World doOneCycleNow].
>  ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
> SystemWindow noteTopWindowIn: World.
> time
>
> (end of benchmark code)
>
> I can make a changeset available for the brave who want to try.

>
>
> I've managed to refactor the worst offenders.
>
> Benchmarks for the "opening system browser" below show an improvement.
>
> Going from patched to unpatched shows that the unpatched takes  
> between 15%
> and 20% longer to complete depending on fonts/theme.
>
> (Benchmark code)
>
> | saveMorphs time |
> [saveMorphs := World submorphs.
>  World removeAllMorphs."heh, heh"
>  time := [1 to: 10 do: [:i |
> MorphicToolBuilder new open:
>           (Browser new setClass: SystemDictionary selector: nil).
> World doOneCycleNow].
> World submorphs do: [:m | m delete. World doOneCycleNow].
>  ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
> SystemWindow noteTopWindowIn: World.
> time
>
> (end of benchmark code)
>
> I can make a changeset available for the brave who want to try.
> I have developed a workspace script that (finally) appears to load it
> correctly,
> waas a lot of hung-image before getting there...
>
> (loading tested on 10451-BETA)
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Henrik Johansen" <[hidden email]>
> To: <[hidden email]>
> Sent: Tuesday, September 08, 2009 7:01 PM
> Subject: Re: [Pharo-project] Morph extension
>
>
>
>
> Stéphane Ducasse skrev:
>> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>>
>>
>>> After some experimenting I can get over 10% perfromance improvement
>>> with
>>> window operations when fillStyle; borderStyle; hResizing; vResizing
>>> are
>>> made as instance variables of Morph, rather than going through
>>> extension.
>>>
>>
>> this is a lot.
>> You really mean Morph or we could get them in subclasses too.
>>
>>
> Inspect this in an image with some windows open, it will give you the
> percentage of morphs with otherProperties containing any given  
> property:
>
> |propBag noMorphs|
> propBag := Bag new: 50.
> noMorphs := 0.
> Morph allSubInstances do: [:each | each otherProperties ifNotNil:
> [:props | propBag addAll: props keys.
>        noMorphs := noMorphs +1]]  .
> noMorphs := noMorphs asFloat.
> propBag sortedCounts collect: [:each | each key: each key / noMorphs;
> yourself]
>
>
> otherProperties is heavily abused. with respectively 98 and 125  
> senders
> of valueOfProperty: / valueOfProperty:ifAbsent:...
> In my case there were _57_ different distinct otherProperties in  
> use, an
> average of three, a maximum of 15, and four of them present in over a
> quarter of morphs defining any (80% for the most common one)...
> If moving directly to Morph is a bit extreme, at least _some_ of these
> qualify for promotion to direct access in MorphExtension imho, it  
> seems
> to have some "free" instvars anyways after the removal of players.
>
> In the interest of seeing which would benefit the most from moving, I
> did a small profile:
> - Dragging a window and switching some between different ones with 2
> browsers, a monticello browser, a workspace and a Method search open.
> I had the following access numbers:
> 105586->#clipSubmorphs (about 4.5 per millisecond)
> 66029->#layoutProperties
> 62783->#layoutPolicy
> 55556->#theme
> 41312->#hasDropShadow
> 41310->#hasRolloverBorder
> 36817->#fillStyle
> 19241->#cornerStyle
> 13239->#highlightedForDrop
> 13239->#highlightedForMouseDown
> 11945->#roundedCorners
> 11911->#borderStyle
> 10644->#edgeToAdhereTo
> 9020->#paneColor
> 8885->#lastPaneColor
> [rest below 5000 accesses]
>
> Cheers,
> Henry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Gary I would love to see morphic goes faster so we are ready to try :)
>
> Stef
>
>  
>> I've managed to refactor the worst offenders.
>>
>> Benchmarks for the "opening system browser" below show an improvement.
>>
>> Going from patched to unpatched shows that the unpatched takes  
>> between 15%
>> and 20% longer to complete depending on fonts/theme.
>>
>> (Benchmark code)
>>
>> | saveMorphs time |
>> [saveMorphs := World submorphs.
>>  World removeAllMorphs."heh, heh"
>>  time := [1 to: 10 do: [:i |
>> MorphicToolBuilder new open:
>>           (Browser new setClass: SystemDictionary selector: nil).
>> World doOneCycleNow].
>> World submorphs do: [:m | m delete. World doOneCycleNow].
>>  ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
>> SystemWindow noteTopWindowIn: World.
>> time
>>
>> (end of benchmark code)
>>
>> I can make a changeset available for the brave who want to try.
>> I have developed a workspace script that (finally) appears to load it
>> correctly,
>> waas a lot of hung-image before getting there...
>>
>> (loading tested on 10451-BETA)
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Henrik Johansen" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Tuesday, September 08, 2009 7:01 PM
>> Subject: Re: [Pharo-project] Morph extension
>>
>>
>>
>>
>> Stéphane Ducasse skrev:
>>    
>>> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>>>
>>>
>>>      
>>>> After some experimenting I can get over 10% perfromance improvement
>>>> with
>>>> window operations when fillStyle; borderStyle; hResizing; vResizing
>>>> are
>>>> made as instance variables of Morph, rather than going through
>>>> extension.
>>>>
>>>>        
>>> this is a lot.
>>> You really mean Morph or we could get them in subclasses too.
>>>
>>>
>>>      
>> Inspect this in an image with some windows open, it will give you the
>> percentage of morphs with otherProperties containing any given  
>> property:
>>
>> |propBag noMorphs|
>> propBag := Bag new: 50.
>> noMorphs := 0.
>> Morph allSubInstances do: [:each | each otherProperties ifNotNil:
>> [:props | propBag addAll: props keys.
>>        noMorphs := noMorphs +1]]  .
>> noMorphs := noMorphs asFloat.
>> propBag sortedCounts collect: [:each | each key: each key / noMorphs;
>> yourself]
>>
>>
>> otherProperties is heavily abused. with respectively 98 and 125  
>> senders
>> of valueOfProperty: / valueOfProperty:ifAbsent:...
>> In my case there were _57_ different distinct otherProperties in  
>> use, an
>> average of three, a maximum of 15, and four of them present in over a
>> quarter of morphs defining any (80% for the most common one)...
>> If moving directly to Morph is a bit extreme, at least _some_ of these
>> qualify for promotion to direct access in MorphExtension imho, it  
>> seems
>> to have some "free" instvars anyways after the removal of players.
>>
>> In the interest of seeing which would benefit the most from moving, I
>> did a small profile:
>> - Dragging a window and switching some between different ones with 2
>> browsers, a monticello browser, a workspace and a Method search open.
>> I had the following access numbers:
>> 105586->#clipSubmorphs (about 4.5 per millisecond)
>> 66029->#layoutProperties
>> 62783->#layoutPolicy
>> 55556->#theme
>> 41312->#hasDropShadow
>> 41310->#hasRolloverBorder
>> 36817->#fillStyle
>> 19241->#cornerStyle
>> 13239->#highlightedForDrop
>> 13239->#highlightedForMouseDown
>> 11945->#roundedCorners
>> 11911->#borderStyle
>> 10644->#edgeToAdhereTo
>> 9020->#paneColor
>> 8885->#lastPaneColor
>> [rest below 5000 accesses]
>>
>> Cheers,
>> Henry
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>    
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> .
>
>  

>
> On 16.09.2009, at 10:29, Gary Chambers wrote:
>
>> I get a different "top offenders" list of course.
>> I've managed to refactor the worst offenders.
>>
>> Benchmarks for the "opening system browser" below show an  
>> improvement.
>>
>> Going from patched to unpatched shows that the unpatched takes
>> between 15%
>> and 20% longer to complete depending on fonts/theme.
>>
>> (Benchmark code)
>>
>> | saveMorphs time |
>> [saveMorphs := World submorphs.
>> World removeAllMorphs."heh, heh"
>> time := [1 to: 10 do: [:i |
>> MorphicToolBuilder new open:
>>          (Browser new setClass: SystemDictionary selector: nil).
>> World doOneCycleNow].
>> World submorphs do: [:m | m delete. World doOneCycleNow].
>> ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
>> SystemWindow noteTopWindowIn: World.
>> time
>>
>> (end of benchmark code)
>>
>> I can make a changeset available for the brave who want to try.
>
> Yes, I would like to try!
>
> Marcus
>
>
>
>
> --
> Marcus Denker - http://marcusdenker.de
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Me too!
> Both actorState and player in MorphExtension  are now unused btw, if
> you decided to put them there you might as well remove those two at
> the same time  :)
>
> Cheers,
> Henry
>
> On Sep 16, 2009, at 4:43 43PM, Marcus Denker wrote:
>
>>
>> On 16.09.2009, at 10:29, Gary Chambers wrote:
>>
>>> I get a different "top offenders" list of course.
>>> I've managed to refactor the worst offenders.
>>>
>>> Benchmarks for the "opening system browser" below show an
>>> improvement.
>>>
>>> Going from patched to unpatched shows that the unpatched takes
>>> between 15%
>>> and 20% longer to complete depending on fonts/theme.
>>>
>>> (Benchmark code)
>>>
>>> | saveMorphs time |
>>> [saveMorphs := World submorphs.
>>> World removeAllMorphs."heh, heh"
>>> time := [1 to: 10 do: [:i |
>>> MorphicToolBuilder new open:
>>>          (Browser new setClass: SystemDictionary selector: nil).
>>> World doOneCycleNow].
>>> World submorphs do: [:m | m delete. World doOneCycleNow].
>>> ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
>>> SystemWindow noteTopWindowIn: World.
>>> time
>>>
>>> (end of benchmark code)
>>>
>>> I can make a changeset available for the brave who want to try.
>>
>> Yes, I would like to try!
>>
>> Marcus
>>
>>
>>
>>
>> --
>> Marcus Denker - http://marcusdenker.de
>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Gary I would love to see morphic goes faster so we are ready to try :)
>
> Stef
>
>
>> I've managed to refactor the worst offenders.
>>
>> Benchmarks for the "opening system browser" below show an improvement.
>>
>> Going from patched to unpatched shows that the unpatched takes
>> between 15%
>> and 20% longer to complete depending on fonts/theme.
>>
>> (Benchmark code)
>>
>> | saveMorphs time |
>> [saveMorphs := World submorphs.
>>  World removeAllMorphs."heh, heh"
>>  time := [1 to: 10 do: [:i |
>> MorphicToolBuilder new open:
>>           (Browser new setClass: SystemDictionary selector: nil).
>> World doOneCycleNow].
>> World submorphs do: [:m | m delete. World doOneCycleNow].
>>  ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
>> SystemWindow noteTopWindowIn: World.
>> time
>>
>> (end of benchmark code)
>>
>> I can make a changeset available for the brave who want to try.
>> I have developed a workspace script that (finally) appears to load it
>> correctly,
>> waas a lot of hung-image before getting there...
>>
>> (loading tested on 10451-BETA)
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Henrik Johansen" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Tuesday, September 08, 2009 7:01 PM
>> Subject: Re: [Pharo-project] Morph extension
>>
>>
>>
>>
>> Stéphane Ducasse skrev:
>>
>>> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>>>
>>>
>>>
>>>> After some experimenting I can get over 10% perfromance improvement
>>>> with
>>>> window operations when fillStyle; borderStyle; hResizing; vResizing
>>>> are
>>>> made as instance variables of Morph, rather than going through
>>>> extension.
>>>>
>>>>
>>> this is a lot.
>>> You really mean Morph or we could get them in subclasses too.
>>>
>>>
>>>
>> Inspect this in an image with some windows open, it will give you the
>> percentage of morphs with otherProperties containing any given
>> property:
>>
>> |propBag noMorphs|
>> propBag := Bag new: 50.
>> noMorphs := 0.
>> Morph allSubInstances do: [:each | each otherProperties ifNotNil:
>> [:props | propBag addAll: props keys.
>>        noMorphs := noMorphs +1]]  .
>> noMorphs := noMorphs asFloat.
>> propBag sortedCounts collect: [:each | each key: each key / noMorphs;
>> yourself]
>>
>>
>> otherProperties is heavily abused. with respectively 98 and 125
>> senders
>> of valueOfProperty: / valueOfProperty:ifAbsent:...
>> In my case there were _57_ different distinct otherProperties in
>> use, an
>> average of three, a maximum of 15, and four of them present in over a
>> quarter of morphs defining any (80% for the most common one)...
>> If moving directly to Morph is a bit extreme, at least _some_ of these
>> qualify for promotion to direct access in MorphExtension imho, it
>> seems
>> to have some "free" instvars anyways after the removal of players.
>>
>> In the interest of seeing which would benefit the most from moving, I
>> did a small profile:
>> - Dragging a window and switching some between different ones with 2
>> browsers, a monticello browser, a workspace and a Method search open.
>> I had the following access numbers:
>> 105586->#clipSubmorphs (about 4.5 per millisecond)
>> 66029->#layoutProperties
>> 62783->#layoutPolicy
>> 55556->#theme
>> 41312->#hasDropShadow
>> 41310->#hasRolloverBorder
>> 36817->#fillStyle
>> 19241->#cornerStyle
>> 13239->#highlightedForDrop
>> 13239->#highlightedForMouseDown
>> 11945->#roundedCorners
>> 11911->#borderStyle
>> 10644->#edgeToAdhereTo
>> 9020->#paneColor
>> 8885->#lastPaneColor
>> [rest below 5000 accesses]
>>
>> Cheers,
>> Henry
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> .
>
>

> Have a go with it (use a fresh image rather than anything you might  
> want to lose...).
> Stick the .cs in your image directory, open a workspace and do the  
> following...
>
> (FileStream readOnlyFileNamed: 'MorphicExtensionPerformance.1.cs')
> fileInSilentlyAnnouncing: nil.
> Morph allSubInstances do: [:m |
> #(fillStyle layoutPolicy layoutFrame layoutProperties borderStyle  
> cornerStyle actionMap clipSubmorphs) do: [:prop |
> m extension ifNotNilDo: [:extension |
> extension otherProperties ifNotNilDo: [:otherProperties |
>  extension instVarNamed: prop put: (
>   otherProperties at: prop ifAbsent: []).
>  otherProperties removeKey: #prop ifAbsent: []]]]]
>
> Regards, Gary
>
> ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]
> >
> To: <[hidden email]>
> Sent: Wednesday, September 16, 2009 3:49 PM
> Subject: Re: [Pharo-project] Morph extension
>
>
> Gary I would love to see morphic goes faster so we are ready to try :)
>
> Stef
>
>>
>>
>> I've managed to refactor the worst offenders.
>>
>> Benchmarks for the "opening system browser" below show an  
>> improvement.
>>
>> Going from patched to unpatched shows that the unpatched takes
>> between 15%
>> and 20% longer to complete depending on fonts/theme.
>>
>> (Benchmark code)
>>
>> | saveMorphs time |
>> [saveMorphs := World submorphs.
>> World removeAllMorphs."heh, heh"
>> time := [1 to: 10 do: [:i |
>> MorphicToolBuilder new open:
>>          (Browser new setClass: SystemDictionary selector: nil).
>> World doOneCycleNow].
>> World submorphs do: [:m | m delete. World doOneCycleNow].
>> ] timeToRun] ensure:[World addAllMorphs: saveMorphs].
>> SystemWindow noteTopWindowIn: World.
>> time
>>
>> (end of benchmark code)
>>
>> I can make a changeset available for the brave who want to try.
>> I have developed a workspace script that (finally) appears to load it
>> correctly,
>> waas a lot of hung-image before getting there...
>>
>> (loading tested on 10451-BETA)
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Henrik Johansen" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Tuesday, September 08, 2009 7:01 PM
>> Subject: Re: [Pharo-project] Morph extension
>>
>>
>>
>>
>> Stéphane Ducasse skrev:
>>> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
>>>
>>>
>>>> After some experimenting I can get over 10% perfromance improvement
>>>> with
>>>> window operations when fillStyle; borderStyle; hResizing; vResizing
>>>> are
>>>> made as instance variables of Morph, rather than going through
>>>> extension.
>>>>
>>>
>>> this is a lot.
>>> You really mean Morph or we could get them in subclasses too.
>>>
>>>
>> Inspect this in an image with some windows open, it will give you the
>> percentage of morphs with otherProperties containing any given
>> property:
>>
>> |propBag noMorphs|
>> propBag := Bag new: 50.
>> noMorphs := 0.
>> Morph allSubInstances do: [:each | each otherProperties ifNotNil:
>> [:props | propBag addAll: props keys.
>>       noMorphs := noMorphs +1]]  .
>> noMorphs := noMorphs asFloat.
>> propBag sortedCounts collect: [:each | each key: each key / noMorphs;
>> yourself]
>>
>>
>> otherProperties is heavily abused. with respectively 98 and 125
>> senders
>> of valueOfProperty: / valueOfProperty:ifAbsent:...
>> In my case there were _57_ different distinct otherProperties in
>> use, an
>> average of three, a maximum of 15, and four of them present in over a
>> quarter of morphs defining any (80% for the most common one)...
>> If moving directly to Morph is a bit extreme, at least _some_ of  
>> these
>> qualify for promotion to direct access in MorphExtension imho, it
>> seems
>> to have some "free" instvars anyways after the removal of players.
>>
>> In the interest of seeing which would benefit the most from moving, I
>> did a small profile:
>> - Dragging a window and switching some between different ones with 2
>> browsers, a monticello browser, a workspace and a Method search open.
>> I had the following access numbers:
>> 105586->#clipSubmorphs (about 4.5 per millisecond)
>> 66029->#layoutProperties
>> 62783->#layoutPolicy
>> 55556->#theme
>> 41312->#hasDropShadow
>> 41310->#hasRolloverBorder
>> 36817->#fillStyle
>> 19241->#cornerStyle
>> 13239->#highlightedForDrop
>> 13239->#highlightedForMouseDown
>> 11945->#roundedCorners
>> 11911->#borderStyle
>> 10644->#edgeToAdhereTo
>> 9020->#paneColor
>> 8885->#lastPaneColor
>> [rest below 5000 accesses]
>>
>> Cheers,
>> Henry
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> <MorphicExtensionPerformance.
> 1.cs>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project