Hi, > On 16 Dec 2015, at 08:21, Eliot Miranda <[email protected]> wrote: > > Hi Esteban, > > On Dec 15, 2015, at 5:06 AM, Esteban Lorenzano <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On 15 Dec 2015, at 13:18, Norbert Hartl <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> We have a test build for pharo5 that checks if we need to do stuff for >>> future migrations. Since yesterday it fails, of course. >>> I have a fueled out object graph stored as byte array in a method. The fuel >>> bytes are serialized using a non-spur image. Now when the spur image reads >>> the bytes I get an exception. Has this something to do with immediate >>> characters? Is there a way to fix that or will it just not be possible to >>> exchange objects between spur and non-spur using fuel? >> >> I think is not possible, but I will let fuel maintainers to have the last >> word :) > > > Of course it's possible; in VW we exchanged objects between 32- & 64-but > images using a format much like fuel and in 32-bits all floats are arrays of > 32-bit bit objects whereas in 64-bits a range of floats are immediate.
Oh well… of course is possible. What I meant is that I think current implementation of Fuel does not support it, just that :) but again, I’m not sure: Martin and Mariano can for sure say something more detailed about :) (problem is Martin is on vacations after getting his PhD and Mariano didn’t followed in close the spur migration) cheers, Esteban > > In spur characters are immediate (Max, "primitive" is not the right term) > whereas in v3 they're objects with a single isn't var. So at least fuel > needs to be modified to read characters specially. One way to architect this > is to ask the class (SmallInteger, Character, Float etc) to materialize, and > then the class can decide how to represent its instances. The question is > whether characters in spur should serialize themselves using the same wire > format as v3 or whether fuel should modify its wire format to serialize > immediate characters specially and have v3 materialize characters as > serialized by spur. The issue is whether it's important to preserve object > identity of characters with code >= 256 or not. > >> >> Esteban >> >>> >>> thanks, >>> >>> Norbert >>> >>> >>> primitive #value: in Character class failed >>> Stacktrace >>> >>> Character class(Object)>>primitiveFailed: >>> Character class(Object)>>primitiveFailed >>> Character class>>value: >>> Character class>>materializeFrom: >>> FLHookPrimitiveCluster>>materializeInstanceWith: >>> FLHookPrimitiveCluster(FLIteratingCluster)>>materializeInstancesStepWith: >>> FLMaterialization>>clusterInstancesStep >>> [ self clusterInstancesStep ] in FLMaterialization>>instancesStep >>> SmallInteger(Integer)>>timesRepeat: >>> FLMaterialization>>instancesStep >>> FLMaterialization>>run >>> [ :aDecoder | >>> (FLMaterialization with: aDecoder) >>> run; >>> yourself ] in FLMaterializer>>setDefaultMaterialization >>> FLMaterializer>>materializeFrom: >>> FLMaterializer class>>materializeFromByteArray: >>> MAPExampleModels class>>readModelFromSelector: >>> MAPExampleModels class>>readModelNamed: >>> [ self readModelNamed: aString ] in MAPExampleModels class>>named: >>> [ self at: key put: aBlock value ] in Dictionary>>at:ifAbsentPut: >>> Dictionary>>at:ifAbsent: >>> Dictionary>>at:ifAbsentPut: >>> MAPExampleModels class>>named: >>> MAPTest>>model >>> MAPTest>>tcapModule >>> MAPTest>>testInsertSubscriberDataBitStringAccess >>> [ testMethod perform: testMethod selector ] in Given>>produceReturnValueAt: >>> [ self at: key put: aBlock value ] in Dictionary>>at:ifAbsentPut: >>> Dictionary>>at:ifAbsent: >>> Dictionary>>at:ifAbsentPut: >>> Given>>produceReturnValueAt: >>> MAPTest(Phexample)>>performTest >>> >>> >>
