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

[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

[ruby-core:111101] [Ruby master Bug#19162] [ANN] Restrict weak ssh public key for git.ruby-lang.org
by hsbt (Hiroshi SHIBATA) 15 Dec '22

15 Dec '22

Issue #19162 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19162: [ANN] Restrict weak ssh public key for git.ruby-lang.org https://bugs.ruby-lang.org/issues/19162 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- We continuously migrate our ssh public keys on git.ruby-lang.org from svn and cvs. I found some of pub keys used weak algorithm. So, I will restrict them at 15 Dec 2022. I'll notify committers who are still use weak key later. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:111297] [Ruby master Feature#18683] Allow to create hashes with a specific capacity.
by hsbt (Hiroshi SHIBATA) 15 Dec '22

15 Dec '22

Issue #18683 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed https://github.com/ruby/ruby/pull/5835 has been merged. I'll close this. @byroot If you have any concern or proposal, please re-open or file another issue. Thanks. ---------------------------------------- Feature #18683: Allow to create hashes with a specific capacity. https://bugs.ruby-lang.org/issues/18683#change-100657 * 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:111296] [Ruby master Feature#18498] Introduce a public WeakKeysMap that compares by equality
by matz (Yukihiro Matsumoto) 15 Dec '22

15 Dec '22

Issue #18498 has been updated by matz (Yukihiro Matsumoto). LGTM. Probably too late for 3.2. For 3.3 maybe? Matz. ---------------------------------------- Feature #18498: Introduce a public WeakKeysMap that compares by equality https://bugs.ruby-lang.org/issues/18498#change-100656 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- This is a clean take on #16038 ### Spec #### Weak keys only After a chat with @eregon we believe that what would make the most sense and would be most useful would be a "WeakKeysMap". Meaning **the keys would be weak references, but the values would be strong references**. This behavior is also consistent with the terminology in other popular languages such as Javascript and Java were `WeakMap` only have weak keys. By default **it would use equality semantic, just like a regular `Hash`**. Having an option to compare by indentity instead could be useful, but not strictly required. #### Immediate objects support Many WeakMap implementation in other languages don't accept "immediate" objects (or their equivalent) in the weak slots. This is because since they are never collected, the weak reference will never possibly expire. `ObjectSpace::WeakMap` currently accept them, but since both keys and values are weak references, there is legitimate use. However in a `WeakKeysMap`, using an immediate object as key should likely raise a `TypeError`. What is less clear is wether `BIGNUM` (allocated `Integer`) and dynamic symbols (allocated `Symbol`) should be accepted. I believe they shouldn't for consistency, so: - No immediate objects - No `Integer` - No `Symbol` #### `member` method to lookup an existing key For some use case, notably deduplication sets, a `member` method that maps `st_get_key` would be useful. ```ruby def member(key) -> existing key or nil ``` Not sure if `member` is the best possible name, but `#key` is already used for looking up a key by value. That same method could be useful on `Hash` and `Set` as well, but that would be a distinct feature request. #### Naming Possible names: - `::WeakMap` - `::WeakKeysMap` - `::WeakRef::Map` - `::WeakRef::WeakMap` - `::WeakRef::WeakKeysMap` - `::WeakRef::WeakHash` - `::WeakRef::WeakKeysHash` My personal, ligthly held, preference goes toward `::WeakRef::WeakKeysMap`. ### Use cases #### WeakSet A `WeakKeysMap` would be a good enough primitive to implement a `WeakSet` in pure Ruby code, just like `Set` is implemented with a `Hash`. `WeakSet` are useful for use cases such as avoiding cycles in an object graph without holding strong references. #### Deduplication sets Assuming `WeakMap` have the `#member` method. A small variation on the "deduplicating constructors" use case, better suited for smaller but numerous objects. The difference here is that we first build the object and then lookup for a pre-existing one. This is the strategy used to [deduplicate Active Record schema metadata](https://github.com/rails/rails/blob/3be590edbedab8ddcacdf72790d50…. ```ruby class DeduplicationSet def initialize @set = WeakKeysMap.new end def dedup(object) if existing_object = @set.member(object) existing_object else @set[object] = true object end end end ``` #### Third party object extension When you need to record some associated data on third party objects for which you don't control the lifetime. A WeakMap can be used: ```ruby METADATA = WeakKeysMap.new def do_something(third_party_object) metadata = (METADATA[third_party_object] ||= Metadata.new) metadata.foo = "bar" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111295] [Ruby master Feature#18033] Time.new to parse a string
by matz (Yukihiro Matsumoto) 15 Dec '22

15 Dec '22

Issue #18033 has been updated by matz (Yukihiro Matsumoto). Accepted. Performance improvement is a great benefit. Both `Time.iso8859` and `Time.parse` requires loading `date` gem, and providing those methods in the core may cause overwriting. Currently, `Time.new` only takes numeric arguments, so adding extra argument pattern add only a small complexity. Matz. ---------------------------------------- Feature #18033: Time.new to parse a string https://bugs.ruby-lang.org/issues/18033#change-100654 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- Make `Time.new` parse `Time#inspect` and ISO-8601 like strings. * `Time.iso8601` and `Time.parse` need an extension library, `date`. * `Time.iso8601` can't parse `Time#inspect` string. * `Time.parse` often results in unintentional/surprising results. * `Time.new` also about 1.9 times faster than `Time.iso8601`. ``` $ ./ruby -rtime -rbenchmark -e ' n = 1000 s = Time.now.iso8601 Benchmark.bm(12) do |x| x.report("Time.iso8601") {n.times{Time.iso8601(s)}} x.report("Time.parse") {n.times{Time.parse(s)}} x.report("Time.new") {n.times{Time.new(s)}} end' user system total real Time.iso8601 0.006919 0.000185 0.007104 ( 0.007091) Time.parse 0.018338 0.000207 0.018545 ( 0.018590) Time.new 0.003671 0.000069 0.003740 ( 0.003741) ``` https://github.com/ruby/ruby/pull/4825 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111293] [Ruby master Feature#18033] Time.new to parse a string
by mame (Yusuke Endoh) 15 Dec '22

15 Dec '22

Issue #18033 has been updated by mame (Yusuke Endoh). https://github.com/ruby/ruby/pull/4825 ---------------------------------------- Feature #18033: Time.new to parse a string https://bugs.ruby-lang.org/issues/18033#change-100651 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- Make `Time.new` parse `Time#inspect` and ISO-8601 like strings. * `Time.iso8601` and `Time.parse` need an extension library, `date`. * `Time.iso8601` can't parse `Time#inspect` string. * `Time.parse` often results in unintentional/surprising results. * `Time.new` also about 1.9 times faster than `Time.iso8601`. ``` $ ./ruby -rtime -rbenchmark -e ' n = 1000 s = Time.now.iso8601 Benchmark.bm(12) do |x| x.report("Time.iso8601") {n.times{Time.iso8601(s)}} x.report("Time.parse") {n.times{Time.parse(s)}} x.report("Time.new") {n.times{Time.new(s)}} end' user system total real Time.iso8601 0.006919 0.000185 0.007104 ( 0.007091) Time.parse 0.018338 0.000207 0.018545 ( 0.018590) Time.new 0.003671 0.000069 0.003740 ( 0.003741) ``` https://github.com/ruby/ruby/pull/4639 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111291] [Ruby master Bug#18605] Fails to run on (newer) 32bit Windows with ucrt
by larskanis (Lars Kanis) 14 Dec '22

14 Dec '22

Issue #18605 has been updated by larskanis (Lars Kanis). Thanks all for sharing the details! I started a branch to replace the UCRT/MSVCRT pioinfo here: https://github.com/ruby/ruby/compare/master...larskanis:ruby:pioinfo?expand… My rough plan is to first replace pioinfo with a ruby-internal mapping between FD and HANDLE/SOCKET. This makes it necessary to replace all uses of FD and change it to native WINAPI functions using HANDLE/SOCKET. Fortunately many functions are already based on the native WINAPI. Among others it currently fails at the many process spawn variations and the text file CRLF conversions are not yet implemented. Also the few uses of FILE based libc functions still have to be replaced. After pioinfo is replaced and the implementation is passing all tests again, I would like to replace FD completely by HANDLE/SOCKET including in `IO#fileno` and `IO.new`. This is because the FD is then just an internal number, with no external meaning. But HANDLE/SOCKET is the native Windows handle to access resources and to process events. Even if this sounds pretty simple, there are a lot of tricky challenges on the way and I'm sure @naruse had very good reasons to build the pioinfo hack. ---------------------------------------- Bug #18605: Fails to run on (newer) 32bit Windows with ucrt https://bugs.ruby-lang.org/issues/18605#change-100647 * Author: lazka (Christoph Reiter) * Status: Open * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- 32bit ruby using ucrt has started to fail on newer Windows with "unexpected ucrtbase.dll" -> https://github.com/ruby/ruby/blob/3fb7d2cadc18472ec107b14234933b017a33c14d/… The problem is that ruby depends on ucrt internals and those have apparently changed with newer versions. See https://github.com/msys2/MINGW-packages/pull/10878 and https://github.com/msys2/MINGW-packages/issues/10896 for some background and a potential fix. But ideally ruby wouldn't depend on Windows internals like this. thanks! -- https://bugs.ruby-lang.org/

1 0