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

[ruby-core:114785] [Ruby master Bug#19886] "default->bundled gem" warning is not shown under "bundle exec"
by mame (Yusuke Endoh) 06 Dec '23

06 Dec '23

Issue #19886 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19886: "default->bundled gem" warning is not shown under "bundle exec" https://bugs.ruby-lang.org/issues/19886 * Author: mame (Yusuke Endoh) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ cat Gemfile source "https://rubygems.org" $ cat test.rb require "base64" $ bundle exec ruby test.rb $ ``` In this situation, `bundle exec ruby test.rb` should print a warning: base64 which will be not part of the default gems since Ruby 3.4.0. Note that `ruby test.rb` shows the warning, which is not needed (see #19885). ``` $ ruby test.rb test.rb:1: warning: base64 which will be not part of the default gems since Ruby 3.4.0 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115484] [Ruby master Bug#20022] GC.verify_compaction_references does not actually move alll objects
by kjtsanaktsidis (KJ Tsanaktsidis) 03 Dec '23

03 Dec '23

Issue #20022 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20022: GC.verify_compaction_references does not actually move alll objects https://bugs.ruby-lang.org/issues/20022 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- While debugging https://bugs.ruby-lang.org/issues/20021, I ran into a separate issue which I figured was worth resolving whilst I had it in my head. The intention of GC.verify_compaction_references is, I believe, to force every single movable object to be moved, so that it's possible to debug native extensions which not correctly updating their references to objects they mark as movable (if this is _not_ the case, you can stop reading now and accept my apologies!) To do this, it doubles the number of allocated pages for each size pool, and sorts the heap pages so that the free ones are swept first; thus, every object in an old page should be moved into a free slot in one of the new pages. This worked fine until movement of objects between size pools during compaction was implemented. That causes some problems for verify_compaction_references: - We were doubling the number of pages in each size pool, but actually if some objects need to move into a different pool, there's no guarantee that they'll be enough room in that one. - It's possible for the sweep & compact cursors to meet in one size pool before all the objects that want to move into that size pool from another are processed by the compaction. You can see these problems by changing some of the movement tests in test_gc_compact.rb to try and move e.g. 50,000 objects instead of 500 (by changing `HASH_COUNT`); the test is not able to actually move all of the objects in a single compaction run. What I implemented in this PR (https://github.com/ruby/ruby/pull/9041) is two things: - Firstly, it examines every object and determine where it wants to be compacted into; we use this information to calculate the desired number of pages to add to each size pool. - Secondly, it compacts twice; once in order of ascending size pool, and once descending. This means that we are guaranteed to be able to move everything we want to move into a size pool before we start advancing that pool's own compact cursor. With these fixes in place, I was able to make the compaction tests move any amount of objects (previously, `test_moving_hashes_down_size_pools` would begin failing on my machine if I set `HASH_COUNT` to above about 6,000. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:115546] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by Eregon (Benoit Daloze) 30 Nov '23

30 Nov '23

Issue #19117 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-21: > * How much impact does exception generation have on performance? (Each frame of the backtrace needs to maintain self) That's a good point. While the method name can be stored in the bytecode or so, not so much for the module name (especially since it can get a proper name later). In many cases it can be known statically or is the same when defining the method, but not always (e.g. `MyStruct = Struct.new(:x) { def foo; end; }`). Maybe we should only use this notation when the module name is known statically? ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-105481 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115541] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by byroot (Jean Boussier) 30 Nov '23

30 Nov '23

Issue #19117 has been updated by byroot (Jean Boussier). Target version set to 3.4 Agreed. I took the liberty to create a 3.4 target version and add it. ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-105476 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115539] [Ruby master Feature#19117] Include the method owner in backtraces, not just the method name
by mame (Yusuke Endoh) 30 Nov '23

30 Nov '23

Issue #19117 has been updated by mame (Yusuke Endoh). Let's discuss this towards Ruby 3.4 :cry: ---------------------------------------- Feature #19117: Include the method owner in backtraces, not just the method name https://bugs.ruby-lang.org/issues/19117#change-105474 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ``` module Foo class Bar def inspect 1 + '1' end end end p Foo::Bar.new ``` This code produce the following backtrace: ``` /tmp/foo.rb:4:in `+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `inspect' from /tmp/foo.rb:9:in `p' from /tmp/foo.rb:9:in `<main>' ``` This works, but on large codebases and large backtraces the method name isn't always all that revealing, most of the time you need to open many of the locations listed in the backtrace to really understand what is going on. I propose that we also include the owner name: ``` /tmp/foo.rb:4:in `Integer#+': String can't be coerced into Integer (TypeError) from /tmp/foo.rb:4:in `Foo::Bar#inspect' from /tmp/foo.rb:9:in `Kernel#p' from /tmp/foo.rb:9:in `<main>' ``` I believe that in many case it would allow to much better understand the backtrace without having to jump back and forth between it and the source code. This is inspired by @ivoanjo 's `backtracie` gem: https://github.com/ivoanjo/backtracie -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115537] [Ruby master Bug#16145] regexp match error if mixing /i, character classes, and utf8
by zenspider (Ryan Davis) 30 Nov '23

30 Nov '23

Issue #16145 has been updated by zenspider (Ryan Davis). @duerst I don't think your intuition about the character classes is correct: ``` ruby "CAFÉ" =~ /[a]/i # => 1 ``` ---------------------------------------- Bug #16145: regexp match error if mixing /i, character classes, and utf8 https://bugs.ruby-lang.org/issues/16145#change-105473 * Author: zenspider (Ryan Davis) * Status: Open * Priority: Normal * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- (reported on behalf of mage(a)mage.gold -- there appears to be an error in registration or login): See: ruby-talk @ X-Mail-Count: 440336 2.6.3 :049 > 'SHOP' =~ /[xo]/i => 2 2.6.3 :050 > 'CAFÉ' =~ /[é]/i => 3 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => nil 2.6.3 :052 > 'CAFÉ' =~ /[xÉ]/i => 3 Expected result: 2.6.3 :051 > 'CAFÉ' =~ /[xé]/i => 3 I tested it on random regex online pages. It does not match on https://regex101.com/ It matches on: https://regexr.com/ https://www.regextester.com/ https://www.freeformatter.com/regex-tester.html (Ignore case turned on). The reason I suppose it’s more like a bug than a feature is the fact that /[é]/i matches 'CAFÉ'. If the //i didn’t work for UTF-8 characters then the /[é]/i wouldn’t match it either. For example, [é] does not match 'CAFÉ' on https://regex101.com/ I could not find a page or a system that behaves the same way as Ruby does. For example, it matches in PostgreSQL 10 (under FreeBSD 12) too: # select 'CAFÉ'~ '[xé]'; ?column? ---------- f (1 row) # select 'CAFÉ' ~* '[xé]'; ?column? ---------- t (1 row) Tested it in IRB on macOS and FreeBSD. $ uname -a && ruby -v && locale Darwin xxx 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 20 18:42:21 PDT 2019; root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-darwin18] LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8" $ uname -a && ruby -v && locale FreeBSD xxx 12.0-RELEASE-p9 FreeBSD 12.0-RELEASE-p9 GENERIC amd64 ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-freebsd12.0] LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 I installed Ruby with RVM. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115446] [Ruby master Misc#20015] Privacy policy for ruby-lang.org
by hsbt (Hiroshi SHIBATA) 30 Nov '23

30 Nov '23

Issue #20015 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #20015: Privacy policy for ruby-lang.org https://bugs.ruby-lang.org/issues/20015 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- We got the request to add privacy policy page on ruby-lang.org at https://github.com/ruby/www.ruby-lang.org/issues/3134 I put a draft page: https://github.com/ruby/www.ruby-lang.org/pull/3144 We will discuss about this in dev meeting with Matz before deploy that. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification
by kyanagi (Kouhei Yanagita) 30 Nov '23

30 Nov '23

Issue #19588 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Feature #19588: Allow Comparable#clamp(min, max) to accept nil as a specification https://bugs.ruby-lang.org/issues/19588 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- `Comparable#clamp(min, max)` (with two arguments) accepts `nil`. This behaves the same as beginless/endless Range. ~~~ruby 5.clamp(nil, 0) # => 0 5.clamp(10, nil) # => 10 5.clamp(..0) # => 0 5.clamp(10..) # => 10 ~~~ This behavior is not documented. Presumably, this was not introduced intentionally. The old Rubies did not accept accept a `Range` argument. In Ruby 2.7, accepting `Range` as an argument was introduced. At that time, the approach of passing `nil` as a two-argument method was also discussed but not adopted, and using Range was chosen instead. https://bugs.ruby-lang.org/issues/14784 However, in Ruby 3.0, the behavior of `clamp` has changed to accept `nil`. This change is not documented in the NEWS or the documentation for `clamp`, and I believe that it was not an intentional change. ~~~ % docker run -it --rm rubylang/all-ruby env ALL_RUBY_SINCE=ruby-2.4.0 ./all-ruby -e "p 5.clamp(0, nil)" ruby-2.4.0 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ... ruby-2.7.8 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ruby-3.0.0-preview1 5 ... ruby-3.2.2 5 ~~~ It seems that https://github.com/ruby/ruby/commit/a93da4970be44a473b7b42e7516eb2663dece2c3 brought about this change. How about making the current behavior a specification? It has been three years since the behavior changed, and I don't see much point in prohibiting `nil` now. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:115071] [Ruby master Misc#19931] to_int is not for implicit conversion?
by Dan0042 (Daniel DeLorme) 29 Nov '23

29 Nov '23

Issue #19931 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Misc #19931: to_int is not for implicit conversion? https://bugs.ruby-lang.org/issues/19931 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- While reviewing some implicit vs explicit conversion concepts, I discovered that arithmetic operations do not perform the implicit conversion I expected from #to_int ```ruby o = Object.new def o.to_int; 1; end 1 + o #TypeError ``` I understand there's the whole #coerce thing for numbers, but I had expected #to_int to fit neatly into this and cause the object to be implicitly coerced to Integer. So basically I thought that #to_i was for explicit conversion and #to_int for implicit conversion; is that not the case? Most of the internet seems to think that (to_int : to_i) relationship is like (to_str : to_s). But I can't seems to find authoritative documentation on the topic. -- https://bugs.ruby-lang.org/

9 15

[ruby-core:115517] [Ruby master Bug#20026] Ruby doesn't throw a syntax error when rescuing with ||
by arian (Arian Faurtosh) 29 Nov '23

29 Nov '23

Issue #20026 has been reported by arian (Arian Faurtosh). ---------------------------------------- Bug #20026: Ruby doesn't throw a syntax error when rescuing with || https://bugs.ruby-lang.org/issues/20026 * Author: arian (Arian Faurtosh) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- We had a coworker new to ruby try an interesting syntax for rescue that doesn't result in a syntax error, and works partially. Why does ruby allow the logical OR || operator, is there a purpose for this? If not this feels like it should be a syntax error, instead of resulting in partially working code. ``` ruby class FooError < StandardError; end class BarError < StandardError; end # works begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end # doesn't work begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end ``` -- https://bugs.ruby-lang.org/

2 2