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

[ruby-core:114115] [Ruby master Bug#19762] rubyspec refers wrongly ruby version instead of gem versions
by nobu (Nobuyoshi Nakada) 10 Jul '23

10 Jul '23

Issue #19762 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19762: rubyspec refers wrongly ruby version instead of gem versions https://bugs.ruby-lang.org/issues/19762 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Assignee: Eregon (Benoit Daloze) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```shell-session $ git grep ruby_version_is spec/ruby/library/ | grep -F -v -e /rbconfig/ -e /objectspace/ -e /coverage/ -e /fiber/ | wc -l 193 ``` Libraries under this directory, except for libraries excluded with `grep -v` in the above, are standard or bundled gems, and their own versions, and `RUBY_VERSION` is unrelated to them. `version_is` must be used under the directory instead of `ruby_version_is`, for example: ``` spec/ruby/library/bigdecimal/remainder_spec.rb:57: version_is BigDecimal::VERSION, ""..."3.1.4" do spec/ruby/library/datetime/to_time_spec.rb:22: version_is(date_version, '3.2.3') do spec/ruby/library/logger/device/close_spec.rb:18: version_is Logger::VERSION, ""..."1.4.0" do spec/ruby/library/logger/device/close_spec.rb:25: version_is Logger::VERSION, "1.4.0" do spec/ruby/library/logger/device/write_spec.rb:38: version_is Logger::VERSION, ""..."1.4.0" do spec/ruby/library/logger/device/write_spec.rb:45: version_is Logger::VERSION, "1.4.0" do spec/ruby/library/matrix/unitary_spec.rb:17: version_is((Matrix::const_defined?(:VERSION) ? Matrix::VERSION : "0.1.0"), "0.3.0") do spec/ruby/library/openssl/config/freeze_spec.rb:6:version_is(OpenSSL::VERSION, ""..."2.2") do spec/ruby/library/stringio/initialize_spec.rb:299: version_is(stringio_version, "0.0.3"..."0.1.1") spec/ruby/library/time/to_datetime_spec.rb:17: version_is(date_version, '3.2.3') do ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:114119] [Ruby master Bug#19763] Inconsistent error message for String#index vs String#rindex
by itarato (Peter Arato) 08 Jul '23

08 Jul '23

Issue #19763 has been reported by itarato (Peter Arato). ---------------------------------------- Bug #19763: Inconsistent error message for String#index vs String#rindex https://bugs.ruby-lang.org/issues/19763 * Author: itarato (Peter Arato) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `String#index` and `String#rindex` yields different error messages when used with a `Regexp` argument: ```ruby 'abc'.force_encoding("ISO-2022-JP").index(/わ/) ``` Prints: `incompatible character encodings: ISO-2022-JP and UTF-8 (Encoding::CompatibilityError)` ```ruby 'abc'.force_encoding("ISO-2022-JP").rindex(/わ/) ``` Prints: `incompatible encoding regexp match (UTF-8 regexp with ISO-2022-JP string) (Encoding::CompatibilityError)` Looking at a few other use cases (eg `String#byteindex`, `String#byterindex`) Ruby seems to use the message `incompatible encoding regexp match ` when encoding is checked between a String and a Regexp instance. Is this a bug for `String#index`? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114108] [Ruby master Bug#19760] Marshal.load Segmentation fault in ruby 2.2.10 aarch64
by lijian＠zdns.cn (jian li) 07 Jul '23

07 Jul '23

Issue #19760 has been reported by lijian(a)zdns.cn (jian li). ---------------------------------------- Bug #19760: Marshal.load Segmentation fault in ruby 2.2.10 aarch64 https://bugs.ruby-lang.org/issues/19760 * Author: lijian(a)zdns.cn (jian li) * Status: Open * Priority: Normal * ruby -v: 2.2.10 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- irb(main):121:0> 100000.times{ Marshal.load(Marshal.dump(""))} (irb):121: [BUG] Segmentation fault at 0x00000000000000 ruby 2.2.10p489 (2018-03-28 revision 63023) [aarch64-linux] -- C level backtrace information ------------------------------------------- /usr/local/appsys/normal/package/lib/libruby.so.2.2(rb_vm_bugreport+0x9c) [0xffff04c92dfc] vm_dump.c:697 /usr/local/appsys/normal/package/lib/libruby.so.2.2(rb_bug_context+0xb8) [0xffff04b37908] error.c:425 /usr/local/appsys/normal/package/lib/libruby.so.2.2(sigsegv+0x40) [0xffff04c10800] signal.c:879 linux-vdso.so.1 [0xffff04dc07c0] /usr/local/appsys/normal/package/lib/libruby.so.2.2(r_object0+0x98) [0xffff04b81378] marshal.c:1773 /usr/local/appsys/normal/package/lib/libruby.so.2.2(marshal_load+0x104) [0xffff04b82fd4] marshal.c:1981 /usr/local/appsys/normal/package/lib/libruby.so.2.2(vm_call_cfunc+0x104) [0xffff04c7eae4] vm_insnhelper.c:1380 /usr/local/appsys/normal/package/lib/libruby.so.2.2(vm_exec_core+0x494) [0xffff04c8164c] vm_insnhelper.c:475 /usr/local/appsys/normal/package/lib/libruby.so.2.2(vm_exec+0x8c) [0xffff04c86f84] vm.c:1551 /usr/local/appsys/normal/package/lib/libruby.so.2.2(invoke_block_from_c+0x4d0) [0xffff04c8ba30] vm.c:873 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:114106] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by nobu (Nobuyoshi Nakada) 07 Jul '23

07 Jul '23

Issue #19057 has been updated by nobu (Nobuyoshi Nakada). k0kubun (Takashi Kokubun) wrote in #note-20: > It looks like @byroot sent a patch for this at https://yhbt.net/kgio-public/B5843088-6EC1-4D1B-A45A-2699CA75DD7F@gmail.com…. `rb_convert_type(io, T_FILE, "IO", "to_io")` can be `rb_io_get_io(io)`. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-103781 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- 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:114104] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by k0kubun (Takashi Kokubun) 07 Jul '23

07 Jul '23

Issue #19057 has been updated by k0kubun (Takashi Kokubun). > I've noticed the same thing while trying to install kgio with the latest ruby HEAD. It looks like @byroot sent a patch for this at https://yhbt.net/kgio-public/B5843088-6EC1-4D1B-A45A-2699CA75DD7F@gmail.com…. Both patches are still not released. Unless @normalperson cuts a timely release for kgio and raindrops, we will not be able to use Unicorn on Ruby 3.3 because of this Feature. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-103779 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- 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:114080] [Ruby master Bug#19756] URI::HTTP.build does not accept a host of `_gateway`, but `URI.parse` will.
by postmodern (Hal Brodigan) 05 Jul '23

05 Jul '23

Issue #19756 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Bug #19756: URI::HTTP.build does not accept a host of `_gateway`, but `URI.parse` will. https://bugs.ruby-lang.org/issues/19756 * Author: postmodern (Hal Brodigan) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I noticed a difference in behavior between `URI::HTTP.build` and `URI.parse`. `URI::HTTP.build` will not accept `host:` value of `_gateway`, but `URI.parse` will. ## Steps To Reproduce ```ruby URI::HTTP.build(host: "_gateway") ``` vs. ```ruby URI.parse("http://_gateway") ``` ### Expected Results Both raise the same exception, or return the same URI object. ### Actual Results ``` URI::HTTP.build(host: "_gateway") /usr/share/ruby/uri/generic.rb:601:in `check_host': bad component(expected host component): _gateway (URI::InvalidComponentError) from /usr/share/ruby/uri/generic.rb:640:in `host=' from /usr/share/ruby/uri/generic.rb:673:in `hostname=' from /usr/share/ruby/uri/generic.rb:190:in `initialize' from /usr/share/ruby/uri/generic.rb:136:in `new' from /usr/share/ruby/uri/generic.rb:136:in `build' from /usr/share/ruby/uri/http.rb:61:in `build' from (irb):2:in `<main>' from /usr/local/share/gems/gems/irb-1.7.0/exe/irb:9:in `<top (required)>' from /usr/local/bin/irb:25:in `load' from /usr/local/bin/irb:25:in `<main>' ``` ``` URI.parse("https://_gateway") # => #<URI::HTTPS https://_gateway> ``` ## Additional Information ``` $ gem list uri uri (default: 0.12.1) ``` -- https://bugs.ruby-lang.org/

6 8

[ruby-core:114088] [Ruby master Feature#19757] Add new C API to create a subclass of `Data`
by nobu (Nobuyoshi Nakada) 05 Jul '23

05 Jul '23

Issue #19757 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #19757: Add new C API to create a subclass of `Data` https://bugs.ruby-lang.org/issues/19757 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- I propose a C API `rb_data_define` which crates a subclass of `Data`. ```C /** * Defines an anonymous data class. * * @endinternal * * @param[in] super Superclass of the defining class. Must be a * descendant of ::rb_cData, or 0 as ::rb_cData. * @param[in] ... Arbitrary number of `const char*`, terminated by * NULL. Each of which are the name of fields. * @exception rb_eArgError Duplicated field name. * @return The defined class. */ VALUE rb_data_define(VALUE super, ...); ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114087] [Ruby master Feature#16657] Don't ship bundled gems as .gem files as well as in expanded form
by hsbt (Hiroshi SHIBATA) 05 Jul '23

05 Jul '23

Issue #16657 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Assigned Assignee set to hsbt (Hiroshi SHIBATA) ---------------------------------------- Feature #16657: Don't ship bundled gems as .gem files as well as in expanded form https://bugs.ruby-lang.org/issues/16657#change-103764 * Author: vo.x (Vit Ondruch) * Status: Assigned * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- Working at #16651, I wonder why the release tarball ships with the bundled gem in form of .gem packages as well as the expanded sources. It would be nice, if one option is chosen. Ideally just the .gem packages, because these are vanilla upstream packages installable via RubyGems without rbinstall magic. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112773] [Ruby master Feature#19521] Support for `Module#name=` and `Class#name=`.
by ioquatix (Samuel Williams) 02 Jul '23

02 Jul '23

Issue #19521 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19521: Support for `Module#name=` and `Class#name=`. https://bugs.ruby-lang.org/issues/19521 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- See https://bugs.ruby-lang.org/issues/19450 for previous discussion and motivation. This proposal introduces `Class#name=` to set the temporary class name. This is an alternative or addition to <https://bugs.ruby-lang.org/issues/19520>. ```ruby c = Class.new do self.name = "fake name" end c = Class.new c.name = "fake name" ``` Alternatively, we could use `set_name`: ```ruby Class.new do set_name "fake_name" end ``` ## Example usage The current Ruby test suite has code which shows the usefulness of this new method: ```ruby def labeled_module(name, &block) Module.new do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_module def labeled_class(name, superclass = Object, &block) Class.new(superclass) do singleton_class.class_eval { define_method(:to_s) {name} alias inspect to_s alias name to_s } class_eval(&block) if block end end module_function :labeled_class ``` The updated code would look like this: ```ruby def labeled_module(name, &block) Module.new do self.name = name class_eval(&block) if block end end def labeled_class(name, superclass = Object, &block) Class.new(superclass) do self.name = name class_eval(&block) if block end end module_function :labeled_class ``` Because the name cannot be set as part of `.new`, we have to have a separate block to set the name, before calling `class_eval`. I think the ergonomics and performance of this are slightly worse than the [counter proposal](https://bugs.ruby-lang.org/issues/19520). -- https://bugs.ruby-lang.org/

10 30

[ruby-core:114065] [Ruby master Feature#17339] Semantic grouping with BigDecimal#to_s
by cryptogopher (crypto gopher) 01 Jul '23

01 Jul '23

Issue #17339 has been updated by cryptogopher (crypto gopher). I've sent pull request with solution as specified by author of issue: https://github.com/ruby/bigdecimal/pull/264 ---------------------------------------- Feature #17339: Semantic grouping with BigDecimal#to_s https://bugs.ruby-lang.org/issues/17339#change-103736 * Author: chumaltd (Takahiro Chuma) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) ---------------------------------------- # Abstract Thousands, millions, ... should be expressible with `BigDecimal#to_s`. # Background `BigDecimal('1234567').to_s('3F')` returns "123 456 7.0". # Proposal - Have an option with which `BigDecimal('1234567').to_s('3F')` returns "_1 234 567_.0". - With decimal, `BigDecimal('1234567.8901234').to_s('3F')` should return "1 234 567.890 123 4". - Default behavior should be the above in long term. - And/Or, it would be nice to have a pretty method name. I think #to_s('3F') has universal use cases like money calculation. # Discussion - International System of Units aka SI defines 3-digit-grouping on long numeric sequence. https://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=22&RES=10 - Original discussion in 1948 shows some example of 3-digit-grouping. https://www1.bipm.org/utils/common/pdf/CGPM/CGPM9.pdf#page=117 # Summary We want to have a natural format. -- https://bugs.ruby-lang.org/

1 0