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 -
ed.boyce@duke.edu 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 forall three major platforms?
On Windows it's 3.10.4.
2) Is there any reason anyone can think of that this latest version wouldnot 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 availableon. 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, ed.boyce@duke.edu wrote:
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.
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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Quoting John M McIntosh johnmci@smalltalkconsulting.com:
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.
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?
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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Quoting Andreas Raab andreas.raab@gmx.de:
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
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 isavailable for all three major platforms?
On Windows it's 3.10.4.
2) Is there any reason anyone can think of that this latestversion 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 Cobaltis 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 12:53 PM, ed.boyce@duke.edu wrote:
Quoting Andreas Raab andreas.raab@gmx.de:
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?
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.
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
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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On 14-Feb-09, at 12:31 PM, ed.boyce@duke.edu 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.
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?
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.
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?
Look at the UTI info.plist requirements.
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
ed.boyce@duke.edu 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
Thanks again for all insights.
-- EdLooking 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 isavailable for all three major platforms?
On Windows it's 3.10.4.
2) Is there any reason anyone can think of that this latestversion 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 isavailable 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
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 piumarta@speakeasy.net:
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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
ed.boyce＠duke.edu -
Ian Piumarta -
John M McIntosh