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

[ruby-core:111264] [Ruby master Feature#19197] Add Exception#root_cause
by AMomchilov (Alexander Momchilov) 03 Jun '23

03 Jun '23

Issue #19197 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #19197: Add Exception#root_cause https://bugs.ruby-lang.org/issues/19197 * Author: AMomchilov (Alexander Momchilov) * Status: Open * Priority: Normal ---------------------------------------- ## Description I would like to add a `#root_cause` method to `Exception`. It returns the last exception in linked-list of causality chain, that is, the original exception (whose own `cause` is `nil`). ## Example ```ruby e = begin raise 'a' # This is the root cause rescue => a begin raise 'b' rescue => b begin raise 'c' # This is the outermost cause assigned to `e` rescue => c c end end end p(e) # => #<RuntimeError: c> p(e.cause) # => #<RuntimeError: b> p(e.cause.cause) # => #<RuntimeError: a> p(e.cause.cause.cause) # => nil p(e.root_cause) # => #<RuntimeError: a> p(e.root_cause.cause) # => nil ``` # Motivation There are some kinds of exceptions that can occur all over the place (and might be wrapped by arbitrarily many middlemen), but are attributable to a singular global cause. For example, a database outage could raise exceptions in almost every line of business logic of an app that uses ActiveRecord models. Fundamentally, you wouldn't want an error report for every one of these lines. You'd want to look at the root cause, and bucket all SQL-connection issues into a single report, regardless of where they surface. ### Implementation Draft PR: https://github.com/ruby/ruby/pull/6913 -- https://bugs.ruby-lang.org/

4 7

[ruby-core:112505] [Ruby master Bug#19452] `Thread::Backtrace::Location` should have column information if possible.
by ioquatix (Samuel Williams) 23 May '23

23 May '23

Issue #19452 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19452: `Thread::Backtrace::Location` should have column information if possible. https://bugs.ruby-lang.org/issues/19452 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I discussed this with @mame and it would be pretty useful if we could also get the column information from exception backtrace location, even if it was slow. A POC: ```ruby class Thread::Backtrace::Location if defined?(RubyVM::AbstractSyntaxTree) def first_column RubyVM::AbstractSyntaxTree.of(self, keep_script_lines: true).first_column end else def first_column raise NotImplementedError end end end ``` It would be good to have a standard interface, so we follow the same interface as https://bugs.ruby-lang.org/issues/19451 and vice versa where it makes sense. I'll investigate it. -- https://bugs.ruby-lang.org/

8 12

[ruby-core:112072] [Ruby master Bug#19386] `test_hmac.rb` of openssl is timeout on RHEL9
by hsbt (Hiroshi SHIBATA) 22 May '23

22 May '23

Issue #19386 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19386: `test_hmac.rb` of openssl is timeout on RHEL9 https://bugs.ruby-lang.org/issues/19386 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I prepared new test instance of RHEL9 for https://rubyci.org/. But it stuck with openssl tests. see http://rubyci.s3.amazonaws.com/rhel9/ruby-master/log/20230127T003004Z.fail.… I did bisect this issue. This issue caused by https://github.com/ruby/ruby/blob/master/test/openssl/test_hmac.rb#L23 ``` def test_dup h1 = OpenSSL::HMAC.new("KEY", "MD5") h1.update("DATA") h = h1.dup assert_equal(h1.digest, h.digest, "dup digest") end ``` Stuck is happened after running this test. /cc @vo.x @jaruga @rhenium -- https://bugs.ruby-lang.org/

7 13

[ruby-core:111566] [Ruby master Bug#19294] Enumerator.product works incorrectly with consuming enumerators
by zverok (Victor Shepelev) 14 May '23

14 May '23

Issue #19294 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #19294: Enumerator.product works incorrectly with consuming enumerators https://bugs.ruby-lang.org/issues/19294 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby s = StringIO.new('abc') Enumerator.product([1, 2, 3], s.each_char).to_a # Expected: => [[1, "a"], [1, "b"], [1, "c"], [2, "a"], [2, "b"], [2, "c"], [3, "a"], [3, "b"], [3, "c"]] # Actual: => [[1, "a"], [1, "b"], [1, "c"]] ``` The implementation consumes the non-first enumerator to produce the first combination. Somewhat related to the dilemma of consuming and non-consuming enumerators (#19061). PS: I noticed I don't understand why it is `Enumerator.product` and not `Enumerable#product`, but probably it is too late to raise the questions :( -- https://bugs.ruby-lang.org/

3 2

[ruby-core:111136] [Ruby master Bug#19168] "such file" is bad grammar
by masterleep2 (Bill Lipa) 12 May '23

12 May '23

Issue #19168 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #19168: "such file" is bad grammar https://bugs.ruby-lang.org/issues/19168 * Author: masterleep2 (Bill Lipa) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The error message for a missing required file has bad grammar: $ irb irb(main):001:0> require 'wuxx' <internal:/opt/local/lib/ruby3.1/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- wuxx (LoadError) The "such" should be removed. "cannot load file" reads more normally in English. -- https://bugs.ruby-lang.org/

7 6

[ruby-core:111792] [Ruby master Bug#19334] Defining many instance variables and accessing them is slow in Ruby 3.2.0
by mame (Yusuke Endoh) 10 May '23

10 May '23

Issue #19334 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #19334: Defining many instance variables and accessing them is slow in Ruby 3.2.0 https://bugs.ruby-lang.org/issues/19334 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal * Assignee: tenderlovemaking (Aaron Patterson) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` class C eval("def initialize; #{ (0..100000).map { "@x#{ _1 } = 0; " }.join } end") attr_reader :x50000 end p :start C.new.x50000 ``` This script takes less than one second in Ruby 3.1.3, and does more than ten second in Ruby 3.2.0. ``` $ time ruby -v test.rb ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] :start real 0m0.210s user 0m0.167s sys 0m0.044s ``` ``` $ time ruby -v test.rb ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] :start real 0m11.026s user 0m10.950s sys 0m0.040s ``` This problem is not critical, but is there any room for improvement? -- https://bugs.ruby-lang.org/

6 11

[ruby-core:111309] [Ruby master Bug#19238] URI.open fails for file path when second argument is a hash
by dkinzer (David Kinzer) 10 May '23

10 May '23

Issue #19238 has been reported by dkinzer (David Kinzer). ---------------------------------------- Bug #19238: URI.open fails for file path when second argument is a hash https://bugs.ruby-lang.org/issues/19238 * Author: dkinzer (David Kinzer) * Status: Open * Priority: Normal * ruby -v: 3.0, 3.1 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I upgraded one of my projects to ruby 3.1.3 and I found that `URI.open` now throws an error when passed a second argument when the first argument is a file path. When the first argument is a URL, then URI.open will work as expected. I was able to replicate this issue in all 3.x versions including the latest so it's an issue that was introduce with the release of 3.0 I found it convenient that `URI.open(uri, {})`, worked regardless of wether uri was a file path or a URL because it meant I did not have to add logic for varying cases. When the uri argument was a file path URI.open would simply open up the file and disregard the hash options params. But now I have to add that logic myself which is not as clean looking. Below is an example of the error. It's quite easy to reproduce on any version of ruby 3.x ``` URI.open("spec/fixtures/blogs.json", {}) /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `initialize': no implicit conversion of Hash into String (TypeError) from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `open' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/open-uri.rb:31:in `open' from (irb):9:in `<main>' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>' from /Users/dkinzer/.rbenv/versions/3.1.3/bin/irb:25:in `load' from /Users/dkinzer/.rbenv/versions/3.1.3/bin/irb:25:in `<top (required)>' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:58:in `load' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:58:in `kernel_load' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli/exec.rb:23:in `run' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:486:in `exec' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:31:in `dispatch' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start' from /Users/dkinzer/.rbenv/versions/3.1.3/lib/ruby/3.1.0/bundler/cli.rb:25:in `start' ... 5 levels... ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112329] [Ruby master Misc#19431] DevMeeting at RubyKaigi 2023
by mame (Yusuke Endoh) 10 May '23

10 May '23

Issue #19431 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19431: DevMeeting at RubyKaigi 2023 https://bugs.ruby-lang.org/issues/19431 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- RubyKaigi 2023 will be at Matsumoto, Japan, May 11th - 13th. I would like to try to hold a face-to-face dev meeting at Matsumoto. (@matz will also participate!) Date: 2023/05/10 (Wed.) 14:00-18:00 (The day before RubyKaigi) Location: A meeting room in [Matsumoto Performing Arts Centre](https://www.mpac-en.com/about) (in the RubyKaigi venue, detailed location TBA) ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. If you would like to participate, please comment on this ticket so that we can get a headcount. ### Call for agenda If you want to give a talk at the meeting, please raise your agenda on this ticket. I recommend you to file a ticket of your proposal ahead of time. ### Meeting format Depending on the number of talks, we plan to spend approximately half the time on the talks and the remaining time triaging and discussing open tickets. (However, the schedule may change.) ### Disclaimer We may cancel the meeting depending on the situation, such as due to COVID-19. -- https://bugs.ruby-lang.org/

33 34

[ruby-core:112398] [Ruby master Feature#19435] Expose counts for each GC reason in GC.stat
by byroot (Jean Boussier) 09 May '23

09 May '23

Issue #19435 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19435: Expose counts for each GC reason in GC.stat https://bugs.ruby-lang.org/issues/19435 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context We recently tuned the GC settings on our monolith application because we were seeing some very long GC pauses (multiple seconds) during some requests. Very early we realized that we could know how often the GC was triggered, and how long it was taking, but we had no information as to why, hence no good way to know which specific configuration to tune. As of today, the only way to get this information is to compile Ruby with debug counters, but that's not really accessible for most users, and not very suitable to be deployed in production. So we patched our Ruby to expose counters for each specific reason in `GC.stat` and this data was extremely valuable. For instance we discovered that the number 1 cause of major GC was `shady` objects, which allowed us to both better tune or GC and to drive some targeted patches to Ruby. ### Proposal We'd like to merge the patch we used on our Ruby build. It expose 8 new keys in `GC.stat`: - `:major_gc_nofree_count` - `:major_gc_oldgen_count` - `:major_gc_shady_count` - `:major_gc_newobj_count` - `:major_gc_malloc_count` - `:major_gc_oldmalloc_count` - `:minor_gc_newobj_count` - `:minor_gc_malloc_count` Some very uncommon reasons like `force` etc are ignored as they're not valuable. Also note that sometimes multiple conditions can be met to trigger GC, in such case we my increment several counters, so the sum of `major_gc_*_count` can be higher than `major_gc_count`. Proposed patch: https://github.com/ruby/ruby/pull/7250 -- https://bugs.ruby-lang.org/

6 9

[ruby-core:112183] [Ruby master Bug#19401] [Doc] Broken links in CSV documentation
by eightbitraptor (Matthew Valentine-House) 19 Apr '23

19 Apr '23

Issue #19401 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #19401: [Doc] Broken links in CSV documentation https://bugs.ruby-lang.org/issues/19401 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The link "Recipes for CSV" on [this page](https://docs.ruby-lang.org/en/master/CSV.html) points to a broken link: [https://docs.ruby-lang.org/en/master/csv/recipes/recipes_rdoc.html](https:/…. It doesn't look like the intended target `doc/csv/recipes/recipes.rdoc` is being included in the rdoc output. There isn't an equivalent HTML file generated in `.ext/html` after I run `make doc` -- https://bugs.ruby-lang.org/

2 2