From @masak

<colomon> rakudo​: say index("uuúuúuùù", "úuù")
<p6eval> rakudo 403afe​: ( no output )
* masak submits rakudobug
<masak> even locally, that oneliner produces nothing.
<masak> rakudo​: say index("uuúuúuùù", "úuù"); say "alive"
<p6eval> rakudo 403afe​: OUTPUT«alive␤»
<masak> isn't that strange?
<masak> I don't have an explanation for where the first newline goes.
<jnthn> wtf
<PerlJam> weird indeed
<jnthn> Me either.

From @masak

<pmichaud> 14​:38 <PerlJam> rakudo​: say index("úuúuùù", "úuù");
<pmichaud> 14​:38 <p6eval> rakudo 403afe​: ( no output )
<pmichaud> I call parrotbug.
<pmichaud> code coming up.
<pmichaud> http://nopaste.snit.ch/19794 # bug with index op?
<jnthn> Parrot FAIL.
* masak adds this to the RT ticket
<colomon> That doesn't explain the missing newline from say, does it?
<masak> actually, no.
<colomon> rakudo​: say index("hello", "elf");
<p6eval> rakudo 4fc3af​: ( no output )
<masak> except that a -1 probably translates into a Failure of some
kind.
<pmichaud> fail("Substring '$substring' not found in '{self}'") if
$result < 0;
<colomon> Yes, it becomes a fail.
<masak> ok, so the bug is actually two bugs.
<masak> one Parrot-based, and one having to do with &fail
<pmichaud> ah, yes.
<pmichaud> stringifying the failure causes it to throw the exception
<pmichaud> so say() never gets a chance to output the newline.
<masak> that's it, then.
<pmichaud> that, to me, is not a bug.
<masak> I don't see the failure being thrown, either.
<pmichaud> yeah, that part is an error
<pmichaud> Perhaps the failure is being thrown but we're never seeing
the message?
<pmichaud> rakudo​: sub foo() { fail 'bar'; 'xyz' }; say foo();
<p6eval> rakudo 4fc3af​: ( no output )
<pmichaud> parrot bug gets weirder​: http://nopaste.snit.ch/19795
<masak> o.O
<masak> so, just Unicode strings make the problem occur?
<colomon> Though there were Unicode string examples in the backlog
there that worked, right?
<colomon> It's not just all Unicode strings fail.
<masak> ok.
<colomon> rakudo​: say index("ùuúuù", "úuù");
<p6eval> rakudo 4fc3af​: OUTPUT«2␤»

@masak - Status changed from 'new' to 'open'

From @coke

On Fri Feb 26 07​:06​:43 2010, masak wrote​:

<pmichaud> 14​:38 <PerlJam> rakudo​: say index("úuúuùù", "úuù");
<pmichaud> 14​:38 <p6eval> rakudo 403afe​: ( no output )
<pmichaud> I call parrotbug.
<pmichaud> code coming up.
<pmichaud> http://nopaste.snit.ch/19794 # bug with index op?
<jnthn> Parrot FAIL.
* masak adds this to the RT ticket
<colomon> That doesn't explain the missing newline from say, does it?
<masak> actually, no.
<colomon> rakudo​: say index("hello", "elf");
<p6eval> rakudo 4fc3af​: ( no output )
<masak> except that a -1 probably translates into a Failure of some
kind.
<pmichaud> fail("Substring '$substring' not found in '{self}'") if
$result < 0;
<colomon> Yes, it becomes a fail.
<masak> ok, so the bug is actually two bugs.
<masak> one Parrot-based, and one having to do with &fail
<pmichaud> ah, yes.
<pmichaud> stringifying the failure causes it to throw the exception
<pmichaud> so say() never gets a chance to output the newline.
<masak> that's it, then.
<pmichaud> that, to me, is not a bug.
<masak> I don't see the failure being thrown, either.
<pmichaud> yeah, that part is an error
<pmichaud> Perhaps the failure is being thrown but we're never seeing
the message?
<pmichaud> rakudo​: sub foo() { fail 'bar'; 'xyz' }; say foo();
<p6eval> rakudo 4fc3af​: ( no output )
<pmichaud> parrot bug gets weirder​: http://nopaste.snit.ch/19795
<masak> o.O
<masak> so, just Unicode strings make the problem occur?
<colomon> Though there were Unicode string examples in the backlog
there that worked, right?
<colomon> It's not just all Unicode strings fail.
<masak> ok.
<colomon> rakudo​: say index("ùuúuù", "úuù");
<p6eval> rakudo 4fc3af​: OUTPUT«2␤»

The original string that caused the issue works now. Needs tests.

--
Will "Coke" Coleda

From @moritz

now tested in S32-str/index.t

@moritz - Status changed from 'open' to 'resolved'