Open bocasti opened 5 years ago
Hi,
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).
So your example works with
ByteArray streamContents: [:stream | znResponse writeOn: stream ].
But maybe that does not help ...
Sven
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.
Yes, exactly, it works in some cases, but not all.
You know about ZnLogEvent ? Try:
ZnLogEvent open
and use GT inspector to follow the announcements tab, you'll get real event objects that you can inspect.
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: