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

[ruby-core:119331] [Ruby master Feature#20768] Add Hash#delete_at
by seanpdoyle (Sean Doyle) 01 Oct '24

01 Oct '24

Issue #20768 has been reported by seanpdoyle (Sean Doyle). ---------------------------------------- Feature #20768: Add Hash#delete_at https://bugs.ruby-lang.org/issues/20768 * Author: seanpdoyle (Sean Doyle) * Status: Open ---------------------------------------- Add `Hash#delete_at` to delete values from a list keyed by its arguments. The interface and return values draw inspiration from [Hash#values_at](https://docs.ruby-lang.org/en/3.3/Hash.html#method-i-values… and [Array#delete_at](https://docs.ruby-lang.org/en/3.3/Array.html#method-i-dele…. It can pair nicely with multiple assignment to deconstruct a `Hash` instance: ```ruby hash = { a: true, b: false } a, c = hash.delete_at(:a, :c) # => [ true, nil ] hash # => { b: false } ``` Similar outcomes can be achieved with rightward assignment: ```ruby hash = { a: true, b: false } hash => { a:, **rest } a # => true rest # => { b: false } ``` However, rightward assignment will raise an error when a key is missing, whereas `Hash#delete_at` could return `nil` or the `Hash#default_value`: ```ruby hash => { c: } # => raises NoMatchingPatternKeyError ``` Similarly, rightward assignment does not mutate the original `Hash` instance. In some circumstances, this is beneficial. However, others that require mutation would involve re-assigning the variable: ```ruby hash => { a:, **hash } a # => true hash # => { b:false } ``` Finally, a block can be passed in the same style as [Hash#delete](https://docs.ruby-lang.org/en/3.3/Hash.html#method-i-delete) to provide a default value: ```ruby attributes = { disabled: true, aria: { label: "label text" } } aria, data = attributes.delete_at(:aria, :data) { Hash.new } attributes # => { disabled: true } aria # => { label: "label text" } data # => {} ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119356] [Ruby master Bug#20773] CI of RHEL8 and Amazon Linux 2 are failed from Sep 26th
by hsbt (Hiroshi SHIBATA) 01 Oct '24

01 Oct '24

Issue #20773 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20773: CI of RHEL8 and Amazon Linux 2 are failed from Sep 26th https://bugs.ruby-lang.org/issues/20773 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- RHEL8 and Amazon Linux 2 are failed with `Cannot allocate memory - fork(2)` from Sep 26th. * http://rubyci.s3.amazonaws.com/rhel8/ruby-master/log/20240926T093004Z.fail.… * http://rubyci.s3.amazonaws.com/amazon2/ruby-master/log/20240926T033004Z.fai… I'm not sure what's the root cause yet. Amazon Linux 2 is resolved with swapon by @mame. These are strange to increase to usage of memory only for some old distribution. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:119329] [Ruby master Bug#20765] Unexpected node type in pattern matching expression: PM_IMPLICIT_REST_NODE evaluating `a=>*,`
by tompng (tomoya ishida) 30 Sep '24

30 Sep '24

Issue #20765 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20765: Unexpected node type in pattern matching expression: PM_IMPLICIT_REST_NODE evaluating `a=>*,` https://bugs.ruby-lang.org/issues/20765 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-27T17:45:22Z master 027ef60500) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ~~~ # ruby --parser=prism -e "a=>*," -e: [BUG] Unexpected node type in pattern matching expression: PM_IMPLICIT_REST_NODE # ruby --parser=parse.y -e "a=>*," -e:1: syntax error, unexpected end-of-input ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119353] [Ruby master Bug#20772] Test with -O3 is flaky
by hsbt (Hiroshi SHIBATA) 30 Sep '24

30 Sep '24

Issue #20772 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20772: Test with -O3 is flaky https://bugs.ruby-lang.org/issues/20772 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I enabled `-O3` build and those tests. But it failed with flaky status. https://github.com/ruby/ruby/actions/runs/11098648054/job/30831665071#step:… ``` [251/251] 53150=test_range worker 53144=test_euc_jp does not respond; SEGV is sent /github/workspace/src/tool/lib/test/unit/parallel.rb:82: [BUG] Segmentation fault at 0x000000000000cf93 ruby 3.4.0dev (2024-09-30T03:03:02Z master 3fe59b04d6) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0009 p:---- s:0055 e:000054 CFUNC :close me: called_id: close, type: cfunc owner class: IO self: (IO) c:0008 p:0039 s:0051 e:000050 RESCUE /github/workspace/src/tool/lib/test/unit/parallel.rb:82 me: called_id: _run_suite, type: iseq owner class: Test::Unit::Worker self: (Test::Unit::Worker)len:31 ptr:0x000056195a0f4d20 lvars: $!: (ThreadError)(embed) len:3 c:0007 p:0296 s:0047 E:002530 METHOD /github/workspace/src/tool/lib/test/unit/parallel.rb:83 me: called_id: _run_suite, type: iseq owner class: Test::Unit::Worker self: (Test::Unit::Worker)len:31 ptr:0x000056195a0f4d20 lvars: suite: TestEUC_JP type: T_SYMBOL test orig_testout: (IO) i: (IO) o: (IO) orig_stdin: (IO) orig_stdout: (IO) th: T_NIL e: T_NIL f: T_NIL s: T_NIL result: T_NIL c:0006 p:0007 s:0030 e:000029 BLOCK /github/workspace/src/tool/lib/test/unit/parallel.rb:24 [FINISH] me: called_id: _run_suites, type: iseq owner class: Test::Unit::Worker self: (Test::Unit::Worker)len:31 ptr:0x000056195a0f4d20 lvars: suite: TestEUC_JP c:0005 p:---- s:0026 e:000025 CFUNC :map me: called_id: map, type: cfunc owner class: Array self: (Array)[E ] len: 1 (embed) c:0004 p:0005 s:0022 e:000021 METHOD /github/workspace/src/tool/lib/test/unit/parallel.rb:23 me: called_id: _run_suites, type: iseq owner class: Test::Unit::Worker self: (Test::Unit::Worker)len:31 ptr:0x000056195a0f4d20 lvars: suites: (Array)[E ] len: 1 (embed) type: T_SYMBOL test c:0003 p:0210 s:0016 E:0011d0 METHOD /github/workspace/src/tool/lib/test/unit/parallel.rb:122 me: called_id: run, type: iseq owner class: Test::Unit::Worker self: (Test::Unit::Worker)len:31 ptr:0x000056195a0f4d20 lvars: args: [E ] len: 0 (embed) buf: (String) len: 60, capa: 135 "run /github/workspace/src/test/ruby/enc/test_euc_jp.rb test " suites: (Array)[E ] len: 59 (embed) err: T_NIL e: T_NIL trace: T_NIL c:0002 p:0051 s:0006 E:001360 EVAL /github/workspace/src/tool/lib/test/unit/parallel.rb:220 [FINISH] self: (embed) len:3 c:0001 p:0000 s:0003 E:000d50 DUMMY [FINISH] self: (embed) len:3 (snip) ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117781] [Ruby master Bug#20472] Ractor support for ** into hash literal
by kddnewton (Kevin Newton) 30 Sep '24

30 Sep '24

Issue #20472 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20472: Ractor support for ** into hash literal https://bugs.ruby-lang.org/issues/20472 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby # shareable_constant_value: experimental_copy a = { "foo" => "bar" } A = { **a } ``` In this example, Ruby fails an assertion and crashes. I think we should either provide support for this, or we should explicitly provide a syntax error indicating that ** isn't allowed in constant writes when ractor pragmas are enabled. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119343] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by mame (Yusuke Endoh) 30 Sep '24

30 Sep '24

Issue #18368 has been updated by mame (Yusuke Endoh). Status changed from Open to Closed I think there is no task in this ticket. Thank you @zverok ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-109954 * Author: zverok (Victor Shepelev) * Status: Closed ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119342] [Ruby master Feature#18423] Installing stable versions like 3.0.3 from source generates fatal error by make
by hsbt (Hiroshi SHIBATA) 30 Sep '24

30 Sep '24

Issue #18423 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed We can't support Solaris anymore. ---------------------------------------- Feature #18423: Installing stable versions like 3.0.3 from source generates fatal error by make https://bugs.ruby-lang.org/issues/18423#change-109953 * Author: dklein (Dmitri Klein) * Status: Closed ---------------------------------------- ``` # make BASERUBY = echo executable host ruby is required. use --with-baseruby option.; false CC = /opt/SUNWspro/bin/CC LD = /usr/ccs/bin/ld LDSHARED = /opt/SUNWspro/bin/CC -G CFLAGS = -g XCFLAGS = -DRUBY_EXPORT -I. -I.ext/include/i386-solaris2.10 -I./include -I. -I./enc/unicode/12.1.0 CPPFLAGS = -D_XOPEN_SOURCE=500 DLDFLAGS = SOLIBS = -lz -lpthread -lrt -lrt -lrt -lsocket -ldl -lcrypt -lm LANG = LC_ALL = LC_CTYPE = MFLAGS = CC: Sun C++ 5.12 SunOS_i386 2011/11/16 compiling vm.c "./include/ruby/backward/cxxanyargs.hpp", line 207: Warning (Anachronism): Formal argument 1 of type extern "C" unsigned long(*)(unsigned long) in call to rb_iterate(extern "C" unsigned long(*)(unsigned long), unsigned long, extern "C" unsigned long(*)(unsigned long,unsigned long,int,const unsigned long*,unsigned long), unsigned long) is being passed unsigned long(*)(unsigned long). ... "./include/ruby/backward/cxxanyargs.hpp", line 648: Error: Template parameter ruby::backward::cxxanyargs::define_method::F requires an expression of type void(*)(const char*,unsigned long(*)(...),int). "./include/ruby/internal/fl_type.h", line 205: Warning: Identifier expected instead of "}". "internal.h", line 16: Error: #error not for C++. *** Error code 2 The following command caused the error: /opt/SUNWspro/bin/CC -g -DRUBY_EXPORT -I. -I.ext/include/i386-solaris2.10 -I./include -I. -I./enc/unicode/12.1.0 -D_XOPEN_SOURCE=500 -o vm.o -c vm.c make: Fatal error: Command failed for target `vm.o' # ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119151] [Ruby master Bug#20729] Test failure with 0fc8422a05 and native mswin environment
by hsbt (Hiroshi SHIBATA) 30 Sep '24

30 Sep '24

Issue #20729 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20729: Test failure with 0fc8422a05 and native mswin environment https://bugs.ruby-lang.org/issues/20729 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I got the following failure with mswin environment. ``` 1) Failure: TestRubyOptions#test_command_line_progname_nonascii [C:/Users/hsbt/DevDrive/github.com/ruby/ruby/test/ruby/test_rubyoptions.rb:1…] [ruby-dev:48752] [Bug #10555] pid 22932 exit 1 | C:\Users\hsbt\DevDrive\github.com\ruby\ruby.build\2022\ruby.exe: No such file or directory -- ��.rb (LoadError) . 1. [1/2] Assertion for "stdout" | <["\x{8198}.rb"]> expected but was | <[]>. 2. [2/2] Assertion for "stderr" | <[]> expected but was | <["C:\\Users\\hsbt\\DevDrive\\github.com\\ruby\\ruby.build\\2022\\ruby.exe: No such file or directory -- \x{8198}.rb (LoadError)"]>. ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:119330] [Ruby master Bug#20766] Endless range rejected inside defs singleton
by tompng (tomoya ishida) 28 Sep '24

28 Sep '24

Issue #20766 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20766: Endless range rejected inside defs singleton https://bugs.ruby-lang.org/issues/20766 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-27T00:58:32Z master 0c25eb4ffe) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- These are syntax error with --parser=parse.y. I think it should be syntax ok. ```ruby def (1...).f; end def (tap{1...}).f; end ``` ruby-3.0: Syntax OK (checked with 3.0.6) ruby-3.1: Syntax Error (checked with 3.1.4) ruby --parser=prism: Syntax OK Pull request: https://github.com/ruby/ruby/pull/11716 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119328] [Ruby master Bug#20764] Forwarding parameter `...` is wrongly allowed in lambda
by tompng (tomoya ishida) 28 Sep '24

28 Sep '24

Issue #20764 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20764: Forwarding parameter `...` is wrongly allowed in lambda https://bugs.ruby-lang.org/issues/20764 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-27T00:58:32Z master 0c25eb4ffe) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- These codes are all syntax error ~~~ruby ->...{} ->(...){} ->(a,...){} ~~~ But these are allowed in --parser=parse.y. It should be syntax error ~~~ruby ->a,...{} ->(a=1,...){} ~~~ ~~~ # ruby --parser=parse.y -e "p ->a,...{}.parameters" [[:opt, :b], [:rest, :*], [:keyrest, :**], [:block, :&]] # ruby --parser=parse.y -e "p ->(a=1,...){}.parameters" [[:opt, :b], [:rest, :*], [:keyrest, :**], [:block, :&]] # ruby --parser=parse.y -e "p ->(a,...){}.parameters" -e:1: syntax error, unexpected ... p ->(a,...){}.parameters ruby: compile error (SyntaxError) ~~~ -- https://bugs.ruby-lang.org/

1 0