August 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123068] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by Eregon (Benoit Daloze) 25 Aug '25

25 Aug '25

Issue #12282 has been updated by Eregon (Benoit Daloze). Agreed `deep_fetch` is good. Also wanted to mention `dig_fetch` from https://bugs.ruby-lang.org/issues/14602#note-16, there is even [a blog post about it](https://shopify.engineering/dig-fetch-truffleruby) so I think that illustrates it's a common name for this functionality. What this issue wants is `dig` with `fetch` semantics instead of `[]` semantics, hence `dig_fetch`. `fetch_path` doesn't seem ideal to me because this method would also be used e.g. with arrays and `object.fetch_path(:foo, 2, :baz)` doesn't really sounds like a "path". Similarly, `deep_fetch` looks nice but doesn't make the relation to `dig` as clear as `dig_fetch`. It could be `obj.dig(:foo, 2, :baz, exception: true)` I guess, but that's very verbose. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114381 * 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:123067] (7) incoming messages on hold
by administrator 25 Aug '25

25 Aug '25

1 0

[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:123062] [Ruby Bug#21551] Ractor isolation error points to the wrong place
by tenderlovemaking (Aaron Patterson) 23 Aug '25

23 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: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: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

[ruby-core:123045] [Ruby Feature#14718] Use jemalloc by default?
by mame (Yusuke Endoh) 22 Aug '25

22 Aug '25

Issue #14718 has been updated by mame (Yusuke Endoh). Status changed from Open to Rejected jemalloc development has been discontinued. https://jasone.github.io/2025/06/12/jemalloc-postmortem/ ---------------------------------------- Feature #14718: Use jemalloc by default? https://bugs.ruby-lang.org/issues/14718#change-114362 * Author: mperham (Mike Perham) * Status: Rejected ---------------------------------------- I know Sam opened #9113 4 years ago to suggest this but I'm revisiting the topic to see if there's any movement here for Ruby 2.6 or 2.7. I supply a major piece of Ruby infrastructure (Sidekiq) and I keep hearing over and over how Ruby is terrible with memory, a huge memory hog with their Rails apps. My users switch to jemalloc and a miracle occurs: their memory usage drops massively. Some data points: https://twitter.com/brandonhilkert/status/987400365627801601 https://twitter.com/d_jones/status/989866391787335680 https://github.com/mperham/sidekiq/issues/3824#issuecomment-383072469 Redis moved to jemalloc many years ago and it solved all of their memory issues too. Their conclusion: the glibc allocator "sucks really really hard". http://oldblog.antirez.com/post/everything-about-redis-24.html This is a real pain point for the entire Rails community and would improve Ruby's reputation immensely if we can solve this problem. ---Files-------------------------------- glibc_arena_2.png (7.23 KB) jemalloc.png (21.1 KB) glibc-arena-2.log (60.3 KB) glibc.log (62.3 KB) jemalloc-3-5.log (58.5 KB) glibc.png (9.03 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120873] [Ruby master Bug#21111] RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs
by stanhu (Stan Hu) 22 Aug '25

22 Aug '25

Issue #21111 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #21111: RbConfig::CONFIG['CXX'] quietly set to "false" when Ruby cannot build C++ programs https://bugs.ruby-lang.org/issues/21111 * Author: stanhu (Stan Hu) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As reported in https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/2222 and https://trac.macports.org/ticket/70750, we've had numerous macOS users experience problems with compiling Ruby C++ extensions after upgrading to XCode 16. Users have had to fix their XCode setups and reinstall Ruby when this happens. It turns out that when Ruby can't build a CXX program, it essentially sets CXX to the `false` string. From https://github.com/ruby/ruby/blob/7317f96727725ca37ddb06011918deb841de371c/…: ``` AS_IF([test -n "${rb_there_is_in_fact_no_gplusplus_but_autoconf_is_cheating_us}"], [ AC_MSG_NOTICE([Test skipped due to lack of a C++ compiler.]) ], [test -n "${CXX}"], [ RUBY_WERROR_FLAG([ AC_MSG_CHECKING([whether CXXFLAGS is valid]) AC_LANG_PUSH(C++) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[@%:@include <cstdio>]], [[]])], [AC_MSG_RESULT(yes)],[ AC_MSG_RESULT(no) # The message mentions CXXFLAGS, but CPPFLAGS might also affects. AC_MSG_WARN([something wrong with CXXFLAGS="$CXXFLAGS"]) CXX=false ``` This causes C++ extensions, such as `unf_ext`, to fail while attempting to compile native extensions. There are no error messages because `false` is executed, so users only see: ``` Installing unf_ext 0.0.8.2 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext /Users/kerrizor/.rvm/rubies/ruby-3.3.7/bin/ruby extconf.rb checking for -lstdc++... yes creating Makefile current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 clean current directory: /Users/myuser/.rvm/gems/ruby-3.3.7/gems/unf_ext-0.0.8.2/ext/unf_ext make DESTDIR\= sitearchdir\=./.gem.20250203-69237-u2oi17 sitelibdir\=./.gem.20250203-69237-u2oi17 compiling unf.cc make: *** [unf.o] Error 1 ``` `unf_ext` only checks whether `RbConfig::CONFIG['CXX']` is defined, not that it is `false`: https://github.com/knu/ruby-unf_ext/blob/c72a36d0a5ea9fe3950611b0f289fc68a2…. Questions: 1. Should CXX just be set to `nil`? Or should all C++ extensions be expected to check for `false`? The latter seems surprising to me. 2. Should there be a way to fail the Ruby build if a valid C++ compiler is not found? -- https://bugs.ruby-lang.org/

7 9