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

[ruby-core:119559] [Ruby master Feature#20805] Allow Ractor#send from a signal trap Proc
by kirs (Kir Shatrov) 25 Oct '24

25 Oct '24

Issue #20805 has been reported by kirs (Kir Shatrov). ---------------------------------------- Feature #20805: Allow Ractor#send from a signal trap Proc https://bugs.ruby-lang.org/issues/20805 * Author: kirs (Kir Shatrov) * Status: Open ---------------------------------------- It was surfaced in https://bugs.ruby-lang.org/issues/18139 that Ractor is designed to "unexpected interruption free" and it's not supposed to have a `kill`-like method. A better alternative to that would be allow the main Ractor to consume a shutdown signal from the pipe. Example: ```ruby shutdown_ractor = Ractor.new do Ractor.recv # Wait for a signal end # Signal trap for SIGTERM Signal.trap("TERM") do puts "Received SIGTERM, shutting down..." shutdown_ractor.send(:shutdown) # Send the shutdown signal end pipe = Ractor.new do loop do r, value = Ractor.select(Ractor.recv, shutdown_ractor) if r == shutdown_ractor # Shutdown signal received break else Ractor.yield(value, move: true) # Normal operation end end end ``` However, it's not possible to do `Ractor#send` from a trap Proc right now: ``` <internal:ractor>:282:in `new': can not isolate a Proc because it accesses outer variables (shutdown_ractor). (ArgumentError) ``` From what I've gathered, it makes it impossible to implement any graceful shutdown in a process with a few Ractors running. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119599] [Ruby master Bug#20810] Re-enable s390x CI Builds on Master Branch in Travis CI
by mayur.jadhav (Mayur Jadhav) 25 Oct '24

25 Oct '24

Issue #20810 has been reported by mayur.jadhav (Mayur Jadhav). ---------------------------------------- Bug #20810: Re-enable s390x CI Builds on Master Branch in Travis CI https://bugs.ruby-lang.org/issues/20810 * Author: mayur.jadhav (Mayur Jadhav) * Status: Open * ruby -v: master * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Description: Currently, the Travis CI has been temporarily disabled on the master branch via Pr(https://github.com/ruby/ruby/pull/11509). However, the s390x builds are successfully running on other branches( ruby_3_3, ruby_3_2) on Travis CI, which were previously experiencing timeouts. The issue has been addressed by the Travis team. Given the significance of multi-architecture support for Ruby, we request that the Travis CI builds be re-enabled on the master branch. please let us know we are more than happy to collaborate to make this happen. Thanks. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:119606] [Ruby master Feature#20812] Proposal for Safe Include Method in Ruby
by rogerconsul (Roger Consul) 24 Oct '24

24 Oct '24

Issue #20812 has been reported by rogerconsul (Roger Consul). ---------------------------------------- Feature #20812: Proposal for Safe Include Method in Ruby https://bugs.ruby-lang.org/issues/20812 * Author: rogerconsul (Roger Consul) * Status: Open ---------------------------------------- # Proposal for Safe Include Method in Ruby ## Description Add a new method `include_safe?` to Ruby's `Enumerable` module that safely handles nil arguments in inclusion checks. ## Problem Statement The current `include?` method raises an error when passed `nil` as an argument. This requires developers to write defensive code with explicit nil checks, leading to less readable and more error-prone code. ```ruby # Current problematic scenarios: collection.include?(nil) # Works, checks for nil in collection collection.include?(value) # Raises error if value is nil # Current workarounds: value && collection.include?(value) collection.include?(value.to_s) ``` ## Proposed Solution Add `include_safe?` method that returns `false` when the argument is `nil`: ```ruby module Enumerable def include_safe?(obj) return false if obj.nil? include?(obj) end end ``` ### Usage Examples ```ruby numbers = [1, 2, 3] document_id = nil # Current approach document_id && numbers.include?(document_id) # false # Proposed approach numbers.include_safe?(document_id) # false # Works normally for non-nil values numbers.include_safe?(2) # true numbers.include_safe?(4) # false # Edge cases handled [nil].include_safe?(nil) # false [].include_safe?(nil) # false ``` ## Benefits 1. **Improved Safety**: Eliminates a common source of runtime errors 2. **Better Readability**: Removes need for explicit nil checks 3. **Consistent Behavior**: Provides predictable handling of nil values 4. **Rails Alignment**: Similar to Rails' safe navigation patterns 5. **Reduced Boilerplate**: Eliminates common defensive coding patterns ## Implementation Notes This would be implemented in C as part of Ruby's core, but here's a Ruby reference implementation: ```ruby module Enumerable def include_safe?(obj) return false if obj.nil? include?(obj) end end ``` ## Testing Strategy ```ruby require 'minitest/autorun' class TestIncludeSafe < Minitest::Test def setup @array = [1, 2, 3] @array_with_nil = [1, nil, 3] end def test_basic_inclusion assert @array.include_safe?(1) refute @array.include_safe?(4) end def test_nil_handling refute @array.include_safe?(nil) refute @array_with_nil.include_safe?(nil) end def test_empty_collection refute [].include_safe?(nil) refute [].include_safe?(1) end end ``` ## Alternative Considerations 1. **Name Alternatives**: - `try_include?` - `safe_include?` - `includes_safely?` 2. **Alternative Approaches**: - Modify existing `include?` behavior (rejected due to backward compatibility) - Add parameter to existing `include?` (rejected for clarity) ## Impact Analysis ### Positive Impact - Reduces runtime errors - Improves code readability - Follows principle of least surprise ### Potential Concerns - Another method to learn - Possible confusion with regular `include?` ## Similar Features in Ruby - Safe navigation operator (`&.`) - `try` method in Rails - `fetch` method with default value ## Backward Compatibility This change is fully backward compatible as it introduces a new method without modifying existing behavior. ## Reference Implementation A gem implementing this feature is available at: [Link to gem if created] ## Questions for Core Team 1. Is `include_safe?` the best name for this method? 2. Should this be added to `Array` specifically rather than `Enumerable`? 3. Should we consider any additional edge cases? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119605] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by Eregon (Benoit Daloze) 24 Oct '24

24 Oct '24

Issue #15381 has been updated by Eregon (Benoit Daloze). Regarding `**@`, I'm not a big fan because `**` on the caller side is very much syntax a bit like a keyword, and it has the meaning the pass the Hash/expression as keyword arguments and not as a position argument. Of course you could have `**` the syntax and `**@` the unary operator called by it, but effectively it's not really an operator in the sense of unary +/- or binary operators, e.g. it can only be used in calls and in Hash literals. Regarding trying `to_hash` then `to_h` or vice-versa it will have some overhead for the second method being tried for non-Hash. `foo(**obj.to_h)` doesn't sound too bad to me as I would expect it's needed in only a few places (compared to all `**hash` usages) and it's probably clearer what is happening that way if `obj` is not a Hash/to_hash. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110227 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119549] [Ruby master Bug#20803] Windows intermittent spec failure
by MSP-Greg (Greg L) 23 Oct '24

23 Oct '24

Issue #20803 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #20803: Windows intermittent spec failure https://bugs.ruby-lang.org/issues/20803 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: master * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This frequently fails on ruby-loco's mingw build, but I think there have been less frequent failures on ucrt and mswin. I've started a new GHA build when it occurs, and it usually passes. I could not repro locally. ``` ObjectSpace.memsize_of returns 0 for literal Symbols FAILED Expected 40 == 0 to be truthy but was false /ruby/spec/ruby/library/objectspace/memsize_of_spec.rb:16:in 'block (2 levels) in <top (required)>' /ruby/spec/ruby/library/objectspace/memsize_of_spec.rb:4:in '<top (required)>' ``` The test code: ```ruby it "returns 0 for literal Symbols" do ObjectSpace.memsize_of(:abc).should == 0 end ``` ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119596] Mailbox is full <ruby-core@ruby-lang.org>
by Mailbox Team 23 Oct '24

23 Oct '24

1 0

[ruby-core:119595] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by zverok (Victor Shepelev) 23 Oct '24

23 Oct '24

Issue #15381 has been updated by zverok (Victor Shepelev). > I think that would be awesome. If I do `other_method(**model)` and that model is representable as a hash, passing it as keyword arguments is beautiful. ...until you passed it erroneously, and it was never meant to be, and the error happened not where it should happen but in some completely different place. ...until somebody tries to make heads or tails from the legacy codebase and assumes that something that is invoked with `**value` is hash-like, while in fact, it was a value object, and there is no way to know it without chasing it back and forth by call stack. Now, _imagine_ if that was the author’s intention (“here we unpack our model into the keyword args”) and the author just wrote (like, five more characters) ```ruby other_method(**model.to_h) ``` ...and the reader immediately sees where the “transition point” is from value object/model to keyword args/hash-like data. > Imagine something like > ```ruby > ValidOptions = Struct.new(:ssl, :host, :port) > ``` Now imagine that if you want to have such options as kwarg-passable, you can just ```ruby ValidOptions = Struct.new(:ssl, :host, :port) { alias to_hash to_h } ``` ...and that immediately communicates “this particular value object (unlike many other value objects) thinks of it as a hash-like object that would be unpacked probably at some point”. >> problem of things being unintentionally unpacked, considering how many objects have to_h method > > That never happens. I have never ever written code where `foo(**opts)` throws "no implicit conversion of Object into Hash" and then I realize I really meant to use something other than opts. I saw this a lot (especially transitioning from older to newer syntaxes, libraries, and Ruby versions). Fighting anecdata with anecdata! :) The conversion from “it had just one extra parameter” to “it has a hash of extra parameters” is a frequent refactoring when some library matures, and I really like to have it reported to me early that some object passed where it doesn’t correspond to the target method’s expectations. `NoMethodError`/“no implicit conversion” is a wonderful tool for this, but only if it happens _in the closest place to the possible error_. PS: Honestly, I am still not sure which _problem_ we are trying to solve (that is not covered by the `**nil` addition) that is so frequent and has no other easy solution to be worth all the drawbacks. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110217 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119572] [Ruby master Bug#20807] String#gsub fails when called from string subclass with a block passed
by koilanetroc (Oleg Tolmashov) 23 Oct '24

23 Oct '24

Issue #20807 has been reported by koilanetroc (Oleg Tolmashov). ---------------------------------------- Bug #20807: String#gsub fails when called from string subclass with a block passed https://bugs.ruby-lang.org/issues/20807 * Author: koilanetroc (Oleg Tolmashov) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When `String#gsub` is called from a string subclass with a block, `Regexp.last_match` is nil, but passed block is executed. Here is example code: ```ruby def call_gsub(str) str.gsub(/%/) do puts "checking #{str.class}" puts "Special variable value: #{$&}" puts "Regexp.last_match = #{Regexp.last_match.inspect}\n\n" raise "Special variable $& is not assigned, but block is called" if $&.nil? end end class MyString < String def gsub(*args, &block) super(*args, &block) # just forward everything end end text = 'test%text_with_special_character' call_gsub(String.new(text)) # original string call_gsub(MyString.new(text)) # string subclass ``` Result: ``` checking String Special variable value: % Regexp.last_match = #<MatchData "%"> checking MyString Special variable value: Regexp.last_match = nil gsub_bug.rb:7:in `block in call_gsub': Special variable $& is not assigned, but block is called (RuntimeError) from gsub_bug.rb:13:in `gsub' from gsub_bug.rb:13:in `gsub' from gsub_bug.rb:2:in `call_gsub' from gsub_bug.rb:20:in `<main>' ``` I expect result to be the same for both classes since `MyString` just wraps the same method: ``` checking String Special variable value: % Regexp.last_match = #<MatchData "%"> checking MyString Special variable value: % Regexp.last_match = #<MatchData "%"> ``` Maybe there is something off with with control frame when params are forwarded? Thanks in advance! -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119514] [Ruby master Bug#20796] Segmentation fault in rubyzip tests with ruby 3.4.0-preview2
by tikkss (Tsutomu Katsube) 22 Oct '24

22 Oct '24

Issue #20796 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Bug #20796: Segmentation fault in rubyzip tests with ruby 3.4.0-preview2 https://bugs.ruby-lang.org/issues/20796 * Author: tikkss (Tsutomu Katsube) * Status: Open * ruby -v: ruby 3.4.0preview2 (2024-10-07 master 32c733f57b) +PRISM [x86_64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Steps to reproduce --- ```console $ git clone git@github.com:rubyzip/rubyzip $ cd rubyzip $ bundle $ bundle exec rake ``` Expected behavior --- The tests should complete successfully. Actual behavior --- A segmentation fault occurs during the test run. This issue does not occur with ruby 3.4.0-preview1 or other Ruby versions. Console dump --- See attached `crash.log` and `ruby-2024-10-13-071029.ips` for full details ```console $ bundle exec rake TESTOPTS="-v --seed=1" 2>crash.log Run options: -v --seed=1 # Running: ZipFileTest#test_get_output_stream = 0.02 s = . ZipFileTest#test_add_directory = 0.01 s = . ZipFileTest#test_streaming = 0.01 s = . ZipFileTest#test_nonexistant_zip = 0.00 s = . ZipFileTest#test_open_buffer_without_block = 0.00 s = . ZipFileTest#test_rename_to_existing_entry = 0.00 s = . ZipFileTest#test_open_buffer_with_io_and_block = 0.00 s = . ZipFileTest#test_write_buffer = 0.01 s = . ZipFileTest#test_open_buffer_with_stringio = 0.00 s = . ZipFileTest#test_odd_extra_field = 0.00 s = . ZipFileTest#test_add_existing_entry_name = 0.00 s = . ZipFileTest#test_open_buffer_no_op_does_not_change_file = 0.00 s = . ZipFileTest#test_replace = 0.01 s = . ZipFileTest#test_rename = 0.01 s = . ZipFileTest#test_recover_permissions_after_add_files_to_archive = % ``` My environment --- ```console $ gem env RubyGems Environment: - RUBYGEMS VERSION: 3.6.0.dev - RUBY VERSION: 3.4.0 (2024-10-07 patchlevel -1) [x86_64-darwin24] - INSTALLATION DIRECTORY: /Users/zzz/.rbenv/versions/3.4.0-preview2/lib/ruby/gems/3.4.0+0 - USER INSTALLATION DIRECTORY: /Users/zzz/.gem/ruby/3.4.0+0 - RUBY EXECUTABLE: /Users/zzz/.rbenv/versions/3.4.0-preview2/bin/ruby - GIT EXECUTABLE: /usr/local/bin/git - EXECUTABLE DIRECTORY: /Users/zzz/.rbenv/versions/3.4.0-preview2/bin - SPEC CACHE DIRECTORY: /Users/zzz/.gem/specs - SYSTEM CONFIGURATION DIRECTORY: /Users/zzz/.rbenv/versions/3.4.0-preview2/etc - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-24 - GEM PATHS: - /Users/zzz/.rbenv/versions/3.4.0-preview2/lib/ruby/gems/3.4.0+0 - /Users/zzz/.gem/ruby/3.4.0+0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :backtrace => true - :bulk_threshold => 1000 - "gem" => "--no-document" - REMOTE SOURCES: - https://rubygems.org/ - SHELL PATH: - /Users/zzz/.rbenv/versions/3.4.0-preview2/bin - /usr/local/Cellar/rbenv/1.3.0/libexec - /Users/zzz/.local/bin - /Users/zzz/.rbenv/shims - /Users/zzz/.rbenv/bin - /Users/zzz/.nodenv/bin - /Users/zzz/bin - /Users/zzz/.cargo/bin - /usr/local/sbin - /usr/local/bin - /System/Cryptexes/App/usr/bin - /usr/bin - /bin - /usr/sbin - /sbin - /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin - /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin - /var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin - /Library/Apple/usr/bin ``` ```console $ cat Gemfile.lock PATH remote: . specs: rubyzip (3.0.0.alpha) GEM remote: https://rubygems.org/ specs: ast (2.4.2) docile (1.4.1) json (2.7.2) language_server-protocol (3.17.0.3) minitest (5.22.3) parallel (1.26.3) parser (3.3.5.0) ast (~> 2.4.1) racc psych (5.1.2) stringio racc (1.8.1) rainbow (3.1.1) rake (13.1.0) rdoc (6.6.3.1) psych (>= 4.0.0) regexp_parser (2.9.2) rexml (3.3.8) rubocop (1.61.0) json (~> 2.3) language_server-protocol (>= 3.17.0) parallel (~> 1.10) parser (>= 3.3.0.2) rainbow (>= 2.2.2, < 4.0) regexp_parser (>= 1.8, < 3.0) rexml (>= 3.2.5, < 4.0) rubocop-ast (>= 1.30.0, < 2.0) ruby-progressbar (~> 1.7) unicode-display_width (>= 2.4.0, < 3.0) rubocop-ast (1.32.3) parser (>= 3.3.1.0) rubocop-performance (1.20.2) rubocop (>= 1.48.1, < 2.0) rubocop-ast (>= 1.30.0, < 2.0) rubocop-rake (0.6.0) rubocop (~> 1.0) ruby-progressbar (1.13.0) simplecov (0.22.0) docile (~> 1.1) simplecov-html (~> 0.11) simplecov_json_formatter (~> 0.1) simplecov-html (0.13.1) simplecov-lcov (0.8.0) simplecov_json_formatter (0.1.4) stringio (3.1.1) unicode-display_width (2.6.0) PLATFORMS ruby x86_64-darwin-24 DEPENDENCIES minitest (~> 5.22.0) rake (~> 13.1.0) rdoc (~> 6.6.2) rubocop (~> 1.61.0) rubocop-performance (~> 1.20.0) rubocop-rake (~> 0.6.0) rubyzip! simplecov (~> 0.22.0) simplecov-lcov (~> 0.8) BUNDLED WITH 2.6.0.dev ``` ---Files-------------------------------- crash.log (74.3 KB) ruby-2024-10-13-071029.ips (31.5 KB) -- https://bugs.ruby-lang.org/

4 9

[ruby-core:119592] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by Dan0042 (Daniel DeLorme) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by Dan0042 (Daniel DeLorme). > There are certainly backwards compatibility issues from changing `**` from calling `to_hash` to `to_h`. What kind of backwards compatibility issues exactly? My idea was to call #to_hash and fall back to #to_h, that should ensure no backwards incompatibility at all, unless I'm missing something? > Using the unary `**` operator on an object would call the `**@` method, which should return a hash (or raise an exception). That's a very intriguing solution, and very elegant I have to say. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110213 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0