August 2025 - ruby-core - ml.ruby-lang.org

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

26 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: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

[ruby-core:123066] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by Dan0042 (Daniel DeLorme) 25 Aug '25

25 Aug '25

Issue #12282 has been updated by Dan0042 (Daniel DeLorme). k0kubun (Takashi Kokubun) wrote in #note-7: > How about this name? > > ~~~ > places.deep_fetch(:countries, :canada, :ontario) > ~~~ Best suggestion I've seen so far. ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114380 * 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:123064] Zoom In: Your Meeting Link is Here
by Zoom 25 Aug '25

25 Aug '25

2 1