December 2022 - ruby-core - ml.ruby-lang.org

[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

[ruby-core:111300] [Ruby master Feature#18683] Allow to create hashes with a specific capacity.
by byroot (Jean Boussier) 15 Dec '22

15 Dec '22

Issue #18683 has been updated by byroot (Jean Boussier). Yeah the ruby side of the proposal wasn't merged, but I'll open an issue specifically for it. ---------------------------------------- Feature #18683: Allow to create hashes with a specific capacity. https://bugs.ruby-lang.org/issues/18683#change-100660 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal ---------------------------------------- Various protocol parsers such as Redis `RESP3` or `msgpack`, have to create hashes, and they know the size in advance. For efficiency, it would be preferable if they could directly allocate a Hash of the necessary size, so that large hashes wouldn't cause many re-alloccations. Example of code that would benefit: - [`hiredis` bindings](https://github.com/redis-rb/redis-client/blob/830d586b665bc956933… - [Ruby `redis RESP3` parser](https://github.com/redis-rb/redis-client/blob/830d586b665bc9569335d… - [magpack-ruby](https://github.com/msgpack/msgpack-ruby/blob/c46bb60f79312cab… `String` and `Array` both already offer similar APIs: ```ruby String.new(capacity: XXX) Array.new(XX) / rb_ary_new_capa(long) ``` However there's no such public API for Hashes, neither in Ruby land not in the C extension API. ### Proposal I think `Hash.new` should accept a `capacity:` named parameter: ```ruby hash = Hash.new(capacity: 1000) ``` Additionally I think the internal `rb_hash_new_with_size` function should be exposed to C extensions as `rb_hash_new_capa(long)`, for consistency with `rb_ary_new_capa(long)`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111299] [Ruby master Feature#18183] make SecureRandom.choose public
by mame (Yusuke Endoh) 15 Dec '22

15 Dec '22

Issue #18183 has been updated by mame (Yusuke Endoh). Status changed from Rejected to Assigned Assignee set to nobu (Nobuyoshi Nakada) ---------------------------------------- Feature #18183: make SecureRandom.choose public https://bugs.ruby-lang.org/issues/18183#change-100659 * Author: olleicua (Antha Auciello) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- This issue https://bugs.ruby-lang.org/issues/10849 added `SecureRandom.alphanumeric` and also the private method choose. `choose` was kept private because the method name wasn't the best name to represent the behavior. I think if it was called `random_string` it would be very clear what it does. I also think it should be aliased to choose as well to allow backwards compatibility for people bypassing the private method with `send` (e.g. https://www.thetopsites.net/article/58611103.shtml) I'm planning to put together a pull request for this. Please let me know if there are any complications I'm not considering. -- https://bugs.ruby-lang.org/

1 0