Tx martin I added https://pharo.fogbugz.com/f/cases/20492/Update-EPICEA Do you have a bug entry for the 7.0 integration or should I create one? Stef On Tue, Oct 3, 2017 at 7:58 PM, Martin Dias <tinchodias@gmail.com> wrote:
I've put ConfigurationOfEpicea 8.2.4 in p6 inbox. MartÃn
On Tue, Oct 3, 2017 at 1:40 PM, Martin Dias <tinchodias@gmail.com> wrote:
Hi
On Tue, Oct 3, 2017 at 11:40 AM, Gabriel Cotelli <g.cotelli@gmail.com> wrote:
Yes, please backport the changes to Pharo 6.1 because the travis builds are failing a lot with this kind of errors when you have a project with non-ASCII characters.
Ok
Probably it makes no sense to enable Epicea in the images used by SmalltalkCI. Is there some way to disable it?
Sure, you can evaluate: EpMonitor reset
On Mon, Oct 2, 2017 at 10:18 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
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 <tinchodias@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 <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-as...
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