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 |
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, |
On Thu, Oct 17, 2019 at 1:03 PM Edgar De Cleene <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
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, |
> 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 > > > |
On Thu, Oct 17, 2019 at 2:18 PM Tobias Pape <[hidden email]> wrote:
Now there is an idea! Does it support OpenGL? We need that for running Plopp. - Bert - > |
> 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 > > > > > > |
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 |
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 |
In reply to this post by Bert Freudenberg
Hi Bert, On Thu, Oct 17, 2019 at 2:13 PM Bert Freudenberg <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
> 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 |
On Thu, Oct 17, 2019 at 5:10 PM tim Rowledge <[hidden email]> wrote:
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 - |
On Thu, Oct 17, 2019 at 5:19 PM Bert Freudenberg <[hidden email]> wrote:
Btw, this discussion should go to vm-dev, see John's thread there. - Bert - |
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 > > |
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 |
Free forum by Nabble | Edit this page |