> On 27 Sep 2016, at 13:41, Clément Bera <bera.clem...@gmail.com> wrote:
> 
> 
> 
> On Tue, Sep 27, 2016 at 11:43 AM, Max Leske <maxle...@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 <s...@stfx.eu> wrote:
>> 
>> 
>>> On 27 Sep 2016, at 11:21, Norbert Hartl <norb...@hartl.name> wrote:
>>> 
>>> Sven,
>>> 
>>>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <s...@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.


Reply via email to