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

[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

[ruby-core:113069] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 01 Apr '23

01 Apr '23

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 0

[ruby-core:113061] [Ruby master Feature#19565] Ignore lower-case/upper-case Proposal
by rubyFeedback (robert heiler) 01 Apr '23

01 Apr '23

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/

2 1