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

[ruby-core:123066] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by Dan0042 (Daniel DeLorme) 25 Aug '25

25 Aug '25

Issue #12282 has been updated by Dan0042 (Daniel DeLorme). k0kubun (Takashi Kokubun) wrote in #note-7: > How about this name? > > ~~~ > places.deep_fetch(:countries, :canada, :ontario) > ~~~ Best suggestion I've seen so far. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114380 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123064] Zoom In: Your Meeting Link is Here
by Zoom 25 Aug '25

25 Aug '25

2 1

[ruby-core:123063] [Ruby Feature#21552] allow String.strip and similar to take a parameter similar to String.delete
by MSP-Greg (Greg L) 24 Aug '25

24 Aug '25

Issue #21552 has been reported by MSP-Greg (Greg L). ---------------------------------------- Feature #21552: allow String.strip and similar to take a parameter similar to String.delete https://bugs.ruby-lang.org/issues/21552 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Regrading `String.strip` (and `lstrip`, `rstrip`, and `!` versions) Some text data representations differentiate between what one might call vertical and horizontal white space, and the 'strip' methods currently strip both. It would be helpful if they had an optional parameter similar to `String.delete` with a one multi-character selector, so one could do: ```ruby t = str.strip " \t" ``` One can use a regex for this, but this much simpler. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123062] [Ruby Bug#21551] Ractor isolation error points to the wrong place
by tenderlovemaking (Aaron Patterson) 24 Aug '25

24 Aug '25

Issue #21551 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21551: Ractor isolation error points to the wrong place https://bugs.ruby-lang.org/issues/21551 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following code has a bug in it. The block passed to `Ractor.new` references the outer `channel` variable, so it can't be isolated. The problem is that I forgot to add `|channel|` to the block: ```ruby channel = Ractor::Port.new coordinator = Ractor.new(channel) do inbound_work = Ractor::Port.new channel << inbound_work end ``` However, the exception this raises is strange: ``` > ruby thing.rb thing.rb:3: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. thing.rb:3:in 'Ractor.new': can not isolate a Proc because it accesses outer variables (channel). (ArgumentError) coordinator = Ractor.new(channel) do ^^^^^^^ from thing.rb:3:in '<main>' ``` I would expect the `channel` local inside the block to be underlined instead of the parameter passed to `Ractor.new`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112552] [Ruby master Bug#19461] Time.local performance tanks in forked process (on macOS only?)
by ioquatix (Samuel Williams) 23 Aug '25

23 Aug '25

Issue #19461 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19461: Time.local performance tanks in forked process (on macOS only?) https://bugs.ruby-lang.org/issues/19461 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following program demonstrates a performance regression in forked child processes when invoking `Time.local`: ```ruby require 'benchmark' require 'time' def sir_local_alot result = Benchmark.measure do 10_000.times do tm = ::Time.local(2023) end end $stderr.puts result end sir_local_alot pid = fork do sir_local_alot end Process.wait(pid) ``` On Linux the performance is similar, but on macOS, the performance is over 100x worse on my M1 laptop. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:122615] [Ruby Misc#21458] Test 'make install'?
by MSP-Greg (Greg L) 23 Aug '25

23 Aug '25

Issue #21458 has been reported by MSP-Greg (Greg L). ---------------------------------------- Misc #21458: Test 'make install'? https://bugs.ruby-lang.org/issues/21458 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Can `make install` be tested? Two items come to mind: 1. Test that all gems can be required? 2. Check that all gem binstubs are installed and work. Some of the above are being done in ruby-loco and https://github.com/ruby/ruby-dev-builder/blob/master/cli_test.rb. Both of these are cron jobs, they don't run on every commit. A long time ago, I think this was discussed, but it was back when CI was much more limited. It was also mixed in with the idea of running tests from the 'install' folder, rather than the 'build' folder. Maybe a few jobs could be added to check `make install` on the three main OS's (Ubuntu, macOS, Windows)? Lastly, with minimal changes, tests can be run from the install folder, which is what ruby-loco has done for years. Recently, two tests that I believe are skipped here started failing: ``` TestGemRequire#test_realworld_default_gem Line: 471 Expected "" to not be empty. TestGemRequire#test_realworld_upgraded_default_gem Line: 492 <"999.99.9"> expected but was <"/ruby/tmp/test_rubygems_20250628-8920-sifyoe/test_realworld_upgraded_default_gem.rb:3:in '<main>': undefined method 'version' for nil (NoMethodError)">. ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:122964] [Ruby Feature#21543] Point ArgumentError to the call site
by mame (Yusuke Endoh) 22 Aug '25

22 Aug '25

Issue #21543 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21543: Point ArgumentError to the call site https://bugs.ruby-lang.org/issues/21543 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- Consider this buggy code: ```ruby def foo(x, y) end foo(1) ``` The resulting error is: ``` $ ruby test.rb test.rb:1:in `foo': wrong number of arguments (given 1, expected 2) (ArgumentError) from test.rb:4:in `<main>' ``` I want this to be: ``` $ ruby test.rb test.rb:4:in `<main>': wrong number of arguments (given 1, expected 2) (ArgumentError) for `foo' at test.rb:1 ``` ## Problem In my experience, the code that needs fixing is almost always the caller, not the callee. In the above case, one would change `foo(1)` to something like `foo(1, 2)`. My typical debugging workflow starts with opening the first location shown in the backtrace. This takes me to the `def` line of the method. However, I can barely remember a single time I've ever had to fix the method definition itself in this scenario. I often find myself sighing, going back to the backtrace, finding the second location (the caller), and opening that file instead. I think this inconvenience is a significant loss of productivity. I understand that the current behavior is designed because developers need to check the callee (the method definition) to see what arguments are required for the fix. However, I believe the primary location in a backtrace should point to the code that is most likely to need modification. There are cases where developers can fix the call site without re-checking the method definition. Even when they do need to check the callee to recall the expected arguments, it feels more natural to first understand "what arguments am I currently passing?" at the call site before asking "what arguments should I be passing?". This workflow makes it easier to spot the mistake. ## Proposal I propose that the backtrace for an ArgumentError should point to the caller's location (the call site) as shown in the above. The location of the callee (the method definition) could instead be included within the error message itself. For a longer backtrace, the output would look like this: ```ruby class TestClass def foo(x, y) end def bar foo(1) end def main bar end end TestClass.new.main ``` ``` $ ruby test.rb test.rb:6:in 'TestClass#bar': wrong number of arguments (given 1, expected 2) (ArgumentError) for TestClass#foo at test.rb:2 from test.rb:10:in 'TestClass#main' from test.rb:14:in '<main>' ``` What do you think of this proposal? I have attached a proof-of-concept patch, though it will require more work before it is merge-ready. ```diff diff --git a/vm_args.c b/vm_args.c index 44be6f54c5..986cb3e4c1 100644 --- a/vm_args.c +++ b/vm_args.c @@ -980,17 +980,7 @@ raise_argument_error(rb_execution_context_t *ec, const rb_iseq_t *iseq, const rb { VALUE at; - if (iseq) { - vm_push_frame(ec, iseq, VM_FRAME_MAGIC_DUMMY | VM_ENV_FLAG_LOCAL, Qnil /* self */, - VM_BLOCK_HANDLER_NONE /* specval*/, (VALUE) cme /* me or cref */, - ISEQ_BODY(iseq)->iseq_encoded, - ec->cfp->sp, 0, 0 /* stack_max */); - at = rb_ec_backtrace_object(ec); - rb_vm_pop_frame(ec); - } - else { - at = rb_ec_backtrace_object(ec); - } + at = rb_ec_backtrace_object(ec); rb_ivar_set(exc, idBt_locations, at); rb_exc_set_backtrace(exc, at); @@ -1000,7 +990,15 @@ raise_argument_error(rb_execution_context_t *ec, const rb_iseq_t *iseq, const rb static void argument_arity_error(rb_execution_context_t *ec, const rb_iseq_t *iseq, const rb_callable_method_entry_t *cme, const int miss_argc, const int min_argc, const int max_argc) { - VALUE exc = rb_arity_error_new(miss_argc, min_argc, max_argc); + VALUE rb_gen_method_name(VALUE owner, VALUE name); + VALUE mname = rb_gen_method_name(cme->owner, rb_id2str(cme->def->original_id)); + const rb_iseq_t *miseq = cme->def->body.iseq.iseqptr; + VALUE file = Qfalse, lineno = 0; + if (miseq) { + file = rb_iseq_path(miseq); + lineno = rb_iseq_first_lineno(miseq); + } + VALUE exc = rb_arity_error_new(miss_argc, min_argc, max_argc, mname, file, lineno); if (ISEQ_BODY(iseq)->param.flags.has_kw) { const struct rb_iseq_param_keyword *const kw = ISEQ_BODY(iseq)->param.keyword; const ID *keywords = kw->table; diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 3aca1bc24f..a5ad2f0562 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -484,7 +484,7 @@ rb_vm_push_frame_fname(rb_execution_context_t *ec, VALUE fname) /* method dispatch */ static inline VALUE -rb_arity_error_new(int argc, int min, int max) +rb_arity_error_new(int argc, int min, int max, VALUE mname, VALUE file, VALUE lineno) { VALUE err_mess = rb_sprintf("wrong number of arguments (given %d, expected %d", argc, min); if (min == max) { @@ -497,13 +497,19 @@ rb_arity_error_new(int argc, int min, int max) rb_str_catf(err_mess, "..%d", max); } rb_str_cat_cstr(err_mess, ")"); + if (mname) { + rb_str_catf(err_mess, "\nfor %"PRIsVALUE, mname); + if (file) { + rb_str_catf(err_mess, " at %"PRIsVALUE":%"PRIsVALUE, file, lineno); + } + } return rb_exc_new3(rb_eArgError, err_mess); } void rb_error_arity(int argc, int min, int max) { - rb_exc_raise(rb_arity_error_new(argc, min, max)); + rb_exc_raise(rb_arity_error_new(argc, min, max, Qfalse, Qfalse, INT2FIX(0))); } /* lvar */ ``` ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122842] [Ruby Feature#21518] Statistical helpers to `Enumerable`
by Amitleshed (Amit Leshed) 22 Aug '25

22 Aug '25

Issue #21518 has been reported by Amitleshed (Amit Leshed). ---------------------------------------- Feature #21518: Statistical helpers to `Enumerable` https://bugs.ruby-lang.org/issues/21518 * Author: Amitleshed (Amit Leshed) * Status: Open ---------------------------------------- **Summary** I'd like to add two statistical helpers to `Enumerable`: - `Enumerable#average` (arithmetic mean) - `Enumerable#median` Both are small, well-defined operations that many Rubyists re-implement in apps and gems. Providing them in core avoids repeated, ad-hoc code and aligns with `Enumerable#sum`, which Ruby already ships. **Motivation** - These are among the most common “roll-your-own” helpers for arrays/ranges of numbers. - They are conceptually simple, universally useful beyond web/Rails. - Similar to `sum`, they’re primitives for quick data analysis, ETL scripts, CLI tooling, etc. - Including them encourages consistent semantics (what to do with empty sets, mixed numerics, etc.). ## Proposed API & Semantics ```ruby Enumerable#average -> Float or nil Enumerable#median -> Numeric or nil ``` ```ruby [1, 2, 3, 4].average # => 2.5 (1..4).average # => 2.5 [].average # => nil [1, 3, 2].median # => 2 [1, 2, 3, 10].median # => 2.5 (1..6).median # => 3.5 [].median # => nil ``` Ruby implementation ```ruby module Enumerable def average count = 0 total = 0.0 each do |x| raise TypeError, "non-numeric value for average" unless x.is_a?(Numeric) total += x count += 1 end count.zero? ? nil : total / count end def median arr = to_a return nil if arr.empty? arr.each { |x| raise TypeError, "non-numeric value for median" unless x.is_a?(Numeric) } arr.sort! mid = arr.length / 2 arr.length.odd? ? arr[mid] : (arr[mid - 1] + arr[mid]) / 2.0 end end ``` **Upon approval I'm more than willing to implement spec and code in C.** -- https://bugs.ruby-lang.org/

8 11

[ruby-core:122917] [Ruby Feature#21532] Define most of Pathname in Ruby code
by Eregon (Benoit Daloze) 22 Aug '25

22 Aug '25

Issue #21532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21532: Define most of Pathname in Ruby code https://bugs.ruby-lang.org/issues/21532 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: Eregon (Benoit Daloze) ---------------------------------------- There was discussion in #17473 and before to define most of Pathname in Ruby code and not in the C extension. I have made a PR to achieve that: https://github.com/ruby/pathname/pull/57 I would like to merge it soon to avoid conflicts. Once upon a time, Pathname was pure-Ruby: https://github.com/ruby/ruby/blob/95bc02237635d3fe42532bfe53038257575cee75/… This PR goes back to that, and reuses that original Ruby code, but keeps the C extension implementation of `<=>` and `sub` as those two are significantly faster. The other Pathname methods are actually faster in Ruby than in C, because all these methods just do `rb_funcall()` and `rb_ivar_get()` and those in C code have no inline cache, but the corresponding method calls and `@path` have inline caches in Ruby code. https://railsatscale.com/2023-08-29-ruby-outperforms-c/ is an explanation of that. Therefore having Pathname defined in Ruby seems a clear win for many reasons: * Much clearer implementation, so easier to read what the code does * Easier to maintain * Safer (no risk of accessing out of bounds memory or e.g. passing the wrong number of arguments to `rb_funcall`) * Actually faster, because of these inline caches, see numbers at the end of https://github.com/ruby/pathname/pull/57#issue-3234862768 * Better for JITs as they can optimize this, notably `...` vs the C extension being a blackbox * Works on JRuby (which does not support C extensions) * Faster on TruffleRuby (where a C extension for this is inefficient as it causes needless Ruby->C->Ruby transitions) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122925] [Ruby Feature#21533] Introduce `Time#am?` and `Time#pm?`
by matheusrich (Matheus Richard) 22 Aug '25

22 Aug '25

Issue #21533 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21533: Introduce `Time#am?` and `Time#pm?` https://bugs.ruby-lang.org/issues/21533 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- This proposal adds two predicate methods to `Time`: ```ruby Time.utc(2000, 1, 1, 11, 59, 59).am? # => true Time.utc(2000, 1, 1, 12, 0, 0).pm? # => true ``` * `am?` returns true when the hour is less than 12. * `pm?` returns true when the hour is 12 or greater. These methods provide a clear and expressive way to branch logic based on time of day. For example: ```ruby def reminder_deferral_options options = [] options << ["Later today", "later_today"] if Time.now.am? options << ["Tomorrow morning", "tomorrow_morning"] options << ["Pick a date/time…", "custom"] options end ``` This is a common pattern in applications involving reminders and scheduling. The method names are intuitive, and the semantics are well understood. The implementation is in [this Pull Request](https://github.com/ruby/ruby/pull/14133). -- https://bugs.ruby-lang.org/

5 9