June 2026 - ruby-dev - ml.ruby-lang.org

[ruby-dev:52235] [Ruby Bug#22123] Ruby::Box + `BUNDLER_SETUP` can evaluate gemspecs before main-box RubyGems initialization
by se4weed.dev＠gmail.com (Yuto NORINAGA) 20 Jun '26

20 Jun '26

Issue #22123 has been reported by se4weed.dev(a)gmail.com (Yuto NORINAGA). ---------------------------------------- Bug #22123: Ruby::Box + `BUNDLER_SETUP` can evaluate gemspecs before main-box RubyGems initialization https://bugs.ruby-lang.org/issues/22123 * Author: se4weed.dev(a)gmail.com (Yuto NORINAGA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-13T03:25:52Z master 0e3b8918b3) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- # Ruby::Box + `BUNDLER_SETUP` can evaluate gemspecs before main-box RubyGems initialization ## Subject Ruby::Box + BUNDLER_SETUP can evaluate gemspecs before main-box RubyGems initialization ## Description When Ruby is started with `RUBY_BOX=1` and Bundler's `BUNDLER_SETUP` environment variable is present, RubyGems can require `bundler/setup` while loading `gem_prelude` for the root box. That can make Bundler run code through `TOPLEVEL_BINDING` in the main box before the main box has finished loading RubyGems. In one common case, Bundler evaluates a path gem's `.gemspec`, and a normal gemspec using `Gem::Specification.new` then fails with: ```text uninitialized constant Gem::Specification ``` This happens during Ruby startup, before application code starts. ## Environment Observed with: ```text ruby 4.1.0dev (2026-06-13T03:25:52Z master 0e3b8918b3) +PRISM [arm64-darwin25] macOS 26.4.1 bundler 4.1.0.dev Ruby::Box enabled with RUBY_BOX=1 ``` ## Minimal Reproduction Create a tiny path gem: ```sh rm -rf /tmp/box-bundler-repro mkdir -p /tmp/box-bundler-repro/box_repro cd /tmp/box-bundler-repro ``` `Gemfile`: ```ruby source "https://rubygems.org" gem "box_repro", path: "./box_repro" ``` `box_repro/box_repro.gemspec`: ```ruby Gem::Specification.new do |spec| spec.name = "box_repro" spec.version = "0.1.0" spec.summary = "Ruby::Box BUNDLER_SETUP repro" spec.authors = ["repro"] spec.files = [] end ``` Choose the Ruby executable being tested: ```sh RUBY_UNDER_TEST="${RUBY_UNDER_TEST:-ruby}" ``` Generate the lockfile with the same Ruby/Bundler environment: ```sh "$RUBY_UNDER_TEST" -S bundle lock ``` Then use the same executable to find the bundled `bundler/setup` path: ```sh BUNDLER_SETUP_PATH="$("$RUBY_UNDER_TEST" -rrbconfig -e 'puts File.join(RbConfig::CONFIG["rubylibdir"], "bundler/setup")')" ``` Then run Ruby with `RUBY_BOX=1` and `BUNDLER_SETUP`: ```sh RUBY_BOX=1 \ BUNDLE_GEMFILE="$PWD/Gemfile" \ BUNDLER_SETUP="$BUNDLER_SETUP_PATH" \ "$RUBY_UNDER_TEST" -e 'puts :ok' ``` ## Actual Result ```text [!] There was an error while loading `box_repro.gemspec`: uninitialized constant Gem::Specification. Bundler cannot continue. # from /tmp/box-bundler-repro/box_repro/box_repro.gemspec:1 # ------------------------------------------- > Gem::Specification.new do |spec| # spec.name = "box_repro" # ------------------------------------------- ``` ## Expected Result ```text ok ``` ## Control Cases This succeeds without Ruby::Box: ```sh BUNDLE_GEMFILE="$PWD/Gemfile" \ BUNDLER_SETUP="$BUNDLER_SETUP_PATH" \ "$RUBY_UNDER_TEST" -e 'puts :ok' ``` This also succeeds with Ruby::Box if Bundler is loaded later through `-rbundler/setup` instead of RubyGems' `BUNDLER_SETUP` hook: ```sh RUBY_BOX=1 \ BUNDLE_GEMFILE="$PWD/Gemfile" \ "$RUBY_UNDER_TEST" -rbundler/setup -e 'puts :ok' ``` So this does not appear to be application-specific. The failure is triggered by the Bundler startup environment, especially `BUNDLER_SETUP`. ## Analysis Ruby currently loads `gem_prelude` for both the root and main boxes: ```c // builtin.c rb_load_gem_prelude((VALUE)rb_root_box()); rb_load_gem_prelude((VALUE)rb_main_box()); ``` `gem_prelude.rb` requires RubyGems: ```ruby require "rubygems" ``` At the end of RubyGems, Bundler may be loaded from `BUNDLER_SETUP`: ```ruby # lib/rubygems.rb require ENV["BUNDLER_SETUP"] if ENV["BUNDLER_SETUP"] && !defined?(Bundler) ``` This means the root box's RubyGems load can trigger `bundler/setup` before the main box's RubyGems state is ready. Bundler evaluates path gemspecs with `TOPLEVEL_BINDING`: ```ruby # lib/bundler.rb eval(contents, TOPLEVEL_BINDING.dup, path.expand_path.to_s) ``` To confirm which box evaluated the gemspec and which RubyGems constants were available, I temporarily added the following diagnostics at the beginning of the path gem's `.gemspec`, before `Gem::Specification.new`: ```ruby if defined?(Ruby::Box) warn "box=#{Ruby::Box.current.inspect}" warn "root=#{Ruby::Box.root.inspect}" warn "main=#{Ruby::Box.main.inspect}" else warn "box=nil" warn "root=nil" warn "main=nil" end warn "gem=#{!!defined?(Gem)}" warn "gem_spec=#{!!defined?(Gem::Specification)}" warn "gem_version=#{!!defined?(Gem::VERSION)}" ``` During the failure, that diagnostic output showed: ```text box=#<Ruby::Box:3,user,main> root=#<Ruby::Box:2,root> main=#<Ruby::Box:3,user,main> gem=true gem_spec=false gem_version=false ``` So the gemspec is evaluated in the main box, but before the main box's RubyGems state is ready. The diagnostics suggest that `Gem` is present, but RubyGems constants such as `Gem::Specification` and `Gem::VERSION` are not fully initialized in the main box at that point. ## Why this should not be fixed in gemspecs Normal gemspecs conventionally use: ```ruby Gem::Specification.new do |spec| # ... end ``` Adding `require "rubygems/specification"` to the gemspec does not seem like the right fix. In local testing it only moved the failure further into RubyGems initialization, with other missing pieces such as: ```text Gem::Deprecate Gem::Requirement Gem::VERSION Gem.platforms ``` The problem is that Bundler is evaluating the gemspec before RubyGems is ready in the current box. ## Possible Fix Direction The core issue seems to be that `BUNDLER_SETUP` is consumed from the root box's RubyGems prelude before the main box's RubyGems state is ready. One possible direction is to fix this in Ruby startup / Ruby::Box prelude sequencing. For example, `builtin.c` could prevent the root box `gem_prelude` from consuming `BUNDLER_SETUP`, while still allowing the main box `gem_prelude` to consume it normally. Another possible direction is to fix this on the Bundler/RubyGems side, so that the `BUNDLER_SETUP` hook does not run user/top-level code in the main box before the main box RubyGems state is ready. The invariant I think we want is: `BUNDLER_SETUP` should not be able to trigger main-box code execution before the main box's RubyGems initialization is complete. With a local prototype that temporarily hides `BUNDLER_SETUP` while loading the root box prelude in `builtin.c`, then restores it before loading the main box prelude, the minimal reproduction succeeds. ## Related PR A proposed fix with a regression test is available at: https://github.com/ruby/ruby/pull/17323 -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52234] [ANN] Dev.us.kg - A new developer forum for the Ruby community
by amine kheddache 16 Jun '26

16 Jun '26

Hello Ruby development community, I'm excited to announce the launch of **Dev.us.kg**, a new, free community forum for Ruby developers and contributors of all skill levels. 🔗 Forum: https://dev.us.kg **What you can do on the forum:** - Ask Ruby development questions and get help - Share your Ruby projects and get feedback - Discuss implementation details and best practices - Connect with other Ruby developers **Categories include:** - Ruby 💎 - Python 🐍 - PHP 🐘 - Rust 🦀 - C# (.NET) - SQL - Lua - HTML CSS JS - Share Tools The forum is completely free, has no tracking, and is open to everyone. It's a space to learn, share, and build together. Join us and help build a welcoming Ruby community: 👉 https://dev.us.kg Best regards, AmineKHD

1 0

[ruby-dev:52221] [Ruby Feature#22082] Introduce Bit Operations into String
by hasumikin (hitoshi hasumi) 12 Jun '26

12 Jun '26

Issue #22082 has been reported by hasumikin (hitoshi hasumi). ---------------------------------------- Feature #22082: Introduce Bit Operations into String https://bugs.ruby-lang.org/issues/22082 * Author: hasumikin (hitoshi hasumi) * Status: Open ---------------------------------------- ## Relevant tickets - Introduce #bit_count method on Integer --- #20163 ## Abstract Ruby's `String` is already a byte sequence, but it lacks high-level bit operations. As a result, packed binary data must be handled with manual byte arithmetic. For example, checking set-bit at offset `10` currently requires calculating the byte position and the bit's position within that byte: ```ruby data = "\xAA\xAA\xAA\xAA" # The "classic" way byte_offset = 10 / 8 byte = data.getbyte(byte_offset) bit_offset = 10 % 8 ((byte >> bit_offset) & 1) == 1 #=> false # The "concise" way using Integer#[] data.getbyte(10 / 8)[10 % 8] == 1 #=> false ``` The concise form is a single line, but it still leaks implementation details into every call site: the caller writes `10 / 8` and `10 % 8` by hand (a recurring source of off-by-one errors at byte boundaries), and the `Integer` result must be compared against `1` to be used as a boolean. With a bit-addressed API, `data.bit_at(10)` takes a bit position and returns `true`/`false` directly. The cost compounds for iteration, run-length scanning, or splicing, where each operation otherwise needs its own byte/bit arithmetic. I propose native bit-level APIs, treating the String class as a first-class bit sequence: ```ruby data = "\xAA\xAA\xAA\xAA" data.bit_at(10) #=> false ``` By providing a flat bit-addressing model that handles the underlying bit-to-byte mapping, we allow developers to focus on the logical layout of their data (e.g., an Apache Arrow bitmap or a pixel buffer), making the code more readable and less error-prone. This proposal presents a family of methods for bit-oriented use of `String`, organized into groups below. The immediate goal is agreement on the overall direction and feedback on which subset should be pursued first. Presenting the full menu matters because some design questions only become clear at that level: - bit numbering keyword (`lsb_first:`) and its consistent application across methods - naming symmetry such as `bits` / `each_bit` - behavior for out-of-range bit indices ## Implementation (Prototype) You can try an actual working implementation with `gem install string_bits`. The source code can be seen in https://github.com/hasumikin/string_bits The reason I want to include this feature in the Ruby core rather than a third-party gem is that I want this API to be common across Ruby implementations such as mruby and Spinel. ## Proposed Methods Full prototype and documentation: https://github.com/hasumikin/string_bits/blob/0.2.0/docs/ProposedMethods.md **Read** - `bit_at(bit_offset, lsb_first: true) -> true | false | nil` -- read a single bit - `bit_count -> Integer` -- count of set-bits (popcount) `bit_count(bit_offset, bit_length, lsb_first: true) -> Integer` `bit_count(bit_range, lsb_first: true) -> Integer` - `bit_run_count(bit, bit_offset, lsb_first: true) -> Integer | nil` -- length of the run of `bit` starting at bit_offset **Iterator** - `each_bit(start_offset=0, lsb_first: true) { |bool| ... } -> self` -- yield each bit as true/false `each_bit(start_offset=0, lsb_first: true) -> Enumerator` - `bits(start_offset=0, lsb_first: true) -> Array` -- Array form of `each_bit` `bits(start_offset=0, lsb_first: true) { |bool| ... } -> self` - `each_bit_run(start_offset=0, lsb_first: true) { |bool, offset, len| } -> self` -- yield `(bool, offset, run_length)` pairs `each_bit_run(start_offset=0, lsb_first: true) -> Enumerator` - `bit_runs(start_offset=0, lsb_first: true) -> Array` -- Array form of `each_bit_run` `bit_runs(start_offset=0, lsb_first: true) { |bool, len| } -> self` - `each_bit_offset(bit, start_offset=0, lsb_first: true) { |offset| ... } -> self` -- yield position of each bit equal to `bit` `each_bit_offset(bit, start_offset=0, lsb_first: true) -> Enumerator` - `bit_offsets(bit, start_offset=0, lsb_first: true) -> Array` -- Array form of `each_bit_offset` `bit_offsets(bit, start_offset=0, lsb_first: true) { |offset| ... } -> self` **Mutation** - `bit_set(bit_offset, bit_length=1, lsb_first: true) -> self` -- set one bit or a logical bit bit_range to 1 `bit_set(bit_range, lsb_first: true) -> self` - `bit_clear(bit_offset, bit_length=1, lsb_first: true) -> self` -- set one bit or a logical bit bit_range to 0 `bit_clear(bit_range, lsb_first: true) -> self` - `bit_flip(bit_offset, bit_length=1, lsb_first: true) -> self` -- toggle one bit or a logical bit bit_range `bit_flip(bit_range, lsb_first: true) -> self` - `bit_splice(bit_offset, bit_length, str, str_bit_offset=0, lsb_first: true) -> self` -- write a sub-sequence of bits in place (bit-granularity `bytesplice`) `bit_splice(bit_range, str, str_bit_offset=0, lsb_first: true) -> self` **Slice** - `bit_slice(bit_offset, bit_length, lsb_first: true) -> String | nil` -- extract a sub-sequence of bits (bit-granularity `byteslice`) `bit_slice(bit_range, lsb_first: true) -> String | nil` **Bitwise** - `bitwise_not -> String` / `bitwise_not! -> self` -- invert every bit - `bitwise_and(other) -> String` / `bitwise_and!(other) -> self` -- bitwise AND - `bitwise_or(other) -> String` / `bitwise_or!(other) -> self` -- bitwise OR - `bitwise_xor(other) -> String` / `bitwise_xor!(other) -> self` -- bitwise XOR ## Performance This is not only about convenience. In a prototype implementation (string_bits gem), bulk operations such as `bitwise_and`, `bitwise_or`, and `bit_count` are also substantially faster than Ruby-level loops over bytes (see the Benchmark link below). I do not think performance alone is the reason to add the feature, but it is a practical benefit. ## Notes Benchmarks, discussion, and prior art: - Proposed methods (with use cases): https://github.com/hasumikin/string_bits/blob/0.2.0/docs/ProposedMethods.md - Benchmark: https://github.com/hasumikin/string_bits/blob/0.2.0/docs/Benchmark.md - Discussion: https://github.com/hasumikin/string_bits/blob/0.2.0/docs/Discussion.md - Why extend `String` rather than introduce a new class? - Naming convention: symmetry with `bytes` / `each_byte` - Bit Position Numbering of the String bit API - Why `lsb_first: true` is the default? - Bit ordering across domains - Apache Arrow Compatibility - Error behavior for out-of-range bit indices - Prior art: https://github.com/hasumikin/string_bits/blob/0.2.0/docs/PriorArt.md -- https://bugs.ruby-lang.org/

6 12