[#24105] [Bug #1711] Marshal Failing to Round-Trip Certain Recurisve Data Structures — Run Paint Run Run <redmine@...>

Bug #1711: Marshal Failing to Round-Trip Certain Recurisve Data Structures

9 messages 2009/07/01

[#24116] [Bug #1715] Numeric#arg for NaN is Inconsistent Across Versions — Run Paint Run Run <redmine@...>

Bug #1715: Numeric#arg for NaN is Inconsistent Across Versions

10 messages 2009/07/02

[#24240] [Bug #1755] IO#reopen Doesn't Fully Associate with Given Stream on 1.9; Ignores pos on 1.8 — Run Paint Run Run <redmine@...>

Bug #1755: IO#reopen Doesn't Fully Associate with Given Stream on 1.9; Ignores pos on 1.8

8 messages 2009/07/09

[#24321] [Bug #1773] Gem path doesn't honor user gem? — Lin Jen-Shin <redmine@...>

Bug #1773: Gem path doesn't honor user gem?

12 messages 2009/07/14

[#24390] [Feature #1784] More encoding (Big5 series) support? — Lin Jen-Shin <redmine@...>

Feature #1784: More encoding (Big5 series) support?

12 messages 2009/07/16

[#24467] Re: [ruby-cvs:31226] Ruby:r24008 (ruby_1_8_6): Removed private on to_date and to_datetime. — Urabe Shyouhei <shyouhei@...>

Hello.

10 messages 2009/07/21

[#24472] [Feature #1800] rubygems can replace system executable files — Kazuhiro NISHIYAMA <redmine@...>

Feature #1800: rubygems can replace system executable files

13 messages 2009/07/21

[#24530] [Feature #1811] Default BasicSocket.do_not_reverse_lookup to true — Roger Pack <redmine@...>

Feature #1811: Default BasicSocket.do_not_reverse_lookup to true

9 messages 2009/07/23

[#24624] [Bug #1844] Immediates Should Not Respond to :dup — Run Paint Run Run <redmine@...>

Bug #1844: Immediates Should Not Respond to :dup

15 messages 2009/07/30

[ruby-core:24562] Re: Expected change in behavior for ARGF.eof?

From: Mike Kasick <mkasick-rc@...>
Date: 2009-07-26 03:01:13 UTC
List: ruby-core #24562
On Sat, Jul 25, 2009 at 03:49:25PM +0900, Heesob Park wrote:

> I guess it is a bug of 1.9.x.

I concur.  I took a close look today at the ARGF code.  I'm not sure if
this is documented elsewhere, but for the sake of explicitness, this is
what looks like is going on:

On startup, ARGF is in a kind of "pre-initalized" state in that the File
object for ARGV[0] is yet to be loaded.  This is flagged by "init_p", where
"init_p == 0" means pre-initialized and "init_p == 1" means initialized
(that is, ARGF.current_file points to an actual file).  This initalization
takes place in the "next_argv" function (actually a macro for
argf_next_argv).

There's also a "next_p" state flag, where 0 means ARGF.current_file is
active and should be maintained across the next_argv function, 1 means
ARGF.current_file is closed and should be switched to the next file, and -1
means ARGF.current_file points to $stdin.

Anyways, it looks to me like all ARGF methods should respond to the
pre-initalized state by either calling "next_argv", or otherwise maintain
the illusion that ARGF is initialized.

Most ARGF methods just call "next_argv" early on.  The exceptions are
ARGF.skip and ARGF.eof.  Both are supposed to check the status of init_p to
short circuit in the pre-initialized, but neither was actually doing so
until recently.

> > Also, is there a way to advance ARGF to the next (in ARGV) file once EOF
> > for the current file has been reached?
>
> In my test, ARGF.gets advanced ARGF to the next file in ARGV

Sorry, I should've qualified that by saying "without reading from the
current ARGF stream".

It looks like ARGF.skip is supposed to do this.  ARGF.close will as well,
but ARGF.skip won't close $stdin.  The problem is that neither can be
directly followed by a call to ARGF.eof:

$ echo foo > /tmp/foo; echo bar > /tmp/bar
$ ./ruby -e 'ARGF.gets; ARGF.skip; p ARGF.eof?' /tmp/foo /tmp/bar
-e:1:in `eof?': closed stream (IOError)
        from -e:1:in `<main>'

This can be made to work for now by calling one of the ARGF accessor
methods that calls "next_argv" as a side-effect between skip and eof:

$ ./ruby -e 'ARGF.gets; ARGF.skip.file; p ARGF.eof?' /tmp/foo /tmp/bar
false

But probably the better solution is to fix ARGF.eof to call "next_argv" in
the "init_p != 0" case like other methods do.

I submitted a bug/patch to the issue tracker, #1818.

Thanks everyone!

In This Thread

Prev Next