[#67346] Future of test suites for Ruby — Charles Oliver Nutter <headius@...>
I'll try to be brief so we can discuss all this. tl;dr: RubySpec is
19 messages
2015/01/05
[#67353] Re: Future of test suites for Ruby
— Tanaka Akira <akr@...>
2015/01/05
2015-01-06 7:18 GMT+09:00 Charles Oliver Nutter <headius@headius.com>:
[#67444] [ruby-trunk - Feature #10718] [Open] IO#close should not raise IOError on closed IO objects. — akr@...
Issue #10718 has been reported by Akira Tanaka.
3 messages
2015/01/09
[#67689] Keyword Arguments — Anthony Crumley <anthony.crumley@...>
Please forgive my ignorance as I am new to MRI development and am still
5 messages
2015/01/20
[#67733] [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5 — normalperson@...
Issue #10761 has been updated by Eric Wong.
4 messages
2015/01/21
[#67736] Re: [ruby-trunk - Bug #10761] Marshal.dump 100% slower in 2.2.0 vs 2.1.5
— Eric Wong <normalperson@...>
2015/01/22
normalperson@yhbt.net wrote:
[#67772] Preventing Redundant Email Messages — Jeremy Evans <code@...>
For a long time, I've wondered why I sometimes receive redundant email
5 messages
2015/01/23
[ruby-core:67452] [ruby-trunk - Feature #10718] IO#close should not raise IOError on closed IO objects.
From:
e@...
Date:
2015-01-09 03:08:24 UTC
List:
ruby-core #67452
Issue #10718 has been updated by Zachary Scott. I think the API is improved but I'm not sure we need to find & replace every occurrence in the stdlib On Thursday, January 8, 2015, <normalperson@yhbt.net> wrote: > Issue #10718 has been updated by Eric Wong. > > > Thank you for proposing this. I think this will simplify working with > Ruby IO and make me happier since I work with a lot of IO-related code. > Outside of test cases, I don't forsee compatibility problems either. > > ---------------------------------------- > Feature #10718: IO#close should not raise IOError on closed IO objects. > https://bugs.ruby-lang.org/issues/10718#change-50875 > > * Author: Akira Tanaka > * Status: Open > * Priority: Normal > * Assignee: > * Category: > * Target version: > ---------------------------------------- > I'd like to change IO#close. > It should not raise IOError on closed IO objects. > > We sometimes invoke IO#close only when the IO object is not closed as: > > ``` > f.close if !f.closed? > ``` > > If this issue is accepted, we can write it simply as follows. > > ``` > f.close > ``` > > Simple grep finds many examples. > Following examples are just a little excerpt. > > ``` > lib/webrick/server.rb: sock.close unless sock.closed? > lib/pstore.rb: file.close if !file.closed? > lib/mkmf.rb: @log.close if @log and not @log.closed? > lib/cgi/session.rb: f.close if f and !f.closed? > lib/open-uri.rb: io.close if !io.closed? > lib/net/pop.rb: s.close if s and not s.closed? > lib/net/http.rb: @socket.close if @socket and not @socket.closed? > lib/net/smtp.rb: s.close if s and not s.closed? > lib/shell/process-controller.rb: io.close unless io.closed? > test/ruby/test_io.rb: w.close unless !w || w.closed? > ... > ``` > > I think there is no problem with the behavior which IO#close doesn't raise > an exception on closed IO object. > Because the closed state fulfils the postcondition of the method. > > Moreover raising IOError can smash other exceptions if it is called in > ensure clause. > It makes debugging difficult and the proposed behavior ease it. > > It also useful to close IO object asynchronously. > Asynchronous close can be used for graceful shutdown. > This issue can eliminate "rescue IOError". > See lib/webrick/server.rb and lib/drb/drb.rb for example. > > Note that "double close" is a bad idea in C. > But it is not applicable to Ruby. > A FILE structure is freed on fclose(). > But Ruby's IO object is not freed until GC. > So method invocation on closed object doesn't cause invalid memory access. > A file descriptor (FD) can be reused any time because a signal handler or > another thread may allocate a FD. > But Ruby's IO object is not reused after close. > So it is impossible to close an IO object unintentionally. > > > ---Files-------------------------------- > io-close.patch (1.97 KB) > > > -- > https://bugs.ruby-lang.org/ > ---------------------------------------- Feature #10718: IO#close should not raise IOError on closed IO objects. https://bugs.ruby-lang.org/issues/10718#change-50876 * Author: Akira Tanaka * Status: Open * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- I'd like to change IO#close. It should not raise IOError on closed IO objects. We sometimes invoke IO#close only when the IO object is not closed as: ``` f.close if !f.closed? ``` If this issue is accepted, we can write it simply as follows. ``` f.close ``` Simple grep finds many examples. Following examples are just a little excerpt. ``` lib/webrick/server.rb: sock.close unless sock.closed? lib/pstore.rb: file.close if !file.closed? lib/mkmf.rb: @log.close if @log and not @log.closed? lib/cgi/session.rb: f.close if f and !f.closed? lib/open-uri.rb: io.close if !io.closed? lib/net/pop.rb: s.close if s and not s.closed? lib/net/http.rb: @socket.close if @socket and not @socket.closed? lib/net/smtp.rb: s.close if s and not s.closed? lib/shell/process-controller.rb: io.close unless io.closed? test/ruby/test_io.rb: w.close unless !w || w.closed? ... ``` I think there is no problem with the behavior which IO#close doesn't raise an exception on closed IO object. Because the closed state fulfils the postcondition of the method. Moreover raising IOError can smash other exceptions if it is called in ensure clause. It makes debugging difficult and the proposed behavior ease it. It also useful to close IO object asynchronously. Asynchronous close can be used for graceful shutdown. This issue can eliminate "rescue IOError". See lib/webrick/server.rb and lib/drb/drb.rb for example. Note that "double close" is a bad idea in C. But it is not applicable to Ruby. A FILE structure is freed on fclose(). But Ruby's IO object is not freed until GC. So method invocation on closed object doesn't cause invalid memory access. A file descriptor (FD) can be reused any time because a signal handler or another thread may allocate a FD. But Ruby's IO object is not reused after close. So it is impossible to close an IO object unintentionally. ---Files-------------------------------- io-close.patch (1.97 KB) -- https://bugs.ruby-lang.org/