January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] NewCompiler load on PharoCore

by Igor Stasenko

2010/1/13 Igor Stasenko <siguctua(a)gmail.com>: > 2010/1/13 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Wed, Jan 13, 2010 at 12:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> 2010/1/13 Martin McClure <martin(a)hand2mouse.com>: >>> > Eliot Miranda wrote: >>> >> A *much* better way to implement this is to support immutability in the >>> >> VM (I know, I know, but all the code is available in the Newspeak VM), >>> >> mark objects one wants to mark as dirty as immutable, catch the >>> >> NoModificationError exception, and proceed after having made the object >>> >> mutable and marked it dirty. Â No creating hidden classes, no trying to >>> >> get change class to work for compact classes, etc. Â Just a simple >>> >> VM-implemented write barrier that can also be used for a host of other >>> >> things (object-database mapping, debugging, immutable literals etc). >>> > >>> > Since object dirtying is at the core of the product I work with, and >>> > I've worked extensively with both methods of implementing write >>> > barriers... >>> > >>> > I very strongly agree with Eliot. *So* much nicer a way to do this. >>> > >>> >>> It could be more efficient, in respect that you don't need to create >>> shadow classes. >>> But triggering exception leads to stack unwinding to find a handler, >>> which inevitably leads to deoptimizing all contexts.. >> >> Uh, not so. Â In VW and Cog examining a context does _not_ deoptimize a >> context. Â A context will be "deoptimized" (actually converted to a vanilla >> heap context) only if you write to other than its stack contents or sender. >> Â i.e. a context's frame is only discarded if >> - one assigns to any of its instance variables other than sender >> - the stack zone runs out of room for new frames and a stack page must be >> vacated, causing all frames on that page to be converted to stack contexts >> So exception handling does *not* usually involve converting contexts. Â It >> would be very slow if it did. >> > Ah, cool.. So, even when debugging (and hence accessing context state) > does not leads automatically to deoptimization? > >>> >>> and if stack depth is high >>> (between point of writing attempt and hook, where magma will handle >>> exception), this will be much slower >>> than WriteBarrier implementation, described by Cris, >>> which checking the value in-place, without the need of touching >>> exception machinery. >> >> I disagree strongly. Â Martin's experience with Gemstone (and Gemstone's >> experience) covers over twenty years and the VM-supported immutability >> implementations (first in VisualAge IIRC) of Gemstone are far more >> performant and less problematic than the code-rewriting implementations >> similar to Magma. Â Martin really knows what he's talking about. > > I'm not saying anything against immutability, but capturing the object > state change > seem will be less efficient. > By reading Cris description i imagine that WriteBarrier rewriting a code like: > > SomeClass>>foo: newValue > Â foo := newValue > > to: > > SomeClass*>>foo: newValue > Â | old | > Â old := foo. > Â foo := newValue. > Â old == foo ifFalse: [ Magma markAsDirty: self ] > > now compare performance of evaluating: > > [[[[[[ self foo: 5 ]]]]]] > > with: > > [[[[[[ self foo: 5 ]]]]]] on: ImmutableException do: [:ex | Â Magma > markAsDirty: ex receiver. ex receiver beMutable. ex resume ] > > where [[[[[]]]]]] is a call stack, which can be deeeeep. > A stack unwinding, actually could be avoided, if we suppose that VM signaling the exception , by sending SomeExceptionSpecialObject>>#signal: immutableObject Then Magma could hook there and override that method, to something like: SomeExceptionSpecialObject>>#signal: immutableObject (Magma watchingOverThisObject: immutableObject) ifFalse: [ ^ self new signal: immutableObject ]. Magma markAsDirty: immutableObject. immutableObject beMutable. "retry code here" -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2010

Re: [Pharo-project] [ANN] Icons for Mac users

by Stefan Marr

Hi: The icon for the images, and probably also the changes icon (which is not used for some reason on my machine) would benefit from a transparent background. At the moment, they have a white frame instead of a clean (white) pice of paper on a transparent background. Best Stefan On 08 Jan 2010, at 19:27, Mariano Martinez Peck wrote: > That's cooler, but you put a white background instead of transparency :( > > To convert a picture (png) for examplte to icns you can use the tool img2icns > > cheers > > 2010/1/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I was playing with adding a bit of shadow so that the icon stand out. > > > > may be people with better tools can produce something better. > > > 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 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525

Jan. 14, 2010

Re: [Pharo-project] clone vs shallowCopy

by StÃ©phane Ducasse

Thanks I linked the two issues On Jan 13, 2010, at 2:33 PM, Stan Shepherd wrote: > > > StÃ©phane Ducasse wrote: >> >> any bunch of cool tests before hacking? >> >> >> On Jan 13, 2010, at 9:53 AM, Alain Plantec wrote: >> >>> Lukas Renggli a Ã©crit : >>>> I suggest everybody to have a quick look at VW: >>>> - they have #copy and #postCopy as we do >>>> - they have #shallowCopy that is used from #copy as we do >>>> - they have #dcopy (what a horrible name) that is implemented in a >>>> similar way to what I suggested for #deepCopy >>>> >>>> There is nothing else. >>>> >>> yes, I think we should adopt this with (dcopy -> deepCopy). >>> Alain >>>> Lukas >>>> >> >> > > there's one (not a bunch) at: > http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=… > -- > View this message in context: http://n2.nabble.com/clone-vs-shallowCopy-tp4290815p4348552.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Igor Stasenko

2010/1/13 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Wed, Jan 13, 2010 at 12:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> 2010/1/13 Martin McClure <martin(a)hand2mouse.com>: >> > Eliot Miranda wrote: >> >> A *much* better way to implement this is to support immutability in the >> >> VM (I know, I know, but all the code is available in the Newspeak VM), >> >> mark objects one wants to mark as dirty as immutable, catch the >> >> NoModificationError exception, and proceed after having made the object >> >> mutable and marked it dirty. Â No creating hidden classes, no trying to >> >> get change class to work for compact classes, etc. Â Just a simple >> >> VM-implemented write barrier that can also be used for a host of other >> >> things (object-database mapping, debugging, immutable literals etc). >> > >> > Since object dirtying is at the core of the product I work with, and >> > I've worked extensively with both methods of implementing write >> > barriers... >> > >> > I very strongly agree with Eliot. *So* much nicer a way to do this. >> > >> >> It could be more efficient, in respect that you don't need to create >> shadow classes. >> But triggering exception leads to stack unwinding to find a handler, >> which inevitably leads to deoptimizing all contexts.. > > Uh, not so. Â In VW and Cog examining a context does _not_ deoptimize a > context. Â A context will be "deoptimized" (actually converted to a vanilla > heap context) only if you write to other than its stack contents or sender. > Â i.e. a context's frame is only discarded if > - one assigns to any of its instance variables other than sender > - the stack zone runs out of room for new frames and a stack page must be > vacated, causing all frames on that page to be converted to stack contexts > So exception handling does *not* usually involve converting contexts. Â It > would be very slow if it did. > Ah, cool.. So, even when debugging (and hence accessing context state) does not leads automatically to deoptimization? >> >> and if stack depth is high >> (between point of writing attempt and hook, where magma will handle >> exception), this will be much slower >> than WriteBarrier implementation, described by Cris, >> which checking the value in-place, without the need of touching >> exception machinery. > > I disagree strongly. Â Martin's experience with Gemstone (and Gemstone's > experience) covers over twenty years and the VM-supported immutability > implementations (first in VisualAge IIRC) of Gemstone are far more > performant and less problematic than the code-rewriting implementations > similar to Magma. Â Martin really knows what he's talking about. I'm not saying anything against immutability, but capturing the object state change seem will be less efficient. By reading Cris description i imagine that WriteBarrier rewriting a code like: SomeClass>>foo: newValue foo := newValue to: SomeClass*>>foo: newValue | old | old := foo. foo := newValue. old == foo ifFalse: [ Magma markAsDirty: self ] now compare performance of evaluating: [[[[[[ self foo: 5 ]]]]]] with: [[[[[[ self foo: 5 ]]]]]] on: ImmutableException do: [:ex | Magma markAsDirty: ex receiver. ex receiver beMutable. ex resume ] where [[[[[]]]]]] is a call stack, which can be deeeeep. >> >> Just 2 cents. >> >> > Regards, >> > >> > -Martin >> > >> > >> > _______________________________________________ >> > 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.

Jan. 14, 2010

Re: [Pharo-project] EventSensor vs EventInputSensor

by StÃ©phane Ducasse

I do not know what I know is that we should support the new event architecture and deprecate the polling one On Jan 13, 2010, at 5:23 PM, Miguel Enrique CobÃ¡ Martinez wrote: > El miÃ©, 13-01-2010 a las 17:15 +0100, Fernando olivero escribiÃ³: >> Sensor class = InputEventSensor true >> > > Now, it only remains to know if this should be a permanent change in the > Pharo image or just a preloadDoit of the metacello configuration of > Magma. > > Stef? What do you think? > > Cheers > >> >> On Jan 13, 2010, at 5:08 PM, Chris Muller wrote: >> >>> Sensor class = InputEventSensor >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 14, 2010

Re: [Pharo-project] ConfigurationOfAlien

by StÃ©phane Ducasse

On Jan 13, 2010, at 7:00 PM, Levente Uzonyi wrote: > On Wed, 13 Jan 2010, Henrik Johansen wrote: > >> >> On Jan 13, 2010, at 6:06 53PM, Schwab,Wilhelm K wrote: >> >>> That's great news, at least for mac users. What does a penguin herder do to get a plugin? >> >> 1) Download VM sources for latest release from www.squeakvm.org. >> 2) Make an image with VMMaker and AlienPlugin. >> 3) Use VMMakerTool to generate AlienPlugin sources. >> 4) (possibly) use special sqVirtualMachine.c/h from the \Cross\plugins\IA32ABI folder. >> 5) Try to compile, fix errors that pop up. >> 6) Repeat step5 enough times that you end up with a compiled plugin. > > 7) Run the tests and wonder why your plugin doesn't work. Repeat 1-7 a few times. > 8) Give up and wait till someone else succeeds. > >> >> >>> Would it be easier to use a squeak image to build it? >> Only step 2, unless you load from www.squeaksource.org/JBARepo, and run VMMakerLoader loadAndFix. probably because JB was fighting in his corner against the dragon and did not dare to fucked up the VMMaker repository After the paper we are writing I will ask him to take action and to ask if people wants his stuff. > > I wonder why are these packages forked. > > > Levente > >> >> Cheers, >> Henry >> _______________________________________________ >> 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

Jan. 14, 2010

Re: [Pharo-project] Flaw in SocketStream>>peek detected

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1813 On Jan 13, 2010, at 8:49 PM, Igor Stasenko wrote: > http://bugs.squeak.org/view.php?id=7446 > > -- > 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

Jan. 14, 2010

[Pharo-project] [update 1.1] #11156

by StÃ©phane Ducasse

11156 ----- - Issue 1811: FreeType fix for better integration of Rome Tx Mike :) - Issue 1151: RFC2047MimeConverter>>#readWord is broken, and this may be part of a larger issue tx Peter :) (it was not marked as fixed nor 1.1 so skipped our radar) - Issue 1751: allPairsDo: aBinaryBlock self do: [:first| self do: [:second| aBinaryBlock value: first value: second]] - Issue 1769: TestRunner author while running tests so we will have popup menu problems and in such case should fix the tests ;) Stef

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Eliot Miranda

On Wed, Jan 13, 2010 at 12:45 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/1/13 Martin McClure <martin(a)hand2mouse.com>: > > Eliot Miranda wrote: > >> A *much* better way to implement this is to support immutability in the > >> VM (I know, I know, but all the code is available in the Newspeak VM), > >> mark objects one wants to mark as dirty as immutable, catch the > >> NoModificationError exception, and proceed after having made the object > >> mutable and marked it dirty. No creating hidden classes, no trying to > >> get change class to work for compact classes, etc. Just a simple > >> VM-implemented write barrier that can also be used for a host of other > >> things (object-database mapping, debugging, immutable literals etc). > > > > Since object dirtying is at the core of the product I work with, and > > I've worked extensively with both methods of implementing write > barriers... > > > > I very strongly agree with Eliot. *So* much nicer a way to do this. > > > > It could be more efficient, in respect that you don't need to create > shadow classes. > But triggering exception leads to stack unwinding to find a handler, > which inevitably leads to deoptimizing all contexts.. Uh, not so. In VW and Cog examining a context does _not_ deoptimize a context. A context will be "deoptimized" (actually converted to a vanilla heap context) only if you write to other than its stack contents or sender. i.e. a context's frame is only discarded if - one assigns to any of its instance variables other than sender - the stack zone runs out of room for new frames and a stack page must be vacated, causing all frames on that page to be converted to stack contexts So exception handling does *not* usually involve converting contexts. It would be very slow if it did. > and if stack depth is high > (between point of writing attempt and hook, where magma will handle > exception), this will be much slower > than WriteBarrier implementation, described by Cris, > which checking the value in-place, without the need of touching > exception machinery. > I disagree strongly. Martin's experience with Gemstone (and Gemstone's experience) covers over twenty years and the VM-supported immutability implementations (first in VisualAge IIRC) of Gemstone are far more performant and less problematic than the code-rewriting implementations similar to Magma. Martin really knows what he's talking about. > Just 2 cents. > > > Regards, > > > > -Martin > > > > > > _______________________________________________ > > 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 >

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Marcus Denker

On Jan 13, 2010, at 5:11 PM, Lukas Renggli wrote: >> Can someone clarify, why WriteBarrier depends on compiler (new >> compiler or old compiler - not really important). >> I just wonder what compiler functionality its depends on. > > WriteBarrier introduces something like immutable objects at the > language level by rewriting all state access in an anonymous subclass. > Having a compiler at hand certainly makes things simpler. And modifying bytecode gets even more simpler with ByteSurgeon: http://scg.unibe.ch/research/bytesurgeon ... soon in a new release, closure enabled, using a DSL implemented with Lukas' Helvetia: http://scg.unibe.ch/research/helvetia Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 14, 2010