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

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

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

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

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

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

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

Re: [Pharo-project] 12186 image quit problem
by Marcus Denker Oct. 11, 2010

Oct. 11, 2010

On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: > Hmm, this is the result for Linux and > cogvm 3.9-7 and pharovm 3.10-3 > > can you try: https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 30

[Pharo-project] Xtreams port to Squeak - second wave
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

Hi again, I now have ported two more packages - Xtreams-Transforms - Xtreams-Substreams and their tests I did not have any portability problem with those... But that's because I did not handle the Character encoder/decoder. Consequently, I have 8 tests failing (the Base64 related tests) Plus 4 other tests failing because of my poor implementation of #after:do: (forking processes in a SUnit TestCase can't be that obvious). Now, the easy part of the port (copy/paste) is almost ended. Once we manage a compatible way to handle pragmas, PEG Parser should port quite easily too. Then, the harder work begins: - File/Socket/Pipe - Pointers (in External Heap) - Character encoding/decoding - Compression/Decompression If you think you can help in any of these, please tell. Nicolas

3 2

[Pharo-project] bad bracket autocompletion in Pharo Core 1.2
by Guillermo Polito Oct. 11, 2010

Oct. 11, 2010

http://code.google.com/p/pharo/issues/detail?id=3069 if you type: [] -> []] () -> ()) {} -> {}} Bye!

4 6

Re: [Pharo-project] Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 11, 2010

Oct. 11, 2010

"Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) > - Character encoding/decoding I just published XtreamsDevelopment(387) with following changes: * abstracted Encoder out of encoded streams to allow implementing our own encodings. * Encoder.Encoders registers known encoders * Encoder.DialectEncoder provides a hook to access dialect specific encoders * added ASCIIEncoder implementing ASCII encoding portably * added VWEncoder wrapping VisualWorks StreamEncoders Obviously VWEncoder won't work in Squeak and should eventually move to a VW specific package. But at the moment it might be useful as an example of how to take advantage of the existing encoders in Squeak. I briefly looked at the Multilingual categories in Pharo and there seem to be quite a few encodings available through the TextConverter hierarchy. You've expressed some reservations about that, but it might be worth taking advantage of those at least initially. Anyway with the above there should be at least an #ascii encoder available for now.

1 0

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

Oct. 11, 2010

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 11 Oct 2010, Igor Stasenko wrote: > >> 2010/10/11 Levente Uzonyi <leves(a)elte.hu>: >> On Mon, 11 Oct 2010, Igor Stasenko wrote: >> >>> On 10 October 2010 23:43, Levente Uzonyi <leves(a)elte.hu> wrote: >>> On Sun, 10 Oct 2010, Igor Stasenko wrote: >>> >>>> 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 ] >>> >>> It's only an issue with the new WeakRegistry implementation, previous >>> implementations don't have such problem. I think changing the method as >>> you >>> suggested, implementing WeakFinalizerItem >> #discardFinalization as >>> "executor := nil" and changing WeakFinalizerItem >> #finalizaValues to >>> ignore the executor if it's nil will fix the problem. Am I right? >>> >>> I don't get how "multiple finalizers per object" is related to this >>> problem >>> at all. >>> >> >> No, you miss the point. >> When you removing object from weak registry, it is important , time to >> time to tell all of its executors, >> that they will no longer receive #finalize, because object is no >> longer a member of weak registry. >> >> If you simply set executor := nil, it does nothing, an executor itself >> did not notified that he won't be needed >> in any possible future. >> So, if your finalization action is to remove some object(s) from the >> list , you'll get your list dirty after object will die, >> because #finalize will be never sent to your executor. >> >> Here the simple test case: >> >> | coll obj someWrapper | >> coll := OrderedCollection new. >> obj := Object new. >> someWrapper := WeakArray with: obj. >> coll add: someWrapper. >> >> obj toFinalizeSend: #remove: to: coll with: someWrapper. >> obj finalizationRegistry remove: obj. >> obj := nil. >> Smalltalk garbageCollect. >> self assert: coll isEmpty >> >> >> the point is, that once you doing a #remove: , >> your finalization scheme is broken. >> >> >> I don't get you. When you remove an object from a WeakRegistry, you tell >> the >> system that you want the object removed and all related executors deleted. >> So the executors should never receive #finalize, they should be thrown >> away. >> Even if there's action to be done with the executors (which is pointless >> IMHO since those will be thrown away, but who knows), doing them is the >> responsibility of the sender of #remove:. >> > > Let us get back to multiple finalizers per object, > when you have two separate places, which adding possibly different > executors for a single object > without knowing about each other (otherwise why would you want to add > two finalizers instead of one). > Now if one decides to do #remove: , > how to ensure that second one won't be left with dirty/invalid state? > > > It's not ensured, and it doesn't have to be. The sender of #remove: takes > all responsibility. It can decide to add some executors back to the registry > if that's necessary. > If you want to keep your executors safe from some other code, which may > #remove: your objects from a WeakRegistry, then you can create a private > WeakRegistry and store your executors there, just like Sockets and > FileStreams do. > Conclusion: weak registry don't have to support multiple finalizers per single object. Instead, if one sees the need to control a finalization of certain object(s) in own way, indepentently fron any other, then he should use a private weak registry (like Sockets and FileStreams do), and register object and its executor there. -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [Pharo-project] Xtreams : first embryonary port on Squeak
by mkobetic＠gmail.com Oct. 11, 2010

Oct. 11, 2010

"Schwab,Wilhelm K"<bschwab(a)anest.ufl.edu> wrote: > FWIW, SIF might help you: > > http://www.pocketsmalltalk.com/sif/ > > I have put a lot of code through it in the past couple of years. I'd recommend giving the Monticello tools in VW a try before trying to put something together from lower level tools. It's used to keep Seaside in sync in VW, so it should handle most of the obvious obstacles. With the help of your Xtreams-VWCompatibility package on Squeak side and maybe some adjustments in the portable code and maybe moving some of the non-portable code into packages of their own, we should be able to make this largely automatic.

1 0

Oct. 10, 2010

On Oct 10, 2010, at 3:07 PM, Igor Stasenko wrote: > On 10 October 2010 15:39, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 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. >> > +1 > > i am also missing: > > someThing ifTrue: 1 ifFalse: 0 I hate this idea. Let the compiler doing optimizations and please do not mix implementation and language design. The ***semantics*** of iftrue: is to get a thunk (in scheme parlance) something whose evaluation is blocked. 1 is not that! Now the compiler could be smart and inline whatever. Stef

2 1