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".