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

[ruby-core:111484] [Ruby master Bug#19278] Constructing subclasses of Data with positional arguments
by tenderlovemaking (Aaron Patterson) 30 Dec '22

30 Dec '22

Issue #19278 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #19278: Constructing subclasses of Data with positional arguments https://bugs.ruby-lang.org/issues/19278 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I'd expect both of the following subclasses to work, but the subclass that uses positional parameters raises an exception: ```ruby Foo = Data.define class Bar < Foo def initialize foo: p foo end end class Baz < Foo def initialize foo p foo end end Bar.new foo: 1 # Prints 1 Baz.new 1 # Raises ArgumentError ``` I'd expect the subclass that uses positional arguments to work. -- https://bugs.ruby-lang.org/

4 15

[ruby-core:111540] [Ruby master Feature#15778] Expose an API to pry-open the stack frames in Ruby
by st0012 (Stan Lo) 30 Dec '22

30 Dec '22

Issue #15778 has been updated by st0012 (Stan Lo). I think such feature has a great potential for production use too, especially for error monitoring. For example, both [Rollbar](https://rollbar.com) and [Sentry](https://sentry.io) tries to support local variables capturing with `TracePoint`: - [Rollbar's implementation](https://github.com/rollbar/rollbar-gem/blob/caa82a97177b946… (captures all frames' data) - [Sentry's implementation](https://github.com/getsentry/sentry-ruby/blob/3097c49c16de2… (captures only the current frame's data) But as we all know, using `TracePoint` in production is usually risky. So this feature in both services remained "experimental" and is disabled by default, even though it'd be super helpful to users. I think in a sense it proves @Eregon's point: > hiding it in the C API is not much of a safety, but it makes it inconvenient to use, inefficient (see above) and not portable (e.g., cannot be implemented on JRuby as a C API). If there can be a bundled gem to power usage like: ```rb caller_locations(1, 1, debug: true).first.binding ``` it'd level up our developer's debugging experience significantly in both development and production. ### Reasons to have a bundled gem then just use [`binding_of_caller`](https://github.com/banister/binding_of_caller) 1. From a business' perspective, it's easier to convince customers adding a language-official library than a community library. 2. We can be confident that it'd work well with Ruby's latest development, especially with YJIT. 3. It'd allow better cross-platform support. (As a side note, [Honeybdger](https://www.honeybadger.io/) supports it via [`binding_of_caller`](https://github.com/banister/binding_of_caller), but also disables it by default). ---------------------------------------- Feature #15778: Expose an API to pry-open the stack frames in Ruby https://bugs.ruby-lang.org/issues/15778#change-100904 * Author: gsamokovarov (Genadi Samokovarov) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Hello, I'm the maintainer of the web-console (https://github.com/rails/web-console/) gem, where one of our features is to jump between the frames in which an error occurred. To accomplish this, I currently use the Debug Inspector CRuby API. I think we should expose this functionality in Rubyland, so tools like web-console don't need to resort to C code for this. This also makes it quite harder for me to support different implementations like JRuby or TruffleRuby as everyone is having a different way to create Ruby Binding objects that represent the frames. Here the API ideas: Add `Thread::Backtrace::Location#binding` method that can create a binding for a specific caller of the current frame. We can reuse the existing `Kernel.caller_locations` method to generate the array of `Thread::Backtrace::Location` objects. We can optionally have the `Kernel.caller_locations(debug: true)` argument if we cannot generate the bindings lazily on the VM that can instruct the VM to do the slower operation. - `Thread::Backtrace::Location#binding` returns `Binding|nil`. Nil result may mean that the current location is a C frame or a JITted/optimized frame and we cannot debug it. We can also expose the DebugInspector API directly, as done in the https://github.com/banister/debug_inspector gem, but for tools like web-console, we'd need to map the bindings with the backtrace, as we cannot generate Bindings for every frame (C frames) and this needs to be done in application code, so I think the `Thread::Backtrace::Location#binding` is the better API for Ruby-land. Such API can help us eventually write most of our debuggers in Ruby as right now we don't have a way to do Post-Mortem debugging without native code or even start our debuggers without monkey-patching `Binding`. I have presented this idea in a RubyKaigi's 2019 talk called "Writing Debuggers in Plain Ruby", you can check-out the slides for more context: http://kaigi-debuggers-in-ruby.herokuapp.com. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111277] [Ruby master Feature#19232] add NoMatchingPatternError#matchee
by dalexj (alex jensen) 30 Dec '22

30 Dec '22

Issue #19232 has been reported by dalexj (alex jensen). ---------------------------------------- Feature #19232: add NoMatchingPatternError#matchee https://bugs.ruby-lang.org/issues/19232 * Author: dalexj (alex jensen) * Status: Open * Priority: Normal ---------------------------------------- currently if you pattern match a Hash, you can inspect the #key and #matchee methods from the NoMatchingPatternKeyError ```ruby begin { error: true } => { value: } rescue NoMatchingPatternKeyError => e e.matchee end # => {:error=>true} ``` I would find it very helpful for this functionality to be available for the standard `NoMatchingPatternError` without hash key matching proposed: ```ruby begin [:error, "message"] => [:ok, value] rescue NoMatchingPatternError => e e.matchee end # => [:error, "message"] ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111523] [Ruby master Bug#19287] Let DelegateClass respect the original method's arity in case of 0
by matsuda (Akira Matsuda) 29 Dec '22

29 Dec '22

Issue #19287 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19287: Let DelegateClass respect the original method's arity in case of 0 https://bugs.ruby-lang.org/issues/19287 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2022-12-28T16:43:05Z master cada537040) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- As reported in #19165, method delegation with *, **, and ... adds some overhead for a method that takes no argument. And current implementation of delegations in forwardable and delegate basically define all methods to take splat parameters. But, with regard to DelegateClass, we can investigate the arity of the target methods in the initializer, then we can define the delegation method not to take the splat for zero arity methods. A benchmark on trunk today results in 37% runtime performance improvement on a such method. Benchmark: Warming up -------------------------------------- old 551.697k i/100ms new 721.906k i/100ms Calculating ------------------------------------- old 6.511M (± 0.8%) i/s - 33.102M in 5.084530s new 8.925M (± 1.0%) i/s - 44.758M in 5.015619s Comparison: new: 8924652.2 i/s old: 6510691.1 i/s - 1.37x (± 0.00) slower Patch: https://github.com/ruby/ruby/pull/7045 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:111518] [Ruby master Bug#15072] thread.c:4356:5: error: implicit declaration of function ‘ubf_list_atfork’
by normalperson (Eric Wong) 29 Dec '22

29 Dec '22

Issue #15072 has been updated by normalperson (Eric Wong). Status changed from Open to Closed Fixed in #15130 ---------------------------------------- Bug #15072: thread.c:4356:5: error: implicit declaration of function ‘ubf_list_atfork’ https://bugs.ruby-lang.org/issues/15072#change-100886 * Author: duerst (Martin Dürst) * Status: Closed * Priority: Normal * Assignee: normalperson (Eric Wong) * ruby -v: ruby 2.6.0dev (2018-08-01 trunk 64156) [x86_64-cygwin] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- When compiling on cygwin, I get the following error: ``` compiling thread.c thread.c: In function ‘rb_thread_atfork_internal’: thread.c:4356:5: error: implicit declaration of function ‘ubf_list_atfork’ [-Werror=implicit-function-declaration] ubf_list_atfork(); ^~~~~~~~~~~~~~~ ``` The `ubf_list_atfork` function was introduced by issue #15013 in r64485. The problem is that the function is defined *as static* in thread_pthread.c, but is used in thread.c. Not being an expert on threads, I thought that maybe `ubf_list_atfork` is a function that's available on some OSes, but that can't be the case. I only got empty results when searching for it. There's also a macro for `ubf_list_atfork` in thread_win32.c, but that doesn't seem to be related here. [below it says my Ruby version is trunk 64156, but I'm compiling on HEAD.] -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111485] [Ruby master Bug#19279] Allow `Coverage.supported?` to recognize oneshot lines mode
by kevin-j-m (Kevin Murphy) 29 Dec '22

29 Dec '22

Issue #19279 has been reported by kevin-j-m (Kevin Murphy). ---------------------------------------- Bug #19279: Allow `Coverage.supported?` to recognize oneshot lines mode https://bugs.ruby-lang.org/issues/19279 * Author: kevin-j-m (Kevin Murphy) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Currently in Ruby 3.2.0, Coverage's new `supported?` method (introduced in https://bugs.ruby-lang.org/issues/19026) does not recognize support for oneshot lines. Given that it is an available mode of coverage, I'm proposing that `Coverage.supported?` report that oneshot lines is supported. Current behavior: ``` bash ~|⇒ ruby -v ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin22] ~|⇒ irb irb(main):001:0> require "coverage" => true irb(main):002:0> Coverage.supported?(:lines) => true irb(main):003:0> Coverage.supported?(:oneshot_lines) => false ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:111508] Data support for versions before 3.2.0
by Eustáquio Rangel 29 Dec '22

29 Dec '22

I was wondering that every piece of code (gems, etc) that use the new Data object from now on will demand a mandatory upgrade to >= 3.2.0. It's a good thing upgrade the language versions, but often we can't do it for many reasons and would love to use the new code (updated or new gems) on our projects current versions. On the original Data PR I saw one of the reasons asking Data be a language feature and not a gem ("nobody will even try to use a gem for representing it with, unless the framework/library used already provides one"), I agree with that, but I'm curious if i there is any plan to support older language versions, like releasing a gem to mimic main Data features into older language versions and not force a mandatory upgrade to >= 3.2.0. I searched on rubygems but didn't find one like that. Btw, looks like what we had before with Fibers and Ractors, but seems to me Data will have an easier and faster adoption. Thanks.

2 2

[ruby-core:111491] [Ruby master Bug#19280] Wrong error message about arity of Data::define.new
by kyanagi (Kouhei Yanagita) 29 Dec '22

29 Dec '22

Issue #19280 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19280: Wrong error message about arity of Data::define.new https://bugs.ruby-lang.org/issues/19280 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2022-12-28T16:43:05Z master cada537040) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ ~/work/r/bin/ruby -e 'Data.define(:a, :b).new(1, 2, 3)' -e:1:in `new': wrong number of arguments (given 3, expected 0..2) (ArgumentError) Data.define(:a, :b).new(1, 2, 3) ^^^^^^^ from -e:1:in `<main>' ``` On this message, "expected 2" is appropriate because fewer arguments are not allowed. ``` $ ~/work/r/bin/ruby -e 'Data.define(:a, :b).new(1)' -e:1:in `initialize': missing keyword: :b (ArgumentError) Data.define(:a, :b).new(1) ^ from -e:1:in `new' from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111465] [Ruby master Bug#19273] [Regexp] regexp does not does not match expected
by taichi730 (Taichi Ishitani) 29 Dec '22

29 Dec '22

Issue #19273 has been reported by taichi730 (Taichi Ishitani). ---------------------------------------- Bug #19273: [Regexp] regexp does not does not match expected https://bugs.ruby-lang.org/issues/19273 * Author: taichi730 (Taichi Ishitani) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- A regexp pattern does not match expected with Ruby 3.2. Ruby 3.2 ``` ruby pattern = /(?-mix:(?i-mx:[+-]?0b[01](?:_?[01])*)|(?-mix:[+-]?(?:[1-9]_?(?:\d_?)*)?\d)|(?i-mx:[+-]?0x\h(?:_?\h)*))(?::(?-mix:(?i-mx:[+-]?0b[01](?:_?[01])*)|(?-mix:[+-]?(?:[1-9]_?(?:\d_?)*)?\d)|(?i-mx:[+-]?0x\h(?:_?\h)*))){0,3}/ "10:0:0".mathc(pattern) #=> #<MatchData "10"> "0:0:0".match(pattern) #=> #<MatchData "0:0:0"> ``` String "10.0.0" is only partially matched but not all of it. Ruby 3.1.0: ```ruby pattern = /(?-mix:(?i-mx:[+-]?0b[01](?:_?[01])*)|(?-mix:[+-]?(?:[1-9]_?(?:\d_?)*)?\d)|(?i-mx:[+-]?0x\h(?:_?\h)*))(?::(?-mix:(?i-mx:[+-]?0b[01](?:_?[01])*)|(?-mix:[+-]?(?:[1-9]_?(?:\d_?)*)?\d)|(?i-mx:[+-]?0x\h(?:_?\h)*))){0,3}/ "10:0:0".match(pattern) #=> #<MatchData "10:0:0"> "0:0:0".match(pattern) #=> #<MatchData "0:0:0"> ``` Both strings matches with the regexp wholy. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:111438] [Ruby master Bug#19263] MJIT fails to compile multiple values in a single case in Ruby 3.2.0
by k0kubun (Takashi Kokubun) 29 Dec '22

29 Dec '22

Issue #19263 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19263: MJIT fails to compile multiple values in a single case in Ruby 3.2.0 https://bugs.ruby-lang.org/issues/19263 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- ``` $ cat test.rb def test(a) case a when true, false a end end test(true) test(true) $ ruby --mjit-verbose=1 --mjit-wait --mjit-call-threshold=2 test.rb /tmp/_ruby_mjit_p237606u1.c: In function ‘_mjit0’: /tmp/_ruby_mjit_p237606u1.c:58:7: error: duplicate case value 58 | case 19: | ^~~~ compilation terminated due to -Wfatal-errors. Successful MJIT finish ``` I'd like to fix this in master and ask the branch maintainer to backport this to 3.2.1. -- https://bugs.ruby-lang.org/

2 2