Hi Sven,
Thanks for all that background information on the history of streams. It
makes everything a lot clearer for me.
> But first, it would help a lot that you give a self-contained
> reproducible snippet that raises your problem, like mine. I tried
> reproducing your failure but could not.
Konrad,
You are raising many different points, I'll try to answer them.
But first, it would help a lot that you give a self-contained reproducible
snippet that raises your problem, like mine. I tried reproducing your failure
but could not.
Also note that all FUEL tests are green on a recent
Am 09.03.19 um 08:16 schrieb Konrad Hinsen:
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.
The fix I found is simple, but I don't understand the whole system well
Sven Van Caekenberghe 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'
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.
FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer
newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ].
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?
Tim
Sent from my iPhone
> On 8 Mar 2019, at 20:22, Konrad Hinsen wrote:
>
> Hi everyone,
>
> after playing with
Hi everyone,
after playing with FUEL in-memory (byte arrays) for a while, I am ready
to attack files. But... that's not so easy.
At
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Fuel/Fuel.html
I find the basic exxample
'demo.fuel'
