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

[ruby-core:114620] [Ruby master Feature#19075] Binary searching for the last element
by sawa (Tsuyoshi Sawada) 04 Sep '23

04 Sep '23

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/

1 0

[ruby-core:114619] [Ruby master Feature#19075] Binary searching for the last element
by Dan0042 (Daniel DeLorme) 04 Sep '23

04 Sep '23

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/

1 0

[ruby-core:114488] [Ruby master Bug#19847] Cannot install Ruby 3.2.2 on Windows using Visual Studio 2019
by dmwhitne (David Whitney) 01 Sep '23

01 Sep '23

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/

2 2

[ruby-core:114433] [Ruby master Bug#19843] Promote bigdecimal as bundled gems at Ruby 3.4
by hsbt (Hiroshi SHIBATA) 01 Sep '23

01 Sep '23

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/

3 4

[ruby-core:114612] [Ruby master Bug#16951] Consistently referer dependencies
by hsbt (Hiroshi SHIBATA) 01 Sep '23

01 Sep '23

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/

1 0

[ruby-core:114276] [Ruby master Bug#19784] String#delete_prefix! problem
by inversion (Yura Babak) 01 Sep '23

01 Sep '23

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/

6 9