3.9 vs. 3.10 : Closures, fixTemps

> I am struggling with local variables used across nested blocks (Magma
> #commit: within Seaside #callback: or Scriptaculous #triggerInPlaceEditor
> etc.) and am finding it quite frustrating. I had some #fixTemps but am
> totally guessing at when and why to use it.
>
> Thanks - Sophie
>
>
>
>
>

> 2007/12/18, itsme213 <[hidden email]>:
> > Do block closures work right in 3.9? 3.10?
>
> No, block closures are broken in every Squeak. You have to load the
> NewCompiler and activate two compiler settings to get working block
> closures. You'll have to live with some other issues though.
>
> Cheers
> Philippe
>
>
> > I am struggling with local variables used across nested blocks (Magma
> > #commit: within Seaside #callback: or Scriptaculous #triggerInPlaceEditor
> > etc.) and am finding it quite frustrating. I had some #fixTemps but am
> > totally guessing at when and why to use it.
> >
> > Thanks - Sophie
> >
> >
> >
> >
> >
>
>

> On Dec 18, 2007 2:08 PM, Philippe Marschall
> <[hidden email]> wrote:
> > 2007/12/18, itsme213 <[hidden email]>:
> > > Do block closures work right in 3.9? 3.10?
> >
> > No, block closures are broken in every Squeak. You have to load the
> > NewCompiler and activate two compiler settings to get working block
> > closures. You'll have to live with some other issues though.
> >
> > Cheers
> > Philippe
> >
> >
> > > I am struggling with local variables used across nested blocks (Magma
> > > #commit: within Seaside #callback: or Scriptaculous #triggerInPlaceEditor
> > > etc.) and am finding it quite frustrating. I had some #fixTemps but am
> > > totally guessing at when and why to use it.
> > >
> > > Thanks - Sophie
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>

> Philippe Marschall wrote:
> > The compiler itself works and can be loaded into 3.9 without problems.
>
> Unfortunately, I can't confirm the "working without problems" part in
> 3.9. For testing the speed I was copying class Object and it barfed
> halfways through in #copyTwoLevel in a perfectly valid expression:
>
> class isVariable ifTrue:[
>    index _ self basicSize.
>    [index > 0] whileTrue:[
>      newObject basicAt: index put: (self basicAt: index) shallowCopy.
>      index _ index - 1]"xxxxx Argument expected ->xxxxx"].
>
> (note: you can just select the expression in a workspace and doIt if you
> have compileUseNewCompiler enabled; it'll complain right away) This is
> very strange and the error message makes little sense to me - I tried
> adding a period because perhaps it was expecting a message to the block
> but that doesn't do it. Has anyone tried to simply recompile the
> entirety of 3.9 to see if that works or not? I've been using
> 3.9-final-7067 for my test with the latest published Squeakmap releases
> for AST and NewCompiler. If there is a better version to use, please let
> me know.

> [BTW, there are many other obscure errors that happen when I simply
> remove the offending code and continue to compile. Ultimately it appears
> to die somewhere unrelated at first glance but since this only happens
> when using compileUseNewCompiler I'm pretty sure it's related to some
> NewCompiler issues]
>
> > Error messages are much improved and unlike your standard SmaCC error
> > messages. Performance is lower. There is a lot of work going on in the
> > decompiler and I don't know the exact state of this.
>
> Nice to hear about the error messages. I hadn't tried the compiler in a
> while but the above really shows that error messages really have greatly
> improved.
>
> Concerning speed: When doing an [Object2 compileAll] timeToRun (Object2
> being the partial copy of class Object that NewCompiler was able to hand
> me) I ended up with 1444 msecs for Compiler and 4020 msecs for
> NewCompiler. Unless I'm mistaken this is an improvement over the last
> version I tried which was roughly 4x slower (this is still 2.8x slower
> but it's a definitive improvement).

>> Concerning speed: When doing an [Object2 compileAll] timeToRun (Object2
>> being the partial copy of class Object that NewCompiler was able to hand
>> me) I ended up with 1444 msecs for Compiler and 4020 msecs for
>> NewCompiler. Unless I'm mistaken this is an improvement over the last
>> version I tried which was roughly 4x slower (this is still 2.8x slower
>> but it's a definitive improvement).
>
> I wasn't talking about compilation speed. What's really limiting for
> bigger projects is not the speed of the compiler but PackageInfo which
> makes Monticello slow. I was talking about execution speed.

> Would you mind sharing what details you know about the current state
> of closures and what the trade-offs are using the NewCompiler?
>
> And, do you know of any energy focused on improving the existing  
> alternatives?
>
>
> On Dec 18, 2007 2:08 PM, Philippe Marschall
> <[hidden email]> wrote:
>> 2007/12/18, itsme213 <[hidden email]>:
>>> Do block closures work right in 3.9? 3.10?
>>
>> No, block closures are broken in every Squeak. You have to load the
>> NewCompiler and activate two compiler settings to get working block
>> closures. You'll have to live with some other issues though.
>>
>> Cheers
>> Philippe
>>
>>
>>> I am struggling with local variables used across nested blocks  
>>> (Magma
>>> #commit: within Seaside #callback: or Scriptaculous  
>>> #triggerInPlaceEditor
>>> etc.) and am finding it quite frustrating. I had some #fixTemps  
>>> but am
>>> totally guessing at when and why to use it.
>>>
>>> Thanks - Sophie
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

> Philippe Marschall wrote:
>> The compiler itself works and can be loaded into 3.9 without  
>> problems.
>
> Unfortunately, I can't confirm the "working without problems" part  
> in 3.9. For testing the speed I was copying class Object and it  
> barfed halfways through in #copyTwoLevel in a perfectly valid  
> expression:
>
> class isVariable ifTrue:[
>   index _ self basicSize.
>   [index > 0] whileTrue:[
>     newObject basicAt: index put: (self basicAt: index) shallowCopy.
>     index _ index - 1]"xxxxx Argument expected ->xxxxx"].
>
> (note: you can just select the expression in a workspace and doIt  
> if you have compileUseNewCompiler enabled; it'll complain right  
> away) This is very strange and the error message makes little sense  
> to me - I tried adding a period because perhaps it was expecting a  
> message to the block but that doesn't do it. Has anyone tried to  
> simply recompile the entirety of 3.9 to see if that works or not?  
> I've been using 3.9-final-7067 for my test with the latest  
> published Squeakmap releases for AST and NewCompiler. If there is a  
> better version to use, please let me know.
>
> [BTW, there are many other obscure errors that happen when I simply  
> remove the offending code and continue to compile. Ultimately it  
> appears to die somewhere unrelated at first glance but since this  
> only happens when using compileUseNewCompiler I'm pretty sure it's  
> related to some NewCompiler issues]
>
>> Error messages are much improved and unlike your standard SmaCC error
>> messages. Performance is lower. There is a lot of work going on in  
>> the
>> decompiler and I don't know the exact state of this.
>
> Nice to hear about the error messages. I hadn't tried the compiler  
> in a while but the above really shows that error messages really  
> have greatly improved.
>
> Concerning speed: When doing an [Object2 compileAll] timeToRun  
> (Object2 being the partial copy of class Object that NewCompiler  
> was able to hand me) I ended up with 1444 msecs for Compiler and  
> 4020 msecs for NewCompiler. Unless I'm mistaken this is an  
> improvement over the last version I tried which was roughly 4x  
> slower (this is still 2.8x slower but it's a definitive improvement).
>
>> You should ask Marcus about what the current status exactly is. Or  
>> Klaus.
>
> It would be a big step if it were possible to recompile Squeak  
> successfully and perhaps even bytecode-identically. Being able to  
> generate an identical version of the method would allow people to  
> trivially verify the correct functioning of NewCompiler.
>
>>> And, do you know of any energy focused on improving the existing  
>>> alternatives?
>> What alternatives?
>
> The compiler that's actually being used. The one that's 3x  
> faster ;-) If NewCompiler worked properly I'd be actually quite  
> tempted to just adopt the closure solution to the current compiler  
> since it's smaller, faster, and well-established.
>
> Cheers,
>   - Andreas
>
>

> Philippe Marschall wrote:
>>> Concerning speed: When doing an [Object2 compileAll] timeToRun  
>>> (Object2
>>> being the partial copy of class Object that NewCompiler was able  
>>> to hand
>>> me) I ended up with 1444 msecs for Compiler and 4020 msecs for
>>> NewCompiler. Unless I'm mistaken this is an improvement over the  
>>> last
>>> version I tried which was roughly 4x slower (this is still 2.8x  
>>> slower
>>> but it's a definitive improvement).
>> I wasn't talking about compilation speed. What's really limiting for
>> bigger projects is not the speed of the compiler but PackageInfo  
>> which
>> makes Monticello slow. I was talking about execution speed.
>
> I see. Has anyone measured the performance of the micro and macro  
> benchmarks with the entire system compiled for using closures? I'm  
> particularly interested in the macro benchmarks.
>
>>>> You should ask Marcus about what the current status exactly is.  
>>>> Or Klaus.
>>> It would be a big step if it were possible to recompile Squeak
>>> successfully
>> The NewCompiler images from Marcus do this since a long time ago. See
>> the Recompiler class.
>
> Ah, good.
>
>>> and perhaps even bytecode-identically.
>> Nah, NewCompiler in certain circumstances generates marginally more
>> efficient bytecode.
>
> This may actually be worthwhile "undoing" simply for being able to  
> verify correctness.

>
>
>>>>> And, do you know of any energy focused on improving the existing  
>>>>> alternatives?
>>>> What alternatives?
>>> The compiler that's actually being used. The one that's 3x  
>>> faster ;-)
>> The one that's causing so much trouble in Seaside? The that gives you
>> this cool C++ feeling bugs where you spend two hours trying to find
>> out why your block arguments are all messed up and you think you went
>> crazy? And then suddenly you add a lot of #fixTemps everywhere until
>> it works?
>
> Am I missing a smiley somewhere? You are describing properties that  
> apply to NewCompiler just as well if you disable closure compilation  
> and there is really no reason whatsoever why a working closure  
> solution couldn't be adopted to the current compiler (which would  
> mitigate the risk factors of adoption dramatically). Just like I was  
> saying in the part you'd snipped away I'd be quite interested in  
> adopting a working solution (which doesn't strike me as hard given  
> the simplistic nature of the current compiler).
>
> BTW, since you phrase it as such a big deal, is anyone using  
> NewCompiler with Seaside? If it is really as problematic as you make  
> it above I'd expect to see users of Seaside using it. Do they? If  
> so, what's the practical experience?
>
> Cheers,
>  - Andreas
>

> Do block closures work right in 3.9? 3.10?
>
> I am struggling with local variables used across nested blocks (Magma
> #commit: within Seaside #callback: or Scriptaculous  
> #triggerInPlaceEditor
> etc.) and am finding it quite frustrating. I had some #fixTemps but am
> totally guessing at when and why to use it.
>
> Thanks - Sophie
>
>
>
>

> Philippe Marschall wrote:
> >> Concerning speed: When doing an [Object2 compileAll] timeToRun (Object2
> >> being the partial copy of class Object that NewCompiler was able to hand
> >> me) I ended up with 1444 msecs for Compiler and 4020 msecs for
> >> NewCompiler. Unless I'm mistaken this is an improvement over the last
> >> version I tried which was roughly 4x slower (this is still 2.8x slower
> >> but it's a definitive improvement).
> >
> > I wasn't talking about compilation speed. What's really limiting for
> > bigger projects is not the speed of the compiler but PackageInfo which
> > makes Monticello slow. I was talking about execution speed.
>
> I see. Has anyone measured the performance of the micro and macro
> benchmarks with the entire system compiled for using closures? I'm
> particularly interested in the macro benchmarks.
>
> >>> You should ask Marcus about what the current status exactly is. Or Klaus.
> >> It would be a big step if it were possible to recompile Squeak
> >> successfully
> >
> > The NewCompiler images from Marcus do this since a long time ago. See
> > the Recompiler class.
>
> Ah, good.
>
> >> and perhaps even bytecode-identically.
> >
> > Nah, NewCompiler in certain circumstances generates marginally more
> > efficient bytecode.
>
> This may actually be worthwhile "undoing" simply for being able to
> verify correctness.
>
> >>>> And, do you know of any energy focused on improving the existing alternatives?
> >>> What alternatives?
> >> The compiler that's actually being used. The one that's 3x faster ;-)
> >
> > The one that's causing so much trouble in Seaside? The that gives you
> > this cool C++ feeling bugs where you spend two hours trying to find
> > out why your block arguments are all messed up and you think you went
> > crazy? And then suddenly you add a lot of #fixTemps everywhere until
> > it works?
>
> Am I missing a smiley somewhere?

> Philippe Marschall wrote:
>>> Concerning speed: When doing an [Object2 compileAll] timeToRun  
>>> (Object2
>>> being the partial copy of class Object that NewCompiler was able  
>>> to hand
>>> me) I ended up with 1444 msecs for Compiler and 4020 msecs for
>>> NewCompiler. Unless I'm mistaken this is an improvement over the  
>>> last
>>> version I tried which was roughly 4x slower (this is still 2.8x  
>>> slower
>>> but it's a definitive improvement).
>> I wasn't talking about compilation speed. What's really limiting for
>> bigger projects is not the speed of the compiler but PackageInfo  
>> which
>> makes Monticello slow. I was talking about execution speed.
>
> I see. Has anyone measured the performance of the micro and macro  
> benchmarks with the entire system compiled for using closures? I'm  
> particularly interested in the macro benchmarks.
>
>>>> You should ask Marcus about what the current status exactly is.  
>>>> Or Klaus.
>>> It would be a big step if it were possible to recompile Squeak
>>> successfully
>> The NewCompiler images from Marcus do this since a long time ago. See
>> the Recompiler class.
>
> Ah, good.
>
>>> and perhaps even bytecode-identically.
>> Nah, NewCompiler in certain circumstances generates marginally more
>> efficient bytecode.
>
> This may actually be worthwhile "undoing" simply for being able to  
> verify correctness.
>
>>>>> And, do you know of any energy focused on improving the existing  
>>>>> alternatives?
>>>> What alternatives?
>>> The compiler that's actually being used. The one that's 3x  
>>> faster ;-)
>> The one that's causing so much trouble in Seaside? The that gives you
>> this cool C++ feeling bugs where you spend two hours trying to find
>> out why your block arguments are all messed up and you think you went
>> crazy? And then suddenly you add a lot of #fixTemps everywhere until
>> it works?
>
> Am I missing a smiley somewhere? You are describing properties that  
> apply to NewCompiler just as well if you disable closure compilation  
> and there is really no reason whatsoever why a working closure  
> solution couldn't be adopted to the current compiler (which would  
> mitigate the risk factors of adoption dramatically). Just like I was  
> saying in the part you'd snipped away I'd be quite interested in  
> adopting a working solution (which doesn't strike me as hard given  
> the simplistic nature of the current compiler).

>
>
> BTW, since you phrase it as such a big deal, is anyone using  
> NewCompiler with Seaside? If it is really as problematic as you make  
> it above I'd expect to see users of Seaside using it. Do they? If  
> so, what's the practical experience?
>
> Cheers,
>  - Andreas
>

> "Mathieu Suen" <[hidden email]> wrote
>
>> The NewCompiler status is:
>>
>> Compiler:
>> - Block closure - Work
>
>
> I have not yet tried NewCompiler, but here is one that does not work  
> in
> 3.10. At point 1>>, newModel is correct and non-nil. At point 2>>  
> newModel

>
> is nil. I'm trying this on 3.10gamma.
>
> Thanks -- Sophie
>
> renderNewModelButton: html
>  { M1. M2 } do:
>    [ : modelClass |
>       html submitButton
>       callback:
>         [ | newModel |
>           self session magma commit: [
>             newModel := self repository models add: modelClass new.
> 1>>          self halt] fixTemps.
>             self halt.
> 2>>          self call: (newModel viewerClass new model: newModel).
>             selectedModel := nil ] fixTemps;
>       value: #New , ' ' , modelClass name ]
>
>> Decompiler
>>  - Block closure - Don't Work (That should not take too long to fix  
>> it)
>
> That would unfortunately make it impossible for newbies like me to  
> debug
> etc.
>
>
>
>

> renderNewModelButton: html
>   { M1. M2 } do:
>     [ : modelClass |
>        html submitButton
>        callback:
>          [ | newModel |
>              self session magma commit: [
>               newModel := self repository models add: modelClass new.]
>
>              self call: (newModel viewerClass new model: newModel).
>              selectedModel := nil ] fixTemps;  value: #New , ' ' ,  
> modelClass name ]
>
> On Dec 19, 2007, at 3:08 PM, itsme213 wrote:
>
>> "Mathieu Suen" <[hidden email]> wrote
>>
>>> The NewCompiler status is:
>>>
>>> Compiler:
>>> - Block closure - Work
>>
>>
>> I have not yet tried NewCompiler, but here is one that does not work in
>> 3.10. At point 1>>, newModel is correct and non-nil. At point 2>>  
>> newModel
>
> Of cours at pont 2 is nil cause:
> The #fixTemps of the commit block will create a copy of the newModel  
> temp.
> Then when you affect a value to the newModel inside the block you are  
> affecting the copy not the original one.
>
> Will the second fix temp will prevent you having modelClass being the  
> same for the commit  of M1 and M2.
> It will copy the modelClass temps.
>
> Ask if I haven't been clear.
>
> Cheers,
>
>>
>> is nil. I'm trying this on 3.10gamma.
>>
>> Thanks -- Sophie
>>
>> renderNewModelButton: html
>>  { M1. M2 } do:
>>    [ : modelClass |
>>       html submitButton
>>       callback:
>>         [ | newModel |
>>           self session magma commit: [
>>             newModel := self repository models add: modelClass new.
>> 1>>          self halt] fixTemps.
>>             self halt.
>> 2>>          self call: (newModel viewerClass new model: newModel).
>>             selectedModel := nil ] fixTemps;
>>       value: #New , ' ' , modelClass name ]
>>
>>> Decompiler
>>>  - Block closure - Don't Work (That should not take too long to fix it)
>>
>> That would unfortunately make it impossible for newbies like me to debug
>> etc.
>>
>>
>>
>>
>
> Mth
>
>
>
>
>

> Philippe Marschall wrote:
>>> there is really no reason whatsoever why a working closure solution
>>> couldn't be adopted to the current compiler (which would mitigate  
>>> the
>>> risk factors of adoption dramatically).
>> They why was the closure solution of the new compiler rejected?
>
> "The closure solution rejected"? Not that I know of. I haven't even  
> seen a thorough discussion about its merits (which should include  
> benchmarks etc) - what I did see was some talk that led me to  
> believe that there is still a ways to go here. To the best of my  
> knowledge this solution isn't "final" by any means.
>
> Or do you mean the compiler itself? In which case all I can say  
> it's hard to recommend a compiler which can't even recompile  
> Object ;-)
>
> Cheers,
>   - Andreas
>
>
>