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

[ruby-core:123228] Confirm You’re Not a Robot
by administrator 11 Sep '25

11 Sep '25

1 0

[ruby-core:123184] [Ruby Feature#21564] Extend permutation, repeated_permutation, combination and repeated_combination argument
by toy (Ivan Kuchin) 11 Sep '25

11 Sep '25

Issue #21564 has been reported by toy (Ivan Kuchin). ---------------------------------------- Feature #21564: Extend permutation, repeated_permutation, combination and repeated_combination argument https://bugs.ruby-lang.org/issues/21564 * Author: toy (Ivan Kuchin) * Status: Open ---------------------------------------- When using functions `permutation`, `repeated_permutation`, `combination` and `repeated_combination`, often one needs not one, but multiple permutation/combination sizes. Currently all functions accept one Integer argument (for `permutation` it is optional and defaults to array size), and it would be more powerful if it would accept also a range or a Enumerable: ```ruby a = [1, 2, 3] a.permutation(1..3).to_a # => [[1], [2], [3], # [1, 2], [1, 3], [2, 1], [2, 3], [3, 1], [3, 2], # [1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]] a.permutation([1, 3]).to_a # => [[1], [2], [3], # [1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]] a.permutation([3, 1]).to_a # => [[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1], # [1], [2], [3]] a.repeated_permutation([2, 1]).to_a # => [[1, 1], [1, 2], [1, 3], [2, 1], [2, 2], [2, 3], [3, 1], [3, 2], [3, 3], # [1], [2], [3]] a.combination(1..3).to_a # => [[1], [2], [3], # [1, 2], [1, 3], [2, 3], # [1, 2, 3]] a.repeated_combination(1..3).to_a # => [[1], [2], [3], # [1, 1], [1, 2], [1, 3], [2, 2], [2, 3], [3, 3], # [1, 1, 1], [1, 1, 2], [1, 1, 3], [1, 2, 2], [1, 2, 3], [1, 3, 3], [2, 2, 2], [2, 2, 3], [2, 3, 3], [3, 3, 3]] ``` Ruby code to enhance current `permutation` would be: ```ruby class Array alias_method :original_permutation, :permutation def permutation(counts, &block) return to_enum(__method__, counts) unless block if counts.is_a?(Enumerable) counts.each do |count| original_permutation(count, &block) end else original_permutation(counts, &block) end end end ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:123222] [Ruby Misc#21570] Windows: Static compilation struggles
by NuriYuri (Youri Nouri) 11 Sep '25

11 Sep '25

Issue #21570 has been reported by NuriYuri (Youri Nouri). ---------------------------------------- Misc #21570: Windows: Static compilation struggles https://bugs.ruby-lang.org/issues/21570 * Author: NuriYuri (Youri Nouri) * Status: Open ---------------------------------------- Hi, I'm trying to make static Ruby binaries and I've discovered several issues in the **Windows** building process: 1. The `GNUMakefile` is trying to generate a ruby.exp file. It uses dllwrap leading to a failure since this is deprecated and exits with non-zero. (The ruby.exp file looks unnecessary for the compilation process). 2. The generation of encoding (src/enc) files seem to be missing RUBY_EXPORT define and -lonig 3. The openssl extconf.h is missing RUBY_EXPORT define. 4. All the bundled gems are missing RUBY_EXPORT define and -lgmp Also, the makefile is making some mess with the static and shared library file. It forces me to add `lib=arc` in `rbinstall.rb` so make install can work. Here's the commands I ran for that result: - `ridk enable ucrt64` - `sh ./src/autogen.sh` - `cd build` - `sh ../src/configure -C --disable-install-doc --disable-dln -disable-install-rdoc --disable-install-capi --with-static-linked-ext --disable-shared --disable-yjit --disable-rjit --enable-load-relative --with-parser=parse.y --prefix=C:/Projet/ruby/build/install` - `make` - `make install` I used the Ruby 3.4.5 archive from https://www.ruby-lang.org/en/downloads and mostly followed this doc https://github.com/ruby/ruby/blob/master/doc/windows.md#building-ruby-using… by simply adding the static spices. In the end I was able to generate the .a files and a ruby.exe file but I had to do a ton of manual changes to achieve this result ^^. Note: I have tried to use gcc or ldd to get the .exp file but they only make an empty .def file. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123219] [Ruby Feature#17316] On memoization
by nobu (Nobuyoshi Nakada) 11 Sep '25

11 Sep '25

Issue #17316 has been updated by nobu (Nobuyoshi Nakada). If it matters only for instance variables, a new syntax won't be needed. ```ruby instance_variable_set_unless_defined(:@foo) do some_heavy_calculation(...) end ``` or, like `Ractor.store_if_absent`: ```ruby instance_variable_set_if_absent(:@foo) do some_heavy_calculation(...) end ``` ---------------------------------------- Feature #17316: On memoization https://bugs.ruby-lang.org/issues/17316#change-114550 * 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:123212] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by briankung (Brian Kung) 11 Sep '25

11 Sep '25

Issue #12282 has been updated by briankung (Brian Kung). How about `dig_cons()`, similar to `each_cons()`? They'd be different in that the argument to `each_cons` is how large each output slice is, whereas the arguments to `dig_cons` would represent consecutive keys in a "path" (not the file path, of course). The similarity would be the idea of "consecutive" elements. The "consecutive" in `dig_cons()` would just refer to its inputs rather than its outputs. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114542 * 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:123189] [Ruby Bug#21565] YJIT has panicked in rails
by eiskrenkov (Egor Iskrenkov) 10 Sep '25

10 Sep '25

Issue #21565 has been reported by eiskrenkov (Egor Iskrenkov). ---------------------------------------- Bug #21565: YJIT has panicked in rails https://bugs.ruby-lang.org/issues/21565 * Author: eiskrenkov (Egor Iskrenkov) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I've got YJIT has panicked crash in rails app locally on my M1 Pro Mac Book pro for 2 times for last 2 weeks ``` Started GET "/api/admin/environments/13/edit" for ::1 at 2025-09-08 18:32:17 +0200 Processing by Api::Admin::EnvironmentsController#edit as JSON Parameters: {"id" => "13", "environment" => {}} ruby: YJIT has panicked. More info to follow... thread '<unnamed>' panicked at ./yjit/src/codegen.rs:5031:9: assertion failed: !val_type.is_imm() stack backtrace: 0: _rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::panic 3: yjit::codegen::jit_guard_known_klass 4: yjit::codegen::gen_equality_specialized 5: yjit::codegen::gen_opt_eq 6: yjit::codegen::gen_single_block 7: yjit::core::gen_block_series 8: yjit::core::branch_stub_hit_body 9: yjit::stats::with_compile_time 10: yjit::cruby::with_vm_lock 11: yjit::core::branch_stub_hit note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. /Users/eiskrenkov/.local/share/mise/installs/ruby/3.4.5/lib/ruby/gems/3.4.0/gems/actionpack-8.0.2.1/lib/action_dispatch/request/session.rb:118: [BUG] YJIT: panicked at ./yjit/src/codegen.rs:5031:9: assertion failed: !val_type.is_imm() ruby 3.4.5 (2025-07-16 revision 20cda200d3) +YJIT +PRISM [arm64-darwin24] ``` It happens randomly, I couldn't find reproduction steps sadly ---Files-------------------------------- ruby-2025-09-08-183231.ips (45.3 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:123207] [Ruby Bug#21568] Requiring core libraries when already requiring mutliple user defined libraries with the same name can error
by alexalexgriffith (Alex Griffith) 10 Sep '25

10 Sep '25

Issue #21568 has been reported by alexalexgriffith (Alex Griffith). ---------------------------------------- Bug #21568: Requiring core libraries when already requiring mutliple user defined libraries with the same name can error https://bugs.ruby-lang.org/issues/21568 * Author: alexalexgriffith (Alex Griffith) * Status: Open * ruby -v: ruby 3.1.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The simplest way to understand this error is that after requiring 2 or more files with the same name as some core libraries, any subsequent calls to require the core library will fail, ie ```ruby require '/Users/alex/foo/fiber' require '/Users/alex/bar/fiber' require 'fiber' ``` raises ``` cannot load such file -- fiber ``` More detailed instructions to repro this can be found in the code snippet below. Noting that I am on a Mac, OS 15.6. This is reproducible across my team on a few different OS versions, all Mac. The same underlying issue can also be seen in some other issues like: https://github.com/newrelic/newrelic-ruby-agent/issues/2001 The context this error is discovered in is that some gems may require their own libraries with the same name as core libraries, often wrapping the implementations of those core libraries to extend functionality, like the New Relic ruby agent does with fiber, for example (https://github.com/newrelic/newrelic-ruby-agent/tree/dev/lib/new_relic/agen…) Then, if 2 or more gems do something like that, and any other gem has `require 'fiber'` in it to support old ruby versions where this was necessary, the error occurs. **Full Steps to Reproduce:** ``` ruby # Setup # ===== # 1. Set this base_dir variable to be an absolute path to a dir # or something that can be found in your $LOAD_PATH. base_dir = # ex: "/Users/<you>/ruby_require_test" # 2. Within that base directory create 2 directories named `foo` and `bar` # 3. Within both `foo` and `bar` touch new files named # - complex.rb # - enumerator.rb # - fiber.rb # - rational.rb # - ruby2_keywords.rb # - set.rb # - thread.rb # Note - this list was generated by running: # `ruby -ve 'p $LOADED_FEATURES.reject { |feature| %r|/| =~ feature }'` # which returns: `["enumerator.so", "thread.rb", "fiber.so", "rational.so", "complex.so", "ruby2_keywords.rb"]` # Reproducing the error: # After requiring 2 (or more) user defined files with the same name as part of # the ruby core library that is required as a bare filename, requiring that part of # the core library will error, ex: `cannot load such file -- fiber`. # The erroring require statements are all .so files begin require "#{base_dir}/foo/complex" require "#{base_dir}/bar/complex" require 'complex' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/enumerator" require "#{base_dir}/bar/enumerator" require 'enumerator' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/fiber" require "#{base_dir}/bar/fiber" require 'fiber' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/rational" require "#{base_dir}/bar/rational" require 'rational' rescue LoadError => e puts e.message end # The following examples do not error. # The difference seems to be that the core lib files are defined as .rb not .so begin require "#{base_dir}/foo/ruby2_keywords" require "#{base_dir}/bar/ruby2_keywords" require 'ruby2_keywords' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/set" require "#{base_dir}/bar/set" require 'set' rescue LoadError => e puts e.message end begin require "#{base_dir}/foo/thread" require "#{base_dir}/bar/thread" require 'thread' rescue LoadError => e puts e.message end ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:123172] [Ruby Bug#21560] RUBY_MN_THREADS=1 causes large performance regression in Puma 7
by schneems (Richard Schneeman) 09 Sep '25

09 Sep '25

Issue #21560 has been reported by schneems (Richard Schneeman). ---------------------------------------- Bug #21560: RUBY_MN_THREADS=1 causes large performance regression in Puma 7 https://bugs.ruby-lang.org/issues/21560 * Author: schneems (Richard Schneeman) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## Expected Running a webserver with `RUBY_MN_THREADS=1` will increase performance or keep it the same. ## Actual - Before: 22919.85 Requests/sec - After: 2287.13 Requests/sec ## Reproduction Tracking this at https://github.com/puma/puma/issues/3720. I would like to get a smaller reproduction, but until then here's how we're able to induce the failure: Prepare puma: ``` $ git clone https://github.com/puma/puma $ cd puma $ git checkout v7.0.0.pre1 $ rake compile ``` Boot the server to deliver a "hello world" response: ``` $ bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` Exercise the server with `wrk` (brew install wrk): ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 ``` ### Results Before: ``` $ bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 Running 15s test @ http://localhost:9292 12 threads and 16 connections Thread Stats Avg Stdev Max +/- Stdev Latency 786.74us 1.45ms 45.57ms 90.62% Req/Sec 1.92k 188.55 4.20k 83.22% Latency Distribution 50% 386.00us 75% 523.00us 90% 2.11ms 99% 4.63ms 344638 requests in 15.04s, 25.23MB read Requests/sec: 22919.85 Transfer/sec: 1.68MB ``` After: ``` $ env RUBY_MN_THREADS=1 bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 Running 15s test @ http://localhost:9292 12 threads and 16 connections Thread Stats Avg Stdev Max +/- Stdev Latency 28.89ms 40.82ms 129.37ms 78.94% Req/Sec 207.34 64.09 252.00 70.70% Latency Distribution 50% 212.00us 75% 56.77ms 90% 99.48ms 99% 127.01ms 34365 requests in 15.03s, 2.52MB read Requests/sec: 2287.13 Transfer/sec: 171.45KB ``` (Notice the dramatic drop in requests per second). -- https://bugs.ruby-lang.org/

5 4

[ruby-core:123203] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0

[ruby-core:123202] ‍
by voicemaiI 09 Sep '25

09 Sep '25

1 0