February 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:124746] [ruby-core:124711][Ruby Feature#/21869] Add receive_all Method to Ractor API for Message Batching
by milovidovmikhail＠gmail.com 09 Feb '26

09 Feb '26

**Summary** The Ractor API provides an excellent mechanism for inter‑thread communication, but it currently lacks a built‑in message batching technique. I propose adding a receive_all method to enable batch processing of messages, which can significantly improve performance in high‑load scenarios. **Motivation** In distributed queued systems, processing messages one‑by‑one (as with the current receive method) can introduce unnecessary overhead. Batch processing allows: Reduced context‑switching overhead. More efficient I/O operations (e.g., fewer file writes). Better throughput in high‑concurrency environments. **Proposed Solution** Add a receive_all method to the Ractor API that: Returns all available messages in the Ractor’s mailbox at once (as an array). **Demonstration Code** Below is a benchmark comparing individual receive vs. batch receive_all: ``` ruby require 'benchmark' class RactorsTest def initialize(count) @count = count @ractor1 = Ractor.new(count, 'output1.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? message = receive file.write("Ractor 1 received message: #{message}\n") file.flush count -= 1 end end end @ractor2 = Ractor.new(count, 'output2.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? messages = receive_all messages.each do |message| file.write("Ractor 2 received message: #{message}\n") end count -= messages.length file.flush end end end end def run1 @count.times do |i| @ractor1.send("Message #{i + 1}") end @ractor1.join end def run2 @count.times do |i| @ractor2.send("Message #{i + 1}") end @ractor2.join end end records = 1_000_000 test = RactorsTest.new(records) p [:once, Benchmark.realtime { test.run1 }.round(2)] p [:all, Benchmark.realtime { test.run2 }.round(2)] ``` **Benchmark Results** On my system, receive_all shows ~4x improvement over individual receive: **Key Observations:** Ractor1 (using receive): Processes each message individually, resulting in frequent I/O calls. Ractor2 (using receive_all): Processes all queued messages at once, minimizing I/O overhead **PR on Github** https://github.com/ruby/ruby/pull/16105

1 0

[ruby-core:124579] [Ruby Bug#21842] Encoding of rb_interned_str
by herwin (Herwin W) 09 Feb '26

09 Feb '26

Issue #21842 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21842: Encoding of rb_interned_str https://bugs.ruby-lang.org/issues/21842 * Author: herwin (Herwin W) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This is one of the API methods to get an fstring. The documentation in the source says the following: ```c /** * Identical to rb_str_new(), except it returns an infamous "f"string. What is * a fstring? Well it is a special subkind of strings that is immutable, * deduped globally, and managed by our GC. It is much like a Symbol (in fact * Symbols are dynamic these days and are backended using fstrings). This * concept has been silently introduced at some point in 2.x era. Since then * it gained wider acceptance in the core. Starting from 3.x extension * libraries can also generate ones. * * @param[in] ptr A memory region of `len` bytes length. * @param[in] len Length of `ptr`, in bytes, not including the * terminating NUL character. * @exception rb_eArgError `len` is negative. * @return A found or created instance of ::rb_cString, of `len` bytes * length, of "binary" encoding, whose contents are identical to * that of `ptr`. * @pre At least `len` bytes of continuous memory region shall be * accessible via `ptr`. */ VALUE rb_interned_str(const char *ptr, long len); ``` I tried to create some specs for them (https://github.com/ruby/spec/pull/1327) but instead of binary encoding, the string is actually encoded as US-ASCII. This may result is some weird behaviour if the input contains bytes that are not valid in US-ASCII (the following is more an observation of the current behaviour) ```ruby it "support binary strings that are invalid in ASCII encoding" do str = "foo\x81bar\x82baz".b result = @s.rb_interned_str(str, str.bytesize) result.encoding.should == Encoding::US_ASCII result.should == str.dup.force_encoding(Encoding::US_ASCII) result.should_not.valid_encoding? end ``` So it seems to me like either the implementation of the documentation is incorrect. (`rb_interned_str_cstr` has the same behaviour, it's pretty much the same thing except using a null terminator instead of an explicit length argument). -- https://bugs.ruby-lang.org/

5 7

[ruby-core:123966] [Ruby Bug#21723] `binding.irb` raises a LoadError under `bundle exec`
by osyoyu (Daisuke Aritomo) 09 Feb '26

09 Feb '26

Issue #21723 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21723: `binding.irb` raises a LoadError under `bundle exec` https://bugs.ruby-lang.org/issues/21723 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In Ruby 4.0, `binding.irb` raises a LoadError when some unknown condition is met. ```ruby # main.rb binding.irb ``` ``` main.rb:1: warning: irb used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0. You can add irb to your Gemfile or gemspec to fix this error. Failed to activate irb, please install it with 'gem install irb' /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError) Did you mean? erb from /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'block (2 levels) in Kernel#replace_require' from main.rb:1:in 'Binding#irb' from main.rb:1:in '<main>' /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError) Did you mean? erb from /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'block (2 levels) in Kernel#replace_require' from main.rb:1:in 'Binding#irb' from main.rb:1:in '<main>' ``` While irb has been changed to a bundle gem in #20309, it is agreed that `binding.irb` shall work under `bundle exec` without adding `irb` in Gemfile. Thus, I've considered this behavior as an bug and created a ticket here. One condition I have discovered is when the Gemfile contains a `gem` reference with a `path:` option. I have created a repro repository in https://github.com/osyoyu/irbfail for that case. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:124738] [Ruby Feature#6478] BasicObject#__class__
by Eregon (Benoit Daloze) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by Eregon (Benoit Daloze). byroot (Jean Boussier) wrote in #note-18: > I mean, it's consistent with `__send__` and `__id__`, aliases of `send` and `object_id` meant to be used by generic code that want to ensure it can deal with any object, even ones that would redefine common methods. Yeah, I dislike those too 😅 Specifically I think it looks very unidiomatic (and ugly) when used in Ruby code. I think at least it's clear it's not good to go towards having every `Kernel` method as a `__x__` variant on BasicObject. Also even `__send__` and `__id__` can be redefined, so the `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` approach is in fact safer. So my take on this is `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` is good enough, and also most BasicObject subclasses should implement Kernel-like methods. Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116339 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124735] [Ruby Feature#6478] BasicObject#__class__
by byroot (Jean Boussier) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by byroot (Jean Boussier). Not that I'm for nor against this feature request, but: > In terms of naming I think __class__ looks like a hack that Python would use and not Ruby-like. I mean, it's consistent with `__send__` and `__id__`, aliases of `send` and `object_id` meant to be used by generic code that want to ensure it can deal with any object, even ones that would redefine common methods. > Why not add BasicObject#class? I suspect that would break various proxy classes in gems. Might not be a huge deal. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116336 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124734] [Ruby Feature#6478] BasicObject#__class__
by Eregon (Benoit Daloze) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by Eregon (Benoit Daloze). In terms of naming I think `__class__` looks like a hack that Python would use and not Ruby-like. Why not add `BasicObject#class`? I think `Kernel.instance_method(:class).bind_call(o)` is fine for most cases. FWIW performance-wise on TruffleRuby there isn't much difference when storing the `UnboundMethod` in a constant: ``` truffleruby 33.0.1 (2026-01-20), like ruby 3.3.7, Oracle GraalVM Native [x86_64-linux] Calculating ------------------------------------- instance_method.bind_call 33.492M (± 3.0%) i/s (29.86 ns/i) - 169.962M in 5.079892s bind_call 631.582B (± 1.1%) i/s (0.00 ns/i) - 3.157T in 4.998908s __class__ 750.398B (± 1.3%) i/s (0.00 ns/i) - 3.751T in 4.999106s ``` BasicObject are very difficult to use because they miss so many "standard" methods from Kernel. As such I see them as mostly meant to proxy all the Kernel methods to maybe some delegate object or so, and the responsability of the BasicObject subclass to implement Kernel-like methods to make the object usable in normal Ruby code. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116335 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 09 Feb '26

09 Feb '26

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

3 8

[ruby-core:124723] [Ruby Feature#6478] BasicObject#__class__
by jneen (Jeanine Adkisson) 08 Feb '26

08 Feb '26

Issue #6478 has been updated by jneen (Jeanine Adkisson). I wonder if exposing a static `Object.class_of(thing)` would be appropriate? There's also the singleton_class to consider as well. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116321 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124721] [Ruby Feature#6478] BasicObject#__class__
by trinistr (Alexander Bulancov) 08 Feb '26

08 Feb '26

Issue #6478 has been updated by trinistr (Alexander Bulancov). I would like to revive discussion for this feature request as I feel that `BasicObject#__class_` is still needed. Note: obviously, it is possible to transplant methods with `define_method` (that is very nice!), but one doesn't always control the class of the object. **What for?** - Inspection of objects. Currently, it's not possible to print anything reasonable for a BasicObject-derived object. - Introspection. Everything in Ruby is an object with a class, and not being able to get that class is weird and painful. It's possible to use `Kernel.instance_method(:class).bind_call(o)`, but why is this even required? It's very un-ergonomical. **Why?** 1. Printing of classes is especially useful for error messages, and Ruby's internals can just do that (though maybe this is also just `Kernel#class`?): ```ruby class A < BasicObject; end 1.clone(freeze: A.new) # in 'Numeric#clone': unexpected value for freeze: A (ArgumentError) ``` Creating such messages in regular code is unnecessarily hard when any object can happen, it requires conditionals and/or using the `bind_call` trick. 2. Getting a class of an object is probably mostly useful for interactive use (which is still important), but the long incantation to do it is inconvenient and hard to remember as something that can be done. 3. `bind_call` is an order of magnitude slower than just using the method: ```ruby class B < BasicObject; define_method(:__class__, ::Kernel.instance_method(:class)); end b = B.new class_method = Kernel.instance_method(:class) Benchmark.ips { |x| x.report("instance_method.bind_call") { Kernel.instance_method(:class).bind_call(b) } x.report("bind_call") { class_method.bind_call(b) } x.report("__class__") { b.__class__ } } ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [x86_64-linux] Warming up -------------------------------------- instance_method.bind_call 107.359k i/100ms bind_call 119.100k i/100ms __class__ 2.187M i/100ms Calculating ------------------------------------- instance_method.bind_call 1.022M (± 3.3%) i/s (978.28 ns/i) - 5.153M in 5.046952s bind_call 1.147M (± 4.6%) i/s (871.47 ns/i) - 5.836M in 5.096893s __class__ 22.494M (± 3.6%) i/s (44.46 ns/i) - 113.699M in 5.062084s ``` **Compatibility** I believe virtually no code would be negatively impacted by addition of `BasicObject#__class__`. Code would need to both check for the presence of `#__class__` and do something completely divorced from `#class` to be affected. On the other hand, it would allow for a method that doesn't conflict with a keyword. Searching for uses of `__class__` on GitHub (https://github.com/search?q=__class__+language%3Aruby&ref=searchresults&typ…) seems to show just a few current uses: - defining `__class__` to refer to the class of a proxy object itself - `alias __class__ class`, seemingly to call directly instead of `self.class` - Rubinius has it (https://github.com/rubinius/rubinius/blob/84368419a49767ef9549a5778812e5f54…) - Pythonification There are some results that define `__class__` if it doesn't exist already, but those should not be impacted, as the meaning would be the same. **In short** Adding `BasicObject#__class__` would - make it possible to always get the class for any object in the same way; - be faster than current solution; - have no negative impact on existing codebase. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116318 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118784] [Ruby master Feature#20664] Add `before` and `until` options to Enumerator.produce
by knu (Akinori MUSHA) 08 Feb '26

08 Feb '26

Issue #20664 has been reported by knu (Akinori MUSHA). ---------------------------------------- Feature #20664: Add `before` and `until` options to Enumerator.produce https://bugs.ruby-lang.org/issues/20664 * Author: knu (Akinori MUSHA) * Status: Open ---------------------------------------- Enumerator.produce provides a nice way to generate an infinite sequence but is a bit awkward to define how to end a sequence. It lacks a simple and easy way to produce typical finite sequences in an intuitive syntax. This proposal attempts to solve the problem by adding these two options to the method: - `before`: when provided, it is used as a predicate to determine if an iteration should end before a generated value gets yielded. - `until`: when provided, it is used as a predicate to determine if an iteration should end until after a generated value gets yielded. Any value that responds to `to_proc` and returns a `Proc` object is accepted in these options. A typical use case for the `before` option is traversing a tree structure to iterate over the ancestors or following/preceding siblings of a node. The `until` option can be used when there is a clear definition of the "last" value to yield. ```ruby enum = Enumerator.produce(File, before: :nil?, &:superclass) enum.to_a #=> [File, IO, Object, BasicObject] enum = Enumerator.produce(3, until: :zero?, &:pred) enum_to_a #=> [3, 2, 1, 0] ``` ---Files-------------------------------- 0001-Add-before-and-until-options-to-Enumerator.produce.patch (10.7 KB) -- https://bugs.ruby-lang.org/

6 12