- ruby-core - ml.ruby-lang.org

[ruby-core:114012] [Ruby master Bug#18810] Make `Kernel#p` interruptable.
by Eregon (Benoit Daloze) 23 Jun '23

23 Jun '23

Issue #18810 has been updated by Eregon (Benoit Daloze). Mmh, but it does work to interrupt `p`: ``` $ ruby -e 'o=Object.new; def o.inspect; loop { Thread.pass }; end; p 1; p o' 1 ^C-e:1:in `pass': Interrupt from -e:1:in `block in inspect' from -e:1:in `loop' from -e:1:in `inspect' from -e:1:in `p' from -e:1:in `<main>' ``` What am I missing then? ---------------------------------------- Bug #18810: Make `Kernel#p` interruptable. https://bugs.ruby-lang.org/issues/18810#change-103673 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- While figuring out https://bugs.ruby-lang.org/issues/18465 I found a test which fails when `rb_io_flush` becomes blocking.: https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 It seems unusual to me that `Kernel#p` is uninterruptible (unique among all Ruby methods). I'd like to make `Kernel#p` interruptible. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114011] [Ruby master Bug#18810] Make `Kernel#p` interruptable.
by Eregon (Benoit Daloze) 23 Jun '23

23 Jun '23

Issue #18810 has been updated by Eregon (Benoit Daloze). `p` being uninterruptible means all of `object.inspect` and potential Fiber scheduler code is run under `Thread.handle_interrupt(Object => :never) { ... }`. That seems a really bad idea, because e.g. if `inspect` would take a long time (creates a huge String or buggy), then it's not possible to interrupt it, e.g. with Ctrl+C. I think this is a CRuby bug, it's too dangerous to disable interrupts for arbitrary code. ---------------------------------------- Bug #18810: Make `Kernel#p` interruptable. https://bugs.ruby-lang.org/issues/18810#change-103672 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- While figuring out https://bugs.ruby-lang.org/issues/18465 I found a test which fails when `rb_io_flush` becomes blocking.: https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 It seems unusual to me that `Kernel#p` is uninterruptible (unique among all Ruby methods). I'd like to make `Kernel#p` interruptible. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114010] [Ruby master Bug#18810] Make `Kernel#p` interruptable.
by jeremyevans0 (Jeremy Evans) 22 Jun '23

22 Jun '23

Issue #18810 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to update the Kernel#p documentation: https://github.com/ruby/ruby/pull/7975 ---------------------------------------- Bug #18810: Make `Kernel#p` interruptable. https://bugs.ruby-lang.org/issues/18810#change-103671 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- While figuring out https://bugs.ruby-lang.org/issues/18465 I found a test which fails when `rb_io_flush` becomes blocking.: https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 It seems unusual to me that `Kernel#p` is uninterruptible (unique among all Ruby methods). I'd like to make `Kernel#p` interruptible. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114009] [Ruby master Bug#18933] Dir.tmpdir implemented in non-Ractor-safe manner
by jeremyevans0 (Jeremy Evans) 22 Jun '23

22 Jun '23

Issue #18933 has been updated by jeremyevans0 (Jeremy Evans). @nobu submitted a pull request to fix this upstream: https://github.com/ruby/tmpdir/pull/22 ---------------------------------------- Bug #18933: Dir.tmpdir implemented in non-Ractor-safe manner https://bugs.ruby-lang.org/issues/18933#change-103669 * Author: kreynolds (Kelley Reynolds) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- # Background Inside a Ractor, it is expected that generating a temporary directory using `Dir.tmpdir` will work. The current implementation uses a number of things which are not considered Rector-safe and will require refactoring. # How to reproduce ```ruby Ractor.new { Dir.tmpdir } ``` # Expectation and result The result is expected to be something along the lines of `"/var/folders/xm/y4c00x0s26sgf_zlnqjh_7800000gn/T"` but instead a `Ractor::IsolationError` exception is raised: ```ruby 3.1.2/lib/ruby/3.1.0/tmpdir.rb:23:in `tmpdir': can not access class variables from non-main Ractors (Ractor::IsolationError) ``` # Suggested solutions * Make cached class variable a shareable constant * Modify how random values are generated to be Rector-safe ---Files-------------------------------- tmpdir.diff (1.77 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114006] [Ruby master Bug#11064] #singleton_methods for objects with special singleton_class returns an empty array
by jeremyevans0 (Jeremy Evans) 22 Jun '23

22 Jun '23

Issue #11064 has been updated by jeremyevans0 (Jeremy Evans). I discussed this with @headius at RubyKaigi, and agree that it would be best to make `singleton_method` consistent with `singleton_methods`. As @matz indicated, NilClass/TrueClass/FalseClass instance methods should be considered as normal instance methods, not as singleton methods of nil, true, and false. I've submitted a pull request for that: https://github.com/ruby/ruby/pull/7973 ---------------------------------------- Bug #11064: #singleton_methods for objects with special singleton_class returns an empty array https://bugs.ruby-lang.org/issues/11064#change-103666 * Author: rbjl (Jan Lelis) * Status: Open * Priority: Normal * ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- ~~~ def nil.bla 42 end # works nil.bla #=> 42 nil.singleton_method(:bla) #=> #<Method: NilClass#bla> NilClass.instance_methods.include? :bla #=> true # does not work nil.singleton_methods #=> [] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112697] [Ruby master Bug#19479] Support IPv4-mapped IPv6 addresses in IPAddr#private?
by tgxworld (Guo Xiang Tan) 22 Jun '23

22 Jun '23

Issue #19479 has been reported by tgxworld (Guo Xiang Tan). ---------------------------------------- Bug #19479: Support IPv4-mapped IPv6 addresses in IPAddr#private? https://bugs.ruby-lang.org/issues/19479 * Author: tgxworld (Guo Xiang Tan) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` irb(main):010:0> IPAddr.new("172.16.0.0").private? => true irb(main):011:0> IPAddr.new("::ffff:172.16.0.0").private? => false ``` If IPAddr#private? is used in a critical code path, not supporting IPv4-mapped IPv6 addresses could lead to security issues. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113083] [Ruby master Bug#19569] #map on Enumerator::Lazy block arguments differ from regular #map
by TomNaessens (Tom Naessens) 21 Jun '23

21 Jun '23

Issue #19569 has been reported by TomNaessens (Tom Naessens). ---------------------------------------- Bug #19569: #map on Enumerator::Lazy block arguments differ from regular #map https://bugs.ruby-lang.org/issues/19569 * Author: TomNaessens (Tom Naessens) * Status: Open * Priority: Normal * ruby -v: 3.0.5...3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- A Ruby 2 to 3 upgrade surfaced the following issue: Ruby 2: ``` irb(main):252:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map(&:last).to_a => [:a, :b, :c] ``` Ruby 3: ``` irb(main):020:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map(&:last).to_a (irb):20:in `each': undefined method `last' for 1:Integer (NoMethodError) ``` Debugging the issue, I noticed the following: Map with a block returns only the first argument (and seems to ignore the zipped list): ``` irb(main):024:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |x| x }.to_a => [1, 2, 3] ``` It's not actually ignored though, it's just passed as a second argument: ``` irb(main):025:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |*x| x }.to_a => [[1, :a], [2, :b], [3, :c]] ``` Thus, this looks like a workaround: ``` irb(main):026:0> [1, 2, 3].to_enum.lazy.zip([:a, :b, :c]).map { |*x| x.last }.to_a => [:a, :b, :c] ``` But it behaves differently when leaving the `lazy` out: ``` irb(main):027:0> [1, 2, 3].to_enum.zip([:a, :b, :c]).map { |*x| x.last }.to_a => [[1, :a], [2, :b], [3, :c]] ``` Not sure if I'm correct in my conclusion, but to me it looks like the argument handling of `map` and `lazy_map` differs in an unexpected manner. Is this a bug/oversight, or I am simply using the different map implementations wrong? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113958] [Ruby master Feature#19741] Mirror YARP to Ruby
by kddnewton (Kevin Newton) 20 Jun '23

20 Jun '23

Issue #19741 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #19741: Mirror YARP to Ruby https://bugs.ruby-lang.org/issues/19741 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- At the [May Ruby Kaigi Dev Meeting](https://github.com/ruby/dev-meeting-log/blob/master/2023/DevMeetin…, Matz approved mirroring YARP into ruby/ruby. @jemmai and I are creating this redmine issue to log this work and link to the pull request. [Here](https://github.com/ruby/ruby/pull/7964) is the pull request that mirrors YARP into CRuby. We want to specifically also thank Adam Hess and Haldun Bayhantopcu for their contributions to YARP in getting us to this point. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113238] [Ruby master Misc#19599] DevMeeting-2023-05-10
by mame (Yusuke Endoh) 20 Jun '23

20 Jun '23

Issue #19599 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19599: DevMeeting-2023-05-10 https://bugs.ruby-lang.org/issues/19599 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/05/10 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/05/07. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

14 13

[ruby-core:113938] [Ruby master Bug#19736] Ripper.tokenize ignores token after heredoc_beg when embexpr inside heredoc is unclosed
by tompng (tomoya ishida) 19 Jun '23

19 Jun '23

Issue #19736 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19736: Ripper.tokenize ignores token after heredoc_beg when embexpr inside heredoc is unclosed https://bugs.ruby-lang.org/issues/19736 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-06-19T09:28:10Z master 2a80bac9f0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I expect Ripper.tokenize(code) to tokenize `+1+2+3\n` part. ```ruby code = <<'RUBY' <<A+1+2+3 #{4 RUBY Ripper.tokenize code # => ["<<A", "\#{", "4", "\n"] ``` It will be easy for IRB's internal code to handle indent and other things if Ripper.tokenize can tokenize all part of the code even if it is incomplete. -- https://bugs.ruby-lang.org/

1 0