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

[ruby-core:118913] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by knu (Akinori MUSHA) 22 Aug '24

22 Aug '24

Issue #18368 has been updated by knu (Akinori MUSHA). We have little choice but to specialize it for strings as we don't want to add support for `"a" + 3` that will most certainly bring disaster. 🫠 ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-109483 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118912] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by matz (Yukihiro Matsumoto) 22 Aug '24

22 Aug '24

Issue #18368 has been updated by matz (Yukihiro Matsumoto). Status changed from Closed to Open It seems this change breaks step over string ranges (e.g. `"a".."z").step(3)`). We need to handle string ranges specifically. Matz. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-109482 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118884] [Ruby master Misc#20683] Propose @ono-max as a committer
by mame (Yusuke Endoh) 20 Aug '24

20 Aug '24

Issue #20683 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20683: Propose @ono-max as a committer https://bugs.ruby-lang.org/issues/20683 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I'd like to propose @ono-max as a committer. He has contributed to Ruby's test framework, starting with the introduction of Launchable (#20254, #20661). Also he has been an ongoing contributor to the investigation and correction of flaky failures in Ruby's CI (#20682). A number of his PRs have already been merged: ``` $ git log --author=onoto --oneline | wc -l 28 ``` And I have merged my fixes based on his investigation. TBH, It is easier for me if he has a commit bit. Incidentally, he also contributes to the debug gem. ``` $ git log --author=onoto --oneline | wc -l 86 ``` @matz What do you think? -- https://bugs.ruby-lang.org/

4 6

[ruby-core:118894] [Ruby master Bug#20686] URI::HTTPS can build URI with blank, invalid host
by ronricardo (Roniece Ricardo) 20 Aug '24

20 Aug '24

Issue #20686 has been reported by ronricardo (Roniece Ricardo). ---------------------------------------- Bug #20686: URI::HTTPS can build URI with blank, invalid host https://bugs.ruby-lang.org/issues/20686 * Author: ronricardo (Roniece Ricardo) * Status: Open * ruby -v: 3.4.0+ * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In Ruby 3.4.0+, calling `URI::HTTPS.build(host: "")` does not raise `URI::InvalidComponentError` as expected. Instead, it returns `#<URI::HTTPS https://>` I think this was introduced in [this PR](https://github.com/ruby/uri/pull/90). ## Steps to Reproduce ### 1. Environment: - **Ruby Version:** 3.4.0+ ### 2. Steps: - Open an IRB session. - Run: ```ruby URI::HTTPS.build(host: "") ``` ### 3. Expected Behavior: - `URI::InvalidComponentError` should be raised due to the invalid empty `host` component. ### 4. Actual Behavior: - Returns `#<URI::HTTPS https://>` without raising an error. ### Ruby 3.1.4: ```ruby irb(main):008:0> RUBY_VERSION => "3.1.4" irb(main):009:0> URI::HTTPS.build(host:"") /home/vscode/.rbenv/versions/3.1.4/lib/ruby/3.1.0/uri/generic.rb:601:in `check_host': bad component(expected host component): (URI::InvalidComponentError) ``` ### Ruby 3.4.0: ```ruby irb(…):015> RUBY_VERSION => "3.4.0" irb(...):016> URI::HTTPS.build(host:"") => #<URI::HTTPS https://> ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:118862] [Ruby master Bug#20679] Rails CI errors since abc04e898b627ab37fa9dd5e330f239768778d8b
by yahonda (Yasuo Honda) 19 Aug '24

19 Aug '24

Issue #20679 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #20679: Rails CI errors since abc04e898b627ab37fa9dd5e330f239768778d8b https://bugs.ruby-lang.org/issues/20679 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.4.0dev (2024-08-15T18:33:13Z :detached: 2c6e16eb51) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Rails CI against Ruby master branch gets failed since abc04e898b627ab37fa9dd5e330f239768778d8b ### Steps to reproduce ``` git clone https://github.com/rails/rails cd rails/railties bundle install bin/test test/application/rendering_test.rb:39 ``` ### Expected behavior It should pass as 2c6e16eb51 does. ``` $ ruby -v ruby 3.4.0dev (2024-08-15T18:33:13Z :detached: 2c6e16eb51) [x86_64-linux] $ bin/test test/application/rendering_test.rb:39 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/json-2.7.1/lib/json/common.rb:3: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. You can add ostruct to your Gemfile or gemspec to silence this warning. /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/json-2.7.1/lib/json/common.rb:3: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. You can add ostruct to your Gemfile or gemspec to silence this warning. Run options: --seed 50444 # Running: . Finished in 1.554218s, 0.6434 runs/s, 1.2868 assertions/s. 1 runs, 2 assertions, 0 failures, 0 errors, 0 skips $ ``` ### Actual behavior It gets `NoMethodError: undefined method '[]' for nil`. ``` $ ruby -v ruby 3.4.0dev (2024-08-15T20:00:09Z :detached: abc04e898b) [x86_64-linux] $ bin/test test/application/rendering_test.rb:39 /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/json-2.7.1/lib/json/common.rb:3: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. You can add ostruct to your Gemfile or gemspec to silence this warning. /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/json-2.7.1/lib/json/common.rb:3: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. You can add ostruct to your Gemfile or gemspec to silence this warning. Run options: --seed 53551 # Running: E Error: ApplicationTests::RenderingTest#test_Unknown_format_falls_back_to_HTML_template: NoMethodError: undefined method '[]' for nil /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/rack-test-2.1.0/lib/rack/test.rb:275:in 'Rack::Test::Session#parse_uri' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/rack-test-2.1.0/lib/rack/test.rb:161:in 'Rack::Test::Session#custom_request' /home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/rack-test-2.1.0/lib/rack/test.rb:112:in 'Rack::Test::Session#get' /home/yahonda/.rbenv/versions/trunk/lib/ruby/3.4.0+0/forwardable.rb:240:in 'Rack::Test::Methods#get' test/application/rendering_test.rb:39:in 'block in <class:RenderingTest>' bin/test test/application/rendering_test.rb:19 Finished in 1.499265s, 0.6670 runs/s, 0.0000 assertions/s. 1 runs, 0 assertions, 0 failures, 1 errors, 0 skips $ ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:118845] [Ruby master Bug#20677] error: mach-o section specifier requires a segment whose length is between 1 and 16 characters
by ryandesign (Ryan Carsten Schmidt) 19 Aug '24

19 Aug '24

Issue #20677 has been reported by ryandesign (Ryan Carsten Schmidt). ---------------------------------------- Bug #20677: error: mach-o section specifier requires a segment whose length is between 1 and 16 characters https://bugs.ruby-lang.org/issues/20677 * Author: ryandesign (Ryan Carsten Schmidt) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ruby (the development version as of 2024-08-11) does not build on macOS 11 or earlier with Apple Clang 1300 or earlier: ``` coroutine/amd64/Context.S:74:14: error: mach-o section specifier requires a segment whose length is between 1 and 16 characters .pushsection .note.gnu.property, "a" ^ coroutine/amd64/Context.S:86:12: error: .popsection without corresponding .pushsection .popsection ^ make: *** [coroutine/amd64/Context.o] Error 1 ``` Here is the bug I filed with MacPorts about this: https://trac.macports.org/ticket/70537 It does build on newer systems with Apple Clang 1316 or later and on older systems when using a newer llvm.org clang compiler but it would be better if a newer compiler were not required. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:117882] [Ruby master Bug#20490] Process.waitpid2(-1, Process::WNOHANG) misbehaves on Ruby 3.1 & 3.2 with detached process
by stanhu (Stan Hu) 18 Aug '24

18 Aug '24

Issue #20490 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #20490: Process.waitpid2(-1, Process::WNOHANG) misbehaves on Ruby 3.1 & 3.2 with detached process https://bugs.ruby-lang.org/issues/20490 * Author: stanhu (Stan Hu) * Status: Open * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This is a follow-up issue for a bug that I thought was fixed in https://bugs.ruby-lang.org/issues/19837 and duplicated in https://bugs.ruby-lang.org/issues/20181. The following script doesn't terminate quickly in Ruby 3.1.5 and 3.2.4, even with the patches to address https://bugs.ruby-lang.org/issues/19837. It works fine in Ruby 3.3. It appears that the `Process::WNOHANG` argument passed to `Process.wait2` causes this script to spin until the child process stops: ```ruby #!/bin/env ruby Process.spawn({}, "sh -c 'sleep 600'").tap do |pid| puts "detaching PID #{pid}" Process.detach(pid) end forked_pid = fork do loop { sleep 1 } end child_waiter = Thread.new do puts "Waiting for child process to die..." # The spawned process has to exit before this returns in Ruby 3.1 and 3.2 loop do pid, status = Process.wait2(-1, Process::WNOHANG) puts "Exited PID: #{pid}, status: #{status}" break if pid sleep 1 end end process_killer = Thread.new do puts "Killing #{forked_pid}" system("kill #{forked_pid}") end child_waiter.join process_killer.join ``` If I drop the `Process::WNOHANG` argument, it works fine. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:118867] [Ruby master Bug#20681] Regular expression warnings are treated as compiler warnings during runtime
by Earlopain (A S) 18 Aug '24

18 Aug '24

Issue #20681 has been reported by Earlopain (A S). ---------------------------------------- Bug #20681: Regular expression warnings are treated as compiler warnings during runtime https://bugs.ruby-lang.org/issues/20681 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.4 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I have some code that recieves arbitrary input and parses it as a regexp. To supress potential warnings I'm defining the `warn` method. Unfortunately it is not getting called: ```rb def warn(...) puts "CALLED" end source = "/\w**/" Regexp.new(source) ``` Running this emits a warning and doesn't print "CALLED": ``` $ ruby test.rb test.rb:6: warning: regular expression has redundant nested repeat operator '*': /\/w**\// ``` I looked a bit at the code and found something which I think is supposed to handle this case but it seems like its not checking against the right thing: https://github.com/ruby/ruby/blob/4dbf386ca248df0f47f31dc28cdeabe8d4477e5b/… -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118699] [Ruby master Bug#20654] Floor and ceil have unexpected behaviour when ndigits is large
by peterzhu2118 (Peter Zhu) 18 Aug '24

18 Aug '24

Issue #20654 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20654: Floor and ceil have unexpected behaviour when ndigits is large https://bugs.ruby-lang.org/issues/20654 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/11257 There is unexpected behaviour in Integer#floor, Float#floor, Integer#ceil, Float#ceil when ndigits is large such that 10**ndigits is a bignum. Previously, it would return 0 in such cases. However, this would cause unexpected behaviour such as: ```ruby puts -1.floor(-5) # => -100000 puts -1.floor(-10) # => -10000000000 puts -1.floor(-20) # => 0 ``` ```ruby puts 1.ceil(-5) # => 100000 puts 1.ceil(-10) # => 10000000000 puts 1.ceil(-20) # => 0 ``` The PR changes the last result so that it will return -100000000000000000000 and 100000000000000000000, respectively. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118866] [Ruby master Bug#20680] No "void context" warning for literals/etc. in ensure block
by Earlopain (A S) 17 Aug '24

17 Aug '24

Issue #20680 has been reported by Earlopain (A S). ---------------------------------------- Bug #20680: No "void context" warning for literals/etc. in ensure block https://bugs.ruby-lang.org/issues/20680 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.4 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Providing this code, I would expect ruby to emit a void context warning: ```rb begin foo rescue bar ensure 42 end ``` `ensure` blocks don't return a value unless `return` is used explicitly. Am I right in my assumption that this should theoretically emit a warning? -- https://bugs.ruby-lang.org/

1 0