May 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113238] [Ruby master Misc#19599] DevMeeting-2023-05-10
by mame (Yusuke Endoh) 20 Jun '23

20 Jun '23

Issue #19599 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19599: DevMeeting-2023-05-10 https://bugs.ruby-lang.org/issues/19599 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/05/10 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # 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/07. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - 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/

14 13

[ruby-core:113715] [Ruby master Bug#19701] The rb_classext_t::classpath field is not marked for T_ICLASS
by wks (Kunshan Wang) 18 Jun '23

18 Jun '23

Issue #19701 has been reported by wks (Kunshan Wang). ---------------------------------------- Bug #19701: The rb_classext_t::classpath field is not marked for T_ICLASS https://bugs.ruby-lang.org/issues/19701 * Author: wks (Kunshan Wang) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I am hacking Ruby to dump information about some objects, and I found that the `rb_classext_t::classpath` field for `T_ICLASS` objects sometimes contains dangling references to dead objects. The commit https://github.com/ruby/ruby/commit/081cc4eb283cb01ddffb364397e5175dbfacab66 set the `classpath` field of `rb_mRubyVMFrozenCore` to a string "FrozenCore" so that it can be dumped using the `rb_dump_literal` function. However, in `gc_mark_children`, if the `obj` is a `T_ICLASS`, the `RCLASS_EXT(obj)->classpath` will not be marked. As a result, if `rb_mRubyVMFrozenCore` is the only object that holds a reference to the string "FrozenCore", the string will be considered garbage and reclaimed during a GC, and the `classpath` will contain a dangling pointer. There are two solutions to this problem. We can take *one* of the approaches below (not both). 1. Let the GC mark the `classpath` field. I drafted a pull request here: https://github.com/ruby/ruby/pull/7875 2. Revert the commit https://github.com/ruby/ruby/commit/081cc4eb283cb01ddffb364397e5175dbfacab66 Marking the `classpath` field in GC will keep the `rb_dump_literal` function working. For debug purposes, we can also use that field to identify what object a given `T_ICLASS` is. Adding one marked field may make GC slower, but I don't think it will be observable because there are far less `T_ICLASS` objects than ordinary objects. If we reverting the commit above, the `classpath` will always be blank for all `T_ICLASS` objects. (Question: How do we enforce it?) It will also save some memory by keeping less strings alive. However, currently, "FrozenCore" seems to be the only `T_OBJECT` that has its classpath set, and it may not result in significant memory saving. I don't know what purpose the `rb_dump_literal` function originally served. Maybe it is still important. Maybe it is safe to remove now. Which of the two approaches should we take? It looks like each of them has its pros and cons. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:113529] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named
by byroot (Jean Boussier) 11 Jun '23

11 Jun '23

Issue #19681 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19681: The final classpath of partially named modules is sometimes inconsistent once permanently named https://bugs.ruby-lang.org/issues/19681 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 3.0: WONTFIX, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Reported to me by @fxn ```ruby m = Module.new class m::C; end p m::C.name # => "#<Module:0x000000010789fbe0>::C" m::D = m::C p m::D.name # => "#<Module:0x000000010789fbe0>::C" M = m p M::C.name # => "#<M::D" ``` Expected behavior: ```ruby p M::C.name # => "#<M::C" ``` ### Reason When the parent is assigned its permanent classpath, we iterate over its `const_table` to recursively give a permanent name to all the constant it owns. However, `const_table` is an `id_table` so it doesn't retain the insertion order, which means that if the constant was aliased, we can no longer distinguish between the original name and its aliases, and whichever comes first in the `const_table` will be used as the permanent name. ### Potential solution I have a tentative fix for it in https://github.com/ruby/ruby/pull/7829. Instead of relying on the `const_table` key, it extract the original name from the temporary classpath. It does feel a bit wrong to do a string search in such a place, but it does work. -- https://bugs.ruby-lang.org/

7 33

[ruby-core:113660] [Ruby master Feature#19694] Add Regexp#timeout= setter
by aharpole (Aaron Harpole) 09 Jun '23

09 Jun '23

Issue #19694 has been reported by aharpole (Aaron Harpole). ---------------------------------------- Feature #19694: Add Regexp#timeout= setter https://bugs.ruby-lang.org/issues/19694 * Author: aharpole (Aaron Harpole) * Status: Open * Priority: Normal ---------------------------------------- # Abstract In addition to allowing for a Regexp timeout to be set on individual instances by setting a `timeout` argument in `Regexp.new`, I'm proposing that we also allow setting the timeout on Regexp objects with a `#timeout=` setter. # Background To be able to roll out a global Regexp timeout for a large application, there are inevitably some individual regexes for which a different timeout is appropriate. While the `timeout` keyword argument was added to `Regexp.new`, this isn't always a viable option. In the case of regex literal syntax (`/ab*/` or `%r{ab*}`, for instance), it's not possible to set a timeout at all right now without converting to `Regexp.new`, which may be awkward depending on the contents of the regex. It also is desirable from time to time to be able to set a timeout for a regex object after it's been initialized. Finally, because we offer a `Regexp#timeout` getter, for consistency it would be nice to also offer a setter. The introduction of a `Regexp#timeout=` setter was mentioned as a possible way to set individual timeouts in https://bugs.ruby-lang.org/issues/19104#Specification. # Proposal I propose that we add the method `Regexp#timeout=`. It works the same way the `timeout` argument works in `Regexp.new`, taking either a float or nil. This makes it relatively easy to add timeouts to specific regex literals (regex literals are frozen by default so you do have to `dup` them first): ``` emoji_filter_pattern = %r{ (?<!#{Regexp.quote(ZERO_WIDTH_JOINER)}) #{EmojiFilter.unicodes_pattern} (?!#{Regexp.union(EmojiFilter::MODIFIER_CHAR_MAP.keys.map { |k| Regexp.quote k })}) }x.dup emoji_filter_pattern.timeout = 1.0 emoji_filter_pattern.freeze ``` # Implementation This setter has been implemented in https://github.com/ruby/ruby/pull/7847. # Evaluation It's just a setter, so pretty straightforward in terms of implementation and use. # Discussion It's worth considering other options for overriding `Regexp.timeout`. I'd love to see something like the following for overriding regexp timeouts as well: ``` Regexp.timeout = 1.0 Regexp.with_timeout(5.0) do evaluate_slower_regexes end ``` It's possible to implement something like `Regexp.with_timeout` but it's not thread-safe by default since it would involve overwriting `Regexp.timeout`. # Summary Regexp instances have a getter for timeout, and adding a corresponding setter adds consistency and will make it easier for developers to adopt adding a global `Regexp.timeout` by making it simpler to adjust timeouts on a regex by regex basis. It's a minor change but the added consistency and flexibility help us optimize for developer happiness. -- https://bugs.ruby-lang.org/

9 14

[ruby-core:113716] [Ruby master Bug#19702] Promote racc as bundled gems
by hsbt (Hiroshi SHIBATA) 08 Jun '23

08 Jun '23

Issue #19702 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19702: Promote racc as bundled gems https://bugs.ruby-lang.org/issues/19702 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In the past, we need to bundle `racc` runtime for RD parser of RDoc. Now, We have racc compiler and runtime in ruby repository. I'm not sure we should bundle and maintain `racc` as stdlib in the future. Can we promote `racc` to bundled gems? -- https://bugs.ruby-lang.org/

2 5

[ruby-core:112770] [Ruby master Feature#19520] Support for `Module.new(name)` and `Class.new(superclass, name)`.
by ioquatix (Samuel Williams) 08 Jun '23

08 Jun '23

Issue #19520 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19520: Support for `Module.new(name)` and `Class.new(superclass, name)`. https://bugs.ruby-lang.org/issues/19520 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- See <https://bugs.ruby-lang.org/issues/19450> for previous discussion and motivation. [This proposal](https://github.com/ruby/ruby/pull/7376) introduces the `name` parameter to `Class.new` and `Module.new`: ```ruby Class.new(superclass, name) Module.new(name) ``` As a slight change, we could use keyword arguments instead. -- https://bugs.ruby-lang.org/

8 41

[ruby-core:113587] [Ruby master Misc#19684] DevMeeting-2023-06-08
by mame (Yusuke Endoh) 08 Jun '23

08 Jun '23

Issue #19684 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19684: DevMeeting-2023-06-08 https://bugs.ruby-lang.org/issues/19684 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/06/08 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # 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/06/05. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - 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/

6 5

[ruby-core:113714] [Ruby master Bug#19700] TestProcess#test_execopts_redirect_open_fifo_interrupt_print is flaky on macOS
by kjtsanaktsidis (KJ Tsanaktsidis) 07 Jun '23

07 Jun '23

Issue #19700 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #19700: TestProcess#test_execopts_redirect_open_fifo_interrupt_print is flaky on macOS https://bugs.ruby-lang.org/issues/19700 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The test `TestProcess#test_execopts_redirect_open_fifo_interrupt_print` in `test_process.rb` is flaky on macOS for me. Sometimes, it just hangs forever. This test is testing what happens when: * You have two processes * One is blocked opening a FIFO for reading (to redirect to a child process) * The other one sends a signal to that process * And then opens the FIFO for writing (which should unblock the child process) When this test hangs forever, for me, * The child process is blocked on opening the FIFO (i.e. it's waiting for a writer) * But the parent process successfully wrote data to the FIFO already somehow (this shouldn't be possible - the parent should have been blocked opening the FIFO until the open succeeded in the child). Actually I believe this is a bug in macOS. The following program will fail with `write (parent): Broken pipe` on macOS when run in a loop, but works correctly on Linux: https://gist.github.com/KJTsanaktsidis/fc84b006cfff1bb0b55a2571df825d80 I'm going to open a PR to skip this test on macos because I believe the operating system is broken here, and as far as I can tell Ruby is doing the correct thing. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:113656] [Ruby master Misc#19693] Data initialization is significantly slower than Struct
by janosch-x 03 Jun '23

03 Jun '23

Issue #19693 has been reported by janosch-x (Janosch Müller). ---------------------------------------- Misc #19693: Data initialization is significantly slower than Struct https://bugs.ruby-lang.org/issues/19693 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal ---------------------------------------- Maybe there is potential to make it as fast as Struct? ```ruby require 'benchmark/ips' S = Struct.new(:a, :b, :c, :d, :e, :f, :g, :h, :i, :j) D = Data.define(:a, :b, :c, :d, :e, :f, :g, :h, :i, :j) Benchmark.ips do |x| x.report('Struct') { S.new(1, 2, 3, 4, 5, 6, 7, 8, 9, 10) } x.report('Data') { D.new(1, 2, 3, 4, 5, 6, 7, 8, 9, 10) } x.compare! end; 1 # => [...] # => Struct: 6916530.4 i/s # => Data: 1507259.5 i/s - 4.59x slower ``` -- https://bugs.ruby-lang.org/

5 12

[ruby-core:111264] [Ruby master Feature#19197] Add Exception#root_cause
by AMomchilov (Alexander Momchilov) 03 Jun '23

03 Jun '23

Issue #19197 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #19197: Add Exception#root_cause https://bugs.ruby-lang.org/issues/19197 * Author: AMomchilov (Alexander Momchilov) * Status: Open * Priority: Normal ---------------------------------------- ## Description I would like to add a `#root_cause` method to `Exception`. It returns the last exception in linked-list of causality chain, that is, the original exception (whose own `cause` is `nil`). ## Example ```ruby e = begin raise 'a' # This is the root cause rescue => a begin raise 'b' rescue => b begin raise 'c' # This is the outermost cause assigned to `e` rescue => c c end end end p(e) # => #<RuntimeError: c> p(e.cause) # => #<RuntimeError: b> p(e.cause.cause) # => #<RuntimeError: a> p(e.cause.cause.cause) # => nil p(e.root_cause) # => #<RuntimeError: a> p(e.root_cause.cause) # => nil ``` # Motivation There are some kinds of exceptions that can occur all over the place (and might be wrapped by arbitrarily many middlemen), but are attributable to a singular global cause. For example, a database outage could raise exceptions in almost every line of business logic of an app that uses ActiveRecord models. Fundamentally, you wouldn't want an error report for every one of these lines. You'd want to look at the root cause, and bucket all SQL-connection issues into a single report, regardless of where they surface. ### Implementation Draft PR: https://github.com/ruby/ruby/pull/6913 -- https://bugs.ruby-lang.org/

4 7