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.
Cheers, - Andreas
On Mon, 15 Mar 2010, 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.
Did you check if this fix solves the SqueakMap issue?
Levente
Cheers,
- Andreas
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 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.
I am obviously a big fan of SqueakMap. I think a bump in usability/accessibility could reignite and elevate SqueakMap significantly upward for another 10 years..
Regards, Chris
2010/3/15 Göran Krampe goran@krampe.se:
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
Chris Muller wrote:
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.
How much code would that "add" to the image?
The short term fix is of course to use a different kind of serialization, and hey, perhaps a SmartRefStream works? I haven't had the time to try.
Andreas did a small XML hack a while back, and any kind of serialization works as a short term fix. The "only" problem is how to make sure other/older images works too - at least back to 3.8.
I am obviously a big fan of SqueakMap. I think a bump in usability/accessibility could reignite and elevate SqueakMap significantly upward for another 10 years..
Yeah, and I really would like to move to a different model altogether. A model which is more distributed. But that is a different story than fixing SqueakMap for 4.1.
Regards, Chris
regards, Göran
2010/3/16 Göran Krampe goran@krampe.se:
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.
Aye, this will be cheap, safe and very cool upgrade :)
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
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? ;)
regards, Göran
On 3/24/2010 1:56 AM, Göran Krampe wrote:
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? ;)
I very much hope so. The fix is in VMMaker we just need updated builds.
Cheers, - Andreas
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Chris Muller -
Göran Krampe -
Igor Stasenko -
Levente Uzonyi