- ruby-core - ml.ruby-lang.org

[ruby-core:113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification
by kyanagi (Kouhei Yanagita) 30 Nov '23

30 Nov '23

Issue #19588 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Feature #19588: Allow Comparable#clamp(min, max) to accept nil as a specification https://bugs.ruby-lang.org/issues/19588 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- `Comparable#clamp(min, max)` (with two arguments) accepts `nil`. This behaves the same as beginless/endless Range. ~~~ruby 5.clamp(nil, 0) # => 0 5.clamp(10, nil) # => 10 5.clamp(..0) # => 0 5.clamp(10..) # => 10 ~~~ This behavior is not documented. Presumably, this was not introduced intentionally. The old Rubies did not accept accept a `Range` argument. In Ruby 2.7, accepting `Range` as an argument was introduced. At that time, the approach of passing `nil` as a two-argument method was also discussed but not adopted, and using Range was chosen instead. https://bugs.ruby-lang.org/issues/14784 However, in Ruby 3.0, the behavior of `clamp` has changed to accept `nil`. This change is not documented in the NEWS or the documentation for `clamp`, and I believe that it was not an intentional change. ~~~ % docker run -it --rm rubylang/all-ruby env ALL_RUBY_SINCE=ruby-2.4.0 ./all-ruby -e "p 5.clamp(0, nil)" ruby-2.4.0 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ... ruby-2.7.8 -e:1:in `clamp': comparison of Integer with nil failed (ArgumentError) from -e:1:in `<main>' exit 1 ruby-3.0.0-preview1 5 ... ruby-3.2.2 5 ~~~ It seems that https://github.com/ruby/ruby/commit/a93da4970be44a473b7b42e7516eb2663dece2c3 brought about this change. How about making the current behavior a specification? It has been three years since the behavior changed, and I don't see much point in prohibiting `nil` now. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:115071] [Ruby master Misc#19931] to_int is not for implicit conversion?
by Dan0042 (Daniel DeLorme) 29 Nov '23

29 Nov '23

Issue #19931 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Misc #19931: to_int is not for implicit conversion? https://bugs.ruby-lang.org/issues/19931 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- While reviewing some implicit vs explicit conversion concepts, I discovered that arithmetic operations do not perform the implicit conversion I expected from #to_int ```ruby o = Object.new def o.to_int; 1; end 1 + o #TypeError ``` I understand there's the whole #coerce thing for numbers, but I had expected #to_int to fit neatly into this and cause the object to be implicitly coerced to Integer. So basically I thought that #to_i was for explicit conversion and #to_int for implicit conversion; is that not the case? Most of the internet seems to think that (to_int : to_i) relationship is like (to_str : to_s). But I can't seems to find authoritative documentation on the topic. -- https://bugs.ruby-lang.org/

9 15

[ruby-core:115517] [Ruby master Bug#20026] Ruby doesn't throw a syntax error when rescuing with ||
by arian (Arian Faurtosh) 29 Nov '23

29 Nov '23

Issue #20026 has been reported by arian (Arian Faurtosh). ---------------------------------------- Bug #20026: Ruby doesn't throw a syntax error when rescuing with || https://bugs.ruby-lang.org/issues/20026 * Author: arian (Arian Faurtosh) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- We had a coworker new to ruby try an interesting syntax for rescue that doesn't result in a syntax error, and works partially. Why does ruby allow the logical OR || operator, is there a purpose for this? If not this feels like it should be a syntax error, instead of resulting in partially working code. ``` ruby class FooError < StandardError; end class BarError < StandardError; end # works begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end # doesn't work begin raise FooError rescue FooError || BarError => e puts "rescued #{e.class}" end ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115519] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by jeremyevans0 (Jeremy Evans) 28 Nov '23

28 Nov '23

Issue #18886 has been updated by jeremyevans0 (Jeremy Evans). mame (Yusuke Endoh) wrote in #note-7: > @jeremyevans0 Could you measure the overhead? Using the benchmark in the pull request, the pull request seems reliably ~5% faster in my testing for the member reader method, but mixed for other cases (sometimes up to 3% faster/slower depending on run). I don't have any explanation as to why it would be faster, so I'm going to assume that the difference is still within the margin of error. I don't think this will affect performance unless TracePoint is used, because the same method caching is done in both cases. ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105448 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115502] [Ruby master Bug#8299] Minor error in float parsing
by naruse (Yui NARUSE) 28 Nov '23

28 Nov '23

Issue #8299 has been updated by naruse (Yui NARUSE). Status changed from Assigned to Closed hdtoa has the rounding logic, but it doesn't work well on x87, but no one use x87 now. This issue is resolved. ---------------------------------------- Bug #8299: Minor error in float parsing https://bugs.ruby-lang.org/issues/8299#change-105431 * Author: bobjalex (Bob Alexander) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: trunk ---------------------------------------- I encountered a float that either parses [slightly] differently (or converts to string differently) in Ruby than it does in Python or Java. This looks like a Ruby bug since the result "looks" incorrect. It is easily reproduced by entering the magic number (-1.1505945E-5) into irb. It behaves the same in 2.0 and 1.9. I'm using Windows. Below is an irb session that demonstrates. Also included are JRuby and Python trials that show better behavior. This issue is not causing me any problems, but just in case someone there is interested in looking into it... Bob >ruby -v ruby 2.0.0p0 (2013-02-24) [i386-mingw32] >irb irb(main):001:0> RUBY_VERSION => "2.0.0" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 >ruby19 -v ruby 1.9.3p392 (2013-02-22) [i386-mingw32] >irb19 irb(main):001:0> RUBY_VERSION => "1.9.3" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 irb(main):002:0> >jirb irb(main):001:0> -1.1505945E-5 => -1.1505945e-05 >python Python 2.7.4rc1 (default, Mar 24 2013, 14:34:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> -1.1505945E-5 -1.1505945e-05 >>> repr(-1.1505945E-5) '-1.1505945e-05' -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115355] [Ruby master Bug#20003] Array#rassoc does not preform implicit conversion
by temabolshakov (Tema Bolshakov) 28 Nov '23

28 Nov '23

Issue #20003 has been reported by temabolshakov (Tema Bolshakov). ---------------------------------------- Bug #20003: Array#rassoc does not preform implicit conversion https://bugs.ruby-lang.org/issues/20003 * Author: temabolshakov (Tema Bolshakov) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is a difference between behaviour of Array#assoc and Array#rassoc. The first one performs implicit conversion (calls #to_ary) while the former does not. ``` ruby class ArrayConvertible def initialize(*values) @values = values; end def to_ary @values end end s1 = [1, 2] s2 = ArrayConvertible.new(2, 3) a = [s1, s2] ``` The `a.assoc(2)` call returns `[2, 3]` as expected. However, `a.rassoc(3)` returns `nil` **Expected behaviour**: `a.rassoc(3)` returns `[2, 3]` in such cases. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115499] [Ruby master Bug#9189] Build failure on Windows in case of nonascii TEMP environment.
by nobu (Nobuyoshi Nakada) 28 Nov '23

28 Nov '23

Issue #9189 has been updated by nobu (Nobuyoshi Nakada). Backport changed from 1.9.3: DONTNEED, 2.0.0: REQUIRED to 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN pcai (Peter Cai) wrote in #note-13: > I'm unable to reproduce. Windows presents an ascii-safe alias of the TEMP folder for me so I can't seem to test the handling: Thank you for testing. Does it work after `set TEMP=C:\Users\희섭\tmp`? ---------------------------------------- Bug #9189: Build failure on Windows in case of nonascii TEMP environment. https://bugs.ruby-lang.org/issues/9189#change-105428 * Author: phasis68 (Heesob Park) * Status: Assigned * Priority: Normal * ruby -v: ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I experienced a build failure during build extension library with trunk on Windows. make[2]: Entering directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' generating bigdecimal-i386-mingw32.def compiling bigdecimal.c In file included from bigdecimal.c:20:0: bigdecimal.h:62:1: error: static declaration of 'labs' follows non-static declar ation make[2]: *** [bigdecimal.o] Error 1 make[2]: Leaving directory `/c/work/ruby-2.1.0-r43936/ext/bigdecimal' make[1]: *** [ext/bigdecimal/all] Error 2 make[1]: Leaving directory `/c/work/ruby-2.1.0-r43936' make: *** [build-ext] Error 2 I found the cause of this error is mkmk failure. Here is a part of mkmf.log have_func: checking for labs() in stdlib.h... -------------------- no "i686-w64-mingw32-gcc -o conftest.exe -I../../.ext/include/i386-mingw32 -I../.././include -I../.././ext/bigdecimal -D_WIN32_WINNT=0x0501 -D_FILE_OFFSET_BITS=64 -O3 -fno-omit-frame-pointer -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wimplicit-function-declaration conftest.c -L. -L../.. -L. -lmsvcrt-ruby210-static -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi " This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Cannot create temporary file in C:\Users\??苑?AppData\Local\Temp\: Invalid argument The TEMP environment varable is C:\work\ruby-2.1.0-r43936>set TEMP TEMP=C:\Users\희섭\AppData\Local\Temp It seems that miniruby cannot handle encoding properly. C:\work\ruby-2.1.0-r43936>miniruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] "C:\\Users\\\xED\x9D\xAC\xEC\x84\xAD\\AppData\\Local\\Temp" C:\work\ruby-2.1.0-r43936>miniruby.exe -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43936) [i386-mingw32] #<Encoding:ASCII-8BIT> Whereas, the final ruby can handle encoding properly. C:\work>ruby -ve "p ENV['TEMP']" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] "C:\\Users\\희섭\\AppData\\Local\\Temp" C:\work>ruby -ve "p ENV['TEMP'].encoding" ruby 2.1.0dev (2013-11-30 trunk 43923) [i386-mingw32] #<Encoding:CP949> -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115498] [Ruby master Feature#18551] Make `Range#reverse_each` to raise an exception if endless
by mame (Yusuke Endoh) 28 Nov '23

28 Nov '23

Issue #18551 has been updated by mame (Yusuke Endoh). In the previous dev meething, matz accepted this. I will merge the PR ---------------------------------------- Feature #18551: Make `Range#reverse_each` to raise an exception if endless https://bugs.ruby-lang.org/issues/18551#change-105427 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal ---------------------------------------- https://github.com/ruby/ruby/pull/5498 Currently, `Range#reverse_each` for an endless range never returns. ``` % ruby -e '(1..).reverse_each { }' # never return ... ``` (This is because `Enumerable#reverse_each` tries `#to_a` and `#to_a` for an endless range comes into an infinite loop.) I think `Range#reverse_each` for an endless range should raise an exception, similar to `Range#each` for a beginless range. ``` % ruby -e '(..1).each { }' -e:1:in `each': can't iterate from NilClass (TypeError) from -e:1:in `<main>' ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115483] [Ruby master Bug#20021] TestGCCompact#test_moving_hashes_down_size_pools is flaky
by kjtsanaktsidis (KJ Tsanaktsidis) 27 Nov '23

27 Nov '23

Issue #20021 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20021: TestGCCompact#test_moving_hashes_down_size_pools is flaky https://bugs.ruby-lang.org/issues/20021 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The test `TestGCCompact#test_moving_hashes_down_size_pools is flaky` is, I believe, flaky, and sometimes fails with this message: ``` 1) Failure: TestGCCompact#test_moving_hashes_down_size_pools [/home/chkbuild/chkbuild/tmp/build/20231112T183003Z/ruby/test/ruby/test_gc_compact.rb:442]: Expected 499 to be >= 500. ``` I started looking at this because when https://github.com/ruby/ruby/pull/8858 was merged, rubyci began failing on Ubuntu 22.04 with this message (https://rubyci.s3.amazonaws.com/ubuntu2204/ruby-master/log/20231112T183003Z…) I was able to reproduce this failure after _very_ carefully reproducing the ruibyci testing environment (same EC2 instance type, and I actually had to install _exactly_ the same kernel version as well!). After debugging the test, what I discovered is that the _last_ hash that was modified in the test is actually on the machine stack when `GC.verify_compaction_references` is called, which means it gets pinned and cannot be moved; thus, the test fails because only 499 out of 500 objects got moved! The hash's VALUE is "on the stack" in the sense that it's in a memory location below `%rsp`, but it is _NOT_ actually live in any C local variable. The stack address I found the VALUE in is part of the frame of `gc_start`, but `gc_start` obviously doesn't hold a reference to the hash from the test. Rather, it's left-behind in uninitialized memory. I think this is made more likely because of how GCC wound up compiling the `gc_start` function. It seems to have allocated quite a lot of stack space - 440 bytes of it - and very little of it seems to be used for local variables. Thus, a lot of this memory just contains assorted tidbits from previous VM execution state. This patch works around the issue, at least on my testbench, by running the code which touches the test hashes in a separate fiber. Each fiber gets its own machine stack, so references to the to-be-moved hashes shouldn't leak into the main stack, and this fiber's stack should be out of scope when the compaction is run, so it should get freed. https://github.com/ruby/ruby/pull/9040 The other approach I considered is counting the number of pinned objects, and asserting that (moved + pinned) >= 500 instead of just moved >= 500. However, it's very likely that there will be a pinned hash (or string, etc, for the other, similar test cases), so this would make the test pass even when it should not, I think. Also, since this these tests were skipped on Solaris because of this bug, I have unskipped them (although it seems we no longer have solaris on ruby ci, so I guess it doesn't matter). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115494] [Ruby master Bug#18886] Struct aref and aset don't trigger any tracepoints.
by mame (Yusuke Endoh) 27 Nov '23

27 Nov '23

Issue #18886 has been updated by mame (Yusuke Endoh). @jeremyevans0 Could you measure the overhead? ---------------------------------------- Bug #18886: Struct aref and aset don't trigger any tracepoints. https://bugs.ruby-lang.org/issues/18886#change-105423 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Given the following program, `thing.name` and `thing.shape` don't trigger `c_call` trace points (or any trace points actually). ```ruby pp RUBY_VERSION trace_point = TracePoint.new(:line, :call, :c_call, :a_call) do |trace| puts trace.event if trace.event == :call # Ruby doesn't always mark call-sites in sub-expressions, so we use this approach to compute a call site and mark it: if location = caller_locations(2, 1).first and path = location.path puts "> #{path}:#{location.lineno}:#{trace.event}" end end if path = trace.path puts "= #{path}:#{trace.lineno}:#{trace.event}" end end trace_point.enable # This will trigger call trace points class Thing def name :cat end def shape :square end end thing = Thing.new # Thing = Struct.new(:name, :shape) # thing = Thing.new(:cat, :rectangle) [ name: thing.name, shape: thing.shape, ] ``` ## Current HEAD ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: ``` ## Proposed PR ``` = ../test.rb:30:line: = ../test.rb:30:c_call:new = ../test.rb:30:c_call:inherited = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:singleton_method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:method_added = ../test.rb:30:c_call:const_added = ../test.rb:31:line: = ../test.rb:31:c_call:new = ../test.rb:31:c_call:initialize = ../test.rb:34:line: = ../test.rb:34:c_call:name = ../test.rb:35:c_call:shape ``` The reason is the internal implementation of struct doesn't have trace point instrumentation in `vm_call_opt_struct_aset` or `vm_call_opt_struct_aref`. Proposed fix: https://github.com/ruby/ruby/pull/6071 but this would need a review, maybe @jeremyevans0 and @ko1 can help. -- https://bugs.ruby-lang.org/

1 0