Problems with record sep in Rakudo.

[p6rt]

Migrated from rt.perl.org#122971 (status was 'resolved')

Searchable as RT122971$

[p6rt]

From @cjfields

I'm seeing a bug with the current implementation of the nl parameter for IO.open. If I parse a standard FASTA file in p5 I can set the input line separator to "\n>", which will split records quite efficiently. If I try to to the same in rakudo doing as in the following gist example​:

https://gist.github.com/cjfields/f2a2c274039556b1e6dc

it doesn't work as expected. In the first instance it matches the beginning '>' even though there isn't a preceding new line; similarly in the others it matches the '>'. Seems likely that it is only matching the last character in the string, not the entire string; maybe an nqp issue?

[p6rt]

From @cjfields

Forgot to mention​:

[cjfields@​Chriss-MacBook-Pro bioperl6]$ perl6 -v
This is perl6 version 2014.09-202-g8b3e8c2 built on MoarVM version 2014.09-54-g03ac9a7

[p6rt]

From @FROGGS

That is an issue in MoarVM, which I was aware about yesterday when making line separators available to open() calls.
I am about to fix that today.

[p6rt]

The RT System itself - Status changed from 'new' to 'open'

[p6rt]

From @cjfields

On Mon Oct 13 23​:36​:32 2014, FROGGS.de wrote​:

That is an issue in MoarVM, which I was aware about yesterday when
making line separators available to open() calls.
I am about to fix that today.

Cool! Yeah, I kinda wondered about that, as nqp seemed to return the expected line ending when I tested it.

[p6rt]

From @jnthn

On Mon Oct 13 21​:04​:38 2014, cjfields wrote​:

I'm seeing a bug with the current implementation of the nl parameter
for IO.open. If I parse a standard FASTA file in p5 I can set the
input line separator to "\n>", which will split records quite
efficiently. If I try to to the same in rakudo doing as in the
following gist example​:

https://gist.github.com/cjfields/f2a2c274039556b1e6dc

it doesn't work as expected. In the first instance it matches the
beginning '>' even though there isn't a preceding new line; similarly
in the others it matches the '>'. Seems likely that it is only
matching the last character in the string, not the entire string;
maybe an nqp issue?

Up until today, MoarVM could only handle reading lines with a one single-char separator. It's now able to handle multi-char separators, and multiple of those, so the code in this ticket now works. Added a test case to S16-filehandles/io_in_while_loops.t.

Thanks,

/jnthn

[p6rt]

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