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

Re: [Pharo-project] [ANN] WorkingSet

by Romain Robbes

>> >> >>> Future work: integration in the browser :) >>> >> >> How do you envision that? I tried to not be too browser-specific, as these things are moving targets. > > I would not integrate that in browser because it makes the state machine of this brittle tools brittler and like that you > can focus on working set functionality vs browser bugs :) > If anything, WorkingSet makes code browsers look like disposable entities. It opens so many of them that it even includes a shortcut to close all the windows opened by it :-). What I would like to have now is a better window placement, with possibilities to tile windows. Has anybody done something like that already? Romain -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Chris Muller

Compilation of the subclass is only done once per class (and cached). It takes under one second per class and could be done at application start-up anyway. So I'm dubious that any kind of Exception Handling approach is going to be "far more performant" that simply calling "self modified:" as the existing WriteBarrier implementation does. As for "less-problematic", that might have been true with GemStone. Personally, I would worry about forgetting to set the immutable bit on my objects. If that were the basis by which changed-detection occurs, forgetting to set immutable could result in object changes not being detected, and therefore not committed. Silently - you wouldn't know you lost work until much later. *That* sounds problematic! For Magma, the existing WriteBarrier approach really hasn't been problematic at all, even under lots of heavy use (though we run with it turned off in our own production systems, don't need it). It operates transparently to the Magma user as a "set and forget". I concur, however, that it *is* a more complex solution than simply handling the NoModify exception approach. Introducing the notion of a VM-level immutable bit to objects may be a nice feature, but "feels" less-dynamic, since it reflects a similarity with static typing. I have "set up" objects for use and, introduces the notion that every single mutative operation, in all places, must (or at least should) now have to handle the NoModify exception. - Chris 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. > >> >> 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 > > _______________________________________________ > 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 John M McIntosh

On 2010-01-13, at 8:43 AM, Fernando olivero wrote: > To load Alien using Metacello configurations evaluate > > Gofer new > url: 'http://www.squeaksource.com/MetacelloRepository' ; > package: 'ConfigurationOfAlien'; > load. > (ConfigurationOfAlien project version:'1.0') load. > > > ( John please update the ALIEN squeaksource page with the previous text ) Done -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 14, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Martin McClure

Igor Stasenko wrote: >> >> [[[[[[ 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" This is actually very close to what we do currently. We intercept before the exception is signaled. The generic handler like Eliot describes is what we'd like to move to, as our current scheme would conflict with anyone else who was doing something similar. ---- Eliot Miranda wrote: > > Martin could you say something about the dispatch schemes Gemstone uses > and what the performance issues have been in practice? (TIA) > The maintainability of the code has been much better than schemes that modify the application's bytecodes, which is what we did previously, similar to what Chris describes. Performance is better also, though I don't have figures. Imagine that you need to track changes to an Array. You either have to make that one Array in reality a different class than all the untracked Arrays, in which case somewhere along the line someone's going to catch you at that trick and some code will break, or you have to instrument basicAt:put: for every Array in the system. As Eliot points out, with VM support you only pay a penalty for writes to clean tracked objects. Untracked objects and already-dirtied objects pay no penalty. Since these are the majority of assignments, it's a clear win. And I believe that Eliot's implementation of the VM support for immutability was clever enough that it carried exactly zero penalty for writes to mutable objects, by combining the immutability check into the already-necessary range check. ---- Igor Stasenko wrote: > > 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. > Actually, the VW VM gives you the value that failed to be assigned (and you need that anyway to re-do the assignment after the mark dirty) so we use that to ignore identical assignment at the Smalltalk level. I probably wouldn't put that in the VM code, it's not a common enough case to warrant the complexity. Regards, -Martin

Jan. 14, 2010

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

by Henrik Sperre Johansen

On 13.01.2010 23:19, Stan Shepherd wrote: > > (Workspace new embeddedInMorphicWindowLabeled: 'Welcome to Pharo') > position: > 100@100 ; width: 200; height: 500; openInWorld > > :) > > Try evaluating that twice in a row and see if your Workspace opens at the same spot ;) Cheers, Henry

Jan. 14, 2010

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

by Stan Shepherd

Mariano Martinez Peck wrote: > > 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 ? > > > > (Workspace new embeddedInMorphicWindowLabeled: 'Welcome to Pharo') position: 100@100 ; width: 200; height: 500; openInWorld :) -- View this message in context: http://n2.nabble.com/How-can-I-remove-a-picture-from-background-tp4349399p4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 14, 2010

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

by Mariano Martinez Peck

2010/1/13 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > On 13.01.2010 22:56, Mariano Martinez Peck wrote: > > > > 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 ? > > Not to mention, position: moves by a delta (don't ask me why), so that > would derive from whatever position is decided by openInWorld. > I imagine this is not what you want. > Try: > (Workspace new > > acceptContents: 'This is the content'; > embeddedInMorphicWindowLabeled: 'This is a label') > position: 50@50; > extent: 500 @ 400; > openAsIs > > Henry: I hope you never leave the Pharo community :) Thank you very much. That did the trick!!! Now...a helpmer method for this in Workspace! > 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] [ANN] Metacello configuration of OSProcess

by Schwab,Wilhelm K

Stef (correctly) does not like filling Object with methods that have no business there. IMHO, one thing that is worse is the horrible level of needless subclassing in Squeak. However dubious (or simply avoidable) it might be to intermingle an ip address and a port, it is much worse to subclass the whole mess from a byte array :( I have hit several similar kinds of bugs in the process of trying to sort out the IPv6 changes. Port numbers are orthogonal to addresses, and addresses come in name and number. We would do well to follow Dolphin in having an address with two aspects, either of which can be set and other lazily resolved. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Wednesday, January 13, 2010 5:02 PM To: Pharo Subject: Re: [Pharo-project] [ANN] Metacello configuration of OSProcess 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 _______________________________________________ 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:58, Nicolas Cellier wrote: > 2010/1/13 Henrik Sperre Johansen<henrik.s.johansen(a)veloxit.no>: > >> >> 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 > Sweet, I was browsing an old version then :D

Jan. 14, 2010

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

by Henrik Sperre Johansen

On 13.01.2010 22:56, Mariano Martinez Peck wrote: > > > On Wed, Jan 13, 2010 at 10:50 PM, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com > <mailto:marianopeck@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 ? > Not to mention, position: moves by a delta (don't ask me why), so that would derive from whatever position is decided by openInWorld. I imagine this is not what you want. Try: (Workspace new acceptContents: 'This is the content'; embeddedInMorphicWindowLabeled: 'This is a label') position: 50@50; extent: 500 @ 400; openAsIs Cheers, Henry

Jan. 14, 2010