- ruby-core - ml.ruby-lang.org

[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

[ruby-core:121531] [Ruby Bug#21215] IRB upto yield self when self is little then end_val
by fitmap (Justin Peal) 02 Apr '25

02 Apr '25

Issue #21215 has been reported by fitmap (Justin Peal). ---------------------------------------- Bug #21215: IRB upto yield self when self is little then end_val https://bugs.ruby-lang.org/issues/21215 * Author: fitmap (Justin Peal) * Status: Open * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- irb(main):001:0> 1.upto(0) { |k| p k } => 1 1 irb(main):002:0> 0.downto(1) { |k| p k } => 0 0 Save these statements to script and run the script, no output. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121497] [Ruby Feature#21209] Endless classes and modules
by Dan0042 (Daniel DeLorme) 02 Apr '25

02 Apr '25

Issue #21209 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #21209: Endless classes and modules https://bugs.ruby-lang.org/issues/21209 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- Endless methods have proven popular enough that we should bring the same endlessness to module/class definitions. For a long time we've had this ugly pattern of class definitions with an extreme level of indentation. I propose a simple new rule to fix this: if a 'class' or 'module' statement is at the beginning of a line, the matching 'end' becomes optional; EOF is enough. instead of: ```ruby module Arel module Visitors class UnsupportedVisitError module ClassMethod module AmIDeepEnough module NoNotDeepEnough class LetsGoDeepter def firstmethod "man, I'm just the first method and already indented 14 spaces deep!" end end #what end #a end #chain end #we end #have end #here end #weee!!! ``` we can have the much more readable: ```ruby module Arel module Visitors class UnsupportedVisitError module ClassMethod module AmIDeepEnough module NoNotDeepEnough class LetsGoDeepter def firstmethod "now that's better!" end ``` Brilliant! -- https://bugs.ruby-lang.org/

3 2

[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