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

[ruby-core:113087] [Ruby master Bug#19570] `Exception#full_message` raises an `EncodingError` if the exception contains UTF8 characters after a newline and `Exception#cause` contains UTF8 characters
by timothy.willard (Timothy Willard) 10 Apr '23

10 Apr '23

Issue #19570 has been reported by timothy.willard (Timothy Willard). ---------------------------------------- Bug #19570: `Exception#full_message` raises an `EncodingError` if the exception contains UTF8 characters after a newline and `Exception#cause` contains UTF8 characters https://bugs.ruby-lang.org/issues/19570 * Author: timothy.willard (Timothy Willard) * Status: Open * Priority: Normal * ruby -v: 3.2.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` e = begin begin raise "Übersicht" rescue => e raise "\n#{e.message}" end rescue => e e end e.full_message ``` will reproduce the error with the exception `incompatible character encodings: ASCII-8BIT and UTF-8 (Encoding::CompatibilityError)`. In this case, all of `e.message`, `e.cause.message` and `e.cause.detailed_message` have a UTF-8 encoding, but `e.detailed_message` has an ASCII-8BIT encoding. I think the issue is related to [this](https://github.com/ruby/ruby/blob/31819e82c88c6f8ecfaeb162519bfa26a14… line (possibly caused by the encoding differences between `write_warn2` used [here](https://github.com/ruby/ruby/blob/31819e82c88c6f8ecfaeb162519bfa26a14… and [here](https://github.com/ruby/ruby/blob/31819e82c88c6f8ecfaeb162519bfa26a14… in the newline case vs `write_warn_str` used [here](https://github.com/ruby/ruby/blob/31819e82c88c6f8ecfaeb162519bfa26a14… in the no-newline case. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113161] AIX 64-bit Ruby 2.5.9 build's miniruby hangs
by Jay Mav 08 Apr '23

08 Apr '23

Hello, Building 64-bit Ruby 2.5.9 on AIX using xlc compiler. Miniruby hangs during "generating encdb.h". Call-stacks of the miniruby process: ---------- tid# 24838655 (pthread ID: 1) ---------- 0x00000001001267f0 ruby_atomic_compare_and_swap(0x1100636b8, 0x1b15a7001b15a7, 0x1af5a7001af5a7) + 0x30 0x000000010001c058 atomic_sub_nounderflow(0x1100636b8, 0x2000) + 0x58 0x0000000100025880 objspace_malloc_increase(0x1100636b0, 0x1102f8f30, 0x0, 0x2000, 0x200000002) + 0x80 0x000000010001eb8c objspace_xfree(0x1100636b0, 0x1102f8f30, 0x2000) + 0x4c 0x000000010001ec10 ruby_sized_xfree(0x1102f8f30, 0x2000) + 0x30 0x00000001001e71a4 free_io_buffer(0x1102f8e90) + 0x24 0x00000001001e7394 fptr_finalize(0x1102f8e50, 0x0) + 0x34 0x00000001001e7438 rb_io_fptr_cleanup(0x1102f8e50, 0x0) + 0x58 0x00000001001e7560 io_close_fptr(0x1101ad7c0) + 0xe0 0x00000001001e7674 rb_io_close(0x1101ad7c0) + 0x14 0x0000000100007378 restore_load_file(0xfffffffffffe900) + 0x38 0x00000001000083dc rb_ensure(0x110023278, 0xfffffffffffe900, 0x110023290, 0xfffffffffffe900) + 0x1bc 0x00000001000009a0 load_file(0x1101ae468, 0x1101ae698, 0x1101ad7c0, 0x100000001, 0xfffffffffffefb0) + 0x60 0x0000000100005688 process_options(0x60000000b, 0xffffffffffff4c8, 0xfffffffffffefb0) + 0xa48 0x0000000100005c50 ruby_process_options(0xb0000000b, 0xffffffffffff4a0) + 0xd0 0x000000010000be70 ruby_options(0xb0000000b, 0xffffffffffff4a0) + 0xd0 0x0000000100000560 main(0xb0000000b, 0xffffffffffff4a0) + 0x60 0x0000000100000268 __start() + 0x70 ---------- tid# 21168597 (pthread ID: 258) ---------- 0x0900000000168334 __fd_poll(??, ??, ??) + 0xb4 0x000000010011d6c4 poll(0x1102dc6d8, 0x2, 0xffffffffffffffff) + 0x24 0x000000010011d790 timer_thread_sleep(0x110062678) + 0x90 0x000000010011d944 thread_timer(0x110062678) + 0x44 0x09000000005abfe8 _pthread_body(??) + 0xe8 Any suggestions on how to fix this? Thanks.

1 0

[ruby-core:113147] [Ruby master Bug#19583] Unary minus inconsistency when used with variables and literals
by hurricup (Alexandr Evstigneev) 06 Apr '23

06 Apr '23

Issue #19583 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19583: Unary minus inconsistency when used with variables and literals https://bugs.ruby-lang.org/issues/19583 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This feels a bit inconsistent and I could not find an explanation. This is fine and `-` has higher precedence than `.` ``` -2.upto 0 do |arg| puts arg end ``` But this is not working, won't even compile (requires parens): ``` var = 2 -var.upto 0 do |arg| puts arg end ``` I presume that in the first example there is no unary minus operation, just negative literal. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113138] [Ruby master Misc#19581] Will Openssl 1.1.x fully support for Ruby3.1 throught the life time of Ruby3.1?
by mliu404 (Nikola Liu) 05 Apr '23

05 Apr '23

Issue #19581 has been reported by mliu404 (Nikola Liu). ---------------------------------------- Misc #19581: Will Openssl 1.1.x fully support for Ruby3.1 throught the life time of Ruby3.1? https://bugs.ruby-lang.org/issues/19581 * Author: mliu404 (Nikola Liu) * Status: Open * Priority: Normal ---------------------------------------- Currently Ruby3.1 require openSSL 1.1.x / 3.0.x to build rubyGem. Does the requirement for openSSL will be the same for all future minor version of Ruby3.1 ? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113132] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by Dan0042 (Daniel DeLorme) 05 Apr '23

05 Apr '23

Issue #18368 has been updated by Dan0042 (Daniel DeLorme). Ah, from https://github.com/ruby/dev-meeting-log/blob/master/2022/DevMeeting-2022-01… > matz: we should not modify the behavior when the receiver is a String I take that to mean Matz prefers not breaking compatibility. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102666 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- 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:113131] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 05 Apr '23

05 Apr '23

Issue #18368 has been updated by zverok (Victor Shepelev). @Dan0042 I value backwards compatibility a lot (I mentioned it in original ticket). I though believe that in _this_ particular case the old behaviour for non-numeric ranges is so weird that 1. Very small amount of code, if any, would be broken 2. The error would be very clear 3. Preserving both behaviours just for strings would be very hard to explain in hindsight and will affect language's quality and learnability. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102665 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- 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:113130] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by Dan0042 (Daniel DeLorme) 05 Apr '23

05 Apr '23

Issue #18368 has been updated by Dan0042 (Daniel DeLorme). I guess we just have different values regarding backward compatibility. Your arguments are not false, but to me they have a value several orders of magnitude below compatibility. It doesn't need to be a "very common" idiom, it just needs to be used by a few people, who discover their code breaks upon upgrade, and after a few times of getting angry due to breakage decide to throw the towel and never again choose ruby for a new project. I'm not sure if @Matz meant "yes, it's ok to break compatibility" or "yes, it's ok since it doesn't break compatibility". ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102664 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- 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:113112] [Ruby master Bug#19578] abort() shows stack trace when run within rescue clause
by Dan0042 (Daniel DeLorme) 05 Apr '23

05 Apr '23

Issue #19578 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Bug #19578: abort() shows stack trace when run within rescue clause https://bugs.ruby-lang.org/issues/19578 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I sometimes use the pattern `print(str) rescue abort` in order to exit without stack trace when the output of a ruby program is interrupted by SIGPIPE, ex: `./printstuff.rb | head` It seems that since ruby 2.7 this results in printing the stack trace. This is not the case when using `abort` by itself. Is this intended? I would expect `abort` to behave much like `exit(1)`, as it always has. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:113127] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 05 Apr '23

05 Apr '23

Issue #18368 has been updated by zverok (Victor Shepelev). @Dan0042 I don't think that "maintaining compatibility" here is valuable unless proven otherwise (e.g. it is a very common idiom for iterating through strings - while working on this ticket, I found no evidence for that). My reasoning is that it is very confusing when some simple and "math-alike" functionality is specialized for exactly one type. What if some user's type has both T+T and T#succ, should it also maintain "two behaviours depending on argument type"? If not, why? Breaking this particular case has a benefit of clear semantics, explained by one phrase, which never breaks user's mental model with "well, the method does this, but with String boundaries and Int argument it also behaves like that." If we are bold enough to change generic method's semantics (I believe Matz is open to it), maintaining legacy behaviours totally unrelated to the new semantics is a forever burden on the language. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102662 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- 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:113064] [Ruby master Bug#19566] OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't
by jgomo3 04 Apr '23

04 Apr '23

Issue #19566 has been reported by jgomo3 (Jesús Gómez). ---------------------------------------- Bug #19566: OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't https://bugs.ruby-lang.org/issues/19566 * Author: jgomo3 (Jesús Gómez) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation says > OptionParser comes with a few ready-to-use kinds of type coercion. They are > .. > * URI – Anything accepted by URI.parse > But when I try to use the class `URI` as a coercion class: ``` op = OptionParser.new op.on("--uri URI", URI) ``` I get: `unsupported argument type: URI (ArgumentError)`. The workaround is to register it with `accept`: ``` op = OptionParser.new op.accept(URI, &URI.method(:parse)) op.on("--uri URI", URI) ``` I attached 2 files, the first one `ruby-op-uri-bug.rb` displays the Error. The second one, `ruby-op-uri-workaround.rb` show the proper output. ---Files-------------------------------- ruby-op-uri-bug.rb (340 Bytes) ruby-op-uri-bug-workaround.rb (377 Bytes) -- https://bugs.ruby-lang.org/

3 2