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

Re: [Pharo-project] FreeType and finalization

by Igor Stasenko

2010/10/12 Gary Chambers <gazzaguru2(a)btinternet.com>: > Hi all, I've encountered a problem with FreeType with respect to the new > finalization scheme. > http://code.google.com/p/pharo/issues/detail?id=3096 > Regards, Gary > FT2HandleRegistry overrides following method: add: anObject "Add anObject to the receiver. Store the object as well as the associated executor." | executor dup | executor := anObject executor. dup := nil. self protected:[ dup := valueDictionary detect: [ :v | v handle = executor handle ] ifNone: [ ]. valueDictionary at: anObject put: executor. ]. dup ifNotNil: [ self error: 'Duplicate object added!'. self remove: anObject ]. ^anObject As i see, the intent is to prevent registering a same handle twice, so in own turn, when time will come, a #finalize won't attempt to destroy same handle twice. The proposed fix (as you wrote in issue tracker) registry ^Registry ifNil: [ Registry := WeakRegistry new] appears to fix the problem... But apparently its not the same as in original. Okay, but since we never seen the error: 'Duplicate object added!', then i think it may work without it :) Still, it would be good to know, how handles are created, and what the chances that they could be duplicated. -- Best regards, Igor Stasenko AKA sig.

Oct. 12, 2010

Re: [Pharo-project] who is maintaining shout?

by Lukas Renggli

The code is in the official repository: http://www.squeaksource.com/shout.html On 12 October 2010 14:02, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Am 2010-10-12 um 13:48 schrieb Lukas Renggli: >> I do. >> >> 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> Stef > > Do y'all mean generally or for Pharo? > > So Long, > Â Â Â Â -Tobias > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

Re: [Pharo-project] who is maintaining shout?

by Lukas Renggli

I closed the issue. On 12 October 2010 14:01, Lukas Renggli <renggli(a)gmail.com> wrote: > I integrated this during ESUG. > > Lukas > > On 12 October 2010 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> ok can you have a look at issue 1611 because now we can have an interface to define the color apparently. >> >> Stef >> >> On Oct 12, 2010, at 1:49 PM, Lukas Renggli wrote: >> >>> I do. >>> >>> 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> Stef >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

Re: [Pharo-project] who is maintaining shout?

by Tobias Pape

Am 2010-10-12 um 13:48 schrieb Lukas Renggli: > I do. > > 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Stef Do y'all mean generally or for Pharo? So Long, -Tobias

Oct. 12, 2010

Re: [Pharo-project] who is maintaining shout?

by Lukas Renggli

I integrated this during ESUG. Lukas On 12 October 2010 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > ok can you have a look at issue 1611 because now we can have an interface to define the color apparently. > > Stef > > On Oct 12, 2010, at 1:49 PM, Lukas Renggli wrote: > >> I do. >> >> 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 12 October 2010 14:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 11, 2010, at 10:17 18PM, Igor Stasenko wrote: > >> On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> The most important words in there are "critical section." Â Carry on :) >>> >> >> Oh, please. This is not too hard to code. >> >> My mind rolling around following choice(s) Â (there may be others i don't see). >> What would be a proper way to handle error during #finalize. >> >> [ executor finalize ] on: Error do: [:ex | >> Â self handleFinalizationError: ex Â "where self is registry" >> ]. >> >> or: >> >> [ executor finalize ] on: Error do: [:ex | >> Â executor handleFinalizationError: ex >> ]. >> >> >> of course, i should catch this error in test, so i can verify that: >> >> a) test is get notified upon synthetically made error >> b) no matter what i do inside error handler (up to 'Processor >> activeProcess terminate'), a finalization process continues working >> (or restarts without losing remainder of executors). >> > > I agree it should be the executor doing handling. > However, if you get to this point, the executor already had the chance to do so in the finalize method itself, so I don't really see the point of sending it back.. > well, its easier to add a default error handler in Object class, so any executor will have a default handler, and then some specific one may choose to override it, without putting a boilerplate of [ ] on: .. do: [] in every #finalize method. Besides, its natural , when you writing a code, you always expect that it will work w/o errors, and even if it fails, then in some concrete place, which means you usually not wrapping whole thing with exception handler. This leaves a chance to make another mistakes, like 'hey, despite i put error handler in my #finalize, something is still hangs finalization process'. > Personally, I feel the only promises FinalizationRegistry should make wrt. to errors during finalization, is it should never lead to: > - termination of the (or a) finalization process, > - discarding another finalization action. > Yes this is the main intent. > IE I am perfectly fine with an error here being thrown in your face (hopefully in a somewhat debuggable way, unlike what happened in your first example when removing the error-swallowing), as you've already passed the point a correction should be made, and there's nothing more intelligible to do than making sure everything keeps working, and inform of the error. > (Pretty sure the error swallowing was a quick hack for keeping everything working in the first place ;) ) > What i like in doing #finalize in forked process, that it doesn't matter where you screwed up: in finalization code or even in error handling code, you still don't have a chance to damage the system. And moreover, you can open debugger and debug it. Spice must flooow :) > Cheers, > Henry > _______________________________________________ > 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.

Oct. 12, 2010

Re: [Pharo-project] who is maintaining shout?

by StÃ©phane Ducasse

ok can you have a look at issue 1611 because now we can have an interface to define the color apparently. Stef On Oct 12, 2010, at 1:49 PM, Lukas Renggli wrote: > I do. > > 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 12, 2010

Re: [Pharo-project] who is maintaining shout?

by Lukas Renggli

I do. 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

[Pharo-project] FreeType and finalization

by Gary Chambers

Hi all, I've encountered a problem with FreeType with respect to the new finalization scheme. http://code.google.com/p/pharo/issues/detail?id=3096 Regards, Gary

Oct. 12, 2010

[Pharo-project] who is maintaining shout?

by StÃ©phane Ducasse

Stef

Oct. 12, 2010