On Wed, 22 Feb 2017 15:09:44 -0800, c...@zoffix.com wrote:
> If .seek(... SeekFromCurrent) is called after a call to .readchars,
> the position sought to appears to be way off target:
>
> 22:54 IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you so very
> much"; with "/tmp/Foo.pm6".IO.open { .read(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 22:54 camelia rakudo-moar 5ec251: OUTPUT: «3»
> 22:55 IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you so very
> much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 22:55 camelia rakudo-moar 5ec251: OUTPUT: «24»
> 22:55 IOninja looks .readchars messes up the current position as
> far as seekage is concerned (it's fine if you try to read more, for
> example)
>
> After some discussion on IRC (https://irclog.perlgeek.de/perl6-
> dev/2017-02-22 ), one suggestion was that there's some sort of
> buffering involved:
>
> 23:00 m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much"; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00 camelia rakudo-moar 5ec251: OUTPUT: «24»
> 23:00 IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much" x 100; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00 camelia rakudo-moar 5ec251: OUTPUT: «2301»
> 23:00 jnthn Anyway, just sayin' that if it's off-by-one it's
> actually not lying :)
> 23:00 IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much" x 10000; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00 camelia rakudo-moar 5ec251: OUTPUT: «32769»
> 23:00 IOninja m: "/tmp/Foo.pm6".IO.spurt: "I love you\nso very
> much" x 20000; with "/tmp/Foo.pm6".IO.open { .readchars(2); .seek: 1,
> SeekFromCurrent; .tell.say }
> 23:00 camelia rakudo-moar 5ec251: OUTPUT: «32769»
>
> This behaviour is not present on JVM.
The fixes, and tests, made by Zoffix, when fixing
https://rt.perl.org/Public/Bug/Display.html?id=131376
covers this bug as well.
