You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have the feeling that the Zinc encoder is expected to work with a "bivalent" stream,
So that it can optimize and directly write bytes (see #next:putAllASCII:startingAt:toStream:).
In the example above, the encoder is used with a ZnBufferedWriteStream.
And writing bytes on such stream raises the exception.
I am able to workaround by making a change like this one:
Thanks for reaching out and reporting your problem with an executable snippet.
However (and I do not known if this is related to the snippet or your original issue), ZnMessages are meant to be written to and read from binary socket streams (and yes they also use some bivalent tricks).
Yes, that does help, thank you.
Then it means that we were wrongly using #writeOn: as a kind of "string printing utility" method.
And I guess it was working in some cases and not in some other.
Didn't know, thank you.
Here the objective was not to debug "live",
but rather to log (outside the image) comprehensive representation (status, header, entity) of some response we get.
Issue can be reproduced with a Pharo 7 image.
Here is a piece of code to reproduce:
I have the feeling that the Zinc encoder is expected to work with a "bivalent" stream,
So that it can optimize and directly write bytes (see #next:putAllASCII:startingAt:toStream:).
In the example above, the encoder is used with a ZnBufferedWriteStream.
And writing bytes on such stream raises the exception.
I am able to workaround by making a change like this one:
The text was updated successfully, but these errors were encountered: