Last updated at 4:37 pm UTC on 1 July 2018
loads fine in Squeak 3.10.2, for example in this release: BabyIDE.
Loading it into 5.2 gives problems.
Notes (to be refined)
Projects files use VM-specific encoding, so they can't be used across different types of VM :-(
An ImageSegment is a WordArray whose contents are a sequence of heap objects in the VM's native object format. A segment is loaded by invoking a primitive that swizzles the pointers in the word array so that they become valid objects, and then shortening the word array, leaving the objects behind in memory. Since the contents of the WordArray are specific to a given VM architecture one cannot use the primitive loading mechanism to load segments from VMs with different object representations.
I am confused with the first statement. segment in ImageSegment is byte indexed and ByteArray has support for endian read/writes. Is there any reason why WordArray was used instead of ByteArray?
I dug into this a little deeper today as it gave me an opportunity to study ImageSegments. I extracted the cs from 001 and used a binary editor to search for version number. I found one sequence 16r64006619 which decodes to a big-endian 6502 format ImageSegment.
In the project file 002, I found the sequence 16r66190073 which decodes to a little-endian segment.
When I dropped 001 pr (= the one attached to this page) into Squeak 5.2alpha (18120/64b/Ubuntu) and examined the resulting error stack I found something strange.
Before the endian check in LegacyImageSegment>>#comeFullyUpOnReload, the instance is already created in DataStream>>#next method assuming little-endian, so segment ivar first word is 16r66190064. Therefore, the endianness check in:
... ^(segment first bitShift: -24) asCharacter == $d ifTrue: [#big] ifFalse: [#little]
ends up checking the wrong byte for endianness. I changed this code to check for both $s and $d and confirmed that endian check is incorrect at this point.
I got stuck here. How should one fix this error?