- Pharo-dev - lists.pharo.org

[Pharo-project] WeakRegistry>>remove: - when you'll be in trouble
by Igor Stasenko Oct. 11, 2010

Oct. 11, 2010

A current implementation of this method remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) ifNil: [ exceptionBlock value ] simply removes a previously registered object from registry and voila. Now lets get back to our discussion about multiple finalizers per object and using them in weak subscriptions etc. Suppose i am added a socket to weak registry, and suppose i am added a weak subscription to it. Now, if i do 'socket close' , it tells weak registry to remove it from list. And what we'll have: - socket handle is closed - socket is wiped from weak registry - but weak subscription still listed somewhere in a list of subscriptions My suggestion is, that upon #remove:, a weak registry should notify all executors that object of interest are no longer takes part in finalization scheme, so they should not count on receiving #finalize eventually. In other words: remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ | executor | executor := valueDictionary removeKey: oldObject ifAbsent: nil. executor discardFinalization. ]) ifNil: [ exceptionBlock value ] -- Best regards, Igor Stasenko AKA sig.

4 9

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

>> >> >> Now to me this looks like a hack and again it works because now Symbol are valuable objects. >> Too many hacks will only make the system more hackish. >> And especially the >> iftrue: 'foo' ifFalse: 'zork' >> > > This is not a hack, because if you refer to implementation: > > True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^trueAlternativeBlock value > > False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^falseAlternativeBlock value > > so, it answers either 'foo' value , or 'zork' value. > And #value could be sent to any object in system: > > Object>>value > ^self > > What actually shown here is a use of duck typing, because any object, > which implemets #value, could be safely passed > as argument to #ifTrue:ifFalse: message. > It is well consistent with language design. I know well that. and it sucks from a language semantics point of view. I agree with the mail of lukas. Stef

2 1

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

On Oct 11, 2010, at 1:28 PM, Lukas Renggli wrote: >> Object>>value >> ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. > > Magritte implemented Symbol>>#value: for a while before any Smalltalk > had this is their standard library. I must admit that I liked it in > the beginning, but in the long run I realized that ... > > 1. It is not easily understandable for newbies. > 2. It quickly leads to very unreadable, hard to understand and hard to > refactor code. > 3. It is very limiting in itself and quickly leads to other hacks > (like to replace sort blocks). > 4. #value and friends should be only understood by objects that can be > evaluated (certainly not by Object). A symbol (name) by itself cannot > be evaluated. + 200 > I eventually removed Symbol>>#value: for good. Re-occuring questions > in the mailing list disappeared. > > Therefor I strongly suggest to remove #value, #value:, and friends > from all objects that are not self-evaluable. BlockClosure and > MessageSend are self-evaluable. Only there it makes sense. > > If people are too lazy to create a block where something > self-evaluable is needed they should use a programming language > designed for cryptic code. Creating a block closure in Smalltalk is > concise and makes clear what happens easily. A symbol does not, you > need to exactly understand how this dispatches with various objects. This is exactly my point. Especially for system API like ifNotNil: When I read self bar: #zook I just know ok we are just passing a symbol as argument. I do not have to rely on the semantics of bar: so this is the only conclusion I can draw. Now I do not want to force people to have to understand the semantics of each single selector. In addition, it breaks nice rule such as use [ ] for any place where you do not know if the code will be executed. Simple nice and beautiful. [..]s delay execution and let the guy control it. Stef

1 0

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

Hi we should improve from that side, but unfortunately we do not have enough man power to build tool that could support it. Stef On Oct 11, 2010, at 1:28 PM, Johannes Rasche wrote: > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! > > Thanks in advance > > > > > Johannes Rasche > Hagelberger Str. 56 > 10965 Berlin > > mail: johannesrasche(a)me.com > skype: johannesrasche > www: http://myNeat.de > fon: +49-30-7469 4425 (skypeIn) > fax: +49-30-315 66 821 > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] another little OB "bug"
by Mariano Martinez Peck Oct. 11, 2010

Oct. 11, 2010

Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no problem then ;) Suppose you are working with a method that it is in the half of the method pane of OB. Once you save it or run test on it for example, the "scroll" and the method pane is updated so that THAT method is first, above. And sometimes this is quite annoying for me. Cheers Mariano

2 4

[Pharo-project] Xtreams : first embryonary port on Squeak
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

So, I started a quick port of VW Xtreams to Squeak this evening. Only the Xtreams-Core and the trivial Xtreams-Terminals (no file/pipe/socket/pointer). You'll find code at http://www.squeaksource.com/XTream. My previous experimental Xtream project has been renamed SqueaXTream to reduce confusion, but still sits in the same project. Please find my report below. cheers Nicolas --------------------- REPORT --------------------- THE CONTENTS: This first port is made of 3 packages - Xtreams-Core - Xtreams-Terminals - Xtreams-VWCompatible Plus 2 tests - Xtreams-CoreTests - Xtreams-TerminalsTests Please notice I removed one hyphen from test package names for MC compatibility. THE PROCEDURE: I didn't use FileOut30 not any more advanced tool, but just a simple copy/paste strategy. This gave me a chance to do a fast review of code. For porting the future evolutions of VW Xtreams, more advanced tools will be necessary, the manual approach does not scale. THE MODIFICATIONS: The changes I made are quite restricted, which indicates that Xtreams is not that hard to port. Main changes are due to lack of namespace in Squeak: - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) - I added XTPools, a SharedPool for holding the single Xtreams namespace variable DefaultBufferSize - I transformed class SharedVariables into class variables and added proper class side initialization for these in XTWriteStream For the rest, I tried to not change Xtreams contents. but rather did implement VW compatible messages when possible in the Xtreams-VWCompatible package when they did not exist in Squeak. These message are a full rewrite and are also released under MIT license. The few exceptions are: - I modified originator -> self originator in XTIncomplete. - I changed the senders of #newInFixedSpace: to rather send an #error: 'not implemented in Squeak' in XTRecyclingBuffer - I replaced #waitIfCurtailedSignal/#signal with a #critical: section in XTRecyclingBuffer - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests A DISCUSSION OF TECHNICAL DETAILS: I first attempted to replace #growToAtLeast: with #grownBy: because Squeak become: is notoriously inefficient. But obviously, this did not work, the tests rely on destination preserving its identity. This clearly is going to degrade micro benchmarks when the destination collection capacity is not well adjusted in advance. I think we should discuss this particular point. Is identity preservation absolutely required, or just convenient ? THE STATUS OF TESTS: Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM). THE FUTURE: I will probably continue porting with reduced activity, so I invite any interested person to help. Right now, the project is world writeable, code commited here falling under MIT license.

4 5

Re: [Pharo-project] 12186 image quit problem
by StÃ©phane Ducasse Oct. 11, 2010

Oct. 11, 2010

Thanks. So let's see what is the best choice and tell us. On Oct 11, 2010, at 11:47 AM, Igor Stasenko wrote: > On 11 October 2010 12:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I integrate >> Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >> http://code.google.com/p/pharo/issues/detail?id=3086 >> >> >> >> Igor can you have a look and let me know: >> 1- if we should rollback Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. >> 2- if we should integrate >> Issue 3048: MC method cache fix >> http://code.google.com/p/pharo/issues/detail?id=3048 >> >> I will integrate >> http://code.google.com/p/pharo/issues/detail?id=3091 >> > > Wait , MCMethodDefinition is only a consequence (however, removing it > from weakdependents would be good idea as well ;)). Yes I integrate it to avoid system hanging. > The real cultprit is HostSystemMenusProxy , which locks the weak > registry during finalization. > Then MCMethodDefinition>>shutdown simply locks at same point (trying > to obtain semaphore lock). > Note, that HostSystemMenusProxy locks finalization process, but not > the process which doing shutdown, > and then during image startup, a new finalization process get created. > That's why removing access to weakdependents in > MCMethodDefinition>>shutdown , kinda solved the issue. > In reality its not. > An old weak registry were sending #finalize outside a critical section: > > finalizeValues > "Some of our elements may have gone away. Look for those and activate > the associated executors." > | finiObjects | > finiObjects := nil. > "First collect the objects." > self protected:[ > valueDictionary allAssociationsDo:[:assoc| > assoc key isNil ifTrue:[ > finiObjects isNil > ifTrue:[finiObjects := OrderedCollection with: assoc value] > ifFalse:[finiObjects add: assoc value]] > ]. > finiObjects isNil ifFalse:[valueDictionary finalizeValues: > finiObjects asArray]. > ]. > "Then do the finalization" > finiObjects isNil ifTrue:[^self]. > finiObjects do:[:each| each finalize]. > > > So, there two ways to solve it: > a) perform finalization outside a critical section (see attached) > b) fix the HostSystemMenusProxy to prevent any manupulation with weak > registry during finalization. > > > I checked Squeak 4.2 image, and i can also say, that any attempt to > manipulate weak registry during finalization will also lock down a > finalization process (see Squeak's WeakRegistry>>finalizeValues & > WeakKeyDictionary>>finalizeValues) > > So, if we going to assume, in future that it is error to modify weak > registry during finalization, then we should leave the code in > WeakRegistry as-is, and fix HostSystemMenusProxy instead. > If not, the we should make sure that #finalize should be sent outside > weak registry's critical section. > > And the last note: if VM supports new finalization, it will happen > outside a critical section (See the > bottom of WeakRegistry>>finalizeValues). So any manipulations with > registry during finalization can't cause lockdown. > > > P.S. forwarded to Squeak-dev, to make Squeakers aware of potential > danger , when manipulating weak registry during finalization. > > -- > Best regards, > Igor Stasenko AKA sig. > <WeakRegistry-finalizeValues.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Oct. 11, 2010

I integrate Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. http://code.google.com/p/pharo/issues/detail?id=3086 Igor can you have a look and let me know: 1- if we should rollback Issue 3086: MCMethodDefinition>>shutdown hack to avoid lock down. 2- if we should integrate Issue 3048: MC method cache fix http://code.google.com/p/pharo/issues/detail?id=3048 I will integrate http://code.google.com/p/pharo/issues/detail?id=3091 Stef > Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 > > The patch works for me, Thank you Igor. > > Cheers, > -- Pavel > > On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > > Sig, > > > > Have you thought about using a Mutex? Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are wonderful for #wait/#signal. But for #critical:, I use Mutex which won't deadlock a thread with itself. > > > > yes, i thought about it. It wont help in this situation, > because if you start modifying dictionary inside a loop, which > scanning its elements (like #do:) > you'll have very unpleasant results. > > All HostSystemMenusProxy doing during #finalize is removing itself > from weakregistry (which is complete nonsense, since weak registry > cleaning itself from dead stuff anyways). > So, > self protected: [ > valueDictionary expiredValuesDo: [:finItem | > finItem finalizeValues ]. > ]. > > actually triggers a bug/mistake in HostSystemMenusProxy , which leads > to deadlock. > :) > > > Bill > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > > Sent: Sunday, October 10, 2010 7:56 AM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] 12186 image quit problem > > > > OKay, now i see what the problem: > > > > <weak registry protected> > > <finalize items> > > <HostSystemMenusProxy>>finalize> > > .... > > <HostSystemMenusProxy class>>unregister> > > <weak registry protected> > > > > > > In my WeakRegistry, a #finalize message sent while registry semaphore locked, > > so, in case if object in #finalize trying to manipulate with registry > > then it going to deadlock. > > > > Then following piece: > > > > WeakRegistry>>finalizeValues > > > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | > > finItem finalizeValues ]. > > ]. > > > > should be rewritten as: > > > > | expired | > > expired := OrderedCollection new. > > self protected: [ > > valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] > > ]. > > expired do: #finalizeValues. > > > > > > But either way, HostSystemMenusProxy should not attempt remove itself > > from registry during #finalize (and causing a deadlock), > > since its pointless. > > > > > > -- > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Oct. 11, 2010

personnally I do not like this form What does it do? > process ifNotNil: #terminate. for me it means passes the symbol #terminate as argument to the method ifNotNil: If it has a more magical behavior then I do not know it. Stef > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > > cheers > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 4

Oct. 11, 2010

> > > ? > In any way, passing anything else than block literal as argument should work. You mean in the implementation or in the semantics? Read my mail. This is a question of semantics. The argument of iftrue:ifFalse: are thunk (piece of code with frozen execution). > This is smalltalk, not C with static types. consistency and elegance as nothing to do with absence of static types. With such a change we can break a lot of uniformity and break potential type inferencers. And I do not see the advantage, beside having a clunky system. Stef

1 0