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

[ruby-core:126160] [Ruby Feature#22212] Add Thread::Backtrace::Location#source_range
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22212 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #22212: Add Thread::Backtrace::Location#source_range https://bugs.ruby-lang.org/issues/22212 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ## Motivation The main motivation is to be able to implement `Prism.find(Thread::Backtrace::Location)` precisely and cleanly on any Ruby implementation, in a way which does not depend on implementation details like `node_id`. For that we need the start/end line/column and the `absolute_path`, which is exactly what `Ruby::SourceRange` provides. In https://bugs.ruby-lang.org/issues/21998 we added `source_range` for `{Method,UnboundMethod,Proc}`. However we also need `source_range` for `Thread::Backtrace::Location` as this is used in `error_highlight`, `power_assert`, etc. Those tools currently use `RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location(Thread::Backtrace::Location)`, however: * that's a CRuby-only experimental API * it exposes CRuby internals (`node_id`) * it adds a lot of complexity for all usages because they need to handle both `Prism::Node` and `RubyVM::AbstractSyntaxTree::Node`. We solve all of this by adding a new portable API which exposes universal concepts like line and column, which are stable to find AST nodes. ## Implementation How can we get the start/end line/column when we only keep the start line in CRuby? By re-parsing, and specifically by re-parsing with *exactly* the same parser that the interpreter used to compile to bytecode. That way there is no issue of using different Prism versions, it's the Prism C library built in CRuby, or `parse.y` in `--parser=parse.y` mode. Either way, we reparse to extract the start/end line/column. We make the returned start/end line/column match for both `Prism` and `parse.y`, in practice the only difference is for calls with blocks, where we adapt the location from parse.y to match Prism. One can then easily use Prism to get a node matching that `Ruby::SourceRange` and use the resulting `Prism::Node` as they wish. This also means all versions of Prism can be used, and for example if some dependency requires some specific version of Prism it works fine and is not a problem. As a result, the user of this API can choose the Prism version they want and always get a `Prism::Node` (and not having to handle `RubyVM::AbstractSyntaxTree::Node` too, or a duplicate `Ruby::Node` API as mentioned in #21795). PR: https://github.com/ruby/ruby/pull/18043 -- https://bugs.ruby-lang.org/

5 8

[ruby-core:126165] [Ruby Feature#22213] Allow no-argument and chained calls of Proc#refined
by shugo (Shugo Maeda) 06 Aug '26

06 Aug '26

Issue #22213 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22213: Allow no-argument and chained calls of Proc#refined https://bugs.ruby-lang.org/issues/22213 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract Currently, `Proc#refined` rejects no-argument and chained calls, because I wasn't sure what the desired behavior should be. How about returning the receiver for no-argument calls: ```ruby original = -> {} refined = original.refined p refined.equal?(original) #=> true ``` and activating all the given modules for chained calls? ```ruby module M refine String do def shout = upcase + "!" end end module M2 refine Integer do def doubled = self * 2 end end original = ->(s, i) { [s.shout, i.doubled] } refined = original.refined(M).refined(M2) # the same result as original.refined(M, M2) refined.call("hi", 3) #=> ["HI!", 6] ``` ## Motivation This change is necessary to make `Proc#refined` composable. A no-argument call of `Proc#refined` is a no-op, but it's useful when the arguments are calculated at runtime: ```ruby def foo(prc, *modules) ... refined = prc.refined(*modules) ... end ``` If an empty module list were rejected, a guard like `unless modules.empty?` would be needed. A chained call of `Proc#refined` is useful to extend existing DSLs: ```ruby require "packrat_parser" require "mathn" class MathParser < PackratParser def define(sym, &block) # PackratParser#define also calls Proc#refined super(sym, &block.refined(Math::N)) end end parser = MathParser.new { ... define :multitive do [:primary, "*", :multitive].map { |x, _, y| x * y } | [:primary, "/", :multitive].map { |x, _, y| x / y } | :primary end ... } parser.parse("1 / 2") #=> (1/2) ``` ## Formal semantics With this proposal, `Proc#refined` can be formalized as a monoid action on Procs created from a block, where the acting monoid is the sequences of modules under concatenation, with the empty sequence as its unit. Writing ≃ for behavioral equivalence, the action satisfies the unit and associativity laws: ``` prc.refined ≃ prc # unit law prc.refined(*ms).refined(*ns) ≃ prc.refined(*ms, *ns) # associativity law ``` Note that the unit law holds for any Proc, since `refined` with no modules returns the receiver itself. I've written a formalization in the Rocq Prover: https://github.com/shugo/ruby-refinements-semantics It abstracts away the details irrelevant to refinements. ## Design decisions ### The receiver or a copy for no-argument calls Returning a copy was also considered, but I chose to return the receiver, following precedents such as `Data#with` and `Enumerator::Lazy#lazy`. Mutable containers tend to return a copy even for a no-op, but `Proc#refined` is closer to the former group. ### Extend or replace for chained calls If a chained call replaced the receiver's refinements instead of extending them, `prc.refined(M).refined(M2)` would activate only `M2`. That breaks the associativity law above, and makes chaining useless for the DSL case in Motivation. Extending also matches nested `using`, where refinements activated later take precedence. ## Implementation Pull request: https://github.com/ruby/ruby/pull/18052 `Proc#refined` on an already refined Proc is not memoized: the cache would be keyed on short-lived copies, and entries are retained for the VM's lifetime, so it would grow without bound. A performance warning is emitted under `Warning[:performance] = true`, and passing all the modules in a single call is more efficient. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125775] [Ruby Feature#22118] Introduce Basic Bit Operations into String
by hasumikin (hitoshi hasumi) 06 Aug '26

06 Aug '26

Issue #22118 has been reported by hasumikin (hitoshi hasumi). ---------------------------------------- Feature #22118: Introduce Basic Bit Operations into String https://bugs.ruby-lang.org/issues/22118 * Author: hasumikin (hitoshi hasumi) * Status: Open ---------------------------------------- This PR implements a subset of the specification proposed in the parent feature ticket #22082 PR URL: [placeholder to be updated] ## Methods implemented with the same specification as the parent ticket * `String#bit_at(offset, lsb_first: true) -> true | false | nil` * `String#bitwise_not -> String` * `String#bitwise_not! -> self` * `String#bitwise_and(other) -> String` * `String#bitwise_and!(other) -> self` * `String#bitwise_or(other) -> String` * `String#bitwise_or!(other) -> self` * `String#bitwise_xor(other) -> String` * `String#bitwise_xor!(other) -> self` ## Methods with range-oriented forms omitted for now The parent ticket also included range-oriented forms for some methods. In this PR, those range arguments are intentionally omitted, and the methods are limited to simpler forms. Range support can be considered as a future extension. * `String#bit_count -> Integer` * `String#bit_set(offset, lsb_first: true) -> self` * `String#bit_clear(offset, lsb_first: true) -> self` * `String#bit_flip(offset, lsb_first: true) -> self` In particular, `String#bit_count` currently takes no arguments. It does not accept a range, offset/length pair, or `lsb_first:` keyword. --- ## Remaining design questions even after narrowing the scope The overall direction of adding these methods has already been approved by Matz. The remaining questions are mostly about naming and API details. ### 1. Why the `bitwise_*` prefix is used In the parent ticket, all other methods are related to bit positions: they either take bit-position arguments, yield bit positions, or operate on a specified bit range. In contrast, the `bitwise_*` methods are whole-data operations. They apply to the entire string as a fixed-size bitmap and do not expose bit positions or bit ordering. The `bitwise_*` prefix is intended to make this distinction explicit. ### 2. Bit numbering #### `lsb_first: true` (default) Within each byte, `offset = 0` is the LSB. Numbering proceeds upward through byte[0] and then continues at the LSB of byte[1]: ```text byte[0] byte[1] offset: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ LSB LSB offset = byte_index * 8 + bit_in_byte ``` #### `lsb_first: false` for MSB-first Byte order is preserved (`byte[0]` is still first), but within each byte numbering starts at the MSB: ```text byte[0] byte[1] offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ MSB MSB offset = byte_index * 8 + (7 - bit_in_byte) ``` * Whether `lsb_first:` is needed at all, or whether an equivalent mechanism should exist under another name? * If such a mechanism is needed, whether `lsb_first:` is the right keyword name? * If `lsb_first:` is acceptable, should its default be `true`? My point is that `lsb_first:` is needed because both bit numbering conventions are used in real byte-buffer formats. LSB-first is the more common convention for general in-memory bitmap use, including formats and APIs such as Apache Arrow validity bitmaps, ext4 block bitmaps, Roaring bitmaps, Linux/BSD bitmap APIs, and hardware register descriptions. MSB-first is also needed for domains such as RFC-style network protocol diagrams, PNG low-bit-depth scanlines, BitTorrent bitfields, and some compressed bit streams. The keyword only controls bit numbering within each byte. Byte order itself is unchanged. ### 3. Out-of-range behavior `String#bit_at` returns `nil` when the bit offset is out of range. On the other hand, mutating methods such as `String#bit_set`, `String#bit_clear`, and `String#bit_flip` raise `IndexError` for an out-of-range bit offset. This follows the same general distinction as read-like access versus write-like access: reading a missing position can return `nil`, but mutating a missing position should not silently do nothing. ### 4. Negative bit offsets Negative bit offsets are rejected with `IndexError`. Although Ruby often uses negative indices to count from the end, combining negative bit offsets with the `lsb_first: true/false` mechanism would make the numbering rule harder to explain and reason about. The API keeps bit offsets as non-negative flat positions from the beginning of the string. ### 5. Length mismatch for binary bitwise operations `String#bitwise_and`, `String#bitwise_or`, and `String#bitwise_xor` require both operands to have the same byte size. If the byte sizes differ, they raise `ArgumentError`. This avoids implicit truncation or zero-padding. Since these methods operate on strings as fixed-size bitmaps, requiring equal sizes makes the operation explicit and predictable. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure
by vo.x (Vit Ondruch) 03 Aug '26

03 Aug '26

Issue #19921 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19921: TestYJIT#test_bug_19316 test failure https://bugs.ruby-lang.org/issues/19921 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master 52709a4862) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing with 52709a4862 on Fedora Rawhide, I observe following failure: ~~~ 94) Failure: TestYJIT#test_bug_19316 [/builddir/build/BUILD/ruby-3.3.0-52709a4862/test/ruby/test_yjit.rb:1126]: Expected no exits, but got {:opt_and=>1} ~~~ -- https://bugs.ruby-lang.org/

6 21

[ruby-core:123776] [Ruby Bug#21682] The result of IO#pos is inconsistent after using IO#ungetc.
by YO4 (Yoshinao Muramatsu) 31 Jul '26

31 Jul '26

Issue #21682 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21682: The result of IO#pos is inconsistent after using IO#ungetc. https://bugs.ruby-lang.org/issues/21682 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In this issue, I propose modifying `IO#ungetc` to never change the file position and explain the reasons for this change. The file location after using IO#ungetc may or may not change. This behavior is not documented. Since there are cases that the file position cannot be modified, I propose to unify the behavior so that the file position is not changed. ## Motivation Ensure file position behavior is independent of I/O setup. Avoid excessive exposure of implementation details. ## Current Details The file position after using IO#ungetc depends on the following conditions: When encoding conversion is not used: It changes. When encoding conversion is used: It does not change. This corresponds internally to whether the ungetc character is stored in the IO object's rbuf or cbuf. When using cbuf, the byte count of a character in cbuf may differ from its byte count in rbuf, making conversion from cbuf byte count to rbuf byte count potentially complex. Furthermore, even if one reverse-converts a character in cbuf to calculate its byte count in rbuf, the practical significance of this calculation is questionable. Therefore, it appears that adjusting the buffered byte count from the actual file position to calculate the file position in Ruby when a character exists in cbuf is not implemented. When stored in rbuf, its byte count can be used to calculate the file position, so the file position moves due to ungetc. ## Problems It seems relatively unknown that the side effects of ungetc can change depending on I/O setup. The Ruby community doesn't seem to discuss avoiding the use of file positions after ungetc. Behavior changing under little-known conditions reduces test coverage and leaves potential bugs. On Windows, files opened in "r" mode perform CRLF conversion but operate without encoding conversion, delegating conversion to the C runtime library (CRT). This is primarily for speed, but it modifies IO state in various places within io.c, reducing readability. It has also caused numerous bugs related to file position. Unfortunately, in Windows, "r" and "rt" are not equivalent depending on whether encoding conversion is used or not. This means the behavior of ungetc cannot be predicted within the context of 'text mode'. I'm working personally on switching to use encoding conversion instead of CRT read(), which means encoding conversion will be used for files opened with "r". This change will alter the behavior of ungetc. This impact occurs because implementation details are being exposed excessively, which is undesirable. ## Changes and Impact IO#ungetc will no longer change the file position. This affects not only IO#pos, but also implicitly impacts the file position when writing after ungetc. TestIO#test_copy_stream_dst_rbuf depends on this behavior. Changing the behavior of IO#ungetbyte is outside the scope of this issue. Changing it caused many tests to fail, but the details have not been investigated. Since IO#ungetbyte changes the file position while IO#ungetc does not, mixing their use is no longer possible. This means that performing ungetbyte after unetc before reading the entire data will cause an exception. /test/ruby/test_io.rb fails due to the above implicit dependency, and /spec/ruby/core/io/ungetc_spec.rb fails due to a test explicitly checking IO#pos. I have no idea about investigating the impact of real-world usage. ## Another approach Do not modify Ruby's behavior. Instead, document that the file position after using IO#ungetc cannot be trusted. Alternatively, it might be possible to issue a warning during specific operations when characters from IO#ungetc remain pending. In these cases, when Windows is switched to use encoding conversion for "r", io_unread() and rb_io_tell() will also take into account the number of bytes in cbuf in addition to rbuf to maintain compatibility. I prefer to minimize code for specific environments, so this is not to my ideal. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:126214] [Ruby Feature#9779] Add Module#descendants
by shugo (Shugo Maeda) 31 Jul '26

31 Jul '26

Issue #9779 has been updated by shugo (Shugo Maeda). I've added specs to the pull request: https://github.com/ruby/ruby/pull/17807/changes/ed81db60a57ec586d4c5300282b… ---------------------------------------- Feature #9779: Add Module#descendants https://bugs.ruby-lang.org/issues/9779#change-118296 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Now classes have links to their subclasses, so how about to add Module#descendents? ```ruby class X end class Y < X end class Z < Y end p X.descendents #=> [X, Y, Z] module A end module B include A end module C include A end p A.descendents #=> [A, C, B] ``` One of my own use cases is to implement AspectJ like pointcut which matches all subclasses of the given class. Considerations: * Should the return value of Module#descendents include self? * Should the return value of Module#descendents include singleton classes? I attach a patch, where the return value includes both self and singleton classes. ---Files-------------------------------- 0001-Add-Module-descendents.patch (3.75 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126209] [Ruby Bug#15980] Coverage shows while/until after raise if/unless as uncovered line
by ioquatix (Samuel Williams) 31 Jul '26

31 Jul '26

Issue #15980 has been updated by ioquatix (Samuel Williams). Fixed in https://github.com/ruby/ruby/pull/18122 ---------------------------------------- Bug #15980: Coverage shows while/until after raise if/unless as uncovered line https://bugs.ruby-lang.org/issues/15980#change-118287 * Author: jeremyevans0 (Jeremy Evans) * Status: Closed * Assignee: mame (Yusuke Endoh) * ruby -v: ruby 2.7.0dev (2019-07-03) [x86_64-openbsd6.5] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: DONE ---------------------------------------- The following code shows line 2 (`while true`) as uncovered: ```ruby raise if 1 == 2 while true break end ``` Coverage reports the following for this file: `[1, 0, 1, nil]`. Note that `true` isn't important, any `while` condition will work. However, if you change line 1 to `raise if false`, line 1 shows `nil` coverage, and line 2 shows as covered (`[nil, 1, 1, nil]`). That leads me to believe this issue is related to the optimizer. I bisected this to commit:100bf2757468439106775a7d95a791a8c10b874a, which certainly appears related. This is not a theoretical case, it affected three lines in Sequel. While not a major problem, I do think a fix should be backported to 2.6. Note that this only affects line coverage. Branch coverage shows: ```ruby {"file.rb"=> {:branches=> {[:if, 0, 1, 0, 1, 15]=> {[:then, 1, 1, 0, 1, 5]=>0, [:else, 2, 1, 0, 1, 15]=>1}, [:while, 3, 2, 0, 4, 3]=>{[:body, 4, 3, 2, 3, 7]=>1}}}} ``` If you run with both branch and line coverage, line coverage shows correctly. This affects `while`/`until` after a line with `raise ... if ...` or `raise ... unless ...`. If you switch to `if ...; raise ...; end`, then line coverage shows correctly. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126200] [Ruby Bug#22219] IO::Buffer#free, #resize and #transfer should raise FrozenError if the receiver is frozen
by himura467 (Akito Shitara) 31 Jul '26

31 Jul '26

Issue #22219 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22219: IO::Buffer#free, #resize and #transfer should raise FrozenError if the receiver is frozen https://bugs.ruby-lang.org/issues/22219 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Currently `IO::Buffer#free`, `#resize` and `#transfer` can be called even if the receiver is frozen. All three release, reallocate or hand away the memory the buffer references, so they change the state of the buffer. Therefore it seems a bug to me, and these methods should raise `FrozenError` if the receiver is frozen. ```ruby # Current IO::Buffer.new(4).freeze.free # succeeds, the buffer becomes null IO::Buffer.new(4).freeze.resize(8) # succeeds, the memory is reallocated IO::Buffer.new(4).freeze.transfer # succeeds, the receiver becomes null # Expected IO::Buffer.new(4).freeze.free # raise FrozenError IO::Buffer.new(4).freeze.resize(8) # raise FrozenError IO::Buffer.new(4).freeze.transfer # raise FrozenError ``` Methods to fix: * `IO::Buffer#free` * `IO::Buffer#resize` * `IO::Buffer#transfer` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126185] [Ruby Feature#22215] Introduce narrow internal interfaces for bundled extensions
by nobu (Nobuyoshi Nakada) 28 Jul '26

28 Jul '26

Issue #22215 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22215: Introduce narrow internal interfaces for bundled extensions https://bugs.ruby-lang.org/issues/22215 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- ## Abstract Introduce narrow internal interfaces for bundled extensions so that they do not need to depend on VM implementation headers such as `vm_core.h` or thread implementation files such as `thread_pthread.h`. These interfaces are declared in `internal/` headers and are not intended to be stable APIs for third-party extensions. ## Background Some bundled extensions currently include private implementation headers to access a small part of CRuby internals. For example, `ext/coverage` needs to enumerate method coverage data. Doing that directly requires knowledge of method entries, IMEMOs, the object space, and VM-private structures. Consequently, the extension depends on `internal/gc.h` and `vm_core.h`. Likewise, `ext/objspace` accesses fields of call-info and call-cache IMEMOs directly. These dependencies expose the extensions to much more of the VM implementation than they actually need. They also cause extensions to depend transitively on thread implementation files through `vm_core.h`. ## Proposal Add narrow internal interfaces for the bundled extensions: * Collect coverage constants and declarations in `internal/coverage.h`. * Perform method-entry traversal in the core and pass normalized method coverage data to `ext/coverage` through `rb_coverage_each_method`. * Add `rb_imemo_callinfo_mid` and `rb_imemo_callcache_get_data` for the information required by `ext/objspace`. * Keep these declarations in `internal/` headers rather than public `ruby/` headers. * Remove the transitive inclusion of `vm_core.h` from `internal/gc.h`. The new interfaces must be exported because the bundled extensions can be built as shared libraries. They are internal implementation interfaces, not supported extension APIs. With these interfaces, extensions under `ext` no longer depend on `vm_core.h` or `thread_pthread.[ch]`. ## Compatibility There is no intended Ruby-level behavior change. The new interfaces are internal to CRuby and are not intended to provide API or ABI compatibility guarantees for third-party extensions. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126183] [Ruby Bug#22214] SEGV when struct ractor_port.r is referenced after Ractor::Port.allocate
by himura467 (Akito Shitara) 28 Jul '26

28 Jul '26

Issue #22214 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22214: SEGV when struct ractor_port.r is referenced after Ractor::Port.allocate https://bugs.ruby-lang.org/issues/22214 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `Ractor::Port` has a public allocator, so `Ractor::Port.allocate` returns a port whose owner Ractor (`struct ractor_port.r`) is still NULL; only `ractor_port_init()` fills it in. Methods dereference it without a check. ```ruby Ractor::Port.allocate.closed? ``` ``` <internal:ractor>:829: [BUG] Segmentation fault at 0x0000000000000060 ruby 4.1.0dev (2026-07-26T18:55:18Z master eb9d72aea1) +PRISM [arm64-darwin25] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' <internal:ractor>:829:in 'closed?' -- C level backtrace information ------------------------------------------- ruby(rb_native_mutex_lock+0xc) [0x104f922fc] ../thread_pthread.c:127 ruby(ractor_port_closed_p+0x30) [0x104efc2f8] ../ractor.c:74 ruby(builtin_inline_class_829) ../ractor.rb:830 ruby(builtin_invoker0+0x8) [0x104fd76ac] ../vm_insnhelper.c:7392 ``` `#send` and `Ractor#monitor` / `#unmonitor` fault at the same address, `#inspect` at 0x8 in `rb_ractor_id()`. `#receive` and `#close` happen to raise `Ractor::Error`, but only because their `rp->r != current ractor` check catches NULL by accident, so they report the port as belonging to another Ractor. `Ractor.select` does not crash, because `ractor_try_receive()` keys only on `rp->id_`. That field is 0 for an uninitialized port, which is also the id of the current Ractor's default port, so the port takes messages from it: ```ruby port = Ractor::Port.allocate Ractor.current.default_port.send(:hello) p Ractor.select(port)[1] #=> :hello ``` -- https://bugs.ruby-lang.org/

1 1