Okay, I've finally addressed all these issues. The issue with the
readline method was definitely the bulk of the work. Since Socket and
FileHandle (and StringHandle, etc) share a common readline
implementation now, I've had to add the ability to use multi-character
record separators to all these types. This means, in master, you can
now do this:
var f = new 'FileHandle';
string s = f.readline("TEST");
The string argument to the readline method is optional. It defaults to
whatever the record_separator on the handle is. The old way of doing
this would be something like:
f.record_separator("TEST");
string s = f.readline();
Notice that this second method is probably faster if doing repeated
readlines where the encoding of the handle is different from the
encoding of the separator string (because the record separator needs
to be re-encoded for substring searching, and doing it once, as
opposed to doing it for every readline, is better). All these same
methods and caveats apply to Socket as well, since all the code is
shared.
I've got a little bit more testing to do on this branch, and I would
appreciate as much additional testing as is possible. Specifically,
getting NQP and Rakudo fully exercised is high-priority.
Thanks!
--Andrew Whitworth
On Mon, Jul 9, 2012 at 4:59 AM, Moritz Lenz <[email protected]> wrote:
> Hi,
>
> I've finally got around to a proper breakdown of the rakudo test failures
> caused by the whiteknight/io_cleanup1 branch. Sorry that it took that long.
>
> There are two blocks of failing tests in t/spec/S32-io/IO-Socket-INET.t.
>
> The first block is the discrepancy about .read(4) reading 4 bytes but
> returning a string in parrot/master. I'm happy to address this on the Rakudo
> side (and tests) once the branch is merged. I like the new behavior better.
>
> The second block is related to $socket.readline($sep) behaving differently
> from parrot/master with a non-\n separator (the first test that fails uses
> "\r\n" as a separator). I haven't tracked down what the exact bug is, but
> since those tests pass with parrot/master, I guess it's parrot regression.
>
> Finally there are two failing tests in t/spec/S16-filehandles/io.t.
> The cause here seems to be that $IO.read_bytes($n) reads $n bytes no matter
> what, even beyond the end of the file:
>
> $ hexdump -C io.test.data
> 00000000 66 f6 f6 |f..|
> 00000003
> $ ./perl6 -e 'my $f = open("io.test.data", :bin); say $f.read(10)'
> Buf:0x<66 f6 f6 d2 57 2b 00 00 a0 17>
>
> (Rakudo's IO.read calls the read_bytes method from parrots file handle)
> So it gives me the 10 bytes I asked for, even though it should have stopped
> after 3 bytes.
>
> Once the latter two regressions (readline separator and reading past the end
> of the file) are fixed, I'm happy to have the branch merged.
>
> Cheers,
> Moritz
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
