Now I do not know the best way for you to get the new fixed version. It's too late to include it in P6.1, I guess, so... either add epicea into metacello configuration or wait until P7. On Fri, Sep 29, 2017 at 5:34 AM, Jan BlizniÄenko <bliznjan@fit.cvut.cz> wrote:
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
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html