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

[ruby-core:113383] [Ruby master Feature#19626] Alias Base64 methods to non-64 suffixed methods
by ryanbigg (Ryan Bigg) 02 May '23

02 May '23

Issue #19626 has been reported by ryanbigg (Ryan Bigg). ---------------------------------------- Feature #19626: Alias Base64 methods to non-64 suffixed methods https://bugs.ruby-lang.org/issues/19626 * Author: ryanbigg (Ryan Bigg) * Status: Open * Priority: Normal ---------------------------------------- Long time Ruby user, first time issue poster. Apologies if this isn't the correct process of proposing this sort of change. Redirect me somewhere else if I need to be. I'd like to propose aliasing the methods in the Base64 module to new methods: Base64.encode64 -> Base64.encode Base64.decode64 -> Base64.decode etc. I am guessing that this suffix was used to prevent issues where `Base64` was included into a class and would (potentially) clash with that class's own `decode` and `encode` methods. This is not how `Base64` has been used in my experience -- it's typically a call to the method such as `Base64.encode64`. But maybe my experience of Ruby is unique in that way. I would still like to open this issue at least to start a potential discussion about these potential aliases, or at least documenting solid reasons why the 64 suffix has to stick. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113378] [Ruby master Feature#8707] Hash#reverse_each
by bughit (bug hit) 28 Apr '23

28 Apr '23

Issue #8707 has been updated by bughit (bug hit). Another point is that that hash.reverse_each already exists via enumerable, but with a highly suboptimal array conversion. If it didn't exist you could perhaps debate whether it should be added, but that's moot at this point. The only question here is whether hash.reverse_each should be a hidden perf land-mine or have an optimal implementation for a Hash. Seems like a no-brainer. ---------------------------------------- Feature #8707: Hash#reverse_each https://bugs.ruby-lang.org/issues/8707#change-102948 * Author: Glass_saga (Masaki Matsushita) * Status: Feedback * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently, {}.reverse_each calls Enumerable#reverse_each. It will make array and its size can be large. I made Hash#reverse_each to avoid array creation and performance improvement. benchmark: require "benchmark" Size = 10000 HASH = Hash[*Array.new(Size) {|i| [i, true] }.flatten] Benchmark.bmbm do |x| x.report("Hash#reverse_each") do 300.times do HASH.reverse_each {|a, b|} end end end result: trunk(r42256): Rehearsal ----------------------------------------------------- Hash#reverse_each 1.210000 0.000000 1.210000 ( 1.207964) -------------------------------------------- total: 1.210000sec user system total real Hash#reverse_each 0.950000 0.000000 0.950000 ( 0.951069) proposal: Rehearsal ----------------------------------------------------- Hash#reverse_each 0.600000 0.000000 0.600000 ( 0.600242) -------------------------------------------- total: 0.600000sec user system total real Hash#reverse_each 0.450000 0.000000 0.450000 ( 0.459006) ---Files-------------------------------- patch.diff (7.55 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113376] [Ruby master Bug#19622] Undocumented behavior of Array#& and similar methods
by tycooon (Yuri Smirnov) 28 Apr '23

28 Apr '23

Issue #19622 has been reported by tycooon (Yuri Smirnov). ---------------------------------------- Bug #19622: Undocumented behavior of Array#& and similar methods https://bugs.ruby-lang.org/issues/19622 * Author: tycooon (Yuri Smirnov) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Currently, the docs only state that the objects are compared using `eql?` method. However, it turns out that if arrays are "big" (size more than `SMALL_ARRAY_LEN`), then the hash is used so things stop working unless you also redefine `hash` method. I know that there is information regarding that in the `eql?` method docs (see https://ruby-doc.org/3.2.2/Object.html#method-i-eql-3F) however it's very likely that people will just go ahead and define the `eql?` method and everything will work until some point in time. So I think it would be great to update the docs for Array method `&`, `intersection` and `intersect?` to clearly state that both `eql?` and `hash` methods are used. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113342] [Ruby master Feature#19617] Add Method#binding and UnboundMethod#binding, similar to Proc#binding
by nevans (Nicholas Evans) 28 Apr '23

28 Apr '23

Issue #19617 has been reported by nevans (Nicholas Evans). ---------------------------------------- Feature #19617: Add Method#binding and UnboundMethod#binding, similar to Proc#binding https://bugs.ruby-lang.org/issues/19617 * Author: nevans (Nicholas Evans) * Status: Open * Priority: Normal ---------------------------------------- When a method is defined dynamically with `define_method`, it would be useful to obtain access to the defining block's binding and the local variables it has captured, based on the defining block's binding. For methods defined using the `def` keyword, the binding's local variables might be empty or might be all of the names in the method's locals table, with all values set to `nil`. For UnboundMethod, it is unclear (to me) what the appropriate receiver for the binding would be, so perhaps `unbound.binding.receiver` should raise an exception. Alternatively (or additionally), something like `Method#defining_proc` and `UnboundMethod#defining_proc` might be added and return `nil` for `def` definitions and the proc for `define_method` definitions. This would be a useful tool when debugging from the console. As another example, it might be used to scan a code base for dynamically generated regexps which are only reachable via the enclosed local variables and test that they are all linear time (see https://github.com/ruby/net-imap/blob/92db350b24c388d2a2104f36cac9caa49a104…) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:113372] [Ruby master Bug#19621] Resolv::Hosts uses ineffective File.read, making using big hosts file 'impossible'
by felix.wolfsteller＠betterplace.org (Felix Wolfsteller) 28 Apr '23

28 Apr '23

Issue #19621 has been reported by felix.wolfsteller(a)betterplace.org (Felix Wolfsteller). ---------------------------------------- Bug #19621: Resolv::Hosts uses ineffective File.read, making using big hosts file 'impossible' https://bugs.ruby-lang.org/issues/19621 * Author: felix.wolfsteller(a)betterplace.org (Felix Wolfsteller) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- By default, `Resolv` will read `/etc/hosts` once. Privacy- and security aware people might use the file to prevent unwanted traffic, developers use it to quickly manipulate address resolution. `Resolv::Hosts` uses [`IO.read`](https://github.com/betterplace/ruby/blob/9b07d30df8c6bf65c2558c023fd6452405915610/lib/resolv.rb#LL195C4-L195C4), which seems to be inefficient when dealing with large amounts of data that should be consumed by line. E.g. if you install the `/etc/hosts` additions by [hblock](https://hblock.molinero.dev/hosts) (https://github.com/hectorm/hblock) the first call to resolve an address will likely take **minutes**. We believe the solution is easy: Use streaming `IO.foreach` (see patch and PR attached). Benchmarking with examplary /etc/host from xyz done like this ``` require 'resolv' require 'benchmark' Benchmark.measure do Resolv::Hosts.new.lazy_initialize end ``` With `read`: ... With `foreach`: ... -- https://bugs.ruby-lang.org/

1 1

[ruby-core:113371] [Ruby master Feature#12165] Hash#first, Hash#last
by nobu (Nobuyoshi Nakada) 28 Apr '23

28 Apr '23

Issue #12165 has been updated by nobu (Nobuyoshi Nakada). stillhart (Fabian Stillhart) wrote: > Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? It is [`Enumerable#first`](https://docs.ruby-lang.org/en/3.2/Enumerable.html#method-i-first). ```ruby p Hash.instance_method(:first) #=> #<UnboundMethod: Enumerable#first(*)> ``` ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-102937 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113368] [Ruby master Feature#8707] Hash#reverse_each
by bughit (bug hit) 27 Apr '23

27 Apr '23

Issue #8707 has been updated by bughit (bug hit). > Do we really need it? What is use-cases? When you have an ordered collection it seems self evident that you may need to iterate in reverse. This would for example back a performant `last(n = 1)` method (#12165) Would you demand to know why one may want the last n elements of an array? These are both ordered collections, if `last(n = 1)` makes sense for one, it makes sense for the other. Why is this closed with a status of "Feedback"? ---------------------------------------- Feature #8707: Hash#reverse_each https://bugs.ruby-lang.org/issues/8707#change-102934 * Author: Glass_saga (Masaki Matsushita) * Status: Feedback * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently, {}.reverse_each calls Enumerable#reverse_each. It will make array and its size can be large. I made Hash#reverse_each to avoid array creation and performance improvement. benchmark: require "benchmark" Size = 10000 HASH = Hash[*Array.new(Size) {|i| [i, true] }.flatten] Benchmark.bmbm do |x| x.report("Hash#reverse_each") do 300.times do HASH.reverse_each {|a, b|} end end end result: trunk(r42256): Rehearsal ----------------------------------------------------- Hash#reverse_each 1.210000 0.000000 1.210000 ( 1.207964) -------------------------------------------- total: 1.210000sec user system total real Hash#reverse_each 0.950000 0.000000 0.950000 ( 0.951069) proposal: Rehearsal ----------------------------------------------------- Hash#reverse_each 0.600000 0.000000 0.600000 ( 0.600242) -------------------------------------------- total: 0.600000sec user system total real Hash#reverse_each 0.450000 0.000000 0.450000 ( 0.459006) ---Files-------------------------------- patch.diff (7.55 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113367] [Ruby master Feature#12165] Hash#first, Hash#last
by bughit (bug hit) 27 Apr '23

27 Apr '23

Issue #12165 has been updated by bughit (bug hit). Hash should absolutely have a performant last method that doesn't build an intermediate array (`hash.(values|keys).last`). This is connected to having a performant reverse_each (#8707) ---------------------------------------- Feature #12165: Hash#first, Hash#last https://bugs.ruby-lang.org/issues/12165#change-102933 * Author: stillhart (Fabian Stillhart) * Status: Open * Priority: Normal ---------------------------------------- Just run into a simple problem with a colleague and was wondering why there is no Hash#last method? ~~~ruby {a: true, b: false}.last NoMethodError: undefined method 'last' for {:a=>true, :b=>false}:Hash ~~~ Interestingly I while playing arround I found out that the Hash#first method works. But why is it not in the ruby-doc? ~~~ruby {a: true, b: false}.first => [:a, true] ~~~ I would assume the Hash#last method would work like the Hash#first method: ~~~ruby {a: true, b: false}.last => [:b, false] ~~~ If I am not wrong the order of a Hash is always the same when calling Hash#each. So wouldn't it make sense to have Hash#last method? I tested it in Ruby 2.2.4 and Ruby 2.3.0. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113363] [Ruby master Feature#19620] allow non-module rescue filters that implement the === opertor
by bughit (bug hit) 27 Apr '23

27 Apr '23

Issue #19620 has been reported by bughit (bug hit). ---------------------------------------- Feature #19620: allow non-module rescue filters that implement the === opertor https://bugs.ruby-lang.org/issues/19620 * Author: bughit (bug hit) * Status: Open * Priority: Normal ---------------------------------------- ```ruby module FooErrorFilter def self.===(e) e.message =~ /foo/ end end def foo_error_filter FooErrorFilter end begin raise 'foo error' rescue foo_error_filter => e p e.message end ``` Filter matching is done via the `===` operator, which is why the rescue filter modules don't need to be exception classes. But they are required to be modules, why? Since the rescue filter object is only used for the `===` operator it should accept any object supporting it. The module restriction seems arbitrary and pointless. ```ruby begin raise 'foo error' rescue ->e{e.message =~ /foo/} p e.message end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113283] [Ruby master Bug#19606] addr2line.c broken on Fedora 38
by kjtsanaktsidis (KJ Tsanaktsidis) 26 Apr '23

26 Apr '23

Issue #19606 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #19606: addr2line.c broken on Fedora 38 https://bugs.ruby-lang.org/issues/19606 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I'm running the Fedora 38 beta on my machine, and the Ruby crash reporter is itself crashing while trying to print C-level backtraces, with an error like this: ``` -- C level backtrace information ------------------------------------------- 1344: Abbrev Number 27547 not found ``` This seems to happen because the debuginfo provided by Fedora 38 (for e.g. the libc frames) is compressed with dwz. Some debginfo is shared between multiple files, and a reference to the shared file is put in the `.gnu_debugaltlink` attribute of the debug object. Then, the main debug object contains forms of type `DW_FORM_GNU_ref_alt` and `DW_FORM_GNU_strp_alt`, whose values will refer to offsets inside the debugaltlink file. For example, libc symbols contain a `.gnu_debugaltlink` section ``` % readelf -x .gnu_debugaltlink /usr/lib/debug/lib64/libc.so.6-2.37-1.fc38.x86_64.debug Hex dump of section '.gnu_debugaltlink': 0x00000000 2e2e2f2e 64777a2f 676c6962 632d322e ../.dwz/glibc-2. 0x00000010 33372d31 2e666333 382e7838 365f3634 37-1.fc38.x86_64 0x00000020 002a30a8 c71ff2fd aa58a637 226c0f56 .*0......X.7"l.V 0x00000030 3ffd674a de ?.gJ. ``` Some DWARF abbrev's contain references to this shared data: ``` % readelf --debug-dump /usr/lib/debug/lib64/libc.so.6-2.37-1.fc38.x86_64.debug ... Contents of the .debug_abbrev section (loaded from /usr/lib/debug/lib64/libc.so.6-2.37-1.fc38.x86_64.debug): ... 50 DW_TAG_typedef [no children] DW_AT_name DW_FORM_GNU_strp_alt DW_AT_decl_file DW_FORM_data1 DW_AT_decl_line DW_FORM_data1 DW_AT_decl_column DW_FORM_data1 DW_AT_type DW_FORM_GNU_ref_alt DW_AT value: 0 DW_FORM value: 0 ... ``` Because addr2line.c doesn't know how to read these `DW_FORM_GNU_*` forms in `debug_info_reader_read_value`, it doesn't advance the reader at all and so the DWARF parsing becomes confused. This can lead to a garbage abbrev number being read, or even to just straight up segfaults. I have a patch which simply skips over the right number of bytes for these forms, without actually reading any of the data: https://github.com/ruby/ruby/pull/7731. This was sufficient to make the crash reporter work again properly on my machine. _Technically_ speaking, perhaps we should _actually_ open the `.gnu_debugaltlink` file and dig out the referenced attribute value - this would be required if filename strings were put into the shared dwz info with `DW_FORM_GNU_strp_apt`. If you think this is necessary I can try and put together a follow up patch to do this. However I've not actually seen a debuginfo file that does this, yet. -- https://bugs.ruby-lang.org/

1 1