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

[ruby-core:123042] [Ruby Feature#21550] Ractor.sharable_proc/sharable_lambda to make sharable Proc object
by ko1 (Koichi Sasada) 27 Aug '25

27 Aug '25

Issue #21550 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21550: Ractor.sharable_proc/sharable_lambda to make sharable Proc object https://bugs.ruby-lang.org/issues/21550 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Target version: 3.5 ---------------------------------------- Let's introduce a way to make a sharable Proc. * `Ractor.shareable_proc(self: nil, &block)` makes proc. * `Ractor.shareable_lambda(self: nil, &block)` makes lambda. See also: https://bugs.ruby-lang.org/issues/21039 ## Background ### Motivation Being able to create a shareable Proc is important for Ractors. For example, we often want to send a task to another Ractor: ```ruby worker = Ractor.new do while task = Ractor.receive task.call(...) end end task = (sharable_proc) worker << task task = (sharable_proc) worker << task task = (sharable_proc) worker << task ``` There are various ways to represent a task, but using a Proc is straightforward. However, to make a Proc shareable today, self must also be shareable, which leads to patterns like: ```ruby nil.instance_eval{ Proc.new{ ... } } ``` This is noisy and cryptic. We propose dedicated methods to create shareable Proc objects directly. ## Specification * `Ractor.shareable_proc(self: nil, &block)` makes a proc. * `Ractor.shareable_lambda(self: nil, &block)` makes a lambda. Both methods create the Proc/lambda with the given self and make the resulting object shareable. Captured outer variables follow the current `Ractor.make_shareable` semantics: * If a captured outer local variable refers to a shareable object, a shareable Proc may read it. * If any captured outer variable refers to a non‑shareable object, creating the shareable Proc raises an error. ```ruby a = 42 b = "str" Ractor.sharalbe_proc{ p a #=> 42 } Ractor.sharalbe_proc{ # error when making a sharealbe proc p b #=> 42 } ``` * The captured outer local variables are copied by value when the shareable Proc is created. Subsequent modifications of those variables in the creator scope do not affect the Proc. ``` a = 42 shpr = Ractor.sharable_proc{ p a } a = 0 shpr.call #=> 42 ``` ``` * Assigning to outer local variables from within the shareable Proc is not allowed (error at creation). ```ruby a = 42 Ractor.shareable_proc{ # error when making a sharealbe proc a = 43 } ``` More about outer-variable handling are discussed below. In other words, from the perspective of a shareable Proc, captured outer locals are read‑only constants. This proposal does not change the semantics of Ractor.make_shareable() itself. ## Discussion about outer local variables [Feature #21039] discusses how captured variables should be handled. I propose two options. ### 1. No problem to change the @Eregon noted that the current behavior of `Ractor.make_shareable(proc_obj)` can surprise users. While that is understandable, Ruby already has similar *surprises*. For instance: ```ruby RSpec.describe 'foo' do p self #=> RSpec::ExampleGroups::Foo end ``` Here, `self` is implicitly replaced, likely via `instance_exec`. This can be surprising if one does not know self can change, yet it is accepted in Ruby. We view the current situation as a similar kind of surprise. ### 2. Enforce a strict rule for non‑lexical usage The difficulty is that it is hard to know which block will become shareable unless it is lexically usage. ```ruby # (1) On this code, it is clear that the block will be shareable block: a = 42 Ractor.sharable_proc{ p a } # (2) On this code, it is not clear that the block becomes sharable or not get path do p a end # (3) On this code, it has no problem because get '/hello' do "world" end ``` The idea is to allow accessing captured outer variables only for lexically explicit uses of `Ractor.shareable_proc` as in (1), and to raise an error for non‑lexical cases as in (2). So the example (3) is allowed if the block becomes sharable or not. The strict rule is same as `Ractor.new` block rule. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123069] [Ruby Bug#21553] Remove opt_aref_with and opt_aset_with instructions
by tenderlovemaking (Aaron Patterson) 27 Aug '25

27 Aug '25

Issue #21553 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21553: Remove opt_aref_with and opt_aset_with instructions https://bugs.ruby-lang.org/issues/21553 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hi, I'd like to remove the `opt_aref_with` and `opt_aset_with` instructions. I think they are fairly rare these days. Removing them will simplify the YARV compiler, the JIT compilers, and fix an issue with warnings. For background, these instructions are used with code like `foo["bar"]`, but only when the string literal isn't frozen: ``` > ./miniruby --dump=insns -e'foo["bar"]' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putself ( 1)[Li] 0001 opt_send_without_block <calldata!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0003 opt_aref_with "bar", <calldata!mid:[], argc:1, ARGS_SIMPLE> 0006 leave ``` Enabling frozen string literals will use `putobject` with `opt_aref`: ``` > ./miniruby --dump=insns --enable=frozen-string-literal -e'foo["bar"]' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putself ( 1)[Li] 0001 opt_send_without_block <calldata!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE> 0003 putobject "bar" 0005 opt_aref <calldata!mid:[], argc:1, ARGS_SIMPLE>[CcCr] 0007 leave ``` The optimization avoids duping the string if the receiver happens to be a hash. I tested this with YJIT benchmarks and didn't see any impact. To be sure, I checked the lobsters benchmark to find uses of this instruction, and I found it was only used 4 times during any particular request which explained why removing the instruction didn't impact runtime performance. Also, removing these instructions fixes a bug where a "chilled string warning" won't show up. For example: ```ruby class Foo def self.[](x)= x.gsub!(/hello/, "hi") end Foo["hello world"] ``` I would expect to see a "chilled string" warning with this code, but no warning shows up. Removing these instructions makes the warning show up as expected. I sent a patch to remove the instructions here: https://github.com/ruby/ruby/pull/14336 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123076] [Ruby Feature#21554] Which `make` should be supported?
by hsbt (Hiroshi SHIBATA) 26 Aug '25

26 Aug '25

Issue #21554 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21554: Which `make` should be supported? https://bugs.ruby-lang.org/issues/21554 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- @nobu tried to support the following make for prism dependencies: * GNU make(gmake) * BSD make(bsdmake) * NetBSD make(bmake) * NMAKE But it's not complete with `bmake` now. I added `gmake` to our OpenBSD instance and use it for chkbuild failures. @jeremyevans0 Is it ok to use `gmake` on OpenBSD? And I propose defining the necessary make tools for building Ruby as `gmake`, `bsdmake`, and `NMAKE`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123080] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by zverok (Victor Shepelev) 26 Aug '25

26 Aug '25

Issue #12282 has been updated by zverok (Victor Shepelev). I'll allow myself to copy-paste my reasoning from the related ticket #14602: Just a bit of "design space" analysis: 1. I think `dig!` is unusual for core Ruby. A lot of Rubyists are used that in Rails pairs like `find_by`/`find_by!` are raising/non-raising, but I don't remember any Ruby core API using this convention 2. I don't believe the keyword argument is expressive enough. The "visual structure" of the `dig` signature includes multiple values of user data (and the list of values might be of arbitrary length), so the option at the end of arguments is a) not visible enough and b) not immediately intuitively obvious if it isn't part of user's data 3. In Hash, we already have at least two examples of using `fetch` in a sense "get the value or fail": `#[]` vs `#fetch` and `#values_at` vs `#fetch_values`. It seems like it gives enough precedent to look at the "fetch"-based naming, and it seems like `fetch_dig`, while grammatically not ideal, would be guessable enough, based on existing experience. (...) I fully agree with @duerst in #14602#note-24: > maybe we can think it as a combination of `dig` with `fetch`. Then what about `dig_fetch` or `fetch_dig`? These names don't look very natural, but it's easy to understand what they are about. First, we **already have examples of `fetch`-based naming**: not only `#fetch` itself as a variation of `#[]`, but also `#fetch_values` as a variation of `#values_at`, so there is a precedent for **recognizability** Second, I value short one-word names, so all the witty options like `#shovel` and `#retrieve` are nice, but I am afraid that when we have a variation of a known method in an API established long ago, introducing **completely new word** into Ruby would be a false move. Imagine you started to read code and met with `#retrieve` (or `#shovel`) for the first time. There is nothing that might help you to understand what it does; one verb that "a bit resembles `dig`" is not suggestive enough. Third, `deep_fetch` **is** somewhat suggestive, but the problem "it behaves like `dig`, but the name logic is nothing like `dig`" stands. Maybe if it would a pair of, IDK, `#deep_fetch` and `#deep_get` it might've been tolerable, but now is too late for that, everybody has used to `#dig`. `fetch_dig`, OTOH, is reasonably short, clearly suggests the meaning, and follows the logic of other methods existing. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114390 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122969] [Ruby Feature#21545] `#try_dig`: a dig that returns early if it cannot dig deeper
by cb341 (Daniel Bengl) 26 Aug '25

26 Aug '25

Issue #21545 has been reported by cb341 (Daniel Bengl). ---------------------------------------- Feature #21545: `#try_dig`: a dig that returns early if it cannot dig deeper https://bugs.ruby-lang.org/issues/21545 * Author: cb341 (Daniel Bengl) * Status: Open ---------------------------------------- Ruby offers `dig` for traversing nested hashes and arrays. It is strict and will raise if an intermediary object does not support `dig`. In many cases we only want to attempt the lookup and return `nil` if it cannot be followed, without caring about the exact reason. **Example:** ```rb { a: "foo" }.dig(:a, :b) # TypeError: String does not have #dig method { a: "foo" }.try_dig(:a, :b) # => nil ``` This is especially useful when dealing with data from APIs or other inconsistent sources: ```rb api_response = { status: "ok" } api_response.try_dig(:status, :code) # => nil api_response = { status: { code: 200 } } api_response.try_dig(:status, :code) # => 200 ``` The name `try_dig` makes it clear that it behaves like `dig` but will never raise for structural mismatches. It complements `dig` and the proposed `dig!` ([#12282](https://bugs.ruby-lang.org/issues/12282), [#15563](https://bugs.ruby-lang.org/issues/15563)) by covering the tolerant lookup case. A possible sketch: ```rb class Object def try_dig(*path) current = self path.each do |key| return nil unless current.respond_to?(:dig) begin current = current.dig(key) rescue StandardError return nil end end current end end ``` **Advantages** - Simplifies tolerant lookups without repetitive rescue logic - Clear intent when the value is optional - Useful for working with inconsistent or partially known data structures - Complements `dig` and potential `dig!` by covering the tolerant case **Disatvantages** - May hide structural issues that should be noticed during development -- https://bugs.ruby-lang.org/

5 9

[ruby-core:123077] Your Meeting Link is Here
by Zoom lnvite 26 Aug '25

26 Aug '25

1 0

[ruby-core:123075] Bonus Payment For ruby-core@ruby-lang.org
by ruby-core＠ruby-lang.org 26 Aug '25

26 Aug '25

1 0

[ruby-core:122343] [Ruby Misc#21385] Namespace: Suggesting a rename
by fxn (Xavier Noria) 26 Aug '25

26 Aug '25

Issue #21385 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21385: Namespace: Suggesting a rename https://bugs.ruby-lang.org/issues/21385 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- I'd like to suggest a rename of namespaces. The word "namespace" is already taken in Ruby. We say that classes and modules act as or represent. Constant paths nest them in practice. We say that it is a best practice that gems create their own namespace, etc. If the feature goes ahead with this name, the above sentences, well-established in the Ruby community, will start to sound confusing, because that meaning of "namespace" stays. If you look at the index in Matz's book, "namespaces" is indexed in pages 248–250. Title of section 7.5.1 is "Modules as Namespaces". Besides, I have had a few experiences explaining the proposal to people, and quickly realizing they assume this is something like C++ namespaces or Java packages. Then, I have to undo that mental model and start all over saying "forget that mental model". Those are like our constant paths, only more simple and strict. I think it may also be confusing in this sense (though this could be OK if it wasn't for the previous point.) To be constructive: Some alternative names that I have thought about are "isolates", "shields", or "cells". ("sandboxes" is close, but may have security connotations you do not want to suggest.) -- https://bugs.ruby-lang.org/

16 27

[ruby-core:123068] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by Eregon (Benoit Daloze) 25 Aug '25

25 Aug '25

Issue #12282 has been updated by Eregon (Benoit Daloze). Agreed `deep_fetch` is good. Also wanted to mention `dig_fetch` from https://bugs.ruby-lang.org/issues/14602#note-16, there is even [a blog post about it](https://shopify.engineering/dig-fetch-truffleruby) so I think that illustrates it's a common name for this functionality. What this issue wants is `dig` with `fetch` semantics instead of `[]` semantics, hence `dig_fetch`. `fetch_path` doesn't seem ideal to me because this method would also be used e.g. with arrays and `object.fetch_path(:foo, 2, :baz)` doesn't really sounds like a "path". Similarly, `deep_fetch` looks nice but doesn't make the relation to `dig` as clear as `dig_fetch`. It could be `obj.dig(:foo, 2, :baz, exception: true)` I guess, but that's very verbose. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114381 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123067] (7) incoming messages on hold
by administrator 25 Aug '25

25 Aug '25

1 0