December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] squeak VM 5.0

by Laval Jannik

The problem is that it does not work fine. But I publish it soon. Jannik On Dec 5, 2009, at 15:48 , StÃ©phane Ducasse wrote: > cool jannik > May be we should publish this package system tracer somewhere. > On Dec 5, 2009, at 3:38 PM, Laval Jannik wrote: > >> Hi John, >> >> Ok, I thried this: >> - file in the updated System-Tracer (attached) >> > I modified some references to Smalltalk to SmalltalkImage current, but not all. >> - run it >> ok, it runs and generate a new image. >> This is done in a 4.2.2VM runing with rosetta. >> >> Now, when I try to load the new image, VM open a white window (this is not bad :) ) >> But I don't know what I can do with this, there is no message. >> >> So, I tried also with a pharo10259 and a Squeak 3.10 and I have the same error. >> >> Do you have an idea of the bug ? >> >> Cheers, >> Jannik >> >> <System-Tracing.2forPharo.cs> >> On Dec 4, 2009, at 22:39 , John M McIntosh wrote: >> >>> I think David Lewis made the last one, let's cc him. >>> >>> Perhaps the process would be >>> >>> Examine the squeak image. >>> take the required source that does the system tracing >>> someone make a MC project (no idea if one exists?) >>> >>> a) file that into a Pharo image. >>> b) Correct things like references to Smalltalk, versus SmalltalkImage current >>> c) run it. >>> d) place 64bit image on pharo server. >>> >>> I note to run the system tracer you need to run it either on a PowerPC. >>> Or on a MacIntel using a 4.x series macintosh VM, make a copy, do a get info on the VM >>> check "Open using Rosetta" >>> >>> If "Open using Rosetta" is not an option and you are running 10.6 then it is likely you did >>> not install Rosetta when you upgraded/installed 10.6. You need to find your 10.6 DVD >>> and lookup how to install Rosetta after installing 10.6 >>> >>> PS yes you could use a 10.5 series VM for this too. >>> >>> >>> However to complicate things I don't think anyone has done a Closure based image >>> and I don't know if that will be a problem. You could take a pre-closure Pharo image >>> and try it just to get past the point where having the SystemTracer code in a MC is done. >>> >>> >>> On 2009-12-04, at 1:23 PM, Laval Jannik wrote: >>> >>>> Hi Alex, >>>> >>>> PharoCore is a 32bits image. >>>> So it works on Squeak.5.0.0.b9.64*32.app. >>>> >>>> I see that Squeak has a 64bits fork image, is it possible to have a Pharo one? >>>> What is the process to do this ? >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> On Dec 4, 2009, at 20:50 , Alexandre Bergel wrote: >>>> >>>>> Hi! >>>>> >>>>> I just tried Squeak.5.0.0.b9.64*64.app.zip, but I was not able to run >>>>> a pharo core on it. >>>>> I have a MacBookPro 10.5.8. I do not know whether this is helpful or >>>>> not. Feel free to ask more info about my config. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> 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 >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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

Dec. 5, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by StÃ©phane Ducasse

Excellent! We need really cool and well tested imageSegments without etoy and project refs everywhere. Let us know up to date. On Dec 5, 2009, at 3:17 AM, Sheridan Mahoney wrote: > > Great! The other person helping me is Martin McClure, and Mariano contacted > me just yesterday to start collaborating, so looks like there are 3 of us > now > hooked on ImageSegment.... > > -- Sheri > > > > Adrian Lienhard wrote: >> >> Hi Sheri, >> >> Sounds ok to make new: raise an exception if you adjust the tests (and >> any code that exists in the image using new: (but I assume there is >> none)). >> >> However, the actual reason why you get multiple same symbols after >> loading a segment likely is unrelated to ByteSymbol class>>new:. I >> guess it is because when creating the segment you do not hold onto >> these symbols. Like this they do not get into the outPointers ref >> stream but in the bytearray. When installing the segment again, with >> same symbols existing in the image already, then you get duplicates. >> >> The "right way" to do this is to strongly hold onto all symbols when >> creating a segment. See #createSegmentFrom:. You can reproduce this >> problem by commenting out the first line of #createSegmentFrom: and >> running #testSymbols. >> >> Let us know how it goes... >> >> BTW, Mariano is also writing ImageSegment tests, so maybe you want to >> join forces (or maybe he already is the colleague you mentioned?). >> >> Cheers, >> Adrian >> >> On Dec 3, 2009, at 23:10 , StÃ©phane Ducasse wrote: >> >>>> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> >>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>>> To: pharo-project-bounces(a)lists.gforge.inria.fr >>>> Subject: Re: getting rid of Symbol >> new: ? >>>> Reply-To: sheridan(a)sheridan-mahoney.com >>>> >>>> >>>> A colleague and I are investigating the ImageSegment class and its >>>> methods, we came across an issue I would like to get external >>>> opinions on. Newbie alert, BTW (at least one of us, no names >>>> mentioned...). Also, this is not a problem that will affect many >>>> users, but it is familiarizing us with the check-in process, >>>> slices, etc. While working on ImageSegment tests, we discovered a >>>> problem on trying to load segments that had Symbols in the root >>>> array. It is possible to create 2 ByteSymbols with the same >>>> sequence of characters. :( In trying to track down how this is >>>> possible, we came across a side issue, that ByteSymbol new: had >>>> the capacity to create multiple new ByteSymbols with the same >>>> number of nil characters (as in, initialized with nil). We want to >>>> dissallow Symbol new: , which would cause people to use one of >>>> the nicer methods for Symbol/ByteSymbol creation (namely, one which >>>> checks that the sequence of characters doesn't already exist, as >>>> part of the creation process). We have a fix we want to check in, >>>> but currently it breaks a test case in the SymbolTest class, which >>>> is checking that new: works. We also changed the intern: >>>> method on the class side of Symbol to use basicNew: instead >>>> of new: . Are there reasons to keep 'Symbol new:' , that >>>> outweigh the reasons to get rid of it? >>>> Many thanks, >>>> and Cheers, >>>> Sheri Mahoney >>> >>> _______________________________________________ >>> 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 >> >> > > -- > View this message in context: http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4116203.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 5, 2009

Re: [Pharo-project] squeak VM 5.0

by StÃ©phane Ducasse

cool jannik May be we should publish this package system tracer somewhere. On Dec 5, 2009, at 3:38 PM, Laval Jannik wrote: > Hi John, > > Ok, I thried this: > - file in the updated System-Tracer (attached) > > I modified some references to Smalltalk to SmalltalkImage current, but not all. > - run it > ok, it runs and generate a new image. > This is done in a 4.2.2VM runing with rosetta. > > Now, when I try to load the new image, VM open a white window (this is not bad :) ) > But I don't know what I can do with this, there is no message. > > So, I tried also with a pharo10259 and a Squeak 3.10 and I have the same error. > > Do you have an idea of the bug ? > > Cheers, > Jannik > > <System-Tracing.2forPharo.cs> > On Dec 4, 2009, at 22:39 , John M McIntosh wrote: > >> I think David Lewis made the last one, let's cc him. >> >> Perhaps the process would be >> >> Examine the squeak image. >> take the required source that does the system tracing >> someone make a MC project (no idea if one exists?) >> >> a) file that into a Pharo image. >> b) Correct things like references to Smalltalk, versus SmalltalkImage current >> c) run it. >> d) place 64bit image on pharo server. >> >> I note to run the system tracer you need to run it either on a PowerPC. >> Or on a MacIntel using a 4.x series macintosh VM, make a copy, do a get info on the VM >> check "Open using Rosetta" >> >> If "Open using Rosetta" is not an option and you are running 10.6 then it is likely you did >> not install Rosetta when you upgraded/installed 10.6. You need to find your 10.6 DVD >> and lookup how to install Rosetta after installing 10.6 >> >> PS yes you could use a 10.5 series VM for this too. >> >> >> However to complicate things I don't think anyone has done a Closure based image >> and I don't know if that will be a problem. You could take a pre-closure Pharo image >> and try it just to get past the point where having the SystemTracer code in a MC is done. >> >> >> On 2009-12-04, at 1:23 PM, Laval Jannik wrote: >> >>> Hi Alex, >>> >>> PharoCore is a 32bits image. >>> So it works on Squeak.5.0.0.b9.64*32.app. >>> >>> I see that Squeak has a 64bits fork image, is it possible to have a Pharo one? >>> What is the process to do this ? >>> >>> Cheers, >>> Jannik >>> >>> >>> On Dec 4, 2009, at 20:50 , Alexandre Bergel wrote: >>> >>>> Hi! >>>> >>>> I just tried Squeak.5.0.0.b9.64*64.app.zip, but I was not able to run >>>> a pharo core on it. >>>> I have a MacBookPro 10.5.8. I do not know whether this is helpful or >>>> not. Feel free to ask more info about my config. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> >> _______________________________________________ >> 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

Dec. 5, 2009

Re: [Pharo-project] Protocol extension proposal: Boolean>>asBit ?

by StÃ©phane Ducasse

I like the idea. publish the code with some tests + a bug entry and we include it. Now do you have any idea how the selector could mkae sure that we know that true is one? Because I could never remember that in C. I used stickers on my screen or macros. On Dec 5, 2009, at 11:44 AM, Igor Stasenko wrote: > I currently writing a code which looks like: > > a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]). > > And i get somewhat tired repeating the same pattern in multiple places. > So, i thinking , maybe #asBit convenience method could be useful? > > True>>asBit > ^ 1 > False>>asBit > ^ 0 > > so, then, in case of need like above, we could write much shorter expressions: > a := some numeric expression + someBoolean asBit. > > And its much less error prone comparing to #ifTrue:ifFalse:, since i > found its relatively easy to make a mess (swapping 1 with 0), > especially, when you having negations in expression, because once you see: > > (someBoolean not ifTrue: [1] ifFalse: [0]) > > you always tempted to write it as: > > (someBoolean ifTrue: [0] ifFalse: [1]). > > or as: > > (someBoolean ifFalse: [1] ifTrue: [0]). > > but once you start playing with it, its very easy to shoot into own > feet if you are not careful. > > But if we could add #asBit, then we could write: > > someBoolean not asBit > > which is much more: > a) concise & cleaner > b) error proof > > > -- > 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

Dec. 5, 2009

Re: [Pharo-project] christmas coding parties?

by StÃ©phane Ducasse

ok we should pick some dates. mariano can you launch a doodle? On Dec 4, 2009, at 9:39 PM, Lukas Renggli wrote: > I would be in for an online-video-screensharing-pairprogramming-coding-party :-) > > Lukas > > 2009/12/4 <csrabak(a)bol.com.br>: >> I expect you folks make the scheduling invitation giving the time in UTC, so I can >> check my availability ;-) >> >> >> Em 04/12/2009 17:21, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: >> >> >> why not? If skype is reachable from where we are, I have no problem :) >> >> Ahh the time ;) Take into consideration the difference between your time and our. >> >> Best, >> >> Mariano >> >> >> On Fri, Dec 4, 2009 at 7:52 PM, <csrabak(a)bol.com.br> wrote: >> >> Is there a means of joining via Skype and/or IRC? >> >> >> Em 04/12/2009 09:57, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: >> >> >> >> >> Hi all >> >> I would like to organize a couple of coding parties around christmas. >> The 18 of december? is one possibility (even if I can only start at 11h). >> So if some of you are close to lille during holidays we could have fun coding >> together. >> >> I would like to organize a moose day too. I want to code what I have in mind >> with CAnalyzer and mondrian. >> >> 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 >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > 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

Dec. 5, 2009

Re: [Pharo-project] squeak VM 5.0

by Laval Jannik

Hi John, Ok, I thried this: - file in the updated System-Tracer (attached) > I modified some references to Smalltalk to SmalltalkImage current, but not all. - run it ok, it runs and generate a new image. This is done in a 4.2.2VM runing with rosetta. Now, when I try to load the new image, VM open a white window (this is not bad :) ) But I don't know what I can do with this, there is no message. So, I tried also with a pharo10259 and a Squeak 3.10 and I have the same error. Do you have an idea of the bug ? Cheers, Jannik On Dec 4, 2009, at 22:39 , John M McIntosh wrote: > I think David Lewis made the last one, let's cc him. > > Perhaps the process would be > > Examine the squeak image. > take the required source that does the system tracing > someone make a MC project (no idea if one exists?) > > a) file that into a Pharo image. > b) Correct things like references to Smalltalk, versus SmalltalkImage current > c) run it. > d) place 64bit image on pharo server. > > I note to run the system tracer you need to run it either on a PowerPC. > Or on a MacIntel using a 4.x series macintosh VM, make a copy, do a get info on the VM > check "Open using Rosetta" > > If "Open using Rosetta" is not an option and you are running 10.6 then it is likely you did > not install Rosetta when you upgraded/installed 10.6. You need to find your 10.6 DVD > and lookup how to install Rosetta after installing 10.6 > > PS yes you could use a 10.5 series VM for this too. > > > However to complicate things I don't think anyone has done a Closure based image > and I don't know if that will be a problem. You could take a pre-closure Pharo image > and try it just to get past the point where having the SystemTracer code in a MC is done. > > > On 2009-12-04, at 1:23 PM, Laval Jannik wrote: > >> Hi Alex, >> >> PharoCore is a 32bits image. >> So it works on Squeak.5.0.0.b9.64*32.app. >> >> I see that Squeak has a 64bits fork image, is it possible to have a Pharo one? >> What is the process to do this ? >> >> Cheers, >> Jannik >> >> >> On Dec 4, 2009, at 20:50 , Alexandre Bergel wrote: >> >>> Hi! >>> >>> I just tried Squeak.5.0.0.b9.64*64.app.zip, but I was not able to run >>> a pharo core on it. >>> I have a MacBookPro 10.5.8. I do not know whether this is helpful or >>> not. Feel free to ask more info about my config. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 5, 2009

Re: [Pharo-project] Protocol extension proposal: Boolean>>asBit ?

by Levente Uzonyi

On Sat, 5 Dec 2009, Igor Stasenko wrote: > I currently writing a code which looks like: > > a := some numeric expression + (someBoolean ifTrue: [1] ifFalse: [0]). > > And i get somewhat tired repeating the same pattern in multiple places. > So, i thinking , maybe #asBit convenience method could be useful? > It's useful IMO, so I use it whenever I need it. It's in the image with 7/1/2004 timestamp. Levente > True>>asBit > ^ 1 > False>>asBit > ^ 0 > > so, then, in case of need like above, we could write much shorter expressions: > a := some numeric expression + someBoolean asBit. > > And its much less error prone comparing to #ifTrue:ifFalse:, since i > found its relatively easy to make a mess (swapping 1 with 0), > especially, when you having negations in expression, because once you see: > > (someBoolean not ifTrue: [1] ifFalse: [0]) > > you always tempted to write it as: > > (someBoolean ifTrue: [0] ifFalse: [1]). > > or as: > > (someBoolean ifFalse: [1] ifTrue: [0]). > > but once you start playing with it, its very easy to shoot into own > feet if you are not careful. > > But if we could add #asBit, then we could write: > > someBoolean not asBit > > which is much more: > a) concise & cleaner > b) error proof > > > -- > 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 >

Dec. 5, 2009

Re: [Pharo-project] christmas coding parties?

by Lukas Renggli

> Yes, I also tought about RFB/VNC but how do to redirect the port?Â There > will be a router for sure and even maybe a proxy...so, redirecting the prt > 5900 or whatever to a certain pc will be maybe impossible to do it. That's why we ran the image on a server somewhere else and not on somebodies machine. It would have been too slow if two other people connected through my slow connection on my local RFB/VNC server. Furthermore RFB/VNC is typically used through an SSH tunnel, because RFB/VNC does not provide a security protocol. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 5, 2009

Re: [Pharo-project] christmas coding parties?

by Mariano Martinez Peck

On Sat, Dec 5, 2009 at 10:26 AM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > 2009/12/5 Lukas Renggli <renggli(a)gmail.com>: > >> You already try ? > > > > Yes, I even blogged about it: > > > > <http://www.lukas-renggli.ch/blog/pairprogramming> > > > > We used IRC for communication, but probably Skype audio/video would be > > better for that. I don't know if Skype can also do screen-sharing? > > Some all-in-one solution would probably be the easiest. > > > > Using a RFB/VNC server in Pharo is very cool and works well, > > especially the fact that you don't share your whole screen but just > > the Pharo window. It is not trivial to setup though, and certainly > > requires some work to get everything running smoothly. > > Looks interesting, i would like to participate once in order to see if > it works or not ;-) > Yes, maybe a predefined setup could help us using this kind of tools. > > Yes, I also tought about RFB/VNC but how do to redirect the port? There will be a router for sure and even maybe a proxy...so, redirecting the prt 5900 or whatever to a certain pc will be maybe impossible to do it. > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 5, 2009

Re: [Pharo-project] why OOP needs tails recursion article

by Igor Stasenko

2009/12/5 Lukas Renggli <renggli(a)gmail.com>: > We recently had a discussion on tail-call optimization at the SCG. In > one of my Pharo image I counted 160464 send locations, of which only > 8884 would allow for tail call optimization (5.5%). > > Tail call optimization could certainly be implemented at the VM level, > but I don't know if the additional checks and complexity would be > worth the effort for these few locations? VM experts might be able to > tell more ... > > Also I think it would be rather confusing to debug a tail-call > optimized program in the debugger (random stack frames would be > missing). > I am also looking suspiciously on such kind of optimization for smalltalk, because it could make debugging harder as well as breaking a reflection, since you can't be sure that 'thisContext sender' is one that actually made a call. In languages with lower reflection bar, such optimization could be employed, but in smalltalk, i doubt. > Lukas -- Best regards, Igor Stasenko AKA sig.

Dec. 5, 2009