New Window VM (Closures, FT2Plugin, Large Cursors)

Folks -

Since I was in VM building mode today I figured I might as well make a new Squeak VM. There is some interesting new stuff in it:

* Closure support. This VM is based on VMMaker-dtl.116 meaning it includes support for the closure bytecodes. I have verified it by both running a Qwaq image on this VM and and a converted closure image on our Stack VM (this is useful since the Stack VM will die a horrible death something goes wrong in the process). It worked fine both ways which means that I no longer need to switch VMs (yay! ;-)

* Experimental large cursor support. Try the following for fun (but don't do it in an image you care about):

       cursor := Cursor extent: 128@128 depth: 32.
       cursor offset: -64@-64.
       cursor getCanvas
               fillOval: cursor boundingBox color: (Color white alpha: 0.1);
               frameOval: cursor boundingBox width: 4 color: Color red;
               line: 62@64 to: 66@64 width: 1 color: Color blue;
               line: 64@62 to: 64@66 width: 1 color: Color blue.
       Cursor classPool at: #NormalCursor put: cursor.

This changes your normal cursor to be a 128x128 pixels large, translucent cursor.

* FT2Plugin. The build includes an external FT2Plugin that has no dependencies on extra DLLs.

The downloads are in the usual places:
http://squeakvm.org/win32/release/SqueakVM-Win32-3.11.1-bin.zip
http://squeakvm.org/win32/release/SqueakVM-Win32-3.11.1-src.zip

A closure image (for those interested):
http://squeakvm.org/win32/release/Squeak-3.10.2-Closures.zip

Note that I consider this an "alpha" version since there is a goodly bit of new and untested stuff in it. I'm in particular interested in finding people to test large cursor support and the FT2Plugin.

Feedback is highly welcome.

Cheers,
 - Andreas

Ah, I have a bias opinion for an answer, but I'll not discuss that here.

However the BIG issue for the 3.8.x and earlier series of macintosh carbon VM is their behaviour for opening a closure image.
What you will find is that if you attempt to open a closure image the squeak.app will start then terminate
It will print a diagnostic message to the console which you can see via Apple's Console.app found in Applications/Utilities.

07/03/09 11:11:51 AM [0x0-0x8d08d].org.squeak.Squeak[1894] This interpreter (vers. 6502) cannot read image file (vers. 6504).
07/03/09 11:11:51 AM [0x0-0x8d08d].org.squeak.Squeak[1894] Press CR to quit...

The reason for this behaviour is that 15 some years back John Maloney coded up the version checking logic and  there was a question
what to do now. At the time CodeWarrior under os-7.5.x would helpfully put up a dialog window if you printed to the *console* and did
a getchar for the answer, that code has moved forward for years now and no-one really has tested until now.

Interestingly the getchar on os-x does not block and returns null and we terminate the VM, but the behaviour is confusing if you don't
understand what is going on.

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.

On 7-Mar-09, at 8:12 AM, Andreas Raab wrote:

Bert Freudenberg wrote:

John bumped the Mac VM's major version to 4 to signify closure support. Maybe the other platforms should follow suit?

I figured v4 would signify the Stack VM or later as this VM will no longer be able to run v3 images. The current set of VMs are fully backwards compatible so I consider them logically to be v3 VMs.

But I'm willing to reconsider if people prefer the v4 terminology.

Cheers,
 - Andreas

--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

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