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

[ruby-core:120043] [Ruby master Bug#20919] IO#seek does not clear the character buffer in some cases while transcoding
by javanthropus (Jeremy Bopp) 14 Apr '25

14 Apr '25

Issue #20919 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20919: IO#seek does not clear the character buffer in some cases while transcoding https://bugs.ruby-lang.org/issues/20919 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.4.0dev (2024-11-28T12:38:16Z master 3af1a04741) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When transcoding characters, `IO#seek` only clears the internal character buffer if `IO#getc` is called first: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) # Character buffer WILL NOT be cleared f.seek(2, :SET) f.getc # => 'a'.encode('utf-16le'); should be '2'.encode('utf-16le') end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind # Added a call to #getc here f.getc f.ungetc('a'.encode('utf-16le')) # Character buffer WILL be cleared now f.seek(2, :SET) f.getc # => '2'.encode('utf-16le') end ``` -- https://bugs.ruby-lang.org/

2 6

[ruby-core:120906] [Ruby master Feature#21121] Ractor channels
by luke-gru (Luke Gruber) 14 Apr '25

14 Apr '25

Issue #21121 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #21121: Ractor channels https://bugs.ruby-lang.org/issues/21121 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- # Motivation: It would be nice be able to `Ractor.yield` in a non-blocking way. Right now a `Ractor.yield` blocks until another ractor calls `r.take` on the yielding ractor. This is bad in the following scenario: ```ruby main = Ractor.current rs = 10.times.map do Ractor.new(main) do |m| ret = [] loop do # do a bunch of work that takes a while, then: begin obj = m.take rescue Ractor::ClosedError end if obj ret << obj else break end end ret end end 50.times do |i| Ractor.yield(i) # this will block until some ractor calls take on us, but it could be a while if there is processing before the `take` call. end main.close_outgoing # Ideally, we could do some work in main ractor that takes some time while the other ractors do their processing. But we're blocking right now # during all the calls to `Ractor.yield`. # Finally, get the results while rs.any? r, obj = Ractor.select(*rs) $stderr.puts "Ractor #{r} got #{obj}" rs.delete(r) end ``` I'd like other ractors to be able to do work in a "fire and forget" kind of way. It isn't possible right now due to the limitations of `Ractor.yield` and `Ractor#take`. What we need is some kind of `yield` buffer so the yielder doesn't block. I propose that Ractor channels would allow this type of programming to work. ## Example using channels: ```ruby chan = Ractor::Channel.new # We could specify buffer size like Go or it could be dynamically growable rs = 10.times.map do Ractor.new(chan) do |c| ret = [] loop do obj, _closed = c.receive # returns `[nil, true]` if `c` is closed and its buffer is empty. It blocks if the buffer is empty and `c` is not closed. if obj ret << obj else break end end ret end end 50.times do |i| chan.send(i) # non-blocking, fills a buffer and only wakes a receiver if there is one end chan.close # Do some processing while ractors do their work. # Then, collect the results while rs.any? r, obj = Ractor.select(*rs) puts "Ractor #{r} got #{obj}" rs.delete(r) end ``` With an API similar to this, we could have "fire and forget" processing with ractors. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:116555] [Ruby master Feature#20233] pkg-config not working on MSVC
by jmarrec (Julien Marrec) 13 Apr '25

13 Apr '25

Issue #20233 has been reported by jmarrec (Julien Marrec). ---------------------------------------- Feature #20233: pkg-config not working on MSVC https://bugs.ruby-lang.org/issues/20233 * Author: jmarrec (Julien Marrec) * Status: Open * Priority: Normal ---------------------------------------- The PKG_CONFIG variable is not respected in win32/Makefile.sub Also, need to ideally use the `--msvc-syntax` flag (pkgconf 1.4.0, released 7 years ago, adds it). But mostly, I realized that the `try_ldflags` in `lib/mkmf.rb` actually passes these ldflags as the `opt` parameter to the `link_command` function, and not as `ldflags`. While the UNIX systems are forgiving, the MSVC compiler is not, and because the flags are passed before the `-link`, MSVC complains that it ignores it and therefore cannot find the requested library. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121066] [Ruby master Bug#21141] `Time#utc?` does not work with a timezone object
by nobu (Nobuyoshi Nakada) 09 Apr '25

09 Apr '25

Issue #21141 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21141: `Time#utc?` does not work with a timezone object https://bugs.ruby-lang.org/issues/21141 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby require 'timezone' require 'tzinfo' t = Time.now(in: "UTC") t_timezone = Time.now(in: Timezone["UTC"]) t_tzinfo = Time.now(in: TZInfo::Timezone.get("UTC")) p t.utc? #=> true p t_timezone.utc? #=> false p t_tzinfo.utc? #=> false ``` This also affects `strftime("%-z")`. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116666] [Ruby master Bug#20255] Embedded arrays aren't moved correctly across ractors
by luke-gru (Luke Gruber) 07 Apr '25

07 Apr '25

Issue #20255 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20255: Embedded arrays aren't moved correctly across ractors https://bugs.ruby-lang.org/issues/20255 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `ractor.send(ary, move: true)` works incorrectly because if `ary` is embedded, the new moved object doesn't populate its own embedded space, it uses the MovedObject's embedded space. example: ```ruby r = Ractor.new { inner_ary = receive values = {} values[:equal] = (inner_ary == ["",{},2,3,4,5,6]) values[:string] = inner_ary.to_s values } ary = [String.new,Hash.new,2,3,4,5,6] r.send(ary, move: true) r_values = r.take p r_values[:equal] p r_values[:string] # => false # => "[\"\", {}, 2, 2.0, 21747991570, String, 3]" ``` -- https://bugs.ruby-lang.org/

3 17

[ruby-core:120613] [Ruby master Bug#21027] `not()` receiver should be `nil`
by kddnewton (Kevin Newton) 06 Apr '25

06 Apr '25

Issue #21027 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #21027: `not()` receiver should be `nil` https://bugs.ruby-lang.org/issues/21027 * Author: kddnewton (Kevin Newton) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `not` has a 0-argument mode, and the behavior differs from that of parse.y: ``` % RBENV_VERSION=3.4.0 ruby --parser=parse.y -e 'p not()' true % RBENV_VERSION=3.4.0 ruby --parser=prism -e 'p not()' false ``` This is because Prism interprets `not()` as `self.!` where parse.y interprets it as `nil.!`. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120414] [Ruby master Bug#20984] ENV.inspect is not encoding aware
by nobu (Nobuyoshi Nakada) 02 Apr '25

02 Apr '25

Issue #20984 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20984: ENV.inspect is not encoding aware https://bugs.ruby-lang.org/issues/20984 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```console $ ruby -e 'ENV.clear; ENV["\u{3042}"] = "a"; p ENV.inspect.encoding' #<Encoding:BINARY (ASCII-8BIT)> ``` -- https://bugs.ruby-lang.org/

3 6

[ruby-core:120895] [Ruby master Bug#21117] Inconsistent behaviour between "_1" and "it" variables
by radarek 30 Mar '25

30 Mar '25

Issue #21117 has been reported by radarek (Radosław Bułat). ---------------------------------------- Bug #21117: Inconsistent behaviour between "_1" and "it" variables https://bugs.ruby-lang.org/issues/21117 * Author: radarek (Radosław Bułat) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I believe variables `_1` and `it` should have consistent behaviour and the same as normal local variables. Here are inconsistencies: ```ruby # 1. Assigning new value [1, 2, 3].each { |v| v = v + 1; p v } # works as expected [1, 2, 3].each { it = it + 1; p it } # works as expected [1, 2, 3].each { _1 = _1 + 1; p _1 } # SyntaxError # 2. Using operators like += on them [1, 2, 3].each { |v| v += 1; p v } # works as expected [1, 2, 3].each { it += 1; p it } # SyntaxError but I expected it to work correctly after 1st point [1, 2, 3].each { _1 += 1; p _1 } # works, which is inconsistent with 1 point # however, this one does not work [1, 2, 3].map { _1 += 1 } # runtime error is raised: undefined method '+' for nil (NoMethodError) ``` If both `_1` and `it` are advertised as block local variables then I would expect that overwriting works correctly, both using expressions like `_1 = _1 + 1` and `_1 *= 2`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:120808] [Ruby master Bug#21094] Module#set_temporary_name does not affect a name of a nested module
by andrykonchin (Andrew Konchin) 29 Mar '25

29 Mar '25

Issue #21094 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21094: Module#set_temporary_name does not affect a name of a nested module https://bugs.ruby-lang.org/issues/21094 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Wondering whether it's intentional and correct behaviour: ```ruby m = Module.new m::N = Module.new p m::N.name # => "#<Module:0x000000010d0a00b0>::N" m.set_temporary_name("foo") p m::N.name # => "#<Module:0x000000010d0a00b0>::N" ``` I would expect that setting `foo` as a temporary name changes `m::N.name` to `foo::N`. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114410] [Ruby master Bug#19841] Marshal.dump stack overflow with recursive Time
by segiddins (Samuel Giddins) 29 Mar '25

29 Mar '25

Issue #19841 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19841: Marshal.dump stack overflow with recursive Time https://bugs.ruby-lang.org/issues/19841 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` ruby #!/usr/bin/env ruby puts RUBY_VERSION t = Time.at(0, 1, :nanosecond) t.instance_variable_set :@itself, t Marshal.dump(t) ``` Yields a stack overflow error from the `Marshal.dump` call, even though Marshal is explicitly able to handle cyclical references -- https://bugs.ruby-lang.org/

6 8