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

[ruby-core:114675] [Ruby master Feature#19871] Add __owner__
by konsolebox (K B) 12 Sep '23

12 Sep '23

Issue #19871 has been reported by konsolebox (K B). ---------------------------------------- Feature #19871: Add __owner__ https://bugs.ruby-lang.org/issues/19871 * Author: konsolebox (K B) * Status: Open * Priority: Normal ---------------------------------------- Which will give the owner of the currently executing method. `method(__method__).owner` or `method(__callee__).owner` isn't enough since it may return a different owner if the method is overridden. Relying on calling the name of its owner is also theoretically not reliable since the constant can be overshadowed and it makes code less portable when moving it from one namespace to another. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:114446] [Ruby master Bug#19844] Ruby 3.2 fails to build with openssl version 3
by narine_moss＠yahoo.com (Narine Mossikyan) 12 Sep '23

12 Sep '23

Issue #19844 has been reported by narine_moss(a)yahoo.com (Narine Mossikyan). ---------------------------------------- Bug #19844: Ruby 3.2 fails to build with openssl version 3 https://bugs.ruby-lang.org/issues/19844 * Author: narine_moss(a)yahoo.com (Narine Mossikyan) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby version 3.2 code base: https://github.com/ruby/ruby/tree/1c7624469880bcb964be09a49e4907873f45b026 openssl v3 is installed under /usr/local_ssl_3.0.0. ./configure --with-openssl-dir=/usr/local_ssl_3.0.0 I get the following error when running make: openssl_missing.c:24:13: error: dereferencing pointer to incomplete type ‘X509_CRL {aka const struct X509_crl_st}’ *psig = crl->signature; ^~ openssl_missing.c: In function ‘ossl_X509_REQ_get0_signature’: openssl_missing.c:36:13: error: dereferencing pointer to incomplete type ‘X509_REQ {aka const struct X509_req_st}’ *psig = req->signature; ^~ I am trying to build ruby 3.2 with openssl version 3 to install it on ubuntu 22 that only has openssl v3. Can you advise me how to configure ruby to bypass this error? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114682] [Ruby master Feature#19075] Binary searching for the last element
by mame (Yusuke Endoh) 12 Sep '23

12 Sep '23

Issue #19075 has been updated by mame (Yusuke Endoh). I think the workaround is good enough. Do you have a good use case to introduce this? The proposed behavior is not something that can simply be called "last". The traditional behavior requires a given block to return `false` for elements in the first half and `true` for elements in the second half. On the other hand, this proposal requires it to return `true` for the first half and `false` for the second half. The name `bsearch_last` is never clear enough to me for this behavior. `bsearch_rindex` and `rbsearch` are not good either. `bsearch` is confusing, and this proposed mode is even more confusing. I don't think it is a good idea to make this mode selectable by a keyword argument. ---------------------------------------- Feature #19075: Binary searching for the last element https://bugs.ruby-lang.org/issues/19075#change-104510 * 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:114681] [Ruby master Bug#19873] Thread#native_thread_id is incorrectly cached across fork on Linux
by kjtsanaktsidis (KJ Tsanaktsidis) 12 Sep '23

12 Sep '23

Issue #19873 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #19873: Thread#native_thread_id is incorrectly cached across fork on Linux https://bugs.ruby-lang.org/issues/19873 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- On Linux, when a process forks, the native thread ID of the (only) thread in the forked child should change. ``` >> libc = Fiddle.dlopen(nil) => #<Fiddle::Handle:0x0000ffffb0d8e900> >> gettid = Fiddle::Function.new(libc['gettid'], [], Fiddle::TYPE_INT) => #<Fiddle::Function:0x0000ffffb15d1130 ... >> gettid.call => 33 >> fork { puts gettid.call }; nil; => nil 36 ``` However, the value of `Thread#native_thread_id` is (incorrectly) still set to the old value. ``` >> Thread.current.native_thread_id => 33 >> fork { puts Thread.current.native_thread_id }; nil; => nil 33 ``` I think `#native_thread_id` should be re-fetched from the operating system via `gettid(2)` after fork. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114674] [Ruby master Misc#19870] Why is a long-run thread allocated more memory than a short-run one?
by caracal (Taishi Kasuga) 10 Sep '23

10 Sep '23

Issue #19870 has been reported by caracal (Taishi Kasuga). ---------------------------------------- Misc #19870: Why is a long-run thread allocated more memory than a short-run one? https://bugs.ruby-lang.org/issues/19870 * Author: caracal (Taishi Kasuga) * Status: Open * Priority: Normal ---------------------------------------- I want to write multithreading programing in Ruby but I found the following memory consumptions. ``` $ irb irb(main):001> require 'objspace' => true irb(main):002> t1 = Thread.new {} => #<Thread:0x00007f9237a74b28 (irb):2 run> irb(main):003> t2 = Thread.new { sleep 6000 } => #<Thread:0x00007f9237b4f1d8 (irb):3 run> irb(main):004> t3 = Thread.new { loop { sleep 5 } } => #<Thread:0x00007f9237b6d840 (irb):4 run> irb(main):005> ObjectSpace.memsize_of(t1) => 360 irb(main):006> ObjectSpace.memsize_of(t2) => 1048936 irb(main):007> ObjectSpace.memsize_of(t3) => 1048936 irb(main):008> ``` Is the above behavior legitimate? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114310] [Ruby master Bug#19788] Ripper returns a symbol instead of a token as operator for "::"
by thyresias (Thierry Lambert) 09 Sep '23

09 Sep '23

Issue #19788 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #19788: Ripper returns a symbol instead of a token as operator for "::" https://bugs.ruby-lang.org/issues/19788 * 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 ---------------------------------------- ```ruby require 'ripper' 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 require 'pp' BasicParser.new('a&.b').parse # in stdout: # ident(["a"]) # op(["&."]) # vcall([[:ident, "a"]]) # ident(["b"]) # call([[:vcall, [:ident, "a"]], [:op, "&."], [:ident, "b"]]) BasicParser.new('a::b').parse # in stdout: # ident(["a"]) # op(["::"]) # vcall([[:ident, "a"]]) # ident(["b"]) # call([[:vcall, [:ident, "a"]], :"::", [:ident, "b"]]) ``` On the last line, consistent with `&.`, I would have expected: ```ruby # call([[:vcall, [:ident, "a"]], [:op, "::"], [:ident, "b"]]) ``` This is true for the "operator" argument of `call`, `command_call` and `field`. Is it intended? -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114380] [Ruby master Bug#19837] Concurrent calls to Process.waitpid2 misbehave on Ruby 3.1 & 3.2
by kjtsanaktsidis (KJ Tsanaktsidis) 09 Sep '23

09 Sep '23

Issue #19837 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #19837: Concurrent calls to Process.waitpid2 misbehave on Ruby 3.1 & 3.2 https://bugs.ruby-lang.org/issues/19837 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.4p236 (2023-07-26 revision a8670865c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- On Ruby 3.1 & 3.2, if you have one thread blocked into a directed call to `Process.waitpid2` with a pid specified, a concurrent call to `Process.waitpid2 -1` will not be able to find & reap any other terminated child process, even one with a different pid that is not individually being waited on. I've attached a Ruby program which should terminate but doesn't as a result of this bug, as well as a C program which demonstrates that the underlying syscalls (at least on Linux) do behave how you would expect. My reproduction creates two processes; a long-running process that does not exit, and a short one which does. There is a background thread calling `Process.waitpid2` on the long process. Then, a concurrent call to `Process.waitpid2 -1` does not notice that the short-running process has exited. My `wait_bug.rb` program _does_ work properly and terminate on the current master branch of Ruby; I assume this is because all of the MJIT-related process management stuff with the waiting_pids & stuff has been cleaned up as part of the MJIT -> RJIT refactoring. Because of this, I'm not sure exactly how to make a patch; should I open a pair of PRs targeting the `ruby_3_2` and `ruby_3_1` branch? Thanks! ---Files-------------------------------- wait_bug.c (1.55 KB) wait_bug.rb (735 Bytes) -- https://bugs.ruby-lang.org/

4 6

[ruby-core:114669] [Ruby master Bug#19869] Mark skipped test somehow
by vo.x (Vit Ondruch) 08 Sep '23

08 Sep '23

Issue #19869 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19869: Mark skipped test somehow https://bugs.ruby-lang.org/issues/19869 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-09-05 master 7c8932365f) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When Minitest was used to execute the Ruby test suite, skipped test were cleanly marked, e.g.: ~~~ [14036/25715] TestGemExtCmakeBuilder#test_self_build_has_makefile = s ~~~ However, with the test-unit the output is: ~~~ [14036/25715] TestGemExtCmakeBuilder#test_self_build_has_makefile = 0.01 s ~~~ This is problematic, because running test suite, I can see that some test were skipped: ~~~ 25705 tests, 6108213 assertions, 0 failures, 0 errors, 99 skips ~~~ But I can't tell which. Is there a chance to fix this? -- https://bugs.ruby-lang.org/

1 1

[ruby-core:114668] [Ruby master Bug#19868] `Process::Status` methods for compatibility with `Fixnum`
by nobu (Nobuyoshi Nakada) 07 Sep '23

07 Sep '23

Issue #19868 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19868: `Process::Status` methods for compatibility with `Fixnum` https://bugs.ruby-lang.org/issues/19868 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Looking at commit:54274b8c65a0981f1c69055a1513ba3c614dd675, noticed that `pst_rshift` contains shift by a negative integer, an unspecified behavior in C99. I think an exception would be ok for such argument, also we can suggest alternative methods to encourage the transition. https://github.com/nobu/ruby/tree/process_status-fixnum-compatibility -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114662] [Ruby master Bug#19867] Unicode line and paragraph separator are not stripped
by iainbeeston (Iain Beeston) 06 Sep '23

06 Sep '23

Issue #19867 has been reported by iainbeeston (Iain Beeston). ---------------------------------------- Bug #19867: Unicode line and paragraph separator are not stripped https://bugs.ruby-lang.org/issues/19867 * Author: iainbeeston (Iain Beeston) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Unicode newline and paragraph separators are not removed by any of the strip methods: `"\u2028\u2029\u0000\t\n\v\f\r ".strip # => "\u2028\u2029"` I would have expected `strip` (and `lstrip`, `rstrip`) to remove unicode whitespace as well. It looks like #7154 reported something similar but for regular expressions and way back In ruby 1.9. I think that fixing this should be simple (just checking for `\x2028` and `\x2029` in ctype.h) but I'm not sure if it's supposed to behave this way or if changing it could introduce unexpected consequences. -- https://bugs.ruby-lang.org/

2 3