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

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

by Igor Stasenko

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). Also, i used #ensure: and #ifCurtailed: but i tend to forget where they are applicable and how. So, little help in this regard will be wellcome. > Bill > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

On Oct 11, 2010, at 5:25 PM, Nick Papoylias wrote: > > > On Mon, Oct 11, 2010 at 5:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > For example there currently exist a setter in the class side for 'migratting' in a new environment, that just alters the class knowledge about the new namespace and does not erase it's record from the old namespace. > where? > > Class>>environment: (as far as I understand the class changes it's environment, without erasing itself from the old one and adding itself to the new one) clearly a bug. Cna you open a ticket? if you could write a test it would be excellent. In fact this method was never build with multiple environment in mind :) > > Is this intented ? What is the underlying design ? Should we add an environment: setter in the subclass message, so that we integrate namespaces with the current Browser ? Should Behavior always return Smalltalk globals, or there should be a setter to be able to migrate a whole hierarchy of classes elsewhere ? > > Normally a class should be able to return its environment and it can be different to Smalltalk globals, for example > we want to have to environments so that we can load Opal in one to modify the other Opal compiler that we will running. > > Up to now marcus was using the old compiler to compile the new but in the future we only want one compiler and still been able to > change it. > > Stef > > > _______________________________________________ > 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. 11, 2010

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

by StÃ©phane Ducasse

Ok for me do the simplest thing for you. This was just a meta remark. Stef On Oct 11, 2010, at 5:32 PM, Lukas Renggli wrote: >>> 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 problem is that the sync with Pier does not work with SVN. You can > only update and backup by using Git with the SVN backend. > > 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

Oct. 11, 2010

Re: [Pharo-project] R: R: R: R: Problem with inspector

by Frederic Pluquet

Did you expand the category NewInspector and check the two first options ? See my attached screenshot. Once done, close the inspector and reopen it. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/11 morod <morod(a)tiscali.it> > Iâm sorry but something may be wrong. > > > > My Pharo.image > > > > > > NewInspector installed > > > > > > System settings > > > > I tried again and the result has not changed > > > > > > > > Thanks again for your patience > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Frederic > Pluquet > *Inviato:* lunedÃ¬ 11 ottobre 2010 00:23 > > *A:* Pharo-project(a)lists.gforge.inria.fr > *Oggetto:* Re: [Pharo-project] R: R: R: Problem with inspector > > > > It's really strange. It works perfectly here. > > > > Step by step: > > > > - Download the last image of Pharo > > - Go to Monticello and load the last package of NewInspector > > - Go to System > Settings > Debugging > NewInspector > > - Check the options > > - Open a new inspector on an object > > > > The new children must appear. > > > > FrÃ©d > > > > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > 2010/10/10 morod <morod(a)tiscali.it> > > Thanks for your interest, I have done what was suggested, but nothing has > changed. > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Frederic > Pluquet > *Inviato:* domenica 10 ottobre 2010 17:00 > > > *A:* Pharo-project(a)lists.gforge.inria.fr > > *Oggetto:* Re: [Pharo-project] R: R: Problem with inspector > > > > If you load the last version of NewInspector (posted this morning), you go > to the Settings Browser (System > Settings in the World menu), expand > "Debugging" > "NewInspector" and check the options you want. > > > > FrÃ©d > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > 2010/10/10 morod <morod(a)tiscali.it> > > Hello, > > > > How can I switch from the two different versions of tool âInspectorâ > > > > Best regards > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Frederic > Pluquet > *Inviato:* sabato 9 ottobre 2010 14:08 > > > *A:* Pharo-project(a)lists.gforge.inria.fr > > *Oggetto:* Re: [Pharo-project] R: Problem with inspector > > > > Hello, > > > > It's the NewInspector on both pictures but two different versions of this > tool. In the old version, the class and the methods were displayed for each > inspected object. In the current version, there are not displayed (because > the community prefers less children for each object). > > > > FrÃ©d > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > 2010/10/8 morod <morod(a)tiscali.it> > > Hi Mariano > > > > I tried it with multiple images and the behavior is the same with all the > images. > > > > Sent the sample is made with: > > Pharo-1.1-11411 > > Latest update: #11411 > > > > The first one is my image and the second is taken from the book âPharo by > Exampleâ > > > > Thanks again > > > > Morod > > > > *Da:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *Per conto di *Mariano > Martinez Peck > *Inviato:* venerdÃ¬ 8 ottobre 2010 21:43 > *A:* Pharo-project(a)lists.gforge.inria.fr > *Oggetto:* Re: [Pharo-project] Problem with inspector > > > > Hi morod, and welcome to Pharo! > > Which Pharo image are you exactly using? (the name of the zip, the image > file or go to System -> About) The first one is your image, right ? and > the second one? where is it from ? > > The difference is that the first image is using the "old" traditional > inspector, while the second picture is using another inspector, which is > called "NewInspector", which provides more information. > > Cheers > > Mariano > > 2010/10/8 morod <morod(a)tiscali.it> > > Hi > > iâm new to smalltalk and Pharo and my inspector show > > > > *Errore. Il nome file non Ã¨ specificato.* > > > > instead of > > > > *Errore. Il nome file non Ã¨ specificato.* > > Why? Thanks > > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > 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. 11, 2010

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

by Schwab,Wilhelm K

Sig, The most important words in there are "critical section." Carry on :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, October 11, 2010 2:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 21:07, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > As a friend here: when did I say I'd remove all? Remove and process one at a time. I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. > Removing and processing one at a time could do the job, but it will be very inefficient (especially on VMs which not support new finalization). Because: - you have to enter critical section for scanning valueDictionary - you then have to leave critical section for sending a single #finalize - then you should start over and look for next element with nil key (if any) So, as i said, devil in details. > Bill > -- 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. 11, 2010

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

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: >>> >>> These problems should be solved with the latest version of CoreTests. >>> >>> Levente >> >> Thanks! > > I just realized that sometimes the 100 ms timeout is not enough even on Cog > and the test fails, 200 ms works well. It typically happens when running > #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, to > make sure it doesn't fail with SqueakVM or on slower machines. > > > Levente > Just proceed (in http://www.squeaksource.com/Xtreams) if you want to.

Oct. 11, 2010

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

by Levente Uzonyi

On Mon, 11 Oct 2010, Igor Stasenko wrote: > On 11 October 2010 21:07, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > As a friend here: when did I say I'd remove all? Â Remove and process one at a time. Â I will admit to having a bias toward doing this with a single executor per object, but even if multiples turn out to have value (need to hunt down and read Levente's description of that), the same idea should apply. > Removing and processing one at a time could do the job, but it will be very inefficient (especially on VMs which not support new finalization). Because: - you have to enter critical section for scanning valueDictionary - you then have to leave critical section for sending a single #finalize - then you should start over and look for next element with nil key (if any) So, as i said, devil in details. You can select the executors to a collection and finalize them later, so you don't have to restart the scanning of valueDictionary. Levente > Bill > -- 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. 11, 2010

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

by Levente Uzonyi

On Mon, 11 Oct 2010, Nicolas Cellier wrote: > 2010/10/11 Levente Uzonyi <leves(a)elte.hu>: >> On Sun, 10 Oct 2010, mkobetic(a)gmail.com wrote: >> >>> Hi Nicolas, >>> >>> "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> Hi again, >>>> I now have ported two more packages >>>> - Xtreams-Transforms >>>> - Xtreams-Substreams >>>> and their tests >>> >>> This is great! I loaded your code into Pharo 1.1 and things seem to be >>> working quite well. There was a complaint about missing SharedQueue2, I just >>> created a dummy subclass of SharedQueue with that name and things seemed to >>> load fine. >>> XTRecyclingCenter seems to be subclass of XTWriteStream, it should be >>> Object subclass, maybe a typo ? >>> >>>> I did not have any portability problem with those... >>>> But that's because I did not handle the Character encoder/decoder. >>>> Consequently, I have 8 tests failing (the Base64 related tests) >>> >>> I was thinking, we could implement just 'encoding: #ascii' quite easily, >>> to make this reasonably usable at least for applications that are fine with >>> that. We're actually contemplating about implementing our own encoders for >>> Xtreams too. The VW ones are tied to the classic streams more than we like. >>> You might have noticed some rather hairy parts in the encoding streams >>> yourself, where we're trying to work around some of the issues it creates. >>> The advantage of reusing the existing encoders was that there are quite a >>> few of those available, so reimplementing all that would be a drag. But we >>> can come up with a scheme where we can reimplement at least the common ones >>> and in VW we can still preserve hooking into the old ones for the rest. I >>> can give that a try on VW side in the meantime so you could get those for >>> free. >>> >>>> Plus 4 other tests failing because of my poor implementation of >>>> #after:do: (forking processes in a SUnit TestCase can't be that >>>> obvious). >>> >>> I looked at this, and I think this is how #after:do: should look like: >>> >>> after: aDelay do: aBlock >>> Â Â Â Â "Evaluate the argument block delayed after the specified duration." >>> >>> Â Â Â Â | watchdog | >>> Â Â Â Â watchdog := [ >>> Â Â Â Â Â Â Â Â aDelay wait. >>> Â Â Â Â Â Â Â Â aBlock value. >>> Â Â Â Â ] newProcess. >>> Â Â Â Â watchdog priority: Processor userInterruptPriority. >>> Â Â Â Â watchdog resume. >>> >>> This would assume that the 2 tests calling #timeout:server:client: would >>> use a Delay instance instead of a Duration, which I'd be fine with. However >>> making that change doesn't quite get the tests running. It's blowing up with >>> a DNU on the 'output close' bit in #terminate:server:client: with output >>> being nil, which I'm having trouble figuring out. I can't find who could >>> possibly be nilling it out. I'm somewhat struggling finding my way around >>> the Pharo tools. The test seems to otherwise pass but the DNUs from the >>> background process isn't nice. Also when I just click on the test in the >>> TestRunner, I actually get four DNUs, not just one as I would expect. So I'm >>> kinda stuck, not sure how to move forward without help from someone who >>> knows his way around Pharo. >>> I also get odd failure from #testWriteCollectingMultipleBufferSize, which >>> seems to run fine (against collection) when I run the equivalent in a >>> workspace, but strangely fails when running via the #timeout:server:client: >>> construct, i.e. when client and server run in separate processes. Hm, now >>> that I think of it, they sure could fail if something preempts the client, >>> server processes at the right moment. I'll have to rethink that again. >> >> These problems should be solved with the latest version of CoreTests. >> >> Levente > > Thanks! I just realized that sometimes the 100 ms timeout is not enough even on Cog and the test fails, 200 ms works well. It typically happens when running #testReadWriteLargeAmount. I'd suggest increasing it to 1000 ms or more, to make sure it doesn't fail with SqueakVM or on slower machines. Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 11, 2010

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

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Sun, 10 Oct 2010, mkobetic(a)gmail.com wrote: > >> Hi Nicolas, >> >> "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> Hi again, >>> I now have ported two more packages >>> - Xtreams-Transforms >>> - Xtreams-Substreams >>> and their tests >> >> This is great! I loaded your code into Pharo 1.1 and things seem to be >> working quite well. There was a complaint about missing SharedQueue2, I just >> created a dummy subclass of SharedQueue with that name and things seemed to >> load fine. >> XTRecyclingCenter seems to be subclass of XTWriteStream, it should be >> Object subclass, maybe a typo ? >> >>> I did not have any portability problem with those... >>> But that's because I did not handle the Character encoder/decoder. >>> Consequently, I have 8 tests failing (the Base64 related tests) >> >> I was thinking, we could implement just 'encoding: #ascii' quite easily, >> to make this reasonably usable at least for applications that are fine with >> that. We're actually contemplating about implementing our own encoders for >> Xtreams too. The VW ones are tied to the classic streams more than we like. >> You might have noticed some rather hairy parts in the encoding streams >> yourself, where we're trying to work around some of the issues it creates. >> The advantage of reusing the existing encoders was that there are quite a >> few of those available, so reimplementing all that would be a drag. But we >> can come up with a scheme where we can reimplement at least the common ones >> and in VW we can still preserve hooking into the old ones for the rest. I >> can give that a try on VW side in the meantime so you could get those for >> free. >> >>> Plus 4 other tests failing because of my poor implementation of >>> #after:do: (forking processes in a SUnit TestCase can't be that >>> obvious). >> >> I looked at this, and I think this is how #after:do: should look like: >> >> after: aDelay do: aBlock >> Â Â Â Â "Evaluate the argument block delayed after the specified duration." >> >> Â Â Â Â | watchdog | >> Â Â Â Â watchdog := [ >> Â Â Â Â Â Â Â Â aDelay wait. >> Â Â Â Â Â Â Â Â aBlock value. >> Â Â Â Â ] newProcess. >> Â Â Â Â watchdog priority: Processor userInterruptPriority. >> Â Â Â Â watchdog resume. >> >> This would assume that the 2 tests calling #timeout:server:client: would >> use a Delay instance instead of a Duration, which I'd be fine with. However >> making that change doesn't quite get the tests running. It's blowing up with >> a DNU on the 'output close' bit in #terminate:server:client: with output >> being nil, which I'm having trouble figuring out. I can't find who could >> possibly be nilling it out. I'm somewhat struggling finding my way around >> the Pharo tools. The test seems to otherwise pass but the DNUs from the >> background process isn't nice. Also when I just click on the test in the >> TestRunner, I actually get four DNUs, not just one as I would expect. So I'm >> kinda stuck, not sure how to move forward without help from someone who >> knows his way around Pharo. >> I also get odd failure from #testWriteCollectingMultipleBufferSize, which >> seems to run fine (against collection) when I run the equivalent in a >> workspace, but strangely fails when running via the #timeout:server:client: >> construct, i.e. when client and server run in separate processes. Hm, now >> that I think of it, they sure could fail if something preempts the client, >> server processes at the right moment. I'll have to rethink that again. > > These problems should be solved with the latest version of CoreTests. > > Levente Thanks!

Oct. 11, 2010

[Pharo-project] Squeak/Pharo port of Xtreams moved

by Nicolas Cellier

After Julian demand, I moved Squeak/Pharo port of Xtreams to http://www.squeaksource.com/Xtreams.html Sorry for the inconvenience, but it's better to do it now. Please update your links. Nicolas

Oct. 11, 2010