October 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119420] [Ruby master Feature#18127] Ractor-local version of Singleton
by hsbt (Hiroshi SHIBATA) 02 Oct '24

02 Oct '24

Issue #18127 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed I have been merged https://github.com/ruby/singleton/pull/4 ---------------------------------------- Feature #18127: Ractor-local version of Singleton https://bugs.ruby-lang.org/issues/18127#change-110034 * Author: rm155 (Rohit Menon) * Status: Closed ---------------------------------------- **Background** When the Singleton module (from the Singleton library) is included in a class, that class will have only one instance. Since the instance can only be in one Ractor at once, Singleton is not Ractor-compatible. For example, the following code would fail upon trying to access Example.instance in the Ractor: ``` ruby class Example def initialize @value = 1 end end Example.include Singleton Ractor.new do Example.instance end.take #=> can not access instance variables of classes/modules from non-main Ractors (Ractor::IsolationError) ``` In some cases, this may be the desired behavior, as it may be important that the class truly have only one instance. However, in many other cases, it would be more convenient for the class to have one instance per Ractor. **Proposal** The proposal is to create a RactorLocalSingleton module that can be included instead of Singleton to make the instance Ractor-local. Here is how RactorLocalSingleton might be used in the situation above: ``` ruby class Example def initialize @value = 1 end end Example.include RactorLocalSingleton Ractor.new do Example.instance end.take ``` **Discussion** The advantage of creating RactorLocalSingleton is that classes could have Singleton-like behavior while being usable in Ractors. Since some libraries, such as Prime, currently rely on the Singleton module, this would enable those libraries to have more flexibility with Ractors. The disadvantage of creating this module is that it supports the continued use of the Singleton design pattern, which is sometimes considered harmful. An alternative to RactorLocalSingleton might be to simply use Thread-local variables as Singleton instances. Here is how Thread-local variables might be used in the given situation: ``` ruby class Example def initialize @value = 1 end end Ractor.new do Thread.current[:Example] = Example.new Thread.current[:Example] end.take ``` **Summary** Classes that include Singleton are currently incompatible with Ractors. By instead including a new module RactorLocalSingleton, classes can have Singleton-like properties while being used in Ractors. However, this may perpetuate the use of the Singleton design pattern, and using Thread-local variables may be a preferable solution. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119239] [Ruby master Feature#20750] Expose ruby_thread_has_gvl_p in ruby/thread.h
by kbrock (Keenan Brock) 02 Oct '24

02 Oct '24

Issue #20750 has been reported by kbrock (Keenan Brock). ---------------------------------------- Feature #20750: Expose ruby_thread_has_gvl_p in ruby/thread.h https://bugs.ruby-lang.org/issues/20750 * Author: kbrock (Keenan Brock) * Status: Open ---------------------------------------- Hello All, I'm hoping we can make `ruby_thread_has_gvl_p` a public method and no longer experimental. I saw the following code in a gem that was not compiling with ruby 3.3: ``` c // int ruby_thread_has_gvl_p(void); // <== line of concern if (ruby_thread_has_gvl_p()) { method_call(&context); } else { rb_thread_call_with_gvl(method_call, &context); } ``` 400 unique projects on github added the line listed above to fix compilation. [1] Some of the projects detected the method first in `extconf.rb`, but a majority just referenced it. `ffi` used to have the detection code but dropped it since the method was in all supported ruby versions. It feels like this method is now part of the undocumented public interface. My suggestion is to add the method to the real public interface in `ruby/thread.h`. PR with possible solution: https://github.com/ruby/ruby/pull/11619 Also included a patch if that is easier Thank you for your consideration, Keenan Timeline: - Dec 30 2008 - `rb_thread_call_with_gvl` introduced via 9c04a06 [2] - Jan 12 2009 - `ruby_thread_has_gvl_p` introduced via 6f09fc2 [4] - Jul 18 2012 - `rb_thread_call_with_gvl` made public via e9a91d2 [3] Current references to code: `rb_thread_call_with_gvl` [5] `ruby_thread_has_gvl_p` [6]: [1]: https://github.com/search?q=ruby_thread_has_gvl_p+language%3AC++NOT+is%3Afo… [2]: https://github.com/ruby/ruby/commit/9c04a0647fb99f7554cb2e04385ddbb970631e02 [3]: https://github.com/ruby/ruby/commit/e9a91d2c95dfe22ad0487952f7a1053ef9a5fd16 [4]: https://github.com/ruby/ruby/commit/6f09fc2efd1915c4337ce6dded52a8a8771c3222 [5]: https://github.com/ruby/ruby/blob/master/thread.c#L1878 [6]: https://github.com/ruby/ruby/blob/master/thread.c#L1923 ---Files-------------------------------- 11618.patch (3.18 KB) -- https://bugs.ruby-lang.org/

3 7

[ruby-core:119415] [Ruby master Feature#10459] [PATCH] rfc3339 method for Time
by hsbt (Hiroshi SHIBATA) 02 Oct '24

02 Oct '24

Issue #10459 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected I confirmed this to @akr again. He said "rfc3339 is slightly different from iso8601. I don't want to introduce this alias". ---------------------------------------- Feature #10459: [PATCH] rfc3339 method for Time https://bugs.ruby-lang.org/issues/10459#change-110029 * Author: Antiarchitect (Andrey Voronkov) * Status: Rejected * Assignee: akr (Akira Tanaka) ---------------------------------------- Alias for iso8601 method for compatibility with DateTime (Ruby on Rails). ---Files-------------------------------- rfc3339.patch (2.25 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119414] [Ruby master Bug#20780] related to #20779 -- crash creating large number of concurrent-ruby promises
by hms (Hal Spitz) 02 Oct '24

02 Oct '24

Issue #20780 has been reported by hms (Hal Spitz). ---------------------------------------- Bug #20780: related to #20779 -- crash creating large number of concurrent-ruby promises https://bugs.ruby-lang.org/issues/20780 * Author: hms (Hal Spitz) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The attached script crashes (vs. the hang in issue #20779). I believe this is also a OSX specific resource issue, but have been unable to craft a better script to demonstrate the problem. I've included a script to reproduce, the stderr output, and the ruby.ips file. While I am tagging this a 3.3.5 issue, I have reproduced this issue on 3.3.5 - 3.3.1 (Again, a big thanks to @raels for a second set of eyes and sanity checks, @eregon and @bensheldon for the fantastic support over at concurrent-ruby) ---Files-------------------------------- concurrent.rb (378 Bytes) stderr.out (1.74 MB) ruby-2024-10-02-164819.ips.zip (1.38 MB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119412] [Ruby master Feature#17326] Add Kernel#must! to the standard library
by retro 02 Oct '24

02 Oct '24

Issue #17326 has been updated by retro (Josef Šimánek). Looks like PR was opened at https://github.com/ruby/ruby/pull/11772. ---------------------------------------- Feature #17326: Add Kernel#must! to the standard library https://bugs.ruby-lang.org/issues/17326#change-110026 * Author: jez (Jake Zimmerman) * Status: Open ---------------------------------------- # Abstract We should add a method `Kernel#must!` (name TBD) which raises if `self` is `nil` and returns `self` otherwise. # Background Ruby 3 introduces type annotations for the standard library. Type checkers consume these annotations, and report errors for type mismatches. One of the most common and most valuable type errors is whether `nil` is allowed as an argument or return value. Sorbet's type system tracks this, and RBS files have syntax for annotating whether `nil` is allowed or not. Since Sorbet checks proper usage of `nil`, it requires code that looks like this: ```ruby if thing.nil? raise "The thing was nil" end thing.do_something ``` This is good because it forces the programmer to acknowledge that the thing might be `nil`, and declare that they'd rather raise an exception in that case than handle the `nil` (of course, there are many other times where `nil` is both possible and valid, which is why Sorbet forces at least considering in all cases). It is annoying and repetitive to have to write these `if .nil?` checks everywhere to ignore the type error, so Sorbet provides it as a library function, called `T.must`: ```ruby T.must(thing).do_something ``` Sorbet knows that the call to `T.must` raises if `thing` is `nil`. To make this very concrete, here's a Sorbet playground where you can see this in action: [→ View on sorbet.run](https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3ASig%0A%0Aclass%20Thing%0A%20%20def%20do_something%3B%20end%0Aend%0A%0Asig%20%7Bparams(thing%3A%20T.nilable(Thing)).void%7D%0Adef%20example1(thing)%0A%20%20%23%20error%2C%20might%20be%20nil%3A%0A%20%20thing.do_something%0Aend%0A%0Asig%20%7Bparams(thing%3A%20T.nilable(Thing)).void%7D%0Adef%20example2(thing)%0A%20%20if%20thing.nil%3F%0A%20%20%20%20raise%20%22The%20thing%20was%20nil%22%0A%20%20end%0A%0A%20%20%23%20no%20error%2C%20because%20it's%20after%20the%20%60if%20.nil%3F%60%20check%3A%0A%20%20thing.do_something%0Aend%0A%0Asig%20%7Bparams(thing%3A%20T.nilable(Thing)).void%7D%0Adef%20example3(thing)%0A%20%20%23%20no%20error%2C%20because%20it's%20after%20the%20%60if%20.nil%3F%60%20check%3A%0A%20%20T.must(thing).do_something%0Aend) You can read more about `T.must` in the [Sorbet documentation](https://sorbet.org/docs/type-assertions#tmust). # Problem While `T.must` works, it is not ideal for a couple reasons: 1. It leads to a weird outward spiral of flow control, which disrupts method chains: ```ruby # ┌─────────────────┐ # │ ┌────┐ │ # ▼ ▼ │ │ T.must(T.must(task).mailing_params).fetch('template_context') # │ │ ▲ ▲ # │ └──────────┘ │ # └─────────────────────────────────┘ ``` compare that control flow with this: ```ruby # ┌────┐┌────┐┌─────────────┐┌────┐ # │ ▼│ ▼│ ▼│ ▼ task.must!.mailing_params.must!.fetch('template_context') ``` 2. It is not a method, so you can't `map` it over a list using `Symbol#to_proc`. Instead, you have to expand the block: ```ruby array_of_integers = array_of_nilable_integers.map {|x| T.must(x) } ``` Compare that with this: ```ruby array_of_integers = array_of_nilable_integers.map(&:must!) ``` 3. It is in a Sorbet-specific gem. We do not intend for Sorbet to be the only type checker. It would be nice to have such a method in the Ruby standard library so that it can be shared by all type checkers. 4. This method can make Ruby codebases that **don't** use type checkers more robust! `Kernel#must!` could be an easy way to assert invariants early. Failing early makes it more likely that a test will fail, rather than getting `TypeError`'s and `NoMethodError`'s in production. This makes all Ruby code better, not just the Ruby code using types. # Proposal We should extend the Ruby standard library with something like this:: ```ruby module Kernel def must!; self; end end class NilClass def must! raise TypeError.new("nil.must!") end end ``` These methods would get type annotations that look like this: (using Sorbet's RBI syntax, because I don't know RBS well yet) ```ruby module Kernel sig {returns(T.self_type)} def must!; end end class NilClass sig {returns(T.noreturn)} def must!; end end ``` What these annotations say: - In `Kernel#must!`, the return value is `T.self_type`, or "whatever the type of the receiver was." That means that `0.must!` will have type `Integer`, `"".must!` will have type `String`, etc. - In `NilClass#must!`, there is an override of `Kernel#must!` with return type `T.noreturn`. This is a fancy type that says "this code either infinitely loops or raises an exception." This is the name for Sorbet's [bottom type](https://en.wikipedia.org/wiki/Bottom_type), if you are familiar with that terminology. Here is a Sorbet example where you can see how these annotations behave: [→ View on sorbet.run](https://sorbet.run/#%23%20typed%3A%20true%0A%0Amodule%20Kernel%0A%20%20T%3A%3ASig%3A%3AWithoutRuntime.sig%20%7Breturns(T.self_type)%7D%0A%20%20def%20must!%3B%20self%3B%20end%0Aend%0A%0Aclass%20NilClass%0A%20%20T%3A%3ASig%3A%3AWithoutRuntime.sig%20%7Breturns(T.noreturn)%7D%0A%20%20def%20must!%0A%20%20%20%20raise%20TypeError.new(%22nil.must!%22)%0A%20%20end%0Aend%0A%0Axs%20%3D%20T%3A%3AArray%5BInteger%5D.new(%5B0%5D)%0AT.reveal_type(xs.first)%20%20%20%20%20%20%20%23%20T.nilable(Integer)%0AT.reveal_type(xs.first.must!)%20%23%20Integer%0A%0Ays%20%3D%20T%3A%3AArray%5BT.nilable(Integer)%5D.new(%5B0%2C%20nil%2C%201%2C%20nil%2C%202%5D)%0AT.reveal_type(ys)%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20T%3A%3AArray%5BT.nilable(Integer)%5D%0AT.reveal_type(ys.map(%26%3Amust!))%20%23%20T%3A%3AArray%5BInteger%5D) # Alternatives considered There was some discussion of this feature at the Feb 2020 Ruby Types discussion: Summarizing: - Sorbet team frequently recommends people to use `xs.fetch(0)` instead of `T.must(xs[0])` on `Array`'s and `Hash`'s because it chains and reads better. `.fetch` not available on other classes. - It's intentional that `T.must` requires as many characters as it does. Making it slightly annoying to type encourages developers to refactor their code so that `nil` never occurs. - There was a proposal to introduce new syntax like `thing.!!`. This is currently a syntax error. **Rebuttal**: There is burden to introducing new syntax. Tools like Rubocop, Sorbet, and syntax highlighting plugins have to be updated. Also: it is hard to search for on Google (as a new Ruby developer). Also: it is very short—having something slightly shorter makes people think about whether they want to type it out instead of changing the code so that `nil` can't occur. Another alternative would be to dismiss this as "not useful / common enough". I don't think that's true. Here are some statistics from Stripe's Ruby monolith (~10 million lines of code): | methood | percentage of files mentioning method | number of occurrences of method | | --- | --- | --- | | `.nil?` | 16.69% | 31340 | | `T.must` | 23.89% | 74742 | From this, we see that - `T.must` is in 1.43x more files than `.nil?` - `T.must` occurs 2.38x more often than `.nil?` # Naming I prefer `must!` because it is what the method in Sorbet is already called. I am open to naming suggestions. Please provide reasoning. # Discussion In the above example, I used `T.must` twice. An alternative way to have written that would have been using save navigation: ```ruby T.must(task&.mailing_params).fetch('template_context') ``` This works as well. The proposed `.must!` method works just as well when chaining methods with safe navigation: ```ruby task&.mailing_params.must!.fetch('template_context') ``` However, there is still merit in using `T.must` (or `.must!`) twice—it calls out that the programmer intended neither location to be `nil`. In fact, if this method had been chained across multiple lines, the backtrace would include line numbers saying specifically **which** `.must!` failed: ```ruby task.must! .mailing_params.must! .fetch('template_context') ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119331] [Ruby master Feature#20768] Add Hash#delete_at
by seanpdoyle (Sean Doyle) 01 Oct '24

01 Oct '24

Issue #20768 has been reported by seanpdoyle (Sean Doyle). ---------------------------------------- Feature #20768: Add Hash#delete_at https://bugs.ruby-lang.org/issues/20768 * Author: seanpdoyle (Sean Doyle) * Status: Open ---------------------------------------- Add `Hash#delete_at` to delete values from a list keyed by its arguments. The interface and return values draw inspiration from [Hash#values_at](https://docs.ruby-lang.org/en/3.3/Hash.html#method-i-values… and [Array#delete_at](https://docs.ruby-lang.org/en/3.3/Array.html#method-i-dele…. It can pair nicely with multiple assignment to deconstruct a `Hash` instance: ```ruby hash = { a: true, b: false } a, c = hash.delete_at(:a, :c) # => [ true, nil ] hash # => { b: false } ``` Similar outcomes can be achieved with rightward assignment: ```ruby hash = { a: true, b: false } hash => { a:, **rest } a # => true rest # => { b: false } ``` However, rightward assignment will raise an error when a key is missing, whereas `Hash#delete_at` could return `nil` or the `Hash#default_value`: ```ruby hash => { c: } # => raises NoMatchingPatternKeyError ``` Similarly, rightward assignment does not mutate the original `Hash` instance. In some circumstances, this is beneficial. However, others that require mutation would involve re-assigning the variable: ```ruby hash => { a:, **hash } a # => true hash # => { b:false } ``` Finally, a block can be passed in the same style as [Hash#delete](https://docs.ruby-lang.org/en/3.3/Hash.html#method-i-delete) to provide a default value: ```ruby attributes = { disabled: true, aria: { label: "label text" } } aria, data = attributes.delete_at(:aria, :data) { Hash.new } attributes # => { disabled: true } aria # => { label: "label text" } data # => {} ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119356] [Ruby master Bug#20773] CI of RHEL8 and Amazon Linux 2 are failed from Sep 26th
by hsbt (Hiroshi SHIBATA) 30 Sep '24

30 Sep '24

Issue #20773 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20773: CI of RHEL8 and Amazon Linux 2 are failed from Sep 26th https://bugs.ruby-lang.org/issues/20773 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- RHEL8 and Amazon Linux 2 are failed with `Cannot allocate memory - fork(2)` from Sep 26th. * http://rubyci.s3.amazonaws.com/rhel8/ruby-master/log/20240926T093004Z.fail.… * http://rubyci.s3.amazonaws.com/amazon2/ruby-master/log/20240926T033004Z.fai… I'm not sure what's the root cause yet. Amazon Linux 2 is resolved with swapon by @mame. These are strange to increase to usage of memory only for some old distribution. -- https://bugs.ruby-lang.org/

1 1