I concluded that trying to run Fuel-1.8 in Pharo-2.0 was a pointless
exercise. I needed to migrate to 1.8.x or 1.9. So I decided to migrate
to 1.9 in my current Pharo-1.4 based image. This time, I've captured the
migration in classes, which was not too hard (last migration I just ran
code in workspaces).
I tried to write a test case for the migration, but this failed
strangely. When I run:
((Smalltalk at: #ConfigurationOfFuel) project version: '1.9') load: 'Core'
from a workspace it works. But when it is run through a TestCase, it
fails to load the newer version on top of the older version, and it
fails silently - I think TestCase, Metacello, Gofer or Monticello is
swallowing an exception. I tried having the test case return
FLMaterializer via "Smalltalk at: #FLMaterializer" (and same for
FLSerializer), but it made no difference. The test case was eventually
supposed to use #forkHeadlessSqueakAndDo: to run, but I've given up on
the test for now.
The other oddity I noted was that
FLMaterializer/FLSerializer>>currentVersion answers integers like: 18,
181, 182, 19. So, if there are ever over 100 format versions of Fuel,
then there will be some confusion. This came up when I briefly
considered altering the version check to allow 1.8.2 to load a 1.8
version Fuel file.
On 14/03/13 10:56 AM, Martin Dias wrote:
> Hi Yanni,
>
> Could you migrate all your objects to the new format?
>
> Best regards,
> Martin
>
> On Fri, Mar 1, 2013 at 10:49 PM, Yanni Chiu <
[hidden email]> wrote:
>>
>>
>> On 01/03/13 1:54 PM, Martin Dias wrote:
>>>
>>> I'm sorry but AFAIK you won't be able to materialize in 1.8.x the files
>>> you serialized with 1.8. Maybe Max has some trick to do it?
>>
>>
>> I got an exception:
>>
>> FLBadVersion: Materialization error. Unexpected stream version 18 where
>> it should be 182.
>>
>> I disabled the version check, and things loaded fine. But, I've yet to find
>> a saved file with a Date or DateAndTime instance.
Locked
