ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-core

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-core@ml.ruby-lang.org

April 2026

  • 1 participants
  • 152 discussions
[ruby-core:124843] [Ruby Misc#21916] DevMeeting before RubyKaigi 2026
by ko1 (Koichi Sasada) 12 May '26

12 May '26
Issue #21916 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Misc #21916: DevMeeting before RubyKaigi 2026 https://bugs.ruby-lang.org/issues/21916 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- RubyKaigi 2026 will be at Hakodate, Japan, Apr 22th - 24th. We would like to try to hold a face-to-face dev meeting at Hakodate. (@matz will also participate!) * Date: 2026/04/21 (Tue.) 15:00-17:00 (The day before RubyKaigi) * Location: RubyKaigi venue (detailed will be announced before the meeting) ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. Please sign up on the doorkeeper page: https://rubyassociation.doorkeeper.jp/events/195298 The meeting will be held in a hackathon event. Please enjoy Ruby hacking with friends if you want before the meeting. Note: Do not forget to register RubyKaigi ticket too (see "[ruby-core:124591] Invitation to RubyKaigi 2026" from Akira). ### Program * 11:00am door open and start the Hackathon event * 3:00pm opening and self introduction * 3:30pm discuss topics * 5:00pm closing and free time (closing time is depends on topics) * 6:00pm door close ### Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/04/20. I'll ask Matz which should be discussed on this meeting and reorder them. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/
6 6
0 0
[ruby-core:125279] [Ruby Bug#22004] parse.y doesn't executes loop body with `while true || true` condition
by Earlopain (Earlopain _) 11 May '26

11 May '26
Issue #22004 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #22004: parse.y doesn't executes loop body with `while true || true` condition https://bugs.ruby-lang.org/issues/22004 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-15T13:47:25Z master d077df24a2) +PRISM [x86_64-linux] * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- ```rb while true || true puts 1 end ``` This should never exit but with parse.y, the body is never executed. It seems to happen when one of the conditions is a truthy literal. Something similar happens with `unitl`: ```rb until false && true puts 1 end ``` By moving the literals out to methods that just return them, it behaves like I would expect. Seems to have started happening in Ruby 3.3. -- https://bugs.ruby-lang.org/
3 2
0 0
[ruby-core:124918] [Ruby Bug#21940] Ruby::Box: `$_` returns stale value due to gvar_tbl caching
by dak2 (Daichi Kamiyama) 11 May '26

11 May '26
Issue #21940 has been reported by dak2 (Daichi Kamiyama). ---------------------------------------- Bug #21940: Ruby::Box: `$_` returns stale value due to gvar_tbl caching https://bugs.ruby-lang.org/issues/21940 * Author: dak2 (Daichi Kamiyama) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Environment - Ruby Version v4.0.1 - OS: macOS 15.6.1 (arm64) - `RUBY_BOX=1` enabled ## Reproduction ```shell echo -e "a\nb" | RUBY_BOX=1 ruby -e 'gets; $_; gets; p $_' ``` ## Expected ``` "b\n" ``` The second gets reads `"b"` and sets it to `$_`. `p $_` should return the latest value. ## Actual ``` "a\n" ``` `$_` returns the stale value from the first gets. ## Root Cause `$_` is a special variable stored in `svar`. Its getter (`rb_lastline_get`) reads the current value from svar each time it is called. However, when Box is enabled, I believe `rb_gvar_get()` caches the value in the Box's `gvar_tbl` on first access. On subsequent reads, it returns the cached value directly without calling the getter. Since gets updates `$_` via `rb_lastline_set()` which bypasses `rb_gvar_set()`, the cache becomes stale. -- https://bugs.ruby-lang.org/
3 4
0 0
[ruby-core:115241] [Ruby master Bug#19986] Win32: `HOME` is set to just `HOMEDRIVE` if `HOMEPATH` is unset
by nobu (Nobuyoshi Nakada) 11 May '26

11 May '26
Issue #19986 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19986: Win32: `HOME` is set to just `HOMEDRIVE` if `HOMEPATH` is unset https://bugs.ruby-lang.org/issues/19986 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ``` $ env -u HOME -u USERPROFILE -u HOMEPATH HOMEDRIVE=no/such/home ./miniruby.exe -e 'p ENV["HOME"], Dir.home' "no/such/home" "no/such/home" ``` `HOMEDRIVE` should be ignored without `HOMEPATH`, and `HOME` should fallback to `CSIDL_PROFILE`. -- https://bugs.ruby-lang.org/
1 1
0 0
[ruby-core:118940] [Ruby master Bug#20696] `IO.read` ignores `err:` option
by nobu (Nobuyoshi Nakada) 11 May '26

11 May '26
Issue #20696 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20696: `IO.read` ignores `err:` option https://bugs.ruby-lang.org/issues/20696 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I expected the following code captures the error message, but `err:` option is ignored. ```shell-session $ ruby -e 'p IO.read("|ruby -e raise", err: %i[child out])' -e:1:in '<main>': unhandled exception "" ``` -- https://bugs.ruby-lang.org/
1 1
0 0
[ruby-core:124825] [Ruby Bug#21880] The ultra_safe mode of pstore bundled with Ruby 4.0 is broken.
by s3fxn (s3 fxn) 09 May '26

09 May '26
Issue #21880 has been reported by s3fxn (s3 fxn). ---------------------------------------- Bug #21880: The ultra_safe mode of pstore bundled with Ruby 4.0 is broken. https://bugs.ruby-lang.org/issues/21880 * Author: s3fxn (s3 fxn) * Status: Open * ruby -v: 4.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- here is the reproduction code. $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] $ cat pstore.rb #!/usr/bin/env ruby require "bundler/inline" gemfile do source "https://rubygems.org" if ENV['DEBUG'] gem "pstore", "0.1.4" else gem "pstore" end end db = PStore.new("pstore.db") db.ultra_safe = true db.transaction do puts db["now"] = Time.now end $ ruby pstore.rb 2026-02-15 04:49:31 +0000 /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:676:in 'Ractor.make_shareable': Proc's self is not shareable: #<Proc:0x0000749f688df078 /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:673> (Ractor::IsolationError) from /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:676:in 'PStore#on_windows?' from /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:685:in 'PStore#save_data' from /home/s3fxn/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pstore-0.2.0/lib/pstore.rb:575:in 'PStore#transaction' from pstore.rb:14:in '<main>' $ DEBUG=1 ruby pstore.rb 2026-02-15 04:49:53 +0000 -- https://bugs.ruby-lang.org/
6 6
0 0
[ruby-core:124604] [Ruby Bug#21847] Backport `syntax_suggest` 2.0.3 to supported branches
by Earlopain (Earlopain _) 09 May '26

09 May '26
Issue #21847 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21847: Backport `syntax_suggest` 2.0.3 to supported branches https://bugs.ruby-lang.org/issues/21847 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Prism contains a translation layer for ripper, which until very recently didn't emit `on_sp` tokens. This has now been implemented to improve compatibility. However right after merging some `syntax_suggest` tests started failing: https://gist.github.com/schneems/834c75345b2085bda54dab69d913bcc0. `syntax_suggest` is using the ripper translation layer and is working around the missing `on_sp` tokens. Now that they are correctly created by prism, `syntax_suggest` is not able to handle these. For prism this is just a bugfix but I do not want to break `syntax_suggest` unnecessarily. I asked @schneems and this is what he had to say about it: https://github.com/ruby/syntax_suggest/pull/243#issuecomment-3779113958 Backport PRs: -- https://bugs.ruby-lang.org/
4 3
0 0
[ruby-core:124950] [Ruby Bug#21947] `Timeout.timeout` doesn't use `Timeout::ExitException` when Fiber scheduler is in use.
by ioquatix (Samuel Williams) 09 May '26

09 May '26
Issue #21947 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21947: `Timeout.timeout` doesn't use `Timeout::ExitException` when Fiber scheduler is in use. https://bugs.ruby-lang.org/issues/21947 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- The following example executes successfully after 7 seconds instead of timing out after 2. ```ruby require 'async' require 'net/http' start = Time.now Sync do Timeout.timeout 2 do Net::HTTP.get(URI 'https://httpbin.org/delay/5') puts "...request finished, no timeout though; in #{Time.now - start}s" end end puts "Duration: #{Time.now - start}s" # => ...request finished, no timeout though; in 7.7007s # Duration: 7.700962s ``` There are two issues: - `Net::HTTP` rescues `Timeout::Error` and retries. This causes 2s (timeout -> retry) + 5s execution time. - `Timeout.timeout` uses `Timeout::ExitException` when no exception is specified, but the Fiber scheduler code path was not updated. See <https://github.com/socketry/async/issues/448> for more discussion. -- https://bugs.ruby-lang.org/
3 4
0 0
[ruby-core:124920] [Ruby Bug#21941] Local variable becomes nil when YJIT enabled mid-method with fork/signal/ensure
by nicholasdower (Nick Dower) 09 May '26

09 May '26
Issue #21941 has been reported by nicholasdower (Nick Dower). ---------------------------------------- Bug #21941: Local variable becomes nil when YJIT enabled mid-method with fork/signal/ensure https://bugs.ruby-lang.org/issues/21941 * Author: nicholasdower (Nick Dower) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code results in the `read` local variable becoming nil, even though it is never reassigned: ``` def run fork_safe = ->(t) { t } RubyVM::YJIT.enable read, wakeup = IO.pipe Signal.trap("SIGCHLD") { wakeup.write("!") } begin while true begin fork { exit } next if read.wait_readable rescue Interrupt end end ensure end end run ``` Error: ``` repro.rb:13:in 'Object#run': undefined method 'wait_readable' for nil (NoMethodError) next if read.wait_readable ^^^^^^^^^^^^^^ from repro.rb:21:in '<main>' ``` See also: https://github.com/puma/puma/issues/3620 https://github.com/Shopify/ruby/issues/625 -- https://bugs.ruby-lang.org/
5 5
0 0
[ruby-core:125235] [Ruby Bug#21991] `$!` stays as the first exception in Ruby Box
by tikkss (Tsutomu Katsube) 08 May '26

08 May '26
Issue #21991 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Bug #21991: `$!` stays as the first exception in Ruby Box https://bugs.ruby-lang.org/issues/21991 * Author: tikkss (Tsutomu Katsube) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Description --- When Ruby Box is enabled (`RUBY_BOX=1`), `$!` inside `rescue` does not change after the first exception. `$!` is expected to show the exception for each `rescue` block, but it always shows the first one. Steps to reproduce --- ```ruby # test.rb begin raise "First error" rescue pp $! end begin raise "Second error" rescue pp $! end begin raise "Third error" rescue pp $! end ``` Expected result --- ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` Actual result --- ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: First error> #<RuntimeError: First error> ``` Additional information --- This issue does not reproduce when `RUBY_BOX=1` is not set: ```console $ ruby test.rb #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` Also, this issue does not reproduce when the exception object is captured explicitly in the `rescue` clause: ```ruby # test.rb begin raise "First error" rescue => e pp e end begin raise "Second error" rescue => e pp e end begin raise "Third error" rescue => e pp e end ``` ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` -- https://bugs.ruby-lang.org/
2 2
0 0
  • ← Newer
  • 1
  • ...
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.