On 27 Sep 2016, at 13:41, Clément Bera <bera.clement@gmail.com> wrote:
On Tue, Sep 27, 2016 at 11:43 AM, Max Leske <maxleske@gmail.com> wrote: Hi Sven,
An experimental build of the VM works again on Sierra (Iâve tested this one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files). The problem was with the bundle code and a change from Appleâs side to Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try a Squeak VM (e.g. 'Croquet Closure Cog VM [CoInterpreterPrimitives VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282â) or run the current PharoVM in a virtual machine on Linux (as Iâve done).
Concerning Fuel: the versioning problem is a known and big issue I have to admit. Which Fuel versions does your problem concern? There were some big changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to Context. Depending on the objects you store however, you may be able to load the file simply by removing the version check in Fuel, as most things should be identical.
From Pharo 5 to Pharo 6, likely there will be the change from BlockClosure to FullBlockClosure that will have some impact... We'll keep for Pharo 6 the BlockClosure support for migration purpose then.
The problem is not so much that if there is a change there is an incompatibility, that would be understandable. [ And then supporting some backward compatibility is good ] The problem is that FUEL moves forward in version number, and it refuses to load unless the versions match, even if all you do is, say, safe a collection of strings. It should only fail when it really encounters something that changed.
Cheers, Max
On 27 Sep 2016, at 11:26, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 27 Sep 2016, at 11:21, Norbert Hartl <norbert@hartl.name> wrote:
Sven,
Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor.
it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again.
Norbert
Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ].
Like I described in the email, after upgrading, we were unable to run the old image - catch 22.