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

[ruby-core:114627] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.

by byroot (Jean Boussier)

Issue #19057 has been updated by byroot (Jean Boussier). Eric just said he'll cut new `unicorn` and `kgio` releases: https://yhbt.net/kgio.git/dbf5290cf9f89174f6b35a597af9a4226633d79b/s/ > Will push out a release once docs are updated to more strongly discourage the use of kgio and unicorn. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-104455 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.3 ---------------------------------------- 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/

8 months, 1 week

1
0
0 0

[ruby-core:114626] [Ruby master Bug#18080] Syntax error on one-line pattern matching

by yui-knk (Kaneko Yuichiro)

Issue #18080 has been updated by yui-knk (Kaneko Yuichiro). It's possible https://github.com/yui-knk/ruby/tree/bugs_18080. However need to notice about inconsistency for one line pattern matching for command call without block, like `[].append 1 => a`. Because this is interpreted as `#append` call with hash (`1 => a`) now, so it's impossible to change the behavior without introducing incompatibility. ```ruby [].append => a [].append in a [].append do end => a [].append do end in a [].append(1) => a [].append(1) in a [].append(1) do end => a [].append(1) do end in a # Only this is interpreted as #append method call with hash argument [].append 1 => a [].append 1 in a [].append 1 do end => a [].append 1 do end in a ``` In my opinion (1) is more clear than (2). (1) Method call without surrounding parameters parenthesis can not be put on left of single line pattern matching (2) Almost all method calls can be on left of single line pattern matching but there is one exception (a) without block (b) without parenthesis for parameters (c) pattern matching with `=>` # Note The inconsistency can be found as Shift/Reduce conflict. In this state, shift derives `arg_value • "=>" arg_value` (hash), on the other hand reduce derives `command_call => p_top_expr_body` (pattern matching). https://github.com/yui-knk/ruby/tree/bugs_18080_2 ``` State 223 shift/reduce conflict on token "=>": 308 args: arg_value • 759 assoc: arg_value • "=>" arg_value First example: $@1 k_return arg_value • "=>" arg_value opt_block_arg "=>" @7 @8 p_top_expr_body opt_terms "end-of-input" Shift derivation $accept ↳ 0: program "end-of-input" ↳ 2: $@1 top_compstmt ↳ 3: top_stmts opt_terms ↳ 5: top_stmt ↳ 7: stmt ↳ 37: expr ↳ 65: command "=>" @7 @8 p_top_expr_body ↳ 97: k_return call_args ↳ 299: assocs opt_block_arg ↳ 757: assoc ↳ 759: arg_value • "=>" arg_value Second example: $@1 k_return arg_value • opt_block_arg "=>" @7 @8 p_top_expr_body opt_terms "end-of-input" Reduce derivation $accept ↳ 0: program "end-of-input" ↳ 2: $@1 top_compstmt ↳ 3: top_stmts opt_terms ↳ 5: top_stmt ↳ 7: stmt ↳ 37: expr ↳ 65: command_call "=>" @7 @8 p_top_expr_body ↳ 82: command ↳ 97: k_return call_args ↳ 298: args opt_block_arg ↳ 308: arg_value • ``` ---------------------------------------- Bug #18080: Syntax error on one-line pattern matching https://bugs.ruby-lang.org/issues/18080#change-104454 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal * ruby -v: 3.1.0dev * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- One line pattern matching with a method return value with parameters which are not surrounded by parenthesis raises syntax error. I think it is not intentional, but nobu said it's hard to support because of parse.y limitation. ```ruby p do end => a p a #=> nil p(1) do end => a p a #=> 1 p 1 do end => a #=> # syntax error, unexpected =>, expecting end-of-input # end => a # ^~ p 1 do end in a #=> # syntax error, unexpected `in', expecting end-of-input # end in a # ^~ ``` -- https://bugs.ruby-lang.org/

8 months, 1 week

1
0
0 0

[ruby-core:111499] [Ruby master Bug#19281] SyntaxError if first argument of command call has semicolon inside parenthesis

by tompng (tomoya ishida)

Issue #19281 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19281: SyntaxError if first argument of command call has semicolon inside parenthesis https://bugs.ruby-lang.org/issues/19281 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These are syntax error ~~~ruby p (1;2),(3),(4) p (;),(),() a.b (1;2),(3),(4) a.b (;),(),() ~~~ I expect it to be syntax ok because the code below is syntax ok. ~~~ruby p (1),(2;3),(4;5) p (),(;),(;) a.b (1),(2;3),(4;5) a.b (),(;),(;) ~~~ It will be easy to traverse sexp if the sexp of first argument is same as others ~~~ruby Ripper.sexp "p (),(),()" # => [:program, [[:command, [:@ident, "p", [1, 0]], [:args_add_block, [[:paren, false], # [:paren, [[:void_stmt]]] [:paren, [[:void_stmt]]], [:paren, [[:void_stmt]]]], false]]]] Ripper.sexp "p (1),(2),(3)" # => [:program, [[:command, [:@ident, "p", [1, 0]], [:args_add_block, [[:paren, [:@int, "1", [1, 3]]], # [:paren, [[:@int, "1", [1, 3]]]] [:paren, [[:@int, "2", [1, 7]]]], [:paren, [[:@int, "3", [1, 11]]]]], false]]]] ~~~ -- https://bugs.ruby-lang.org/

8 months, 1 week

3
2
0 0

[ruby-core:114620] [Ruby master Feature#19075] Binary searching for the last element

by sawa (Tsuyoshi Sawada)

Issue #19075 has been updated by sawa (Tsuyoshi Sawada). When we want to reverse the direction in any sense, such as the direction of search, in my understanding, it's Ruby's custom to use the word "reverse" or a prefix "r": `Enumerable#revserse_each` `Array#rindex` `String#rindex` `String#rjust` `String#rpartition` `String#rstrip` To be consistent, I think it is better to have independent methods as in the original proposal, but with method names like: `reverse_bsearch` `bsearch_rindex` ---------------------------------------- Feature #19075: Binary searching for the last element https://bugs.ruby-lang.org/issues/19075#change-104447 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- My latest proposal is https://bugs.ruby-lang.org/issues/19075#note-6. I will leave the initial proposal below. --- PR: https://github.com/ruby/ruby/pull/6611 (I'm going to talk about `Array` here, but the same argument can be made for `Range`. If `Array#bsearch_last` is acceptable, I will work also for `Range`.) Ruby's bsearch returns the first element which satisfies the given block. ```ruby # Search the first element greater than 18 array = [10, 15, 20, 25] array.bsearch { |x| x > 18 } # => 20 ``` If we want the last element, we need to invert the condition and step backward. ```ruby # Search the last element less than 18 array = [10, 15, 20, 25] index = array.bsearch_index { |x| !(x < 18) } array[index-1] # => 15 ``` Of course, we need to consider `nil` and the boundary. ```ruby # Search the last element less than 100 index = array.bsearch_index { |x| !(x < 100) } # => nil if index.nil? array.last # => 25 else array[index-1] end ``` ```ruby # Search the last element less than 0 index = array.bsearch_index { |x| !(x < 0) } # => 0 if index.nil? array.last elsif index == 0 nil else array[index-1] end ``` This is where mistakes can easily be made, so I propose `Array#bsearch_last` and `Array#bsearch_last_index`. `Array#bsearch_last` returns the last element which satisfies the given block. `Array#bsearch` requires that all false-evaluating elements precede all true-evaluating elements. As is clear from the meaning of the method, conversely to `bsearch`, `bsearch_last` requires that all true-evaluating elements precede all false-evaluating elements. (If `bsearch_last` is acceptable, the name "find-minimum mode" should be changed.) ```ruby array = [10, 15, 20, 25] array.bsearch_last { |x| x < 18 } # => 15 array.bsearch_last { |x| x < 100 } # => 25 array.bsearch_last { |x| x < 0 } # => nil ``` There are several possible options for find-any mode. (1) `bsearch_last` does not support find-any mode. A block for `bsearch_last` must return `true`, `false` or `nil`. ``` [1, 2, 3].bsearch_last { 0 } # => TypeError ``` My pull request tentatively includes this implementation. (2) `bsearch_last` supports find-any mode and it behaves like `bsearch`. `bsearch` with find-any mode returns an element, for which the block returns zero. If multiple elements satisfy the condition, it is not determined which of them will be returned. It is conceivable that `bsearch_last` behaves in the same way as `bsearch`. ``` # current behavior # It is not specified whether `:b`, `:c`, or `:d` is returned. [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :c] ``` (3) `bsearch_last` supports find-any mode and returns the last element. Make `bsearch` return the first element. Change the behavior of `bsearch` to return the first element for which the block returns zero. `bsearch_last` returns the last element for which the block returns zero. ``` # Change it like this: [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :b] [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch_last { |a, b| 2 <=> a } # => [2, :d] ``` (If this option is adopted, the name "find-any mode" should be renamed.) -- https://bugs.ruby-lang.org/

8 months, 1 week

1
0
0 0

[ruby-core:114619] [Ruby master Feature#19075] Binary searching for the last element

by Dan0042 (Daniel DeLorme)

Issue #19075 has been updated by Dan0042 (Daniel DeLorme). > ``` > a = [2, 3, 5, 7, 11] > a.bsearch {|x| x >= 6 } # => 7 > a.bsearch(target: :first) {|x| x >= 6 } # same as a.bsearch { ... } > a.bsearch(target: :last) {|x| x <= 6 } # => 5 > a.bsearch(target: :first) {|x| 0 } # => 2 > a.bsearch(target: :last) {|x| 0 } # => 11 > ``` I like this implementation. But for naming, personally I find `target: :last` to be confusing. If I suddenly read that in code I wouldn't be able to guess what it does; I would have to refer to the documentation. I don't really have a good alternative. Maybe `bsearch(find: :last)` ?_? ---------------------------------------- Feature #19075: Binary searching for the last element https://bugs.ruby-lang.org/issues/19075#change-104446 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- My latest proposal is https://bugs.ruby-lang.org/issues/19075#note-6. I will leave the initial proposal below. --- PR: https://github.com/ruby/ruby/pull/6611 (I'm going to talk about `Array` here, but the same argument can be made for `Range`. If `Array#bsearch_last` is acceptable, I will work also for `Range`.) Ruby's bsearch returns the first element which satisfies the given block. ```ruby # Search the first element greater than 18 array = [10, 15, 20, 25] array.bsearch { |x| x > 18 } # => 20 ``` If we want the last element, we need to invert the condition and step backward. ```ruby # Search the last element less than 18 array = [10, 15, 20, 25] index = array.bsearch_index { |x| !(x < 18) } array[index-1] # => 15 ``` Of course, we need to consider `nil` and the boundary. ```ruby # Search the last element less than 100 index = array.bsearch_index { |x| !(x < 100) } # => nil if index.nil? array.last # => 25 else array[index-1] end ``` ```ruby # Search the last element less than 0 index = array.bsearch_index { |x| !(x < 0) } # => 0 if index.nil? array.last elsif index == 0 nil else array[index-1] end ``` This is where mistakes can easily be made, so I propose `Array#bsearch_last` and `Array#bsearch_last_index`. `Array#bsearch_last` returns the last element which satisfies the given block. `Array#bsearch` requires that all false-evaluating elements precede all true-evaluating elements. As is clear from the meaning of the method, conversely to `bsearch`, `bsearch_last` requires that all true-evaluating elements precede all false-evaluating elements. (If `bsearch_last` is acceptable, the name "find-minimum mode" should be changed.) ```ruby array = [10, 15, 20, 25] array.bsearch_last { |x| x < 18 } # => 15 array.bsearch_last { |x| x < 100 } # => 25 array.bsearch_last { |x| x < 0 } # => nil ``` There are several possible options for find-any mode. (1) `bsearch_last` does not support find-any mode. A block for `bsearch_last` must return `true`, `false` or `nil`. ``` [1, 2, 3].bsearch_last { 0 } # => TypeError ``` My pull request tentatively includes this implementation. (2) `bsearch_last` supports find-any mode and it behaves like `bsearch`. `bsearch` with find-any mode returns an element, for which the block returns zero. If multiple elements satisfy the condition, it is not determined which of them will be returned. It is conceivable that `bsearch_last` behaves in the same way as `bsearch`. ``` # current behavior # It is not specified whether `:b`, `:c`, or `:d` is returned. [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :c] ``` (3) `bsearch_last` supports find-any mode and returns the last element. Make `bsearch` return the first element. Change the behavior of `bsearch` to return the first element for which the block returns zero. `bsearch_last` returns the last element for which the block returns zero. ``` # Change it like this: [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch { |a, b| 2 <=> a } # => [2, :b] [[1,:a], [2, :b], [2, :c], [2, :d], [3, :e]].bsearch_last { |a, b| 2 <=> a } # => [2, :d] ``` (If this option is adopted, the name "find-any mode" should be renamed.) -- https://bugs.ruby-lang.org/

8 months, 1 week

1
0
0 0

[ruby-core:114488] [Ruby master Bug#19847] Cannot install Ruby 3.2.2 on Windows using Visual Studio 2019

by dmwhitne (David Whitney)

Issue #19847 has been reported by dmwhitne (David Whitney). ---------------------------------------- Bug #19847: Cannot install Ruby 3.2.2 on Windows using Visual Studio 2019 https://bugs.ruby-lang.org/issues/19847 * Author: dmwhitne (David Whitney) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mswin64_140] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I am attempting to build/install Ruby 3.2.2 open-source code on Windows using Visual Studio 2019. These are the steps I followed: Using an x64 Native Tools Command Prompt (for Visual Studio 2019).. 1. cd C:\tmp\ruby-3.2.2 2. win32\configure.bat --prefix=C:\Ruby-3.2.2 --target=x64-mswin64 --disable-install-doc 3. nmake 4. nmake install The error (on Step 4): Downloading bundled gem files... `RubyGems' were not loaded. `error_highlight' was not loaded. `did_you_mean' was not loaded. `syntax_suggest' was not loaded. c:/tmp/ruby-3.2.2/tool/downloader.rb:4:in `require': cannot load such file -- fileutils (LoadError) from c:/tmp/ruby-3.2.2/tool/downloader.rb:4:in `<top (required)>' from -e:in `require' NMAKE : fatal error U1077: 'c:\tmp\RUBY-3~1.2\ruby.exe' : return code '0x1' Stop. Is this a bug, or operator error? -- https://bugs.ruby-lang.org/

8 months, 1 week

2
2
0 0

[ruby-core:114433] [Ruby master Bug#19843] Promote bigdecimal as bundled gems at Ruby 3.4

by hsbt (Hiroshi SHIBATA)

Issue #19843 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19843: Promote bigdecimal as bundled gems at Ruby 3.4 https://bugs.ruby-lang.org/issues/19843 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I triaged target list for bundled gems at https://bugs.ruby-lang.org/issues/19351. After that, I resolved bigdecimal dependency from our test suite at https://github.com/ruby/ruby/commit/3ef6364a988ab24ca7fdbb7d1b6840b2a40f1466 I propose to promote `bigdecimal` as bundled gems at Ruby 3.4. @mrkn Is it okay? I will add `bigdecimal` to `Gem::BUNDLED_GEMS::SINCE` for Ruby 3.3.0-preview2. -- https://bugs.ruby-lang.org/

8 months, 1 week

3
4
0 0

[ruby-core:114612] [Ruby master Bug#16951] Consistently referer dependencies

by hsbt (Hiroshi SHIBATA)

Issue #16951 has been updated by hsbt (Hiroshi SHIBATA). >would it be possible to get an update on this? It's difficult to answer. All of dependencies are maintainer's convenience basically. I started to suggest to add dependency explicitly for gem authors at https://bugs.ruby-lang.org/issues/19776. You can see this suggested gems at https://github.com/ruby/ruby/blob/master/lib/bundled_gems.rb#L2. On the other hand, I have no plan to add `net-http` into `Gem::BUNDLED_GEMS::SINCE` because `net-http` provides core feature of RubyGems. So, we can't remove it from default gems. ---------------------------------------- Bug #16951: Consistently referer dependencies https://bugs.ruby-lang.org/issues/16951#change-104440 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * ruby -v: ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- It seems that the default gems interdependencies in Ruby are mess. Years ago, when JSON was merged into StdLib, there was big movement and everybody dropped their references to JSON "because it is part of StdLib and therefore it is not needed". I always thought that removing the references was mistake. Now, there are other interesting cases. Let me name two I know about: 1) REXML is going to be removed from default gems in Ruby 2.8, so some packages already started to introduce the dependency explicitly [1]. So once somebody uses Kramdown on older Ruby, the external REXML of whatever version is going to be used. 2) There are also gems in StdLib, such as IRB, which are specifying their dependencies in .gemspec file. This is unfortunately causing very inconsistent user experience, depending if RubyGems are enabled/disabled, if one is using Bundler or not, if somebody explicitly states something somewhere and what dependencies are transitively pulled in. I would really appreciate, if Ruby upstream finally paid attention to this problem. My suggestion is that if some gem depends on some other gem, this dependency should be always explicitly stated in the .gemspec file. This would provide clear precedence and guideline to others. This would save all possible surprises and hidden issues, suddenly using dependency of different version, which is pulled in transitively. [1]: https://github.com/gettalong/kramdown/commit/c1aa6ad98fab589050ab8e82897ec4… -- https://bugs.ruby-lang.org/

8 months, 1 week

1
0
0 0

[ruby-core:114276] [Ruby master Bug#19784] String#delete_prefix! problem

by inversion (Yura Babak)

Issue #19784 has been reported by inversion (Yura Babak). ---------------------------------------- Bug #19784: String#delete_prefix! problem https://bugs.ruby-lang.org/issues/19784 * Author: inversion (Yura Babak) * 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 ---------------------------------------- Here is the snipped and the question is in the comments: ``` ruby fp = 'with_BOM_16.txt' body = File.read(fp).force_encoding('UTF-8') p body # "\xFF\xFE1\u00001\u0000" p body.start_with?("\xFF\xFE") # true body.delete_prefix!("\xFF\xFE") # !!! why doesn't work? p body # "\xFF\xFE1\u00001\u0000" p body.start_with?("\xFF\xFE") # true body[0, 2] = '' p body # "1\u00001\u0000" p body.start_with?("\xFF\xFE") # false ``` Works same on Linux (ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]) and Windows (ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt]) -- https://bugs.ruby-lang.org/

8 months, 1 week

6
9
0 0

2024

2023

2022

ruby-core September 2023