On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

> On 23 Sep 2017, at 22:42, Jan Blizni��enko <bliznjan@fit.cvut.cz> wrote:
>
> Hello
>
> I am having very similar errors from time to time when manually loading code
> into Pharo from filetree (gitfiletree), but only in one of my projects which
> contains non-ASCII characters like ��������������������������. For the very same reason
> (not able to find why sometimes the error is there and sometimes is not), I
> did not report it yet, but it is quite annoying. Retrying loading the
> package helps every time.

I think was reported before. I believe Ombu somewhere takes an arbitrary chunk of bytes out of an UTF-8 encoded file (like the last 100 of something like that) and then starts reading that. With UTF-8, a variable length encoding, that can be dangerous because you could end up in the middle of a character, not between encoded character boundaries. This would also explain the randomness, as it is highly dependent on the contents.

ZnUTF8Encoder>>#backOnStream: can be used to make sure you are really at the start of an encoded character.


Hello

This issue was reported as:

https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail-while-reading-non-ascii-blocks

My apologies for the bug... I introduced that code as an i/o optimization but wasn't properly tested.

Thnks Sven, but I finally used stream's #basicNext (as Henrik suggested in fogbugz) which skips forward.


Martin