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

[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

[ruby-core:123062] [Ruby Bug#21551] Ractor isolation error points to the wrong place
by tenderlovemaking (Aaron Patterson) 23 Aug '25

23 Aug '25

Issue #21551 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21551: Ractor isolation error points to the wrong place https://bugs.ruby-lang.org/issues/21551 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following code has a bug in it. The block passed to `Ractor.new` references the outer `channel` variable, so it can't be isolated. The problem is that I forgot to add `|channel|` to the block: ```ruby channel = Ractor::Port.new coordinator = Ractor.new(channel) do inbound_work = Ractor::Port.new channel << inbound_work end ``` However, the exception this raises is strange: ``` > ruby thing.rb thing.rb:3: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. thing.rb:3:in 'Ractor.new': can not isolate a Proc because it accesses outer variables (channel). (ArgumentError) coordinator = Ractor.new(channel) do ^^^^^^^ from thing.rb:3:in '<main>' ``` I would expect the `channel` local inside the block to be underlined instead of the parameter passed to `Ractor.new`. -- https://bugs.ruby-lang.org/

1 0