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

[ruby-core:121589] New contributor
by Matteo Nicoli 08 Apr '25

08 Apr '25

Hi everybody, I am new to this community, and I would like to contribute to the development of Ruby. Although I’m not a very experienced Ruby programmer, I’ve been developing in C for several years. I was wondering if any experienced contributors could suggest some “good first issue” (either bugfix or feature) that I could work on. I couldn’t find this label on the Ruby Issues portal. Thank you for your time. Best regards, Matteo

1 0

[ruby-core:121587] [Ruby Feature#16993] Sets: from hash keys using Hash#key_set
by Dan0042 (Daniel DeLorme) 08 Apr '25

08 Apr '25

Issue #16993 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-9: > Given the convention of deriving methods such as `key_set` from `keys`, where the former returns a set instead of an array, one might expect a corresponding derivation like `Kernel#instance_variable_set` for `Kernel#instance_variables`. Unfortunately, this would conflict with an existing method name. In https://github.com/ruby/set/pull/40 the name was changed to #keys_to_set, so this comment doesn't apply anymore. Then again I wish all optimizations like this could be implemented at the VM level, so that `hash.keys.to_set` would automatically be efficient rather than having to explicitly use the efficient version #keys_to_set. ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-112642 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121586] Email Error (Action Needed)
by Administrator ml.ruby-lang.org 08 Apr '25

08 Apr '25

1 0

[ruby-core:121570] [Ruby Feature#16993] Sets: from hash keys using Hash#key_set
by mame (Yusuke Endoh) 08 Apr '25

08 Apr '25

Issue #16993 has been updated by mame (Yusuke Endoh). Given the convention of deriving methods such as `key_set` from `keys`, where the former returns a set instead of an array, one might expect a corresponding derivation like `Kernel#instance_variable_set` for `Kernel#instance_variables`. Unfortunately, this would conflict with an existing method name. ---------------------------------------- Feature #16993: Sets: from hash keys using Hash#key_set https://bugs.ruby-lang.org/issues/16993#change-112627 * Author: marcandre (Marc-Andre Lafortune) * Status: Open ---------------------------------------- To create a set from hash keys currently implies a temporary array for all keys, rehashing all those keys and rebuilding a hash. Instead, the hash could be copied and its values set to `true`. ```ruby h = {a: 1} # Now: Set.new(h.keys) # => Set[:a] # After h.key_set # => Set[:a], efficiently. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121451] [Ruby Bug#21201] Performance regression when defining methods inside `refine` blocks
by alpaca-tc (Hiroyuki Ishii) 07 Apr '25

07 Apr '25

Issue #21201 has been reported by alpaca-tc (Hiroyuki Ishii). ---------------------------------------- Bug #21201: Performance regression when defining methods inside `refine` blocks https://bugs.ruby-lang.org/issues/21201 * Author: alpaca-tc (Hiroyuki Ishii) * Status: Open * ruby -v: 3.3.7, 3.4.2, 3.5.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- After the change introduced in [PR #10037](https://github.com/ruby/ruby/pull/10037), a significant performance regression has been observed when defining methods within refine blocks. The PR correctly fixes a bug where `callcache` invalidation was missing when methods are defined inside a refinement. To fix this, it now invokes [`rb_clear_all_refinement_method_cache()`](https://github.com/ruby/ruby/blob/752a1d785475d1950b33c7d77b289a6a3a753f02/vm_method.c#L439-L443) at the time of method definition within `refine`. However, this function performs a full object space traversal via `rb_objspace_each_objects`, making it extremely expensive. In our team's Rails application, refinements are used heavily. During application code reload (triggered in development mode), `rb_clear_all_refinement_method_cache()` is called 1425 times, 1142 of which originate via `rb_clear_method_cache()`. As a result, the code reload time has increased from **5 seconds** to **15 seconds** after the patch. Since reloading occurs every time the code changes, this degrades development experience severely. ### Reproduction script: ```ruby require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end mod = Module.new klass = Class.new Benchmark.ips do |x| x.report(RUBY_VERSION) do mod.send(:refine, klass) do def call_1 = nil def call_2 = nil def call_3 = nil end end x.save! "/tmp/performance_regression_refine.bench" x.compare! end ``` ### Benchmark results: ``` Comparison: 3.2.7: 1500316.7 i/s 3.3.7: 158.0 i/s - 9496.46x slower 3.5.0: 124.6 i/s - 12041.43x slower 3.4.2: 119.5 i/s - 12553.50x slower ``` Related Slack discussion: https://ruby-jp.slack.com/archives/CLWSHA76V/p1741932018811539 I totally understand the necessity and value of the past PR that fixed the callcache bugs. That said, I was wondering if there might be any ideas to make it faster, or to handle the invalidation more efficiently. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:121549] [Ruby Bug#21218] SizedQueue not stopping threads in push even when non_block: false
by 0raghvendrrao (Raghvendra Rao) 07 Apr '25

07 Apr '25

Issue #21218 has been reported by 0raghvendrrao (Raghvendra Rao). ---------------------------------------- Bug #21218: SizedQueue not stopping threads in push even when non_block: false https://bugs.ruby-lang.org/issues/21218 * Author: 0raghvendrrao (Raghvendra Rao) * Status: Open * ruby -v: ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) +YJIT [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Use this to recreate ``` ruby 3.1.4 :019 > sq.push(1, non_block: true) => #<Thread::SizedQueue:0x00007f39e759af60> 3.1.4 :020 > sq.push(1, non_block: true) (irb):20:in `push': queue full (ThreadError) 3.1.4 :021 > sq.push(1, non_block: false) (irb):21:in `push': queue full (ThreadError) 3.1.4 :022 > sq.push(1) ----thread waits ``` When `non_block` parameter is not passed (neither true/false) only then the threads wait -- https://bugs.ruby-lang.org/

2 1

[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) 05 Apr '25

05 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:121535] [Ruby Feature#14565] Simpler, one-liner, failsafe require in ruby? [Suggested names: require_failsafe, require_safe, require_try, require_add)
by deivid 03 Apr '25

03 Apr '25

Issue #14565 has been updated by deivid (David Rodríguez). I like `require "rubocop-rspec", optional: true` idea from https://bugs.ruby-lang.org/issues/20714. I wonder if a `nil` return value for `require ..., optional: true` when the feature was not available would make sense, and would enable users to act accordingly? ---------------------------------------- Feature #14565: Simpler, one-liner, failsafe require in ruby? [Suggested names: require_failsafe, require_safe, require_try, require_add) https://bugs.ruby-lang.org/issues/14565#change-112562 * Author: shevegen (Robert A. Heiler) * Status: Open ---------------------------------------- I have quite a bit of code like this: ```ruby begin require 'x/tools/cdrskin.rb' rescue LoadError; end ``` I also use the longer variant, e.g., ```ruby begin require 'foobar' rescue LoadError puts 'project foobar is not available - consider '\ 'installing it via gem install foobar' end ``` Often, I do not need to inform the user about missing gems/projects that are tiny and not very important. In my larger ruby projects, I handle cases where a smaller project is not available or available, so I can proceed either way. It is a bit pointless to notify the user when that is me; that is why I would like to have a one-liner. I am thinking of an API such as any of the following: require_failsafe require_safe require_try require_add This is for loading with a rescue LoadError without notification. If I need to notify a user then I am fine with the longer variant. If anyone has better names, feel free to add them! I think people are more likely to remember the require-family, e. g. require 'foo.rb' or require_relative 'bar.rb' and so forth. --- I also wanted to propose a stronger `require`/`import`, including the possibility to refer to `.rb` files without a hardcoded path (if the .rb file is moved, all explicit requires to it, in particular from external projects, would have to change; and my vague idea is to replace this with some kind of project-specific way to "label" files and load these files based on these "labels", but that is for another suggestion; I only want to mention it because Hiroshi Shibata made some suggestion as extension to require, and I think the use case he mentioned may also be useful to see whether ruby may get a stronger "load code in files" functionality for ruby 3.x eventually). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121532] [Ruby Feature#14565] Simpler, one-liner, failsafe require in ruby? [Suggested names: require_failsafe, require_safe, require_try, require_add)
by austin (Austin Ziegler) 02 Apr '25

02 Apr '25

Issue #14565 has been updated by austin (Austin Ziegler). jeromedalbert (Jerome Dalbert) wrote in #note-4: > I like this feature request, a non-failing require would be great for gems that optionally depend on another gem. > > For example: > > ```ruby > begin > require 'rubocop-rspec' > rescue LoadError > end > > if defined?(RuboCop::RSpec) > # ... > end > ``` > > could be turned into something like this > > ```ruby > if require('rubocop-rspec', exception: false) > # ... > end > ``` Unfortunately, that `if` will not work, because: ```ruby p require('yaml') # true p require('yaml') # false ``` If `LoadError` were a descendant of `StandardError`, then a suffix rescue could work: ```ruby require 'rubocop-spec' rescue nil ``` I wonder if something could be done with pattern matching here to extend suffix rescues: ```ruby require 'rubocop-spec' rescue LoadError => nil ``` You would still need to check for `defined?(RuboCop::Rspec)` because of the return value, but… I do think that `require_try` or even `require(resource, exception: false)` would work nicely without that. ---------------------------------------- Feature #14565: Simpler, one-liner, failsafe require in ruby? [Suggested names: require_failsafe, require_safe, require_try, require_add) https://bugs.ruby-lang.org/issues/14565#change-112558 * Author: shevegen (Robert A. Heiler) * Status: Open ---------------------------------------- I have quite a bit of code like this: ```ruby begin require 'x/tools/cdrskin.rb' rescue LoadError; end ``` I also use the longer variant, e.g., ```ruby begin require 'foobar' rescue LoadError puts 'project foobar is not available - consider '\ 'installing it via gem install foobar' end ``` Often, I do not need to inform the user about missing gems/projects that are tiny and not very important. In my larger ruby projects, I handle cases where a smaller project is not available or available, so I can proceed either way. It is a bit pointless to notify the user when that is me; that is why I would like to have a one-liner. I am thinking of an API such as any of the following: require_failsafe require_safe require_try require_add This is for loading with a rescue LoadError without notification. If I need to notify a user then I am fine with the longer variant. If anyone has better names, feel free to add them! I think people are more likely to remember the require-family, e. g. require 'foo.rb' or require_relative 'bar.rb' and so forth. --- I also wanted to propose a stronger `require`/`import`, including the possibility to refer to `.rb` files without a hardcoded path (if the .rb file is moved, all explicit requires to it, in particular from external projects, would have to change; and my vague idea is to replace this with some kind of project-specific way to "label" files and load these files based on these "labels", but that is for another suggestion; I only want to mention it because Hiroshi Shibata made some suggestion as extension to require, and I think the use case he mentioned may also be useful to see whether ruby may get a stronger "load code in files" functionality for ruby 3.x eventually). -- https://bugs.ruby-lang.org/

1 0