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

Re: [Pharo-project] NewCompiler load on PharoCore

by Igor Stasenko

2010/1/13 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > 1. [ Agreed, and snipped. ] > > 2. Yes, but it doesn't cost as much as you think. Â If one is using > immutability to mark objects dirty then the exception only gets delivered > once for that object. Â Once the object is dirty it can remain mutable until > a batch of objects are updated, etc. > Right. But we should not fool ourselves and actually play nicely even for the worst case here, when application, for some stupid reason, tries to modify every object it can put its hands on ;) Also, one subtle detail about following: old := foo. foo := newValue. old == foo ifFalse: [ Magma markAsDirty: self ] that if old == foo, object will not be marked dirty and write will be performed. But in case of NoModificationError, object will be marked dirty, because you don't know what actual value were attempted to be written, and what sits on that place now. Maybe VM should play nice and just ignore cases when write attempt does not changing anything , because old slot value is same as new one. > Martin could you say something about the dispatch schemes Gemstone uses and > what the performance issues have been in practice? Â (TIA) > > best > Eliot >> -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2010

Re: [Pharo-project] [ANN] Metacello configuration of OSProcess

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 13-01-2010 a las 15:52 -0600, Miguel Enrique CobÃ¡ Martinez escribiÃ³: I ran the tests in PharoCore 10506 and got 4 failures: AioEventHandlerTestCase>>#testSocketExceptionEvent AioEventHandlerTestCase>>#testSocketReadableEvent AioEventHandlerTestCase>>#testSocketReadableEventWithMaskNotSet AioEventHandlerTestCase>>#testSuspendAioForSocketReadableEvent All of them caused by ByteArray(Object)>>doesNotUnderstand: #port: in: Socket>>connectTo:port: Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 14, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Nicolas Cellier

2010/1/13 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > On 13.01.2010 22:25, StÃ©phane Ducasse wrote: >> 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. >> > The changes he made are specific to changes made in Pharo, getting them > commited to VMMaker will be hard without having Squeak adopt them as well. > > As far as I remember, Andreas for one was not against changing > ByteString class >> Â findSubstring;in:startingAt:matchTable: to > primFindSubstring, and changing findSubstring... to a > non-primitive-invoking method that does delegation, although I believe > the bug has already been handled differently (ie. the senders have been > changed to do the check instead) in Trunk. > > As for the spelling correction, the method is still called > findLastOccuranceOfString:startingAt: in Trunk, should be simple enough > to rename it findLastOccurrenceOfString:startingAt: Â and keep the old > version for backwards-compatability if deemed necessary. > Oh this one is already ported in trunk findLastOccuranceOfString: subString startingAt: start self deprecated: 'Use instead #findLastOccurrenceOfString:startingAt:'. ^ self findLastOccurrenceOfString: subString startingAt: start > Cheers, > Henry > > _______________________________________________ > 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] How can I remove a picture from background ?

by Mariano Martinez Peck

On Wed, Jan 13, 2010 at 10:50 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Ok...I am lazy to open a new thread...My understandings of Morphic are > not > > even nil. > > > > I need to programatically open a workspace and set a size to it. For > > example: > > > > > > Workspace new > > acceptContents: 'This is the content'; > > openLabel: 'This is a label'. > > > > I saw the message extent: but is in Morphs, and this is not morph. > > > > I would like to do something like this: > > > > > > Workspace new > > acceptContents: 'This is the content'; > > openLabel: 'This is a label'; > > extent: 500 @ 400. > > > > > > Any tips ? > > > > And of course, if I can choose WHERE (x and y) would be greate also. > > > > Morph new openInWorld position: 100@100 ; width: 200; height: 500 > > Thanks Igor. I am REALLY newbie. I want a workspace to do that, not a Morph. Workspace is not in the Morph hierarchy and thus, it does not understand that message. Maybe I can put a workspace inside that morph ? > > Thanks! > > > > Mariano > > > > 2010/1/13 Gary Chambers <gazzaguru2(a)btinternet.com> > >> > >> Well, still many loose ends around as we refactor, that's for sure! > >> As for understanding Morphic, there's so much that none can know all... > >> hence trying to simplify with Pharo. Some good stuff, some bad and even > when > >> you think you know, there's always something that comes up ,either too > easy > >> or next to impossible... > >> Regards, Gary > >> > >> ----- Original Message ----- > >> From: CÃ©drick BÃ©ler > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Sent: Wednesday, January 13, 2010 4:31 PM > >> Subject: Re: [Pharo-project] How can I remove a picture from background > ? > >> 2010/1/13 Gary Chambers <gazzaguru2(a)btinternet.com> > >>> > >>> All about getting to know how Morphic works... or sometimes doesn't, as > >>> you explore further down the rabbit hole! > >> > >> quite scaring actually :) > >> For instance, for background, I had a quick look at PasteUpMorph and > there > >> is backgroundMorph which might be more appropriate but I find no > hooks... > >> Anyway... now I know I still don't want to understand morphic :) > >> > >>> > >>> Regards, Gary > >>> > >>> ----- Original Message ----- > >>> From: Mariano Martinez Peck > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Sent: Wednesday, January 13, 2010 3:56 PM > >>> Subject: Re: [Pharo-project] How can I remove a picture from background > ? > >>> hahahahha why everybody had the same idea and I didn't ? hahah > >>> > >>> I seems I ask something very stupid... > >>> > >>> Thanks anyway CÃ©drick > >>> > >>> 2010/1/13 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > >>>> > >>>> something like (not sure though): > >>>> World color: Color white > >>>> > >>>> 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com> > >>>>> > >>>>> Hi: I do something like this: > >>>>> > >>>>> Form setBackgroundFromImageFileNamed: '/Users/mariano/Pharo/body.png' > >>>>> > >>>>> And the picture is set as background, but then I don't know how to > >>>>> remove it. I look for a while but I didn't find anything. > >>>>> > >>>>> Thanks for the help, > >>>>> > >>>>> Mariano > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>>> > >>>> > >>>> -- > >>>> CÃ©drick > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > >> > >> > >> -- > >> CÃ©drick > >> > >> ________________________________ > >> > >> _______________________________________________ > >> 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 > > > > > > -- > 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 Eliot Miranda

On Wed, Jan 13, 2010 at 1:41 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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" > Right. Something of this order. Again lighter-weight than delivering an exception and much lighter weight than constructing a special class. But see my previous message for how to write it nicely, or play with Gemstone and VW non-commercial to see how it is done in a production system. > > -- > 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] [ANN] Metacello configuration of OSProcess

by Miguel Enrique CobÃ¡ Martinez

Hi all, I have published the ConfigurationOfOSProcess in the MetacelloRepository of squeaksource. With this you can load OSProcess and its tests in PharoCore. Just evaluate in a workspace: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOSProcess'; load. Then evaluate ((Smalltalk at: #ConfigurationOfOSProcess) project version: '4.3.11') load. to load just the OSProcess, or: ((Smalltalk at: #ConfigurationOfOSProcess) project version: '4.3.11') load: 'Tests'. to load OSProcess and their tests. Tested in PharoCore 10506 Enjoy! -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 14, 2010

Re: [Pharo-project] How can I remove a picture from background ?

by Igor Stasenko

2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Ok...I am lazy to open a new thread...My understandings of Morphic are not > even nil. > > I need to programatically open a workspace and set a size to it. For > example: > > > Â Â Â Workspace new > Â Â Â acceptContents: 'This is the content'; > Â Â Â openLabel: 'This is a label'. > > I saw the message extent:Â Â but is in Morphs, and this is not morph. > > I would like to do something like this: > > > Â Â Â Workspace new > Â Â Â acceptContents: 'This is the content'; > Â Â Â openLabel: 'This is a label'; > Â Â Â extent: 500 @ 400. > > > Any tips ? > > And of course, if I can choose WHERE (x and y) would be greate also. > Morph new openInWorld position: 100@100 ; width: 200; height: 500 > Thanks! > > Mariano > > 2010/1/13 Gary Chambers <gazzaguru2(a)btinternet.com> >> >> Well, still many loose ends around as we refactor, that's for sure! >> As for understanding Morphic, there's so much that none can know all... >> hence trying to simplify with Pharo. Some good stuff, some bad and even when >> you think you know, there's always something thatÂ comes up ,either too easy >> or next to impossible... >> Regards, Gary >> >> ----- Original Message ----- >> From: CÃ©drick BÃ©ler >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Wednesday, January 13, 2010 4:31 PM >> Subject: Re: [Pharo-project] How can I remove a picture from background ? >> 2010/1/13 Gary Chambers <gazzaguru2(a)btinternet.com> >>> >>> All about getting to know how Morphic works... or sometimes doesn't, as >>> you explore further down the rabbit hole! >> >> quite scaring actually :) >> For instance, for background, I had a quick look at PasteUpMorph and there >> is backgroundMorph which might be more appropriate but I find no hooks... >> Anyway... now I know I still don't want to understand morphic :) >> >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: Mariano Martinez Peck >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Sent: Wednesday, January 13, 2010 3:56 PM >>> Subject: Re: [Pharo-project] How can I remove a picture from background ? >>> hahahahha why everybody had the same idea and I didn't ?Â hahah >>> >>> I seems I ask something very stupid... >>> >>> Thanks anyway CÃ©drick >>> >>> 2010/1/13 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> >>>> >>>> something like (not sure though): >>>> World color: Color white >>>> >>>> 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>> >>>>> Hi:Â I do something like this: >>>>> >>>>> Form setBackgroundFromImageFileNamed: '/Users/mariano/Pharo/body.png' >>>>> >>>>> And the picture is set as background, but then I don't know how to >>>>> remove it. I look for a while but I didn't find anything. >>>>> >>>>> Thanks for the help, >>>>> >>>>> Mariano >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>>> -- >>>> CÃ©drick >>>> >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> CÃ©drick >> >> ________________________________ >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Eliot Miranda

On Wed, Jan 13, 2010 at 1:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > 1. Yes, but there are lots of other ways to go about it. One scheme (which I think Gemstone uses as well the immutability stuff for Newspeak) is to have a policy object control what happens when a NoModificationError occurs. Its function is to decide what to do for the immutable object. It can do things like maintain a mapping from objects (or blocks evaluated on objects) to handlers. Only if there is no handler found for an object is the exception actually delivered. Another scheme is to allow objects to override the basic immutability machinery that by default delivers a NoModificationException. Immutability violations come into the image in two ways. If an attempt is made to assign an inst var the Vm sends attemptToAssign: aValue withIndex: instVarIndex to the immutable object. If an attempt is made to assign to an object in a primitive the primitive fails with a #'no modification error' error code. In Object there is a default: noModificationError: selector arguments: arguments ^NoModificationError signal: self message: (Message selector: selector arguments: arguments) attemptToAssign: aValue withIndex: index "The VM sends this message to objects when attempts are made to assign to inst vars of immutable objects" ^self noModificationError: #instVarAt:put: arguments: {index. aValue} at: index put: aValue <primitive: 61> "primitiveAtPut" index isInteger ifTrue: [self class isVariable ifTrue: [(index >= 1 and: [index <= self size]) ifTrue: [self isImmutable ifTrue: [^ self noModificationError: #at:put: arguments: {index. aValue}]. self errorImproperStore] ifFalse: [self errorSubscriptBounds: index]] ifFalse: [self errorNotIndexable]]. index isNumber ifTrue: [^ self at: index asInteger put: aValue]. self errorNonIntegerIndex So a specific class can implement noModificationError:arguments: to short cut even delivering the exception imn the first place. 2. Yes, but it doesn't cost as much as you think. If one is using immutability to mark objects dirty then the exception only gets delivered once for that object. Once the object is dirty it can remain mutable until a batch of objects are updated, etc. Martin could you say something about the dispatch schemes Gemstone uses and what the performance issues have been in practice? (TIA) best Eliot > >> > >> 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. > > _______________________________________________ > 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 Henrik Sperre Johansen

On 13.01.2010 22:25, StÃ©phane Ducasse wrote: > 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. > The changes he made are specific to changes made in Pharo, getting them commited to VMMaker will be hard without having Squeak adopt them as well. As far as I remember, Andreas for one was not against changing ByteString class >> findSubstring;in:startingAt:matchTable: to primFindSubstring, and changing findSubstring... to a non-primitive-invoking method that does delegation, although I believe the bug has already been handled differently (ie. the senders have been changed to do the check instead) in Trunk. As for the spelling correction, the method is still called findLastOccuranceOfString:startingAt: in Trunk, should be simple enough to rename it findLastOccurrenceOfString:startingAt: and keep the old version for backwards-compatability if deemed necessary. Cheers, Henry

Jan. 14, 2010

Re: [Pharo-project] How can I remove a picture from background ?

by Mariano Martinez Peck

Ok...I am lazy to open a new thread...My understandings of Morphic are not even nil. I need to programatically open a workspace and set a size to it. For example: Workspace new acceptContents: 'This is the content'; openLabel: 'This is a label'. I saw the message extent: but is in Morphs, and this is not morph. I would like to do something like this: Workspace new acceptContents: 'This is the content'; openLabel: 'This is a label'; extent: 500 @ 400. Any tips ? And of course, if I can choose WHERE (x and y) would be greate also. Thanks! Mariano 2010/1/13 Gary Chambers <gazzaguru2(a)btinternet.com> > Well, still many loose ends around as we refactor, that's for sure! > As for understanding Morphic, there's so much that none can know all... > hence trying to simplify with Pharo. Some good stuff, some bad and even when > you think you know, there's always something that comes up ,either too easy > or next to impossible... > > Regards, Gary > > ----- Original Message ----- > *From:* CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > *To:* Pharo-project(a)lists.gforge.inria.fr > *Sent:* Wednesday, January 13, 2010 4:31 PM > *Subject:* Re: [Pharo-project] How can I remove a picture from background > ? > > 2010/1/13 Gary Chambers <gazzaguru2(a)btinternet.com> > >> All about getting to know how Morphic works... or sometimes doesn't, as >> you explore further down the rabbit hole! >> > > quite scaring actually :) > > For instance, for background, I had a quick look at PasteUpMorph and there > is backgroundMorph which might be more appropriate but I find no hooks... > > Anyway... now I know I still don't want to understand morphic :) > > > >> >> Regards, Gary >> >> ----- Original Message ----- >> *From:* Mariano Martinez Peck <marianopeck(a)gmail.com> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Sent:* Wednesday, January 13, 2010 3:56 PM >> *Subject:* Re: [Pharo-project] How can I remove a picture from background >> ? >> >> hahahahha why everybody had the same idea and I didn't ? hahah >> >> I seems I ask something very stupid... >> >> Thanks anyway CÃ©drick >> >> 2010/1/13 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> >> >>> something like (not sure though): >>> World color: Color white >>> >>> 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>>> Hi: I do something like this: >>>> >>>> Form setBackgroundFromImageFileNamed: '/Users/mariano/Pharo/body.png' >>>> >>>> And the picture is set as background, but then I don't know how to >>>> remove it. I look for a while but I didn't find anything. >>>> >>>> Thanks for the help, >>>> >>>> Mariano >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> CÃ©drick >>> >>> _______________________________________________ >>> 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 >> > > > > -- > CÃ©drick > > ------------------------------ > > _______________________________________________ > 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