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

[ruby-core:113068] [Ruby master Feature#19567] Add Oxford Comma Support for better readability

by tenderlovemaking (Aaron Patterson)

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/

1 year, 1 month

4
3
0 0

[ruby-core:113080] [Ruby master Misc#17137] Cooperation on maintaining official docker ruby images

by hsbt (Hiroshi SHIBATA)

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 year, 1 month

1
0
0 0

[ruby-core:113033] [Ruby master Feature#19555] Allow passing default options to `Data.define`

by p8 (Petrik de Heus)

Issue #19555 has been reported by p8 (Petrik de Heus). ---------------------------------------- Feature #19555: Allow passing default options to `Data.define` https://bugs.ruby-lang.org/issues/19555 * Author: p8 (Petrik de Heus) * Status: Open * Priority: Normal ---------------------------------------- Defining a subclass of `Data` with default attributes can currently be implemented by overriding `intialize`: ```ruby class Point < Data.define(:x, :y, :z) def initialize(x:, y:, z: 0) = super end p Point.new(1, 2) #=> #<data Point x=1, y=2, z=0> ``` It would be nice if we could do it in `define` as well: ```ruby Point = Data.define(:x, :y, z: 0) ``` -- https://bugs.ruby-lang.org/

1 year, 1 month

3
4
0 0

[ruby-core:113078] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_

by jeremyevans0 (Jeremy Evans)

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 year, 1 month

1
0
0 0

[ruby-core:113076] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges

by zverok (Victor Shepelev)

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 year, 1 month

1
0
0 0

[ruby-core:113075] [Ruby master Feature#8460] PATCH: optparse: add `keep_unknown` option

by felipec (Felipe Contreras)

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 year, 1 month

1
0
0 0

[ruby-core:113069] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces

by marcper (Marcelo Pereira)

Issue #18743 has been updated by marcper (Marcelo Pereira). Hello @ko1, let me know if the patch in the current form is acceptable. Best, Marcelo ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-102602 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 year, 1 month

1
0
0 0

[ruby-core:113061] [Ruby master Feature#19565] Ignore lower-case/upper-case Proposal

by rubyFeedback (robert heiler)

Issue #19565 has been reported by rubyFeedback (robert heiler). ---------------------------------------- Feature #19565: Ignore lower-case/upper-case Proposal https://bugs.ruby-lang.org/issues/19565 * Author: rubyFeedback (robert heiler) * Status: Open * Priority: Normal ---------------------------------------- So, first april is on the horizon and in-before-we-go (nobu tends to make quick first april proposals, so let's hurry up!) It is here proposed to ignore case, that is, lower-case, and upper-case, at the least for method calls. This could be for variables too, but I don't care so much about variables. Rationale for the proposal: Given a method such as primary_link I typoed and wrote: primary_LINK Of course ruby complains and insists it must be written "primary_link". (I use that method for ad-hoc HTML hyperreferences in a webpage.) Wouldn't it be nice if we are able to ignore this, and simply assume that, at the least for method names, ruby would ignore the case, that is, whether it is downcased/lowercased or upper cased? Granted, the proposal is about 85% meant as a jest and joke, but the 15% is that this MAY be useful in SOME situations. Kind of like we had in oldschool evil.rb; I distinctly remember we could even change object identities at runtime too (I don't know what happened to evil.rb, but I distinctly remember we had it during the ruby 1.8.x era or so). I actually only propose this to be used on a per-file basis, to simplify it. So, for instance, you have a .rb file, and in that .rb file you need to tell ruby that you want to ignore the case. This could perhaps be via some configuration-call, such as: RbConfig.ignore_case Or something similar. Or more similar to IRB where we treat RbConfig as a Hash via [] e. g. RbConfig[:ignore_case] = true Or something similar like that. Right now there is no method defined on RbConfig, so this should not cause backwards incompatibility issues. Of course one can reason that this is 100% a rubbish proposal. That's ok. Easier to suggest it when it is close to the first april. :) PHP works like this if I recall correctly. Windows also ignores cases of e. g. binaries and directories if I recall correctly. So while this proposal may be rubbish, and as stated more of a joke, I believe there may be a few potential use cases of this too. Kind of like the ruby user telling ruby "ruby, I know by default you look at the case of characters, but for this specific file or project, I want you to ignore the case". (We could extend this to a whole namespace, e. g. per-module and per-class, but for this proposal I want to keep it simpler and just focus on a per-file basis, that is, on a per .rb basis. We could also add more magic comments such as it was with "# frozen_string_literal: true", but I think the ruby core team does not want to add more meta-meaning, so this probably would have zero chance to be implemented. So the focus on a per .rb file basis just seemed simpler to me for this proposal here.) -- https://bugs.ruby-lang.org/

1 year, 1 month

2
1
0 0

2024

2023

2022

ruby-core April 2023