64 bit migration

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

64 bit migration

Michael Rueger
Hi all,

it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.

And as an XCode user I will have no choice but to update...

Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
migrate to 64 bit?

Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)

I can of course keep a current MacOS installation around, but that is not really a long term solution.

Any pointer(s) appreciated!

Cheers

Michael


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Edgar De Cleene
Welcome to Lost (Catalina)
It’s impossible make a 64 bit VM which open 32 bit .images ?


On Thu, 17 Oct 2019 at 16:56 Michael Rueger <[hidden email]> wrote:
Hi all,

it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.

And as an XCode user I will have no choice but to update...

Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
migrate to 64 bit?

Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)

I can of course keep a current MacOS installation around, but that is not really a long term solution.

Any pointer(s) appreciated!

Cheers

Michael




Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Eliot Miranda-2


On Thu, Oct 17, 2019 at 1:03 PM Edgar De Cleene <[hidden email]> wrote:
Welcome to Lost (Catalina)
It’s impossible make a 64 bit VM which open 32 bit .images ?

It is not necessary.  Spur 32-bit images can be automatically and reliably converted to 64-bit Spur images.  However, it takes about 2 minutes so it is not something one wants to do on start-up.
 


On Thu, 17 Oct 2019 at 16:56 Michael Rueger <[hidden email]> wrote:
Hi all,

it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.

And as an XCode user I will have no choice but to update...

Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
migrate to 64 bit?

Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)

I can of course keep a current MacOS installation around, but that is not really a long term solution.

Any pointer(s) appreciated!

Cheers

Michael





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Bert Freudenberg
In reply to this post by Michael Rueger
We do not have a good story for converting old 32 bit interpreter images to the new format and runtime.

Eliot used to have scripts to convert an image to Cog, and then to Spur. But I'm not sure anyone besides Eliot ever successfully used them. Also not sure where they are.

If we just want to run an old image, a PC emulator with a 32 bit Linux VM might be the best bet.

Also, SqueakJS is fast enough to run many old images (e.g. Etoys and Scratch). Many plugins are not implemented yet, but it's certainly possible, at least as a stand-alone Electron app (as opposed to a web app).

- Bert -
 


On Thu, Oct 17, 2019 at 12:56 PM Michael Rueger <[hidden email]> wrote:
Hi all,

it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.

And as an XCode user I will have no choice but to update...

Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
migrate to 64 bit?

Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)

I can of course keep a current MacOS installation around, but that is not really a long term solution.

Any pointer(s) appreciated!

Cheers

Michael




Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Tobias Pape

> On 17.10.2019, at 23:12, Bert Freudenberg <[hidden email]> wrote:
>
> We do not have a good story for converting old 32 bit interpreter images to the new format and runtime.
>
> Eliot used to have scripts to convert an image to Cog, and then to Spur. But I'm not sure anyone besides Eliot ever successfully used them. Also not sure where they are.
>
> If we just want to run an old image, a PC emulator with a 32 bit Linux VM might be the best bet.
>
> Also, SqueakJS is fast enough to run many old images (e.g. Etoys and Scratch). Many plugins are not implemented yet, but it's certainly possible, at least as a stand-alone Electron app (as opposed to a web app).

BTW: RSqueak is 64bit too and can run 32bit images.

Best regards
        -Tobias

>
> - Bert -
>  
>
>
> On Thu, Oct 17, 2019 at 12:56 PM Michael Rueger <[hidden email]> wrote:
> Hi all,
>
> it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.
>
> And as an XCode user I will have no choice but to update...
>
> Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
> migrate to 64 bit?
>
> Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)
>
> I can of course keep a current MacOS installation around, but that is not really a long term solution.
>
> Any pointer(s) appreciated!
>
> Cheers
>
> Michael
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Bert Freudenberg
On Thu, Oct 17, 2019 at 2:18 PM Tobias Pape <[hidden email]> wrote:

> On 17.10.2019, at 23:12, Bert Freudenberg <[hidden email]> wrote:
>
> We do not have a good story for converting old 32 bit interpreter images to the new format and runtime.
>
> Eliot used to have scripts to convert an image to Cog, and then to Spur. But I'm not sure anyone besides Eliot ever successfully used them. Also not sure where they are.
>
> If we just want to run an old image, a PC emulator with a 32 bit Linux VM might be the best bet.
>
> Also, SqueakJS is fast enough to run many old images (e.g. Etoys and Scratch). Many plugins are not implemented yet, but it's certainly possible, at least as a stand-alone Electron app (as opposed to a web app).

BTW: RSqueak is 64bit too and can run 32bit images.

Best regards
        -Tobias

Now there is an idea! Does it support OpenGL? We need that for running Plopp.

- Bert -

 
>
> - Bert -

>
>
> On Thu, Oct 17, 2019 at 12:56 PM Michael Rueger <[hidden email]> wrote:
> Hi all,
>
> it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.
>
> And as an XCode user I will have no choice but to update...
>
> Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
> migrate to 64 bit?
>
> Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)
>
> I can of course keep a current MacOS installation around, but that is not really a long term solution.
>
> Any pointer(s) appreciated!
>
> Cheers
>
> Michael
>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Tobias Pape

> On 17.10.2019, at 23:24, Bert Freudenberg <[hidden email]> wrote:
>
> On Thu, Oct 17, 2019 at 2:18 PM Tobias Pape <[hidden email]> wrote:
>
> > On 17.10.2019, at 23:12, Bert Freudenberg <[hidden email]> wrote:
> >
> > We do not have a good story for converting old 32 bit interpreter images to the new format and runtime.
> >
> > Eliot used to have scripts to convert an image to Cog, and then to Spur. But I'm not sure anyone besides Eliot ever successfully used them. Also not sure where they are.
> >
> > If we just want to run an old image, a PC emulator with a 32 bit Linux VM might be the best bet.
> >
> > Also, SqueakJS is fast enough to run many old images (e.g. Etoys and Scratch). Many plugins are not implemented yet, but it's certainly possible, at least as a stand-alone Electron app (as opposed to a web app).
>
> BTW: RSqueak is 64bit too and can run 32bit images.
>
> Best regards
>         -Tobias
>
> Now there is an idea! Does it support OpenGL? We need that for running Plopp.
>

It has an SDL-Backend, but we hadn't had the time to tackle opengl…

> - Bert -
>
>  
> >
> > - Bert -
> >  
> >
> >
> > On Thu, Oct 17, 2019 at 12:56 PM Michael Rueger <[hidden email]> wrote:
> > Hi all,
> >
> > it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.
> >
> > And as an XCode user I will have no choice but to update...
> >
> > Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
> > migrate to 64 bit?
> >
> > Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)
> >
> > I can of course keep a current MacOS installation around, but that is not really a long term solution.
> >
> > Any pointer(s) appreciated!
> >
> > Cheers
> >
> > Michael
> >
> >
> >



Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Yoshiki Ohshima-3
In reply to this post by Eliot Miranda-2
For me, whether I can load my .pr files (the project files) onto Etoys
is more important than just running an old image...

On Thu, Oct 17, 2019 at 1:53 PM Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Thu, Oct 17, 2019 at 1:03 PM Edgar De Cleene <[hidden email]> wrote:
>>
>> Welcome to Lost (Catalina)
>> It’s impossible make a 64 bit VM which open 32 bit .images ?
>
>
> It is not necessary.  Spur 32-bit images can be automatically and reliably converted to 64-bit Spur images.  However, it takes about 2 minutes so it is not something one wants to do on start-up.
>
>>
>>
>>
>> On Thu, 17 Oct 2019 at 16:56 Michael Rueger <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.
>>>
>>> And as an XCode user I will have no choice but to update...
>>>
>>> Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
>>> migrate to 64 bit?
>>>
>>> Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)
>>>
>>> I can of course keep a current MacOS installation around, but that is not really a long term solution.
>>>
>>> Any pointer(s) appreciated!
>>>
>>> Cheers
>>>
>>> Michael
>>>
>>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Ron Teitelbaum-3
Mac dropped support for OpenGL.

Ron

On Thu, Oct 17, 2019, 5:36 PM Yoshiki Ohshima <[hidden email]> wrote:
For me, whether I can load my .pr files (the project files) onto Etoys
is more important than just running an old image...

On Thu, Oct 17, 2019 at 1:53 PM Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Thu, Oct 17, 2019 at 1:03 PM Edgar De Cleene <[hidden email]> wrote:
>>
>> Welcome to Lost (Catalina)
>> It’s impossible make a 64 bit VM which open 32 bit .images ?
>
>
> It is not necessary.  Spur 32-bit images can be automatically and reliably converted to 64-bit Spur images.  However, it takes about 2 minutes so it is not something one wants to do on start-up.
>
>>
>>
>>
>> On Thu, 17 Oct 2019 at 16:56 Michael Rueger <[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.
>>>
>>> And as an XCode user I will have no choice but to update...
>>>
>>> Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
>>> migrate to 64 bit?
>>>
>>> Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)
>>>
>>> I can of course keep a current MacOS installation around, but that is not really a long term solution.
>>>
>>> Any pointer(s) appreciated!
>>>
>>> Cheers
>>>
>>> Michael
>>>
>>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


--
-- Yoshiki



Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Eliot Miranda-2
In reply to this post by Bert Freudenberg
Hi Bert,

On Thu, Oct 17, 2019 at 2:13 PM Bert Freudenberg <[hidden email]> wrote:
We do not have a good story for converting old 32 bit interpreter images to the new format and runtime.

Eliot used to have scripts to convert an image to Cog, and then to Spur. But I'm not sure anyone besides Eliot ever successfully used them. Also not sure where they are.

They are in the https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/image/old directory, but they are the result of a work in progress that was the incremental bootstrap of Spur.  It would take some work to build a one-step bootstrap from V3 (old format) to Spur 32-bit.  It is possible, but a fair amount of work.  We have multiple starting points (various versions of old format) and a moving target as the end point (OK, the end point could be some standard Spur release and the user updates from there).

But I still think that the right way is to export one's code as packages and rebuild.  Most code "just works", but nothing is going to automagically replace one's use of someObject/nextObject, or the assumption that Float is the only float class, so the user is still going to have to test their code carefully.


If we just want to run an old image, a PC emulator with a 32 bit Linux VM might be the best bet.

Also, SqueakJS is fast enough to run many old images (e.g. Etoys and Scratch). Many plugins are not implemented yet, but it's certainly possible, at least as a stand-alone Electron app (as opposed to a web app).

- Bert -
 


On Thu, Oct 17, 2019 at 12:56 PM Michael Rueger <[hidden email]> wrote:
Hi all,

it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.

And as an XCode user I will have no choice but to update...

Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
migrate to 64 bit?

Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)

I can of course keep a current MacOS installation around, but that is not really a long term solution.

Any pointer(s) appreciated!

Cheers

Michael





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

timrowledge

> On 2019-10-17, at 4:19 PM, Eliot Miranda <[hidden email]> wrote:
>
> But I still think that the right way is to export one's code as packages and rebuild.  Most code "just works", but nothing is going to automagically replace one's use of someObject/nextObject, or the assumption that Float is the only float class, so the user is still going to have to test their code carefully.

Extra hassles come from images where a great deal of setup was done and is not necessarily encoded in, err, code... and of course a lot of these older images are using older code for some important parts. Updating them can easily be a barrier too far.

A VM capable of running a 32bit image is clearly possible. One might consider simplifying the problem a little by asserting that since 32bit Spur images are easy to convert there is no need to worry about handling them with this VM. That also removes the need to deal with the clevernesses added since the advent of the Spur images, which should simplify things a tad. To be honest, it's probably best to just run a plain(ish) interpreter VM (perhaps the stackvm enhancements would be smart to use) and accept that such old images will just be a bit slow by comparison.

We already have VMs with most of these attributes so with luck the remaining work is, surely,  mostly making sure that 32 bit values do not get incorrectly promoted.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- L'ETAT, C'EST MOE - All the world's a stooge



Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Bert Freudenberg
On Thu, Oct 17, 2019 at 5:10 PM tim Rowledge <[hidden email]> wrote:

> On 2019-10-17, at 4:19 PM, Eliot Miranda <[hidden email]> wrote:
>
> But I still think that the right way is to export one's code as packages and rebuild.  Most code "just works", but nothing is going to automagically replace one's use of someObject/nextObject, or the assumption that Float is the only float class, so the user is still going to have to test their code carefully.

Extra hassles come from images where a great deal of setup was done and is not necessarily encoded in, err, code... and of course a lot of these older images are using older code for some important parts. Updating them can easily be a barrier too far.

A VM capable of running a 32bit image is clearly possible. One might consider simplifying the problem a little by asserting that since 32bit Spur images are easy to convert there is no need to worry about handling them with this VM. That also removes the need to deal with the clevernesses added since the advent of the Spur images, which should simplify things a tad. To be honest, it's probably best to just run a plain(ish) interpreter VM (perhaps the stackvm enhancements would be smart to use) and accept that such old images will just be a bit slow by comparison.

We already have VMs with most of these attributes so with luck the remaining work is, surely,  mostly making sure that 32 bit values do not get incorrectly promoted.

tim

Those VMs do not work anymore because OS vendors (particularly Apple) like to deprecate and then disable old APIs. So the VM needs to be updated to keep on top of that.

The easiest might be to take a current VM and replace its object engine with an old interpreter.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Bert Freudenberg
On Thu, Oct 17, 2019 at 5:19 PM Bert Freudenberg <[hidden email]> wrote:
On Thu, Oct 17, 2019 at 5:10 PM tim Rowledge <[hidden email]> wrote:

> On 2019-10-17, at 4:19 PM, Eliot Miranda <[hidden email]> wrote:
>
> But I still think that the right way is to export one's code as packages and rebuild.  Most code "just works", but nothing is going to automagically replace one's use of someObject/nextObject, or the assumption that Float is the only float class, so the user is still going to have to test their code carefully.

Extra hassles come from images where a great deal of setup was done and is not necessarily encoded in, err, code... and of course a lot of these older images are using older code for some important parts. Updating them can easily be a barrier too far.

A VM capable of running a 32bit image is clearly possible. One might consider simplifying the problem a little by asserting that since 32bit Spur images are easy to convert there is no need to worry about handling them with this VM. That also removes the need to deal with the clevernesses added since the advent of the Spur images, which should simplify things a tad. To be honest, it's probably best to just run a plain(ish) interpreter VM (perhaps the stackvm enhancements would be smart to use) and accept that such old images will just be a bit slow by comparison.

We already have VMs with most of these attributes so with luck the remaining work is, surely,  mostly making sure that 32 bit values do not get incorrectly promoted.

tim

Those VMs do not work anymore because OS vendors (particularly Apple) like to deprecate and then disable old APIs. So the VM needs to be updated to keep on top of that.

The easiest might be to take a current VM and replace its object engine with an old interpreter.

- Bert -

Btw, this discussion should go to vm-dev, see John's thread there.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Greg Lewin
In reply to this post by Michael Rueger
Mojave (the MacOS being phased out now, shipped on machines from last
year like the Mac Mini 2018) will run 32-bit, with a bit of nudging.

It will presumably be supported for a few years yet.

It may be possible to run Mojave in a VM like VBox or VMWare under
later versions like Catalina.

On Thu, 17 Oct 2019 at 20:56, Michael Rueger <[hidden email]> wrote:

>
> Hi all,
>
> it's that time of year again, Apple making everybody's life miserable, this time by cutting off 32 bit support.
>
> And as an XCode user I will have no choice but to update...
>
> Having a gazillion 32 bit images lying around (Sophie, Plopp, Tweak etc) my question is what would be the best way to
> migrate to 64 bit?
>
> Couldn't find anything, but that could just be because I'm great at missing the obvious sometimes ;-)
>
> I can of course keep a current MacOS installation around, but that is not really a long term solution.
>
> Any pointer(s) appreciated!
>
> Cheers
>
> Michael
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 64 bit migration

Michael Rueger
In reply to this post by timrowledge


On 18/10/19 1:10 PM, tim Rowledge wrote:
> Extra hassles come from images where a great deal of setup was done and is not necessarily encoded in, err, code... and of course a lot of these older images are using older code for some important parts. Updating them can easily be a barrier too far.

that is the biggest problem, the old code these images are based on. Sophie even uses the Tweak fork Andreas Raab did
back then and would probably very tricky to port.

Longer term, yes, if you want something to be useful (again), it needs to be updated/ported.

It is just ironic that John and I demoed Sophie at Camp Smalltalk in Portland, proud that it still worked after 10 years
and then Apple pulls the rug from under you...

Thanks for all the input so far!

Michael