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

[ruby-core:111225] [Ruby master Bug#19189] Ruby 3.1.3/3.2.x can no longer find pkg-config if not present at buildtime
by mistydemeo (Misty De Meo) 23 Feb '23

23 Feb '23

Issue #19189 has been reported by mistydemeo (Misty De Meo). ---------------------------------------- Bug #19189: Ruby 3.1.3/3.2.x can no longer find pkg-config if not present at buildtime https://bugs.ruby-lang.org/issues/19189 * Author: mistydemeo (Misty De Meo) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Starting with Ruby 3.1.3, mkmf.rb calls to `pkg-config` will fail if `pkg-config` wasn't present on the system at the time it was built. Prior to that version, even if Ruby itself wasn't configured with `pkg-config`, mkmf.rb would be able to correctly pick it up from the `PATH`. This was introduced by https://github.com/ruby/ruby/commit/7f1ca666424849134990d022266bcd4d6636465f and its Ruby 3.1.3 equivalent, https://github.com/ruby/ruby/commit/3914581213e3aea138b02941b41e62c15461af27. I've confirmed that reverting this specific change fixes the problem. This broke a Ruby deployment which is built in a minimal Docker environment with no `pkg-config`, but which is later copied into a system with `pkg-config` present. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:112550] [Ruby master Bug#18629] block args array splatting assigns to higher scope _ var
by nagachika (Tomoyuki Chikanaga) 23 Feb '23

23 Feb '23

Issue #18629 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED to 2.7: REQUIRED, 3.0: REQUIRED, 3.1: DONE ruby_3_1 536f5ba0d48c033e63398d1751aebd0a11bcc6ff merged revision(s) 3ddf6ad4d2f6dae4caa00b8c407768c7062099a0. ---------------------------------------- Bug #18629: block args array splatting assigns to higher scope _ var https://bugs.ruby-lang.org/issues/18629#change-101997 * Author: Nakilon (Victor Maslov) * Status: Closed * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: DONE ---------------------------------------- ``` ruby v = 1; [[2]].each{ |(v)| }; p v _ = 1; [[2]].each{ |(_)| }; p _ ``` prints ``` 1 2 ``` You can see here that `v` is still `1` but `_` isn't shadowed properly and is being assigned `2`. Reproducible from 2.3.8 to 3.0.2 (macOS rbenv) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112549] [Ruby master Bug#18765] Wrong description introduced by https://github.com/ruby/ruby/pull/4938/files
by nagachika (Tomoyuki Chikanaga) 23 Feb '23

23 Feb '23

Issue #18765 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: DONTNEED, 3.0: DONTNEED, 3.1: REQUIRED to 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONE ruby_3_1 9f072e9ae1bae2d76334c9e97a47280779768859 merged revision(s) 8038d5e40a079d60dfcf7cab1155528959760c28. ---------------------------------------- Bug #18765: Wrong description introduced by https://github.com/ruby/ruby/pull/4938/files https://bugs.ruby-lang.org/issues/18765#change-101996 * Author: sawa (Tsuyoshi Sawada) * Status: Closed * Priority: Normal * Assignee: burdettelamar(a)yahoo.com (Burdette Lamar) * ruby -v: 3.1.0 * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONE ---------------------------------------- Commit https://github.com/ruby/ruby/pull/4938/files introduced problems and made the description wrong. 1) For methods `slice_after` and `slice_when`, it introduces expressions like "partition elements into arrays ('slices')", and for method `chunk_while`, "partition elements into arrays ('chunks')". It suggests to call the resulting elements using different words depending on the name of the method. But that does not make sense. They are all simply arrays, and there is no need to distinguish a "slice array" from a "chunk array". (They can all be called an "array", "slice", or "chunk", or whatever.) Perhaps, it is attempting to explain where the method names came from, under the assumption that the words "slice" and "chunk" in these method names are nouns. If so, that is wrong. The succeeding parts "when (block)" and "while (block)" are (to correspond to English) adverbial clauses, not adjectival (relative) clauses; hence, these "slice" and "chunk" must be interpreted as verbs, not nouns. In fact, "a slice when y is not a successor of x" or "a chunk while y is a successor of x" does not make sense, whereas "slice it when y is not a successor of x" and "chunk them while y is a successor of x" do make sense. The difference between the "slice" and "chunk" methods lies in the process, not the return value. If you want to use these words, it can be something like "slice the receiver into arrays when the block returns a truthy value" and "chunk the elements together while the block returns a truthy value". 2) In the description of `slice_when` and `chunk_while`, it says "it calls the block with each element and its successor", but that is not true. If you are going to phrase it that way, then it only calls each element except for the last one. 3) In the description of `slice_when`, it says "begins a new slice if and only if the block returns a truthy value", but that is not true. Regardless of the value of the block, the first element always begins a new "slice". 4) Most crucially, in the description of `chunk_while`, the expression "begins a new chunk if and only if the block returns a truthy value" is entirely wrong. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111053] [Ruby master Bug#19158] Ruby 3.1.3 installs wrong gemspec for debug gem
by deivid 23 Feb '23

23 Feb '23

Issue #19158 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #19158: Ruby 3.1.3 installs wrong gemspec for debug gem https://bugs.ruby-lang.org/issues/19158 * Author: deivid (David Rodríguez) * 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 ---------------------------------------- A pristine installation of Ruby 3.1.3 shows an installed `debug-1.6.3.gemspec` file that claims that debug-1.6.3 has no dependencies. This is incorrect, and causes issues for Bundler as reported at https://github.com/rubygems/rubygems/issues/6082. An issue workaround is to manually reinstall the gem with `gem install debug:1.6.3`. That will reinstall the gem, including a correct gemspec file. This is the file diff before and after reinstalling the gem ```diff --- old.gemspec 2022-11-29 13:54:36 +++ /Users/deivid/.asdf/installs/ruby/3.1.3/lib/ruby/gems/3.1.0/specifications/debug-1.6.3.gemspec 2022-11-29 13:55:25 @@ -24,4 +24,16 @@ s.summary = "Debugging functionality for Ruby".freeze s.installed_by_version = "3.3.26" if s.respond_to? :installed_by_version + + if s.respond_to? :specification_version then + s.specification_version = 4 + end + + if s.respond_to? :add_runtime_dependency then + s.add_runtime_dependency(%q<irb>.freeze, [">= 1.3.6"]) + s.add_runtime_dependency(%q<reline>.freeze, [">= 0.3.1"]) + else + s.add_dependency(%q<irb>.freeze, [">= 1.3.6"]) + s.add_dependency(%q<reline>.freeze, [">= 0.3.1"]) + end end ``` In general, the files installed by ruby-core for bundled gems should be identical to the ones installed by explicit `gem install`. This issue is also present in master and I'm guessing it was introduced by https://github.com/ruby/ruby/commit/a2c66f52f402cb58372e271226f3341065561e53 (backported at https://github.com/ruby/ruby/commit/2d26e45135af8b427d9ccc6d47082c21be8b9c74) -- https://bugs.ruby-lang.org/

3 9

[ruby-core:111022] [Ruby master Bug#19153] Since 2.7.7 CGI::Cookie raises ArgumentError when cookie domains is prefixed with a dot
by cpinto (Celso Pinto) 23 Feb '23

23 Feb '23

Issue #19153 has been reported by cpinto (Celso Pinto). ---------------------------------------- Bug #19153: Since 2.7.7 CGI::Cookie raises ArgumentError when cookie domains is prefixed with a dot https://bugs.ruby-lang.org/issues/19153 * Author: cpinto (Celso Pinto) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.7p221 (2022-11-24 revision 168ec2b1e5) [arm64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The rspec tests of our Rails app started failing with an ArgumentError after upgrading to 2.7.7. On inspection, the issue seems to be caused by CGI::Cookie.domain=: ``` def domain=(str) if str and ((str = str.b).bytesize > 255 or !DOMAIN_VALUE_RE.match?(str)) raise ArgumentError, "invalid domain: #{str.dump}" end @domain = str end ``` Setting a breakpoint: 0> str => ".example.com" 0> DOMAIN_VALUE_RE => /\A(?<label>(?!-)[-A-Za-z0-9]+(?<!-))(?:\.\g<label>)*\z/ 0> DOMAIN_VALUE_RE.match?(str) => false 0> DOMAIN_VALUE_RE.match?('example.com') => true -- https://bugs.ruby-lang.org/

4 5

[ruby-core:112537] [Ruby master Misc#18761] provide an example wasm project
by rubyFeedback (robert heiler) 22 Feb '23

22 Feb '23

Issue #18761 has been updated by rubyFeedback (robert heiler). > need more getting started instructions? I think it may be helpful if there would be something like a "mini-tutorial", in the sense that you could go from a super simple use case (hello world), towards something that is a bit more useful (something like tic-tac-toe, in the browser, or even just something simpler, like a mini-calculator), to a tiny bit more advanced (but not too overly complicated). Right now the documentation only has "Create and save index.html page with the following contents", but even when you do this, and then load it into your browser, you don't see anything happening. So something is missing. This may be super-trivial for WASM folks who already understand how this works, but for anyone new to the topic, it kind of means that you need to go to another language if you want to understand how this all works right now. Which is unfortunate, because it may be that WASM works well, but this is not shown to others how this can be done, because there is sparsely any documentation. > You can find pre-compiled wasm files on GitHub: > https://github.com/ruby/ruby.wasm/releases The problem here is that the README at https://github.com/ruby/ruby.wasm does not really explain what one can do with this. It seems as if this is all geared more towards advanced users. Interestingly, I checked python + WASM, and the documentation it shows here: https://pythondev.readthedocs.io/wasm.html Is also very, very bad. I don't know why the WASM documentation is in general so bad. The only exception here is mozilla, which actually has a very decent documentation here: https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_A… So it is a bit as if one has to read these other websites first (such as the mozilla one) before being able to dive into the ruby-wasm or python-wasm aspect of it. ---------------------------------------- Misc #18761: provide an example wasm project https://bugs.ruby-lang.org/issues/18761#change-101984 * Author: grosser (Michael Grosser) * Status: Open * Priority: Normal * Assignee: katei (Yuta Saito) ---------------------------------------- Neither the release notes nor the wasm/README.md include any runnable examples. Please provide a docker image that can be used to generate a wasm binary (even if it's just "hello world"), to show how this is supposed to work. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112534] [Ruby master Bug#19456] Incorrect line numbers in GC hook
by peterzhu2118 (Peter Zhu) 22 Feb '23

22 Feb '23

Issue #19456 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19456: Incorrect line numbers in GC hook https://bugs.ruby-lang.org/issues/19456 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7357 If the previous instruction is not a leaf instruction, then the PC was incremented before the instruction was ran (meaning the currently executing instruction is actually the previous instruction), so we should not increment the PC otherwise we will calculate the source line for the next instruction. This bug can be reproduced in the following script: ```ruby require "objspace" ObjectSpace.trace_object_allocations_start a = 1.0 / 0.0 p [ObjectSpace.allocation_sourceline(a), ObjectSpace.allocation_sourcefile(a)] ``` Which outputs: [4, "test.rb"] This is incorrect because the object was allocated on line 10 and not line 4. The behaviour is correct when we use a leaf instruction (e.g. if we replaced `1.0 / 0.0` with `"hello"`), then the output is: [10, "test.rb"]. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112523] [Ruby master Bug#19454] Instruction `send` has nil blockiseq parameter and ARGS_SIMPLE flag
by dmitry.pogrebnoy (Dmitry Pogrebnoy) 22 Feb '23

22 Feb '23

Issue #19454 has been reported by dmitry.pogrebnoy (Dmitry Pogrebnoy). ---------------------------------------- Bug #19454: Instruction `send` has nil blockiseq parameter and ARGS_SIMPLE flag https://bugs.ruby-lang.org/issues/19454 * Author: dmitry.pogrebnoy (Dmitry Pogrebnoy) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ### Setup * OS: MacOS Monterey 12.4 * VM: rbenv * Gems: test-unit 3.5.3 * Ruby: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] ### Problem Description In some cases the instruction `send` has `nil` block argument and `ARGS_SIMPLE` flag. But `send` is supposed to have a valid `blockiseq` parameter. For the case with a missing block there is an instruction `opt_send_without_block`. This breaks some of the logic of the dependent program . ### How to reproduce 1. Open attached project and run test in test_project\test\my_example_test.rb You should get this output: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,22)> (catch: FALSE) 0000 opt_getinlinecache 9, <is:0> ( 1)[Li] 0003 putobject true 0005 getconstant :MyModule 0007 opt_setinlinecache <is:0> 0009 send <calldata!mid:some_method, argc:0, ARGS_SIMPLE>, nil 0012 leave ``` Here you can see the `send` insn with nil blockiseq and ARGS_SIMPLE flag. 2. But if you run the same code as a script (lib\my_example_script.rb) you should get this output: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,22)> (catch: FALSE) 0000 opt_getinlinecache 9, <is:0> ( 1)[Li] 0003 putobject true 0005 getconstant :MyModule 0007 opt_setinlinecache <is:0> 0009 opt_send_without_block <calldata!mid:some_method, argc:0, ARGS_SIMPLE> 0011 leave ``` Here you can see the `opt_send_without_block` insn instead of `send`. It would be good to get rid of `send` insn with nil blockiseq and use `opt_send_without_block` instruction in such cases. ---Files-------------------------------- test_project.zip (38.3 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112528] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by Eregon (Benoit Daloze) 21 Feb '23

21 Feb '23

Issue #18285 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-38: > ``` > new: undefined method `foo' for main > ``` I think that's quite confusing though without the `main:Object`, because `main` has many other meanings (main script = $0, main function, etc). So I'd suggest either: ``` undefined method `foo' for main:Object undefined method `foo' for main object ``` ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101976 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112527] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by ivoanjo (Ivo Anjo) 21 Feb '23

21 Feb '23

Issue #18285 has been updated by ivoanjo (Ivo Anjo). Thank you! :) ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101975 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0