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

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by StÃ©phane Ducasse

hi gabriel > Hi, > VA implemented this behavior in the latest releases for Seaside compatibility and their implementation behaves similar to Pharo one. argh :) > I think that conceptually both methods must return true, but that's my opinion. If we can get to a consensus I can make the necessary changes. So please comment on this!. I like your point of view. This is logical. Everything starts with nothing :) > Thanks, > Gabriel > > On Thu, Mar 4, 2010 at 10:40 AM, Julian Fitzell <jfitzell(a)gmail.com> wrote: > I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined > as returning 0 (no match) for an empty collection. > > This doesn't necessarily mean that #beginsWith: needs to return false > as well, of course, but it would be another data point. And I just > checked VW and it returns true for both #beginsWith: and #endsWith: in > this case so that may be an argument the other way (haven't checked > Gnu or VA - not sure if they even implement it). > > Julian > > 2010/3/4 Gabriel Cotelli <g.cotelli(a)gmail.com>: > > Hi, > > > > I noticed that > > 'pharo' beginsWith: '' > > returns false. > > > > Is that Ok? I expect that this returns true, because the empty string is a > > prefix (and suffix) of any other string. > > Similar behavior exhibits endsWith:. > > > > This seems a bug to me. What do you think? > > > > In case we acknowledge it's a bug I can post an entry in the issue tracker > > and tonight upload a SLICE with the fix. > > > > Regards, > > Gabriel > > > > > > > > _______________________________________________ > > 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

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by Gabriel Cotelli

Hi, VA implemented this behavior in the latest releases for Seaside compatibility and their implementation behaves similar to Pharo one. I think that conceptually both methods must return true, but that's my opinion. If we can get to a consensus I can make the necessary changes. So please comment on this!. Thanks, Gabriel On Thu, Mar 4, 2010 at 10:40 AM, Julian Fitzell <jfitzell(a)gmail.com> wrote: > I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined > as returning 0 (no match) for an empty collection. > > This doesn't necessarily mean that #beginsWith: needs to return false > as well, of course, but it would be another data point. And I just > checked VW and it returns true for both #beginsWith: and #endsWith: in > this case so that may be an argument the other way (haven't checked > Gnu or VA - not sure if they even implement it). > > Julian > > 2010/3/4 Gabriel Cotelli <g.cotelli(a)gmail.com>: > > Hi, > > > > I noticed that > > 'pharo' beginsWith: '' > > returns false. > > > > Is that Ok? I expect that this returns true, because the empty string is > a > > prefix (and suffix) of any other string. > > Similar behavior exhibits endsWith:. > > > > This seems a bug to me. What do you think? > > > > In case we acknowledge it's a bug I can post an entry in the issue > tracker > > and tonight upload a SLICE with the fix. > > > > Regards, > > Gabriel > > > > > > > > _______________________________________________ > > 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 >

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by Julian Fitzell

I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined as returning 0 (no match) for an empty collection. This doesn't necessarily mean that #beginsWith: needs to return false as well, of course, but it would be another data point. And I just checked VW and it returns true for both #beginsWith: and #endsWith: in this case so that may be an argument the other way (haven't checked Gnu or VA - not sure if they even implement it). Julian 2010/3/4 Gabriel Cotelli <g.cotelli(a)gmail.com>: > Hi, > > I noticed that > 'pharo' beginsWith: '' > returns false. > > Is that Ok? I expect that this returns true, because the empty string is a > prefix (and suffix) of any other string. > Similar behavior exhibits endsWith:. > > This seems a bug to me. What do you think? > > In case we acknowledge it's a bug I can post an entry in the issue tracker > and tonight upload a SLICE with the fix. > > Regards, > Gabriel > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

[Pharo-project] String>>beginsWith: with empty strings issue

by Gabriel Cotelli

Hi, I noticed that 'pharo' beginsWith: '' returns false. Is that Ok? I expect that this returns true, because the empty string is a prefix (and suffix) of any other string. Similar behavior exhibits endsWith:. This seems a bug to me. What do you think? In case we acknowledge it's a bug I can post an entry in the issue tracker and tonight upload a SLICE with the fix. Regards, Gabriel

March 4, 2010

Re: [Pharo-project] SmalltalkImage current vs Smalltalk : plan B

by StÃ©phane Ducasse

since this is one of this rare moment in life (I rarely hear that we did something good) I want to say that this is good to know that we did a good job in 95% of the case because after a while we only get the bad signal and now I'm spending time on pharo to build something cool and positive. :) And as I said I was never happy with the solution for smalltalkImage but I hated the put everything in SystemDictionary and I would be happy to fix but I cannot be the driver here. Stef >> If you want to help we can start going in that direction. >> >> I decided that I will not rant about the past anymore because I want new and POSITIVE energy. >> Now just a bit of knowledge of the past is still good. > > Indeed. Time for some more context: The only portion of that work that > has ever been criticized as overly zealous was the abomination named > "SmalltalkImage current". You've done lots of useful things but > SmalltalkImage was unmotivated and pointless because contrary to the > other changes it never encapsulated any useful domain, was verbose just > for the purpose of being verbose and caused more problems than it could > ever hope to solve. We'll be all better off without it. > > The changes done for SpaceTally, ChangeSet, PointerFinder, even > SystemNavigation *did* cover useful domains and were consequently never > debated. It would be good if you remembered the things that were > accepted along with the things that caused discussions because it might > help you to restore a more balanced view of the Squeak community. > > Cheers, > - Andreas > >> For new guys in the community, just imagine that SpaceTally was defined in SystemDictionary. Yes! too >> >> Similarly >> Smalltalk spaceTally >> vs >> SpaceTally new >> >> Smalltalk currentChangeset >> vs. Changeset current >> >> Smalltalk pointersTo: C >> vs PointerFinder pointersTo: C >> >> Smalltalk browserAllCallsOn: >> vs >> Finder/SystemNavigation browserAllCallsOn: >> >> Take scratch and you will see how it was in 2.8 :) >> >> So I believe that "Abstraction is a Good Thing" (TM) >> >> I spent far too many hours arguing in the past. Now we will make it the way we believe it is beautiful and >> people that do not like it are not forced to use Pharo. >> >> Stef >> >> >> On Mar 4, 2010, at 12:30 AM, Nicolas Cellier wrote: >> >>> For now, plan A has more votes than plan B. >>> plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. >>> Let SmalltalkImage current ^Smalltalk for crossfork compatibility >>> plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = >>> SystemDictionary. >>> Use messages indirections like: >>> Smalltalk vm imagePath >>> Smalltalk commandLine optionAt: 2. >>> etc... (see previous thread) >>> >>> At 1st step, they are not much different: >>> both unify Smalltalk and SmalltalkImage current API. >>> >>> Also Plan A is much simpler, thus attractive. But: >>> - Plan A is essentially coming back to 3.8 statu quo. >>> - Plan B is essentially introducing message indirections >>> >>> Advantages of plan B I see for the future: >>> - cleaner separation of concerns >>> - less vulnerable to refactoring (thanks to messages indirection) >>> - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) >>> easier thru messages >>> >>> Last, I do not desesperate to sell plan B to other forks. >>> See the outline pf plan B below. >>> >>> So do you still buy plan A ? >>> >>> Nicolas >>> >>> >>> ------------------------------------------ >>> OUTLINE OF PLAN B : >>> ------------------------------------------ >>> >>> PART I - Fusion of the 2 APIs in 1 >>> 1) add a globals instance variable to SmalltalkImage >>> 2) initialize this instance variable SmalltalkImage current globals: Smalltalk >>> 3) implement SystemDictionary methods in use to SmalltalkImage, and >>> redirect them through globals >>> MessageSentToGlobalFinder testMessagesSentToSmalltalk may help >>> 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. >>> >>> PART II - Refactoring >>> 1) add a few messages in SmalltalkImage (vm ^self) >>> 2) refactor users of SmalltalkImage current -> Smalltalk vm (or >>> Smalltalk commandLine or...) >>> This is the compatibility layer which will enable cross fork compatibility >>> >>> PART III - Provide cross fork compatibility layers: >>> simple, Cuis and Pharo and Squeak3.8 and... just have to respond to >>> Smalltalk vm (and a few others) >>> either ^self or ^SmalltalkImage current or whatever they prefer >>> >>> PART IV - deeper refactorings >>> 1) split SmalltalkImage at will (no precipitation good Rationale SHALL >>> be provided). >>> 2) introduce other Smalltalk hooks for not so well known classes >>> (SystemNavigation / SourceFiles etc...) >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org >>> 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

March 4, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues

by Henrik Johansen

Den 04.03.2010 13:19, skrev StÃ©phane Ducasse: > btw henrik > > does VW have the same behavior? > > Stef > Short answer is no, Eliot described the details: http://n4.nabble.com/ensure-issues-was-Re-Pharo-project-Pharo-by-Example-vo… Cheers, Henry > On Mar 4, 2010, at 11:38 AM, Henrik Johansen wrote: > > >> FWIW, this quote from the following discussion on Squeak-dev distills what I was trying (but failing) to demonstrate: >> "We shouldn't stop trying to support well-behaved ensure blocks properly. >> Because if we don't then ensure >> becomes entirely random. Or can anyone here explain why it would be >> reasonable to expect that this version works: >> >> p := [[Processor yield] ensure:[Transcript show: 'finished']] fork. >> Processor yield. >> p terminate. >> >> but this one doesn't: >> >> p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork. >> Processor yield. >> p terminate. >> >> (we're using yield here to denote any kind of process switch) If the >> only thing that determines whether an ensure block is executed is a >> process switch, then we basically have random, non-predictable unwind >> handling. Which is a problem that is entirely unrelated to whether the >> unwind block is itself well-behaved or not. " >> >> In a book with chapters discussing topics such as ensure and processes, (based on Pharo 1.0 which is unlikely to contain any fixes for such an issue), it deserves at least a mention. >> >> Cheers, >> Henry >> >> Den 03.03.2010 15:33, skrev Levente Uzonyi: >> >>> On Wed, 3 Mar 2010, StÃ©phane Ducasse wrote: >>> >>> >>>> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: >>>> >>>> >>>>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: >>>>> >>>>> >>>>>> >>>>>>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>>>>>> |proc| >>>>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>>>>> 'Finish!' Processor yield.]] newProcess. >>>>>>>> proc resume. >>>>>>>> Processor yield. >>>>>>>> proc suspend. >>>>>>>> proc terminate. >>>>>>>> >>>>>>> Why don't we get it printing? >>>>>>> >>>>>> Forgot a . there, supposed to be >>>>>> >>>>>> |proc| >>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>>> 'Finish!'. Processor yield.]] newProcess. >>>>>> proc resume. >>>>>> Processor yield. >>>>>> proc suspend. >>>>>> proc terminate. >>>>>> >>>>>> on my machine it prints: >>>>>> *Start!Start!Finish! >>>>>> >>>>> The problem occurs because Transcript >> #endEntry (sent from #show:) >>>>> takes a while to execute, so the process (proc) prints 'Start!', but >>>>> it gets terminated before execution reaches #resetContents (#reset in >>>>> Squeak). So 'Start!' is still in the stream. Then our process executes the >>>>> #ensure: block and it prints 'Start!' and 'Finish!' too. >>>>> >>>> >>>> Thanks for the explanation levente! >>>> But I'm still dizzy :) why Transcript show: 'Finish' would also print 'start' ? >>>> >>> Transcript is just a stream. #show: is just a combination of #nextPutAll: and #endEntry. #endEntry displays the contents of the stream and when that's done it removes everything from the stream with #resetContents. #resetContents is never executed, because the process is terminated before that. So the contents of the stream are kept and displayed again later. >>> >>> >>> Levente >>> >>> >>>> >>>>> There's worse problem with #ensure: and #terminate is that, a process executing an #ensure: block can be terminated. If you evaluate this code: >>>>> >>>>> | process stage1 stage2 stage3 counter | >>>>> stage1 := stage2 := stage3 := false. >>>>> counter := 0. >>>>> process := [ >>>>> [ stage1 := true ] ensure: [ >>>>> stage2 := true. >>>>> 1000000 timesRepeat: [ counter := counter + 1 ]. >>>>> stage3 := true ] ] newProcess. >>>>> process resume. >>>>> Processor yield. >>>>> process suspend. >>>>> process terminate. >>>>> 1000 milliSeconds asDelay wait. >>>>> { stage1. stage2. stage3. counter } explore >>>>> >>>>> you will find that stage1 and stage2 is reached as expected, but stage3 is not and counter is less than 1000000. That's because the forked process started evaluating the #ensure: block, but it was terminated by our process. >>>>> >>>>> Is this the expected behavior when sending #terminate to a process which is evaluating an #ensure: block? >>>>> >>>>> >>>>> Cheers, >>>>> BalÃ¡zs & Levente >>>>> >>>>> >>>>> >>>>>> *yay >>>>>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

March 4, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues

by Peter Hugosson-Miller

In case anybody is interested, I tried Henrik's example in VAST: | proc | proc := [[Transcript show: 'Start!'] ensure: [Transcript show: 'Finish!'. Processor yield]] newProcess. proc resume. Processor yield. proc suspend. proc terminate. on my machine it prints: Start!Finish! -- Cheers, Peter On Thu, Mar 4, 2010 at 1:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > btw henrik > > does VW have the same behavior? > > Stef > > On Mar 4, 2010, at 11:38 AM, Henrik Johansen wrote: > > > FWIW, this quote from the following discussion on Squeak-dev distills > what I was trying (but failing) to demonstrate: > > "We shouldn't stop trying to support well-behaved ensure blocks properly. > > Because if we don't then ensure > > becomes entirely random. Or can anyone here explain why it would be > > reasonable to expect that this version works: > > > > p := [[Processor yield] ensure:[Transcript show: 'finished']] fork. > > Processor yield. > > p terminate. > > > > but this one doesn't: > > > > p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork. > > Processor yield. > > p terminate. > > > > (we're using yield here to denote any kind of process switch) If the > > only thing that determines whether an ensure block is executed is a > > process switch, then we basically have random, non-predictable unwind > > handling. Which is a problem that is entirely unrelated to whether the > > unwind block is itself well-behaved or not. " > > > > In a book with chapters discussing topics such as ensure and processes, > (based on Pharo 1.0 which is unlikely to contain any fixes for such an > issue), it deserves at least a mention. > > > > Cheers, > > Henry > > > > Den 03.03.2010 15:33, skrev Levente Uzonyi: > >> On Wed, 3 Mar 2010, StÃ©phane Ducasse wrote: > >> > >>> > >>> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: > >>> > >>>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: > >>>> > >>>>> > >>>>>>> PS. For the not-so-faint-of-heart, open a Transcript and try > evaluating: > >>>>>>> |proc| > >>>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: > >>>>>>> 'Finish!' Processor yield.]] newProcess. > >>>>>>> proc resume. > >>>>>>> Processor yield. > >>>>>>> proc suspend. > >>>>>>> proc terminate. > >>>>>> Why don't we get it printing? > >>>>> Forgot a . there, supposed to be > >>>>> > >>>>> |proc| > >>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: > >>>>> 'Finish!'. Processor yield.]] newProcess. > >>>>> proc resume. > >>>>> Processor yield. > >>>>> proc suspend. > >>>>> proc terminate. > >>>>> > >>>>> on my machine it prints: > >>>>> *Start!Start!Finish! > >>>> > >>>> The problem occurs because Transcript >> #endEntry (sent from #show:) > >>>> takes a while to execute, so the process (proc) prints 'Start!', but > >>>> it gets terminated before execution reaches #resetContents (#reset in > >>>> Squeak). So 'Start!' is still in the stream. Then our process executes > the > >>>> #ensure: block and it prints 'Start!' and 'Finish!' too. > >>> > >>> > >>> Thanks for the explanation levente! > >>> But I'm still dizzy :) why Transcript show: 'Finish' would also print > 'start' ? > >> > >> Transcript is just a stream. #show: is just a combination of > #nextPutAll: and #endEntry. #endEntry displays the contents of the stream > and when that's done it removes everything from the stream with > #resetContents. #resetContents is never executed, because the process is > terminated before that. So the contents of the stream are kept and displayed > again later. > >> > >> > >> Levente > >> > >>> > >>>> > >>>> There's worse problem with #ensure: and #terminate is that, a process > executing an #ensure: block can be terminated. If you evaluate this code: > >>>> > >>>> | process stage1 stage2 stage3 counter | > >>>> stage1 := stage2 := stage3 := false. > >>>> counter := 0. > >>>> process := [ > >>>> [ stage1 := true ] ensure: [ > >>>> stage2 := true. > >>>> 1000000 timesRepeat: [ counter := counter + 1 ]. > >>>> stage3 := true ] ] newProcess. > >>>> process resume. > >>>> Processor yield. > >>>> process suspend. > >>>> process terminate. > >>>> 1000 milliSeconds asDelay wait. > >>>> { stage1. stage2. stage3. counter } explore > >>>> > >>>> you will find that stage1 and stage2 is reached as expected, but > stage3 is not and counter is less than 1000000. That's because the forked > process started evaluating the #ensure: block, but it was terminated by our > process. > >>>> > >>>> Is this the expected behavior when sending #terminate to a process > which is evaluating an #ensure: block? > >>>> > >>>> > >>>> Cheers, > >>>> BalÃ¡zs & Levente > >>>> > >>>> > >>>>> > >>>>> *yay > >>>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues

by StÃ©phane Ducasse

btw henrik does VW have the same behavior? Stef On Mar 4, 2010, at 11:38 AM, Henrik Johansen wrote: > FWIW, this quote from the following discussion on Squeak-dev distills what I was trying (but failing) to demonstrate: > "We shouldn't stop trying to support well-behaved ensure blocks properly. > Because if we don't then ensure > becomes entirely random. Or can anyone here explain why it would be > reasonable to expect that this version works: > > p := [[Processor yield] ensure:[Transcript show: 'finished']] fork. > Processor yield. > p terminate. > > but this one doesn't: > > p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork. > Processor yield. > p terminate. > > (we're using yield here to denote any kind of process switch) If the > only thing that determines whether an ensure block is executed is a > process switch, then we basically have random, non-predictable unwind > handling. Which is a problem that is entirely unrelated to whether the > unwind block is itself well-behaved or not. " > > In a book with chapters discussing topics such as ensure and processes, (based on Pharo 1.0 which is unlikely to contain any fixes for such an issue), it deserves at least a mention. > > Cheers, > Henry > > Den 03.03.2010 15:33, skrev Levente Uzonyi: >> On Wed, 3 Mar 2010, StÃ©phane Ducasse wrote: >> >>> >>> On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: >>> >>>> On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: >>>> >>>>> >>>>>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>>>>> |proc| >>>>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>>>> 'Finish!' Processor yield.]] newProcess. >>>>>>> proc resume. >>>>>>> Processor yield. >>>>>>> proc suspend. >>>>>>> proc terminate. >>>>>> Why don't we get it printing? >>>>> Forgot a . there, supposed to be >>>>> >>>>> |proc| >>>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>>> 'Finish!'. Processor yield.]] newProcess. >>>>> proc resume. >>>>> Processor yield. >>>>> proc suspend. >>>>> proc terminate. >>>>> >>>>> on my machine it prints: >>>>> *Start!Start!Finish! >>>> >>>> The problem occurs because Transcript >> #endEntry (sent from #show:) >>>> takes a while to execute, so the process (proc) prints 'Start!', but >>>> it gets terminated before execution reaches #resetContents (#reset in >>>> Squeak). So 'Start!' is still in the stream. Then our process executes the >>>> #ensure: block and it prints 'Start!' and 'Finish!' too. >>> >>> >>> Thanks for the explanation levente! >>> But I'm still dizzy :) why Transcript show: 'Finish' would also print 'start' ? >> >> Transcript is just a stream. #show: is just a combination of #nextPutAll: and #endEntry. #endEntry displays the contents of the stream and when that's done it removes everything from the stream with #resetContents. #resetContents is never executed, because the process is terminated before that. So the contents of the stream are kept and displayed again later. >> >> >> Levente >> >>> >>>> >>>> There's worse problem with #ensure: and #terminate is that, a process executing an #ensure: block can be terminated. If you evaluate this code: >>>> >>>> | process stage1 stage2 stage3 counter | >>>> stage1 := stage2 := stage3 := false. >>>> counter := 0. >>>> process := [ >>>> [ stage1 := true ] ensure: [ >>>> stage2 := true. >>>> 1000000 timesRepeat: [ counter := counter + 1 ]. >>>> stage3 := true ] ] newProcess. >>>> process resume. >>>> Processor yield. >>>> process suspend. >>>> process terminate. >>>> 1000 milliSeconds asDelay wait. >>>> { stage1. stage2. stage3. counter } explore >>>> >>>> you will find that stage1 and stage2 is reached as expected, but stage3 is not and counter is less than 1000000. That's because the forked process started evaluating the #ensure: block, but it was terminated by our process. >>>> >>>> Is this the expected behavior when sending #terminate to a process which is evaluating an #ensure: block? >>>> >>>> >>>> Cheers, >>>> BalÃ¡zs & Levente >>>> >>>> >>>>> >>>>> *yay >>>>> 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

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by StÃ©phane Ducasse

jorge could you make a list of things to do in 10 min? So that we get an idea. I really believe that we should invest for the future. Stef On Mar 4, 2010, at 10:07 AM, Jorge Ressia wrote: > Yes, the New compiler is not better. However, I think the New Compiler > is the right direction to pursue. > > After fighting with it for some months to make the Closures work in it > I can tell you that I learn a great deal from it, painfully :) . > But I now have a pretty good idea of what it is required to have a > modularized compiler with more suitable abstraction for this > particular domain. > I implemented many tests and I have to implement a lot more. Then, I > believe that by expressing ourselves through these tests we will be > able to modify the compiler to make it look the way we want. > > At least that is my plan with the New compiler. > > Cheers, > > Jorge > > On Thu, Mar 4, 2010 at 9:53 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> I'll try to build the tests and come up with a better solution. >>> >>> You what I would love to spend 2/3 weeks just coding in the new compiler and making sure >>> that it has the right abstractions/messages to deal with issue like that. >> >> The problem is that the New Compiler is not really in a better state >> than the old compiler. Of course it has more objects and is much >> easier to extend, but all in all it is a mess too. This is mostly due >> to the fact that the system below it changed quite a bit in the past >> years (pragmas, properties, closures, primitives, new bytecodes, ...) >> and that the New Compiler had to be patched and changed quite heavily >> to accommodate these new requirements that it was not designed for. >> Maintaining and fixing the New Compiler got so extremely expensive >> that it is questionable if this is still a viable platform? Ask Jorge >> and Marcus. >> >> Lukas >> >> -- >> Lukas Renggli >> http://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

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Alexandre Bergel

> But I *definitly* need the infrastructure... in some form. I need to > get Reflectivity to > work again, it's needed for at least Jorge's work and JB's work... > and for other research > on Reflection. I also needs it for my work on code profiling. I am currently using the "object as compiled method" trick to instrument the base application. It slows everything down significantly. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 4, 2010