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

[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

[ruby-core:111302] [Ruby master Feature#8223] Make Matrix more omnivorous.
by hsbt (Hiroshi SHIBATA) 15 Dec '22

15 Dec '22

Issue #8223 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 #8223: Make Matrix more omnivorous. https://bugs.ruby-lang.org/issues/8223#change-100669 * Author: Anonymous * Status: Third Party's Issue * Priority: Normal * Assignee: marcandre (Marc-Andre Lafortune) ---------------------------------------- Let's imagine a class Metre, whose instances represent physical magnitudes in metres. class Metre attr_reader :magnitude def initialize magnitude; @magnitude = magnitude end def to_s; magnitude.to_s + ".m" end end Let's say that metres can be multiplied by a number: class Metre def * multiplicand case multiplicand when Numeric then Metre.new( magnitude * multiplicand ) else raise "Metres can only be multiplied by numbers, multiplication by #{multiplicand.class} attempted!" end end end And that they can be summed up with other magnitudes in metres, but, as a feature, not with numbers (apples, pears, seconds, kelvins...). class Metre def + summand case summand when Metre then Metre.new( magnitude + summand.magnitude ) else raise "Metres can only be summed with metres, summation with #{summand.class} attempted!" end end end Now with one more convenience constructor Numeric#m: class Numeric def m; Metre.new self end end We can write expressions such as 3.m + 5.m #=> 8.m 3.m * 2 #=> 6.m And with defined #coerce: class Metre def coerce other; [ self, other ] end end Also this expression is valid: 2 * 3.m #=> 6.m Before long, the user will want to make a matrix of magnitudes: require 'matrix' mx = Matrix.build 2, 2 do 1.m end #=> Matrix[[1.m, 1.m], [1.m, 1.m]] It works, but the joy does not last long. The user will fail miserably if ze wants to perform matrix multiplication: cv = Matrix.column_vector [1, 1] mx * cv #=> RuntimeError: Metres can only be summed with metres, summation with Fixnum attempted! # where 2.m would be expected In theory, everything should be O.K., since Metre class has both metre summation and multiplication by a number defined. The failure happens due to the internal workings of the Matrix class, which assumes that the elements can be summed together with numeric 0. But it is a feature of metres, that they are picky and allow themselves to be summed only with other Metre instances. In my real physical units library that I have written, I have solved this problem by defining an über zero object that produces the expected result, when summed with objects, that would otherwise not lend themselves to summation with ordinary numeric 0, and patching the Matrix class so that it uses this über zero instead of the ordinary one. But this is not a very systematic solution. Actually, I think that the Matrix class would be more flexible, if, instead of simply using 0, it asked the elements of the matrix what their zero is, as in: class << Metre def zero; new 0 end end But of course, that would also require that ordinary numeric classes can tell what their zero is, as in: def Integer.zero; 0 end def Float.zero; 0.0 end def Complex.zero; Complex 0.0, 0.0 end # etc. I think that this way of doing things (that is, having #zero methods in numeric classes and making Matrix actually require the class of the objects in it to have public class method #zero defined) would make everything more consistent and more algebra-like. I am having this problem for already almost half a year, but I only gathered courage today to encumber you guys with this proposal. Please don't judge me harshly for it. I have actually already seen something like this, in particular with bigdecimal's Jacobian (http://ruby-doc.org/stdlib-2.0/libdoc/bigdecimal/rdoc/Jacobian.html) which requires that the object from which the Jacobian is computed implements methods #zero, #one, #two etc. Sorry again. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111301] [Ruby master Bug#18797] Third argument to Regexp.new is a bit broken
by matz (Yukihiro Matsumoto) 15 Dec '22

15 Dec '22

Issue #18797 has been updated by matz (Yukihiro Matsumoto). I thought it was marked as obsolete long time ago. I think it's time to make it obsolete, probably via the usual obsoleting process (i.e. adding warning first). Matz ---------------------------------------- Bug #18797: Third argument to Regexp.new is a bit broken https://bugs.ruby-lang.org/issues/18797#change-100662 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- ## Situation 'n' or 'N' can be passed as a third argument to `Regexp.new`. However, the behavior is not the same as the literal `n`-flag or the `Regexp::NOENCODING` option, and it makes the `#encoding` of `Regexp` and `Regexp#source` diverge: ```ruby /😅/n # => SyntaxError Regexp.new('😅', Regexp::NOENCODING) # => RegexpError re = Regexp.new('😅', nil, 'n') # => /😅/ re.options == Regexp::NOENCODING # => true re.encoding # => ASCII-8BIT re.source.encoding # => UTF-8 re =~ '😅' # => Encoding::CompatibilityError ``` ## Code [Here](https://github.com/ruby/ruby/blob/b41de3a1e8c36a5cc336b6f7cd3cb71126c…. There is also a test for the resulting encoding [here](https://github.com/ruby/ruby/blob/cf2bbcfff2985c116552967c7c4522f4630…, but it is a no-op because the whole file is set to that encoding via magic comment anyway. The third argument was added when ASCII was still the default Ruby encoding, so I guess Regexp and source encoding still matched at that point. ## Solution It could be fixed, but my impression is that it is not useful anymore. It was probably only added because `Regexp::NOENCODING` wasn't available at the time, so I think it could be deprecated like so: > Passing a third argument to Regexp.new is deprecated. Use `Regexp::NOENCODING` as second argument instead. -- https://bugs.ruby-lang.org/

1 0