Martin

if you publish a fix for 6.1 we will port it back because this is important.

Stef

On Fri, Sep 29, 2017 at 3:55 PM, Martin Dias <tinchod...@gmail.com> wrote:
> 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 <blizn...@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 &lt;
>>
>> > sven@
>>
>> > &gt; wrote:
>> >
>> >>
>> >> > On 23 Sep 2017, at 22:42, Jan Blizničenko &lt;
>>
>> > bliznjan@.cvut
>>
>> > &gt; 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
>>
>

Reply via email to