I'm glad it has known reason then, thank you for looking into it, all I was
able to find out was that it relates to non-ascii characters and that build
on our production server fails because of that :)
Jan
tinchodias wrote
> On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe <
> sven@
> > wrote:
>
>>
>> > On 23 Sep 2017, at 22:42, Jan Blizni��enko <
> bliznjan@.cvut
> > 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