Sven Van Caekenberghe <s...@stfx.eu> writes:
> FUEL is a binary serialiser, in the new Pharo 7 stream approach, a
> stream is either binary or textual, not both, nor can they be switched
> on the fly.
OK, thanks for confirming my suspicion that there was a change in Pharo.
> FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer
> newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ].
So what I have been using is correct.
Tim Mackinnon <tim@testit.works> writes:
> Hmmm - yesterday I had someone serialise their debug stack (the top
> right menu bar action) to a file and send it to me and it worked treat
> - so I wonder what the difference is?
The problem I have occurs in buffering code. I suspect that it happens
as a function of the size distribution of the objects that are
serialized.
The problem is best analyzed by looking at the implementors of
#nextBytesPutAll:. That's an extension method that Fuel puts on the
Stream hierarchy, including its own class FLBufferedWriteStream where
the method contains the lines
collection size > (self buffer size / 2)
ifTrue: [ stream nextBytesPutAll: collection ]
ifFalse: [ self nextBytesPutAll: collection ]
In the second line, it sends nextBytesPutAll: to the unbuffered
stream. Which should be fine if it inherits from Stream. But
ZnBufferedWriteStream does not inherit from Stream.
I tried unraveling the construction of ZnBufferedWriteStream, to use
directly its underlying stream:
| ref stream |
ref := FileLocator temp / 'test.fuel'.
stream := ref fileSystem binaryWriteStreamOn: ref path.
[ FLSerializer newDefault serialize: { 'Foo'. #bar. Float pi. 42 }
on: stream ]
ensure: [ stream close ]
On a standard file, that yields a BinaryFileStream, and everything works
fine. But for my test cases I use a MemoryFileSystem, and then I get
the same problem again - MemoryFileWriteStream does not inherit from
Stream either.
I wonder what's wrong with the Stream class - why are there stream-type
classes that don't inherit from it?
Konrad.
