Best and latest VMs for Open Cobalt release?

 
Everyone,

   Open Cobalt (http://opencobalt.org -- based on Open Croquet) is nearing its
public alpha release.  We would like to ship Open Cobalt with the most
up-to-date VM possible on Mac, Linux and Windows, preferably at the same
version on each.  Ideally, that would probably mean 3.10.4 on every platform.

   Looking at http://squeak.org/Download/ and http://squeakvm.org, I see various
latest version #'s available for the different platforms.  One possible course
of action I could take is do fresh builds on each platform from the current
subversion sources.  But before go through that exercise, I would like to ask
the knowledgeable members of this list:

    1) What is the latest STABLE version of the Squeak VM that is available for
all three major platforms?

    2) Is there any reason anyone can think of that this latest version would
not be suitable and stable for Open Cobalt's alpha debut? This would include
performance issues. If so, what is the most recent VM that would be suitable
and stable?

    3) We would like to expand the number of platforms that Cobalt is available
on.  Does anyone know of Squeak VM builds on platforms such as Solaris and
FreeBSD that have the functioning openAL and openGL bindings necessary for
Cobalt?

    All pointers, links, tarballs, and advice will be most appreciated.

        Best Regards,

           Ed Boyce
           for the Open Cobalt Project

 
Hi Ed -

[hidden email] wrote:
>    Open Cobalt (http://opencobalt.org -- based on Open Croquet) is nearing its
> public alpha release.  We would like to ship Open Cobalt with the most
> up-to-date VM possible on Mac, Linux and Windows, preferably at the same
> version on each.  Ideally, that would probably mean 3.10.4 on every platform.

The numbering scheme of VMs differs between the various platforms so the
3.10.4 nomenclature is really only applicable to Windows.

>    Looking at http://squeak.org/Download/ and http://squeakvm.org, I see various
> latest version #'s available for the different platforms.  One possible course
> of action I could take is do fresh builds on each platform from the current
> subversion sources.  But before go through that exercise, I would like to ask
> the knowledgeable members of this list:
>
>     1) What is the latest STABLE version of the Squeak VM that is available for
> all three major platforms?

On Windows it's 3.10.4.

>     2) Is there any reason anyone can think of that this latest version would
> not be suitable and stable for Open Cobalt's alpha debut? This would include
> performance issues. If so, what is the most recent VM that would be suitable
> and stable?

All of the recent VMs should be fine. Do note however, that due to the
bit-identical replication requirements of Croquet you'll want to run the
CroquetVMTests to ensure that everything comes out as expected.

>     3) We would like to expand the number of platforms that Cobalt is available
> on.  Does anyone know of Squeak VM builds on platforms such as Solaris and
> FreeBSD that have the functioning openAL and openGL bindings necessary for
> Cobalt?

Can't help you here.

Cheers,
   - Andreas

 

On 14-Feb-09, at 10:49 AM, [hidden email] wrote:


For the macintosh that would be the 3.8.21beta1U VM
You should consider the SparklePlugin so you can push application  
bundle updates to people if you wish.

If you are making a one-click application then you should consider if  
you need to change

(a) the document types information
(b) the name of the executable
(c) the get info string, perhaps retain the VM version number
(d) the icon file
(e) the bundle identifier, name, OS Type, verson string, creator, &  
version
(f) Drop the Services unless you want to offer your app in the  
Services menu
(g) SqueakImageName is ?
(h)  SqueakMaxHeapSize is ? (512MB, bigger? smaller?)
(i) The SqueakTrustedDirectory & SqueakUnTrustedDirectory
(j) SqueakEncodingType  is that application macroman or does it really  
understand UTF-8 file names? Most vertical apps opt for
UTF-8 after they have ensured any broken file name translation code in  
the image has been purged.

Retain the PGP signature for the binary  Squeak VM Opt.sig, if you  
rename the binary you can rename the signature.
If you build your own VM you can discard it.

For the plugins
Which plugin are required is up to the application team's decision,  
they all require Smalltalk code

CroquetPlugin.bundle - no idea what is current
FloatMathPlugin.bundle - no idea what is current

Usually these are required, check your smalltalk code, and ftp.smalltalkconsulting.com
  for any updates

FT2Plugin.bundle - FreeType font support
LocalePlugin.bundle - Locale support, some images use this to get  
things like the http proxy used.
SqueakFFIPrims.bundle - FFI interace
UnixOSProcessPlugin.bundle - OSProcess interface

These are optional macintosh specific

PrintJobPlugin.bundle - ProjectJob interface (macintosh print dialogs)
QuicktimePlugin.bundle - Quicktime interface for Sophie (optional for  
sophie)
ServicesPlugin.bundle - Services menu interface
SpellingPlugin.bundle - Spelling interface (macintosh spelling api)
TestOSAPlugin.bundle - AppleScript interface
ClipboardExtendedPlugin.bundle  - This is the extended clipboard  
support for cut/copy/paste of UTF8 between squeak and elsewhere
ObjectiveCPlugin.bundle - Yet another Objective-C bridge


Optional plugins, supported on other platforms.

SparklePlugin.bundle - Sparkle is an API that lets you push  
application updates to clients, used by many mac applications now
mpeg3Plugin.bundle - The historically old MP3 support, see Sophie  
media support for much better solution.
CurlPlugin.bundle - Do you need Curl support?
OggPlugin.bundle - Do you need Ogg?
RomePlugin.bundle - Do you need the Rome api that fronts FreeType?
IA32ABI.bundle - Support for Alien
KedamaPlugin.bundle - eToys
KedamaPlugin2.bundle - eToys
OpenALPlugin.bundle - OpenAL support
SerialExtendedUnixPlugin.bundle - Extended Serial port support


Icon files, which do you need, or do you have replacements?
Squeak.icns
SqueakChanges.icns
SqueakGeneric.icns
SqueakImage.icns
SqueakPlugin.icns
SqueakProject.icns
SqueakScript.icns
SqueakSources.icns

Technically if you want some other file type for image files you might  
need to code a UTI  in the info.plist

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

 
Quoting John M McIntosh <[hidden email]>:

   We will be changing the VM's application's name and registration to
Cobalt.app with a new Cobalt specific application registration that we
obtained
from Apple.  This is seemly necessary because we generated new .icns
files, but
the system didn't seem to want to recognize them, clinging to the Squeak
filetype associations.  In searching through the MacOS specific source files,
we found a couple of places where we need to swap out the Squeak
application ID
for Cobalt's.  But if you had a comprehensive list of code locations
where this
change is necessary, that would be a great help.  Are we correct in our
conclusion that there's no way to change the app registration short of doing a
rebuild?


> Icon files, which do you need, or do you have replacements?

  We've made Cobalt replacements for all of these. Besides changing the
filename
references in info.plist and changing the app registration, do you know
of other
steps that will be necessary?

 
Quoting Andreas Raab <[hidden email]>:


>
> The numbering scheme of VMs differs between the various platforms so
> the 3.10.4 nomenclature is really only applicable to Windows.
>

   Thanks Andreas. So I gather from your response and John McIntosh's that
Windows 3.10-4 and Mac 3.8.21beta are approximately equivalent versions?

   John McIntosh: Then what is the 3.10-2-7179mac offered at squeak.org about?
Is it an alias for 3.8.21beta?

   And I have one not-so-off-topic question: Why are the VM version
numbers/schemes allowed to diverge like this across platforms?
Particularly for
users who want assurances that SmallTalk code will execute identically across
platforms, this is confusing and not reassuring.

   Thanks again for all insights.

        -- Ed

 

On 14-Feb-09, at 12:53 PM, [hidden email] wrote:

  Mac 3.8.21beta1U is the most current macintosh one, it should behave  
like a current windows one, if not make a mantis report.

>
>
>  John McIntosh: Then what is the 3.10-2-7179mac offered at  
> squeak.org about?
> Is it an alias for 3.8.21beta?

This is the images/changes at version 3.10-2-7179, bundled with a  
current macintosh VM, you would need to check to see
if it is the most current, from time to time after making fixes &  
enhancements, and based on early user feedback I ask the
image/changes folks to rebuild the current squeak macintosh zip  
file.   You do need to check to see if you run the most current.

Or use the sparkle interface to ensure your users get the proper VM  
and support files.


The VM source tree is different from the smalltalk image/changes base.
The VM source tree has different platforms  (oh say linux, macintosh,  
& windows) let's exclude (risc, hydra, & iPhone for now).

So you have the three flavours of the VM changing to a particular  
version number logic set by the maintainers, and you have the image/
changes changing to
another version number schema, all quite independently for the most  
part.

'

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

 

On 14-Feb-09, at 12:31 PM, [hidden email] wrote:
>

>  We will be changing the VM's application's name and registration to
> Cobalt.app with a new Cobalt specific application registration that  
> we obtained
> from Apple.  This is seemly necessary because we generated new .icns  
> files, but
> the system didn't seem to want to recognize them, clinging to the  
> Squeak
> filetype associations.

Adding a new file type association is fraught with fun...
After fiddling with the logic you need to finder duplicate the  
application and see if the finder notices the world has changed,
pay close attention to the version number of the info.plist it  
dictates who is most current and has precedence over older versions.


I don't believe you need to change the C source to work around this  
issue.

'FAST' I think is only used for

(a) CreateMouseTrackingRegion  which is a region id identifier for  
mouse tracking so we know when to change the mouse cursor when it  
leaves the squeak window, it can be anything, so you need not change it.

(b)  at image save time we set the file to stim and FAST, but you can  
in smalltalk use the setMacFileTypeAndCreator to set the image file to  
whatever, so
you don't need to change the snapshot primitive. & writeImageFile  
primitive (Oops I see we do it twice, oh well a bug).  To override  
this just set the
mac file type and creator in the Smalltalk code after doing the  
snapshot.


Note when we open an existing file for read/write and the file type is  
BINA or ???? or null we set the type and creator to "TEXT","R*ch"
which is the signature for BBEdit.   This too can be overridden in  
Smalltalk.

Look at the UTI info.plist requirements.


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

 
[hidden email] wrote:
>   Thanks Andreas. So I gather from your response and John McIntosh's that
> Windows 3.10-4 and Mac 3.8.21beta are approximately equivalent versions?

Yes.

> And I have one not-so-off-topic question: Why are the VM version
> numbers/schemes allowed to diverge like this across platforms?

Because this is open source and I don't get to tell John how he names
his VMs. Do I think it's good? No, I think it's horrible. But unless I
start making Macintosh VM packages, I don't get to decide how John names
his VMs.

> Particularly for users who want assurances that SmallTalk
> code will execute identically across platforms, this
> is confusing and not reassuring.

Yes. I agree to 100%. Which is why I have generally named "my" VMs in
sync with the image releases to make it reasonably understandable for
people that for running a 3.10 image they should consider a 3.10 VM.
(Coincidentally, this is why the Croquet VM is labeled 1.0 too).

Cheers,
   - Andreas

Why add more uncertainty to Cobalt alpha by changing the VM too?

Aik-Siong Koh

 
Ed,

On Feb 14, 2009, at 3:42 PM, Andreas Raab wrote:

> Yes. I agree to 100%. Which is why I have generally named "my" VMs  
> in sync with the image releases to make it reasonably  
> understandable for people that for running a 3.10 image they should  
> consider a 3.10 VM.

The Unix VM follows the same principle.  The major and minor version  
numbers track those of the image from which the interpreter sources  
are generated.  The patch number starts at 0 and increases by 1 each  
time a major set of changes are applied.  The configure script, the  
configure.ac file and the output from 'squeak -version' identify the  
precise version (to the nearest update number) of the image used to  
generate the VM.

The latest SVN should be good, except that it is still missing some  
Solaris patches that I have in my pending commit queue.  AFAIK it  
compiles out of the box on FreeBSD.

Just curious: why did you name it 'cobalt'?

Cheers,
Ian

 
Quoting Ian Piumarta <[hidden email]>:

>
> The latest SVN should be good, except that it is still missing some  
> Solaris patches that I have in my pending commit queue.  AFAIK it  
> compiles out of the box on FreeBSD.

   Thanks Ian.

    Some of our Linux users (with the custon 3.8.x VM we've been using) have
experienced problems with the OpenAL and UUID plugins finding their respective
.so libraries, particularly on 64 bit systems that have /lib32 and /lib64
folders in addition to /lib.  Do you know of this issue and if it's been
solved/improved in the past year+?

   Also, do you know if the Solaris and FreeBSD VMs have functioning OpenGL,
OpenAL and UUID plugins?

>
> Just curious: why did you name it 'cobalt'?
>
  It started out as a codename for the project, which was inspired by the blue
color in Duke University's logo. The moniker simply has stuck for the past
number of months, and may well become all or part of the permanent name of the
project.

  Thank you very much for your insights and guidance.

      Best Regards,

        Ed Boyce


> Cheers,
> Ian
>
>