[squeak-dev] New Window VM (Closures, FT2Plugin, Large Cursors)

Rob Rothwell wrote:

Perfect!

Thanks...sorry for missing that the two were the same...

No worries. I've updated the image [1] with Eliot's patch so if you download the latest all should work as you expected it to.

[1]http://squeakvm.org/win32/release/Squeak-3.10.2-Closures.zip

Cheers,
 - Andreas

Rob

On Sun, Mar 8, 2009 at 6:47 PM, Andreas Raab <[hidden email] <mailto:[hidden email]>> wrote:

   That is the bug Eliot was referring to earlier. The loop variable in
   optimized to:do: loops wasn't handled correctly. Try this instead:


          multiply := Array new: 4.
          (1 to: 4) do: [:i |
                  multiply at: i put: [:x | x * i].
          ].

   Note the parens around "1 to: 4" which prevents the block from being
   optimized.

   Cheers,
    - Andreas


   Rob Rothwell wrote:

       Ok...thanks...this is making sense!

       So...should I get the "right answer" with the new VM and the
       3.10.2-Closures image?

       Because...I still get 25!

       Rob

       On Sun, Mar 8, 2009 at 2:01 PM, Bert Freudenberg
       <[hidden email] <mailto:[hidden email]>

       <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

          On 08.03.2009, at 18:13, Rob Rothwell wrote:

              On Sun, Mar 8, 2009 at 12:38 PM, Bert Freudenberg
              <[hidden email] <mailto:[hidden email]>

       <mailto:[hidden email] <mailto:[hidden email]>>> wrote:

                  multiply := Array new: 4.
                  1 to: 4 do: [:i |
                        multiply at: i put: [:x | x * i].
                  ].

                  And you would rightfully assume that this is
       equivalent to
                  the version above, just more concise. But now try again:

                  (multiply at: 3) value: 5.

                  The answer will, surprisingly, not be 15 in current
       Squeak.


              You are right!  25, in fact...

                  But with closures, the blocks would behave as
       expected. They
                  are said to "close over" the state that the bound
       variables
                  (i in this case) had at the time the block was created.


              So...VW does this "right," I guess, since I get 15 in VW
       NC 7.6?


          Yes, it has block closures.


                  So basically, you can use blocks as you always have, but
                  they will behave as you might have assumed they would.

              So the recent VM work discussed handles this?  I will have to
              give that a try!

              Thanks for the explanation!  The next question, of course, is
              WHY does it get 25 and not 15... ;)



          Because instead of "closing over" the current value of i when the
          block is created, all the blocks share the same reference to i,
          which is actually another temporary variable of the method,
       instead
          of being local to the block. So when the block is evaluated
       later,
          the last value of i is used.

          Now you might still expect that last value of i to be 4, but
          actually "1 to: 4 do:" is expanded by the compiler to a while
       loop
          like "i := 1. [i <= 4] whileTrue: [i := i + 1]", so it
       actually is 5
          after the loop terminates.

          And all this is avoided by having real closures, the i would
       indeed
          be local to the block and not a shared temp.

          - Bert -




       ------------------------------------------------------------------------

------------------------------------------------------------------------

On Sun, 08 Mar 2009 21:46:44 +0100, Eliot Miranda wrote:

Eliot (phone)

On 7 Mar 2009, at 22:24, "Klaus D. Witzel" wrote:

On Sat, 07 Mar 2009 18:51:01 +0100, Eliot Miranda wrote:

Hi Klaus,

Hi Eliot,

great job, native closures-support was overdue and is appreciated by the Squeakers.

You're so welcome! I'm looking forward to the quality of the implementation improving with wider usage. Lukas has already sent me a bug report for which we have an acceptable fix.

You may perhaps also want to check the attachment from Mantis #7311 that I created a minute ago:

- http://bugs.squeak.org/view.php?id=7311

This .st has 61 tests which I've written for Marcus' NewCompiler project (testing sourceCode -> Parser -> nodes -> compiled method -> InstructionStream). Made a small change for adapting them to your passing EncoderForV3 to the parser. BTW: all green in the recent Squeak-3.10.2-Closures.image ;)

There's perhaps more to come, did a buch of tests for Igor's parser for Moebius, mainly around syntax constructs. Adapting them may need some effort+time, they depend on accurate reporting of source code position.

/Klaus

Best
Eliot (mobile compromised)

...

--
"If at first, the idea is not absurd, then there is no hope for it". Albert Einstein

On Mon, 09 Mar 2009 19:02:27 +0100, Eliot Miranda wrote:

On Mon, Mar 9, 2009 at 1:23 AM, Klaus D. Witzel wrote:

...

You may perhaps also want to check the attachment from Mantis #7311 that I
created a minute ago:

- http://bugs.squeak.org/view.php?id=7311

This .st has 61 tests which I've written for Marcus' NewCompiler project
(testing sourceCode -> Parser -> nodes -> compiled method ->
InstructionStream). Made a small change for adapting them to your passing
EncoderForV3 to the parser. BTW: all green in the recent
Squeak-3.10.2-Closures.image ;)

Cool!  But TBH let's add a little yellow:

testInlineBlockCollection1
| col |
col := OrderedCollection new.
1 to: 11 do: [ :each | col add: [ each ] ].
self assert: (col collect: [ :each | each value ]) asArray = (1 to: 11)
asArray

testInlineBlockCollection2
| col |
col := OrderedCollection new.
1 to: 11 do: [ :each | | i | i := each. col add: [ i ]. i := i + 1 ].
self assert: (col collect: [ :each | each value ]) asArray = (2 to: 12)
asArray

Yellow, right, and they belong into ClosureCompilerTest. But they also raise questions:

I've seen that one of the differences between the Encoder*XYZ's is #supportsClosureOpcodes being true/false but also #generateAsClosure plays a role. So the *Closures suffix is short for *EmitClosuresBytecode? Also, blocks are never emitted the old (non-closure) way?

If they where (under whatever *config*, blocks emitted the old way) then both tests can only fail, that's why I ask.

/Klaus

--
"If at first, the idea is not absurd, then there is no hope for it". Albert Einstein

Keith Hodges wrote:
> Keith Hodges wrote:
>
>>> I will at some point push out a 3.8.22 VM that should put up a more
>>> helpful dialog message, but people who have older VMs underfoot
>>> should realize this behaviour should be an indication that perhaps
>>> your VM is too old.
>>>
>>>
>> Unfortunately the machine that I have designated for Bob to be an auto
>> build/test server is a power-pc machine. What are the chances of a
>> power-pc version of the closures vm?
>>
>> just interested to know
>>
>> Keith
>>
> Ok I see it is designated beta1U for universal, so the problem lies
> elsewhere!
>
> Keith
>

OK so assigining to closure temporaries is no-longer allowed and flags a
syntax error (not my code you understand)

Keith

Keith Hodges wrote:
> Keith Hodges wrote:
>
>> Keith Hodges wrote:
>>
>>
>>>> I will at some point push out a 3.8.22 VM that should put up a more
>>>> helpful dialog message, but people who have older VMs underfoot
>>>> should realize this behaviour should be an indication that perhaps
>>>> your VM is too old.
>>>>
>>>>
>>>>
>>> Unfortunately the machine that I have designated for Bob to be an auto
>>> build/test server is a power-pc machine. What are the chances of a
>>> power-pc version of the closures vm?
>>>
>>> just interested to know
>>>
>>> Keith
>>>
>>>
>> Ok I see it is designated beta1U for universal, so the problem lies
>> elsewhere!
>>
>> Keith
>>
>>
> OK so assigining to closure temporaries is no-longer allowed and flags a
> syntax error (not my code you understand)
>
> Keith
>

Does this mean that existing compiled code is expected to work, but an
image recompile could cause problems?

I have just fixed an instance in MCzInstaller>>#associate: Which assigns
to the block temporary.

associate: tokens
   | result |
   result _ Dictionary new.
   tokens pairsDo: [:key :value |
                   value isString ifFalse: [value _ value collect: [:ea
| self associate: ea]].
                   value = 'nil' ifTrue: [value _ ''].
                   result at: key put: value].
   ^ result

The fix is so ugly that I am beginning to think that assigning to a
block temp isn't such a bad idea after all.

Keith

Hi Eliot,

On Tue, 10 Mar 2009 01:04:29 +0100, Eliot Miranda wrote:

Hi Klaus,

On Mon, Mar 9, 2009 at 11:04 AM, Klaus D. Witzel wrote:

...

I've seen that one of the differences between the Encoder*XYZ's is
#supportsClosureOpcodes being true/false but also #generateAsClosure plays a
role. So the *Closures suffix is short for *EmitClosuresBytecode? Also,
blocks are never emitted the old (non-closure) way?

The scheme is that by choosing the encoder one can choose the type of code generated.  So that e.g. if you say

(Parser new
encoderClass: EncoderForV3PlusClosures;
parse: someString readStream class: MyClass)
 generate: #(0 0 0 0)

you'll get closure code and if you say

(Parser new
encoderClass: EncoderForV3;
parse: someString readStream class: MyClass)
 generate: #(0 0 0 0)

you'll get pre-closure old-block code.

Okay thanks, perfectly clear now.

...

And on the wrong VM it'll crash.  Only the CLosure VM that people are
providing right now can run both new and old code.  The StackVM we have in
Qwaq (that I hope will be released sometime) will only run Closure code and die horribly if given old block code.

This implies that any test*ABC method which compiles source code and passes the wrong Encoder*XYZ to Parser can crash its VM. So one has to check, in such tests, what VM type is running. How can the VM be queried for that?

/Klaus

--
"If at first, the idea is not absurd, then there is no hope for it". Albert Einstein