From @masak

Rakudo r32151 contains a bug which makes it "read" a nonexistent blank
line at the end of files.

$ wc README | awk '{ print $1 }'
102

$ <README ./perl6 -e 'my $l = 0; while !$*IN.eof { $l++; my $dummy =
=$*IN; }; say $l'
103

From @masak

As a funny bonus, Parrot segfaults if the dummy assignment is left out
inside the loop​:

$ <README ./perl6 -e 'my $l = 0; while !$*IN.eof { $l++; =$*IN; }; say $l'
Segmentation fault

From @jnthn

Appears to be a bug in Parrot's .eof() method; sent a ticket on Parrot
for looking into this.

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

From @jnthn

See also related ticket
http://rt.perl.org/rt3/Ticket/Display.html?id=61224 - looks like we may
have to do our own thing in Rakudo to make this work...

From @pmichaud

On Sun Oct 26 12​:27​:26 2008, masak wrote​:

Rakudo r32151 contains a bug which makes it "read" a nonexistent blank
line at the end of files.

$ wc README | awk '{ print $1 }'
102

$ <README ./perl6 -e 'my $l = 0; while !$*IN.eof { $l++; my $dummy =
=$*IN; }; say $l'
103

IO.pod​:1207 claims that "IO.eof" is gone, to be replaced with
C<IO​::Endable>. But I can't seem to find any specification or
documentation on Endable.

So, I'm converting this ticket to a specbug, in hopes that p6l or
someone can sort it out.

If it turns out that IO.eof still exists, then should it continue to
have the Perl 5 behavior of performing a getc/ungetc to check EOF?

Pm

From wayland@wayland.id.au

Changed the spec so it refers to IO​::Seekable.eoi instead, since that
seems to perform the same function.

From @moritz

IO.eof seems to work now, and is documented in S32​::IO. All IO​::Endable
craziness is gone. Nothing to see here, move along :-)

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