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

[ruby-core:118637] [Ruby master Bug#20641] `lib/bundled_gems.rb` makes `Kernel.require` over 100x slower
by byroot (Jean Boussier) 02 Sep '24

02 Sep '24

Issue #20641 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20641: `lib/bundled_gems.rb` makes `Kernel.require` over 100x slower https://bugs.ruby-lang.org/issues/20641 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- I just discovered this while profiling Active Record's test suite, and I noticed 40% of the runtime was in `$LOAD_PATH.resolve_feature_path`, so much I thought it was a profiler bug. But it turns out it's real. Various APIs do call `require` late, for instance Psych calls `require 'date'` every single time it parses a date: https://github.com/ruby/psych/blob/be0ba74e5613c20f213403e15914d24944c2652d… I've put together a quick benchmark: ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report(RUBY_VERSION) { require "erb" } x.save! "/tmp/require.bench" x.compare! end ``` And the difference is massive: ``` Calculating ------------------------------------- 3.2.2 6.450M (± 1.2%) i/s - 32.822M in 5.089538s Comparison: 3.2.2: 6449899.4 i/s 3.3.3: 46996.8 i/s - 137.24x slower ``` And that's with a small `$LOAD_PATH`, the bigger the application, the worse it is, if I add: ```ruby 100.times do |i| $LOAD_PATH.unshift("/tmp/empty-#{i}") end ``` ``` Calculating ------------------------------------- 3.3.3 6.198k (± 6.1%) i/s - 30.968k in 5.018955s Comparison: 3.2.2: 3380939.6 i/s 3.3.3: 6198.4 i/s - 545.46x slower ``` I'm looking at a way to speed this up, but this is big enough that I believe we should backport the fix. cc @hsbt -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118983] [Ruby master Bug#20706] Can't build Ruby on macOS Sonoma and Sequoia due to: ignoring duplicate libraries, archive member '/' not a mach-o file in libruby.3.3-static.a
by wkoszek (Adam Koszek) 30 Aug '24

30 Aug '24

Issue #20706 has been reported by wkoszek (Adam Koszek). ---------------------------------------- Bug #20706: Can't build Ruby on macOS Sonoma and Sequoia due to: ignoring duplicate libraries, archive member '/' not a mach-o file in libruby.3.3-static.a https://bugs.ruby-lang.org/issues/20706 * Author: wkoszek (Adam Koszek) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, I had the same problems with macOS Sonoma and (after an upgrade) Sequoia -- something about my macOS makes it impossible to build Ruby. Upon an upgrade to Sequoia, I did Xcode upgrade, and then CommandLine tools download. Then I did "sudo xcode-select --reset" I'm trying ruby-3.3.4 and ruby-3.2.5 -- both have the same result from below. Steps: wget https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.4.tar.gz tar xzf ruby-3.3.4.tar.gz cd ruby-3.3.4 script ./configure make -j Last lines: linking shared-object -test-/scan_args.bundle linking shared-object -test-/string.bundle linking shared-object objspace.bundle linking shared-object digest/bubblebabble.bundle linking shared-object stringio.bundle linking transcoder big5.bundle linking shared-object json/ext/generator.bundle making ends make[1]: Nothing to be done for `encs'. linking shared-object nkf.bundle linking shared-object ripper.bundle file2lastrev.rb: does not seem to be under a vcs: . revision.h unchanged config.status: creating ruby-runner.h ln -sf ../../rbconfig.rb .ext/arm64-darwin24/rbconfig.rb linking ruby ld: warning: ignoring duplicate libraries: '-ldl', '-lobjc', '-lpthread' ld: archive member '/' not a mach-o file in '/Users/wk/tmp/rubyc/ruby-3.3.4/libruby.3.3-static.a' clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [ruby] Error 1 make[1]: *** [ruby] Error 2 make: *** [build-ext] Error 2 [07:35:03][wk@wkoszek_mba:~/tmp/rubyc/ruby-3.3.4]$ exit exit Script done, output file is typescript file /Users/wk/tmp/rubyc/ruby-3.3.4/libruby.3.3-static.a /Users/wk/tmp/rubyc/ruby-3.3.4/libruby.3.3-static.a: current ar archive I'm attaching the transcript. This ticket has this warning too: https://bugs.ruby-lang.org/issues/20283 But looks like it's a warning. For me it's somehow an error. ---Files-------------------------------- typescript (54.7 KB) -- https://bugs.ruby-lang.org/

4 6

[ruby-core:118964] [Ruby master Bug#20700] `warn_cr_in_shebang()` doesn't fire if there's no `\n`
by AMomchilov (Alexander Momchilov) 27 Aug '24

27 Aug '24

Issue #20700 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Bug #20700: `warn_cr_in_shebang()` doesn't fire if there's no `\n` https://bugs.ruby-lang.org/issues/20700 * Author: AMomchilov (Alexander Momchilov) * 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 ---------------------------------------- The `warn_cr_in_shebang()` function looks for `\r\n` together, but the `\r` should emit a warning, regardless if there's also a `\n` or not. ```ruby #!/usr/bin/ruby require "tempfile" require "open3" def run_rb(ruby_src) puts "===== Output of #{ruby_src.inspect}:" Tempfile.create("script.rb") do |f| f.print(ruby_src) f.close stdout_and_stderr_str, status = Open3.capture2e("/opt/rubies/3.3.4/bin/ruby", f.path) raise unless status.success? puts stdout_and_stderr_str end end run_rb("#!ruby") # ✅ no warning run_rb("#!ruby\r") # ❌ no warning! run_rb("#!ruby\r\n") # ✅ warns run_rb("#!ruby -Eutf-8\r\n123") # ✅ warns ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118963] [Ruby master Feature#11273] [PATCH] Make it possible to `load` from a FIFO file
by alanwu (Alan Wu) 26 Aug '24

26 Aug '24

Issue #11273 has been updated by alanwu (Alan Wu). Status changed from Open to Closed Closing as we carry a test since commit:bc8687acd62584bf2ba9a951289f3f25a4de7229 that exercises this functionality. ---------------------------------------- Feature #11273: [PATCH] Make it possible to `load` from a FIFO file https://bugs.ruby-lang.org/issues/11273#change-109535 * Author: cesario (Franck Verrot) * Status: Closed ---------------------------------------- Revision #50887 (https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/50887) avoided `load` from blocking the VM when accessing a FIFO file, but loading from a FIFO doesn't work (raises `LoadError`). This patch makes it possible. PS: I wasn't sure it was a bug or a feature so I've set it to bug. Of course, feel free to fix this. ---Files-------------------------------- 0001-file.c-load-now-supports-reading-from-a-FIFO-file.patch (3.18 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118954] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 25 Aug '24

25 Aug '24

Issue #18368 has been updated by zverok (Victor Shepelev). Here we go: https://github.com/ruby/ruby/pull/11454 In the absence of further discussion, I went with option (3): String ranges support both “old” and “new” behavior. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-109527 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118953] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by nobu (Nobuyoshi Nakada) 25 Aug '24

25 Aug '24

Issue #6648 has been updated by nobu (Nobuyoshi Nakada). `-C` option arguments are cumulative and can be relative paths. I don't think `ruby -C subdir -e 'exec(*Process.argv)'` would work as expected. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109526 * 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:118952] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by nobu (Nobuyoshi Nakada) 25 Aug '24

25 Aug '24

Issue #19057 has been updated by nobu (Nobuyoshi Nakada). OK, unless `FMODE_EXTERNAL` is given `descriptor` will be closed when a new object could not be allocated. I thought about pty extension, and it seems to work at least for pty. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-109525 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- 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:118951] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by nobu (Nobuyoshi Nakada) 25 Aug '24

25 Aug '24

Issue #19057 has been updated by nobu (Nobuyoshi Nakada). I found `rb_io_open_descriptor` is a bad design, it can results in FD-leaks, because a file descriptor isn't a Ruby object with finalizer. It should be "allocate then open & set" instead of "open then allocate & initialize". ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-109524 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- 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:118933] [Ruby master Bug#20694] "try to mark T_NONE object" error for very large arrays
by ngan (Ngan Pham) 25 Aug '24

25 Aug '24

Issue #20694 has been reported by ngan (Ngan Pham). ---------------------------------------- Bug #20694: "try to mark T_NONE object" error for very large arrays https://bugs.ruby-lang.org/issues/20694 * Author: ngan (Ngan Pham) * Status: Open * ruby -v: 3.3.4 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In CI, we've been occasionally seeing `[BUG] try to mark T_NONE object`. I don't have any way to reproduce it but I'm going to put some information here in case anyone has any ideas. One thing I've noticed is that it happens for very large arrays: ``` <OBJ_INFO:gc_mark_ptr@gc.c:7072> 0x00007f587d04fc90 [0 M ] T_NONE /usr/local/bundle/ruby/3.3.0/gems/simpleidn-0.2.2/lib/simpleidn/uts46mapping.rb: [BUG] try to mark T_NONE object ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] ``` https://github.com/mmriis/simpleidn/blob/master/lib/simpleidn/uts46mapping.… and... ``` <OBJ_INFO:gc_mark_ptr@gc.c:7072> 0x00007f7ec426fdc8 [0 M ] T_NONE /usr/local/bundle/ruby/3.3.0/gems/domain_name-0.6.20240107/lib/domain_name/etld_data.rb: [BUG] try to mark T_NONE object ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] ``` https://github.com/knu/ruby-domain_name/blob/master/lib/domain_name/etld_da… ---Files-------------------------------- backtrace.txt (9.12 KB) -- https://bugs.ruby-lang.org/

3 6

[ruby-core:118535] [Ruby master Feature#20625] Object#chain_of
by matheusrich (Matheus Richard) 23 Aug '24

23 Aug '24

Issue #20625 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #20625: Object#chain_of https://bugs.ruby-lang.org/issues/20625 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- ## Motivation It's often common to traverse a tree/list-like structure in order to get a chain of elements. This proposal is to add a method to `Object` that allows collecting a chain of elements by applying a block to each element. It doesn't require the root element to be an instance of a specific class or respond to a specific protocol. I think this method could be useful in many cases, since hierarchies like this are common in codebases (e.g. file systems, organizations structures, commit histories, breadcrumbs in web apps, configuration hierarchies, etc.). Here are some examples extracted from real codebases (simplified for the sake of the example/privacy): ```rb # Given a file system structure, get the breadcrumbs of a file or directory def breadcrumbs(root) crumbs = [] current = root while current crumbs << current current = current.parent_dir end crumbs end # Given an employee, get the hierarchy of managers def hierarchy(employee) hierarchy = [] current = employee while current hierarchy << current current = current.manager end hierarchy end ``` ## Implementation The implementation in Ruby could look like this: ```rb class Object def chain_of(&block) chain = [] current = self while current chain << current current = block.call(current) end chain end end ``` Here's an example use: ```rb class ListNode attr_accessor :value, :parent def initialize(value, parent = nil) @value = value @parent = parent end def ancestors chain_of(&:parent).shift end end root = ListNode.new("root") child1 = ListNode.new("child1", root) child2 = ListNode.new("child2", child1) puts child2.ancestors.map(&:value) # => ["child1", "root"] ``` The examples from the motivation section could be rewritten as: ```rb breadcrumbs = root.chain_of(&:parent_directory) hierarchy = employee.chain_of(&:manager) ``` ## Considerations - While I'm including the object by default in the chain, it could be more intuitive to exclude it. In any case, it's easy to remove or add it with `shift`/`unshift`. - On a different note, the method could be named differently (I do like `chain_of`, though). Some alternatives I've considered are `map_chain`, `traverse`, and `trace_path`. - The method assumes that the traversal will finish at some point. If the user has a cyclic structure, it will loop indefinitely. We could stop looping if we find the same element twice. I don't think it's worth the extra complexity. - I'm not sure `Object` is the best place for this method. While it's very general, I think it gives power to the user to decide how to traverse a chain like this without having to rely on a specific class. Maybe a mixin (`Traversable`/`Chainable`) would be more appropriate? Could this fit in `Enumerable`, somehow? Of course, I'm open to suggestions and feedback. Thanks for reading! -- https://bugs.ruby-lang.org/

3 4