Re: [squeak-dev] Porting my programs from Squeak 3.10.2 to 3.5

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

Re: [squeak-dev] Porting my programs from Squeak 3.10.2 to 3.5

Eliot Miranda-2
 
Hi Trygve,

On Apr 5, 2020, at 2:47 AM, Trygve Reenskaug <[hidden email]> wrote:

 I'm struggling with a new .image3 extension. It seems that Squeak Cog Spur Virtual Machine actually KNOWS that all images have the .image extension. This seems to mean that I can't run two different Squeak generation images within the same OS instance.

there’s no restriction on running multiple kinds of image or multiple images or multiple instances of the same image.  One can always drop an image on the right vm, or manually launch a specific vm with a specific in a shell.

The issue is only having double clicking select an appropriate vm for the image, and for that you’re right that one needs a wrapper.

Pharo has a wrapper implemented in Smalltalk, PharoLauncher, that could be adapted.  VisualWorks has a small wrapper and an ini file, VisualWorks.exe & VisualWorks.ini IIRC (know it? I wrote it).

It wouldn’t be hard to implement the wrapper solution.  I’ll try and get that done in the next few days.  But then it has to get pushed through to production, to be built using some kind of CI.  And of course it makes sense on all platforms.


I'll try running my 3.10.2 under Cog Spur Virtual Machine. I hope it works.

It won’t.  Spur 32-bit VMs are the only VMs that can run 32-bit Spur images, Spur 64-bit VMs are the only VMs that can run 64-bit Spur images, etc.  it isn’t just a matter of converting each individual object.  There are bytecode set, closure design, identity hash and object enumeration method, and other Smalltalk-level differences that mean automatically converting images is impossible.

Converting between 32-bit and 64-bit Spur images *is* automatable and there is a program (a Spur image) I should package up to do it.  But it takes a few seconds and requires VMMaker, so it is not small, and so is not something to add the the vm and have some images takes seconds to launch instead of milliseconds.



On 04-Apr-20 9:13 PM, tim Rowledge wrote:
We were discussing this with regard to the 5.3 release but didn't have time to sort out. Having a wrapper that checks the image file format and picks the right vm is not in principle difficult; we just need someone to write it.

The unix package for example already has a shell script that does a fair bit of fiddle-faddle. Adding use of the image format command wouldn't make a lot of difference.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Virtual Memory" means never knowing where your next byte is coming from.






--

The essence of object orientation is that objects collaborate  to achieve a goal.
Trygve Reenskaug      
[hidden email]
Morgedalsvn. 5A       
http://folk.uio.no/trygver/
N-0378 Oslo             
http://fullOO.info
Norway                     Tel: (+47) 22 49 57 27