On Tue, Jun 14, 2011 at 12:56 AM, Yanni Chiu <yanni@rogers.com> wrote:
On 13/06/11 5:49 PM, Mariano Martinez Peck wrote:
Why the following is not enought?
(FLSerializer on: myStream) serialize: myPRKernel.
and
(FLMaterializer on: myStream) materialize
Yes, that's pretty much the code. Except that it's in a test case that uses FSMemoryStore. The tests run a lot faster when writing to memory, instead of to disk.
Yes, but if you want to serialize in memory you can also use for example: myStream := (MultiByteBinaryOrTextStream on: ''). (FLSerializer on: myStream) serialize: myPRKernel. ... myStream reset. (FLMaterializer on: myStream) materialize That would use a stream in memory. And even more, you can serialize in memory with Fuel this way: testSerializationAndMaterializationInMemory | byteArray materializedObject | byteArray := FLSerializer serializeInMemory: 'mariano'. materializedObject := FLMaterializer materializeFromByteArray: byteArray. self assert: materializedObject equals: 'mariano'.
The FSMemoryStore holds the "file" bytes in a ByteArray. During
serialization, I got a stack trace with KeyNotFound due to FLSerializer>>nextPutReferenceTo: when the object is the "file" ByteArray.
Since this ByteArray is where the serialization is being written to,
mmmmmm so you are using a stream to serialize and such stream is also being refenced from the object to serialize?
Yes, that's it - except that the stream is an FSWriteStream on a FSMemoryStore "file", which I think is an issue here. The PRKernel is holding an instance of PRFuelPersistency, which holds an FSReference. That FSReference happens to refer to a memory-based "file".
-- Mariano http://marianopeck.wordpress.com