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

[ruby-core:113104] [Ruby master Bug#19574] [BUG] Bus Error at 0x0000000102a7c000
by haneul (Haneul Kihm) 04 Apr '23

04 Apr '23

Issue #19574 has been reported by haneul (Haneul Kihm). ---------------------------------------- Bug #19574: [BUG] Bus Error at 0x0000000102a7c000 https://bugs.ruby-lang.org/issues/19574 * Author: haneul (Haneul Kihm) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ---Files-------------------------------- ruby-2023-04-04-181657.ips (13.5 KB) ruby-2023-04-04-182522.ips (13.5 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112990] [Ruby master Bug#19545] lp/hp logic parsing inconsistency
by hurricup (Alexandr Evstigneev) 04 Apr '23

04 Apr '23

Issue #19545 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19545: lp/hp logic parsing inconsistency https://bugs.ruby-lang.org/issues/19545 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- As far as i get it, low precedence logic should behave the same as high precedence. But: This is ok: ``` puts(false || !false) ``` And this is not: ``` puts(false or not false) ``` Feels like in latter case there is some mess with comma precedence. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:112445] [Ruby master Bug#19441] Closing an IO#dup behaviour
by stac47 (Laurent Stacul) 03 Apr '23

03 Apr '23

Issue #19441 has been reported by stac47 (Laurent Stacul). ---------------------------------------- Bug #19441: Closing an IO#dup behaviour https://bugs.ruby-lang.org/issues/19441 * Author: stac47 (Laurent Stacul) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello amazing ruby folks! I classified that ticket as a "Bug" although it is perhaps something I did not understand. Here is a ruby session: ``` ruby irb(main):001:0> file = Tempfile.new => #<File:/var/folders/m2/bljzrgq160vbf0vk466k_7gw0000gn/T/20230216-39664-davfmj> irb(main):002:0> file.fileno => 9 irb(main):003:0> dup = file.dup => #<File:/var/folders/m2/bljzrgq160vbf0vk466k_7gw0000gn/T/20230216-39664-davfmj> irb(main):004:0> dup.fileno => 10 irb(main):005:0> dup.close => nil irb(main):006:0> dup.closed? => false irb(main):007:0> file.closed? => true ``` The two last lines are unexpected to me. I would have expected the converse: ```ruby irb(main):006:0> dup.closed? => true irb(main):007:0> file.closed? => false ``` I tried this scenario in latest ruby but also in ruby 2.7. Thanks in advance for helping me to understand this behaviour. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:113022] [Ruby master Bug#19548] Ambiguous and confusing syntax for alias/undef arguments
by hurricup (Alexandr Evstigneev) 03 Apr '23

03 Apr '23

Issue #19548 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19548: Ambiguous and confusing syntax for alias/undef arguments https://bugs.ruby-lang.org/issues/19548 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This was introduced in https://bugs.ruby-lang.org/issues/8851 and looks really confusing at least because of bare `/`. Here are 3 semantically similar methods, but feels like first two should not be valid: ``` def method1 undef :*,<<,/,[] alias :* / end def method2 undef :*, <<, /, [] alias :* / end def method3 undef :* undef :<< undef :/ undef :[] alias :* :/ end puts RubyVM::InstructionSequence.of(method :method1).disasm puts RubyVM::InstructionSequence.of(method :method2).disasm puts RubyVM::InstructionSequence.of(method :method3).disasm ``` -- https://bugs.ruby-lang.org/

2 1

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

03 Apr '23

Issue #18368 has been updated by Dan0042 (Daniel DeLorme). Ah yes, sorry for that. Whenever I write and review something before posting, it seems fine. And whenever I re-read it a week later it feels too strong. Maybe it's a curse. Please accept my advance apologies if I'm doing the same thing in this post. As I tried saying in #note-9 and #note-14, it's easy to keep a special case for a string range with a numeric step. I noticed you removed the special case for Symbol ranges (and I was quite surprised it existed in the first place). But it would have been just as easy to keep the special case in there, and add the same things for Strings, e.g. ```ruby else if (STRING_P(b) && (NIL_P(e) || STRING_P(e)) && step_num_p) { /* strings + numeric step are special */ if (NIL_P(e)) { rb_str_upto_endless_each(b, step_i, (VALUE)iter); } else { rb_str_upto_each(b, e, EXCL(range), step_i, (VALUE)iter); } } ``` By "pointless" I meant that breaking compatibility here is not needed. We can have the improved behavior without breaking compatibility. Breaking this particular case has no benefit; something that previously worked now raises an error, and may break someone's code. Now, if `str + int` had a defined behavior I would agree that breaking compatibility serves a purpose. But since that's not the case, we're just going from "it works" to "it raises" and that serves no purpose, hence why I said "pointless". Again sorry for the strong wording. I don't mean to kick up a fuss about your work. I really appreciate the effort you've made in making ranges more generally useful in ruby. I just find it disappointing when compatibility is thrown under the bus when not strictly needed. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102622 * 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:113068] [Ruby master Feature#19567] Add Oxford Comma Support for better readability
by tenderlovemaking (Aaron Patterson) 03 Apr '23

03 Apr '23

Issue #19567 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #19567: Add Oxford Comma Support for better readability https://bugs.ruby-lang.org/issues/19567 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal ---------------------------------------- Ruby has regular commas: ```ruby [a, b, c] ``` Ruby has trailing commas: ```ruby [ a, b, c, ] ``` But I think both of these are hard to read compared to the Oxford comma. We should introduce the Oxford comma so that code is easier to read: For example: ```ruby def foo a, b, and c [a, b, and c] end p foo(1, 2, and 3) ``` As an added bonus, this feature also makes specifying musical beats quite natural, for example: ``` [1, and 2, and 3, and 4] ``` Just to make sure that everyone is pleased, you are allowed to mix the Oxford comma with trailing commas like this: ``` [ 1, and 2, and 3, and 4, ] ``` ---Files-------------------------------- 0001-Add-Oxford-Comma-support.patch (2.09 KB) -- https://bugs.ruby-lang.org/

4 3

[ruby-core:113080] [Ruby master Misc#17137] Cooperation on maintaining official docker ruby images
by hsbt (Hiroshi SHIBATA) 03 Apr '23

03 Apr '23

Issue #17137 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Misc #17137: Cooperation on maintaining official docker ruby images https://bugs.ruby-lang.org/issues/17137#change-102615 * Author: deivid (David Rodríguez) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- It was pointed out to me at https://github.com/docker-library/ruby/issues/323 that the ruby-core team has started maintaining their own docker images at https://github.com/ruby/ruby-docker-images, and that the base Dockerfiles were initially started from the official docker images. The maintainers of the official images would be interesting in collaborating on maintaining these images. Maybe merging the projects would be a nice idea from an end user point of view. I'm guessing there's a reason why https://github.com/ruby/ruby-docker-images was started as a separate project, but maybe any improvements over the official project could be merged back. The obvious new feature that I see in the README is the ability to build development images of specific revisions. Anyways, I mentioned the approach of the docker folks to hsbt and he told me to open a ticket here. So here it is! Regards! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113078] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_
by jeremyevans0 (Jeremy Evans) 02 Apr '23

02 Apr '23

Issue #4040 has been updated by jeremyevans0 (Jeremy Evans). I've updated my pull request to include additional optimizations for: * cfunc: 10-15* for f(*a) and 35-40% for f(*a, **kw) if kw is empty * send: 5-115% depending on type of call * symproc: 5-100% depending of type of call * method_missing: 10-115% depending on type of call The cfunc optimization works by copying the array contents to the stack instead of using CALLER_SETUP_ARG. The send, symproc, and method_missing optimizations are achieved by avoiding unnecessary use of CALLER_SETUP_ARG. Hopefully these additional optimizations help offset any performance decrease from the additional checks needed to fix this issue. ---------------------------------------- Bug #4040: SystemStackError with Hash[*a] for Large _a_ https://bugs.ruby-lang.org/issues/4040#change-102613 * Author: runpaint (Run Paint Run Run) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- =begin I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice. I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack... In IRB, the following is the minimal reproduction of this problem: Hash[*130648.times.map{ 1 }]; true I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces: ruby -e 'Hash[*1380888.times.map{ 1 }]' I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131. =end -- https://bugs.ruby-lang.org/

1 0

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

02 Apr '23

Issue #18368 has been updated by zverok (Victor Shepelev). @Dan0042 Can you please elaborate your question (especially considering its extremely strong wording)? This ticket is about changing the semantics of step to use `+` instead of `succ`, and Matz agreed to give it a try. How exactly do you imagine implementing the change without "pointlessly" breaking compatibility? Thanks in advance. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102612 * 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:113075] [Ruby master Feature#8460] PATCH: optparse: add `keep_unknown` option
by felipec (Felipe Contreras) 02 Apr '23

02 Apr '23

Issue #8460 has been updated by felipec (Felipe Contreras). File 0001-Add-keep_unknown-option.patch added File 0002-Move-dash-dash-handling-to-a-case.patch added File 0003-Properly-keep-dash-dash.patch added Subject changed from PATCH: optparse: add keep_unknown option to PATCH: optparse: add `keep_unknown` option Updated on top of master yet again. ---------------------------------------- Feature #8460: PATCH: optparse: add `keep_unknown` option https://bugs.ruby-lang.org/issues/8460#change-102608 * Author: felipec (Felipe Contreras) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- Currently people have to do very convoluted tricks, essentially making it impossible for optparse to keep unknown options. The safest and cleanest way is to do it in the code itself. [1] http://www.ruby-forum.com/topic/88081 [2] http://stackoverflow.com/questions/3642331/can-optparse-skip-unknown-option… ---Files-------------------------------- 0001-optparse-add-keep_unknown-option.patch (2.98 KB) 0002-optparse-move-dash-dash-handling-to-a-case.patch (1.42 KB) 0003-optparse-properly-keep-dash-dash.patch (1.23 KB) 0001-Add-keep_unknown-option.patch (2.79 KB) 0002-Move-dash-dash-handling-to-a-case.patch (1.28 KB) 0003-Properly-keep-dash-dash.patch (1.1 KB) -- https://bugs.ruby-lang.org/

1 0