- ruby-core - ml.ruby-lang.org

[ruby-core:111324] [Ruby master Bug#13485] MinGW TestEnumerable#test_callcc SEGV info
by MSP-Greg (Greg L) 17 Dec '22

17 Dec '22

Issue #13485 has been updated by MSP-Greg (Greg L). Not sure about what/when/where, but this test is passing and there is no longer a patch in ruby-loco. Hence, ok to close. Sorry. ---------------------------------------- Bug #13485: MinGW TestEnumerable#test_callcc SEGV info https://bugs.ruby-lang.org/issues/13485#change-100701 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * ruby -v: ruby 2.5.0dev (2017-04-18 trunk 58397) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- Re the patch needed in MinGW builds for [TestEnumerable#test_callcc](https://github.com/ruby/ruby/blob/d6873af4bdc99… (file `test/ruby/test_enum.rb`), I ran the following code with `--disable-gems`: ```ruby require_relative '<path to ruby>/lib/ruby/2.5.0/x64-mingw32/continuation.so' 1000.times { c = nil o = Object.new class << o; self; end.class_eval do define_method(:<=>) do |x| callcc {|c2| c ||= c2 } 0 end end ary = [o,o] begin ary.sort_by {|x| x } c.to_s ; c.call rescue end } ``` Attached is a file with the code and the SEGV output when running. I removed the ruby path to shorten it. Note that if the line - ```ruby c.to_s ; c.call ``` is replaced with - ```ruby c.call ``` my system hangs/stops. No output, no response; have to force the command window closed... ---Files-------------------------------- TestEnumerable#call_cc_SEGV.txt (4.01 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111322] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by mame (Yusuke Endoh) 16 Dec '22

16 Dec '22

Issue #18285 has been updated by mame (Yusuke Endoh). I have created a PR based on @akr 's proposal. https://github.com/ruby/ruby/pull/6950 ``` 42.time #=> undefined method `time' for object Integer (NoMethodError) class Foo privatee #=> undefined local variable or method 'privatee' for class Foo (NoMethodError) end s = "" def s.foo = nil s.bar #=> undefined method `bar' for extended object String (NoMethodError) ``` I think we can almost agree to stop using `#inspect` in `NoMethodError#message`. Now, we need to decide the new message format. However, I think it is difficult to decide this through discussion and imagination because it is very much a matter of preference. So, how about trying @akr's proposal towards Ruby 3.3, after the release of Ruby 3.2? Let's evaluate how annoying (or not) the new error format would be for daily programming by those who uses master. Note that @akr is one of the most proven and trusted committers in the area of designing Ruby. I believe that his proposal is a good start. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-100699 * Author: ivoanjo (Ivo Anjo) * Status: Open * 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:111320] [Ruby master Bug#16836] configure-time LDFLAGS leak into ruby pkg-config file
by nobu (Nobuyoshi Nakada) 16 Dec '22

16 Dec '22

Issue #16836 has been updated by nobu (Nobuyoshi Nakada). Status changed from Assigned to Feedback IIRC, `rpath` is the path embedded in the linked binary, in order to resolve shared libraries at runtime. There is no reason to set the path that won’t exist at runtime, I think. ---------------------------------------- Bug #16836: configure-time LDFLAGS leak into ruby pkg-config file https://bugs.ruby-lang.org/issues/16836#change-100690 * Author: stapelberg (Michael Stapelberg) * Status: Feedback * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: 2.7.1 * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- When building ruby with e.g. `-Wl,-rpath=/ro/ruby-amd64-2.7.1-6/lib` (to make it hermetic, see my work-in-progress post at https://website-review.zekjur.net/pull/hermetic/posts/2020-05-04-distri-her…) I noticed that the resulting pkg-config file (`lib/pkgconfig/ruby-2.7.pc`) includes the LDFLAGS! This will result in software that links against ruby being built with the wrong `rpath`. In general, LDFLAGS should not be persisted into pkg-config. The attached patch fixes the issue. Thanks, ---Files-------------------------------- pc-ldflags.patch (563 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111279] [Ruby master Bug#19233] Failed to install sqlite3 gem since 7f1ca666424849134990d022266bcd4d6636465f using Docker
by yahonda (Yasuo Honda) 15 Dec '22

15 Dec '22

Issue #19233 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #19233: Failed to install sqlite3 gem since 7f1ca666424849134990d022266bcd4d6636465f using Docker https://bugs.ruby-lang.org/issues/19233 * Author: yahonda (Yasuo Honda) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-10-02T06:19:14Z :detached: 7f1ca66642) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Failed to install sqlite3 gem since 7f1ca666424849134990d022266bcd4d6636465f using Docker. This issue comes from https://github.com/rails/rails/pull/46711 . ## Steps to reproduce 1. Install Docker 2. Follow this step ``` git clone https://github.com/yahonda/rep19189 cd rep19189 docker build . ``` ## Expected behavior It should pass. ## Actual behavior It fails `Gem::Ext::BuildError: ERROR: Failed to build gem native extension.` ```ruby $ docker build . Sending build context to Docker daemon 69.63kB Step 1/5 : FROM rubylang/rubyfarm:7f1ca666424849134990d022266bcd4d6636465f ---> cdd68058177d Step 2/5 : RUN apt-get update -qq && apt-get install -y sqlite3 libsqlite3-dev pkg-config ---> Using cache ---> b8928c4f6425 Step 3/5 : WORKDIR /myapp ---> Using cache ---> bae259f8abf3 Step 4/5 : COPY Gemfile /myapp/Gemfile ---> Using cache ---> a9fe0822ad64 Step 5/5 : RUN bundle install ---> Running in 00cd9fc0e691 Don't run Bundler as root. Installing your bundle as root will break this application for all non-root users on this machine. Fetching gem metadata from https://rubygems.org/..... Resolving dependencies... Using bundler 2.4.0.dev Fetching mini_portile2 2.8.0 Installing mini_portile2 2.8.0 Fetching sqlite3 1.5.4 Installing sqlite3 1.5.4 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ext/sqlite3 /opt/ruby/bin/ruby -I /opt/ruby/lib/ruby/3.2.0+2 extconf.rb Ignoring debug-1.6.2 because its extensions are not built. Try: gem pristine debug --version 1.6.2 Building sqlite3-ruby using packaged sqlite3. Extracting sqlite-autoconf-3400000.tar.gz into tmp/x86_64-linux-gnu/ports/sqlite3/3.40.0... OK Running 'configure' for sqlite3 3.40.0... OK Running 'compile' for sqlite3 3.40.0... OK Running 'install' for sqlite3 3.40.0... OK Activating sqlite3 3.40.0 (from /opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0)... Could not configure the build properly (pkg_config). Please install either the `pkg-config` utility or the `pkg-config` rubygem. *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --without-make-prog --srcdir=. --curdir --ruby=/opt/ruby/bin/$(RUBY_BASE_NAME) --help --download-dependencies --with-sqlcipher --without-sqlcipher --with-sqlcipher-dir --without-sqlcipher-dir --with-sqlcipher-include --without-sqlcipher-include --with-sqlcipher-lib --without-sqlcipher-lib --enable-system-libraries --disable-system-libraries --with-sqlcipher --without-sqlcipher --with-sqlcipher-dir --without-sqlcipher-dir --with-sqlcipher-include --without-sqlcipher-include --with-sqlcipher-lib --without-sqlcipher-lib --with-sqlite-source-dir --with-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-dir --without-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-dir --with-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-include --without-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-include=${/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-dir}/include --with-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-lib --without-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-lib=${/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-dir}/lib --with-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-config --without-/opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4/ports/x86_64-linux-gnu/sqlite3/3.40.0/lib/pkgconfig/sqlite3.pc-config --with-pkg-config --without-pkg-config To see why this extension failed to compile, please check the mkmf.log which can be found here: /opt/ruby/lib/ruby/gems/3.2.0+2/extensions/x86_64-linux/3.2.0+2/sqlite3-1.5.4/mkmf.log extconf failed, exit code 1 Gem files will remain installed in /opt/ruby/lib/ruby/gems/3.2.0+2/gems/sqlite3-1.5.4 for inspection. Results logged to /opt/ruby/lib/ruby/gems/3.2.0+2/extensions/x86_64-linux/3.2.0+2/sqlite3-1.5.4/gem_make.out /opt/ruby/lib/ruby/3.2.0+2/rubygems/ext/builder.rb:102:in `run' /opt/ruby/lib/ruby/3.2.0+2/rubygems/ext/ext_conf_builder.rb:28:in `build' /opt/ruby/lib/ruby/3.2.0+2/rubygems/ext/builder.rb:171:in `build_extension' /opt/ruby/lib/ruby/3.2.0+2/rubygems/ext/builder.rb:205:in `block in build_extensions' /opt/ruby/lib/ruby/3.2.0+2/rubygems/ext/builder.rb:202:in `each' /opt/ruby/lib/ruby/3.2.0+2/rubygems/ext/builder.rb:202:in `build_extensions' /opt/ruby/lib/ruby/3.2.0+2/rubygems/installer.rb:843:in `build_extensions' /opt/ruby/lib/ruby/3.2.0+2/bundler/rubygems_gem_installer.rb:72:in `build_extensions' /opt/ruby/lib/ruby/3.2.0+2/bundler/rubygems_gem_installer.rb:28:in `install' /opt/ruby/lib/ruby/3.2.0+2/bundler/source/rubygems.rb:202:in `install' /opt/ruby/lib/ruby/3.2.0+2/bundler/installer/gem_installer.rb:54:in `install' /opt/ruby/lib/ruby/3.2.0+2/bundler/installer/gem_installer.rb:16:in `install_from_spec' /opt/ruby/lib/ruby/3.2.0+2/bundler/installer/parallel_installer.rb:186:in `do_install' /opt/ruby/lib/ruby/3.2.0+2/bundler/installer/parallel_installer.rb:177:in `block in worker_pool' /opt/ruby/lib/ruby/3.2.0+2/bundler/worker.rb:62:in `apply_func' /opt/ruby/lib/ruby/3.2.0+2/bundler/worker.rb:57:in `block in process_queue' /opt/ruby/lib/ruby/3.2.0+2/bundler/worker.rb:54:in `loop' /opt/ruby/lib/ruby/3.2.0+2/bundler/worker.rb:54:in `process_queue' /opt/ruby/lib/ruby/3.2.0+2/bundler/worker.rb:91:in `block (2 levels) in create_threads' An error occurred while installing sqlite3 (1.5.4), and Bundler cannot continue. In Gemfile: sqlite3 The command '/bin/sh -c bundle install' returned a non-zero code: 5 ``` -- https://bugs.ruby-lang.org/

4 8

[ruby-core:111311] Building Ruby 3.2 with YJIT enabled
by Maxime Chevalier-Boisvert 15 Dec '22

15 Dec '22

Hello everyone, In the last year we’ve ported YJIT to Rust, and YJIT also now supports Arm64 CPUs (Mac M1/M2, AWS Graviton, Raspberry Pi & more) in addition to x86-64 on Mac/Linux and BSD. I’m writing this because, as we near the 3.2 release 🎁, I really hope that YJIT will be available ✨ as part of precompiled Ruby packages and Ruby binaries, as much as possible. In order to build CRuby with YJIT enabled, on a supported platform, you should only need to install rustc >= 1.58.0 before running the CRuby ./configure script. That is all. The configure script should auto-detect rustc and enable building YJIT. Some instructions for installing rustc on various platforms: # Cross-platform setup script for the Rust toolchain $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh or # On Debian-based distros: $ sudo apt install rustc You can check that your ruby binary has been built with YJIT by running: # should contain the string +YJIT $ ruby --yjit -v Feel free to reach out if you encounter any issues. Happy Holidays! 🎅🎄🎁 - Maxime & the YJIT team

3 2

[ruby-core:111312] Building Ruby 3.2 with YJIT enabled
by Maxime Chevalier-Boisvert 15 Dec '22

15 Dec '22

Hello everyone, In the last year we’ve ported YJIT to Rust, and YJIT also now supports Arm64 CPUs (Mac M1/M2, AWS Graviton, Raspberry Pi & more) in addition to x86-64 on Mac/Linux and BSD. I’m writing this because, as we near the 3.2 release 🎁, I really hope that YJIT will be available ✨ as part of precompiled Ruby packages and Ruby binaries, as much as possible. In order to build CRuby with YJIT enabled, on a supported platform, you should only need to install rustc >= 1.58.0 before running the CRuby ./configure script. That is all. The configure script should auto-detect rustc and enable building YJIT. Some instructions for installing rustc on various platforms: # Cross-platform setup script for the Rust toolchain $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh or # On Debian-based distros: $ sudo apt install rustc You can check that your ruby binary has been built with YJIT by running: # should contain the string +YJIT $ ruby --yjit -v Feel free to reach out if you encounter any issues. Happy Holidays! 🎅🎄🎁 - Maxime & the YJIT team

1 0

[ruby-core:111307] [Ruby master Feature#19069] Default value assignment with `Hash.new` in block form
by Eregon (Benoit Daloze) 15 Dec '22

15 Dec '22

Issue #19069 has been updated by Eregon (Benoit Daloze). As a note this change could be useful to make the default_proc assignment thread-safe (avoid assigning twice for the same key). It's not safe for `Hash` currently (I'll file a separate issue to discuss that) and neither for `Concurrent::Hash` (https://github.com/ruby-concurrency/concurrent-ruby/issues/970#issuecomment…) ---------------------------------------- Feature #19069: Default value assignment with `Hash.new` in block form https://bugs.ruby-lang.org/issues/19069#change-100677 * Author: sawa (Tsuyoshi Sawada) * Status: Rejected * Priority: Normal ---------------------------------------- This is a spin-out from #19063, and is a recapture of my comment https://bugs.ruby-lang.org/issues/19063#note-15. I propose to change the behavior of `Hash.new` when it takes a block with its parameter signature absent. In such case, the evaluated value of the block should be assigned to the hash with the missing key in question (`h3` below). When the block does take parameters, then the behavior should remain as is now (`h1`, `h2` below). ```rb h1 = Hash.new{|h, k| h[k] = "foo"} h2 = Hash.new{|h, k| "foo"} h3 = Hash.new{"foo"} h1[:a] # => "foo" h2[:a] # => "foo" h3[:a] # => "foo" h1 # => {:a=>"foo"} h2 # => {} h3 # => {:a=>"foo"} ``` This will solve a few problems. First, as discussed in #19063, many users make the mistake of writing `Hash.new([])` when they actually mean `Hash.new{|h, k| h[k] = []}`, and I suspect this is partially due to the fact that the block `{|h, k| h[k] = []}` is too long, and the users are tempted to avoid writing so. With the proposed feature introduced, the users will be encouraged to naturally write the correct form `Hash.new{[]}`. Second, some of the more advanced users than those mentioned above still make the mistake of writing `Hash.new{foo}` when they actually mean `Hash.new{|h, k| h[k] = foo}`, and the current proposal is to let them actually be equivalent. Third, this will resemble a similar construct `Array.new(5){[]}` and they will make a good parallel. Indeed, there are situations where the intended behavior is to just run a routine without assigning a new key-value pair to the hash. Examples of current code may be as follows: ```rb h4 = Hash.new{some_routine_to_take_care_of_the_missing_key_situation} h5 = Hash.new{raise WrongKeyBlahBlahError} ``` Such blocks would need to be prepended by a parameter signature `|h, k|` in order to avoid unwanted results. I do not think such transition would be a huge pain. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111305] [Ruby master Feature#19069] Default value assignment with `Hash.new` in block form
by matz (Yukihiro Matsumoto) 15 Dec '22

15 Dec '22

Issue #19069 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected For compatibility's sake (and to avoid extra complexity), we reject this idea. Matz. ---------------------------------------- Feature #19069: Default value assignment with `Hash.new` in block form https://bugs.ruby-lang.org/issues/19069#change-100672 * Author: sawa (Tsuyoshi Sawada) * Status: Rejected * Priority: Normal ---------------------------------------- This is a spin-out from #19063, and is a recapture of my comment https://bugs.ruby-lang.org/issues/19063#note-15. I propose to change the behavior of `Hash.new` when it takes a block with its parameter signature absent. In such case, the evaluated value of the block should be assigned to the hash with the missing key in question (`h3` below). When the block does take parameters, then the behavior should remain as is now (`h1`, `h2` below). ```rb h1 = Hash.new{|h, k| h[k] = "foo"} h2 = Hash.new{|h, k| "foo"} h3 = Hash.new{"foo"} h1[:a] # => "foo" h2[:a] # => "foo" h3[:a] # => "foo" h1 # => {:a=>"foo"} h2 # => {} h3 # => {:a=>"foo"} ``` This will solve a few problems. First, as discussed in #19063, many users make the mistake of writing `Hash.new([])` when they actually mean `Hash.new{|h, k| h[k] = []}`, and I suspect this is partially due to the fact that the block `{|h, k| h[k] = []}` is too long, and the users are tempted to avoid writing so. With the proposed feature introduced, the users will be encouraged to naturally write the correct form `Hash.new{[]}`. Second, some of the more advanced users than those mentioned above still make the mistake of writing `Hash.new{foo}` when they actually mean `Hash.new{|h, k| h[k] = foo}`, and the current proposal is to let them actually be equivalent. Third, this will resemble a similar construct `Array.new(5){[]}` and they will make a good parallel. Indeed, there are situations where the intended behavior is to just run a routine without assigning a new key-value pair to the hash. Examples of current code may be as follows: ```rb h4 = Hash.new{some_routine_to_take_care_of_the_missing_key_situation} h5 = Hash.new{raise WrongKeyBlahBlahError} ``` Such blocks would need to be prepended by a parameter signature `|h, k|` in order to avoid unwanted results. I do not think such transition would be a huge pain. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111304] [Ruby master Feature#19063] Hash.new with non-value objects should be less confusing
by matz (Yukihiro Matsumoto) 15 Dec '22

15 Dec '22

Issue #19063 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Rejected Sorry for being late to reply. As @shugo mentioned above, there are a lot of code that use this functionality valid. Considering this fact, we are not going to add any warning here for the core. Matz. ---------------------------------------- Feature #19063: Hash.new with non-value objects should be less confusing https://bugs.ruby-lang.org/issues/19063#change-100671 * Author: baweaver (Brandon Weaver) * Status: Rejected * Priority: Normal ---------------------------------------- Related to #10713 and #2764. Ruby's `Hash.new` accepts either a block or a param for its default value. In the case of non-value objects this leads to unexpected behaviors: ```ruby bad_hash_with_array_values = Hash.new([]) good_hash_with_array_values = Hash.new { |h, k| h[k] = [] } ``` While, as @hsbt has said in the past, this is behaving as intended for the Ruby language it has caused a lot of confusion in the community over the years and is a known sharp-edge. My assertion is that this is not the intended behavior, and I cannot find a legitimate usecase in which someone intends for this to happen. More often new users to Ruby are confused by this behavior and spend a lot of time debugging. We must consider the impact to Ruby users, despite what the intent of the language is, and make the language more clear where possible. Given that, I have a few potential proposals for Ruby committers. ### Proposal 1: Do What They Meant When people use `Hash.new([])` they mean `Hash.new { |h, k| h[k] = [] }`. Can we make that the case that if you pass a mutable or non-value object that the behavior will be as intended using `dup` or other techniques? When used in the above incorrect way it is likely if not always broken code. ### Proposal 2: Warn About Unexpected Behavior As mentioned above, I do not believe there are legitimate usages of `Hash.new([])`, and it is a known bug to many users as they do not intend for that behavior. It may be worthwhile to warn people if they do use it. ### Proposal 3: Require Frozen or Values This is more breaking than the above, but it may make sense to require any value passed to `Hash.new` to either be `frozen` or a value object (e.g. `1` or `true`) ## Updating RuboCop Failing this, I am considering advocating for RuboCop and similar linters to warn people against this behavior as it is not intended in most to all cases: https://github.com/rubocop/rubocop/issues/11013 ...but as @ioquatix has mentioned on the issue it would make more sense to fix Ruby rather than put a patch on top of it. I would be inclined to agree with his assessment, and would rather fix this at a language level as it is a known point of confusion. ## Final Thoughts I would ask that maintainers consider the confusion that this has caused in the community, rather than asserting this "works as intended." It does work as intended, but the intended functionality can make Ruby more difficult for beginners. We should keep this in mind. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111303] [Ruby master Feature#10455] [PATCH 0/n] Combine interface for creating new matrix
by hsbt (Hiroshi SHIBATA) 15 Dec '22

15 Dec '22

Issue #10455 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Third Party's Issue `matrix` has been extracted to https://github.com/ruby/matrix. ---------------------------------------- Feature #10455: [PATCH 0/n] Combine interface for creating new matrix https://bugs.ruby-lang.org/issues/10455#change-100670 * Author: gogotanaka (Kazuki Tanaka) * Status: Third Party's Issue * Priority: Normal ---------------------------------------- I believe we'd better reduce the number of interface for creating new matrix as much as possible. Right now, we have 7 methods for creating new matrix, ``` * Matrix.[](*rows) * Matrix.rows(rows, copy = true) * Matrix.columns(columns) * Matrix.build(row_count, column_count, &block) * Matrix.row_vector(row) * Matrix.column_vector(column) * Matrix#new_matrix (for internal) ``` I know each methods has meaning for each specific way. But I wanna combine `Matrix.rows` with `Matrix.row_vector` and `Matrix.columns` with `Matrix.column_vector`. I suppose only `Matrix.rows` and `Matrix.columns` is totally enough. `Matrix.row_vector(row)` is equivalent `Matrix.rows([row])` and `Matrix.column_vector(column)` is equivalent `Matrix.columns([column])` If it looks fine for you, I'll make patches. Thanks. -- https://bugs.ruby-lang.org/

1 0