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

[ruby-core:121142] [Ruby master Misc#21154] Document or change Module#autoload?
by fxn (Xavier Noria) 05 Jun '25

05 Jun '25

Issue #21154 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21154: Document or change Module#autoload? https://bugs.ruby-lang.org/issues/21154 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- The documentation of `Module#autoload?` says > Returns filename to be loaded if name is registered as autoload in the namespace of mod or one of its ancestors. Cool, but in the following snippet ```ruby autoload :Foo, 'foo' autoload?(:Foo) ``` the second line could evaluate to `nil`, and this does not seem to agree. I just registered an autoload, therefore (according to the documentation) I should get "foo" back in line 2. I'd like to ask for clarification from the Ruby team: 1. Is the documentation complete? Should that second line always return "foo"? 2. If the answer is no, which is the logic missing in the docs? Thank you! -- https://bugs.ruby-lang.org/

3 31

[ruby-core:119645] [Ruby master Bug#20854] Some bundled gems are not installed starting with 007c75ce4c66243e41144c6977e5ccbf4ab71c93
by jvreeland (Justin Vreeland) 04 Jun '25

04 Jun '25

Issue #20854 has been reported by jvreeland (Justin Vreeland). ---------------------------------------- Bug #20854: Some bundled gems are not installed starting with 007c75ce4c66243e41144c6977e5ccbf4ab71c93 https://bugs.ruby-lang.org/issues/20854 * Author: jvreeland (Justin Vreeland) * Status: Open * ruby -v: Building ruby from master * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I noticed in ruby 3.4.0 preview 2 that some bundled gems weren't being installed any more. I'm running in the same environment each time and bundled gems are installed fine with 3.3 or with the mentioned commit reverted. I bisected this from a version that did install the gems to 007c75ce4c66243e41144c6977e5ccbf4ab71c93 . The comment in that commit does indicate that it's mean to skip games if the gems are not found or can't be built but the final message is 'not found in bundled_gems'. I'm unsure if this is this is working as intended. When my build finishes I see the following line in the log: ``` installing bundled gem cache: /home/user/ruby/build/.rubies/bisect/lib/ruby/gems/3.4.0+0/cache skipped bundled gems: bigdecimal-3.1.8.gem not found in bundled_gems debug-1.9.2.gem not found in bundled_gems nkf-0.2.0.gem not found in bundled_gems/rac racc-1.8.1.gem not found in bundled_gems rbs-3.6.1.gem not found in bundled_gems syslog-0.1.2.gem not found in bundled_gems typeprof-0.30.0.gem not found in bundled_gems ``` I see racc in bundled gems and cached in downloads. I don't see any files named gem.build_complete or errors concerning gem building or missing C extensions in my build logs. Is there additional configure flags or dependencies I need to include the bundled gems in the upcoming 3.4.0 ruby release? I followed the instructions at: https://docs.ruby-lang.org/en/master/contributing/building_ruby_md.html to build: ``` git clean -dxf git checkout -f autoreconf -fi mkdir build pushd build ../configure --prefix=(pwd)/.rubies/bisect make -j(nproc) make install popd find build/.rubies/bisect -name 'racc' | grep . ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118191] [Ruby master Bug#20560] make install - skipped bundled gems - minor issue
by MSP-Greg (Greg L) 04 Jun '25

04 Jun '25

Issue #20560 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #20560: make install - skipped bundled gems - minor issue https://bugs.ruby-lang.org/issues/20560 * Author: MSP-Greg (Greg L) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- See most recent job: https://github.com/ruby/ruby/actions/runs/9389674968/job/25857719333#step:9… Which is logging the following during `make install`: ``` skipped bundled gems: power_assert-2.0.4dev.gem not found in bundled_gems syslog-0.1.2.gem not found in bundled_gems ``` Not sure what the correct versioning should be. Or, should bundled gems use 'dev' versions, etc... -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115995] [Ruby master Bug#20112] Ractors not working properly in ruby 3.3.0
by ariasdiniz (Aria Diniz) 19 May '25

19 May '25

Issue #20112 has been reported by ariasdiniz (Aria Diniz). ---------------------------------------- Bug #20112: Ractors not working properly in ruby 3.3.0 https://bugs.ruby-lang.org/issues/20112 * Author: ariasdiniz (Aria Diniz) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I recently installed Ruby 3.3.0, and noticed that some of my scripts that use Ractors started to struggle with performance. After doing some benchmarks, I noticed that, while Ractors seem to be working well on Ruby 3.2.2, they're not working properly on 3.3.0. I'm using Ubuntu 22.04.3 LTS Here is the benchmark code: ``` ruby # frozen_string_literal: true require 'benchmark' Ractor.new { :warmup } if defined?(Ractor) Benchmark.bmbm do |x| x.report("Thread: ") do threads = [] 8.times do |i| threads << Thread.new do 20000000.times do |j| ((i * 20000000) + j)**2 end end end threads.each(&:join) end x.report("Ractor: ") do ractors = [] 0..8.times do |i| ractors << Ractor.new(i) do |k| 20000000.times do |j| ((k * 20000000) + j)**2 end end end ractors.map(&:take) end end ``` Here is the results for Ruby 3.2.2: Rehearsal -------------------------------------------- Thread: 7.666909 0.001091 7.668000 ( 7.675266) Ractor: 19.318528 0.012017 19.330545 ( 2.505888) ---------------------------------- total: 26.998545sec user system total real Thread: 7.918141 0.004011 7.922152 ( 7.928772) Ractor: 19.366414 0.003954 19.370368 ( 2.517993) Here is the results for Ruby 3.3.0: Rehearsal -------------------------------------------- Thread: 8.634152 0.010895 8.645047 ( 8.645104) Ractor: 100.172179 0.035985 100.208164 ( 15.213245) --------------------------------- total: 108.853211sec user system total real Thread: 9.451236 0.004002 9.455238 ( 9.460132) Ractor: 118.463294 0.119942 118.583236 ( 18.462157) -- https://bugs.ruby-lang.org/

5 4

[ruby-core:120671] [Ruby master Bug#21037] Ractors hang with multiple threads
by tenderlovemaking (Aaron Patterson) 14 May '25

14 May '25

Issue #21037 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21037: Ractors hang with multiple threads https://bugs.ruby-lang.org/issues/21037 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-14T20:59:39Z master f1e32914eb) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program hangs, but I don't expect it to hang: ```ruby # frozen_string_literal: true class Map def initialize @r = Ractor.new { cache = { "int" => "integer", "bool" => "boolean" } loop do key = receive Ractor.yield key end } freeze end def fetch(key) @r.send key m = @r.take raise unless key == m m end end tm = Map.new t1 = Thread.new { 10.times { |i| p [i + 1,tm.fetch("int")] } } t2 = Thread.new { 10.times { |i| p [i + 1, tm.fetch("bool")] } } t1.join t2.join ``` I'm not sure why this program hangs yet, but it does both on macOS and Linux. I've tested with master, Ruby 3.4, and Ruby 3.3. I'm not sure why it's hanging yet, but I wanted to file an issue. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:119137] [Ruby master Bug#20726] Issue with hash without braces when assigned to constant with ractor literals
by luke-gru (Luke Gruber) 14 May '25

14 May '25

Issue #20726 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20726: Issue with hash without braces when assigned to constant with ractor literals https://bugs.ruby-lang.org/issues/20726 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.0dev * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby a = 'hi' A = ['hello' => a] p A ``` gives: ``` ./ruby -I../ruby/lib -I. -I.ext/x86_64-linux -I.ext/common -r./x86_64-linux-fake ../ruby/test.rb -- raw disasm-------- trace: 1 0000 putchilledstring "hi" ( 3) 0002 setlocal_WC_0 3 ( 3) trace: 1 0004 newarray 1 ( 4) 0006 putspecialobject 3 ( 4) * 0008 setconstant :A ( 4) trace: 1 0010 putself ( 5) 0011 opt_getconstant_path [:A] ( 5) 0013 opt_send_without_block <calldata:p, 1> ( 5) 0015 leave ( 5) --------------------- ../ruby/test.rb:4: argument stack underflow (-1) ../ruby/test.rb: compile error (SyntaxError) ``` This is due to a line in `compile.c`, function `compile_shareable_literal_constant`: ```c if (!RNODE_HASH(node)->nd_brace) { } ``` I'm not sure why this condition is there so I'm not confident in making a fix. Also, my git-fu isn't the best so I can't track down the right commit where it was added. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:111809] [Ruby master Bug#19338] Ruby hangs when defining new constant in ractor
by luke-gru (Luke Gruber) 13 May '25

13 May '25

Issue #19338 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19338: Ruby hangs when defining new constant in ractor https://bugs.ruby-lang.org/issues/19338 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This code causes Ruby to hang: ``` ruby rs = [] 2.times do rs << Ractor.new do MYCONSTANT = 2 end end rs.each(&:take) ``` There is a problem when the warning is being outputted with multiple ractors. A thread is calling RB_VM_LOCK() while holding the VM lock in ractor.c (ractor_check_blocking()) If the code is changed to RB_VM_LOCK_ENTER() and RB_VM_LOCK_LEAVE() then it fixes it, but I don't know if there's a better way. Thanks! -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118467] [Ruby master Feature#20610] Float::INFINITY as IO.select timeout argument
by akr (Akira Tanaka) 13 May '25

13 May '25

Issue #20610 has been reported by akr (Akira Tanaka). ---------------------------------------- Feature #20610: Float::INFINITY as IO.select timeout argument https://bugs.ruby-lang.org/issues/20610 * Author: akr (Akira Tanaka) * Status: Open ---------------------------------------- I propose IO.select accepts Float::INFINITY as a timeout argument. It behaves the same as nil which means IO.select will block indefinitely. Motivation: Currently, the Ruby convention to indicate no timeout is using nil. This practice often forces us to treat the nil case separately. Conceptually, no timeout can be thought of as an infinite timeout. So I propose to accept Float::INFINITY as a timeout. It makes us less conditionals when we need to calculate or compare timeouts. Assume `now` method as follows to read the following examples. ``` def now = Process.clock_gettime(Process::CLOCK_MONOTONIC) ``` Example 1: absolute timeout Sometimes we maintain timeout as an absolute clock. The following method takes a relative timeout as an argument. It invokes IO.select several times and raises if the timeout is reached. Assuming a user must specify a finite timeout, the following definition is possible. ``` # user_timeout is the required argument def method(..., user_timeout) abs_timeout = now + user_timeout loop { IO.select(rs, ws, es, (abs_timeout - now).clamp(0..)) raise "timeout" if abs_timeout < now ... } end ``` Consider we need to make user_timeout optional. If user_timeout is not given, no timeout occurs. The implementation is as follows. I think the following implementation is typical. It needs 3 more conditionals than the above. ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : nil loop { IO.select(rs, ws, es, user_timeout ? (abs_timeout - now).clamp(0..) : nil) raise "timeout" if abs_timeout && (abs_timeout < now) ... } end ``` It is possible to reduce a conditional if we use Float::INFINITY. (`abs_timeout && (abs_timeout < now)` is changed to `abs_timeout < now`) ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : Float::INFINITY loop { IO.select(rs, ws, es, abs_timeout != Float::INFINITY ? (abs_timeout - now).clamp(0..) : nil) raise "timeout" if abs_timeout < now ... } end ``` If IO.select accepts Float::INFINITY as a timeout argument (this proposal), we can reduce one more conditional as follows. ``` # user_timeout is an optional argument. nil means no timeout. def method(..., user_timeout=nil) abs_timeout = user_timeout ? now + user_timeout : Float::INFINITY loop { IO.select(rs, ws, es, (abs_timeout - now).clamp(0..)) raise "timeout" if abs_timeout < now ... } end ``` Example 2: minimum of timeouts Sometimes we need to choose the minimum of several timeouts. I think many event-driven programs use this strategy to determine the timeout for select function. If "no timeout" is represented as nil, `[t1, t2, t3, ...].compact.min` is the minimum. If "no timeout" is represented as Float::INFINITY, we can remove `compact`: `[t1, t2, t3, ...].min` However, Float::INFINITY must be converted to nil for IO.select. This proposal removes this conversion. Example 3: maximum of timeouts Sometimes we need to choose the maximum of several timeouts. We encountered this situation with a Happy Eyeballs implementation. There are two timeouts for getaddrinfo and connect. We need to wait the longer timeout because a timeout for one doesn't stop another. Also, we don't ignore results after a timeout as long as the algorithm waits for something. If "no timeout" is represented as nil, `ts = [t1, t2, t3, ...]; ts.include?(nil) ? nil : ts.max` is the maximum. If "no timeout" is represented as Float::INFINITY, we can compute the maximum more easily: `[t1, t2, t3, ...].max` It makes code simpler. However, Float::INFINITY must be converted to nil for IO.select. This proposal removes this conversion. Several Consideration: Consideration 1: Methods other than IO.select. Several methods take a timeout. An incomplete list of methods is as follows. (I searched rb_time_interval.) - IO.select(rs, ws, es, timeout) - sleep(secs) - TCPSocket.new(connect_timeout:) - io.wait_readable(timeout) - io.wait_writable(timeout) - io.wait_priority(timeout) - mutex.sleep(timeout) Do we want to modify them consistently to accept Float::INFINITY? Consideration 2: C-level API If we want to change the timeout of many methods, we would wish to new C-level API similar to rb_time_interval but can return NULL. Unfortunately, rb_time_interval cannot return NULL because the return type is struct timeval. Note that ext/io/wait/wait.c contains get_timeout function. It seems a good first step for such API. Consideration 3: IEEE 754 dependency. Minor platforms (such as VAX) use non-IEEE 754 floating point numbers without infinity. Note that NetBSD/vax still works. (And there is an emulator, simh). Consideration 4: It seems no major languages accept infinity as select's timeout. I found Perl, Python, and OCaml take a floating point number as a timeout of select function. But they don't accept infinity. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:116085] [Ruby master Bug#20165] Ractors moving a Struct breaks beyond the first 3 fields
by codekitchen (Brian Palmer) 09 May '25

09 May '25

Issue #20165 has been reported by codekitchen (Brian Palmer). ---------------------------------------- Bug #20165: Ractors moving a Struct breaks beyond the first 3 fields https://bugs.ruby-lang.org/issues/20165 * Author: codekitchen (Brian Palmer) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Experimenting with Ractors on ruby 3.3.0, and I'm seeing a bug where if you move a struct between ractors, all but the first 3 fields are set to nil. ``` ruby Foo = Struct.new(:a,:b,:c,:d,:e,:f) r = Ractor.new { foo = Foo[0,0,0,0,0,0] p foo Ractor.yield(foo, move: true) } p r.take ``` ``` ❯ ruby -v ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] ❯ ruby rbug.rb rbug.rb:3: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<struct Foo a=0, b=0, c=0, d=0, e=0, f=0> #<struct Foo a=0, b=0, c=0, d=nil, e=nil, f=nil> ``` This seems specific to moving, if I set `move: false` the struct makes it across OK. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119941] [Ruby master Bug#20897] resolv: not usable across ractors
by chucke (Tiago Cardoso) 09 May '25

09 May '25

Issue #20897 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #20897: resolv: not usable across ractors https://bugs.ruby-lang.org/issues/20897 * Author: chucke (Tiago Cardoso) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Using the `resolv` library in a non-main ractor is impossible, due to DNS resources being memoized in a mutable class variable. [This patch](https://github.com/ruby/resolv/pull/62) fixes it by storing resource information in static variables. -- https://bugs.ruby-lang.org/

3 2