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

[ruby-core:112772] [Ruby master Bug#9366] "make -j32 check TESTS=-j32" occasionally fails on rubygems/specification
by hsbt (Hiroshi SHIBATA) 09 Mar '23

09 Mar '23

Issue #9366 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Feedback @normalperson Do you still have this issue? ---------------------------------------- Bug #9366: "make -j32 check TESTS=-j32" occasionally fails on rubygems/specification https://bugs.ruby-lang.org/issues/9366#change-102267 * Author: normalperson (Eric Wong) * Status: Feedback * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 2.2.0dev (2014-01-05 trunk 44507) [x86_64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- This only happens occasionally, maybe 1 out of 10 times during "make check", so it's probably a bug somewhere with GC. I'll try to reproduce without parallel tests (could take a while). It seems to reproduce more easily on slower machine. I initially thought it was a bug in cachelined, but I can also reproduce it with plain trunk. /home/ew/ruby/lib/rubygems/specification.rb:748:in `block in _resort!': undefined method `name' for nil:NilClass (NoMethodError) /home/ew/ruby/lib/rubygems/specification.rb:747:in `sort!' /home/ew/ruby/lib/rubygems/specification.rb:747:in `_resort!' /home/ew/ruby/lib/rubygems/specification.rb:699:in `_all' /home/ew/ruby/lib/rubygems/specification.rb:882:in `each' /home/ew/ruby/lib/rubygems/dependency.rb:284:in `find_all' /home/ew/ruby/lib/rubygems/dependency.rb:284:in `to_specs' /home/ew/ruby/lib/rubygems/dependency.rb:309:in `to_spec' /home/ew/ruby/lib/rubygems/core_ext/kernel_gem.rb:53:in `gem' /home/ew/ruby/lib/rubygems/package_task.rb:25:in `<top (required)>' /home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require' /home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require' /home/ew/ruby/test/rubygems/test_gem_package_task.rb:3:in `<top (required)>' /home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require' /home/ew/ruby/lib/rubygems/core_ext/kernel_require.rb:55:in `require' /home/ew/ruby/lib/test/unit/parallel.rb:114:in `run' /home/ew/ruby/lib/test/unit/parallel.rb:183:in `<main>' Some worker was crashed. It seems ruby interpreter's bug or, a bug of test/unit/parallel.rb. try again without -j option. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112494] [Ruby master Feature#19450] Is there an official way to set a class name without setting a constant?
by ioquatix (Samuel Williams) 09 Mar '23

09 Mar '23

Issue #19450 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19450: Is there an official way to set a class name without setting a constant? https://bugs.ruby-lang.org/issues/19450 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- This is the best I could come up with: ```ruby klass = Class.new Object.const_set("Klass", klass) Object.send(:remove_const, "Klass") puts klass.new # => #<Klass:0x0000000100a9d688> ``` Can we do better? -- https://bugs.ruby-lang.org/

9 26

[ruby-core:112771] [Ruby master Feature#16431] Optionally load did_you_mean (and RubyGems)
by hsbt (Hiroshi SHIBATA) 09 Mar '23

09 Mar '23

Issue #16431 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Feature #16431: Optionally load did_you_mean (and RubyGems) https://bugs.ruby-lang.org/issues/16431#change-102266 * Author: vo.x (Vit Ondruch) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I just have opened PR [1], which allows Ruby to run when did_you_mean is not available. As I previously discussed in #16427, there are cases when speed, memory, disk or network bandwidth is a concern and did_you_mean is not useful for runtime. This is especially useful when Ruby is installed via packaging systems of (Linux) distributions. The PR is split into 4 commits, because since I was there, I prepared similar changes to RubyGems. [1]: https://github.com/ruby/ruby/pull/2764 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112767] [Ruby master Bug#18658] Need openssl 3 support for Ubuntu 22.04 (Ruby 2.7.x and 3.0.x)
by hsbt (Hiroshi SHIBATA) 09 Mar '23

09 Mar '23

Issue #18658 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected We decided to not backport openssl-3.x gem into `ruby_2_7` and `ruby_3_0` branches. Because it affects with OpenSSL 1.0.x. Unfortunately, the users should upgrade their ruby version to 3.1+ before upgrading their OS version. ---------------------------------------- Bug #18658: Need openssl 3 support for Ubuntu 22.04 (Ruby 2.7.x and 3.0.x) https://bugs.ruby-lang.org/issues/18658#change-102262 * Author: schneems (Richard Schneeman) * Status: Rejected * Priority: Normal * Assignee: usa (Usaku NAKAMURA) * ruby -v: 3.0 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Ubuntu 22.04 is being released soon and ships with openssl 3. As of now Ruby 2.7.x and 3.0.x are under core support and will not build on Ubuntu 22.04 with openssl (Ruby 3.1.x can compile). When attempting to compile 3.0.3 on Ubuntu 22 it issues this warning: ``` *** Following extensions are not compiled: openssl: Could not be configured. It will not be installed. /ruby-3.0.3/ext/openssl/extconf.rb:113: OpenSSL >= 1.0.1, < 3.0.0 or LibreSSL >= 2.5.0 is required Check ext/openssl/mkmf.log for more details. ``` Here are some existing issues/PRs that I could find: - https://github.com/ruby/openssl/issues/369 - https://github.com/ruby/openssl/pull/399 Ideally I would like to compile and support all non-EOL Ruby versions for Ubuntu 22 on release day. Are there any plans to backport support for OpenSSL 3 to Ruby 3.0 and 2.7? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112763] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by ko1 (Koichi Sasada) 09 Mar '23

09 Mar '23

Issue #18743 has been updated by ko1 (Koichi Sasada). Assignee set to ko1 (Koichi Sasada) ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-102258 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112762] [Ruby master Feature#19094] `sleep(nil)` vs `sleep()` and replicating the default implementation.
by matz (Yukihiro Matsumoto) 09 Mar '23

09 Mar '23

Issue #19094 has been updated by matz (Yukihiro Matsumoto). I understand the usefulness of the proposal. Accepted. But do not propose other changes just for consistency with this change. Matz. ---------------------------------------- Feature #19094: `sleep(nil)` vs `sleep()` and replicating the default implementation. https://bugs.ruby-lang.org/issues/19094#change-102255 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- ``` > sleep(nil) (irb):1:in `sleep': can't convert NilClass into time interval (TypeError) ``` However, I feel that this makes implementing a compatible sleep method a little difficult. ```ruby def sleep(time = nil) if time sleep_some(time) else sleep_forever end end ``` Can we consider allowing `sleep(nil)` and `sleep(false)` to be the same as `sleep()` to simplify this behaviour? Otherwise, it's hard to proxy (e.g. fiber scheduler, or even just a plain old variable argument). e.g. ```ruby class Sleeper def initialize(time = nil) @time = time end def sleep Kernel::sleep(@time) # Hard to get the behaviour of `sleep()` here without explicitly handling/checking. end end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112755] [Ruby master Bug#19519] Merge RubyGems-3.4.8 and Bundler-2.4.8 into Ruby 3.2
by hsbt (Hiroshi SHIBATA) 09 Mar '23

09 Mar '23

Issue #19519 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19519: Merge RubyGems-3.4.8 and Bundler-2.4.8 into Ruby 3.2 https://bugs.ruby-lang.org/issues/19519 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: naruse (Yui NARUSE) * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- https://github.com/ruby/ruby/pull/7479 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112656] [Ruby master Feature#19472] Ractor::Selector to wait multiple ractors
by ko1 (Koichi Sasada) 09 Mar '23

09 Mar '23

Issue #19472 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #19472: Ractor::Selector to wait multiple ractors https://bugs.ruby-lang.org/issues/19472 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Target version: 3.3 ---------------------------------------- This ticket propose `Ractor::Selector` API to wait multiple ractor events. Now, if we want to wait for taking from r1, r2 and r3, we can use `Ractor.select()` like that. ```ruby r, v = Ractor.select(r1, r2, r3) p "taking an object #{v} from #{r}" ``` With proposed `Ractor::Selector` API, we can write the following: ```ruby selector = Ractor.selector.new(r1, r2) # make a waiting set with r1 and r2 selector.add(r3) # we can add r3 to the waiting set after that. selector.add(r4) selector.remove(r4) # we can remove r4 from the waiting set. r, v = selector.wait p "taking an object #{v} from #{r}" ``` * `Ractor::Selector.new(*ractors)`: create a selector * `Ractor::Selector#add(r)`: add `r` to the waiting list * `Ractor::Selector#remove(r)`: remove `r` from the waiting list * `Ractor::clear`: remove all ractors from the waiting list * `Ractor::wait`: wait for the ractor events The advantages from `Ractor.select` is: * (1) (API design) We can preset the waiting set before waiting. Providing unified way to manage waiting list seems better. * (2) (Performance) It is lighter than passing an array object to the `Ractor.select(*rs)` if `rs` is bigger and bigger. For (2), it is important to supervise thousands of ractors. `Ractor::Selector#wait` also has additional features: * `wait(receive: true)` also waits receiving. * `Ractor.select(*rs, Ractor.current)` does same, but I believe `receive: true` keyword is more direct to understand. * `wait(yield_value: obj, move: true/false)` also waits yielding. * Same as `Ractor.select(yield_value: obj, move: true/false)` * If a ractor `r` is closing, then `#wait` removes `r` automatically. * If there is no waiting ractors, it raises an exception (now `Ractor::Error` is raised but it should be a better exception class) With automatic removing, we can write the code to wait n tasks. ```ruby rs = n.times.map{ Ractor.new{ do_task } } selector = Ractor::Selector.new(*rs) loop do r, v = selector.wait handle_answers(r, v) rescue Ractor::Error p :all_tasks_done end ``` Without auto removing, we can write the following code. ```ruby rs = n.times.map{ Ractor.new{ do_task } } selector = Ractor::Selector.new(*rs) loop do r, v = selector.wait handle_answers(r, v) rescue Ractor::ClosedError => e selector.remove e.ractor rescue Ractor::Error p :all_tasks_done end # or on this case worker ractors only yield one value (at exit) so the following code works as well. loop do r, v = selector.wait handle_answers(r, v) selector.remove r rescue Ractor::Error p :all_tasks_done end ``` I already merged it but I want to discuss about the spec. Discussion: * The name `Selector` is acceptable? * Auto-removing seems convenient but it can hide the behavior. * allow auto-removing * allow auto-removing as configurable option * per ractor or per selector * which is default? * disallow auto-removing * What happens on no taking ractors * raise an exception (which exception?) * return nil simply maybe and more... -- https://bugs.ruby-lang.org/

3 4

[ruby-core:112741] [Ruby master Feature#19484] Calling `binding` on a C-level proc raises an `ArgumentError`
by joel＠drapper.me (Joel Drapper) 08 Mar '23

08 Mar '23

Issue #19484 has been reported by joel(a)drapper.me (Joel Drapper). ---------------------------------------- Feature #19484: Calling `binding` on a C-level proc raises an `ArgumentError` https://bugs.ruby-lang.org/issues/19484 * Author: joel(a)drapper.me (Joel Drapper) * Status: Open * Priority: Normal ---------------------------------------- Calling `binding` on a C-level proc (from `&:symbol`) raises an `ArgumentError`, "Can't create Binding from C level Proc" but there is no way to tell if a given proc is a C-level proc before calling `binding` on it. It’s possible to rescue this error, but rescuing an exception is slow. Given that a C-level proc doesn't have a binding, would it make more sense to respond to `binding` with `nil` rather than raise an error? That would allow us to, for example, look up the receiver and fall back to self, e.g. `block.binding&.receiver || self`. Alternatively, it would be useful to be able to check whether a given proc is a C-Level proc using something like this. ```ruby case block when CProc block.call(self) else block.call end ``` An example use case is an interface that takes a hash of conditions and tokens. If the condition is valid, we do something with the token. Otherwise, we ignore it. ```ruby some_interface(-> { true } => "foo", -> { false } => "bar" ) ``` With literal Procs, it makes sense to call them and check their truthiness. ```ruby def some_interface(**conditional_tokens) conditional_tokens.each do |condition, token| do_something_with(token) if condition.call end end ``` When given C-Level procs, it makes sense to call them with `self` to evaluate the corresponding method. ```ruby some_interface(&:foo? => "foo", &:bar? => "bar" ) ``` ```ruby def foo? = true def bar? = false def some_interface(**conditional_tokens) conditional_tokens.each do |condition, token| case condition when CProc do_something_with(token) if condition.call(self) else do_something_with(token) if condition.call end end end ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112333] [Ruby master Feature#19432] Introduce a wrapping operator (&) to Proc
by joel＠drapper.me (Joel Drapper) 08 Mar '23

08 Mar '23

Issue #19432 has been reported by joel(a)drapper.me (Joel Drapper). ---------------------------------------- Feature #19432: Introduce a wrapping operator (&) to Proc https://bugs.ruby-lang.org/issues/19432 * Author: joel(a)drapper.me (Joel Drapper) * Status: Open * Priority: Normal ---------------------------------------- I don't know if this concept exists under another name, or whether there’s a technical term for it. I often find myself wanting to wrap a proc in another proc. Here's a snippet from a recent example where a visitor class renders a TipTap AST. Given a `text` node, we want to output the text by calling the `text` method with the value. But if the text has `marks`, we want to iterate through each mark, wrapping the output for each mark. It's possible to do this using the `>>=` operator if each proc explicitly returns another proc. ```ruby when "text" result = -> { -> { text node["text"] } } node["marks"]&.each do |mark| case mark["type"] when "bold" result >>= -> (r) { -> { strong { r.call } } } when "italic" result >>= -> (r) { -> { em { r.call } } } end end result.call.call end ``` This is quite difficult to follow and the `result.call.call` feels wrong. I think the concept of wrapping one proc in another proc would make for a great addition to `Proc` itself. I prototyped this using the `&` operator. ```ruby class Proc def &(other) -> { other.call(self) } end end ``` With this definition, we can call `&` on the original proc with our other proc to return a new proc that calls the other proc with the original proc as an argument. It also works with `&=`, so the above code can be refactored to this: ```ruby when "text" result = -> { text node["text"] } node["marks"]&.each do |mark| case mark["type"] when "bold" result &= -> (r) { strong { r.call } } when "italic" result &= -> (r) { em { r.call } } end end result.call end ``` -- https://bugs.ruby-lang.org/

4 4