- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Collaboractive book chapter 10

by Alexandre Bergel

Patricio, Apparently there is some room for writing your experience on OpenGl and Pharo. Cheers, Alexandre On 12 Oct 2010, at 06:27, Simon Denier wrote: > > I did a large pass to reorganize stuff around so that it gets more consistent, starting with basic stuff and advancing towards the more technical stuff. > > Chapters "How to contribute" and "3D Graphics and OpenGL" are nearly empty > > > On 12 oct. 2010, at 10:20, Simon Denier wrote: > >> I'm fixing ordering in book chapters >> >> For some reasons, two chapters (Customizing Pharo and Pharo Tools) were created as children of Table-Of-Contents, and they pushed everything down. >> >> Also I notice that a figure was created as a child of Table-Of-Figures, I have no idea where it should go >> http://book.pharo-project.org/book/table-of-figures/RepositoryEnvironment >> >> >> On 12 oct. 2010, at 09:07, Norbert Hartl wrote: >> >>> I just had a look at the book and wondered why the chapter introduction is chapter 10. Looks like it is supposed to be 1 or 2 >>> >>> Norbert >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Simon >> >> >> > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2010

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

by Igor Stasenko

On 12 October 2010 15:33, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Oct 12, 2010, at 2:00 42PM, Igor Stasenko wrote: > >> 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'. > > At which point I'd go "Fix the damn handlers in the finalize method" rather than add more indirection ;) KISS. > You still have to write the handling if you do encounter an error, whether that initial error is #dnu handleFinalizationError:, or the actual error is of little consequence. > What we want away from, is the default case now where an unhandled error is assumed to be inconsequential and simply skipped over by default > >> >> >>> 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 :) > How about something like: (warning, untested code) > > WeakArray >> finalizationProcess > > Â Â Â Â ^[[[true] whileTrue: > Â Â Â Â Â Â Â Â [FinalizationSemaphore wait. > Â Â Â Â Â Â Â Â FinalizationLock critical: > Â Â Â Â Â Â Â Â Â Â Â Â [FinalizationDependents do: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [:weakDependent | > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â weakDependent ifNotNil: > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [weakDependent finalizeValues]]]]] > Â Â Â Â Â Â Â Â ifCurtailed: [self startFinalizationProcess]] newProcess priority: Â Processor userInterruptPriority > > WeakArray >>startFinalizationProcess > > > Â Â Â Â FinalizationSemaphore := Smalltalk specialObjectsArray at: 42. > Â Â Â Â FinalizationDependents ifNil: [FinalizationDependents := WeakArray new: 10]. > Â Â Â Â FinalizationLock := Semaphore forMutualExclusion. > Â Â Â Â FinalizationProcess := self finalizationProcess. > Â Â Â Â FinalizationProcess resume > > WeakArray >>restartFinalizationProcess > Â Â Â Â "Killing the current Finalization process will start a new one" > Â Â Â Â FinalizationProcess terminate > > WeakRegistry finalizeValues: > > snip > self finalize: finiObjects > > WeakArray >> finalize: finalizationObjects > Â Â Â Â [[finalizationObjects isEmpty] > Â Â Â Â Â Â Â Â whileFalse: [finalizationObjects removeFirst finalize]] > Â Â Â Â Â Â Â Â on: Error > Â Â Â Â Â Â Â Â do: [:error | > Â Â Â Â Â Â Â Â Â Â Â Â self finalize: (finalizationObjects). > Â Â Â Â Â Â Â Â Â Â Â Â error pass]. > > The last has some issues of course, if more than one error is encountered, the first ones won't be passed if the last ones are terminated. > Changing it to fork of the error block would mean having to change finalizationObjects to something that is threadsafe rather than OrderedCollection though. > With new finalization, i got a list of finalizers i.e first -> next -> next lists is much easier to manipulate in thread-safe manner. But i still have to care about old ways... pfff :) > 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] Another finalization concern: error handling

by Henrik Johansen

On Oct 12, 2010, at 2:00 42PM, Igor Stasenko wrote: > 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'. At which point I'd go "Fix the damn handlers in the finalize method" rather than add more indirection ;) KISS. You still have to write the handling if you do encounter an error, whether that initial error is #dnu handleFinalizationError:, or the actual error is of little consequence. What we want away from, is the default case now where an unhandled error is assumed to be inconsequential and simply skipped over by default > > >> 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 :) How about something like: (warning, untested code) WeakArray >> finalizationProcess ^[[[true] whileTrue: [FinalizationSemaphore wait. FinalizationLock critical: [FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]]]] ifCurtailed: [self startFinalizationProcess]] newProcess priority: Processor userInterruptPriority WeakArray >>startFinalizationProcess FinalizationSemaphore := Smalltalk specialObjectsArray at: 42. FinalizationDependents ifNil: [FinalizationDependents := WeakArray new: 10]. FinalizationLock := Semaphore forMutualExclusion. FinalizationProcess := self finalizationProcess. FinalizationProcess resume WeakArray >>restartFinalizationProcess "Killing the current Finalization process will start a new one" FinalizationProcess terminate WeakRegistry finalizeValues: snip self finalize: finiObjects WeakArray >> finalize: finalizationObjects [[finalizationObjects isEmpty] whileFalse: [finalizationObjects removeFirst finalize]] on: Error do: [:error | self finalize: (finalizationObjects). error pass]. The last has some issues of course, if more than one error is encountered, the first ones won't be passed if the last ones are terminated. Changing it to fork of the error block would mean having to change finalizationObjects to something that is threadsafe rather than OrderedCollection though. Cheers, Henry

Oct. 12, 2010

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