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

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

by Igor Stasenko

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.

Oct. 11, 2010

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

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. > > I have been trying some of the examples from the doc pages (google code project), this simple one still fails: > > ((1 to: 10) reading collecting: [:x | x * x]) rest Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly ... on: Incomplete do: #count. We can certainly replace all those with regular block style. > The readline example is using the non-existing #slicer: method, this simpler version seems to work: > > |text| > text := 'line1\line2\line3\line4' withCRs reading. > text := text ender: [ :char | char = Character cr ]. > text collect: [ :line | line rest ]. > > That is a documentation bug though. Hm, odd, this is fixed in the package comments, but looks like I failed to regenerate the project pages properly. I'll review the comments again and update the site. Thanks!

Oct. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Levente Uzonyi

On Mon, 11 Oct 2010, Lukas Renggli wrote: > It is not the mailing list that is the problem, it is the > squeaksource.com server that is. It takes several minutes to calculate > a simple diff of a single version and that just kills responsiveness > at the current rate of commits. That seems to be a really high number. I just compared a version of the CollectionTests package in Squeak 4.2 with a Pharo version. The two are totally different, there are 2002 changes. Parsing both packages and creating the diffs takes less than a second with Cog. So it's probably less than 3 seconds with the standard VM. And this is an edge case. Levente > > Lukas > > On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> Maybe on a separate mailing list. >> >> Cheers, >> Alexandre >> >> >> On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: >> >>> I would really like to have the same behavior than the squeak system ie having the source modification >>> send to the list. I could not see how to set it up on Â squeaksource. >>> May be this is not the same version running. >>> >>> Stef >>> _______________________________________________ >>> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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. 11, 2010

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

by Schwab,Wilhelm K

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. 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 1:39 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider. > Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria. > 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 1:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. >> > > If it would be only about restarting, then its a piece of cake. > We should make sure that all finalizations detected prior to error, > did not get lost and are able to proceed as if nothing happens, > except a single one, which failed with error. > >> 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 12:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> Meanwhile, i'll try to implement two test cases for WeakRegistryTest. >> >> One, should cover following: >> >> coll := OrderedCollection new. >> obj := Object new. >> wrapper := WeakArray with: obj. >> coll add: wrapper. >> >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> >> obj := nil. >> Smalltalk garbageCollect. >> >> i.e somehow, user should be notified that there is an error during finalization. >> >> And second test case is to make sure that if one finalizer unable to >> complete due to error, >> the other ones (and finalization process itself) should continue >> running, skipping over errorneous finalizer. >> >> -- >> 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 > -- 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] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 20:04, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Understood, but are they all that different? Â The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Â Just something to consider. > Devil is always in details. The problem can be illustrated by following: | todoList | todoList := collection select: [ some criteria ]. collection removeAllFoundIn: todoList. todoList do: [ :each | each doSomething ]. now, if inside of #doSomething you got an error, a loop is interrupted, and if you restart the process, your todoList temp is gone, since it is local to particular context, which will be discarded. You also can't restore todoList by rescanning a collection, since you removed all elements, which met your criteria. > 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 1:02 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. Â That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. >> > > If it would be only about restarting, then its a piece of cake. > We should make sure that all finalizations detected prior to error, > did not get lost and are able to proceed as if nothing happens, > except a single one, which failed with error. > >> 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 12:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list >> Subject: Re: [Pharo-project] Another finalization concern: error handling >> >> Meanwhile, i'll try to implement two test cases for WeakRegistryTest. >> >> One, should cover following: >> >> coll := OrderedCollection new. >> obj := Object new. >> wrapper := WeakArray with: obj. >> coll add: wrapper. >> >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> obj toFinalizeSend: #remove: to: coll with: wrapper. >> >> obj := nil. >> Smalltalk garbageCollect. >> >> i.e somehow, user should be notified that there is an error during finalization. >> >> And second test case is to make sure that if one finalizer unable to >> complete due to error, >> the other ones (and finalization process itself) should continue >> running, skipping over errorneous finalizer. >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

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

by morod

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

Oct. 11, 2010

[Pharo-project] License question

by Schwab,Wilhelm K

Stef, Let's go forward in time. NativeBoost, Alien or FFI provide callbacks, I do some adaptation on my end, and out comes a pretty capable wrapper for the GNU Scientific Library. That sentence trivializes a LOT of work :( Details aside, is the wrapper code itself affected by GPL, or is it merely something unrelated that happens to invoke GSL if the latter is present on a system? What implications would that have for putting the wrapper in the inbox? This won't happen next week or next month, but depending on how easy it is to get going with callbacks, it shouldn't be years either. Bill

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

2010/10/11 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 11 Oct 2010, Lukas Renggli wrote: > >>> Object>>value >>> Â Â Â Â ^self >>> >>> What actually shown here is a use of duck typing, because any object, >>> which implemets #value, could be safely passed >>> as argument to #ifTrue:ifFalse: message. >>> It is well consistent with language design. >> >> Magritte implemented Symbol>>#value: for a while before any Smalltalk >> had this is their standard library. I must admit that I liked it in >> the beginning, but in the long run I realized that ... >> >> 1. It is not easily understandable for newbies. > > That's true. > Well, it depends. Very newbies can understand it because they trust the words. My son did. More advanced newbies can wonder how the hell this could work eventually, because they can differentiate a regular message and a literal #symbol. It's true that writing code is another matter. Why and when to use a block a message or a Symbol ? Maybe a newbie could be tempted to write: x > 1 and: #even. which currently does not work. >> 2. It quickly leads to very unreadable, hard to understand and hard to >> refactor code. >> 3. It is very limiting in itself and quickly leads to other hacks >> (like to replace sort blocks). > > That "hack" is really cool IMO. The code is easily understood by anyone: > > #(4 1 3 5 2) sort: #<=. > >> 4. #value and friends should be only understood by objects that can be >> evaluated (certainly not by Object). A symbol (name) by itself cannot >> be evaluated. >> >> I eventually removed Symbol>>#value: for good. Re-occuring questions >> in the mailing list disappeared. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. > > > Levente > >> >> Therefor I strongly suggest to remove #value, #value:, and friends >> from all objects that are not self-evaluable. BlockClosure and >> MessageSend are self-evaluable. Only there it makes sense. >> >> If people are too lazy to create a block where something >> self-evaluable is needed they should use a programming language >> designed for cryptic code. Creating a block closure in Smalltalk is >> concise and makes clear what happens easily. A symbol does not, you >> need to exactly understand how this dispatches with various objects. >> >> 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 > > _______________________________________________ > 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, Understood, but are they all that different? The ones that were served ahead of the error should stay that way (proper recording of same is what needs attention), and those yet to be served, if it's done well, should be ready for the new thread to handle. Just something to consider. 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 1:02 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. > If it would be only about restarting, then its a piece of cake. We should make sure that all finalizations detected prior to error, did not get lost and are able to proceed as if nothing happens, except a single one, which failed with error. > 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 12:14 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > Meanwhile, i'll try to implement two test cases for WeakRegistryTest. > > One, should cover following: > > coll := OrderedCollection new. > obj := Object new. > wrapper := WeakArray with: obj. > coll add: wrapper. > > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > > obj := nil. > Smalltalk garbageCollect. > > i.e somehow, user should be notified that there is an error during finalization. > > And second test case is to make sure that if one finalizer unable to > complete due to error, > the other ones (and finalization process itself) should continue > running, skipping over errorneous finalizer. > > -- > 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. 11, 2010

Re: [Pharo-project] how to get the diff on commit on the pharo source?

by Lukas Renggli

It is not the mailing list that is the problem, it is the squeaksource.com server that is. It takes several minutes to calculate a simple diff of a single version and that just kills responsiveness at the current rate of commits. Lukas On 11 October 2010 18:01, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Maybe on a separate mailing list. > > Cheers, > Alexandre > > > On 11 Oct 2010, at 12:49, StÃ©phane Ducasse wrote: > >> I would really like to have the same behavior than the squeak system ie having the source modification >> send to the list. I could not see how to set it up on Â squeaksource. >> May be this is not the same version running. >> >> Stef >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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

Oct. 11, 2010

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

by Igor Stasenko

On 11 October 2010 19:28, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. Â That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. > If it would be only about restarting, then its a piece of cake. We should make sure that all finalizations detected prior to error, did not get lost and are able to proceed as if nothing happens, except a single one, which failed with error. > 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 12:14 PM > To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list > Subject: Re: [Pharo-project] Another finalization concern: error handling > > Meanwhile, i'll try to implement two test cases for WeakRegistryTest. > > One, should cover following: > > coll := OrderedCollection new. > obj := Object new. > wrapper := WeakArray with: obj. > coll add: wrapper. > > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > obj toFinalizeSend: #remove: to: coll with: wrapper. > > obj := nil. > Smalltalk garbageCollect. > > i.e somehow, user should be notified that there is an error during finalization. > > And second test case is to make sure that if one finalizer unable to > complete due to error, > the other ones (and finalization process itself) should continue > running, skipping over errorneous finalizer. > > -- > 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. 11, 2010

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

by Schwab,Wilhelm K

Ok, I'll dig around for that and have a look. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, October 11, 2010 12:31 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Another finalization concern: error handling On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > Henry, > > Ok, what valid use of multiple executors have I missed? I described it earlier how the AXAnnouncements project uses this feature. Levente > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] > Sent: Monday, October 11, 2010 11:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote: > >> >> I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. >> >> Bill > > I fail to see how a blatantly obvious misuse of a feature becomes a valid argument against supporting that feature, or something you should worry alot about. > You can do Object become: nil, which is also not good style, but it's certainly not an valid argument for not allowing #become:. > Nor do I lose any sleep thinking of ways people could possibly abuse #become: > > Cheers, > Henry > _______________________________________________ > 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 Levente Uzonyi

On Mon, 11 Oct 2010, Schwab,Wilhelm K wrote: > Henry, > > Ok, what valid use of multiple executors have I missed? I described it earlier how the AXAnnouncements project uses this feature. Levente > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] > Sent: Monday, October 11, 2010 11:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Another finalization concern: error handling > > On Oct 11, 2010, at 4:10 13PM, Schwab,Wilhelm K wrote: > >> >> I am far more worried about having multiple executors per object (when did p=malloc();free(p);free(p);free(p) become good style?) than I am about getting the finalizer process itself completely robust at this point. >> >> Bill > > I fail to see how a blatantly obvious misuse of a feature becomes a valid argument against supporting that feature, or something you should worry alot about. > You can do Object become: nil, which is also not good style, but it's certainly not an valid argument for not allowing #become:. > Nor do I lose any sleep thinking of ways people could possibly abuse #become: > > Cheers, > Henry > _______________________________________________ > 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] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

2010/10/11 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > I think this discussion has diverged a lot from the original question, which > is to do with the compiler being too pedantic. > > #ifNotNil: and friends are the selectors of methods which just happen to > give the compiler an opportunity for a nice optimization, in the case when > the argument that follows is a literal block. In all other cases they can be > treated as message sends. If the compiler starts to impose limitations on > the language just because some magic selectors can be treated specially, > then IMO it is not behaving as it should. > +100 > Smalltalk is beautiful because it is so simple: everything is an object, and > all processing is done by sending messages to objects. Of course, in the > interests of speed, we can write a compiler that actually does something > different under the covers, like causing a branch in the byte codes instead > of sending a message, and of course the cases when that can be done need to > be clearly defined. But that does not mean that these magic selectors should > be allowed to pose limitations on how they can be used, because then we no > longer have Smalltalk, we have Smalltalk-- instead. > +100. You allowed to cheat, just not get caught! > Now, the above discussion is orthogonal to the questions of what is good > style, what is readable, maintainable, understandable to newbies, etc, etc. > Those questions are IMO just as important, but they should have nothing do > do with what the compiler is supposed to do. If the compiler is being too > pedantic, then it should be fixed. Then we can start discussing good style > without mixing apples and oranges together. > Amen :) > -- > Cheers, > Peter > > On Mon, Oct 11, 2010 at 5:03 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> I think that for typing in a transcript experessions when you want to >> experiment with something >> selectors are fun but not in method body. But I know that this is not a >> really good argument. Just feeling. >> May be we get trapped in our way of thinking. >> >> >> >>>>>> >> > I personally don't like the ifTrue:ifFalse: related changes, though it's >> > a logical change. I probably won't use that feature though. But I like the >> > monadic block <-> keyword selector substitution. Maybe the best is to add a >> > setting/preference to the compiler. >> >> >> _______________________________________________ >> 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. 11, 2010

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

by Schwab,Wilhelm K

Sig, The Dolphin approach is to restart any of the finalizer, main, timer, idler threads (I *think* there is one more in a baseline image) any time they quit; an #ensure: block forks a new thread of the type that terminated. That way, whether they are taken down by an error doing what they are supposed to do or just by a stray #terminate or mistake with an attached debugger, the system rolls onward intact. 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 12:14 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] Another finalization concern: error handling Meanwhile, i'll try to implement two test cases for WeakRegistryTest. One, should cover following: coll := OrderedCollection new. obj := Object new. wrapper := WeakArray with: obj. coll add: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj toFinalizeSend: #remove: to: coll with: wrapper. obj := nil. Smalltalk garbageCollect. i.e somehow, user should be notified that there is an error during finalization. And second test case is to make sure that if one finalizer unable to complete due to error, the other ones (and finalization process itself) should continue running, skipping over errorneous finalizer. -- 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