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

[ruby-core:114221] [Ruby master Bug#19771] Backport 79a4484, abfac22
by krk (Kerem Kat) 08 Aug '23

08 Aug '23

Issue #19771 has been reported by krk (Kerem Kat). ---------------------------------------- Bug #19771: Backport 79a4484, abfac22 https://bugs.ruby-lang.org/issues/19771 * Author: krk (Kerem Kat) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- * https://github.com/ruby/ruby/commit/79a4484a072e9769b603e7b4fbdb15b1d7eccb15 * https://github.com/ruby/ruby/commit/abfac2222bd51a03ec11b64f4770179cb6d06515 Related backport PR: https://github.com/ruby/ruby/pull/8023 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114342] [Ruby master Feature#19830] Allow `Array#transpose` to take an optional size argument
by tomstuart (Tom Stuart) 04 Aug '23

04 Aug '23

Issue #19830 has been reported by tomstuart (Tom Stuart). ---------------------------------------- Feature #19830: Allow `Array#transpose` to take an optional size argument https://bugs.ruby-lang.org/issues/19830 * Author: tomstuart (Tom Stuart) * Status: Open * Priority: Normal ---------------------------------------- One benefit of supplying an initial value to `Enumerable#inject` is that it avoids an annoying edge case when the collection is empty: ``` >> [1, 2, 3].inject(:+) => 6 # good >> [].inject(:+) => nil # bad >> [].inject(0, :+) => 0 # good ``` A similar edge case exists for `Array#transpose`: ``` >> [[1, :a], [2, :b], [3, :c]].transpose => [[1, 2, 3], [:a, :b, :c]] # good >> [].transpose => [] # bad ``` Although no explicit `nil` is produced here, the subtle problem is that the caller may assume that the result array contains arrays, and that assumption leads to `nil`s in the empty case: ``` >> [[1, :a], [2, :b], [3, :c]].transpose.then { _2.join } => "abc" >> [].transpose.then { _2.join } undefined method `join' for nil:NilClass (NoMethodError) ``` If we allow `Array#transpose` to take an optional argument specifying the size of the result array, we can use this to always return an array of the correct size: ``` >> [[1, :a], [2, :b], [3, :c]].transpose(2) => [[1, 2, 3], [:a, :b, :c]] # good >> [].transpose(2) => [[], []] # good ``` By avoiding an unexpectedly empty result array, we also avoid unexpected downstream `nil`s: ``` >> [[1, :a], [2, :b], [3, :c]].transpose(2).then { _2.join } => "abc" >> [].transpose(2).then { _2.join } => "" ``` Here is a patch which adds an optional argument to `Array#transpose` to support the above usage: https://github.com/ruby/ruby/pull/8167 Something similar was requested eleven years ago in #6852. I believe this feature addresses the problem expressed in that issue without compromising backward compatibility with existing callers of #transpose. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:111740] [Ruby master Bug#19325] Windows support lacking.
by dsisnero (Dominic Sisneros) 03 Aug '23

03 Aug '23

Issue #19325 has been reported by dsisnero (Dominic Sisneros). ---------------------------------------- Bug #19325: Windows support lacking. https://bugs.ruby-lang.org/issues/19325 * Author: dsisnero (Dominic Sisneros) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby's support on windows has always been second class. With some of the recent decisions, windows support is falling even more behind. Recent developments in mjit and yjit that exclude windows are two glaring issues that should be corrected. Googling 'percent of windows vs other operating systems' and it shows windows has a share of 76%. Ceding that users to python and other programming languages has to be one of the reasons python continues get more market share from ruby. With rust having first class windows support and threading support, is there a reason why yjit is not able to work on windows? Also, windows compiler support has matured enough and vcpkg support has evolved enough that it seems it should be possible to finally get a ruby version without having to use msys2. Even Crystal language has a version that runs on windows without needing msys2. -- https://bugs.ruby-lang.org/

9 10

[ruby-core:113096] [Ruby master Feature#19572] Proposal: New TracePoint event for rescued exceptions
by st0012 (Stan Lo) 02 Aug '23

02 Aug '23

Issue #19572 has been reported by st0012 (Stan Lo). ---------------------------------------- Feature #19572: Proposal: New TracePoint event for rescued exceptions https://bugs.ruby-lang.org/issues/19572 * Author: st0012 (Stan Lo) * Status: Open * Priority: Normal ---------------------------------------- **Summary** Support a new `rescue` event type in TracePoint. When the event is triggered, `TracePoint#rescued_exception` can be used to access the exception. **Reason** Currently, TracePoint supports `raise` events, which can be helpful for debugging by showing which exception occurs at which location. By adding a `rescue` event type, we can improve the developer's debugging experience by making it easier to check where an exception is rescued. Currently, the most effective way to check where an exception is rescued involves setting a breakpoint at the exception's raised location and stepping through the code to see whether the debugger stops inside a rescue block. However, this can be a tedious process, especially in large applications with deep call stacks. By using a TracePoint event for rescue, developers can easily track exceptions as they are rescued by adding a few lines of code: ``` TracePoint.trace(:rescue) do |tp| puts "Exception rescued: #{tp.rescued_exception} at #{tp.path}:#{tp.lineno}" end ``` This new TracePoint event will also improve the `ruby/debug`'s [`ExceptionTracer`](https://github.com/ruby/debug/blob/master/lib/debug/tracer.rb#L150-L166) and provide users with a better debugging experience. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:114333] [Ruby master Bug#19795] attr_accessor leading to nil values for re-assignment
by francktrouillez (Franck Trouillez) 02 Aug '23

02 Aug '23

Issue #19795 has been reported by francktrouillez (Franck Trouillez). ---------------------------------------- Bug #19795: attr_accessor leading to nil values for re-assignment https://bugs.ruby-lang.org/issues/19795 * Author: francktrouillez (Franck Trouillez) * 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 ---------------------------------------- ### Steps to reproduce: - Create a class with an `attr_accessor` for an instance variable - Create an instance method that reassign this variable using the current value stored in the variable - Show that the variable is set to nil during the evaluation Code snippet: ``` ruby # attr_accessor_nil.rb class A attr_accessor :a def initialize @a = 1 end def my_method puts "a is '#{a.inspect}' of class '#{a.class}'" a += 1 if a.positive? # use an integer method end end instance = A.new instance.my_method # output: # # a is '1' of class 'Integer' # attr_accessor_nil.rb:12:in `my_method': undefined method `positive?' for nil:NilClass (NoMethodError) # # a += 1 if a.positive? # use an integer method # ^^^^^^^^^^ # from attr_accessor_nil.rb:17:in `<main>' ``` ### Expected behavior `a += 1` should lead to `a` being equal to `1` at the end of the assignment, because `a` was storing `0` previously, as shown by the `puts`. Am I being wrong expecting this result? ### Actual behavior `a += 1` raises an error about `a` being `nil` in the evaluation. ### Further investigation I checked if it was coming from the "instance variable", or about the "attr_accessor" by running the following snippet: Code snippet: ```ruby # attr_accessor_nil.rb class A attr_accessor :a def initialize @a = 0 end def my_method puts "a is '#{a.inspect}' of class '#{a.class}'" @a += 1 # use the instance variable directly, instead of the accessor end end instance = A.new instance.my_method # output: # # a is '1' of class 'Integer' ``` This snippet runs just fine, and no error is raised. ### System configuration Ruby version : 3.2.2 -- https://bugs.ruby-lang.org/

2 3