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

[Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations
by Hernan Wilkinson Oct. 13, 2010

Oct. 13, 2010

Hi, I added an issue (an enhancement really) and also uploaded the code for it. The enhancement is that when you press "Create" on the debugger, it would be nice if the generated method could realize that the message is a getter or setter and provide an implementation accordingly. I also refactor the method #createMethodStub in Message. To do so I create the class DynamicMessageImplementor and its test DynamiMessageImplementorTest. I hope you like it! Hernan. -- * HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/> *

1 0

[Pharo-project] [update 1.2] #12193
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

12193 ----- - Issue 3096: FreeType problem with new finalization. Thanks Igor Stasenko. - Issue 2999: Object>>isConflict. Moving isConflict from Object to MCPacthOperation. - Issue 3085: StringHolder should not be in Kernel Stef

1 0

[Pharo-project] Code annotations? Why they broken again?
by Igor Stasenko Oct. 12, 2010

Oct. 12, 2010

Hello, i just found that annotation panes is not updating in latest pharo. Digging through it , i found that it no longer receives #annotation notification (through #update:) but #contents instead. Fix already in inbox, see issue #3098 P.S. Is it only me, stubborn one, who using annotation panes among pharoers, that nobody else noticed it? -- Best regards, Igor Stasenko AKA sig.

1 0

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

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

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