June 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:122600] [Ruby Bug#21451] Ractor.make_shareable(->{}, copy: true) raises unhelpful error
by tenderlovemaking (Aaron Patterson) 25 Jun '25

25 Jun '25

Issue #21451 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21451: Ractor.make_shareable(->{}, copy: true) raises unhelpful error https://bugs.ruby-lang.org/issues/21451 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Assignee: ractor * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` > ruby -e'Ractor.make_shareable(->{}, copy:true)' <internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError) from -e:1:in '<main>' ``` This error isn't very helpful and I think we can improve it. The exception happens when we call `rb_obj_clone` on the lambda. I've made a patch to improve the error message so it's like this: ``` > ./miniruby -e'Ractor.make_shareable(->{}, copy:true)' -e:1:in 'Ractor.make_shareable': cannot copy #<Proc:0x000000011f311a80 -e:1 (lambda)> (Ractor::IsolationError) from -e:1:in '<main>' -e:1:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError) from -e:1:in '<main>' ``` The patch is here: https://github.com/ruby/ruby/pull/13703 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122452] [Ruby Misc#21399] DevMeeting-2025-07-10
by mame (Yusuke Endoh) 25 Jun '25

25 Jun '25

Issue #21399 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21399: DevMeeting-2025-07-10 https://bugs.ruby-lang.org/issues/21399 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/07/10 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # 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/07/07. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - 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/

4 3

[ruby-core:122242] [Ruby Feature#21365] Add `Namespace#eval`
by tenderlovemaking (Aaron Patterson) 25 Jun '25

25 Jun '25

Issue #21365 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21365: Add `Namespace#eval` https://bugs.ruby-lang.org/issues/21365 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- I would like a way to eval code on to a `Namespace` object. Could we add an eval method that _doesn't_ take a binding object? Writing a new file every time I want to test Namespaces is too cumbersome. Thanks! -- https://bugs.ruby-lang.org/

6 11

[ruby-core:122596] Cooperation Offer.
by ruby-core＠ruby-lang.org 25 Jun '25

25 Jun '25

Hello!<br> As you can see, this is not a formal email, and unfortunately, it does not mean anything good for you. <br> BUT do not despair, it is not critical. I am going to explain to you everything right now. <br> <br> I have access to your electronic devices, which are the part of the local network you regularly use. <br> I have been tracking your activity for the last few months. <br> <br> How did that happen?<br> You visited some hacked websites with Exploit, and your device was exposed to my malicious software (I bought it in Darknet from specialists in this field).<br> This is a very complex software, operating as Trojan Horse. It updates regularly, and your antivirus can not detect it. <br> The program has a keylogger; it can turn your camera and microphone on and off, send files and provide access to your local network. <br> <br> It took me some time to get access to the information from other devices, and as of now, I have all your contacts with conversations, info about your locations, what you like, your favourite websites, etc. <br> Honestly, I meant nothing bad at first and did that just for fun. This is my hobby. <br> <br> But I got HIV and unfortunately lost my job. <br> And I figured out how to use "my hobby" to get money from you! <br> I recorded a video of you masturbating. This video has a separated screen, where you can be easily recognised; also, it can be clearly seen what sort of video you prefer. <br> Well, I am not proud of this, but I need money to survive. <br> <br> Let's make a deal. You pay me as much as I ask you to, and I won't send this video to your friends, family, and other acquaintances. <br> You should understand, this is not a joke. I can send it by email, through SMS-link, social media, even post it in mass media (I have got some hacked accounts of their admins).<br> So you can become Twitter or Instagram "Star"! <br> <br> To avoid this, you should send me 1,290 USD in Bitcoins on my BTC wallet:124mgnHaGQDnrgTBQ6aAJvehdepafvsVFg<br> <br> If you don't know how to use Bitcoins, search it in Bing or Google <<how can I purchase Bitcoins>> or other stuff like that. <br> I will delete the video as soon as I receive the money. I will also delete the malicious software from your device, and you will never hear from me again. <br> I'll give you 2 days, that's more than enough, I think. Time tracking will start as soon as you open this email, I am monitoring this! <br> <br> And one last thing:<br> It makes no sense to report about this to the police since I am using TOR, so there is no way to track Bitcoin transactions. <br> Don't respond to me (I generated this letter in your account and put the real address of the man who has no idea about this). In such a way, I make it impossible to track me.<br> <br> If you ever do something stupid or against my expectations, I will immediately share this video. <br> Good luck!<br>

1 0

[ruby-core:122597] Your account has been set to expire
by Administrator ml.ruby-lang.org 25 Jun '25

25 Jun '25

1 0

[ruby-core:112664] [Ruby master Bug#19473] can't be called from trap context (ThreadError) is too limiting
by Eregon (Benoit Daloze) 24 Jun '25

24 Jun '25

Issue #19473 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19473: can't be called from trap context (ThreadError) is too limiting https://bugs.ruby-lang.org/issues/19473 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Simple reproducer: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] -e:1:in `synchronize': can't be called from trap context (ThreadError) from -e:1:in `block in <main>' from -e:1:in `kill' from -e:1:in `<main>' ``` Expected behavior: ``` $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' truffleruby 22.3.1, like ruby 3.0.3, GraalVM CE Native [x86_64-linux] :OK $ ruby -ve 'm=Mutex.new; trap(:HUP) { m.synchronize { p :OK } }; Process.kill :HUP, Process.pid; sleep 0.1' jruby 9.4.0.0 (3.1.0) 2022-11-23 95c0ec159f OpenJDK 64-Bit Server VM 17.0.6+10 on 17.0.6+10 +jit [x86_64-linux] :OK ``` This exception is highly problematic, for instance it breaks `Timeout.timeout` in `trap`: https://github.com/ruby/timeout/issues/17#issuecomment-1142035939 I suppose this behavior is because *sometimes* it's problematic to lock a Mutex in trap, e.g., if it's already locked by the main thread/fiber. However, that's just one case, not all, so we should not raise an exception early like that. There seems to be no valid reason to prevent *all* `Mutex#synchronize` in `trap`. After all, if the Mutex for instance is only used in `trap`, it's well-defined AFAIK. For instance a given trap handler does not seem executed concurrently: ``` $ ruby -ve 'trap(:HUP) { puts "in trap\n"+caller.join("\n")+"\n\n"; sleep 0.1 }; pid = Process.pid; Process.wait fork { 20.times { Process.kill :HUP, pid } }; sleep 1' ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' in trap -e:1:in `wait' -e:1:in `<main>' ``` And if the trap handler using the Mutex is never called while the Mutex is held by the main thread/fiber, there is also no problem. -- https://bugs.ruby-lang.org/

5 18

[ruby-core:122214] [Ruby Bug#21355] `csv/test/csv/interface/test_read.rb` at test-bundled-gems is flaky recent days
by hsbt (Hiroshi SHIBATA) 24 Jun '25

24 Jun '25

Issue #21355 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21355: `csv/test/csv/interface/test_read.rb` at test-bundled-gems is flaky recent days https://bugs.ruby-lang.org/issues/21355 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I faced test failure of `make test-bundled-gems` in GitHub Actions. It caused by `csv` testing with `Ractor`. https://github.com/ruby/ruby/actions/runs/15156308046/job/42611877817?pr=13… ``` /home/runner/work/ruby/ruby/src/gems/src/csv/test/csv/interface/test_read.rb:56: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. <OBJ_INFO:rb_ractor_confirm_belonging@../src/ractor_core.h:370> (File) /home/runner/work/ruby/ruby/src/lib/tempfile.rb:387: [BUG] rb_ractor_confirm_belonging object-ractor id:1, current-ractor id:3 ruby 3.5.0dev (2025-05-21T07:35:21Z pull/13391/merge 7c1f3e8f7e) [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122593] [Ruby Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 24 Jun '25

24 Jun '25

Issue #19057 has been updated by ioquatix (Samuel Williams). Status changed from Assigned to Closed The current behaviour as implemented is good enough and we can introduce new private fields in `internal/io.h`. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-113828 * Author: ioquatix (Samuel Williams) * Status: Closed * Assignee: ioquatix (Samuel Williams) * Target version: 3.5 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122582] [Ruby Bug#21450] Inconsistent `upcase` between `String` and `Symbol`
by Stranger6667 (Dmitry Dygalo) 24 Jun '25

24 Jun '25

Issue #21450 has been reported by Stranger6667 (Dmitry Dygalo). ---------------------------------------- Bug #21450: Inconsistent `upcase` between `String` and `Symbol` https://bugs.ruby-lang.org/issues/21450 * Author: Stranger6667 (Dmitry Dygalo) * Status: Open * ruby -v: 3.4 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Behavior for `Symbol#upcase` and `String#upcase` differs for `i` character if the `:turkic` is present I'd expect `val.upcase(:turkic)` behaves consistently for both cases: ```ruby 'i'.upcase(:turkic) # "İ" with dot :i.upcase(:turkic) # :I no dot ``` However, when a non-ASCII character is present, then the mapping on `Symbol` works the same way as with `String`: ```ruby :iФ.upcase(:turkic) # :İФ # with dot ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120315] [Ruby master Bug#20968] `Array#fetch_values` unexpected method name in stack trace
by koic (Koichi ITO) 24 Jun '25

24 Jun '25

Issue #20968 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #20968: `Array#fetch_values` unexpected method name in stack trace https://bugs.ruby-lang.org/issues/20968 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-19T04:44:56Z master 2783868de2) +PRISM [x86_64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- It seems that the current Ruby implementation is displaying unexpected method name in stack trace. ## Expected Similar to `Hash#fetch_values`, the method name `Array#fetch_values` is expected to be displayed in the stack trace. ```console $ ruby -e '{k: 42}.fetch_values(:unknown)' -e:1:in 'Hash#fetch_values': key not found: :unknown (KeyError) from -e:1:in '<main>' $ ruby -e '[1].fetch_values(42)' -e:1:in 'Array#fetch_values': index 42 outside of array bounds: -1...1 (IndexError) from -e:1:in '<main>' ``` ## Actual The stack trace displays the `Array#fetch` method, which user is not aware of, along with the `<internal.array>` stack trace. ```console $ ruby -e '[1].fetch_values(42)' <internal:array>:211:in 'Array#fetch': index 42 outside of array bounds: -1...1 (IndexError) from <internal:array>:211:in 'block in Array#fetch_values' from <internal:array>:211:in 'Array#map!' from <internal:array>:211:in 'Array#fetch_values' from -e:1:in '<main>' ``` It likely requires an approach such as implementing it in C, as suggested in https://github.com/ruby/ruby/pull/11555. -- https://bugs.ruby-lang.org/

10 21