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

[ruby-core:111966] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module
by zverok (Victor Shepelev) 19 Nov '24

19 Nov '24

Issue #19366 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19366: Rename/alias Refinedment#refined_class => #refined_module https://bugs.ruby-lang.org/issues/19366 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- In #12737, `Refinement#refined_class` is introduced. As "module" is more generic concept than "class", the name misleadingly implies that either this method doesn't returns refined _modules_, or modules can't be refined. This is obviously not true and trivially disproved: ```ruby module Refs refine Enumerable do def foo = puts 'foo' end end Refs.refinements[0].refined_class #=> Enumerable. Which is, well, not a class. # The refinement is usable, so it is not a mute concept: using Refs [1, 2, 3].foo # prints "foo" successfully ``` I believe we refer to "modules" when some feature applies to modules and classes. Unless there is some deeper consideration for the current naming (I don't see justification in #12737, but I might miss something), the method should be renamed or aliased. PS: Sorry for a huge amount of "nitpicky" issues after the version release. Typically, those concerns emerge while I am working on the [changelog](https://rubyreferences.github.io/rubychanges/), and I am usually trying to start the work at least a month before the release. Unfortunately, due to you-know-what, I was unable to do it in time this year. After the 3.2 changelog, I plan to switch to the "master changelog" approach (following the development with the "current unreleased changes" document) this year. Unless I'll be unable to due to reasons not in my control. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:119462] [Ruby master Bug#20785] Should `a in b, and c` `a in b, or c` `a in b, rescue c` be syntax ok?
by tompng (tomoya ishida) 16 Nov '24

16 Nov '24

Issue #20785 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20785: Should `a in b, and c` `a in b, or c` `a in b, rescue c` be syntax ok? https://bugs.ruby-lang.org/issues/20785 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-04T03:22:53Z master 939ec9f080) +YJIT +MN +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This code is accepted in parse.y but rejected in prism ~~~ruby tap do a in b, and c a in b, or c a in b, rescue c end # parsed as tap do (a in b,;) and c (a in b,;) or c a in b,; rescue c end ~~~ I think these should be rejected like prism (parse.y accepts) ~~~ruby a in b, and c a in b, and c tap do a in b, rescue c end ~~~ I think these should be accepted like parse.y (prism rejects) ~~~ruby tap do a in b, end tap do a in b, rescue end ~~~ -- https://bugs.ruby-lang.org/

7 9

[ruby-core:117240] [Ruby master Feature#20350] Return chilled string from Symbol#to_s
by Dan0042 (Daniel DeLorme) 12 Nov '24

12 Nov '24

Issue #20350 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20350: Return chilled string from Symbol#to_s https://bugs.ruby-lang.org/issues/20350 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- During Ruby 2.7 development there was an attempt to return a frozen string from Symbol#to_s (#16150#note-22) This had to be rolled back due to incompatibility, but now we have chilled strings (#20205) Symbol#to_s can safely return a chilled string, giving developers time to fix warnings before switching to a frozen string. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:119506] [Ruby master Feature#20794] Expose information about the currently running GC module
by eightbitraptor (Matthew Valentine-House) 11 Nov '24

11 Nov '24

Issue #20794 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Feature #20794: Expose information about the currently running GC module https://bugs.ruby-lang.org/issues/20794 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open ---------------------------------------- ## Summary [[Github PR #11872]](https://github.com/ruby/ruby/pull/11872) Currently it's not possible for the user to easily find out information about the currently running GC, and whether modular GC has been enabled. The linked PR provides a method for the user to query whether modular GC's are enabled, and whether one is active, as well as a Ruby method that exposes the currently active GC. ## Background Since Modular GC was introduced it's been possible to build Ruby with several different GC configurations: 1. Modular GC disabled. Existing GC is linked statically, and active - This is the default case 2. Modular GC enabled, but not loaded. Existing GC is linked statically and is active. 3. Modular GC enabled, and a GC implementation is loaded and overrides the static default GC. Currently there's not an accurate way of determining which of these states the current Ruby process is in. This makes writing tests that work accurately given different GC configurations complex. It also means that developers and admins running Ruby aren't able to get accurate information about their Ruby processes. ## Proposal This ticket proposes the following changes: * Add GC status to `RUBY_DESCRIPTION` so it's visible in the output of `ruby -v` * Add a method `GC.active_gc_name` that will return the name of the currently running GC as a String. ## Implementation The linked PR implements these proposals. #### No shared GC support This is the default case. Ruby statically links and uses the existing GC, with no means to override it. `RUBY_DESCRIPTION` is obviously unchanged ``` ❯ ruby -v ruby 3.4.0dev (2024-10-09T14:20:46Z mvh-active-gc-name 3cb4bd4d43) +PRISM [arm64-darwin24] ``` and `GC.active_gc_name` returns `nil` ``` ❯ ./ruby -e "p GC.active_gc_name" nil ``` #### Shared GC support enabled, Not loaded This is the case when Ruby has been configured with `--with-shared-gc=/path/to/gc` but no GC has been explicitly loaded using the `RUBY_GC_LIBRARY` environment `RUBY_DESCRIPTION` will contain `+MOD_GC` to indicate that shared GC support is built in. This is similar to how `+PRISM`, and `+YJIT` work. ``` ❯ ruby -v ruby 3.4.0dev (2024-10-09T14:38:38Z mvh-active-gc-name 3cb4bd4d43) +PRISM +MOD_GC [arm64-darwin24] ``` and `GC.active_gc_name` still returns `nil`. This is because the existing statically linked GC is in use, and has not been overridden. ``` ❯ ./ruby -e "p GC.active_gc_name" nil ``` #### Shared GC support enabled, and modular GC loaded This is the case when Ruby has been configured with `--with-shared-gc=/path/to/gc` **and** an alternative GC library has been explicitly loaded using the `RUBY_GC_LIBRARY` environment variable `RUBY_DESCRIPTION` will contain `+MOD_GC` to indicate that shared GC support is built in. This is similar to how `+PRISM`, and `+YJIT` work. In addition it will also contain a GC name, which is a human readable name that each concrete GC implementation needs to provide as part of its API. This is seen here as `+MOD_GC[mmtk]` - because in this case `librubygc.dylib` reports it's name as being `mmtk` ``` ❯ RUBY_GC_LIBRARY=librubygc.dylib ./ruby -v ruby 3.4.0dev (2024-10-09T14:38:38Z mvh-active-gc-name 3cb4bd4d43) +PRISM +MOD_GC[mmtk] [arm64-darwin24] ``` `GC.active_gc_name` returns the GC's name, as configured by the GC module (this will be identical to the reported name loaded into `RUBY_DESCRIPTION`). ``` ❯ RUBY_GC_LIBRARY=librubygc.dylib ./ruby -e "puts GC.active_gc_name" mmtk ``` ### Conclusion This should cover all states that the GC can now be in. Users can now query the state from the command line to see whether modular GC's are enabled and if so, what GC is active. From Ruby we can use `GC.active_gc_name` in conjunction with the pre-existing option `RbConfig::CONFIG['shared_gc_dir']` to find out this same information. This will now make it easier to run different Ruby processes with different GC builds, as well as make it easier for GC implementors to write tests that behave correctly in all these circumstances. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:119641] [Ruby master Bug#20853] Hash key retrieval after Process.warmup
by keelerm84 (Matthew Keeler) 10 Nov '24

10 Nov '24

Issue #20853 has been reported by keelerm84 (Matthew Keeler). ---------------------------------------- Bug #20853: Hash key retrieval after Process.warmup https://bugs.ruby-lang.org/issues/20853 * Author: keelerm84 (Matthew Keeler) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- This was first reported as an issue against the [LaunchDarkly SDK](https://github.com/launchdarkly/ruby-server-sdk/issues/282) and [Sidekiq SDKs](https://github.com/sidekiq/sidekiq/issues/6279) as an issue in Ruby 3.3.1. I can still in Ruby 3.3.5. **Overview of behavior** The LaunchDarkly SDK maintains a hash of feature and segment information. This hash is indexed by 2 keys which are themselves hashes. They are defined as: ``` FEATURES = { namespace: "features", priority: 1, get_dependency_keys: lambda { |flag| (flag[:prerequisites] || []).map { |p| p[:key] } }, }.freeze SEGMENTS = { namespace: "segments", priority: 0, }.freeze ``` When running the attached script, we often see an error indicating that the flag is not found. If you comment out the `Process.warmup` line, this error will go away. The `require 'active_support/all'` directive is not strictly necessary. Including it causes the failure to more frequently occur, presumably due to the increase work in the warmup phase. **Hash key and access** When debugging the LaunchDarkly code, I noticed some odd behavior. Even though the hash seems populated, the FEATURES key could not index into it correctly. Below is a bit of code, modified from the SDK, to show how we are trying to interact with the hash. The puts are added to clarify the issue. ```ruby def get(kind, key) @lock.with_read_lock do @items.keys.each do |k| puts "##### Does #{kind[:namespace]} match the key #{k}? #{k == kind} #{k.eql?(kind)} #{k.hash == kind.hash}" end puts "###### Does @items include it? #{(a)items.include?(kind)}" coll = @items[kind] f = coll.nil? ? nil : coll[key.to_sym] (f.nil? || f[:deleted]) ? nil : f end end ``` *Running without Process.warmup* If we run the attached script without the `Process.warmup` call, we will see that the keys align with the FEATURES key we provided. Additionally, the hash does see that the key exists, resulting in an evaluation result of true at the end. That output follows. ```shell ##### Does features match the key {:namespace=>"segments", :priority=>0}? false false false ##### Does features match the key {:namespace=>"features", :priority=>1, :get_dependency_keys=>#<Proc:0x00007ee6174f9738 /home/mkeeler/code/launchdarkly/ruby-server-sdk.git/main/lib/ldclient-rb/in_memory_store.rb:17 (lambda)>}? true true true ###### Does @items include it? true true ``` *Running with Process.warmup* If you enable the `Process.warmup` option, and run the script a few times, you will see output similar to the following. Note that while the keys are `==`, `eql?`, and their `.hash` values are equal, the hash does not see that the FEATURES key exists. ```shell ##### Does features match the key {:namespace=>"segments", :priority=>0}? false false false ##### Does features match the key {:namespace=>"features", :priority=>1, :get_dependency_keys=>#<Proc:0x0000774f1cbfd730 /home/mkeeler/code/launchdarkly/ruby-server-sdk.git/main/lib/ldclient-rb/in_memory_store.rb:17 (lambda)>}? true true true ###### Does @items include it? false I, [2024-10-30T14:34:33.842145 #974568] INFO -- : [LDClient] Unknown feature flag "sample-feature". Returning default value false ``` **Workarounds** We have worked around this issue by replacing these keys with classes. You can refer to the [PR here](https://github.com/launchdarkly/ruby-server-sdk/pull/301/files) for those details. You can also resolve this by triggering a `rehash` on the hash after the `Process.warmup` has run. ---Files-------------------------------- main.rb (630 Bytes) Gemfile (96 Bytes) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118976] [Ruby master Bug#20704] Windows: `-C` option does not work for multibyte path name
by nobu (Nobuyoshi Nakada) 08 Nov '24

08 Nov '24

Issue #20704 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20704: Windows: `-C` option does not work for multibyte path name https://bugs.ruby-lang.org/issues/20704 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Related to [Bug #20699]. ``` C:> \Ruby33-x64\bin\ruby.exe -C xテスト_test -ep \Ruby33-x64\bin\ruby.exe: Can't chdir to xテスト_test (fatal) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:119495] [Ruby master Feature#20792] String#forcible_encoding?
by kddnewton (Kevin Newton) 08 Nov '24

08 Nov '24

Issue #20792 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20792: String#forcible_encoding? https://bugs.ruby-lang.org/issues/20792 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to add a method to String called `forcible_encoding?(encoding)`. This would return true or false depending on whether the receiver can be forced into the given encoding without breaking the string. It would effectively be an alias for: ```ruby def forcible_encoding?(enc) original = encoding result = force_encoding(enc).valid_encoding? force_encoding(original) result end ``` I would like this method because there are extremely rare but possible circumstances where source files are marked as binary but contain UTF-8-encoded characters. In that case I would like to check if it's possible to cleanly force UTF-8 before actually doing it. The code I'm trying to replace is here: https://github.com/ruby/prism/blob/d6e9b8de36b4d18debfe36e4545116539964ceeb…. The pull request for the code is here: https://github.com/ruby/ruby/pull/11851. -- https://bugs.ruby-lang.org/

7 15

[ruby-core:119602] [Ruby master Feature#20811] `warning: in a**b, b may be too big` is really helpful?
by mame (Yusuke Endoh) 08 Nov '24

08 Nov '24

Issue #20811 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #20811: `warning: in a**b, b may be too big` is really helpful? https://bugs.ruby-lang.org/issues/20811 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I tried to calculate the largest prime number recently discovered. However, it did not work. I was a bit disappointed. ``` $ ruby -e 'p 2**136279841-1' -e:1: warning: in a**b, b may be too big Infinity ``` I know this is not a realistic case, but I checked my past chat logs and found a record of the same thing six years ago and the same disappointment. ``` $ ruby -e 'p 2**77232917-1' -e:1: warning: in a**b, b may be too big Infinity ``` So I would like to ask, has anyone experienced that this behavior has actually been helpful? I think that this limit is to prevent a program from unintentionally spending too much time and memory trying to compute a power that is too large. However, is it helpful to return Infinity in such a situation? I think raising an exception would be safer, if this limit is really needed. Also, is this limit appropriate? On my machine, `2 ** 32537661` is calculated normally and `2 ** 32537662` returns Infinity. This calculation took about 100 ms and 400 kB. I think this is short enough for a single computation time. Incidentally, `2 ** 32537661` in decimal notation is 9,794,814 digits, which may be too loose a limit considering the display. Note that this limit only applies when calculating the power directly. `(2 ** 32537661) * 2` returns an Integer, not Infinity. Even `1 << 32537662` gives an Integer. From the above, I suspect that this limit is not particularly useful and only spoils the fun of mathematics. What do you think? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119575] [Ruby master Bug#20808] Cannot override Data#inspect
by maicolben (Maicol Bentancor) 07 Nov '24

07 Nov '24

Issue #20808 has been reported by maicolben (Maicol Bentancor). ---------------------------------------- Bug #20808: Cannot override Data#inspect https://bugs.ruby-lang.org/issues/20808 * Author: maicolben (Maicol Bentancor) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Given the next code: ``` Dog = Data.define(:name) do def inspect "Hello!" end private attr_reader :name end Dog.new(name: "Fido") ``` It throws an error: - An error occurred when inspecting the object: #<NoMethodError: private method `name' called for an instance of Dog> And isn't using my `inspect` function -- https://bugs.ruby-lang.org/

3 7

[ruby-core:119650] [Ruby master Bug#20857] Don't change `Hash#inspect formatting`
by vo.x (Vit Ondruch) 07 Nov '24

07 Nov '24

Issue #20857 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20857: Don't change `Hash#inspect formatting` https://bugs.ruby-lang.org/issues/20857 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-15 master 3da3cabf98) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Testing Ruby 3.4 in Fedora, I just hit issue like this in AsciiDoctor test suite: ~~~ 1) Failure: Minitest::Test::TestExtensions::TestIntegration#test_should_assign_captures_correctly_for_inline_macros [test/extensions_test.rb:1382]: --- expected +++ actual @@ -1,9 +1,9 @@ "target=\"\", attributes={} -target=\"value,key=val\", attributes={1=>\"value\", \"key\"=>\"val\", \"name\"=>\"value\"} -target=\"\", attributes={\"text\"=>\"\"} -target=\"[text]\", attributes={\"text\"=>\"[text]\"} +target=\"value,key=val\", attributes={1 => \"value\", \"key\" => \"val\", \"name\" => \"value\"} +target=\"\", attributes={\"text\" => \"\"} +target=\"[text]\", attributes={\"text\" => \"[text]\"} target=\"target\", attributes={} -target=\"target\", attributes={1=>\"value\", \"key\"=>\"val\", \"name\"=>\"value\"} -target=\"target\", attributes={\"text\"=>\"\"} -target=\"target\", attributes={\"text\"=>\"[text]\"} +target=\"target\", attributes={1 => \"value\", \"key\" => \"val\", \"name\" => \"value\"} +target=\"target\", attributes={\"text\" => \"\"} +target=\"target\", attributes={\"text\" => \"[text]\"} target=\"target\", attributes={}" ~~~ This suggest that `Hash#inspect` formatting was changed and there are additional spaces around hash rocket. Is the space really worth of the troubles? BTW [here](https://github.com/asciidoctor/asciidoctor/issues/4634#issuecomment-2… is AsciiDoctor upstream reaction and I share the sentiment. -- https://bugs.ruby-lang.org/

8 16