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

[ruby-core:119929] [Ruby master Feature#20894] Allow `Range#last(n)` for beginless ranges with Integer end
by kyanagi (Kouhei Yanagita) 14 Nov '24

14 Nov '24

Issue #20894 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Feature #20894: Allow `Range#last(n)` for beginless ranges with Integer end https://bugs.ruby-lang.org/issues/20894 * Author: kyanagi (Kouhei Yanagita) * Status: Open ---------------------------------------- `Range#last(n)` raises an exception on beginless ranges. ``` (..5).last(3) #=> can't iterate from NilClass (TypeError) ``` Since Ruby 3.3, `Range#reverse_each` for beginless ranges with an integer end has been allowed. ``` (..5).reverse_each { p _1 } #=> 5, 4, 3, 2, 1, ... ``` Therefore, shouldn't `Range#last(n)` for such ranges also be acceptable? ``` # before (..5).last(3) => can't iterate from NilClass (TypeError) # after (..5).last(3) => [3, 4, 5] ``` If this is accepted, a similar change could be considered for `Range#max(n)` as well. https://github.com/ruby/ruby/pull/12084 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119892] [Ruby master Feature#20887] Add "latest" version to "docs.ruby-lang.org"
by p8 (Petrik de Heus) 13 Nov '24

13 Nov '24

Issue #20887 has been reported by p8 (Petrik de Heus). ---------------------------------------- Feature #20887: Add "latest" version to "docs.ruby-lang.org" https://bugs.ruby-lang.org/issues/20887 * Author: p8 (Petrik de Heus) * Status: Open ---------------------------------------- Searching for Ruby documentation regularly returns outdated documentation. For example searching for "ruby comparable" : https://www.google.com/search?hl=en&q=ruby%20comparable" returns: - Module: Comparable (Ruby 2.5.8) - Module: Comparable (Ruby 3.0.3) It would be nice if we had a `https://docs.ruby-lang.org/en/latest` that points the latest released version. Older versions could add the "canonical" link to let search engines know what the preferred version is: ```html <link rel="canonical" href="https://docs.ruby-lang.org/en/latest/Comparable.html" /> ``` https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel#canonical This would also allow others to link to this latest versions, instead of hardcoding the version or using "master". -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119901] [Ruby master Bug#20891] Dir.foreach does not give a static list.
by karasu (karasu k) 13 Nov '24

13 Nov '24

Issue #20891 has been reported by karasu (karasu k). ---------------------------------------- Bug #20891: Dir.foreach does not give a static list. https://bugs.ruby-lang.org/issues/20891 * Author: karasu (karasu k) * Status: Open * ruby -v: 2.7.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I was using `Dir.foreach` with a block to batch change filenames. The sample code is something like this: ```rb look_up_table = File.open('look-up-table' ,'w') Dir.foreach('.').each_with_index do |file, index| File.rename(file, index) look_up_table << "#{file}: #{index}\n" end ``` As first I thought it's good, but I found that some indices might be missing. After staring at the look-up table for hours, I realised some files were modified more than once, and this is strange for me. It means that in each iteration of `Dir.foreach`, it acutally **might** fetch the files to see if there are new files that are not in the list before? What I mean **might** is that this situation does not occur anytime, I don't know how to or not to trigger it, but this is what I faced. I am aware that in `Dir.foreach` it might have some `yield` so this behavior might be normal for you guys, but since the function is called `foreach`, I assumed that it should give a list that is not gonna change once it's established. My later fix change to the sample code is: ```rb look_up_table = File.open('look-up-table' ,'w') Dir.foreach('.').to_a.each_with_index do |file, index| File.rename(file, index) look_up_table << "#{file}: #{index}\n" end ``` You can see that I add a `to_a` to change the result from `Dir.foreach` into an array, and rename those files according to it, instead of the result itself. I wonder if this is an old issue but I cannot find it anywhere else. Thanks in advance. Both English and Japanese are welcome! (I know that `Dir.foreach` will give `.` and `..` as well, but let's just forget it for now.) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119895] [Ruby master Bug#20889] IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position
by javanthropus (Jeremy Bopp) 12 Nov '24

12 Nov '24

Issue #20889 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20889: IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position https://bugs.ruby-lang.org/issues/20889 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetbyte(93) f.pos # => -1; negative value is surprising! end Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-8')) f.pos # => -1; similar to the ungetbyte case end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) f.pos # => 0; maybe should be -2 to match the previous ungetc case? end ``` It doesn't seem logical that `IO#pos` should ever be affected by `IO#ungetc` or `IO#ungetbyte`. The pushed characters or bytes aren't really in the stream source. The value of `IO#pos` implies that jumping directly to that position via `IO#seek` and reading from there would return the same character or byte that was pushed, but the pushed characters or bytes are lost when the operation to seek in the stream is performed. In the case where `IO#pos` is a negative value, attempting to seek to that position actually raises an exception. In the `IO#ungetc` with character conversion case above, it seems unreasonable to make `IO#pos` report an even less correct position. In that case, the position would need to be adjusted by 2 bytes in reverse due to the internal encoding of the stream, but that is completely inconsistent with the behavior of `IO#pos` when reading from the stream normally where it reports the underlying stream's byte position and not the number of transcoded bytes that have been read: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc.bytesize # => 2; due to the internal encoding of the stream f.pos # => 1; reports actual bytes read from the stream, not transcoded bytes end ``` Attempting to use `IO#pos` when there are characters or bytes pushed into the read buffer by way of `IO#ungetc` or `IO#ungetbyte` should result in one of the following behaviors: 1. Raise and exception 2. Return the stream's position, clearing the read buffer entirely 3. Return the stream's position, ignoring the pushed characters or bytes, and produce a warning -- https://bugs.ruby-lang.org/

1 0

[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:119889] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Eregon (Benoit Daloze) 12 Nov '24

12 Nov '24

Issue #6648 has been updated by Eregon (Benoit Daloze). nobu (Nobuyoshi Nakada) wrote in #note-43: > Saving a path string is not reliable. Why not? Are you thinking if the directory is removed? In that case there is no way to rerun the command faithfully, so an error like Errno::ENOENT is fine. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-110580 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119886] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by nobu (Nobuyoshi Nakada) 12 Nov '24

12 Nov '24

Issue #6648 has been updated by nobu (Nobuyoshi Nakada). Eregon (Benoit Daloze) wrote in #note-42: > @nobu True, it would also be helpful to have a way to capture the original CWD. > Then that example would work just fine with `ruby -C subdir -e 'exec(RbConfig.ruby, *Process.ruby_args, "-e", "p :OK", chdir: Process.original_working_directory)'` > (using the naming from https://bugs.ruby-lang.org/issues/6648#note-10 but with `Process`). How to "capture the original CWD"? Keeping a fd open is uselessly expensive in many case, I think. Saving a path string is not reliable. I think the method to run without `-C` options in the CWD is better. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-110576 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[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:119868] [Ruby master Feature#17566] Tune thread QoS / efficiency on macOS
by shan (Shannon Skipper) 09 Nov '24

09 Nov '24

Issue #17566 has been updated by shan (Shannon Skipper). From Apple's perspective, it's our "obligation" as developers to make apps go "absolutely idle" on performance cores when "not responding to user input." From their docs, it seems they hope for us to use fine grained priority when we can. See https://developer.apple.com/news/?id=vk3m204o Apple silicon is so popular with programmers that I wonder if it's worth supporting QoS for the sake of developer tools written in Ruby? ---------------------------------------- Feature #17566: Tune thread QoS / efficiency on macOS https://bugs.ruby-lang.org/issues/17566#change-110559 * Author: mperham (Mike Perham) * Status: Open ---------------------------------------- Hi, new Apple M1 processors have "performance" and "efficiency" cores. Apple provides a QoS API so threads can tune which cores they should execute on. Some threads should be executed as high-priority, some should be treated as low-priority. This page shows the pthread APIs that Apple provides: https://developer.apple.com/library/archive/documentation/Performance/Conce… ``` pthread_set_qos_class_self_np(QOS_CLASS_BACKGROUND, 0) ``` I noticed Ruby already provides `Thread#priority=` which says `This is just hint for Ruby thread scheduler. It may be ignored on some platform`. Does this API work still or was it only active for Ruby 1.8's green threads? Should this API use the QoS APIs on macOS? -- https://bugs.ruby-lang.org/

1 0