macintosh cocoa 32/64bit & 64/64bit VM goes BETA

Ok, it's time for the community to do some testing.

ESUG provided me with some funding to take the existing iPhone VM source and extend that to
build a new hosting platform using Cocoa on the macintosh and to enable the VM to run in 32 or 64 bit
mode and work with a 32 or 64bit image.

I have placed two Alpha test VM s in the experimental folder  sub-folder COCOA
found in the usual places via

http://smalltalkconsulting.com/squeak.html

There are two VM's

(a) a 32/64 bit VM that runs 32bit squeak images in 32bit (powerpc, intel) or 64bit (intel) mode.
(b) a 64/64 bit VM that runs 64bit squeak images in 64bit (intel).


The VM currently runs on 10.5.x and 10.6.x  Support for 10.4.x might happen, we will see.

Until I sort out the re-integration of the source code into the squeakvm.org SVN tree you will
find the source at isqueak.org

Issues, Oh lots. It's a fairly high mountain of material that needs to be tested.

Things that should work.

(a) access to files and directories UTF8 support only.
(b) Full screen support
(c) Sockets
(d) Basic Sound (better than in the 3.x/4.x VMs)
(e) jpegplugin2
(f) cut/copy/paste of text data (from/to) squeak and respect UTF8 chars
(g) drag and drop of files into squeak

Right now it does not:

(a) Support a internet browser as a browser plugin.
(b) The 64bit VM has no plugins at the moment.
(b2) I've not included any plugins with the 32/64bit VM.  
        Existing plugins might work if the VM is running as "Open in 32bit mode"
        someone can confirm that.

(c) No macintosh host menus, or serial port support
(d) No Areithfa Ffenestri multiple-window support
(e) No 1, 2, 4, 8, 16 bit appearance support.

Things I know about.
(a) double clicking *.images when the 5.x VM is running sometimes does not open a new VM.
(b) tossing a 32 image at the 64/64 bit VM or a 64 image at the 32/64 VM doesn't give visual feedback that it won't open the image.
(c) Full screen grabs all the screens, yes that will change

Thoughts on internal plugins. Hint we should have TEST cases so we can confirm if all this stuff works.
It would be extremely helpful if someone wanted to work on that.   No doubt someone *could* run all the
current tests for a 32bit image and see what breaks.  However you'll need to explain where and what, versus
Oh it just crashed...

        ADPCMCodecPlugin, untested.
        Squeak3D, Likely busted due to use of (int) data types in 64bit mode.
        B2DPlugin, untested.
        BitBltPlugin, untested.
        BMPReadWriterPlugin, untested.
        ZipPlugin, untested.
        DSAPrims, untested.
        SqueakFFIPrims, untested.
        FFTPlugin, untested.
        FloatArrayPlugin, untested.
        GeniePlugin, untested.
        HostWindowPlugin,  No support yet
        JPEGReaderPlugin,  untested.
        Klatt, untested.
        LargeIntegers, untested.
        Matrix2x3Plugin, untested.
        MiscPrimitivePlugin, untested.
        ObjectiveCPlugin, untested.
        RePlugin, Likely busted due to use of (int) data types in 64bit mode.
        SecurityPlugin, untested.
        SoundCodecPrims, Likely busted due to use of (int) data types in 64bit mode.
        SoundGenerationPlugin, Likely busted due to use of (int) data types in 64bit mode.
        StarSqueakPlugin, untested.
        SurfacePlugin, untested.
        UUIDPlugin untested.

Possibly Large Integers may have a problem in 64bit image mode, but we have to have some
discussion if the (unsigned int *) used by one routine is on purpose or an oversight.

64 bit images.

We need to built a 64bit Closure image. **** I've no time to do that. ***

David T Lewis provided a somewhat current Squeak.image which you'll find on the ftp site.

If you build a 64bit image you need to do that on a PowerPC, or make a copy of  your VM on macIntel
and flip the  "Open in 32-bit mode" and the "Open in Rosetta" to on. You will only see the "Open in 32bit mode" if it's a 64bit VM,
and the "Open in Rosetta on os-x for 10.5 or 10.6 (if you installed it)
Follow the obvious instructions.

No doubt some is required to take the code and build a MC change set for Pharo or Squeak Thrunk use so that
anyone can convert an existing image.

Also see
 http://bugs.squeak.org/view.php?id=5239
 http://bugs.squeak.org/view.php?id=5240

Building your own VM?

Hopefully someone will attempt this so I can see if I checked in all the changes.

32bit image VM pick SqueakPureObjc and set
#define SQ_VI_BYTES_PER_WORD 4
for a
64bit image reading VM  pick SqueakPureObjc64*64 and set
#define SQ_VI_BYTES_PER_WORD 8
in the required places.

PS You'll find that building a 32/64 VM using GNU's tool chain will give you lousy performance
when running as a 64bit VM, more on this later.

----------------------------------------------
Oh and lastly I'm looking for some paid work (smalltalk or objective-c (mac/iPhone) If anyone
requires a Smalltalk consultant, or an iPhone app built, please email me.

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

On 2009-12-04, at 10:24 AM, Miguel Enrique Cobá Martinez wrote:
>> The VM currently runs on 10.5.x and 10.6.x  Support for 10.4.x might happen, we will see.
>
> So this is only for macs. Is that right?

yes

> When the code is integrated with the squeakvm svn code there will be any
> chance of having it run on other OS (GNU/Linux is my own). Or this will
> only work for Macs?
>
> Anyway, thanks.

Ok, there are a number of issues on the table

(a) confirming the base VM and internal plugins work. For example sound, the jpeg2readwriter, etoys security, did not work because
it looked like people wanting to compile as 64bit didn't care if it did sound or rendered jpegs. Typically I think they
just wanted a 64bit platform for Seaside server usage.
 
(b) Making it all work on external plugins, ie for example rome and freetype2

(c) Some people have asked can you take the code base and run on Gnu/Linux using the GNU Objective-C environment?
Well the code base *is* tied to platform specific technology for the iPhone & OSX for sound, display, and sensor input.
However you can subclass override all that behaviour with code that does the right thing for sound, display, and sensor input.
I have to do that anyway to provide variations between os-x and iPhone.

But really I think the question here is reuse of the common code base, lots of that, Sockets for example is generic unix code
so yes the goal is to make the *entire* common code base 64bit clean compile-able on various unix like platforms, versus
just the minimum required to run Seaside


>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>

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