January 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:116233] [Ruby master Bug#14607] Fix use of the rb_profile_frames start parameter
by dylants (Dylan Thacker-Smith) 16 Jan '24

16 Jan '24

Issue #14607 has been updated by dylants (Dylan Thacker-Smith). > The original patch has a merge conflict. However, I have opened a pull request with the fix for this issue (https://github.com/ruby/ruby/pull/2713) that has been rebased to resolve the merge conflict. The github PR has been merged, so this issue can be closed now. It doesn't look like I have permission to change its status though. ---------------------------------------- Bug #14607: Fix use of the rb_profile_frames start parameter https://bugs.ruby-lang.org/issues/14607#change-106253 * Author: dylants (Dylan Thacker-Smith) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- rb_profile_frames was always behaving as if the value given for the start parameter was 0. The reason for this was that it would check `if (start > 0) {` then `continue` without updating the control frame pointer or anything other than decrementing `start`. This bug applies to all branches under normal maintenance, from ruby 2.3 to trunk. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116232] [Ruby master Bug#5179] Complex#rationalize and to_r with approximate zeros
by mrkn (Kenta Murata) 16 Jan '24

16 Jan '24

Issue #5179 has been updated by mrkn (Kenta Murata). `Complex(re, im.to_r).to_r` looks good to me if `im` is not `0` or `0r`. `Complex(re, im.to_i).to_i` is also OK for me in the same manner. `Complex(re, im.to_f).to_f` cannot resolve the problem the current `to_f` holds. I don't have other ideas to resolve this right now. I don't think we can discuss `**` along with `to_r` because `**` is not type conversion. ---------------------------------------- Bug #5179: Complex#rationalize and to_r with approximate zeros https://bugs.ruby-lang.org/issues/5179#change-106251 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) * ruby -v: r32354 ---------------------------------------- Currently, Complex#rationalize and Complex#to_r raise a RangeError if the imaginary part is nonzero *or is a Float*. Note that a BigDecimal(0) is accepted, though: Complex(1, 0).to_r # => Rational(1,1) Complex(1, BigDecimal("0.0")).to_r # => Rational(1,1) Complex(1, 0.0).to_r # => RangeError This is inconsistent. I recommend not raising an error for 0.0 (Float or BigDecimal). Any objection? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114590] [Ruby master Bug#19857] Eval coverage is reset after each `eval`.
by ioquatix (Samuel Williams) 16 Jan '24

16 Jan '24

Issue #19857 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19857: Eval coverage is reset after each `eval`. https://bugs.ruby-lang.org/issues/19857 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It seems like `eval` based coverage is reset every time eval is invoked. ```ruby #!/usr/bin/env ruby require 'coverage' def measure(flag) c = Class.new c.class_eval(<<~RUBY, "foo.rb", 1) def foo(flag) if flag puts "foo" else puts "bar" end end RUBY return c.new.foo(flag) end Coverage.start(lines: true, eval: true) # Depending on the order of these two operations, different computation is calculated, because the evaluation of the code is considered different, even if the content/path is the same. measure(false) measure(true) p Coverage.result ``` Further investigation is required. -- https://bugs.ruby-lang.org/

3 19

[ruby-core:116084] [Ruby master Feature#20164] Add Exception#deconstruct_keys
by Dan0042 (Daniel DeLorme) 15 Jan '24

15 Jan '24

Issue #20164 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20164: Add Exception#deconstruct_keys https://bugs.ruby-lang.org/issues/20164 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- It would be convenient to perform pattern matching with exception classes. So `Exception#deconstruct_keys` should return a hash with `:message` (original_message) as well as any other keys specific to the exception subclass. Examples: ``` begin #code rescue => err case err in StandardError(message: /Permission denied/) abort "please select a different file" in NameError(name: :foo) retry if require "foo_helper else raise end end ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:116198] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 15 Jan '24

15 Jan '24

Issue #19057 has been updated by ioquatix (Samuel Williams). Update from 5 months ago: - unicorn has merged a fix but it is not released: https://yhbt.net/unicorn.git/63c85c4282d15e22bd32a905883d2d0e149619d1/s/ - kgio has merged a fix but it is not released: https://yhbt.net/kgio.git/dbf5290cf9f89174f6b35a597af9a4226633d79b/s/ - raindrops merged a fix but it is not released: https://yhbt.net/raindrops.git/b3212417cc3e7cc44aa9e1ffe89b0d62ef3fdab5/s/ ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-106214 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * 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/

2 1

[ruby-core:116206] [Ruby master Bug#18805] IO::Buffer is inconsistent when returning a string from an empty buffer
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #18805 has been updated by ioquatix (Samuel Williams). Status changed from Open to Closed Fixed in https://github.com/ruby/ruby/commit/c5cf4d4e129f64cb69aaf0a829aed068ef1943c4 ---------------------------------------- Bug #18805: IO::Buffer is inconsistent when returning a string from an empty buffer https://bugs.ruby-lang.org/issues/18805#change-106225 * Author: procmarco (Marco Concetto Rudilosso) * Status: Closed * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I’ve been using `IO::Buffer` and I found it to be slightly inconsistent when it comes to returning empty string for empty buffers. for example, a slice of an allocated buffer with `size = 0`, returns `""` with `get_string`, as an example: ```ruby buffer = IO::Buffer.new(5) empty_buffer = buffer.slice(0,0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this returns "" ``` but, if you create a buffer with IO::Buffer.new(0) then it stops working ```ruby empty_buffer = IO::Buffer.new(0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this raises The buffer is not allocated! (IO::Buffer::AllocationError) ``` Is this working as intended? It would be good I think to have a consistent experience where the base case (buffer with size 0) always returns an empty string. I have a prototype of a possible patch I could send upstream to fix it, which would check the size of the buffer and if 0 it would always return an empty string. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116199] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #18035 has been updated by ioquatix (Samuel Williams). > If this is accepted, should Data classes all be immutable? To quote the docs: By default, it does not look like Data is considered immutable as nested values can mutate. However, this proposal would allow for immutable Data instances, e.g. ```ruby irb(main):001> Person = Data.define(:name, :age, :hobbies) => Person irb(main):002> bob = Person.new("Bob", 20, ["Ruby"]) => #<data Person name="Bob", age=20, hobbies=["Ruby"]> irb(main):003> bob.hobbies << "Fishing" => ["Ruby", "Fishing"] irb(main):004> bob => #<data Person name="Bob", age=20, hobbies=["Ruby", "Fishing"]> irb(main):005> Immutable bob => #<data Person name="Bob", age=20, hobbies=["Ruby", "Fishing"]> irb(main):006> bob.hobbies << "Biking" (irb):6:in `<main>': can't modify frozen Array: ["Ruby", "Fishing"] (FrozenError) from <internal:kernel>:187:in `loop' from -e:1:in `<main>' ``` ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-106215 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116197] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #19057 has been updated by ioquatix (Samuel Williams). Related PR: https://github.com/ruby/ruby/pull/9530 ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-106213 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * 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:116196] [Ruby master Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #18035 has been updated by ioquatix (Samuel Williams). It's not just about performance, it's about providing strong interface guarantees and making sure users don't violate those guarantees accidentally. e.g. ```ruby THINGS = [1, 2, 3] def things return THINGS end # user code: my_things = things my_things << 4 # whoops - modified constant. ``` ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-106212 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116195] [Ruby master Bug#18805] IO::Buffer is inconsistent when returning a string from an empty buffer
by ioquatix (Samuel Williams) 14 Jan '24

14 Jan '24

Issue #18805 has been updated by ioquatix (Samuel Williams). As a 2nd issue was created about the similar issue, I think it's worth improving. See https://github.com/ruby/ruby/pull/9532 for the proposed changes. ---------------------------------------- Bug #18805: IO::Buffer is inconsistent when returning a string from an empty buffer https://bugs.ruby-lang.org/issues/18805#change-106211 * Author: procmarco (Marco Concetto Rudilosso) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I’ve been using `IO::Buffer` and I found it to be slightly inconsistent when it comes to returning empty string for empty buffers. for example, a slice of an allocated buffer with `size = 0`, returns `""` with `get_string`, as an example: ```ruby buffer = IO::Buffer.new(5) empty_buffer = buffer.slice(0,0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this returns "" ``` but, if you create a buffer with IO::Buffer.new(0) then it stops working ```ruby empty_buffer = IO::Buffer.new(0) puts empty_buffer.size # this prints 0 empty_buffer.get_string # this raises The buffer is not allocated! (IO::Buffer::AllocationError) ``` Is this working as intended? It would be good I think to have a consistent experience where the base case (buffer with size 0) always returns an empty string. I have a prototype of a possible patch I could send upstream to fix it, which would check the size of the buffer and if 0 it would always return an empty string. -- https://bugs.ruby-lang.org/

1 0