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

[ruby-core:122917] [Ruby Feature#21532] Define most of Pathname in Ruby code
by Eregon (Benoit Daloze) 05 Aug '25

05 Aug '25

Issue #21532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21532: Define most of Pathname in Ruby code https://bugs.ruby-lang.org/issues/21532 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: Eregon (Benoit Daloze) ---------------------------------------- There was discussion in #17473 and before to define most of Pathname in Ruby code and not in the C extension. I have made a PR to achieve that: https://github.com/ruby/pathname/pull/57 I would like to merge it soon to avoid conflicts. Once upon a time, Pathname was pure-Ruby: https://github.com/ruby/ruby/blob/95bc02237635d3fe42532bfe53038257575cee75/… This PR goes back to that, and reuses that original Ruby code, but keeps the C extension implementation of `<=>` and `sub` as those two are significantly faster. The other Pathname methods are actually faster in Ruby than in C, because all these methods just do `rb_funcall()` and `rb_ivar_get()` and those in C code have no inline cache, but the corresponding method calls and `@path` have inline caches in Ruby code. https://railsatscale.com/2023-08-29-ruby-outperforms-c/ is an explanation of that. Therefore having Pathname defined in Ruby seems a clear win for many reasons: * Much clearer implementation, so easier to read what the code does * Easier to maintain * Safer (no risk of accessing out of bounds memory or e.g. passing the wrong number of arguments to `rb_funcall`) * Actually faster, because of these inline caches, see numbers at the end of https://github.com/ruby/pathname/pull/57#issue-3234862768 * Better for JITs as they can optimize this, notably `...` vs the C extension being a blackbox * Works on JRuby (which does not support C extensions) * Faster on TruffleRuby (where a C extension for this is inefficient as it causes needless Ruby->C->Ruby transitions) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122910] [Ruby Bug#21530] Is IO#eof? supposed to always block and read?
by tenderlovemaking (Aaron Patterson) 05 Aug '25

05 Aug '25

Issue #21530 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21530: Is IO#eof? supposed to always block and read? https://bugs.ruby-lang.org/issues/21530 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm not sure whether or not this is expected behavior, but it seems like eof? blocks when called on $stdin. For example: ```ruby if (str = $stdin.gets) $stderr.puts "read #{str}" end if $stdin.eof? # this call waits for input $stderr.puts "stdin is eof" end ``` I think this is kind of odd behavior because if you input a string but _do not_ input a newline, then hit ^D twice, `$stdin` should be at EOF, but `eof?` will block and wait for input. If you hit ^D a third time, $stdin will be EOF, but if you input a different character it will not be EOF. Compare this C program: ```c #include <stdio.h> #include <stdlib.h> #define BUF_SIZE 4096 int main(int argc, char *argv[]) { char buf[BUF_SIZE]; if (fgets(buf, BUF_SIZE, stdin)) { fprintf(stderr, "read %s\n", buf); } if (feof(stdin)) { // Does not block fprintf(stderr, "stdin is EOF\n"); } } ``` If you hit ^D twice with this C program, `feof` will return true for `stdin`. I would have expected the Ruby program and the C program to behave similarly, but they don't. Is this expected? The documentation indeed says that `eof?` will read, but shouldn't the IO be at EOF after the second ^D? Thank you. -- https://bugs.ruby-lang.org/

3 3

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

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

3 7

[ruby-core:122900] [Ruby Bug#21529] Deprecate the /o modifier and warn against using it
by jpcamara (JP Camara) 04 Aug '25

04 Aug '25

Issue #21529 has been reported by jpcamara (JP Camara). ---------------------------------------- Bug #21529: Deprecate the /o modifier and warn against using it https://bugs.ruby-lang.org/issues/21529 * Author: jpcamara (JP Camara) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I recently ran into a bug in some code because it was using the /o modifier as an optimization, not realizing it created a permanent, immutable value after the first time it gets evaluated. I dug into how the modifier works in CRuby and the history of it here: https://jpcamara.com/2025/08/02/the-o-in-ruby-regex.html. The feature seems like a total footgun with almost no upside. If I run a benchmark between a local regex, and a regex cached by /o, there is no real difference. ```rb require "benchmark" def letters "A-Za-z" end words = %w[the quick brown fox jumped over the lazy dog] Benchmark.bm do |bm| bm.report("without /o:") do regex = /\A[A-Za-z]+\z/ words.each do |word| word.match(regex) end end bm.report("with /o: ") do words.each do |word| word.match(/\A[#{letters}]+\z/o) end end end ``` Most of the time I found that "without /o" actually came out ahead. ``` user system total real without /o: 0.000019 0.000003 0.000022 ( 0.000014) with /o: 0.000020 0.000001 0.000021 ( 0.000020) ``` I'd like to deprecate the feature and update the docs to warn against using it. I'd be happy to submit a PR doing that. Thanks! -- https://bugs.ruby-lang.org/

3 5

[ruby-core:122899] [Ruby Bug#21528] SyntaxError#message may have broken encoding with multibyte source under Prism
by alpaca-tc (Hiroyuki Ishii) 04 Aug '25

04 Aug '25

Issue #21528 has been reported by alpaca-tc (Hiroyuki Ishii). ---------------------------------------- Bug #21528: SyntaxError#message may have broken encoding with multibyte source under Prism https://bugs.ruby-lang.org/issues/21528 * Author: alpaca-tc (Hiroyuki Ishii) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Since the introduction of Prism, when parsing Ruby source code that contains multibyte characters, SyntaxError#message can sometimes have invalid encoding. Here is a reproducible example: ``` begin RubyVM::InstructionSequence.compile(<<~CODE, nil, nil, 1) if a # 0000000000000ああああああ # CODE rescue SyntaxError => e $e = e puts e.message # string contains a multibyte character that is cut off mid-byte. \xE3 # <compiled>:3: syntax errors found # 1 | if a # > 2 | # 0000000000000あああああ\xE3 ... # | ^ expected an `end` to close the conditional clause # > 3 | # # | ^ unexpected end-of-input, assuming it is closing the parent top level context puts e.message.valid_encoding? #=> expected true, but got false end ``` This appears to be caused by a truncation process in prism's error message generating that does not consider multibyte character boundaries. See: The truncation logic around [prism_compile.c L10696-L10709](https://github.com/ruby/ruby//blob/30a20bc166bc37acd7dcb3788… I'm not sure how to correctly fix it due to lack of knowledge about safe byte truncation. I discovered this issue through irb, which attempts to display source code even when it contains syntax errors. Because irb uses `SyntaxError#message`, it raised an `ArgumentError: invalid byte sequence in UTF-8`. See: https://github.com/ruby/irb/blob/f60dfa8549f746f69e9a6d160604a7a4974ffac1/l… If this is considered an irb issue, I already have a patch for IRB that handles it. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122817] [Ruby Bug#21517] Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial
by herwin (Herwin W) 03 Aug '25

03 Aug '25

Issue #21517 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21517: Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial https://bugs.ruby-lang.org/issues/21517 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] (+ others) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The specs for `IO#readpartial` have the following test (https://github.com/ruby/spec/blob/ed254bae321221f5cd24280beb37e5bddaff6bb6/…) ```ruby before :each do @rd, @wr = IO.pipe @rd.binmode @wr.binmode end it "reads after ungetc with multibyte characters in the buffer" do @wr.write("∂φ/∂x = gaîté") c = @rd.getc @rd.ungetc(c) @rd.readpartial(3).should == "\xE2\x88\x82" @rd.readpartial(3).should == "\xCF\x86/" end ``` This behaviour is different in `StringIO#readpartial`. If I add this as a spec: ```ruby it "reads after ungetc with multibyte characters in the buffer" do @string = StringIO.new(+"∂φ/∂x = gaîté") c = @string.getc @string.ungetc(c) @string.readpartial(3).should == "\xE2\x88\x82" @string.readpartial(3).should == "\xCF\x86/" end ``` it fails with every supported Ruby version, and even with 3.5-dev of today, with the message `Expected "\xE2\x88\x82" == "∂"` The `getc` + `ungetc` can be removed, but this does not change the behaviour. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:122897] [Ruby Feature#21526] cryptocurrency & cybersecurity
by umershafique89＠gmail.com (Muhammad umar) 01 Aug '25

01 Aug '25

Issue #21526 has been reported by umershafique89(a)gmail.com (Muhammad umar). ---------------------------------------- Feature #21526: cryptocurrency & cybersecurity https://bugs.ruby-lang.org/issues/21526 * Author: umershafique89(a)gmail.com (Muhammad umar) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122892] [Ruby Bug#21525] Inconsistent execution order for methods with constant blocks
by joel＠drapper.me (Joel Drapper) 01 Aug '25

01 Aug '25

Issue #21525 has been reported by joel(a)drapper.me (Joel Drapper). ---------------------------------------- Bug #21525: Inconsistent execution order for methods with constant blocks https://bugs.ruby-lang.org/issues/21525 * Author: joel(a)drapper.me (Joel Drapper) * Status: Open * ruby -v: ruby 3.4.5 (2025-08-01 revision 07f7832cff) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- If you call a method and pass in a splat of an array with a block argument coerced from calling a method, Ruby maintains the expected execution order and the called method receives a copy of the array prior to modification. In this example, the output is `[1, 2, 3]` since the copy is made before the `bar` method can modify it. ```ruby ARRAY = [1, 2, 3] def bar ARRAY.pop -> {} end def example(*args, &) puts args end example(*ARRAY, &bar) ``` However, when passing a constant, the block coercion itself is able to modify the array. ```ruby ARRAY = [1, 2, 3] module Foo module Bar def self.to_proc ARRAY.pop -> {} end end end def example(*args, &) puts args end example(*ARRAY, &Foo::Bar) ``` Another way to trigger this is to define a `const_missing` method that modifies the array. ```ruby ARRAY = [1, 2, 3] module Foo def self.const_missing(name) ARRAY.pop -> {} end end def example(*args, &) puts args end example(*ARRAY, &Foo::Bar) ``` In both these cases, the output is `[1, 2]` instead of the expected `[1, 2, 3]`. -- https://bugs.ruby-lang.org/

2 2