April 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:116026] [Ruby master Bug#20151] Can't build Ruby 3.1 on FreeBSD 14.0
by hsbt (Hiroshi SHIBATA) 21 May '24

21 May '24

Issue #20151 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20151: Can't build Ruby 3.1 on FreeBSD 14.0 https://bugs.ruby-lang.org/issues/20151 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I couldn't install Ruby 3.1.3 on FreeBSD 14.0. ``` compiling util.c util.c:255:1: error: expected identifier or '(' ruby_qsort(void* base, const size_t nel, const size_t size, cmpfunc_t *cmp, void *d) ^ ./include/ruby/util.h:124:21: note: expanded from macro 'ruby_qsort' # define ruby_qsort qsort_r ^ /usr/include/stdlib.h:356:5: note: expanded from macro 'qsort_r' __generic(arg5, int (*)(void *, const void *, const void *), \ ^ /usr/include/sys/cdefs.h:322:2: note: expanded from macro '__generic' _Generic(expr, t: yes, default: no) ^ 1 error generated. *** Error code 1 Stop. ``` Compiler version is here: ``` FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) ``` I could install Ruby 3.2.2. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114070] [Ruby master Bug#19753] IO::Buffer#get_string can't handle negative offset
by noteflakes (Sharon Rosner) 18 May '24

18 May '24

Issue #19753 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Bug #19753: IO::Buffer#get_string can't handle negative offset https://bugs.ruby-lang.org/issues/19753 * Author: noteflakes (Sharon Rosner) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby irb(main):001:0> b = IO::Buffer.for('abc') => #<IO::Buffer 0x00007f858f5450c0+3 EXTERNAL READONLY SLICE> ... irb(main):002:0> b.get_string(-1) => "\x00abc" irb(main):003:0> b.get_string(-1000, 3) (irb):3:in `get_string': Specified offset+length exceeds data size! (ArgumentError) from (irb):3:in `<main>' from /home/sharon/.rbenv/versions/3.2.0/lib/ruby/gems/3.2.0/gems/irb-1.7.1/exe/irb:9:in `<top (required)>' from /home/sharon/.rbenv/versions/3.2.0/bin/irb:25:in `load' from /home/sharon/.rbenv/versions/3.2.0/bin/irb:25:in `<main>' ``` Using a negative offset returns garbage in the string but it also might segfault: ```ruby irb(main):003:0> b = IO::Buffer.map(File.open('sgt-nodes.sql', 'r+')) => #<IO::Buffer 0x00007f189de14000+2008858 EXTERNAL MAPPED SHARED> irb(main):004:0> b.get_string(-1000) (irb):4: [BUG] Segmentation fault at 0x00007f189de13c18 ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0021 p:---- s:0109 e:000108 CFUNC :get_string ... ``` ## Expected behaviour I think it might be nice to have `#get_string` behave like other methods taking an offset, like `String#[]`. For example: ```ruby irb(main):001:0> b = IO::Buffer.for('abc') => #<IO::Buffer 0x00007f858f5450c0+3 EXTERNAL READONLY SLICE> ... irb(main):002:0> b.get_string(-1) => "c" irb(main):003:0> b.get_string(-2) => "bc" irb(main):003:0> b.get_string(-1000) => "abc" irb(main):003:0> b.get_string(-1000, 2) => "ab" ``` -- https://bugs.ruby-lang.org/

5 9

[ruby-core:112304] [Ruby master Bug#19427] Marshal.load(source, freeze: true) doesn't freeze in some cases
by andrykonchin (Andrew Konchin) 16 May '24

16 May '24

Issue #19427 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19427: Marshal.load(source, freeze: true) doesn't freeze in some cases https://bugs.ruby-lang.org/issues/19427 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I've noticed that the `freeze` option doesn't work in the following cases: - when dumped object extends a module - when dumped object responds to `#marshal_dump` and `#marshal_load` methods - when dumped object responds to `#_dump` method Is it expected behaviour or a known issue? Examples: ```ruby module M end object = Object.new object.extend(M) object = Marshal.load(Marshal.dump(object), freeze: true) object.frozen? # => false ``` ```ruby class UserMarshal attr_accessor :data def initialize @data = 'stuff' end def marshal_dump() :data end def marshal_load(data) @data = data end end object = Marshal.load(Marshal.dump(UserMarshal.new), freeze: true) object.frozen? # => false ``` ```ruby class UserDefined attr_reader :a, :b def initialize @a = 'stuff' @b = @a end def _dump(depth) Marshal.dump [:stuff, :stuff] end def self._load(data) a, b = Marshal.load data obj = allocate obj.instance_variable_set :@a, a obj.instance_variable_set :@b, b obj end end ``` -- https://bugs.ruby-lang.org/

5 13

[ruby-core:112873] [Ruby master Bug#19530] `Array#sum` and `Enumerable#sum` sometimes show different behaviours
by dstosik (David Stosik) 16 May '24

16 May '24

Issue #19530 has been reported by dstosik (David Stosik). ---------------------------------------- Bug #19530: `Array#sum` and `Enumerable#sum` sometimes show different behaviours https://bugs.ruby-lang.org/issues/19530 * Author: dstosik (David Stosik) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi everyone. 👋🏻 We recently discovered that `Array#sum` and `Enumerable#sum` will output different results in some edge cases. Here's the smallest script I managed to write to reproduce the issue: ``` ruby class Money def initialize(amount) @amount = amount.to_f end def +(other) self.class.new(@amount + other.to_f) end def to_f @amount end end p [7.0].each.sum(Money.new(0)).class #=> Money p [7.0] .sum(Money.new(0)).class #=> Float 💥 ``` I understand that it is expected that `#sum` may not honor custom definitions of the `#+` method (particularly when the summed values are `Float`). However, I would like to bring your attention to the fact that, in the example above, calling `#sum` on an `Array` of `Float` values and calling `#sum` on an `Enumerable` that yields the same `Float` values will return results of different types. I've reproduced the same behaviour with multiple versions of Ruby going from 2.6.5 to 3.2.1. Ideally, I would expect `[7.0].sum(Money.new(0))` to return a `Money` object identical to the one returned by `[7.0].each.sum(Money.new(0))`. I think it would make sense if at least they returned an identical value (even if it is a `Float`). -- https://bugs.ruby-lang.org/

3 3

[ruby-core:114403] [Ruby master Feature#19840] [Proposal] Expand Find pattern to Multiple Find
by FlickGradley (Nick Bradley) 15 May '24

15 May '24

Issue #19840 has been reported by FlickGradley (Nick Bradley). ---------------------------------------- Feature #19840: [Proposal] Expand Find pattern to Multiple Find https://bugs.ruby-lang.org/issues/19840 * Author: FlickGradley (Nick Bradley) * Status: Open * Priority: Normal ---------------------------------------- Hello! I love Ruby's pattern matching features. I would like to propose an expansion of the Find pattern which allows the selection of multiple matching elements of an array. I often find myself dealing with data like this: ``` ruby { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }, ... ] } ``` My problem is that I need to retrieve all the `id` values from the nested array of hashes, and I don't know how many there will be in advance. It seems that the Find pattern could be expanded from allowing `pattern` (matching a single element) to `*pattern`. Examples: ``` ruby # Base case case { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }] } in results: [*{ id: ids }] "matched: #{ids}" else "not matched" end #=> matched: [1, 2] # With * at the end (rest of args) - same result case { results: [{ id: 1, name: "foo" }, { id: 2, name: "bar" }] } in results: [*{ id: ids }, *] "matched: #{ids}" else "not matched" end #=> matched: [1, 2] # When one element doesn't match and there is no *rest case { results: [{ name: "foo" }, { id: 2, name: "bar" }] } in results: [*{ id: ids }] "matched: #{ids}" else "not matched" end #=> not matched ``` Similarly, `*Constant` could work to pull out types with an As pattern: ``` ruby case [1, 2, 3, "string"] in *Integer => nums, * "matched: #{nums}" else "not matched" end #=> matched: [1, 2, 3] ``` Other patterns would work in the same way. Essentially, this expands the concept of `*` in pattern matching to mean "a variable number of `things matching subpattern`". Today, the only pattern supported by `*` is a variable binding - but it could be any of the other subpatterns as well. This proposal does imply that this would work: ``` ruby a = 2 [1, 2, 2, 3] in [*, *^a, *] #=> true ``` To me, the `*` represents the variable number of matches, so the syntax makes intuitive sense. But others may have different opinions about `*^` being adjacent. It may also imply this would work, though we could restrict the number of non-variable patterns (in other words, patterns that have the possibility of not matching) to 1 per Array so that this isn't possible.. I'm not sure something like this would be useful or clear. ``` ruby a = 2 [1, 2, "hello", "ruby"] in [*Integer, *String] #=> true ``` This feature feels like the missing piece of the Find pattern to me - I often want to "Find Multiple". If others agree, I would be happy to contribute by working on this feature and creating a pull request. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117497] [Ruby master Bug#20424] ZLib::GZipReader always double allocates strings when passed outbuf, significantly increasing memory usage
by martinemde (Martin Emde) 14 May '24

14 May '24

Issue #20424 has been reported by martinemde (Martin Emde). ---------------------------------------- Bug #20424: ZLib::GZipReader always double allocates strings when passed outbuf, significantly increasing memory usage https://bugs.ruby-lang.org/issues/20424 * Author: martinemde (Martin Emde) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In trying to improve the memory performance during the install of rubygems, we previously found a bug in `eof?`. Further investigation into the memory usage during the fix for this bug found wasteful allocating of strings in readpartial and read. In ZLib, when reading with readpartial or read, a new string is always created for the bytes read from the buffer. The current approach allocates a string no matter if there is an outbuf passed. ``` # vastly simplified psuedo implementation def readpartial(len, dst=nil) if (buffer.empty?) buffer = gzipfile.readpartial(len, dst) # adds inflated bytes into dst if passed end dst = allocate_new_string(len) # make a new string for the destination dst << buffer.read(len) # read from the buffer into the destination end ``` The result is that readpartial always allocated at least double the bytes necessary. Samuel Giddins submitted, and I have tested and reviewed, [a pull request, zlib#61](https://github.com/ruby/zlib/pull/61) that resolves the issue and vastly improves the memory usage and increases the speed of GZipReader by avoiding excess memcpy and rb_str_new calls that were wasted. This PR also adds an outbuf to GZipReader#read for improvement memory management, very similar to [IO#read](https://ruby-doc.org/core-2.5.1/IO.html#method-i-read) We appreciate your attention to this performance improvement. We believe it will further improve the performance of rubygems gem installs. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:117494] [Ruby master Bug#20421] String#index and String#byteindex don't clear `$~` when offset > size (or bytesize)
by andrykonchin (Andrew Konchin) 14 May '24

14 May '24

Issue #20421 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20421: String#index and String#byteindex don't clear `$~` when offset > size (or bytesize) https://bugs.ruby-lang.org/issues/20421 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When String#index and String#byteindex are called with Regexp and offset they clear `$~` (that contains result of the last Regexp matching) when offset < -size. But they don't clear `$~` when offset > size what seems not consistent: ```ruby "a".index(/a/) p $~ # => #<MatchData "a"> string = "blablabla" string.index(/bla/, string.length + 1) p $~ # => #<MatchData "a"> ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:117588] [Ruby master Misc#20436] DevMeeting at RubyKaigi 2024
by ko1 (Koichi Sasada) 13 May '24

13 May '24

Issue #20436 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Misc #20436: DevMeeting at RubyKaigi 2024 https://bugs.ruby-lang.org/issues/20436 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- RubyKaigi 2024 will be at Okinawa, Japan, May 15th - 17th. We would like to try to hold a face-to-face dev meeting at Okinawa. (@matz will also participate!) * Date: 2023/05/14 (Tue.) 14:00-18:00 (The day before RubyKaigi) * Location: SAKURA innobase Okinawa, Haseko Naha Building 1F, 1-2-13 Matsuyama, Naha City, Okinawa * Near by RubyKaigi venue (not a RubyKaigi venue). * Japanese page: https://www.sakura.ad.jp/innobase/ ### Program * 1:45pm door open * 2:00pm opening and self introduction * 2:30pm discuss topics * 5:00pm closing and free time (closing time is depends on topics) * 5:50pm door close There are several RubyKaigi related events after that so let's continue on the party: * [RubyKaigi 2024 前夜祭 Asakusa.rb Welcome Drinkup - connpass](https://andpad.connpass.com/event/313590/) ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. Please write your name on this spreadsheet to count the number of participants. https://docs.google.com/spreadsheets/d/1qXuvXvigP80CFNwseJDKm2YNkpQmzSg9WSI… ### Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/05/10. I'll ask Matz which should be discussed on this meeting and reorder them. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

10 13

[ruby-core:116940] [Ruby master Feature#20300] Hash: set value and get pre-existing value in one call
by AMomchilov (Alexander Momchilov) 11 May '24

11 May '24

Issue #20300 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #20300: Hash: set value and get pre-existing value in one call https://bugs.ruby-lang.org/issues/20300 * Author: AMomchilov (Alexander Momchilov) * Status: Open ---------------------------------------- When using a Hash, sometimes you want to set a new value, *and* see what was already there. Today, you **have** to do this in two steps: ```ruby h = { k: "old value" } # 1. Do a look-up for `:k`. old_value = h[:k] # 2. Do another look-up for `:k`, even though we just did that! h[:k] = "new value" use(old_value) ``` This requires two separate `Hash` look-ups for `:k`. This is fine for symbols, but is expensive if computing `#hash` or `#eql?` is expensive for the key. It's impossible to work around this today from pure Ruby code. I propose adding `Hash#update_value`, which has semantics are similar to this Ruby snippet: ```ruby class Hash def update_value(key, new_value) old_value = self[key] self[key] = new_value old_value end end ``` ... except it'll be implemented in C, with modifications to `tbl_update` that achieves this with a hash-lookup. Here's a PR with a PoC implementation: https://github.com/ruby/ruby/pull/10092 -- https://bugs.ruby-lang.org/

8 18

[ruby-core:117680] [Ruby master Bug#20451] Bad Ruby 3.1.5 backport causes fiddle to fail to build
by Bo98 (Bo Anderson) 01 May '24

01 May '24

Issue #20451 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #20451: Bad Ruby 3.1.5 backport causes fiddle to fail to build https://bugs.ruby-lang.org/issues/20451 * Author: Bo98 (Bo Anderson) * Status: Open * ruby -v: 3.1.5p252 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby 3.1.5 shipped with the following backport: https://github.com/ruby/ruby/commit/84f2aabd272a54e79979795d2d405090704a1d07 However this backport directly breaks the build: ``` closure.c:279:60: error: use of undeclared identifier 'data' result = ffi_prep_closure(pcl, cif, callback, (void *)(data->self)); ^ ``` The original commit (https://github.com/ruby/fiddle/commit/2530496602) was updating the second branch to match the change in the first branch a couple lines up. However that change in the other branch does not exist in Ruby 3.1. The commit in question requires a previous commit of https://github.com/ruby/fiddle/commit/81a8a56239973ab7559229830a449d201955b…. The backport should either be reverted or an other commit should also be backported. Note that these commits were in a series of many commits made to fix an upstream issue https://github.com/ruby/fiddle/issues/102 so I cannot vouch whether or not the two commits are sufficient to fix the originally reported issue. -- https://bugs.ruby-lang.org/

3 4