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

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

22 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 9

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

22 Aug '25

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

8 11

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

21 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:120694] [Ruby master Bug#21039] Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks
by Eregon (Benoit Daloze) 21 Aug '25

21 Aug '25

Issue #21039 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21039: Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks https://bugs.ruby-lang.org/issues/21039 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby def make_counter count = 0 nil.instance_exec do [-> { count }, -> { count += 1 }] end end get, increment = make_counter reader = Thread.new { sleep 0.01 loop do p get.call sleep 0.1 end } writer = Thread.new { loop do increment.call sleep 0.1 end } ractor_thread = Thread.new { sleep 1 Ractor.make_shareable(get) } sleep 2 ``` This prints: ``` 1 2 3 4 5 6 7 8 9 10 10 10 10 10 10 10 10 10 10 10 ``` But it should print 1..20, and indeed it does when commenting out the `Ractor.make_shareable(get)`. This shows a given block/Proc instance is concurrently broken by `Ractor.make_shareable`, IOW Ractor is breaking fundamental Ruby semantics of blocks and their captured/outer variables or "environment". It's expected that `Ractor.make_shareable` can `freeze` objects and that may cause some FrozenError, but here it's not a FrozenError, it's wrong values being read. I think what should happen instead is that `Ractor.make_shareable` should create a new Proc and mutate that. However, if the Proc is inside some other object and not just directly the argument, that wouldn't work (like `Ractor.make_shareable([get])`). So I think one fix would to be to only accept Procs for `Ractor.make_shareable(obj, copy: true)`. FWIW that currently doesn't allow Procs, it gives `<internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError)`. I think the only other way, and I think it would be a far better way would be to not support making Procs shareable with `Ractor.make_shareable`. Instead it could be some new method like `isolated { ... }` or `Proc.isolated { ... }` or `Proc.snapshot_outer_variables { ... }` or so, only accepting a literal block (to avoid mutating/breaking an existing block), and that would snapshot outer variables (or require no outer variables like Ractor.new's block, or maybe even do `Ractor.make_shareable(copy: true)` on outer variables) and possibly also set `self` since that's anyway needed. That would make such blocks with different semantics explicit, which would fix the problem of breaking the intention of who wrote that block and whoever read that code, expecting normal Ruby block semantics, which includes seeing updated outer variables. Related: #21033 https://bugs.ruby-lang.org/issues/18243#note-5 Extracted from https://bugs.ruby-lang.org/issues/21033#note-14 -- https://bugs.ruby-lang.org/

7 24

[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:122501] [Ruby Bug#21402] ruby2_keywords affects methods/procs with post arguments
by jeremyevans0 (Jeremy Evans) 21 Aug '25

21 Aug '25

Issue #21402 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21402: ruby2_keywords affects methods/procs with post arguments https://bugs.ruby-lang.org/issues/21402 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- I believe this is an oversight. We forgot to consider post arguments during the development of `ruby2_keywords`. I believe we should not allow `ruby2_keywords` on methods/procs with post arguments. Example: ```ruby def a(*c, **kw) [c, kw] end def b(*a, b) a(*a, b) end ruby2_keywords(:b) b({foo: 1}, bar: 1) # Currently: [[{foo: 1}], {bar: 1}] # Expected: [[{foo: 1}, {bar: 1}], {}] ``` I think the current behavior is unexpected and undesired, because instead of flagging the last element in the splat array, it flags a post argument. I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/13475 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:122665] [Ruby Bug#21503] \p{Word} does not match on \p{Join_Control} while docs say it does
by procmarco (Marco Concetto Rudilosso) 21 Aug '25

21 Aug '25

Issue #21503 has been reported by procmarco (Marco Concetto Rudilosso). ---------------------------------------- Bug #21503: \p{Word} does not match on \p{Join_Control} while docs say it does https://bugs.ruby-lang.org/issues/21503 * Author: procmarco (Marco Concetto Rudilosso) * Status: Open * ruby -v: 3.4.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- in the [docs](https://ruby-doc.org/3.4.1/Regexp.html#:~:text=/%5Cp%7B-,Word,-%7D/%3… it is mentioned that `\p{Word}` matches the equivalent of: `[\p{M}\p{Nd}\p{Pc}\p{Alpha}\p{Join_Control}]` as it's also defined in the [unicode spec](https://unicode.org/reports/tr18/#word) the issue is that it does not seem to be the case ``` irb(main):018> REGEX = /\p{Word}/u => /\p{Word}/ irb(main):019> "\u200D".gsub(REGEX, "-") => "‍" irb(main):020> REGEX2 = /\p{Join_Control}/u => /\p{Join_Control}/ irb(main):021> "\u200D".gsub(REGEX2, "-") => "-" ``` There's 2 solutions here, either we change the docs or the code. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:122847] [Ruby Feature#21520] Feature Proposal: Enumerator::Lazy#peek
by nuzair46 (Nuzair Rasheed) 21 Aug '25

21 Aug '25

Issue #21520 has been reported by nuzair46 (Nuzair Rasheed). ---------------------------------------- Feature #21520: Feature Proposal: Enumerator::Lazy#peek https://bugs.ruby-lang.org/issues/21520 * Author: nuzair46 (Nuzair Rasheed) * Status: Open ---------------------------------------- # Abstract Add a #peek method to Enumerator::Lazy that allows observing each element in a lazy enumeration pipeline without modifying or consuming the stream. # Background Ruby provides Enumerator::Lazy for efficient lazy stream processing. However, unlike languages such as Java, it lacks a clean way to inspect intermediate elements during lazy evaluation. Currently, developers must misuse .map for side effects, example: ```rb (1..).lazy.map { |x| puts x; x }.select(&:even?).first(3) ``` This is semantically incorrect and confusing, since .map implies transformation, not observation. # Proposal Introduce Enumerator::Lazy#peek, which yields each item to a block and returns the item unmodified, similar to Object#tap, but in a lazy stream: ```rb (1..).lazy .peek { |x| puts "saw: #{x}" } .select(&:even?) .first(3) ``` This would be equivalent to: ```rb lazy.map { |x| block.call(x); x } ``` but with improved semantic clarity. # Use cases • Debugging lazy enumerators without breaking the chain • Logging or instrumentation in pipelines • Educational / demo use for showing lazy evaluation step-by-step • Cleaner replacement for map { puts x; x } hacks Example: ```rb data = (1..).lazy .peek { |x| puts "got #{x}" } .select(&:even?) .first(5) ``` result: ```rb got 1 got 2 got 3 got 4 got 5 ``` And return [2, 4, 6, 8, 10] # Discussion #peek is a minimal, non-breaking addition that improves clarity and idiomatic usage of Enumerator::Lazy. It avoids abusing .map for observation and is familiar to developers from other languages. #peek is also not needed for other enumerators where .tap or .each can do the job. It mirrors Java’s .stream().peek(...) and makes Ruby’s lazy enumeration more expressive and readable. # See also • [Java Stream.peek](https://docs.oracle.com/javase/8/docs/api/java/util/stream/Str… I would be glad to work on this and make a PR. Thank you. -- https://bugs.ruby-lang.org/

4 11

[ruby-core:122343] [Ruby Misc#21385] Namespace: Suggesting a rename
by fxn (Xavier Noria) 21 Aug '25

21 Aug '25

Issue #21385 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21385: Namespace: Suggesting a rename https://bugs.ruby-lang.org/issues/21385 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- I'd like to suggest a rename of namespaces. The word "namespace" is already taken in Ruby. We say that classes and modules act as or represent. Constant paths nest them in practice. We say that it is a best practice that gems create their own namespace, etc. If the feature goes ahead with this name, the above sentences, well-established in the Ruby community, will start to sound confusing, because that meaning of "namespace" stays. If you look at the index in Matz's book, "namespaces" is indexed in pages 248–250. Title of section 7.5.1 is "Modules as Namespaces". Besides, I have had a few experiences explaining the proposal to people, and quickly realizing they assume this is something like C++ namespaces or Java packages. Then, I have to undo that mental model and start all over saying "forget that mental model". Those are like our constant paths, only more simple and strict. I think it may also be confusing in this sense (though this could be OK if it wasn't for the previous point.) To be constructive: Some alternative names that I have thought about are "isolates", "shields", or "cells". ("sandboxes" is close, but may have security connotations you do not want to suggest.) -- https://bugs.ruby-lang.org/

16 26