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.