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

[ruby-core:122724] [Ruby Misc#21508] DevMeeting-2025-08-21
by mame (Yusuke Endoh) 15 Aug '25

15 Aug '25

Issue #21508 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21508: DevMeeting-2025-08-21 https://bugs.ruby-lang.org/issues/21508 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/08/21 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 2025/08/18. 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/

3 3

[ruby-core:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 15 Aug '25

15 Aug '25

Issue #20013 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20013: Travis CI status https://bugs.ruby-lang.org/issues/20013 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- I would like to use this ticket to manage our activities to report Travis CI status. Because there is Travis CI status page provided by Travis CI. However, even when the page shows ok, I actually see infra issues. https://www.traviscistatus.com/ I would share my activities and report the Travis CI status on the ticket. The ticket's status is not closed until we stop using Travis CI. The easiest option to fix the Travis infra issue is to email Travis CI support `support _AT_ travis-ci.com`. You can check [this ruby/ruby Travis CI wiki page](https://github.com/ruby/ruby/wiki/CI-Servers#travis-ci) for details. -- https://bugs.ruby-lang.org/

2 50

[ruby-core:122969] [Ruby Feature#21545] `#try_dig`: a dig that returns early if it cannot dig deeper
by cb341 (Daniel Bengl) 15 Aug '25

15 Aug '25

Issue #21545 has been reported by cb341 (Daniel Bengl). ---------------------------------------- Feature #21545: `#try_dig`: a dig that returns early if it cannot dig deeper https://bugs.ruby-lang.org/issues/21545 * Author: cb341 (Daniel Bengl) * Status: Open ---------------------------------------- Ruby offers `dig` for traversing nested hashes and arrays. It is strict and will raise if an intermediary object does not support `dig`. In many cases we only want to attempt the lookup and return `nil` if it cannot be followed, without caring about the exact reason. **Example:** ```rb { a: "foo" }.dig(:a, :b) # TypeError: String does not have #dig method { a: "foo" }.try_dig(:a, :b) # => nil ``` This is especially useful when dealing with data from APIs or other inconsistent sources: ```rb api_response = { status: "ok" } api_response.try_dig(:status, :code) # => nil api_response = { status: { code: 200 } } api_response.try_dig(:status, :code) # => 200 ``` The name `try_dig` makes it clear that it behaves like `dig` but will never raise for structural mismatches. It complements `dig` and the proposed `dig!` ([#12282](https://bugs.ruby-lang.org/issues/12282), [#15563](https://bugs.ruby-lang.org/issues/15563)) by covering the tolerant lookup case. A possible sketch: ```rb class Object def try_dig(*path) current = self path.each do |key| return nil unless current.respond_to?(:dig) begin current = current.dig(key) rescue StandardError return nil end end current end end ``` **Advantages** - Simplifies tolerant lookups without repetitive rescue logic - Clear intent when the value is optional - Useful for working with inconsistent or partially known data structures - Complements `dig` and potential `dig!` by covering the tolerant case **Disatvantages** - May hide structural issues that should be noticed during development -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122968] [Ruby Misc#21544] CI: Launchable: Early flake detection
by ono-max (Naoto Ono) 15 Aug '25

15 Aug '25

Issue #21544 has been reported by ono-max (Naoto Ono). ---------------------------------------- Misc #21544: CI: Launchable: Early flake detection https://bugs.ruby-lang.org/issues/21544 * Author: ono-max (Naoto Ono) * Status: Open ---------------------------------------- I'm a software engineer at Launchable, and I'd like to propose the mechanism to detect potential flaky tests. ## Background In the current Ruby CI, it's easy for flaky tests to be unintentionally merged into the master branch. Even when tests are known to be flaky, they can often be overlooked because re-running them may yield a passing result. Once flaky tests make it into the master branch, they become much harder to debug, and even reverting the changes can be difficult. Therefore, it's crucial to identify potential flaky tests as early as possible—ideally before merging a pull request into the master branch. If we can detect a flaky test during the PR stage, we can prevent it from being introduced into the codebase. ## How it works Here is the basic flow: 1. After the initial run, Launchable provides a list of tests to re-run. 2. The Ruby test framework executes these tests and uploads the results. 3. Using historical data, Launchable detects new or updated tests and returns an updated list. 4. The Ruby test framework runs the new list of tests and uploads the results. 5. Based on these results, Launchable determines which tests need to be re-run. 6. The Ruby test framework executes the identified tests and uploads the results. 7. Repeat step 5 and 6 until Launchable returns an empty test list. Here is the image: <img src="CI_workflow.png" alt="My Image" style="width:600px;"> ## Concerns * How much will Ruby CI slow down with this change? I don't believe this change significantly slow down the CI process. For example, consider a new test that takes 10 seconds to run. Adding 5 seconds to records to record test results to Launchable and another 5 seconds to provide the test list for re-runs, the total time per attempt becomes: (10 sec + 5 sec + 5 sec) = 20 seconds. With 5 retries, the total execution time would be: 20 seconds × 5 = 100 seconds. ---Files-------------------------------- CI_workflow.png (266 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122932] [Ruby Bug#21534] ppc64le Ractor ractor_port_receive aborted (core dumped)
by jaruga (Jun Aruga) 14 Aug '25

14 Aug '25

Issue #21534 has been reported by jaruga (Jun Aruga). ---------------------------------------- Bug #21534: ppc64le Ractor ractor_port_receive aborted (core dumped) https://bugs.ruby-lang.org/issues/21534 * Author: jaruga (Jun Aruga) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am seeing the following errors in the Ubuntu 24.04 noble server "Ubuntu (ppc64le)" on RubyCI on the relatively latest master branch commit `f3206cc79bec2fd852e81ec56de59f0a67ab32b7`. Originally I found the errors at <https://github.com/ruby/ruby/pull/13972#issuecomment-3160768404>. ## Reproducing the errors ``` $ grep ^VERSION /etc/os-release VERSION_ID="24.04" VERSION="24.04.3 LTS (Noble Numbat)" VERSION_CODENAME=noble $ uname -m ppc64le $ uname -r 6.8.0-71-generic ``` ``` $ pwd /home/jaruga/git/ruby/ruby ``` The following `configure` script's options comes from the `.github/workflows/ubuntu.yml`. https://github.com/ruby/ruby/blob/24d0b458cd6ccde1e052c1db15af120def349693/… ``` $ ./autogen.sh $ ./configure -C --disable-install-doc cppflags=-DRUBY_DEBUG $ make -j4 ``` Then the 2 assertions in the following tests always fail. ``` $ make btest BTESTS=bootstraptest/test_ractor.rb ... FAIL 2/147 tests failed make: *** [uncommon.mk:913: yes-btest] Error 1 $ make btest-ruby BTESTS=bootstraptest/test_ractor.rb FAIL 2/145 tests failed make: *** [uncommon.mk:921: yes-btest-ruby] Error 1 ... ``` And the `test_ractor_1.rb` is a minimal reproducer so far I found for the 1st failing assertion. ``` $ cat test_ractor_1.rb # Ractor.count counts = [] counts << Ractor.count p counts.inspect ractors = (1..2).map { Ractor.new { Ractor.receive } } counts << Ractor.count p counts.inspect ractors[0].send('End 0').join sleep 0.1 until ractors[0].inspect =~ /terminated/ counts << Ractor.count p counts.inspect ractors[1].send('End 1').join sleep 0.1 until ractors[1].inspect =~ /terminated/ counts << Ractor.count p counts.inspect ``` Then the following test fails once in 2 or 3 times. Below is a passing case. ``` $ make run TESTRUN_SCRIPT=test_ractor_1.rb ./miniruby -I./lib -I. -I.ext/common -r./powerpc64le-linux-fake test_ractor_1.rb "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "[1, 3]" "[1, 3, 2]" "[1, 3, 2, 1]" ``` Below is a failing (aborting) case. ``` $ make run TESTRUN_SCRIPT=test_ractor_1.rb ./miniruby -I./lib -I. -I.ext/common -r./powerpc64le-linux-fake test_ractor_1.rb "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "[1, 3]" vm_core.h:2017: Assertion Failed: rb_current_execution_context:ec == rb_current_ec_noinline() ruby 3.5.0dev (2025-08-06T15:07:49Z master f3206cc79b) +PRISM [powerpc64le-linux] -- Control frame information ----------------------------------------------- c:0004 p:0003 s:0014 e:000013 METHOD <internal:ractor>:667 c:0003 p:0008 s:0010 e:000009 METHOD <internal:ractor>:313 c:0002 p:0004 s:0006 e:000005 BLOCK test_ractor_1.rb:6 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test_ractor_1.rb:6:in 'block (2 levels) in <main>' <internal:ractor>:313:in 'receive' <internal:ractor>:667:in 'receive' -- Threading information --------------------------------------------------- Total ractor count: 3 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- /home/jaruga/git/ruby/ruby/miniruby(rb_print_backtrace+0x8) [0x10a262075e10] vm_dump.c:843 /home/jaruga/git/ruby/ruby/miniruby(rb_vm_bugreport) vm_dump.c:1175 /home/jaruga/git/ruby/ruby/miniruby(rb_assert_failure_detail+0x12c) [0x10a261c62aa0] error.c:1215 /home/jaruga/git/ruby/ruby/miniruby(rb_assert_failure+0x1c) [0x10a261c62ae0] error.c:1191 /home/jaruga/git/ruby/ruby/miniruby(rb_current_execution_context+0x34) [0x10a261c66574] vm_core.h:2017 /home/jaruga/git/ruby/ruby/miniruby(ractor_basket_value+0x0) [0x10a261ee2720] ractor_sync.c:826 /home/jaruga/git/ruby/ruby/miniruby(ractor_basket_accept) ractor_sync.c:833 /home/jaruga/git/ruby/ruby/miniruby(ractor_try_receive) ractor_sync.c:1144 /home/jaruga/git/ruby/ruby/miniruby(ractor_receive) ractor_sync.c:1160 /home/jaruga/git/ruby/ruby/miniruby(ractor_port_receive) ractor_sync.c:142 /home/jaruga/git/ruby/ruby/miniruby(builtin_invoker0+0x24) [0x10a26201c3f4] vm_insnhelper.c:7344 /home/jaruga/git/ruby/ruby/miniruby(invoke_bf+0x128) [0x10a26202d968] vm_insnhelper.c:7485 /home/jaruga/git/ruby/ruby/miniruby(vm_invoke_builtin_delegate+0x1c) [0x10a262059e08] vm_insnhelper.c:7509 /home/jaruga/git/ruby/ruby/miniruby(vm_exec_core) insns.def:1698 /home/jaruga/git/ruby/ruby/miniruby(vm_exec_loop+0x0) [0x10a26204af08] vm.c:2621 /home/jaruga/git/ruby/ruby/miniruby(rb_vm_exec) vm.c:2624 /home/jaruga/git/ruby/ruby/miniruby(thread_do_start_proc+0x394) [0x10a261fd6154] thread.c:584 /home/jaruga/git/ruby/ruby/miniruby(thread_do_start+0x8) [0x10a261fd68c8] thread.c:626 /home/jaruga/git/ruby/ruby/miniruby(thread_start_func_2) thread.c:677 /home/jaruga/git/ruby/ruby/miniruby(thread_sched_lock_+0x0) [0x10a261fd7104] thread_pthread.c:2237 /home/jaruga/git/ruby/ruby/miniruby(co_start) thread_pthread_mn.c:460 /home/jaruga/git/ruby/ruby/miniruby(co_start+0x8) [0x10a261fd7028] thread_pthread_mn.c:439 -- Other runtime information ----------------------------------------------- * Loaded script: test_ractor_1.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 fiber.so 3 rational.so 4 complex.so 5 pathname.so 6 ruby2_keywords.rb 7 set.rb 8 /home/jaruga/git/ruby/ruby/powerpc64le-linux-fake.rb * Process memory map: 10a261c30000-10a2622d0000 r-xp 00000000 08:01 1279300 /home/jaruga/git/ruby/ruby/miniruby 10a2622d0000-10a2622e0000 r--p 00690000 08:01 1279300 /home/jaruga/git/ruby/ruby/miniruby 10a2622e0000-10a2622f0000 rw-p 006a0000 08:01 1279300 /home/jaruga/git/ruby/ruby/miniruby 10a2622f0000-10a262300000 rw-p 00000000 00:00 0 10a279e90000-10a27a030000 rw-p 00000000 00:00 0 [heap] 68d2b0000000-68d2b0030000 rw-p 00000000 00:00 0 68d2b0030000-68d2b4000000 ---p 00000000 00:00 0 68d2b8000000-68d2b8030000 rw-p 00000000 00:00 0 68d2b8030000-68d2bc000000 ---p 00000000 00:00 0 68d2bc6f0000-68d2bc700000 ---p 00000000 00:00 0 68d2bc700000-68d2bc800000 rw-p 00000000 00:00 0 68d2bc800000-68d2bc910000 rw-p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bc910000-68d2bc920000 ---p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bc920000-68d2bcb20000 rw-p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bcb20000-68d2bcb30000 ---p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2bcb30000-68d2dc800000 rw-p 00000000 00:00 0 [anon:Ruby:nt_alloc_thread_stack_chunk] 68d2dc800000-68d2dc810000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc810000-68d2dc8c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc8c0000-68d2dc8d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc8d0000-68d2dc980000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc980000-68d2dc990000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dc990000-68d2dca40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dca40000-68d2dca50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dca50000-68d2dcb00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcb00000-68d2dcb10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcb10000-68d2dcbc0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcbc0000-68d2dcbd0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcbd0000-68d2dcc80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcc80000-68d2dcc90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcc90000-68d2dcd40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcd40000-68d2dcd50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcd50000-68d2dce00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dce00000-68d2dce10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dce10000-68d2dcec0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcec0000-68d2dced0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dced0000-68d2dcf80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcf80000-68d2dcf90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dcf90000-68d2dd040000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd040000-68d2dd050000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd050000-68d2dd100000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd100000-68d2dd110000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd110000-68d2dd1c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd1c0000-68d2dd1d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd1d0000-68d2dd280000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd280000-68d2dd290000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd290000-68d2dd340000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd340000-68d2dd350000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd350000-68d2dd400000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd400000-68d2dd410000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd410000-68d2dd4c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd4c0000-68d2dd4d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd4d0000-68d2dd580000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd580000-68d2dd590000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd590000-68d2dd640000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd640000-68d2dd650000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd650000-68d2dd700000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd700000-68d2dd710000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd710000-68d2dd7c0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd7c0000-68d2dd7d0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd7d0000-68d2dd880000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd880000-68d2dd890000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd890000-68d2dd940000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd940000-68d2dd950000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dd950000-68d2dda00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dda00000-68d2dda10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dda10000-68d2ddac0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddac0000-68d2ddad0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddad0000-68d2ddb80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddb80000-68d2ddb90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddb90000-68d2ddc40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddc40000-68d2ddc50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddc50000-68d2ddd00000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddd00000-68d2ddd10000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddd10000-68d2dddc0000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dddc0000-68d2dddd0000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dddd0000-68d2dde80000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dde80000-68d2dde90000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2dde90000-68d2ddf40000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddf40000-68d2ddf50000 ---p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2ddf50000-68d2de000000 rw-p 00000000 00:00 0 [anon:Ruby:fiber_pool_allocate_memory] 68d2de040000-68d2de060000 r-xp 00000000 08:01 13327 /usr/lib/powerpc64le-linux-gnu/libgcc_s.so.1 68d2de060000-68d2de070000 r--p 00010000 08:01 13327 /usr/lib/powerpc64le-linux-gnu/libgcc_s.so.1 68d2de070000-68d2de080000 rw-p 00020000 08:01 13327 /usr/lib/powerpc64le-linux-gnu/libgcc_s.so.1 68d2de080000-68d2de0b0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2de0b0000-68d2de0c0000 ---p 00000000 00:00 0 68d2de0c0000-68d2de1c0000 rw-p 00000000 00:00 0 68d2de1c0000-68d2de1f0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2de1f0000-68d2de200000 ---p 00000000 00:00 0 68d2de200000-68d2dea00000 rw-p 00000000 00:00 0 68d2dea00000-68d2f6a00000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_cache] 68d2f6a00000-68d2f7e00000 rw-p 00000000 00:00 0 [anon:Ruby:Init_default_shapes:shape_list] 68d2f7e00000-68d2f80f0000 r--p 00000000 08:01 5476 /usr/lib/locale/locale-archive 68d2f80f0000-68d2f8200000 rw-p 00000000 00:00 0 68d2f8200000-68d2f8460000 r-xp 00000000 08:01 25968 /usr/lib/powerpc64le-linux-gnu/libc.so.6 68d2f8460000-68d2f8470000 r--p 00260000 08:01 25968 /usr/lib/powerpc64le-linux-gnu/libc.so.6 68d2f8470000-68d2f8480000 rw-p 00270000 08:01 25968 /usr/lib/powerpc64le-linux-gnu/libc.so.6 68d2f8490000-68d2f84c0000 rw-p 00000000 00:00 0 68d2f84c0000-68d2f84d0000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2f84e0000-68d2f8550000 rw-p 00000000 00:00 0 [anon:Ruby:GC:default:heap_page_body_allocate] 68d2f8550000-68d2f85b0000 r--p 00000000 08:01 26004 /usr/lib/locale/C.utf8/LC_CTYPE 68d2f85b0000-68d2f86e0000 r-xp 00000000 08:01 25971 /usr/lib/powerpc64le-linux-gnu/libm.so.6 68d2f86e0000-68d2f86f0000 r--p 00130000 08:01 25971 /usr/lib/powerpc64le-linux-gnu/libm.so.6 68d2f86f0000-68d2f8700000 rw-p 00140000 08:01 25971 /usr/lib/powerpc64le-linux-gnu/libm.so.6 68d2f8700000-68d2f8740000 r-xp 00000000 08:01 5029 /usr/lib/powerpc64le-linux-gnu/libcrypt.so.1.1.0 68d2f8740000-68d2f8750000 r--p 00030000 08:01 5029 /usr/lib/powerpc64le-linux-gnu/libcrypt.so.1.1.0 68d2f8750000-68d2f8760000 rw-p 00040000 08:01 5029 /usr/lib/powerpc64le-linux-gnu/libcrypt.so.1.1.0 68d2f8760000-68d2f8800000 r-xp 00000000 08:01 27939 /usr/lib/powerpc64le-linux-gnu/libgmp.so.10.5.0 68d2f8800000-68d2f8810000 r--p 00090000 08:01 27939 /usr/lib/powerpc64le-linux-gnu/libgmp.so.10.5.0 68d2f8810000-68d2f8820000 rw-p 000a0000 08:01 27939 /usr/lib/powerpc64le-linux-gnu/libgmp.so.10.5.0 68d2f8820000-68d2f8850000 r-xp 00000000 08:01 23504 /usr/lib/powerpc64le-linux-gnu/libz.so.1.3 68d2f8850000-68d2f8860000 r--p 00020000 08:01 23504 /usr/lib/powerpc64le-linux-gnu/libz.so.1.3 68d2f8860000-68d2f8870000 rw-p 00030000 08:01 23504 /usr/lib/powerpc64le-linux-gnu/libz.so.1.3 68d2f8870000-68d2f8880000 r--s 00000000 08:01 25957 /usr/lib/powerpc64le-linux-gnu/gconv/gconv-modules.cache 68d2f8880000-68d2f88a0000 r--p 00000000 00:00 0 [vvar] 68d2f88a0000-68d2f88b0000 r-xp 00000000 00:00 0 [vdso] 68d2f88b0000-68d2f8900000 r-xp 00000000 08:01 25965 /usr/lib/powerpc64le-linux-gnu/ld64.so.2 68d2f8900000-68d2f8910000 r--p 00040000 08:01 25965 /usr/lib/powerpc64le-linux-gnu/ld64.so.2 68d2f8910000-68d2f8920000 rw-p 00050000 08:01 25965 /usr/lib/powerpc64le-linux-gnu/ld64.so.2 7fffe3520000-7fffe3550000 rw-p 00000000 00:00 0 [stack] make: *** [uncommon.mk:1430: run] Aborted (core dumped) ``` ## Debugging on gdb ``` $ make gdb TESTRUN_SCRIPT=test_ractor_1.rb gdb -x run.gdb --quiet --args ./miniruby -I./lib -I. -I.ext/common test_ractor_1.rb Reading symbols from ./miniruby... warning: File "/home/jaruga/git/ruby/ruby/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /home/jaruga/git/ruby/ruby/.gdbinit line to your configuration file "/home/jaruga/.config/gdb/gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/jaruga/.config/gdb/gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" Breakpoint 1 at 0x32acc: file error.c, line 1190. Breakpoint 2 at 0x32d30: file error.c, line 1112. Breakpoint 3 at 0x108820: file debug.c, line 168. warning: ./breakpoints.gdb: No such file or directory This GDB supports auto-downloading debuginfo from the following URLs: <https://debuginfod.ubuntu.com> Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". [New Thread 0x7fffddfff100 (LWP 3470199)] "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [New Thread 0x7fffdd7ef100 (LWP 3470200)] [New Thread 0x7fffbbdff100 (LWP 3470201)] "[1, 3]" "[1, 3, 2]" [Switching to Thread 0x7fffbbdff100 (LWP 3470201)] Thread 4 "miniruby" hit Breakpoint 1, 0x0000000100032acc in rb_assert_failure ( file=file@entry=0x100514e48 "vm_core.h", line=line@entry=2017, name=name@entry=0x100573a28 <__func__.2> "rb_current_execution_context", expr=expr@entry=0x10050f5e0 "ec == rb_current_ec_noinline()") at error.c:1190 1190 { (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/jaruga/git/ruby/ruby/miniruby -I./lib -I. -I.ext/common test_ractor_1.rb [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". [New Thread 0x7fffddfff100 (LWP 3470207)] "[1]" test_ractor_1.rb:6: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [New Thread 0x7fffdd7ef100 (LWP 3470208)] [New Thread 0x7fffbbdff100 (LWP 3470209)] "[1, 3]" "[1, 3, 2]" [Switching to Thread 0x7fffbbdff100 (LWP 3470209)] Thread 4 "miniruby" hit Breakpoint 1, 0x0000000100032acc in rb_assert_failure ( file=file@entry=0x100514e48 "vm_core.h", line=line@entry=2017, name=name@entry=0x100573a28 <__func__.2> "rb_current_execution_context", expr=expr@entry=0x10050f5e0 "ec == rb_current_ec_noinline()") at error.c:1190 1190 { ``` ``` (gdb) bt #0 0x0000000100032acc in rb_assert_failure (file=file@entry=0x100514e48 "vm_core.h", line=line@entry=2017, name=name@entry=0x100573a28 <__func__.2> "rb_current_execution_context", expr=expr@entry=0x10050f5e0 "ec == rb_current_ec_noinline()") at error.c:1190 #1 0x0000000100036574 in rb_current_execution_context (expect_ec=true) at vm_core.h:2017 #2 0x00000001002b2720 in rb_current_execution_context (expect_ec=true) at ractor_sync.c:826 #3 rb_current_ractor_raw (expect=true) at vm_core.h:2039 #4 rb_current_ractor_raw (expect=<optimized out>) at vm_core.h:2033 #5 rb_current_ractor () at vm_core.h:2047 #6 rb_current_ractor () at vm_core.h:2045 #7 ractor_queue_deq (rq=0x10082d680, r=<optimized out>) at ractor_sync.c:339 #8 ractor_try_receive (ec=0x10080ed30, rp=<optimized out>, cr=<optimized out>) at ractor_sync.c:1137 #9 ractor_receive (rp=<optimized out>, ec=<optimized out>) at ractor_sync.c:1160 #10 ractor_port_receive (ec=0x10080ed30, ec@entry=<error reading variable: value has been optimized out>, self=<error reading variable: value has been optimized out>) at ractor_sync.c:142 #11 0x00000001003ec3f4 in builtin_invoker0 (ec=<optimized out>, self=<optimized out>, argv=<optimized out>, funcptr=<optimized out>) at vm_insnhelper.c:7344 #12 0x00000001003fd968 in invoke_bf (ec=0x10080ed30, reg_cfp=0x7fffbc11ff20, bf=0x1006a9678 <ractor_table+552>, argv=0x0) at vm_insnhelper.c:7485 #13 0x0000000100429e08 in vm_invoke_builtin_delegate (start_index=<optimized out>, bf=<optimized out>, cfp=<optimized out>, ec=<optimized out>) at vm_insnhelper.c:7509 #14 vm_exec_core (ec=0x10080ed30) at insns.def:1698 #15 0x000000010041af08 in rb_vm_exec (ec=0x10080ed30) at vm.c:2621 #16 0x00000001003a6154 in thread_do_start_proc (th=th@entry=0x10082d6a0) at thread.c:584 #17 0x00000001003a68c8 in thread_do_start (th=0x10082d6a0) at thread.c:626 #18 thread_start_func_2 (th=th@entry=0x10082d6a0, stack_start=<optimized out>) at thread.c:677 #19 0x00000001003a7104 in call_thread_start_func_2 (th=<optimized out>) at thread_pthread.c:2237 #20 co_start (from=<optimized out>, self=0x10082d960) at thread_pthread_mn.c:458 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ``` In the stacktrace info, the ractor_sync.c:142 is below. https://github.com/ruby/ruby/blob/f3206cc79bec2fd852e81ec56de59f0a67ab32b7/… The ractor_sync.c:826 is below. https://github.com/ruby/ruby/blob/f3206cc79bec2fd852e81ec56de59f0a67ab32b7/… ## RubyCI Ubuntu (ppc64le) passing Interestingly, it seems that this core dump doesn't happen on the RubyCI Ubuntu (ppc64le) server, for example on the following log. I don't know why this core dump doesn't happen on the server. https://rubyci.s3.amazonaws.com/ppc64le/ruby-master/log/20250807T130006Z.lo… -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122643] [Ruby Bug#21498] Windows - Ruby Overrides C Library APIs thus breaking them
by cfis (Charlie Savage) 14 Aug '25

14 Aug '25

Issue #21498 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21498: Windows - Ruby Overrides C Library APIs thus breaking them https://bugs.ruby-lang.org/issues/21498 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: *all* on windows (testing with ruby 3.4.3 (2025-04-14 revision d0b7e5b6a0) +PRISM [x64-mswin64_140]) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am trying to wrap a simple C++ library, https://github.com/baderouaich/BitmapPlusPlus, as a Ruby extension. However when I use the extension to write a bitmap to disk the bitmap is corrupted. This is because the library uses std::ofstream which eventually uses the C API fclose to write the final bytes to the bitmap file and then closes it. The problem is that Ruby overrides `fclose` and replaces it with `rb_w32_fclose`. It then *exports* its custom version from from x64-vcruntime140-ruby340.dll. And the exported version is broken (at least from the standpoint of the C standard library). Note this has been a long standing issue. The first report I see is from 2013: https://bugs.ruby-lang.org/issues/8569 More recently in 2020 (which explains the issue very well): https://github.com/NREL/OpenStudio/issues/3942#issuecomment-610673401 I understand that Ruby is trying to provide a platform independent API. But the problem is this solution breaks any third party libraries that rely on these C APIs (which of course are very common). And there is no good workaround (see https://github.com/NREL/OpenStudio/issues/3942#issuecomment-611072774) So would it be possible for Ruby to stop exporting custom versions of basic C APIs? The code that does it is here: https://github.com/ruby/ruby/blob/master/win32/mkexports.rb#L41 Ruby of course could still use its custom versions of fclose, read, write etc within ruby.exe and x64-vcruntime140-ruby340.dll. But they should not be exported from x64-vcruntime140-ruby340.dll and thus be off limits to extensions. If a case comes up where an extension really needs access to rb_w32_fclose instead of fclose then an extension developer can use an `#ifdef _WIN32` to do so and work across platforms. That at least puts the developer in control versus now where I don't see any way I can to wrap the bitmap library for usage in Ruby. From my experience the biggest problem is the replacing of fclose with rb_w32_fclose. But I propose removing all such mappings, which include: FD_CLR=rb_w32_fdclr FD_ISSET=rb_w32_fdisset Sleep=rb_w32_Sleep accept=rb_w32_accept access=rb_w32_uaccess bind=rb_w32_bind close=rb_w32_close connect=rb_w32_connect dup2=rb_w32_dup2 fclose=rb_w32_fclose fstat=rb_w32_fstati128 get_osfhandle=rb_w32_get_osfhandle getcwd=rb_w32_ugetcwd getenv=rb_w32_ugetenv gethostbyaddr=rb_w32_gethostbyaddr gethostbyname=rb_w32_gethostbyname gethostname=rb_w32_gethostname getpeername=rb_w32_getpeername getpid=rb_w32_getpid getppid=rb_w32_getppid getprotobyname=rb_w32_getprotobyname getprotobynumber=rb_w32_getprotobynumber getservbyname=rb_w32_getservbyname getservbyport=rb_w32_getservbyport getsockname=rb_w32_getsockname getsockopt=rb_w32_getsockopt inet_ntop=rb_w32_inet_ntop inet_pton=rb_w32_inet_pton ioctlsocket=rb_w32_ioctlsocket isatty=rb_w32_isatty listen=rb_w32_listen lseek=rb_w32_lseek lstat=rb_w32_ulstati128 mkdir=rb_w32_umkdir mmap=rb_w32_mmap mprotect=rb_w32_mprotect munmap=rb_w32_munmap pipe=rb_w32_pipe pread=rb_w32_pread pwrite=rb_w32_pwrite read=rb_w32_read recv=rb_w32_recv recvfrom=rb_w32_recvfrom rename=rb_w32_urename rmdir=rb_w32_urmdir select=rb_w32_select send=rb_w32_send sendmsg sendto=rb_w32_sendto setsockopt=rb_w32_setsockopt shutdown=rb_w32_shutdown socket=rb_w32_socket stati128=rb_w32_ustati128 strcasecmp=msvcrt.stricmp strerror=rb_w32_strerror strncasecmp=msvcrt.strnicmp times=rb_w32_times unlink=rb_w32_uunlink utime=rb_w32_uutime utimensat=rb_w32_uutimensat utimes=rb_w32_uutimes write=rb_w32_write -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122959] [Ruby Bug#21541] make install is failing due to using rdoc repo
by MSP-Greg (Greg L) 14 Aug '25

14 Aug '25

Issue #21541 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21541: make install is failing due to using rdoc repo https://bugs.ruby-lang.org/issues/21541 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: master * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, ruby-dev-builder & ruby-loco are failing due to https://github.com/ruby/ruby/commit/8f6f9e88c70bbae, which changed the rdoc 'bundled gem' install from using a released gem to the repo. This results in an invalid rdoc installation. RDoc contains *.ry and *.kpeg source files that need to be 'compiled' into *.rb files with racc and kpeg. These *.rb files are not contained in the rdoc repo. One possible change would be to have rdoc include the compiled *.rb files in its repo. Puma has a similar issue with ragel files. A GHA workflow (https://github.com/puma/puma/blob/master/.github/workflows/ragel.yml) checks that the compiled *.c file matches its respective *.rl source file. Otherwise, a bit of code would be required in Ruby (and install of kpeg), or, rdoc must be installed from a released gem. -- https://bugs.ruby-lang.org/

3 4

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

14 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/

1 0

[ruby-core:122960] [Ruby Feature#21542] logger gem: Context API
by chucke (Tiago Cardoso) 13 Aug '25

13 Aug '25

Issue #21542 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #21542: logger gem: Context API https://bugs.ruby-lang.org/issues/21542 * Author: chucke (Tiago Cardoso) * Status: Open ---------------------------------------- Proposal done as a [github issue](https://github.com/ruby/logger/issues/131) with [WIP implementation](https://github.com/ruby/logger/pull/132) for discussion purposes. -- https://bugs.ruby-lang.org/

1 0

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

12 Aug '25

Issue #17316 has been updated by Dan0042 (Daniel DeLorme). ixti (Alexey Zapparov) wrote in #note-14: > Firstly, rbocop is totally optional. Secondly, even rubocop is suggesting something more elegant than the above example: Ah yes you're right. I read "The new rule enforces this syntax" and took it at face value. But yeah the link has the much more common idiom `return @foo if defined?(@foo)` Also I got the impression this was an official style guide from the Rails team, but now I'm not so sure. Sorry for the overreaction. ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114263 * 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