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 Pharo image. Regarding architecture and design. The idea of the 'new' streams is about simplification, streamlining and composability (if this is a real word) based on separation of concerns. It is my strong opinion that the current stream API is way to broad and complex. That is the main reason why it is not or should not be necessary to inherit from Stream. We want read and write streams to be separate, we want binary and character streams to be separate. Buffering, line end conversions, etc, should be pluggable. I remember that FLBufferedWriteStream was actual based on ZnBufferedWriteStream (one of FUEL's goals is performance), at a time when the primitive binary streams were unbuffered. That was years ago. Today, the high level binary streams are in principle buffered (ZnBufferedWriteStream) (although the raw ones still exist). It is thus no longer necessary to use FLBufferedWriteStream (although its API is slightly larger, it does a bit more than just buffer output). Now, looking at the specific selector you are talking about, #nextBytesPutAll: the way it is implemented and used, I can't understand why it even exists. Unless I am missing something it is the same as #nextPutAll: It is probably related to backwards or cross platform compatibility. Because today in Pharo, given a (buffered) binary stream, #nextPutAll: always takes bytes as argument. Another point is that right now, it seems double buffering is happening, which is not good. I guess we'll have to wait for one of the FUEL developers to chime in. All this being said, we are still in a transition period. Sven
On 9 Mar 2019, at 10:08, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:
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 enough to be sure that it doesn't cause trouble elsewhere. I added the method ZnBufferedWriteStream >> nextBytesPutAll:
nextBytesPutAll: aCollection self nextPutAll: aCollection
and all my problems are gone.
Konrad.