March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Mickael system submission Slice merging problem

by StÃ©phane Ducasse

I do not know since we will have to created the packages and delete the working copy but probably. Stef On Mar 23, 2009, at 11:02 AM, Adrian Lienhard wrote: > > On Mar 21, 2009, at 14:11 , Michael Rueger wrote: > >> StÃ©phane Ducasse wrote: >>> Hi mike >>> >>> could you redo you system organization changes? >> >> I will take a look. >> All the slice should do is to exchange packaging, it is not supposed >> to >> change any code at all. If there have been changes in the meantime, I >> simply need to do re-packaging again. > > It seems, such changes (like moving a class between packages) are > simpler to handle with changesets. When we create a new update we > apply the cs without the need for merging with MC. > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2009

Re: [Pharo-project] Mickael system submission Slice merging problem

by Michael Rueger

Adrian Lienhard wrote: > It seems, such changes (like moving a class between packages) are > simpler to handle with changesets. When we create a new update we > apply the cs without the need for merging with MC. Even simpler with config maps. A config map could be used as a slice as well. Michael

March 23, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by StÃ©phane Ducasse

thanks for the clarification On Mar 23, 2009, at 10:31 AM, Henrik Johansen wrote: > Short answer: Yes. > Long answer: > The implementation in BorderedMorph was fixed in Polymorph-Overrides, > then that version was promoted to Morph, then BorderedMorph reverted > to > pre-Polymorph-Overrides functionality from the removeSelector: in my > cs. > So the "correct" thing to do would be to remove all versions of the > method from BorderedMorph, as it's former (correct) version is now > used > by Morph. > > Cheers, > Henry > > StÃ©phane Ducasse wrote: >> so henrik >> is is ok if I remove areasRemainingToFill: from BorderedMorph? >> >> Stef >> >> On Mar 19, 2009, at 1:46 PM, Henrik Johansen wrote: >> >> >>> I know, which is why I thought it was strange, the .cs contained: >>> !BorderedMorph removeSelector: #areasRemainingToFill:! >>> which when I file it in, results in no areasRemainingToFill: method >>> for >>> BorderedMorph in the image. >>> >>> I really have no idea how the update process makes it revert to an >>> older >>> version instead, nor how one would go about fixing it... :/ >>> >>> Cheers, >>> Henrik >>> >>> StÃ©phane Ducasse wrote: >>> >>>> henrik I just integrated the file you gave me. >>>> If you have a new version that fixes the problem I will do a new >>>> version. >>>> >>>> Stef >>>> >>>> On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: >>>> >>>> >>>>> It seems BorderedMorph's areasRemainingToFill: method got reverted >>>>> to >>>>> the version in use prior to the override by PolyMorph (which has >>>>> now >>>>> been promoted to Morph), instead of removed completely. >>>>> (This is the state my image is in after updating a released 248, >>>>> at >>>>> least) >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> StÃ©phane Ducasse wrote: >>>>> >>>>>> Issue 655: Overlapping Graphics on World do not Properly >>>>>> Repaint >>>>>> Issue 658: Preferences resetHaloSpecifications >>>>>> Issue 664: unimplemented errorCantGoBack >>>>>> Closed 665 >>>>>> >>>>>> now we will focus on the closures. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >

March 23, 2009

Re: [Pharo-project] [ANN] Closures for beta testers

by StÃ©phane Ducasse

For the moment I do not want to do that before we have some fixes ready. Eliot should produce a new version. So what I can do is to publish two images with the test run so that people can help to check the problem. stef On Mar 23, 2009, at 9:50 AM, Damien Cassou wrote: > On Sun, Mar 22, 2009 at 10:11 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I can post the two images somewhere if this helps. > > Please provide a new image or update the stream. > > -- > 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 >

March 23, 2009

Re: [Pharo-project] Mickael system submission Slice merging problem

by Adrian Lienhard

On Mar 21, 2009, at 14:11 , Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> Hi mike >> >> could you redo you system organization changes? > > I will take a look. > All the slice should do is to exchange packaging, it is not supposed > to > change any code at all. If there have been changes in the meantime, I > simply need to do re-packaging again. It seems, such changes (like moving a class between packages) are simpler to handle with changesets. When we create a new update we apply the cs without the need for merging with MC. Adrian

March 23, 2009

[Pharo-project] Issue 686: Remove dice methods in Random

by Serge Stinckwich

http://code.google.com/p/pharo/issues/detail?id=686 -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 23, 2009

Re: [Pharo-project] HowToContribute wiki page

by Serge Stinckwich

On Mon, Mar 23, 2009 at 4:33 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > On Mon, Mar 23, 2009 at 3:37 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >> On Mar 23, 2009, at 09:26 , Serge Stinckwich wrote: >> >>> Hi, >>> i'm currently reading this page : >>> http://code.google.com/p/pharo/wiki/HowToContribute >>> and it's not really clear when someone do not need to make a >>> modification to several packages ... >>> I guess you have to publish to modified package to PharoInbox also. >> >> Yes. In this case, no SLICE package is needed. > > Ok, the page should be more clear about that ... the page is mostly > focused on the SLICE case. Ok, i reword a little bit the page. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 23, 2009

Re: [Pharo-project] Concurrent programming (was: Would you start a new Smalltalk project today?)

by Igor Stasenko

2009/3/23 Michael van der Gulik <mikevdg(a)gmail.com>: > > > On Mon, Mar 23, 2009 at 2:21 PM, Michael van der Gulik <mikevdg(a)gmail.com> > wrote: >> >> >> On Mon, Mar 23, 2009 at 12:34 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >>> >>> Now consider the overhead of creating a fork vs the actual useful code >>> which is running within a block. >>> I presume, this code will run 10x times slower on a single core >>> processor, comparing to one w/o forks. >>> So, you will need to have 10 cores to match the computation time with >>> single core processor. >>> >>> I think its not wise to introduce parallelism on such low levels (in >>> Concurrent.Collections.Array>>withIndexDo:). Its like hammering nails >>> with microscope :) >>> >>> That's why i'm saying its too good to be true. >>> Introducing parallelism at such low levels will be a waste. I leaning >>> toward island model. This is a middle point between no sharing, like >>> in Hydra and sharing everything, like in what you proposing. >> >> 10 times slower? Sounds like a made-up number to me... >> >> " Using 101 threads: " >> c := ConcurrentArray new: 1000001. >> Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i >> asString. ]]. >> 5711 >> 5626 >> 6074 >> >> " Using 11 threads: " >> c := ConcurrentArray new: 1000001. >> Time millisecondsToRun: [c withIndexDo: [ :each :i | c at: i put: i >> asString. ]]. >> 3086 >> 3406 >> 3256 >> >> " Using 1 thread: " >> d := Array new: 1000001. >> Time millisecondsToRun: [d withIndexDo: [ :each :i | d at: i put: i >> asString]]. >> 2426 >> 2610 >> 2599 >> >> My implementation is 1/2 to 1/3 the speed of the single-threaded Array. If >> the blocks did more work, then the overhead would be lower and some benefit >> would be gained from using multiple cores. >> >> I don't have a good idea of where the overhead is going - maybe it's being >> lost in the block copying that is needed to work around Squeak's >> deficiencies? Or maybe it's waiting for the scheduler to do its stuff? >> >> Implementation attached, MIT license if you're picky. > > I just tried it on VisualWorks as well. I removed the block copying and > renamed the method to "keysDo:" (I never thought of an array like that > before... keys and values). > Yeah, Array is just a less generic than Dictionary, in respect that it associating an index as a key to access the values. > d := Array new: 1000001. > Time millisecondsToRun: [d keysDo: [ :i | d at: i put: i > printString]]. > 1180 > 982 > 1008 > > " Using 101 threads " > c := ConcurrentArray new: 1000001. > Time millisecondsToRun: [c keysDo: [ :i | c at: i put: i printString. > ]]. > Â 1072 > 1120 > 962 > > At this stage, I'm suspicous about the results :-). > me too :) > Gulik. > > -- > http://gulik.pbwiki.com/ > > _______________________________________________ > 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.

March 23, 2009

Re: [Pharo-project] HowToContribute wiki page

by Serge Stinckwich

On Mon, Mar 23, 2009 at 3:37 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Mar 23, 2009, at 09:26 , Serge Stinckwich wrote: > >> Hi, >> i'm currently reading this page : >> http://code.google.com/p/pharo/wiki/HowToContribute >> and it's not really clear when someone do not need to make a >> modification to several packages ... >> I guess you have to publish to modified package to PharoInbox also. > > Yes. In this case, no SLICE package is needed. Ok, the page should be more clear about that ... the page is mostly focused on the SLICE case. > We could also mention that instead of going through PharoInbox, > creating a changeset and attaching it to the issue in the tracker is > an alternative (which sometimes is much less time consuming). Yes, i agree. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 23, 2009

Re: [Pharo-project] Fwd: [ANN] 10254

by Henrik Johansen

Short answer: Yes. Long answer: The implementation in BorderedMorph was fixed in Polymorph-Overrides, then that version was promoted to Morph, then BorderedMorph reverted to pre-Polymorph-Overrides functionality from the removeSelector: in my cs. So the "correct" thing to do would be to remove all versions of the method from BorderedMorph, as it's former (correct) version is now used by Morph. Cheers, Henry StÃ©phane Ducasse wrote: > so henrik > is is ok if I remove areasRemainingToFill: from BorderedMorph? > > Stef > > On Mar 19, 2009, at 1:46 PM, Henrik Johansen wrote: > > >> I know, which is why I thought it was strange, the .cs contained: >> !BorderedMorph removeSelector: #areasRemainingToFill:! >> which when I file it in, results in no areasRemainingToFill: method >> for >> BorderedMorph in the image. >> >> I really have no idea how the update process makes it revert to an >> older >> version instead, nor how one would go about fixing it... :/ >> >> Cheers, >> Henrik >> >> StÃ©phane Ducasse wrote: >> >>> henrik I just integrated the file you gave me. >>> If you have a new version that fixes the problem I will do a new >>> version. >>> >>> Stef >>> >>> On Mar 19, 2009, at 12:20 PM, Henrik Johansen wrote: >>> >>> >>>> It seems BorderedMorph's areasRemainingToFill: method got reverted >>>> to >>>> the version in use prior to the override by PolyMorph (which has now >>>> been promoted to Morph), instead of removed completely. >>>> (This is the state my image is in after updating a released 248, at >>>> least) >>>> >>>> Cheers, >>>> Henry >>>> >>>> StÃ©phane Ducasse wrote: >>>> >>>>> Issue 655: Overlapping Graphics on World do not Properly Repaint >>>>> Issue 658: Preferences resetHaloSpecifications >>>>> Issue 664: unimplemented errorCantGoBack >>>>> Closed 665 >>>>> >>>>> now we will focus on the closures. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > >

March 23, 2009