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

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

05 Sep '23

Issue #19075 has been updated by Dan0042 (Daniel DeLorme). sawa (Tsuyoshi Sawada) wrote in #note-11: > `bsearch_rindex` I love this one, how it has a direct parallel in the way the condition must be inverted when using `index` vs `rindex`. ```ruby a = [5,6,6,6,7] a.index{ |e| e >= 6 } #=>1 a.rindex{ |e| e <= 6 } #=>3 (inverted condition) a.bsearch_index{ |e| e >= 6 } #=>1 a.bsearch_rindex{ |e| e <= 6 } #=>3 (inverted condition just like rindex and bsearch(target: :last) implementation above) ``` ---------------------------------------- Feature #19075: Binary searching for the last element https://bugs.ruby-lang.org/issues/19075#change-104468 * 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:114625] [Ruby master Bug#19861] Ripper does not fire any error event on unfinished heredoc
by thyresias (Thierry Lambert) 05 Sep '23

05 Sep '23

Issue #19861 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #19861: Ripper does not fire any error event on unfinished heredoc https://bugs.ruby-lang.org/issues/19861 * Author: thyresias (Thierry Lambert) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- require 'ripper' ```ruby class BasicParser < Ripper EVENTS.each do |event| module_eval(<<~RUBY, __FILE__, __LINE__ + 1) def on_#{event}(*args) puts "#{event}(\#{args.inspect})" args.unshift :#{event} args end RUBY end end p = BasicParser.new(<<~RUBY) <<~EOT foo RUBY p.parse p error: p.error? # in stdout: # heredoc_beg(["<<~EOT"]) # string_content([]) # tstring_content([" foo\n"]) # string_add([[:string_content], [:tstring_content, " foo\n"]]) # heredoc_dedent([[:string_add, [:string_content], [:tstring_content, " foo\n"]], 2]) # string_literal([[:string_add, [:string_content], [:tstring_content, " foo\n"]]]) # nl(["\n"]) # stmts_new([]) # stmts_add([[:stmts_new], [:string_literal, [:string_add, [:string_content], [:tstring_content, " foo\n"]]]]) # program([[:stmts_add, [:stmts_new], [:string_literal, [:string_add, [:string_content], [:tstring_content, " foo\n"]]]]]) # {:error=>true} ``` I would have expected one of the _error events to fire, since `p.error?` returns `true`. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114635] [Ruby master Bug#16492] TestBugReporter#test_bug_reporter_add test failures
by vo.x (Vit Ondruch) 05 Sep '23

05 Sep '23

Issue #16492 has been updated by vo.x (Vit Ondruch). I'm going to drop the patch testing with Ruby 3.3. Just briefly looking at the changes of the test case, I can imagine this one commit:git|308fe1eb858fd8029f67510a18 could have positive influence. But not sure, because I'd say this must have been issue also for Ruby 3.2. I'll see and will be back if I observe some issues. ---------------------------------------- Bug #16492: TestBugReporter#test_bug_reporter_add test failures https://bugs.ruby-lang.org/issues/16492#change-104462 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * Assignee: jaruga (Jun Aruga) * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Building Ruby packages on Fedora, in 90% of cases, I observe the following error on s390: ~~~ 1) Error: TestBugReporter#test_bug_reporter_add: Timeout::Error: execution of assert_in_out_err expired timeout (10 sec) pid 2061293 killed by SIGKILL (signal 9) | | -:1: [BUG] Segmentation fault at 0x001f73ed000003e8 | ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] | | -- Control frame information ----------------------------------------------- | c:0003 p:---- s:0012 e:000011 CFUNC :kill | c:0002 p:0021 s:0006 e:000005 EVAL -:1 [FINISH] | c:0001 p:0000 s:0003 E:000430 (none) [FINISH] | | -- Ruby level backtrace information ---------------------------------------- | -:1:in `<main>' | -:1:in `kill' | | -- Other runtime information ----------------------------------------------- | | * Loaded script: - | | * Loaded features: | | 0 enumerator.so | 1 thread.rb | 2 rational.so | 3 complex.so | 4 ruby2_keywords.rb | 5 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 6 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 7 /builddir/build/BUILD/ruby-2.7.0/abrt.rb | 8 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | | * Process memory map: | | 2aa27a00000-2aa27a01000 r-xp 00000000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa27a01000-2aa27a02000 r--p 00000000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa27a02000-2aa27a03000 rw-p 00001000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa28a7e000-2aa28bfe000 rw-p 00000000 00:00 0 [heap] | 3ff9ff80000-3ff9ff81000 r-xp 00000000 fc:03 1844756 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | 3ff9ff81000-3ff9ff82000 r--p 00000000 fc:03 1844756 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | 3ff9ff82000-3ff9ff83000 rw-p 00000000 00:00 0 | 3ffa0000000-3ffa0002000 r-xp 00000000 fc:03 1844387 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 3ffa0002000-3ffa0003000 r--p 00001000 fc:03 1844387 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 3ffa0003000-3ffa0004000 rw-p 00000000 00:00 0 | 3ffa0036000-3ffa0037000 ---p 00000000 00:00 0 | 3ffa0037000-3ffa0078000 rw-p 00000000 00:00 0 | 3ffa0078000-3ffa0079000 ---p 00000000 00:00 0 | 3ffa0079000-3ffa00ba000 rw-p 00000000 00:00 0 | 3ffa00ba000-3ffa00bb000 ---p 00000000 00:00 0 | 3ffa00bb000-3ffa00fc000 rw-p 00000000 00:00 0 | 3ffa00fc000-3ffa00fd000 ---p 00000000 00:00 0 | 3ffa00fd000-3ffa013e000 rw-p 00000000 00:00 0 | 3ffa013e000-3ffa013f000 ---p 00000000 00:00 0 | 3ffa013f000-3ffa0180000 rw-p 00000000 00:00 0 | 3ffa0180000-3ffa0181000 ---p 00000000 00:00 0 | 3ffa0181000-3ffa01c2000 rw-p 00000000 00:00 0 | 3ffa01c2000-3ffa01c3000 ---p 00000000 00:00 0 | 3ffa01c3000-3ffa0204000 rw-p 00000000 00:00 0 | 3ffa0204000-3ffa0205000 ---p 00000000 00:00 0 | 3ffa0205000-3ffa0246000 rw-p 00000000 00:00 0 | 3ffa0246000-3ffa0247000 ---p 00000000 00:00 0 | 3ffa0247000-3ffa0288000 rw-p 00000000 00:00 0 | 3ffa0288000-3ffa0289000 ---p 00000000 00:00 0 | 3ffa0289000-3ffa02ca000 rw-p 00000000 00:00 0 | 3ffa02ca000-3ffa02cb000 ---p 00000000 00:00 0 | 3ffa02cb000-3ffa030c000 rw-p 00000000 00:00 0 | 3ffa030c000-3ffa030d000 ---p 00000000 00:00 0 | 3ffa030d000-3ffa034e000 rw-p 00000000 00:00 0 | 3ffa034e000-3ffa034f000 ---p 00000000 00:00 0 | 3ffa034f000-3ffa0390000 rw-p 00000000 00:00 0 | 3ffa0390000-3ffa0391000 ---p 00000000 00:00 0 | 3ffa0391000-3ffa03d2000 rw-p 00000000 00:00 0 | 3ffa03d2000-3ffa03d3000 ---p 00000000 00:00 0 | 3ffa03d3000-3ffa0414000 rw-p 00000000 00:00 0 | 3ffa0414000-3ffa0415000 ---p 00000000 00:00 0 | 3ffa0415000-3ffa0456000 rw-p 00000000 00:00 0 | 3ffa0456000-3ffa0457000 ---p 00000000 00:00 0 | 3ffa0457000-3ffa0498000 rw-p 00000000 00:00 0 | 3ffa0498000-3ffa0499000 ---p 00000000 00:00 0 | 3ffa0499000-3ffa04da000 rw-p 00000000 00:00 0 | 3ffa04da000-3ffa04db000 ---p 00000000 00:00 0 | 3ffa04db000-3ffa051c000 rw-p 00000000 00:00 0 | 3ffa051c000-3ffa051d000 ---p 00000000 00:00 0 | 3ffa051d000-3ffa055e000 rw-p 00000000 00:00 0 | 3ffa055e000-3ffa055f000 ---p 00000000 00:00 0 | 3ffa055f000-3ffa05a0000 rw-p 00000000 00:00 0 | 3ffa05a0000-3ffa05a1000 ---p 00000000 00:00 0 | 3ffa05a1000-3ffa05e2000 rw-p 00000000 00:00 0 | 3ffa05e2000-3ffa05e3000 ---p 00000000 00:00 0 | 3ffa05e3000-3ffa0624000 rw-p 00000000 00:00 0 | 3ffa0624000-3ffa0625000 ---p 00000000 00:00 0 | 3ffa0625000-3ffa0666000 rw-p 00000000 00:00 0 | 3ffa0666000-3ffa0667000 ---p 00000000 00:00 0 | 3ffa0667000-3ffa06a8000 rw-p 00000000 00:00 0 | 3ffa06a8000-3ffa06a9000 ---p 00000000 00:00 0 | 3ffa06a9000-3ffa06ea000 rw-p 00000000 00:00 0 | 3ffa06ea000-3ffa06eb000 ---p 00000000 00:00 0 | 3ffa06eb000-3ffa072c000 rw-p 00000000 00:00 0 | 3ffa072c000-3ffa072d000 ---p 00000000 00:00 0 | 3ffa072d000-3ffa076e000 rw-p 00000000 00:00 0 | 3ffa076e000-3ffa076f000 ---p 00000000 00:00 0 | 3ffa076f000-3ffa07b0000 rw-p 00000000 00:00 0 | 3ffa07b0000-3ffa07b1000 ---p 00000000 00:00 0 | 3ffa07b1000-3ffa07f2000 rw-p 00000000 00:00 0 | 3ffa07f2000-3ffa07f3000 ---p 00000000 00:00 0 | 3ffa07f3000-3ffa0834000 rw-p 00000000 00:00 0 | 3ffa0834000-3ffa0835000 ---p 00000000 00:00 0 | 3ffa0835000-3ffa2980000 rw-p 00000000 00:00 0 | 3ffa2980000-3ffa2a17000 r-xp 00000000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a17000-3ffa2a18000 r--p 00096000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a18000-3ffa2a19000 rw-p 00097000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a80000-3ffa2ab2000 r-xp 00000000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab2000-3ffa2ab3000 ---p 00032000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab3000-3ffa2ab4000 r--p 00032000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab4000-3ffa2abd000 rw-p 00000000 00:00 0 | 3ffa2b00000-3ffa2b03000 r-xp 00000000 fc:03 1813826 /usr/lib64/libdl-2.30.9000.so | 3ffa2b03000-3ffa2b04000 r--p 00002000 fc:03 1813826 /usr/lib64/libdl-2.30.9000.so | 3ffa2b04000-3ffa2b05000 rw-p 00000000 00:00 0 | 3ffa2b80000-3ffa2c05000 r-xp 00000000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c05000-3ffa2c07000 r--p 00084000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c07000-3ffa2c08000 rw-p 00086000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c80000-3ffa2c88000 r-xp 00000000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2c88000-3ffa2c89000 r--p 00007000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2c89000-3ffa2c8a000 rw-p 00008000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2d00000-3ffa2d1e000 r-xp 00000000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d1e000-3ffa2d1f000 r--p 0001d000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d1f000-3ffa2d20000 rw-p 0001e000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d20000-3ffa2d24000 rw-p 00000000 00:00 0 | 3ffa2d80000-3ffa2f1e000 r-xp 00000000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f1e000-3ffa2f22000 r--p 0019d000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f22000-3ffa2f25000 rw-p 001a1000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f25000-3ffa2f28000 rw-p 00000000 00:00 0 | 3ffa2f80000-3ffa2f82000 r-xp 00000000 fc:03 1844333 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 3ffa2f82000-3ffa2f83000 r--p 00001000 fc:03 1844333 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 3ffa2f83000-3ffa2f84000 rw-p 00000000 00:00 0 | 3ffa3000000-3ffa336e000 r-xp 00000000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa336e000-3ffa3377000 r--p 0036d000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa3377000-3ffa3378000 rw-p 00376000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa3378000-3ffa338f000 rw-p 00000000 00:00 0 | 3ffa3400000-3ffa3426000 r-xp 00000000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3426000-3ffa3427000 r--p 00025000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3427000-3ffa3428000 rw-p 00026000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3428000-3ffa3429000 rw-p 00000000 00:00 0 | 3ffa3476000-3ffa347e000 rw-p 00000000 00:00 0 | 3ffa347e000-3ffa3480000 r-xp 00000000 00:00 0 [vdso] | 3ffc5301000-3ffc5b00000 rw-p 00000000 00:00 0 [stack] | | | Sample bug reporter: 12345 /builddir/build/BUILD/ruby-2.7.0/test/-ext-/bug_reporter/test_bug_reporter.rb:22:in `test_bug_reporter_add' Finished tests in 544.051367s, 38.5515 tests/s, 4998.1953 assertions/s. 20974 tests, 2719275 assertions, 0 failures, 1 errors, 68 skips ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] ~~~ Since the default timeout is 10s, I tried to increase the timeout to 30s via simple `sed -i '/assert_in_out_err/ s/)/, timeout: 30)/' test/-ext-/bug_reporter/test_bug_reporter.rb` and this seems to help to avoid this issue. However, I am not really sure why s390x is so slow handling this test case :/ ---Files-------------------------------- 0001-Timeout-the-test_bug_reporter_add-witout-raising-err.patch (1.45 KB) Time.png (56 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114627] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by byroot (Jean Boussier) 05 Sep '23

05 Sep '23

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/

1 0

[ruby-core:114626] [Ruby master Bug#18080] Syntax error on one-line pattern matching
by yui-knk (Kaneko Yuichiro) 04 Sep '23

04 Sep '23

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/

1 0

[ruby-core:111499] [Ruby master Bug#19281] SyntaxError if first argument of command call has semicolon inside parenthesis
by tompng (tomoya ishida) 04 Sep '23

04 Sep '23

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/

3 2

[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