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

[ruby-core:113308] [Ruby master Bug#19611] Ruby hangs up with `while true && true`
by tompng (tomoya ishida) 06 May '23

06 May '23

Issue #19611 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19611: Ruby hangs up with `while true && true` https://bugs.ruby-lang.org/issues/19611 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [x86_64-darwin20] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Fails to run this code. It hangs up. Ctrl+C does not work. ~~~ruby def hoge while true && true end end ~~~ Compiling `while true && true; end` will also hangs up ~~~ruby irb(main):001:0> RubyVM::InstructionSequence.compile 'while true && true; end'; puts :done (no response) ~~~ -- https://bugs.ruby-lang.org/

4 5

[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