- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FreeType and finalization
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

1 0

Re: [Pharo-project] Pharo by Example has moved to github
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

1 0

[Pharo-project] Xtreams files
by Nicolas Cellier Oct. 12, 2010

Oct. 12, 2010

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

1 0

[Pharo-project] who is maintaining shout?
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

Stef

4 4

Re: [Pharo-project] FreeType and finalization
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

2 1

Re: [Pharo-project] Pharo by Example has moved to github
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

> Excellent, can I also push the Seaside Book there? 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. 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). > > The main data store remains Pier of course, but we already today keep > the backups and other resources in the SCG SVN. > > Lukas > > > > On 11 October 2010 17:06, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> Great Oscar ! How to join the SquareBracketAssociates ? >> >> >> On Mon, Oct 11, 2010 at 4:39 PM, Oscar Nierstrasz >> <oscar.nierstrasz(a)gmail.com> wrote: >>> >>> See: http://github.com/SquareBracketAssociates/ >>> >>> Cheers, >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> 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

3 2

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

Oct. 12, 2010

"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 ?

2 1

Oct. 12, 2010

==================== 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

1 0

[Pharo-project] FreeType and finalization
by Gary Chambers Oct. 12, 2010

Oct. 12, 2010

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

2 4

[Pharo-project] Learning by download all the mcz files from a repository
by HwaJong Oh Oct. 12, 2010

Oct. 12, 2010

I plan to study history of Metacello. For that I came up with an idea, what if i download all the mcz in the metacello repository on squeaksource. Then sort them by commit time stamp. installing very first version of Metacello to last version of Metacello-Help. Every moment of installation, see the difference by clicking "Changes" button of monticello browser. By doing it, i can grasp the idea, the indents of version and understand how the design has been changed and know the direction of change. What do you think of this idea? -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.

4 7