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

[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

[ruby-core:123036] [Ruby Feature#17316] On memoization
by Dan0042 (Daniel DeLorme) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). The single-character syntax itself isn't a problem if limited to instance variables. `foo ?=` is already valid and shouldn't change, but `@foo ?=` isn't currently valid, so it could serve as "assign if ivar undefined." The problem is consistency. All operator-equals decompose uniformly (`a += b` -> `a = a + b`) but `?=` and its variations (like `@||=`) would be very different. What should happen with cases like: ```ruby foo ?= expr foo[key] ?= expr foo.bar ?= expr ``` If that's a syntax error, it's inconsistent with other operators like `+=` or `||=`. If it means "assign if not nil", it's inconsistent with `@foo ?= expr` as "assign if undefined". And if `@foo ?= expr` is changed to mean "assign if not nil" then we're back to the nil coalescing operator which is a different topic (#13820) An operator for "assign if undefined" is appealing, but the implications don't work out cleanly. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114347 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117216] [Ruby master Bug#20346] FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take
by forthoney (Seong-Heon Jung) 21 Aug '25

21 Aug '25

Issue #20346 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take https://bugs.ruby-lang.org/issues/20346 * Author: forthoney (Seong-Heon Jung) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior ```ruby require "async" class RactorWrapper def initialize @ractor = Ractor.new do Ractor.recv # Ractor doesn't start until explicitly told to # Do some calculations fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) } fib.call(20) end end def take_async @ractor.send(nil) Thread.new { @ractor.take }.join.value end end Async do |task| 10000.times do |i| task.async do RactorWrapper.new.take_async puts i end end end ``` The above code deadlocks, and when we leave a debugging print statement inside of `Async`'s scheduler's `block` and `unblock` method, we can confirm that we only call `Scheduler.block`, and never `Scheduler.unblock` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112206] [Ruby master Bug#19407] 2 threads taking from current ractor will hang forever
by luke-gru (Luke Gruber) 21 Aug '25

21 Aug '25

Issue #19407 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19407: 2 threads taking from current ractor will hang forever https://bugs.ruby-lang.org/issues/19407 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the current implementation of Ractors, it's possible to `take` from the current ractor. This could be useful when co-ordinating threads: ```ruby t = Thread.new do obj = Ractor.current.take p obj # do some work with obj end t0 = Thread.new do obj = Ractor.current.take p obj # do some work with obj end Ractor.yield :go ``` However it hangs forever: ```ruby t = Thread.new do obj = Ractor.current.take p obj end t0 = Thread.new do obj = Ractor.current.take p obj end sleep 0.5 ``` Should "self-take" be disabled, or was it designed to allow it but this is just a bug? -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123030] [Ruby Feature#17316] On memoization
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matz (Yukihiro Matsumoto). Currently, `?=` means "a single character =". We don't want to break current available syntax, unless absolutely necessary. Matz. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114340 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123028] [Ruby Feature#17316] On memoization
by matheusrich (Matheus Richard) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matheusrich (Matheus Richard). @matz I propose `?=` as the uninitialized assignment operator: ```rb @foo ?= some_heavy_calculation(...) ``` ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114338 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122987] [Ruby Bug#21547] SEGV after 2083fa commit
by watson1978 (Shizuo Fujita) 21 Aug '25

21 Aug '25

Issue #21547 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Bug #21547: SEGV after 2083fa commit https://bugs.ruby-lang.org/issues/21547 * Author: watson1978 (Shizuo Fujita) * Status: Open * Target version: 3.5 * ruby -v: ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am maintaining [Fluentd](https://github.com/fluent/fluentd). When I run Fluentd's unit tests after [2083fa](https://github.com/ruby/ruby/commit/2083fa89fc29005035c1a098185c4b7… commit, Ruby causes SEGV. ``` $ git clone --depth 1 https://github.com/fluent/fluentd.git $ cd fluentd $ bundle install $ ruby -v ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] $ bundle exec rake test TESTOPTS=-v TEST=test/plugin/test_in_exec.rb Source locally installed gems is ignoring #<Bundler::StubSpecification name=json version=2.13.2 platform=ruby> because it is missing extensions /home/watson/.rbenv/versions/3.5-debug/bin/ruby -w -I"lib:test" -Eascii-8bit:ascii-8bit /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/rake-13.3.0/lib/rake/rake_test_loader.rb "test/plugin/test_in_exec.rb" -v Source locally installed gems is ignoring #<Bundler::StubSpecification name=json version=2.13.2 platform=ruby> because it is missing extensions /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:240: warning: assigned but unused variable - tag /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:240: warning: assigned but unused variable - time /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:246: warning: assigned but unused variable - d /home/watson/tmp/fluentd/lib/fluent/plugin_helper.rb:46: warning: method redefined; discarding old inherited /home/watson/tmp/fluentd/lib/fluent/plugin_helper.rb:46: warning: previous definition of inherited was here Loaded suite /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/rake-13.3.0/lib/rake/rake_test_loader Started ExecInputTest: test: emit error message with read_with_stderr: .: (0.229405) test: emit with formats[default]: .: (0.908338) test: emit with formats[json]: .: (0.809623) test: emit with formats[msgpack]: /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:105: [BUG] Segmentation fault at 0x0000000000000024 ruby 3.5.0dev (2025-08-13T17:54:56Z master 2083fa89fc) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0054 p:---- s:0316 e:000315 CFUNC :detach c:0053 p:---- s:0313 e:000312 CFUNC :detach c:0052 p:0012 s:0309 e:000308 BLOCK /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:105 [FINISH] c:0051 p:---- s:0304 e:000303 CFUNC :reverse_each c:0050 p:0006 s:0300 e:000299 BLOCK /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:102 [FINISH] c:0049 p:---- s:0297 e:000296 CFUNC :synchronize c:0048 p:0006 s:0293 e:000292 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/event_loop.rb:101 c:0047 p:0014 s:0289 e:000288 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/child_process.rb:149 c:0046 p:0011 s:0283 e:000282 METHOD /home/watson/tmp/fluentd/lib/fluent/plugin_helper/parser.rb:126 c:0045 p:0016 s:0279 e:000278 BLOCK /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:161 c:0044 p:0005 s:0276 e:000275 BLOCK /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:150 c:0043 p:0064 s:0270 E:001588 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:161 c:0042 p:0123 s:0263 E:0022e0 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base.rb:100 c:0041 p:0045 s:0250 E:0003a8 METHOD /home/watson/tmp/fluentd/lib/fluent/test/driver/base_owner.rb:130 c:0040 p:0028 s:0239 e:000238 BLOCK /home/watson/tmp/fluentd/test/plugin/test_in_exec.rb:272 c:0039 p:0131 s:0229 e:000228 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:911 c:0038 p:0003 s:0221 e:000220 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:601 c:0037 p:0024 s:0218 e:000217 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0036 p:0024 s:0214 e:000213 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0035 p:0024 s:0210 e:000209 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:276 c:0034 p:0052 s:0206 e:000205 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:257 c:0033 p:0009 s:0197 e:000196 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/fixture.rb:292 c:0032 p:0004 s:0192 E:000318 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:599 [FINISH] c:0031 p:---- s:0188 e:000187 CFUNC :catch c:0030 p:0046 s:0184 E:001d78 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testcase.rb:598 c:0029 p:0045 s:0175 E:001730 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:96 c:0028 p:0013 s:0163 e:000162 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:62 [FINISH] c:0027 p:---- s:0159 e:000158 CFUNC :each c:0026 p:0009 s:0155 e:000154 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:61 c:0025 p:0037 s:0147 e:000146 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:39 c:0024 p:0030 s:0139 E:000ce8 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testsuite.rb:56 c:0023 p:0045 s:0130 E:000090 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:96 c:0022 p:0013 s:0118 e:000117 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:62 [FINISH] c:0021 p:---- s:0114 e:000113 CFUNC :each c:0020 p:0009 s:0110 e:000109 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:61 c:0019 p:0037 s:0102 e:000101 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:39 c:0018 p:0030 s:0094 E:001318 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/testsuite.rb:56 c:0017 p:0028 s:0085 E:0015a0 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:72 c:0016 p:0041 s:0079 e:000078 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:49 [FINISH] c:0015 p:---- s:0075 e:000074 CFUNC :catch c:0014 p:0004 s:0071 e:000070 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:44 c:0013 p:0008 s:0067 e:000066 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/test-suite-runner.rb:19 c:0012 p:0006 s:0063 e:000062 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:43 c:0011 p:0038 s:0060 E:002668 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:107 c:0010 p:0033 s:0051 E:000d78 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnermediator.rb:42 c:0009 p:0006 s:0044 e:000043 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunner.rb:40 c:0008 p:0019 s:0040 e:000039 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunner.rb:25 c:0007 p:0015 s:0036 e:000035 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/ui/testrunnerutilities.rb:24 c:0006 p:0010 s:0030 e:000029 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:499 c:0005 p:0019 s:0027 e:000026 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:564 c:0004 p:0182 s:0022 e:000021 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:498 c:0003 p:0057 s:0016 e:000015 METHOD /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit/autorunner.rb:68 c:0002 p:0017 s:0007 e:000005 BLOCK /home/watson/.rbenv/versions/3.5-debug/lib/ruby/gems/3.5.0+3/gems/test-unit-3.7.0/lib/test/unit.rb:518 [FINISH] c:0001 p:0000 s:0003 E:000410 DUMMY [FINISH] ...(snip)... ``` -- https://bugs.ruby-lang.org/

3 9

[ruby-core:123013] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #12282 has been updated by matz (Yukihiro Matsumoto). `fetch_path` is much better than `dig!` since this bang method is against our naming convention (if we have x and x!, a method with `!` (bang) should be more dangerous). At the same time, `_path` usually means file paths in Ruby, and possibly cause confusion, although **I** understand `path` here is totally valid. Matz. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114317 * 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:123006] [Ruby Feature#17316] On memoization
by matz (Yukihiro Matsumoto) 21 Aug '25

21 Aug '25

Issue #17316 has been updated by matz (Yukihiro Matsumoto). I understand the motivation, but the proposed "@||=" is unacceptable. Other suggestions were made, but I don't think any of them adequately express the intent. If there are no good operator name suggestions in the future, it would be better to explicitly use `defined?`. Matz. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114308 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- I have seen so many attempts to memoize a value in the form: ```ruby @foo ||= some_heavy_calculation(...) ``` improperly, i.e., even when the value can potentially be falsy. This practice is wide spread, and since in most cases memoization is about efficiency and it would not be critical if it does not work correctly, people do not seem to care so much about correcting the wrong usage. In such case, the correct form would be: ```ruby unless instance_variable_defined?(:@foo) @foo = some_heavy_calculation(...) end ``` but this looks too long, and perhaps that is keeping people away from using it. What about allowing `Kernel#instance_variable_set` to take a block instead of the second argument, in which case the assignment should be done only when the instance variable is not defined? ```ruby instance_variable_set(:@foo){some_heavy_calculation(...)} ``` Or, if that does not look right or seems to depart from the original usage of `instance_variable_set`, then what about having a new method? ```ruby memoize(:foo){some_heavy_calculation(...)} ``` -- https://bugs.ruby-lang.org/

1 0