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

[ruby-core:118839] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by byroot (Jean Boussier) 13 Aug '24

13 Aug '24

Issue #6648 has been updated by byroot (Jean Boussier). This need came up again in https://github.com/rubygems/rubygems/pull/7933. AFAICT there is currently no good way for a program to re-exec itself with all the same arguments. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109406 * 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:118833] [Ruby master Bug#20674] Time zone conversion issue Time.at
by moustafasallam (Moustafa Sallam Mahmoud) 13 Aug '24

13 Aug '24

Issue #20674 has been reported by moustafasallam (Moustafa Sallam Mahmoud). ---------------------------------------- Bug #20674: Time zone conversion issue Time.at https://bugs.ruby-lang.org/issues/20674 * Author: moustafasallam (Moustafa Sallam Mahmoud) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- # Time.at converts the epoch time to the local time zone But there seems a weird case with Central Time (US & Canada) # where it convert it one hour earlier for example # take this timestamp 1728018000 when converted it to Central Time (US & Canada) with Time.at # => Time.zone = "Central Time (US & Canada)" # => "Central Time (US & Canada)" # => Time.at(1728018000) # => 2024-10-04 01:00:00 -0400 # While using ActiveSupport::TimeZone # ActiveSupport::TimeZone['Central Time (US & Canada)'].at(1728018000) # => Fri, 04 Oct 2024 00:00:00.000000000 CDT -05:00 # so Time.at convert it to -4 while ActiveSupport::TimeZone convert it to -5 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118779] [Ruby master Bug#20662] pack("g") completely discards any actual NaN value and always packs the same single-precision bytes for a NaN
by cabo (Carsten Bormann) 13 Aug '24

13 Aug '24

Issue #20662 has been reported by cabo (Carsten Bormann). ---------------------------------------- Bug #20662: pack("g") completely discards any actual NaN value and always packs the same single-precision bytes for a NaN https://bugs.ruby-lang.org/issues/20662 * Author: cabo (Carsten Bormann) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- pack("G")/unpack("G") works great with NaN values. However, # - pack("g") completely discards any actual NaN value and always packs the same bytes for a NaN # ("bug as implemented" in VALUE_to_float) Also: # - unpack("g") always sets the quiet bit to 1 in the Float result # (location of bug not obvious to me) ---Files-------------------------------- showbug.rb (3.21 KB) showbug-arm.txt (5.48 KB) showbug-intel.txt (5.48 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:118826] [Ruby master Bug#20671] Do not show "unused block" warning on `send`
by ko1 (Koichi Sasada) 13 Aug '24

13 Aug '24

Issue #20671 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #20671: Do not show "unused block" warning on `send` https://bugs.ruby-lang.org/issues/20671 * Author: ko1 (Koichi Sasada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Let's disable "unused block" warning on `send` because now it is hard to recognize the calling method accepts a block or not for general framework. Now test/unit has this problem. ```ruby require 'test/unit' class T < Test::Unit::TestCase def setup end def test_foo = nil end #=> /home/ko1/ruby/install/master/lib/ruby/gems/3.4.0+0/gems/test-unit-3.6.2/lib/test/unit/fixture.rb:284: warning: the block passed to 'priority_setup' defined at /home/ko1/ruby/install/master/lib/ruby/gems/3.4.0+0/gems/test-unit-3.6.2/lib/test/unit/priority.rb:183 may be ignored ``` Implementation: https://github.com/ruby/ruby/pull/11349 I think we can revisit it when we provide a way to recognize the calling method may accept a block or not. But now the relaxed behavior is better I think. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118834] New webmail message
by Noreply＠ruby-lang.org 12 Aug '24

12 Aug '24

1 0

[ruby-core:118791] [Ruby master Bug#20666] Segmentation fault instead of LoadError exception
by ErezGeva2＠gmail.com (Erez Geva) 11 Aug '24

11 Aug '24

Issue #20666 has been reported by ErezGeva2(a)gmail.com (Erez Geva). ---------------------------------------- Bug #20666: Segmentation fault instead of LoadError exception https://bugs.ruby-lang.org/issues/20666 * Author: ErezGeva2(a)gmail.com (Erez Geva) * Status: Open * ruby -v: ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Using ruby -v ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt] From [GitHub windows 2022](https://github.com/actions/runner-images/blob/main/images/windows/Win… ) We run the SWIG test: [import_fragments](https://github.com/swig/swig/blob/master/Examples/test-su… The test try to load a broken library, which should rise a `LoadError`. begin require 'import_fragments' rescue LoadError => e # due to missing import_fragments_a exception_file = e.respond_to?(:path) ? e.path : e.to_s.sub(/.* -- /, '') end Instead `LoadError` exception we get `Segmentation fault`: <internal:C:/hostedtoolcache/windows/Ruby/3.2.5/x64/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:151: [BUG] Segmentation fault ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt] -- Control frame information ----------------------------------------------- c:0004 p:0018 s:0028 e:000025 RESCUE <internal:C:/hostedtoolcache/windows/Ruby/3.2.5/x64/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:151 c:0003 p:0275 s:0022 e:000021 METHOD <internal:C:/hostedtoolcache/windows/Ruby/3.2.5/x64/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:40 c:0002 p:0011 s:0007 E:0004e8 EVAL ./import_fragments_runme.rb:13 [FINISH] c:0001 p:0000 s:0003 E:0006e0 DUMMY [FINISH] -- https://bugs.ruby-lang.org/

2 8

[ruby-core:118827] [Ruby master Bug#20672] UNIXSocket.pair transmitting data between pids looks flaky
by danh337 (Dan H) 10 Aug '24

10 Aug '24

Issue #20672 has been reported by danh337 (Dan H). ---------------------------------------- Bug #20672: UNIXSocket.pair transmitting data between pids looks flaky https://bugs.ruby-lang.org/issues/20672 * Author: danh337 (Dan H) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I have code that uses UNIXSocket.pair and fork to send data between parent and child. It seems to work fine for a small number of messages passed, but then fails with Errno::EBADF on the child pid writing to its socket received from the parent. I attached a test driver which includes successful and failed test runs. This is boiled down logic from a larger app, where I first started seeing this issue. I believe I first saw this on Ruby 3.0, but now I am on 3.3.4. This *could* be me, as in my code or my workstation env, but I have not been able to prove that from many web searches. If you look at my test driver and see something wrong with it, I will take the shame and learn something. BUT just in case this is an issue in low level Ruby code, I am submitting this here. ---Files-------------------------------- test.rb (13 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:118782] [Ruby master Bug#20663] Reading from IO does not recover gracefully from bad data pushed via IO#ungetc
by javanthropus (Jeremy Bopp) 09 Aug '24

09 Aug '24

Issue #20663 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20663: Reading from IO does not recover gracefully from bad data pushed via IO#ungetc https://bugs.ruby-lang.org/issues/20663 * Author: javanthropus (Jeremy Bopp) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If bytes that result in at least 2 invalid characters for the internal encoding of an IO object are pushed into the internal buffer with IO#getc, reading from the stream returns invalid characters composed of both bytes from the internal buffer and the converted bytes from the stream even if the next character in the stream itself is completely valid. ``` ruby char_bytes = Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write("🍣") f.rewind f.ungetc("🍣".encode('utf-16le').b[0..-2]) f.each_char.map(&:bytes) end puts char_bytes.inspect ``` The above outputs: ``` [[60, 216], [99, 60], [216, 99], [223]] ``` I expect it to output: ``` [[60, 216], [99], [60, 216, 99, 223]] ``` In other words, I expect it to first completely drain the internal character buffer returning as many characters as necessary (invalid or otherwise) before reading from the stream and converting and returning the next character. Interestingly, if there are only bytes sufficient for 1 invalid character in the internal buffer, it behaves that way: ``` ruby char_bytes = Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write("🍣") f.rewind f.ungetc("🍣".encode('utf-16le').b[0..-3]) # <- Note the -3 here vs. the -2 earlier f.each_char.map(&:bytes) end puts char_bytes.inspect ``` This outputs: ``` [[60, 216], [60, 216, 99, 223]] ``` The first character is invalid, but returning it first clears the buffer. Then the next character is read, converted, and returned in full. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118588] [Ruby master Bug#20634] ruby uses 1/2 (7 out of 16) cores for 16 ractors with RUBY_MAX_CPU=16 environment variable set
by skorobogatydmitry (Dmitry Skorobogaty) 09 Aug '24

09 Aug '24

Issue #20634 has been reported by skorobogatydmitry (Dmitry Skorobogaty). ---------------------------------------- Bug #20634: ruby uses 1/2 (7 out of 16) cores for 16 ractors with RUBY_MAX_CPU=16 environment variable set https://bugs.ruby-lang.org/issues/20634 * Author: skorobogatydmitry (Dmitry Skorobogaty) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It's a cont for #20618, feel free to close this one and reopen the original bug. According to `top`, the below code uses 7/16 cores (700%) of my AMD Ryzen 7 5800HS: #!/usr/bin/env ruby 16.times { Ractor.new { 10_000.downto(1) { |i| 100_000.downto(1) { |j| i * j } } } } sleep 30 ``` Command I ran is `RUBY_MAX_CPU=16 ruby test.rb`. I also tried to set `RUBY_MN_THREADS=1` as an addition and the script starts to occupy 8 cores instead of 7 (possibly, due to N:M algo allocating an extra core for the blocked main Ractor). The same code occupies all 16 cores on ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] The problem reproduces on ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux] (ruby from the latest docker image). -- https://bugs.ruby-lang.org/

1 2

[ruby-core:118789] [Ruby master Bug#20665] Swig testing of Ruby with MinGW-w64 UCRT
by ErezGeva2＠gmail.com (Erez Geva) 07 Aug '24

07 Aug '24

Issue #20665 has been reported by ErezGeva2(a)gmail.com (Erez Geva). ---------------------------------------- Bug #20665: Swig testing of Ruby with MinGW-w64 UCRT https://bugs.ruby-lang.org/issues/20665 * Author: ErezGeva2(a)gmail.com (Erez Geva) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, I try to add SWIG project testing with already installed Ruby on [GitHub Windows2022](https://github.com/actions/runner-images/blob/main/images/wind…. I manage to test with Ruby version 3.0.7 and installed mingw-w64-x86_64-ruby version 3.1.5. Both are build with MinGW-w64. See: https://github.com/swig/swig/pull/2981 Now I want to use the more newer Ruby. GitHub Windows2022 provides 2 Ruby version 3.1.6 and 3.2.5 which are build with MinGW-w64 UCRT. I try and use mingw-w64-ucrt-x86_64-gcc with more mingw-w64-ucrt-x86_64-XXX packages. My testing can be found here: https://github.com/erezgeva/swig/blob/win_ruby2/.github/workflows/windows.y… The test fails: https://github.com/erezgeva/swig/actions/runs/10237377988/job/28320593017 Can you advice what is wrong here? Erez -- https://bugs.ruby-lang.org/

2 4