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

Re: [Pharo-project] FreeType and finalization

by StÃ©phane Ducasse

thanks! On Oct 12, 2010, at 7:08 PM, Igor Stasenko wrote: > In Pharo-INBOX > > Name: FreeType-Igor_Stasenko.536 > Author: Igor.Stasenko > Time: 12 October 2010, 8:07:50 pm > UUID: fa9746fa-e253-7948-8bab-799ea9fba754 > Ancestors: FreeType-StephaneDucasse.535 > > - removed weak registry subclass, > but preserving the same semantics as before (guard against duplicating handles) > > On 12 October 2010 18:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> yes >> >> >> On Oct 12, 2010, at 4:51 PM, Gary Chambers wrote: >> >>> Is in core now I believe. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, October 12, 2010 2:29 PM >>> Subject: Re: [Pharo-project] FreeType and finalization >>> >>> >>>> I can modify Freetype to not use subclass of weakregistry, >>>> and still guarantee non-duplication. >>>> Is Freetype a separate maintained package, or its part of Pharo core? >>>> >>>> >>>> On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >>>>> Indeed... never seen that error hence proposal for simplest solution. >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Tuesday, October 12, 2010 1:21 PM >>>>> Subject: Re: [Pharo-project] FreeType and finalization >>>>> >>>>> >>>>>> 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. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> _______________________________________________ >> 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

Oct. 12, 2010

[Pharo-project] modal windows and unit tests

by Alexandre Bergel

Hi! A modal window is pop up by one of my tests. Is there a way to capture this situation and simply remove the modal window? Apparently, no notification is raised... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 12, 2010

Re: [Pharo-project] Pharo by Example has moved to github

by StÃ©phane Ducasse

Damien we can create an inria project like that we do not rely on external infrastructure. This will be good for us anyway. Stef On Oct 12, 2010, at 6:41 PM, Damien Pollet wrote: > On Mon, Oct 11, 2010 at 17:25, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>> Excellent, can I also push the Seaside Book there? > > Just a heads upâ¦ with all the translations we are already using 2/3 of > the space for a free account :) > >> If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server >> because I know that this is backup by someboyd else than me. > > It shouldn't be too hard to mirror the github repos to git-enabled > project on the gforge. > I just have to check how post-commit hooks workâ¦ > >> and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). > > With SVN, forking is a technical issue (and a tough one because it's > difficult to merge back). > With Git, forking is a political issue, which it should be (and an > easy one because you just have to be clean which repo is the official > one). > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > 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

[Pharo-project] Xtreams files

by Nicolas Cellier

I added a hook to Xtreams files this evening. The hook by now is in FileDirectory (no comment... I'll be happy when a replacement is integrated in Squeak/Pharo). ((FileDirectory default / 'toto.txt') writing encoding: #ascii) write: 'hello world'; close. ((FileDirectory default / 'toto.txt') reading encoding: #ascii) rest. I didn't hook into StandardFileStream, but rather a simplified version of David Lewis IOHandle. I separated this stuff in Xtreams-SqueakExternals. Anyway, this is not really related to Xtreams, most of the functionality should be in core (apart reading/writing/appending which might better return in Xtreams-Terminals). I also slighlty modified XTFileReadStream and XTFileWriteStream to fit some Squeak specific API. Maybe I could have just used the VW API and provide compatibility layer... We'll see later. Nicolas

Oct. 12, 2010

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

by Eliot Miranda

On Tue, Oct 12, 2010 at 4:48 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > I do. > and so do Levente and myself, at least in trunk. > > 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] FreeType and finalization

by Igor Stasenko

In Pharo-INBOX Name: FreeType-Igor_Stasenko.536 Author: Igor.Stasenko Time: 12 October 2010, 8:07:50 pm UUID: fa9746fa-e253-7948-8bab-799ea9fba754 Ancestors: FreeType-StephaneDucasse.535 - removed weak registry subclass, but preserving the same semantics as before (guard against duplicating handles) On 12 October 2010 18:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > yes > > > On Oct 12, 2010, at 4:51 PM, Gary Chambers wrote: > >> Is in core now I believe. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, October 12, 2010 2:29 PM >> Subject: Re: [Pharo-project] FreeType and finalization >> >> >>> I can modify Freetype to not use subclass of weakregistry, >>> and still guarantee non-duplication. >>> Is Freetype a separate maintained package, or its part of Pharo core? >>> >>> >>> On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >>>> Indeed... never seen that error hence proposal for simplest solution. >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Tuesday, October 12, 2010 1:21 PM >>>> Subject: Re: [Pharo-project] FreeType and finalization >>>> >>>> >>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > 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] Pharo by Example has moved to github

by Damien Pollet

On Mon, Oct 11, 2010 at 17:25, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Excellent, can I also push the Seaside Book there? Just a heads upâ¦ with all the translations we are already using 2/3 of the space for a free account :) > If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server > because I know that this is backup by someboyd else than me. It shouldn't be too hard to mirror the github repos to git-enabled project on the gforge. I just have to check how post-commit hooks workâ¦ > and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). With SVN, forking is a technical issue (and a tough one because it's difficult to merge back). With Git, forking is a political issue, which it should be (and an easy one because you just have to be clean which repo is the official one). -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by Sven Van Caekenberghe

On 12 Oct 2010, at 16:29, mkobetic(a)gmail.com wrote: > "Levente Uzonyi"<leves(a)elte.hu> wrote: >> Okay, I really tracked down the cause of the problem. The tests perform >> simple producer-consumer scenarios, but the consumers won't wait at all. >> If there's nothing to consume, the test fails. The randomness come from >> the scheduler. The server process is started first, the client is the >> second. If the server process can produce enough input to the client >> process the test will pass. >> If you decrease the priority of the client process by one in >> #timeout:server:client:, the randomness will be gone and the tests will >> reliably pass, because the client won't be able to starve the server. To >> avoid false timeouts I had to increase the timeout value to 2000 >> milliseconds using SqueakVM. > > An alternative solution I was thinking about would be to dispense with the processes in default case and simply run the server and client blocks sequentially. The cases where we really need the processes are channels with limited capacity (e.g. Socket or Pipe) where the writer needs to be able to block (when the OS buffers fill up) and let the reader consume some of the output before it continues writing. In these cases there aren't any shared resources so process contention should not be an issue. The other advantage would be that cases with the default behavior would be easier to debug and would not be subject to timeouts. As it is I still get timeouts sporadically even when it's set to 1 second. Yes, having strangely behaving unit tests is really annoying, especially when all this process stuff would not really be needed. >> I also found an issue: the process in XTTransformWriteStream doesn't >> terminate. If you run the tests, you'll get 12 lingering processes. > > I don't see that happening in Pharo 1.1. Normally the process should end normally when the stream is closed (the close synchronizes with the process via the closeReady semaphore). Maybe there's a missing close somewhere in the test suite ? I have these hanging processes as well (you probably know that the Process Browser does not auto update by default ?), I've never seen unit tests that did that... > _______________________________________________ > 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] FreeType and finalization

by StÃ©phane Ducasse

yes On Oct 12, 2010, at 4:51 PM, Gary Chambers wrote: > Is in core now I believe. > > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, October 12, 2010 2:29 PM > Subject: Re: [Pharo-project] FreeType and finalization > > >> I can modify Freetype to not use subclass of weakregistry, >> and still guarantee non-duplication. >> Is Freetype a separate maintained package, or its part of Pharo core? >> >> >> On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >>> Indeed... never seen that error hence proposal for simplest solution. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, October 12, 2010 1:21 PM >>> Subject: Re: [Pharo-project] FreeType and finalization >>> >>> >>>> 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. >>>> >>>> _______________________________________________ >>>> 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

Oct. 12, 2010

[Pharo-project] [ANN] Opal Digest

by StÃ©phane Ducasse

==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.47 Author: MarcusDenker Time: 7 October 2010, 10:10:56 am UUID: eabd712c-a974-4416-9551-e210d85b6949 Ancestors: OpalCompiler-Core-JorgeRessia.46 -> Pass over ASTTranslator to make the effect (after) vs. value visiting more correct. More tests are green. -> Cleanups ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.48 Author: MarcusDenker Time: 12 October 2010, 10:14 am UUID: 53fb460f-935c-4dd7-87df-92b9c77eb1f4 Ancestors: OpalCompiler-Tests-MarcusDenker.47 for now, remove OCCompilationEquivalencyTest ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.48 Author: MarcusDenker Time: 12 October 2010, 10:15:08 am UUID: f26101a1-d417-47c7-ab02-4974f0a15c93 Ancestors: OpalCompiler-Core-MarcusDenker.47 - some simplifications (eg remove compiledMethod...Using: methods from bc builder and iRBuilder) - cleanups - some fixes/hacks to make more tests green. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.49 Author: MarcusDenker Time: 12 October 2010, 4:06:20 pm UUID: 21e13b3b-418a-404c-9405-9438b939a7a7 Ancestors: OpalCompiler-Core-MarcusDenker.48 - ASTTranslator: now #acceptBlockNode is responsible for pushing nil on empty bloks - ASTTranslator: simplify #acceptSequenceNode ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.49 Author: MarcusDenker Time: 12 October 2010, 4:09:30 pm UUID: 9a662177-0e87-49fc-9cc3-475a6678f4f5 Ancestors: OpalCompiler-Tests-MarcusDenker.48 - started to merge OCSpecialVariableCases with OCOpalCompilerExamples - removed all #expectedTestfailures (e.g. FFI related tests are just skipped when FFI not installed) - add ASTTranslator test for exampleToDoInsideTemp and testExampleToDoInsideTempNotInlined - added testPushArray and testTodoValue (and example methods) - test initialize class side of BytecodeGenerator

Oct. 12, 2010

Re: [Pharo-project] FreeType and finalization

by Gary Chambers

Is in core now I believe. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, October 12, 2010 2:29 PM Subject: Re: [Pharo-project] FreeType and finalization >I can modify Freetype to not use subclass of weakregistry, > and still guarantee non-duplication. > Is Freetype a separate maintained package, or its part of Pharo core? > > > On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >> Indeed... never seen that error hence proposal for simplest solution. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, October 12, 2010 1:21 PM >> Subject: Re: [Pharo-project] FreeType and finalization >> >> >>> 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. >>> >>> _______________________________________________ >>> 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

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] How about atomic value-swap bytecode?

by Lukas Renggli

>>> But since its non-atomic, a process can be interrupted and such operation >>> is not thread-safe. >> >> As far as I know the VM only preempts on back-jumps and message sends. >> None of that exists in your code snipped, so it should be atomic. No? >> > > This is a bit blurry. I remember Eliot said it is no longer true under Cog VM. Then let's just pray that the method comment of Semaphore>>#critical: is outdated and the implementation is fixed. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave

by mkobetic＠gmail.com

"Levente Uzonyi"<leves(a)elte.hu> wrote: > Okay, I really tracked down the cause of the problem. The tests perform > simple producer-consumer scenarios, but the consumers won't wait at all. > If there's nothing to consume, the test fails. The randomness come from > the scheduler. The server process is started first, the client is the > second. If the server process can produce enough input to the client > process the test will pass. > If you decrease the priority of the client process by one in > #timeout:server:client:, the randomness will be gone and the tests will > reliably pass, because the client won't be able to starve the server. To > avoid false timeouts I had to increase the timeout value to 2000 > milliseconds using SqueakVM. An alternative solution I was thinking about would be to dispense with the processes in default case and simply run the server and client blocks sequentially. The cases where we really need the processes are channels with limited capacity (e.g. Socket or Pipe) where the writer needs to be able to block (when the OS buffers fill up) and let the reader consume some of the output before it continues writing. In these cases there aren't any shared resources so process contention should not be an issue. The other advantage would be that cases with the default behavior would be easier to debug and would not be subject to timeouts. As it is I still get timeouts sporadically even when it's set to 1 second. > I also found an issue: the process in XTTransformWriteStream doesn't > terminate. If you run the tests, you'll get 12 lingering processes. I don't see that happening in Pharo 1.1. Normally the process should end normally when the stream is closed (the close synchronizes with the process via the closeReady semaphore). Maybe there's a missing close somewhere in the test suite ?

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] How about atomic value-swap bytecode?

by Igor Stasenko

On 12 October 2010 17:07, Lukas Renggli <renggli(a)gmail.com> wrote: >> To swap two values, you usually do: >> >> | var1 var2 temp | >> >> temp := var1. >> var1 := var2. >> var2 := temp. >> >> But since its non-atomic, a process can be interrupted and such operation >> is not thread-safe. > > As far as I know the VM only preempts on back-jumps and message sends. > None of that exists in your code snipped, so it should be atomic. No? > This is a bit blurry. I remember Eliot said it is no longer true under Cog VM. > Lukas > > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] How about atomic value-swap bytecode?

by Lukas Renggli

> To swap two values, you usually do: > > | var1 var2 temp | > > temp := var1. > var1 := var2. > var2 := temp. > > But since its non-atomic, a process can be interrupted and such operation > is not thread-safe. As far as I know the VM only preempts on back-jumps and message sends. None of that exists in your code snipped, so it should be atomic. No? Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?

by Igor Stasenko

On 12 October 2010 16:51, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 12 Oct 2010, Igor Stasenko wrote: > >> Hello, i just thought, that it would be cool to have a special bytecode, >> which guarantees atomicity for swapping values between two variables. >> >> To swap two values, you usually do: >> >> | var1 var2 temp | >> >> temp := var1. >> var1 := var2. >> var2 := temp. >> >> But since its non-atomic, a process can be interrupted and such operation >> is not thread-safe. >> >> In order to make it thread safe, you must add even more boilerplate: >> >> | var1 var2 temp | >> >> semaphore critical: [ >> Â temp := var1. >> Â var1 := var2. >> Â var2 := temp. >> ] > > An alternative solution: > > | a b | > a := 1. > b := 2. > [ > Â Â Â Â | tmp | > Â Â Â Â tmp := a. > Â Â Â Â a := b. > Â Â Â Â b := tmp ] valueUnpreemptively > Yeah, another boilerplate under the hood, also highly dependent from scheduling nuances :) valueUnpreemptively "Evaluate the receiver (block), without the possibility of preemption by higher priority processes. Use this facility VERY sparingly!" "Think about using Block>>valueUninterruptably first, and think about using Semaphore>>critical: before that, and think about redesigning your application even before that! After you've done all that thinking, go right ahead and use it..." | activeProcess oldPriority result | activeProcess := Processor activeProcess. oldPriority := activeProcess priority. activeProcess priority: Processor highestPriority. result := self ensure: [activeProcess priority: oldPriority]. "Yield after restoring priority to give the preempted processes a chance to run" Processor yield. ^result > > Levente > -- Best regards, Igor Stasenko AKA sig.

Oct. 12, 2010

Re: [Pharo-project] How about atomic value-swap bytecode?

by Levente Uzonyi

On Tue, 12 Oct 2010, Igor Stasenko wrote: > Hello, i just thought, that it would be cool to have a special bytecode, > which guarantees atomicity for swapping values between two variables. > > To swap two values, you usually do: > > | var1 var2 temp | > > temp := var1. > var1 := var2. > var2 := temp. > > But since its non-atomic, a process can be interrupted and such operation > is not thread-safe. > > In order to make it thread safe, you must add even more boilerplate: > > | var1 var2 temp | > > semaphore critical: [ > temp := var1. > var1 := var2. > var2 := temp. > ] An alternative solution: | a b | a := 1. b := 2. [ | tmp | tmp := a. a := b. b := tmp ] valueUnpreemptively Levente > > So, i thought , if we could have a special bytecode, then we could > write something like: > > | var1 var2 | > > var1 :=: var2. > > So, VM will guarantee that values of var1 and var2 will be swapped > atomically, and completely thread-safe. > > var1 and var2 could be either temps or instance variables, but of > course not arguments, since they are not assignable. > > One thing i don't like, that it will need to introduce a new syntax > for atomic-value-swap operator - :=: > > Or, maybe just reserve a special keyword selector (which is recognized > by compiler), so > > var1 __atomicSwapWith: var2 > > so it will look like a regular smalltalk syntax, except that its not a > message send, but a low-level operation instead. > > > -- > 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 >

Oct. 12, 2010

Re: [Pharo-project] Learning by download all the mcz files from a repository

by HwaJong Oh

Hi, Alex. sorry for late reply i've been busy could not have time to review Ecco. I have a small question, I can find Ecco is treating 'Seaside' package special than other ones. Does it have some purpose? Have a good one HwaJong Oh -- View this message in context: http://forum.world.st/Learning-by-download-all-the-mcz-files-from-a-reposit… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 12, 2010

Re: [Pharo-project] FreeType and finalization

by Igor Stasenko

I can modify Freetype to not use subclass of weakregistry, and still guarantee non-duplication. Is Freetype a separate maintained package, or its part of Pharo core? On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Indeed... never seen that error hence proposal for simplest solution. > > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, October 12, 2010 1:21 PM > Subject: Re: [Pharo-project] FreeType and finalization > > >> 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. >> >> _______________________________________________ >> 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.

Oct. 12, 2010

Re: [Pharo-project] FreeType and finalization

by Gary Chambers

Indeed... never seen that error hence proposal for simplest solution. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, October 12, 2010 1:21 PM Subject: Re: [Pharo-project] FreeType and finalization > 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. > > _______________________________________________ > 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

[Pharo-project] How about atomic value-swap bytecode?

by Igor Stasenko

Hello, i just thought, that it would be cool to have a special bytecode, which guarantees atomicity for swapping values between two variables. To swap two values, you usually do: | var1 var2 temp | temp := var1. var1 := var2. var2 := temp. But since its non-atomic, a process can be interrupted and such operation is not thread-safe. In order to make it thread safe, you must add even more boilerplate: | var1 var2 temp | semaphore critical: [ temp := var1. var1 := var2. var2 := temp. ] So, i thought , if we could have a special bytecode, then we could write something like: | var1 var2 | var1 :=: var2. So, VM will guarantee that values of var1 and var2 will be swapped atomically, and completely thread-safe. var1 and var2 could be either temps or instance variables, but of course not arguments, since they are not assignable. One thing i don't like, that it will need to introduce a new syntax for atomic-value-swap operator - :=: Or, maybe just reserve a special keyword selector (which is recognized by compiler), so var1 __atomicSwapWith: var2 so it will look like a regular smalltalk syntax, except that its not a message send, but a low-level operation instead. -- Best regards, Igor Stasenko AKA sig.

Oct. 12, 2010

Re: [Pharo-project] Adding a new font in System like DejaVu fonts

by Juan Vuletich

Henrik Johansen wrote: > > On Oct 10, 2010, at 12:49 40PM, nullPointer wrote: > >> >> Now I know is possible add a new font, for use cross platform like >> DejaVu. I >> know Juan Vuletich did that but I donÂ´t know found the place of that is >> explained. Is heard do that? > > Whuups, might've sent you in a wild goose chase, sorry :/ > > Was thinking > of http://forum.world.st/DemoMode-should-not-change-Fonts-only-sizes-td2538706… , > which I interpreted as linking to a description of how he builds the > font source. > Clearly that only includes the end result ready for import. > > Anyways, as can be seen from the AAFonts.zip, you basically need a bmp > with the font glyphs, as well as a text file containing offsets for > each character. > You could achieve that through printscreen and manual creation of > offsets txt, or using a more automated tool similar to f.ex. > http://www.angelcode.com/products/bmfont/ . > > CC'ing Juan in case he has time to comment on what his process is > specifically. I just used a few Smalltalk scripts that find glyph boundaries using the various pixel tally methods. Cheers, Juan Vuletich >> takes very space of image when the font is >> added? > > About as much space as the bmp's, ie depends on what sizes you want to > include. > > Cheers, > Henry >

Oct. 12, 2010

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