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

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