New Window VM (Closures, FT2Plugin, Large Cursors)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

New Window VM (Closures, FT2Plugin, Large Cursors)

Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Klaus D. Witzel
 
On Sat, 07 Mar 2009 08:38:32 +0100, Andreas Raab wrote:

> Folks -
>
> Since I was in VM building mode today I figured I might as well make a  
> new Squeak VM.

Hey, great :) thank you.

...

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

This VM also opens and runs Squeak3.10.2-7179-basic.image :) and fonts [I  
have some exotic fonts in use] are rendered fine :)

> 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.

I can't see why but the 3.11.1 VM refuses to open  
Squeak-3.10.2-Closures.image :( windoze (vista) pops up a small window  
with Squeak! in title bar and message text "Could not open image file".  
FWIW the .image file has 15.367 KB.

> Cheers,
>    - Andreas

Thanks again !

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

Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Bert Freudenberg
In reply to this post by Andreas.Raab
 
On 07.03.2009, at 08:38, Andreas Raab wrote:

> 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! ;-)

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

> * 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.

Nice. Looks like it's time to add the image support? These changesets  
add a CursorWithAlpha that can be used for nice large colorful  
cursors. It has a "fallback" cursor used on VMs that do not support  
the new cursors yet.

http://tinlizzie.org/updates/olpc/updates/1252biggerCursors-bf.cs
http://tinlizzie.org/updates/olpc/updates/1260bigCursorFix-bf.cs
http://tinlizzie.org/updates/olpc/updates/1282bigTempCursor-bf.cs

- Bert -

> * 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



Reply | Threaded
Open this post in threaded view
|

Re: Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Brad Fowlow-2
In reply to this post by Klaus D. Witzel
 
>
>

I think the image format was incremented for closures.
Does the 3.11.1 have the same closure support,
and was its the image-format number check adjusted,
using the same conventions as the ones in Andreas ?

(I dunno, just suggesting a possible cause.
I only use the Andreas / Qwaq vm supply.
The image format number was bumped here as part of our switch to  
closure,
and those images cannot be loaded by prior vm's.)

(The format number I mean is
        Smalltalk vmParameterAt: 41 )


- brad


> I can't see why but the 3.11.1 VM refuses to open Squeak-3.10.2-
> Closures.image :( windoze (vista) pops up a small window with  
> Squeak! in title bar and message text "Could not open image file".  
> FWIW the .image file has 15.367 KB.
>
>> Cheers,
>>   - Andreas
>
> Thanks again !
>
> --
> "If at first, the idea is not absurd, then there is no hope for it".  
> Albert Einstein
>

Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Nikolay Suslov
In reply to this post by Andreas.Raab
 
Andreas,
It's great!

And is there a change set to make the current Croquet 1.0.18.image (3.8 based) closure ready also?

Thanks,
Nikolay

On Sat, Mar 7, 2009 at 8:38 AM, Andreas Raab <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: New Window VM (Closures, FT2Plugin, Large Cursors)

David T. Lewis
In reply to this post by Brad Fowlow-2
 
On Sat, Mar 07, 2009 at 01:41:16AM -0800, brad fowlow wrote:
>
> I think the image format was incremented for closures.
> Does the 3.11.1 have the same closure support,
> and was its the image-format number check adjusted,
> using the same conventions as the ones in Andreas ?
>

The image format number is changed if and only if the compiler
has actually generated some of the new closure bytecodes in your
image. If you run an image without closure support on the new VM,
the image format number will not be modified. The logic for setting
and checking the image format number is all included in class
Interpreter (not in any external packages or support code).

The image format numbers now in use are:

 6502 ==> normal 32-bit image (Smalltalk wordSize == 4)
 6504 ==> 32-bit image with closures
 68000 ==> 64-bit image (Smalltalk wordSize == 8)
 68002 ==> 64-bit image with closures

Dave
 
Reply | Threaded
Open this post in threaded view
|

Re: Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Andreas.Raab
In reply to this post by Klaus D. Witzel
 
Klaus D. Witzel wrote:

>> 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.
>
> I can't see why but the 3.11.1 VM refuses to open
> Squeak-3.10.2-Closures.image :( windoze (vista) pops up a small window
> with Squeak! in title bar and message text "Could not open image file".
> FWIW the .image file has 15.367 KB.

That's very odd. I just tried a clean download and it works fine for me
here. The image size should be 15,735,052 bytes. Can you download the
image again and see if you still have that problem? Can someone else
confirm or deny whether that image works for them?

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Andreas.Raab
In reply to this post by Bert Freudenberg
 
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
Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Andreas.Raab
In reply to this post by Nikolay Suslov
 
Nikolay Suslov wrote:
> And is there a change set to make the current Croquet 1.0.18.image (3.8
> based) closure ready also?

We have originally tested the bootstrap against Croquet 1.0.18 and
Squeak 3.9.1 so it should work out of the box. Just download the code
from http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/ (grab
the tar file and extract it) and follow the instructions.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Klaus D. Witzel
In reply to this post by Andreas.Raab
 
On Sat, 07 Mar 2009 17:10:13 +0100, Andreas Raab wrote:

> Klaus D. Witzel wrote:
>>> 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.
>>  I can't see why but the 3.11.1 VM refuses to open  
>> Squeak-3.10.2-Closures.image :( windoze (vista) pops up a small window  
>> with Squeak! in title bar and message text "Could not open image file".  
>> FWIW the .image file has 15.367 KB.
>
> That's very odd. I just tried a clean download and it works fine for me  
> here. The image size should be 15,735,052 bytes. Can you download the  
> image again and see if you still have that problem?

Did that, now it opens and shows "This is a closure-converted image. You  
will not be able to run this image with pre-3.11 VMs. etc" thanks again.

> Can someone else confirm or deny whether that image works for them?
>
> Cheers,
>    - Andreas

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

Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

johnmci
In reply to this post by Andreas.Raab
 
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
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: New Window VM (Closures, FT2Plugin, Large Cursors)

Eliot Miranda-2
 


On Sat, Mar 7, 2009 at 11:23 AM, John M McIntosh <[hidden email]> wrote:

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.

yes, please.  I stumbled across the code this week and the last few statements don't make sense on a number of platforms, because they presume a command-line:

checkImageVersionFrom: f startingAt: imageOffset
"Read and verify the image file version number and return true if the the given image file needs to be byte-swapped. As a side effect, position the file stream just after the version number of the image header. This code prints a warning and does a hard-exit if it cannot find a valid version number."
"This code is based on C code by Ian Piumarta."

| version firstVersion |
<var: #f type: 'sqImageFile '>
<var: #imageOffset type: 'squeakFileOffsetType '>

"check the version number"
self sqImageFile: f Seek: imageOffset.
version := firstVersion := self getLongFromFile: f swap: false.
(self readableFormat: version) ifTrue: [^ false].

"try with bytes reversed"
self sqImageFile: f Seek: imageOffset.
version := self getLongFromFile: f swap: true.
(self readableFormat: version) ifTrue: [^ true].

"Note: The following is only meaningful if not reading an embedded image"
imageOffset = 0 ifTrue:[
"try skipping the first 512 bytes (prepended by certain Mac file transfer utilities)"
self sqImageFile: f Seek: 512.
version := self getLongFromFile: f swap: false.
(self readableFormat: version) ifTrue: [^ false].

"try skipping the first 512 bytes with bytes reversed"
self sqImageFile: f Seek: 512.
version := self getLongFromFile: f swap: true.
(self readableFormat: version) ifTrue: [^ true]].

"hard failure; abort"
self print: 'This interpreter (vers. '.
self printNum: self imageFormatVersion.
self print: ') cannot read image file (vers. '.
self printNum: firstVersion.
self print: ').'.
self cr.
self print: 'Press CR to quit...'.
self getchar.
self ioExit.

 We should replace the last phrase with something like

    self ioReportImageFormat: firstVersion incompatibleWith: self imageFormatVersion andThenExit: nil

and let the platform deal with this as it chooses.




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
===========================================================================




Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Klaus D. Witzel
 


On Tue, Mar 10, 2009 at 12:48 AM, Klaus D. Witzel <[hidden email]> wrote:
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?

Good point.  There isn't a straight-forward way in the normal VMs.  In the Qwaq internal VMs I added the imageFormatVersion of the current VM as vm parameter #41.  BTW, here is the complete list of things I've added

41  imageFormatVersion for the VM
42 nil (number of stack pages in use in Stack VM)
43 nil (desired number of stack pages in Stack VM)
44 nil (size of eden, in bytes in Stack VM)
45 nil (desired size of eden in Stack VM)
46-55 nil; reserved for VM parameters that persist in the image (such as eden above)
56 number of process switches since startup (read-only)
57 number of ioProcessEvents calls since startup (read-only)
58 number of ForceInterruptCheck calls since startup (read-only)
59 number of check event calls since startup (read-only)

There might be a way of constructing an empty closure on a null method and testing if a version of the closure primitive fails, but I prefer the image format parameter.  In older VMs the vm parameter primitive should fail if given parameter 41.  What say the VM devs?  Can we add #41 as answering the imageFormatVersion of the VM?


/Klaus

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



Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
 
Eliot Miranda wrote:

> Good point.  There isn't a straight-forward way in the normal VMs.  In
> the Qwaq internal VMs I added the imageFormatVersion of the current VM
> as vm parameter #41.  BTW, here is the complete list of things I've added
>
> 41  imageFormatVersion for the VM
> 42 nil (number of stack pages in use in Stack VM)
> 43 nil (desired number of stack pages in Stack VM)
> 44 nil (size of eden, in bytes in Stack VM)
> 45 nil (desired size of eden in Stack VM)
> 46-55 nil; reserved for VM parameters that persist in the image (such as
> eden above)
> 56 number of process switches since startup (read-only)
> 57 number of ioProcessEvents calls since startup (read-only)
> 58 number of ForceInterruptCheck calls since startup (read-only)
> 59 number of check event calls since startup (read-only)
>
> There might be a way of constructing an empty closure on a null method
> and testing if a version of the closure primitive fails, but I prefer
> the image format parameter.  In older VMs the vm parameter primitive
> should fail if given parameter 41.  What say the VM devs?  Can we add
> #41 as answering the imageFormatVersion of the VM?

Sounds reasonable to me (but then I may be biased ;-)

Cheers,
   - Andreas