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

[ruby-core:126409] [Ruby Misc#15224] [DOCs] Minor inconsistency in class Array #initialize_copy - https://ruby-doc.org/core-2.5.1/Array.html#method-i-initialize_copy
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #15224 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed RDoc these days shows when methods are aliased like this ---------------------------------------- Misc #15224: [DOCs] Minor inconsistency in class Array #initialize_copy - https://ruby-doc.org/core-2.5.1/Array.html#method-i-initialize_copy https://bugs.ruby-lang.org/issues/15224#change-118551 * Author: shevegen (Robert A. Heiler) * Status: Closed ---------------------------------------- Today I looked at: https://ruby-doc.org/core-2.5.1/Array.html#method-i-initialize_copy The example to this method is this: ```ruby a = [ "a", "b", "c", "d", "e" ] a.replace([ "x", "y", "z" ]) #=> ["x", "y", "z"] a #=> ["x", "y", "z"] ``` What confused me was that I was looking at the method called `initialize_copy` but the example showed `.replace()`. I then looked at `#replace` there: https://ruby-doc.org/core-2.5.1/Array.html#method-i-replace And it was virtually identical to `initialize_copy`. I assume the examples for `.replace()` are correct; and perhaps `initialize_copy` is just an alias? I am not sure, but I would like to suggest to make the documentation, in particular the example, a bit more consistent. When you click on "view source" to look at the C code, they show the very same content, so I believe that initialize_copy is merely an alias to replace; but I tried this and they are not fully equivalent: ```ruby x = [1,2,3] # => [1, 2, 3] x.initialize_copy [4,5,6] ``` ``` Traceback (most recent call last): 2: from /System/Index/bin/irb:11:in `<main>' 1: from (irb):2 NoMethodError (private method `initialize_copy' called for [1, 2, 3]:Array) ``` Yet: ```ruby x.replace [4,5,6] # => [4, 5, 6] ``` works. So I assume that `initialize_copy` is like `.replace()` but is a private method instead. Perhaps it may help to add a sentence below the documentation of `replace()`, to explain what the use case for `initialize_copy` is. Or to perhaps mention that it is an alias. At the least how it is right now is that people may read `initialize_copy`, but then see an example of `#replace`. (Perhaps an example for `initialize_copy` may help, but either way, I think the current docu-example is not ideal). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126408] [Ruby Misc#13968] [Ruby 3.x perhaps] - A (minimal?) static variant of ruby
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #13968 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Sounds like something that can be achieved by https://github.com/natalie-lang/natalie or https://github.com/matz/spinel these days ---------------------------------------- Misc #13968: [Ruby 3.x perhaps] - A (minimal?) static variant of ruby https://bugs.ruby-lang.org/issues/13968#change-118549 * Author: shevegen (Robert A. Heiler) * Status: Closed ---------------------------------------- Hello ruby core team and everyone else, I think this has been brought up before, in one way or the other, but just in case it was not, or not in this context, I would like to **propose that ruby can be compiled statically**. Matz explained how this can be done for mruby: https://github.com/mruby/mruby/issues/3707 This is not so difficult; allow me to copy/paste the major steps for mruby (I modified it a bit): Option A: (1) compile your.rb files into a C file via mrbc. Example: "mrbc -Binit_yourlib -o mrblib.c *.rb" (2) your code/application has to call "init_yourlib(mrb)" after "mrb_open()" (3) compile your code/application with the generated C file (4) link via "libmruby.a" (5) static link options may have to be specified to the linker Option B (1) Create a binary "mrbgem". See mrbgems/mruby-bin-mirb for example. And nobu added better support for statically linked extensions some years ago: https://bugs.ruby-lang.org/issues/9018 Since time is a limited resource by the ruby core team, I understand that you have to prioritize on issues that are more important, or needed more; and a statically compiled ruby may not be of highest priority. Additionally, you may want to know the use case of people, as to why they may want to have a statically compiled variant of ruby. I have a (small) use case which I think has not been explained before. I often break stuff on my linux system when I compile programs. I use many ruby helper scripts to compile programs, so I need ruby. :) When I have a ruby available then I can often batch-compile, batch-install and so on. This works very well so far for most programs out there. Not always is there a host system available with ruby though; sometimes I may be in a confined environment, such as workspaces at university and a central server cluster to which I have no access (or rather, permission to change files/directory). So I tend to compile into the user directory there (home directory). Anyway. Since I tend to break stuff, but sometimes other stuff is also broken on such environments (looking at centos ...), I made it a habit to compile some of the core utilities in a static manner into my home directory; "make" for example or "sed". Both work very well. Others are a bit misbehaving or stubborn, such as awk - I haven't managed a statically compiled variant of awk yet. Of course I also use "busybox," a statically compiled busybox that is. This allows me to recover from many problems or errors if things go awry (I can also use a live-DVD for recovery, at the least at home; or also download some binaries that I know will work on the target platform, so I have more ways to recover). Now the thing is - most of what I do with busybox, has to do with file manipulation of some sort; setting new symlinks, removing, moving, creating files or directories. Here I thought - I could use ruby rather than busybox. :) But I'd want or need a statically compiled ruby, so that it does not break depending on other programs there on the system. I hope I could explain my use case. And I agree, only very few people may ever want to have this perhaps. I looked at my self-compiled MRI ruby, via "ldd", and these are the libraries that ruby depends on: linux-vdso.so.1 libpthread.so.0 => /lib64/libpthread.so.0 libgmp.so.10 => /usr/lib/libgmp.so.10 libdl.so.2 => /lib64/libdl.so.2 libcrypt.so.1 => /lib64/libcrypt.so.1 libm.so.6 => /lib64/libm.so.6 libc.so.6 => /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 I guess this is not minimal; I could probably re-compile ruby from a sandbox, to reduce the amount of .so objects that are needed, but the above is only an example anyway. I assume that making available a ruby that can be statically compiled, is not trivial. It is probably easier for mruby, but mruby is, as far as I understand it, more aimed towards knowledgable C/C++ hackers. I am a bit too scared to try mruby when I do not really know C. I should also state that I do not need a "full" ruby by the way. I can live without the extension stuff, such as "readline" or "openssl" probably (though I'd love to have open-uri since that may help in recovery; ruby's open() functionality for remote data/websites is great). I guess the core functionality I would need is, mostly, file manipulation. So perhaps my request could be titled: "A minimal variant of ruby - that is statically linked." Now this may fit to mruby perhaps but I am a bit scared of mruby also because I do not know mruby very well; I mostly work with MRI ruby. (I did manage to compile mruby without problem and I could run ruby code too but I am not sure how much is available on mruby by default "out of the box". If I remember correctly, not every MRI ruby .rb file will work "out of the box") I also thought of filing an issue request at github-mruby but then I thought that perhaps it may also fit into MRI ruby one day, which is why I prepended with the ruby 3.x label. (I suppose that it may not fit towards 2.x anymore since 2.x will probably focus on stability, bug fixing and so forth.) I hope I could explain my use case. I am not sure if it is a good use case; I can probably just keep on using busybox ... but I would prefer to actually work within a "ruby environment" in general, simply because ruby is a LOT nicer to work with, in particular for batch-automated tasks (I always prefer to use ruby rather than shell scripts, for example). If possible it would be nice if this issue could remain open for a bit longer, if only to see if there is anyone else who may want to have some statically compiled variant of ruby. I see this sometimes in other issue requests, or similar suggestions, so perhaps if there may be a seizable amount of people who may want it, it could be put on a "long-term goal". Perhaps even past 3.x. Last but not least I would like to repeat that I do not need a full featured ruby per se, a minimal may suffice - but that minimal ruby should ideally be easy to use+install. It's a bit like a mix between "MRI ruby" and "mruby" what I want, I think. :D That way, I could both have a MRI ruby that uses .so, but also e. g a binary called "static-ruby" or "ruby-static" or something like that, that can be used a bit like a "recovery ruby". I wrote a lot so now it's time to close without much further ado - thank you for reading! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126407] [Ruby Misc#13634] NilClass is lying about respond_to?(:clone)
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #13634 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Indeed, `nil.clone` now just returns `nil` ---------------------------------------- Misc #13634: NilClass is lying about respond_to?(:clone) https://bugs.ruby-lang.org/issues/13634#change-118545 * Author: rovf (Ronald Fischer) * Status: Closed ---------------------------------------- I put this under "Misc", because I'm not sure, whether this is a bug, a feature request, or maybe a deliberate (but for me obscure) decision in language design: NilClass (and Fixnum) do not support clone. That's fine. However, nil.respons_to?(:clone) returns true. This means that we *can* ask nil to clone itself (we don't get a NoMethod error), it's just trying to do so throws an exception. I stumbled over this problem when I had an collection of objects of different types, and wanted to apply :clone to some of them. My code went approximately like this: object = collection[key] return object.respond_to?(:clone) ? object.clone : object This doesn't work, if object is nil, true, false, a Symbol or a Fixnum, because all of them claim to respond to :clone. Of course, there is a trivial workaround (I just have to rescue the exception), but I find this language design not really intuitive. I think there are two possibilites, how this can be made better: (1) If we decide, that nil is not clonable (because there can be only one nil), then respond_to?(:clone) should IMHO simply be false. (2) However, there might be even be a reason why :clone should be applicable. Note that the usual semantics of clone is to do a shallow copy (for instance, when we 'clone' a nested array). If we want to have a deep copy, the usual approach is Marshal.load(Marshal.dump(object)). Now the odd thing is that we can not "shallowly copy" nil, i.e. nil.clone is forbidden, but we can do a deep copy, i.e. Marshal.load(Marshal.dump(nil)) works. So, an alternative would be to have nil.clone simply return the identical object. Both (1) seems to me a sound solution. The solution (2) has the drawback that we can't guarantee anymore that x.clone has a different object id than x, but is probably the behaviour a programmer would intuitively expect. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126406] [Ruby Misc#13622] Documentation missing
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #13622 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed `io/wait` is now in core https://bugs.ruby-lang.org/issues/18655 `nread` is gone completely as far as I can tell. ---------------------------------------- Misc #13622: Documentation missing https://bugs.ruby-lang.org/issues/13622#change-118544 * Author: sergzhum (Sergey Zhumatiy) * Status: Closed * Assignee: stomar (Marcus Stollsteimer) ---------------------------------------- In documentation for method IO.nread important information is missing: you must do 'require "io/wait"' before using it. May be some other methods of IO in 'io/wait' are missed this IMPORTANT notice. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126405] [Ruby Misc#10983] Why blocks make Ruby methods 439% slower ?
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #10983 has been updated by Earlopain (Earlopain _). Status changed from Open to Closed Today the difference is only ~1.25x slower, not nearly as bad as it used to be. YJIT also improves both versions by at least 2x, altough it is able to optimize yield more than the explicit call. ---------------------------------------- Misc #10983: Why blocks make Ruby methods 439% slower ? https://bugs.ruby-lang.org/issues/10983#change-118543 * Author: Sega100500 (Сергей Е) * Status: Closed ---------------------------------------- https://www.omniref.com/ruby/2.2.0/symbols/Proc/yield#annotation=4087638&li… ~~~ruby require 'benchmark/ips' def block_call(&block) block.call end def just_yield yield end Benchmark.ips do |x| x.report("call") do block_call { 1 + 1 } end x.report("just yield") do just_yield { 1 + 1 } end x.compare! end ~~~ I run on Ruby 2.2.1 ~~~ Calculating ------------------------------------- call 40.754k i/100ms just yield 69.031k i/100ms ------------------------------------------------- call 814.929k (± 4.0%) i/s - 4.075M just yield 2.871M (±25.1%) i/s - 12.909M Comparison: just yield: 2871127.3 i/s call: 814929.3 i/s - 3.52x slower ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126404] [Ruby Misc#10513] instance_eval yields the receiver, but is documented to yield no arguments
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #10513 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed Current docs now specify this ---------------------------------------- Misc #10513: instance_eval yields the receiver, but is documented to yield no arguments https://bugs.ruby-lang.org/issues/10513#change-118542 * Author: ctm (Cliff Matthews) * Status: Closed * Assignee: zzak (zzak _) ---------------------------------------- instance_eval yields the receiver, but is documented as yielding no arguments. I searched the bug reports before writing this up and found bug #2476 which was closed with a message that contained "instance_eval yields the receiver in both 1.8 and 1.9. Unfortunately, a Proc object created by lambda raises ArgumentError when extra arguments are yielded in 1.9.". However such behavior is not expected when the calling sequence is: ~~~ * call-seq: * obj.instance_eval(string [, filename [, lineno]] ) -> obj * obj.instance_eval {| | block } -> obj ~~~ This discrepancy surprised me, but once I realized what was going on I simply used instance_exec instead of instance_eval. All else equal, I would prefer for instance_eval to to not yield the receiver since I can pick up the receiver as self if I want to, but such a change could breaking existing code, so probably documenting the current behavior is better. ~~~ bash-3.2$ ruby --version ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-darwin14.0] bash-3.2$ ./instance_eval This is the lambda that *does* work. arg = 32 self = 32 ./instance_eval:6:in `block in <main>': wrong number of arguments (1 for 0) (ArgumentError) from ./instance_eval:17:in `instance_eval' from ./instance_eval:17:in `<main>' ~~~ ---Files-------------------------------- instance_eval (561 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126403] [Ruby Misc#9136] Deprecated Enumerator.new(object, method) bad for BasicObject
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #9136 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed It was removed in Ruby 3.0 ---------------------------------------- Misc #9136: Deprecated Enumerator.new(object, method) bad for BasicObject https://bugs.ruby-lang.org/issues/9136#change-118541 * Author: atlas (Atlas Prime) * Status: Closed * Assignee: zzak (zzak _) ---------------------------------------- =begin Documentation it says: In the second, deprecated, form, a generated Enumerator iterates over the given object using the given method with the given arguments passed. Use of this form is discouraged. Use Kernel#enum_for or Kernel#to_enum instead. e = Enumerator.new(ObjectSpace, :each_object) #-> ObjectSpace.enum_for(:each_object) But (({#enum_for})) and (({#to_enum})) are not available to subclasses of (({BasicObject})). In fact, I was defining (({#to_enum})) for a class that is a subclass of (({BasicObject})), and now I get warning of deprecation. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117483] [Ruby master Bug#20419] [BUG] inconsistent freelist length with cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1'
by znz (Kazuhiro NISHIYAMA) 16 Aug '26

16 Aug '26

Issue #20419 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #20419: [BUG] inconsistent freelist length with cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1' https://bugs.ruby-lang.org/issues/20419 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `TestGc#test_gc_stress_at_startup` failed on my environment, so I check which configure flags affect. How to reproduce: ``` ./configure cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1' make miniruby env RUBY_DEBUG=gc_stress ./miniruby -v ``` I can't reproduce with `cppflags='-DRGENGC_CHECK_MODE'` or `cppflags='-DUSE_RUBY_DEBUG_LOG=1'`. ---Files-------------------------------- output.txt (9.44 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126401] [Ruby Bug#11808] Different behavior between Enumerable#grep and Array#grep
by wanabe (_ wanabe) 16 Aug '26

16 Aug '26

Issue #11808 has been updated by wanabe (_ wanabe). Status changed from Assigned to Closed It has been fixed at 0a82bfe5e18ac86da72c27389db6eb8da156a0b5 == https://github.com/ruby/ruby/pull/7225 ``` $ cat a.rb class Test include Enumerable def each return enum_for(:each) unless block_given? yield "Hello" yield "World" end end enum = Test.new array = ["Hello", "World"] p enum.grep(/^(.)/) {$1} p array.grep(/^(.)/) {$1} $ git checkout 0a82bfe5e18ac86da72c27389db6eb8da156a0b5~ && make -j miniruby > /dev/null 2>&1 && ./miniruby a.rb HEAD is now at 2675f2c864f Remove whitespace [nil, nil] ["H", "W"] $ git checkout 0a82bfe5e18ac86da72c27389db6eb8da156a0b5 && make -j miniruby > /dev/null 2>&1 && ./miniruby a.rb Previous HEAD position was 2675f2c864f Remove whitespace HEAD is now at 0a82bfe5e18 use correct svar (#7225) ["H", "W"] ["H", "W"] ``` This commit is included in 3.3. Since 3.2 is end-of-life, there is no need to backport it. ---------------------------------------- Bug #11808: Different behavior between Enumerable#grep and Array#grep https://bugs.ruby-lang.org/issues/11808#change-118539 * Author: BenOlive (Ben Olive) * Status: Closed * Assignee: ko1 (Koichi Sasada) * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Regex special global variables are available within the block for `Array#grep`, but are nil within the block for `Enumerable#grep`. Here is an example that explains it better: ~~~ruby class Test include Enumerable def each return enum_for(:each) unless block_given? yield "Hello" yield "World" end end enum = Test.new array = ["Hello", "World"] enum.grep(/^(.)/) {$1} # => [nil, nil] array.grep(/^(.)/) {$1} # => ["H", "W"] ~~~ Tested on 2.0.0, 2.1.5, & 2.2.2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116226] [Ruby master Bug#20189] `rb_str_resize` does not clear coderange when expanding
by tompng (tomoya ishida) 16 Aug '26

16 Aug '26

Issue #20189 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20189: `rb_str_resize` does not clear coderange when expanding https://bugs.ruby-lang.org/issues/20189 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2024-01-09T07:07:19Z master db476cc71c) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Expanding string in some encoding (utf16 utf32) can change coderange to either valid or broken, but rb_str_resize does not clear coderange. This will cause a bug in c-extension libraries that use rb_str_resize. ~~~ruby # Example for stringio s = StringIO.new("\0".encode('UTF-16LE')) s.truncate(1); s.truncate(2); s.string.valid_encoding? #=> true s.truncate(1); s.string.valid_encoding?; s.truncate(2); s.string.valid_encoding? #=> false (expect to be true) ~~~ -- https://bugs.ruby-lang.org/

5 6