Re: Some notes about SqueakMap dead in trunk images...

> On 3/15/2010 1:26 PM, Göran Krampe wrote:
>> But so far I am unclear as to why this is so. I have now tested LOTS of
>> trunk images backwards and it seems to be broken all the way down to
>> 7179! Funny thing is - my 3.10.1-7175 image works fine.
>>
>> And there may be a hint here: The 7175 image can be opened by an old
>> 3-9-8 VM. But the later 7179 images can NOT be opened due to some kind
>> of image format change.
>
> Bingo. The issue is that the image format changed for closures and
> there's been a bug in the image segment loading code that makes the
> primitive fail in cases where the image format is older, but compatible.

>
> Hi!
>
> Andreas Raab wrote:
>>
>> On 3/15/2010 1:26 PM, Göran Krampe wrote:
>>>
>>> But so far I am unclear as to why this is so. I have now tested LOTS of
>>> trunk images backwards and it seems to be broken all the way down to
>>> 7179! Funny thing is - my 3.10.1-7175 image works fine.
>>>
>>> And there may be a hint here: The 7175 image can be opened by an old
>>> 3-9-8 VM. But the later 7179 images can NOT be opened due to some kind
>>> of image format change.
>>
>> Bingo. The issue is that the image format changed for closures and there's
>> been a bug in the image segment loading code that makes the primitive fail
>> in cases where the image format is older, but compatible.
>
> Ah, good that we know what it is then.
>
>> I've posted a fix for that in VMMaker but I really think SM should stop
>> using image segments for data exchange. Image segments are not a reliable
>> long-term interchange format in an evolving system.
>
> Sure, I am all in agreement. I am slightly amazed we got away with it this
> long :)
>
> When it comes to persistence I am pretty sold on CouchDB these days. If you
> just have the ability to make trivial HTTP GETs and parse JSON - then you
> can load stuff from a CouchDB instance.
>
> Anyway, I really need to sleep but we should take SM by the balls and make a
> plan for how to evolve it into the next 10 years :)
>
> SqueakMap was born somewhere in 2002 IIRC.
>
>> Obviously, this fix requires new VMs.
>>
>> Cheers,
>>  - Andreas
>
> Mmmm.
>
> regards, Göran
>
>

>
> Hi!
>
> Andreas Raab wrote:
>>
>> On 3/15/2010 1:26 PM, Göran Krampe wrote:
>>>
>>> But so far I am unclear as to why this is so. I have now tested LOTS of
>>> trunk images backwards and it seems to be broken all the way down to
>>> 7179! Funny thing is - my 3.10.1-7175 image works fine.
>>>
>>> And there may be a hint here: The 7175 image can be opened by an old
>>> 3-9-8 VM. But the later 7179 images can NOT be opened due to some kind
>>> of image format change.
>>
>> Bingo. The issue is that the image format changed for closures and there's
>> been a bug in the image segment loading code that makes the primitive fail
>> in cases where the image format is older, but compatible.
>
> Ah, good that we know what it is then.
>
>> I've posted a fix for that in VMMaker but I really think SM should stop
>> using image segments for data exchange. Image segments are not a reliable
>> long-term interchange format in an evolving system.
>
> Sure, I am all in agreement. I am slightly amazed we got away with it this
> long :)
>
> When it comes to persistence I am pretty sold on CouchDB these days. If you
> just have the ability to make trivial HTTP GETs and parse JSON - then you
> can load stuff from a CouchDB instance.
>

> Anyway, I really need to sleep but we should take SM by the balls and make a
> plan for how to evolve it into the next 10 years :)
>
> SqueakMap was born somewhere in 2002 IIRC.
>
>> Obviously, this fix requires new VMs.
>>
>> Cheers,
>>  - Andreas
>
> Mmmm.
>
> regards, Göran
>
>

> On 3/15/2010 1:26 PM, Göran Krampe wrote:
>> But so far I am unclear as to why this is so. I have now tested LOTS of
>> trunk images backwards and it seems to be broken all the way down to
>> 7179! Funny thing is - my 3.10.1-7175 image works fine.
>>
>> And there may be a hint here: The 7175 image can be opened by an old
>> 3-9-8 VM. But the later 7179 images can NOT be opened due to some kind
>> of image format change.
>
> Bingo. The issue is that the image format changed for closures and
> there's been a bug in the image segment loading code that makes the
> primitive fail in cases where the image format is older, but compatible.
> I've posted a fix for that in VMMaker but I really think SM should stop
> using image segments for data exchange. Image segments are not a
> reliable long-term interchange format in an evolving system.
>
> Obviously, this fix requires new VMs.

>  
> Hi Göran, I'm glad you're on for getting SqueakMap going, thank you.
> CouchDB sounds like it might be a great solution for SqueakMap.  If,
> however, you do decide to consider a near drop-in replacement for
> ImageSegments, I have been using
> MaObjectSerializer>>#fileOut:toFileNamed:in: to save/load my objects
> into files intead of ImageSegments for the very reason Andreas said.
> With MaObjectSerialization, it is a logical serialization, not
> physical, which is of course image independent but also safer because
> the Buffer domain maintains full control.  MaObjectSerializer
> class>>#objectFromStream loads.  I would be happy help with this if
> you want.

> Andreas Raab wrote:
>> On 3/15/2010 1:26 PM, Göran Krampe wrote:
>>> But so far I am unclear as to why this is so. I have now tested LOTS of
>>> trunk images backwards and it seems to be broken all the way down to
>>> 7179! Funny thing is - my 3.10.1-7175 image works fine.
>>>
>>> And there may be a hint here: The 7175 image can be opened by an old
>>> 3-9-8 VM. But the later 7179 images can NOT be opened due to some kind
>>> of image format change.
>>
>> Bingo. The issue is that the image format changed for closures and
>> there's been a bug in the image segment loading code that makes the
>> primitive fail in cases where the image format is older, but
>> compatible. I've posted a fix for that in VMMaker but I really think
>> SM should stop using image segments for data exchange. Image segments
>> are not a reliable long-term interchange format in an evolving system.
>>
>> Obviously, this fix requires new VMs.
>
> So you are saying/proposing that 4.1 will be released with this new VM
> or? ;)