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

[ruby-core:122847] [Ruby Feature#21520] Feature Proposal: Enumerator::Lazy#peek
by nuzair46 (Nuzair Rasheed) 17 Mar '26

17 Mar '26

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 14

[ruby-core:124892] [Ruby Feature#21929] Add configure script options for instrumenting Rust builds
by jprokop (Jarek Prokop) 17 Mar '26

17 Mar '26

Issue #21929 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Feature #21929: Add configure script options for instrumenting Rust builds https://bugs.ruby-lang.org/issues/21929 * Author: jprokop (Jarek Prokop) * Status: Open ---------------------------------------- Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT. Rust is a compiled language with various compile flags at various stages and approaches. My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions can be fully and easily compliant with their guidelines on compilation flags. Currently, for production build of Ruby, `rustc` tool is used, which is instrumented differently from `cargo` in debug builds. In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695 I have focused on providing `rustc` with our distribution flags, during the PR it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 that should be present even when providing distribution flags. This is not too different from C, as there are also security flags, such as configure script enabling the arm64's BTI and PAC when possible. `rustc` of version 1.92, at the time of the PR uses the last mention of a flag. Ideally `rustc` would know `RUSTFLAGS`, but as far as I can tell, the enviroment variable only affects `cargo`. In Fedora the current guidance recommends using `%build_rustflags` https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_f… which expands to `-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn` The best result is each part of Rust in Ruby would receive the flags defined during `configure` time. In cases where complication flags should conflict, in Fedora distribution flags take precedence: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_w… -- https://bugs.ruby-lang.org/

3 3

[ruby-core:124797] [Ruby Feature#21875] Handling of trailing commas in lambda parameters
by Earlopain (Earlopain _) 16 Mar '26

16 Mar '26

Issue #21875 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #21875: Handling of trailing commas in lambda parameters https://bugs.ruby-lang.org/issues/21875 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- https://bugs.ruby-lang.org/issues/19107 was accepted, which is about trailing commands in method definitions. lambdas were not explicitly mentioned but I wanted to confirm how they should behave with a trailing comma. Or if a trailing comma should even be accepted for them. It's not clear to me since lambdas sometimes behave like blocks and sometimes more like methods. `->(...) {}` for example is syntax invalid (same as in blocks) but they do check their arity with blocks don't do. If a trailing comma is accepted it can either * be implicit splat like in `foo do |bar,|; end` or `foo do |bar|; end`. It would also mean that the trailing comma is only allowed after a positional argument. * Just be ignored and be accepted in most places like for method definitions. The first option would be rather useless in regards to https://bugs.ruby-lang.org/issues/19107 when you just want to add the comma for cleaner diffs. But I guess for lambdas this happens very rarely anyways. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124677] [Ruby Feature#21861] C API: expose `ruby_xfree_sized`, `ruby_xrealloc_sized`, etc
by byroot (Jean Boussier) 16 Mar '26

16 Mar '26

Issue #21861 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21861: C API: expose `ruby_xfree_sized`, `ruby_xrealloc_sized`, etc https://bugs.ruby-lang.org/issues/21861 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context For the longest time now, Ruby had internal API such as `ruby_sized_xfree`, `ruby_sized_xrealloc` and `ruby_sized_xrealloc2`. These are identical to their non-sized counterpart, expect they accept the original size of the buffer being free or reallocated. This information is then fed to the garbage collector to improve heuristics as to when GC should run (`malloc_increase_bytes` and `oldmalloc_increase_bytes`). When the old buffer size isn't provided, Ruby tries to obtain it via `malloc_usable_size`, which isn't available on all platform, but also isn't quite correct as it's generally over reporting. It also happen to be quite slow on some allocators, such as `mallocng`, the allocator used by `muslc` hence by alpine linux. ### C23 `free_sized` The C23 standard added the `free_sized(void *ptr, size_t oldsize)` API, and it's now available in `glibc 2.43`, other popular allocators like `jemalloc` and `tcmalloc` also have it since a few years. Original spec: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2699.htm Interestingly the standard doesn't include a `realloc_sized` API, I'm unsure why. For most allocators, providing the size to `free_sized` allow to skip some step and provide a speedup. I've read some 30% claims, but I haven't benchmarked myself. One thing to note is that according to the standard, passing the wrong size is undefined behavior: > If ptr is the result obtained from a call to `malloc(size)`, `realloc(old_ptr, size)`, or `calloc(nmemb, memb_size)`, where `nmemb * memb_size` is equal to `size`, this function behaves equivalently to `free(ptr)`. Otherwise, the result is undefined. Recently I refactored most internal calls to `xfree` inside Ruby itself to use `ruby_sized_xfree` instead, and would like to have it use `free_sized` when available. Also when `RUBY_DEBUG` is defined, `xmalloc` does register the original allocated size, and enforce that the size provided to `ruby_sized_xfree` does match. This allowed to uncover several small bugs, notably in `string.c` where we'd sometime end up with an incorrect `capacity` attribute after an encoding change. ### Benefits Aside from the performance gains on some allocators, and the gains from having more accurate GC statistics, I believe these sized interfaces help ensure correctness of the code. Except for a few exceptions, most code dealing with a buffer must know its size to avoid going out of bound, so providing it to `ruby_xfree_sized` allows to assert the size was correctly tracked in debug builds. I also believe ASAN or UBSAN are likely to also enforce this soon (if they don't already), so it could help catch more bugs early. ### Proposal I would like to expose these sized APIs to C extensions, so that they can benefit from it as well: - `void ruby_xfree_sized(void *ptr, size_t oldsize)` - `void *ruby_xrealloc_sized(void *ptr, size_t newsize, size_t oldsize)` - `void *ruby_xrealloc2_sized(void *ptr, size_t n, size_t size, size_t old_n)` I also think I would be useful to expose the corresponding macros: - `RB_REALLOC_SIZED_N` - `RB_SIZED_FREE` (shorthand to free a simple pointer: `ruby_xfree_sized(ptr, sizeof(*ptr))`). - `RB_SIZED_FREE_N` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124877] [Ruby Misc#21924] Register a Maven artifact for JVM-related libraries
by headius (Charles Nutter) 16 Mar '26

16 Mar '26

Issue #21924 has been reported by headius (Charles Nutter). ---------------------------------------- Misc #21924: Register a Maven artifact for JVM-related libraries https://bugs.ruby-lang.org/issues/21924 * Author: headius (Charles Nutter) * Status: Open ---------------------------------------- For the Prism project, I am working toward having published artifacts for JVM users (like JRuby or TruffleRuby). Publishing these packages will make it much easier for us to support Prism in JRuby, both as our interal Ruby parser and as an installable gem. We do not copy sources into our repository, and *must* be able to point a release artifact that can be tracked through supply chain tooling etc. In order to publish artifacts, we need to register the `org.ruby-lang` namespace with Sonatype, maintainers of Maven Central (the primary source of JVM-based software packages). The process is detailed here: https://central.sonatype.org/register/namespace/ The simple description of the process follows: 1. Register an account on Sonatype. I already have one for JRuby and other JVM projects. 2. Register the namespace. I have posted an initial request for the `org.ruby-lang` namespace. 3. Verify the namespace. This requires DNS help as described on the above page and in the screenshot below. 4. Publish artifacts to the namespace. The first artifact would be named something like `prism-ruby-parser`, so its "coordinates" would be `org.ruby-lang:prism-ruby-parser:0.0.1`. I need: * Someone who can update the DNS entry to include the key needed by Sonatype for verification. * A list of users who should potentially have push rights for this namespace. I don't expect anyone but JRuby committers and possibly TruffleRuby committers will be using this namespace. For the moment I will be publishing the artifacts I need under the `org.jruby` namespace, but because there's very little JRuby-specific logic in the core Prism JVM wrapper library, I would prefer to publish it under the `org.ruby-lang` domain. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 16 Mar '26

16 Mar '26

Issue #21925 has been reported by knu (Akinori MUSHA). ---------------------------------------- Bug #21925: Prism misparses standalone "in" pattern matching in "case/in" https://bugs.ruby-lang.org/issues/21925 * Author: knu (Akinori MUSHA) * Status: Open * Target version: 4.1 * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Prism misparses standalone `in` pattern matching in `case/in` when the left-hand side is a method call with a dot receiver ## Summary When a standalone `expr in pattern` one-line pattern match appears inside a `case/in` branch, and `expr` is a method call with a dot receiver (for example, `obj.method`), Prism incorrectly parses `in pattern` as a new branch of the outer `case/in` instead of treating it as a `MatchPredicateNode`. The parse.y parser handles this case correctly. ## Reproduction ``` $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] ``` It also reproduces on Ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]. ### Minimal script ```ruby x = "x" case x in Integer nil in String p :before x.itself in String p :after end ``` ### Command output ``` $ ruby -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before $ ruby --parser=parse.y -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before :after ``` ### Expected behavior (parse.y) Both `:before` and `:after` are printed. `x.itself in String` is parsed as a standalone pattern match (predicate) inside the `in String` branch. ### Actual behavior (Prism) Only `:before` is printed; `p :after` is never executed. ## Analysis Prism splits `x.itself in String` at the `in` keyword, treating `x.itself` as the last statement of the `in String` branch and `in String` as a third branch of the outer `case/in`. The following script shows how each parser interprets the `case/in` branches: ```ruby code = <<~RUBY x = "x" case x in Integer nil in String x.itself in String p :after end RUBY # Prism require "prism" ast = Prism.parse(code).value.statements.body[1] puts "Prism: conditions: #{ast.conditions.length}" ast.conditions.each_with_index do |c, i| pat = c.pattern name = pat.respond_to?(:name) ? pat.name : pat.class stmts = c.statements&.body&.map { |s| s.class.name.split("::").last } || [] puts " in[#{i}]: pattern=#{name}, body=#{stmts}" end # parse.y (Ripper) require "ripper" sexp = Ripper.sexp(code) case_node = sexp[1][1] def count_in_branches(node) return [] unless node.is_a?(Array) && node[0] == :in pattern_node = node[1] body = node[2] || [] name = pattern_node.is_a?(Array) && pattern_node[1].is_a?(Array) ? pattern_node[1][1] : pattern_node[1] stmts = body.map { |s| s[0].to_s } [{ pattern: name, body: stmts }] + count_in_branches(node[3]) end branches = count_in_branches(case_node[2]) puts "\nparse.y (Ripper): conditions: #{branches.length}" branches.each_with_index do |b, i| puts " in[#{i}]: pattern=#{b[:pattern]}, body=#{b[:body]}" end ``` Output (run with `ruby --parser=parse.y` so Ripper uses parse.y): ``` Prism: conditions: 3 in[0]: pattern=Integer, body=["NilNode"] in[1]: pattern=String, body=["CallNode"] in[2]: pattern=String, body=["CallNode"] parse.y (Ripper): conditions: 2 in[0]: pattern=Integer, body=["var_ref"] in[1]: pattern=String, body=["case", "command"] ``` Prism reports 3 branches, while parse.y reports 2. In the parse.y result, `in[1]` correctly contains both the inner expression (`x.itself in String` parsed as a standalone pattern match) and the `command` (`p :after`). In the Prism result, `x.itself` becomes the sole body of `in[1]`, and `in String` is misinterpreted as a new `in[2]` branch of the outer `case`. ## Consideration From experimentation, the issue appears to be triggered only when all of the following are true: 1. The outer `case/in` has at least two `in` branches before the affected branch. 2. The standalone `in` expression uses a dot-receiver method call as its left-hand side, such as `obj.method in Pattern`. Conditions where this behavior is not observed: - If the expression is a receiver-less call, such as `f(x) in Pattern`, the parser keeps it as a standalone pattern match. - If the receiver expression is parenthesized, such as `(obj.method) in Pattern`, the parser keeps it as a standalone pattern match. - If you assign first, such as `y = obj.method; y in Pattern`, the parser keeps it as a standalone pattern match. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 16 Mar '26

16 Mar '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:124888] [Ruby Bug#21927] Prism: misleading error message for forwarding in lambda argument
by nobu (Nobuyoshi Nakada) 16 Mar '26

16 Mar '26

Issue #21927 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21927: Prism: misleading error message for forwarding in lambda argument https://bugs.ruby-lang.org/issues/21927 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: prism * ruby -v: d256629bf9 * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Even in a forwarding method: ```console $ ruby --parser=prism -e 'def m(...) ->(...){}; end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m(...) ->(...){}; end | ^~~ unexpected ... when the parent method is not forwarding ``` This message is proper for method arguments: ```console $ ruby --parser=prism -e 'def m() p(...); end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m() p(...); end | ^~~ unexpected ... when the parent method is not forwarding ``` The message from parse.y is different; "unexpected ... in lambda argument": ```console $ ruby --parser=parse.y -e 'def m(...) ->(...){}; end' -e:1: unexpected ... in lambda argument def m(...) ->(...){}; end ruby: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120819] [Ruby master Bug#21097] `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism
by tompng (tomoya ishida) 16 Mar '26

16 Mar '26

Issue #21097 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21097: `x = a rescue b in c` and `def f = a rescue b in c` parsed differently between parse.y and prism https://bugs.ruby-lang.org/issues/21097 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ruby x = a rescue b in c (x = (a rescue b)) in c # parse.y, prism(ruby 3.4) x = (a rescue (b in c)) # prism(ruby 3.5) ~~~ ~~~ruby def f = a rescue b in c #=> true(parse.y), :f(prism) (def f = (a rescue b)) in c # parse.y def f = (a rescue (b in c)) # prism ~~~ There is no difference between prism and parse.y parsing these codes ~~~ruby a rescue b in c # a rescue (b in c) x = a rescue b # x = (a rescue b) x = b in c # (x = b) in c def f = a rescue b # def f = (a rescue b) def f = b in c # (def f = a) in b ~~~ -- https://bugs.ruby-lang.org/

9 12

[ruby-core:124848] [Ruby Bug#21917] Unable to build 4.0.1 on AIX 7.2
by mhashizume (Michael Hashizume) 16 Mar '26

16 Mar '26

Issue #21917 has been reported by mhashizume (Michael Hashizume). ---------------------------------------- Bug #21917: Unable to build 4.0.1 on AIX 7.2 https://bugs.ruby-lang.org/issues/21917 * Author: mhashizume (Michael Hashizume) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm attempting to build Ruby 4.0.1 on AIX 7.2. We have had successful builds of previous versions of Ruby on this platform, but are starting to see an issue when using miniruby to build Ruby: ``` shell ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./powerpc64-aix7.2.0.0-fake ./tool/rbinstall.rb --make="gmake" --dest-dir="" --extout=".ext" --ext-build-dir="./ext" --mflags="-j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --make-flags=" -j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --data-mode=0644 --prog-mode=0755 --installed-list .installed.list --mantype="man" --install=all --exclude=doc /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImplementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` I'm not sure where the NotImplementedError is coming from, and when looking at the `truss` output from miniruby, I see a ENOTTY when miniruby attempts to load monitor.so: ```shell accessx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0, 0) = 0 statx("/", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFA680, 176, 011) = 0 __ksetjmp(0x0000000110019F88, 0x09000000026845A8, 2, 0x000000011001A1D8, 0x0FFFFFFFFFFFB790, 0x0000000022242202, 0x000000011011A658, 0x09000 00000260348) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFB800, 176, 0) = 0 kioctl(2, 22528, 0x0000000000000000, 0x0000000000000000) Err#25 ENOTTY /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImpl ementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` monitor.so is present in the path that miniruby is looking for it. Any pointers on where to start debugging this further or what changes in more recent versions of Ruby could have caused this would be greatly appreciated. Thank you! -- https://bugs.ruby-lang.org/

3 4