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

[ruby-core:113112] [Ruby master Bug#19578] abort() shows stack trace when run within rescue clause

by Dan0042 (Daniel DeLorme)

Issue #19578 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Bug #19578: abort() shows stack trace when run within rescue clause https://bugs.ruby-lang.org/issues/19578 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I sometimes use the pattern `print(str) rescue abort` in order to exit without stack trace when the output of a ruby program is interrupted by SIGPIPE, ex: `./printstuff.rb | head` It seems that since ruby 2.7 this results in printing the stack trace. This is not the case when using `abort` by itself. Is this intended? I would expect `abort` to behave much like `exit(1)`, as it always has. -- https://bugs.ruby-lang.org/

1 year, 1 month

3
7
0 0

[ruby-core:113127] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges

by zverok (Victor Shepelev)

Issue #18368 has been updated by zverok (Victor Shepelev). @Dan0042 I don't think that "maintaining compatibility" here is valuable unless proven otherwise (e.g. it is a very common idiom for iterating through strings - while working on this ticket, I found no evidence for that). My reasoning is that it is very confusing when some simple and "math-alike" functionality is specialized for exactly one type. What if some user's type has both T+T and T#succ, should it also maintain "two behaviours depending on argument type"? If not, why? Breaking this particular case has a benefit of clear semantics, explained by one phrase, which never breaks user's mental model with "well, the method does this, but with String boundaries and Int argument it also behaves like that." If we are bold enough to change generic method's semantics (I believe Matz is open to it), maintaining legacy behaviours totally unrelated to the new semantics is a forever burden on the language. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-102662 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- 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 year, 1 month

1
0
0 0

[ruby-core:113064] [Ruby master Bug#19566] OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't

by jgomo3

Issue #19566 has been reported by jgomo3 (Jesús Gómez). ---------------------------------------- Bug #19566: OptionParser::on raises unsupported argument type: URI (ArgumentError) but shouldn't https://bugs.ruby-lang.org/issues/19566 * Author: jgomo3 (Jesús Gómez) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The documentation says > OptionParser comes with a few ready-to-use kinds of type coercion. They are > .. > * URI – Anything accepted by URI.parse > But when I try to use the class `URI` as a coercion class: ``` op = OptionParser.new op.on("--uri URI", URI) ``` I get: `unsupported argument type: URI (ArgumentError)`. The workaround is to register it with `accept`: ``` op = OptionParser.new op.accept(URI, &URI.method(:parse)) op.on("--uri URI", URI) ``` I attached 2 files, the first one `ruby-op-uri-bug.rb` displays the Error. The second one, `ruby-op-uri-workaround.rb` show the proper output. ---Files-------------------------------- ruby-op-uri-bug.rb (340 Bytes) ruby-op-uri-bug-workaround.rb (377 Bytes) -- https://bugs.ruby-lang.org/

1 year, 1 month

3
2
0 0

[ruby-core:113052] [Ruby master Bug#19562] Setting default_(in|ex)ternal encoding after running an Ractor freezes ruby

by larskanis (Lars Kanis)

Issue #19562 has been reported by larskanis (Lars Kanis). ---------------------------------------- Bug #19562: Setting default_(in|ex)ternal encoding after running an Ractor freezes ruby https://bugs.ruby-lang.org/issues/19562 * Author: larskanis (Lars Kanis) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following command blocks infinitely and must be killed with "kill -9" ``` ruby -e "Ractor.new{}.take; Encoding.default_external = Encoding::ISO8859_2" ``` Backtrace is: ``` #0 futex_wait (private=0, expected=2, futex_word=0x55555555abd0) at ../sysdeps/nptl/futex-internal.h:146 #1 __GI___lll_lock_wait (futex=futex@entry=0x55555555abd0, private=0) at ./nptl/lowlevellock.c:49 #2 0x00007ffff760a082 in lll_mutex_lock_optimized (mutex=0x55555555abd0) at ./nptl/pthread_mutex_lock.c:48 #3 ___pthread_mutex_lock (mutex=mutex@entry=0x55555555abd0) at ./nptl/pthread_mutex_lock.c:93 #4 0x00007ffff7c5a40d in rb_native_mutex_lock (lock=lock@entry=0x55555555abd0) at ruby-3.2.1/thread_pthread.c:556 #5 0x00007ffff7cc5376 in vm_lock_enter (cr=0x55555555deb0, vm=0x55555555aba0, locked=locked@entry=false, no_barrier=no_barrier@entry=false, lev=0x55555555ac00) at vm_sync.c:56 #6 0x00007ffff7cc5747 in rb_vm_lock_body () at vm_sync.c:175 #7 0x00007ffff7bc02c2 in rb_vm_lock (line=1829, file=0x7ffff7e209cb "ractor.c") at ruby-3.2.1/vm_sync.h:57 #8 ractor_check_blocking (remained_thread_cnt=<optimized out>, file=0x7ffff7e209cb "ractor.c", line=1865, cr=0x55555555deb0) at ractor.c:1829 #9 ractor_check_blocking (line=1865, file=0x7ffff7e209cb "ractor.c", remained_thread_cnt=<optimized out>, cr=0x55555555deb0) at ractor.c:1811 #10 rb_ractor_blocking_threads_inc (cr=0x55555555deb0, file=file@entry=0x7ffff7e29b04 "thread.c", line=line@entry=1488) at ractor.c:1865 #11 0x00007ffff7c60977 in blocking_region_begin (th=0x55555555d070, region=0x7fffffffd220, ubf=0x7ffff7c5b300 <ubf_select>, arg=0x55555555d070, fail_if_interrupted=<optimized out>) at thread.c:1488 #12 0x00007ffff7c61edf in rb_nogvl (func=0x7ffff7ac66e0 <no_gvl_stat>, data1=0x7fffffffd2a0, ubf=<optimized out>, data2=0x55555555d070, flags=<optimized out>) at thread.c:1548 #13 0x00007ffff7acdfbc in stat_without_gvl (st=0x7fffffffd2b0, path=0x7ffff27dfe88 "ruby-3.2.1/lib/ruby/3.2.0/x86_64-linux/enc/iso_8859_2.so") at file.c:1171 #14 rb_check_realpath_internal (basedir=basedir@entry=4, path=path@entry=140737261984200, origenc=0x555555565030, mode=mode@entry=RB_REALPATH_STRICT) at file.c:4491 #15 0x00007ffff7acebaa in rb_realpath_internal (basedir=basedir@entry=4, path=path@entry=140737261984200, strict=strict@entry=1) at file.c:4536 #16 0x00007ffff7b2cdd4 in require_internal (ec=0x55555555e1f0, fname=<optimized out>, exception=1, warn=<optimized out>) at load.c:1195 #17 0x00007ffff7aa0a17 in load_encoding (name=0x5555556049b0 "ISO-8859-2") at encoding.c:779 #18 0x00007ffff7aa2ef8 in check_encoding (enc=0x5555556049d0) at encoding.c:191 #19 enc_check_encoding (obj=140737335533800) at encoding.c:202 #20 rb_to_encoding (enc=enc@entry=140737335533800) at encoding.c:307 #21 0x00007ffff7aa4049 in enc_set_default_encoding (name=0x7ffff7de6287 "external", encoding=140737335533800, def=0x7ffff7fb00c0 <default_external>) at encoding.c:1563 #22 rb_enc_set_default_external (encoding=140737335533800) at encoding.c:1637 #23 0x00007ffff7aa411f in set_default_external (klass=<optimized out>, encoding=140737335533800) at encoding.c:1658 #24 0x00007ffff7c99037 in vm_call_cfunc_with_frame (ec=0x55555555e1f0, reg_cfp=0x7ffff6f7df90, calling=<optimized out>) at ruby-3.2.1/vm_insnhelper.c:3268 #25 0x00007ffff7ca9564 in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at ruby-3.2.1/vm_callinfo.h:367 #26 vm_exec_core (ec=0x55555555e1f0, initial=128) at ruby-3.2.1/insns.def:820 #27 0x00007ffff7caee93 in rb_vm_exec (ec=0x55555555e1f0, jit_enable_p=true) at vm.c:2374 #28 0x00007ffff7abfbf1 in rb_ec_exec_node (ec=ec@entry=0x55555555e1f0, n=n@entry=0x7ffff796c2c0) at eval.c:289 #29 0x00007ffff7ac60b3 in ruby_run_node (n=0x7ffff796c2c0) at eval.c:330 #30 0x0000555555555187 in rb_main (argv=0x7fffffffdb98, argc=3) at ./main.c:38 #31 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:57 ``` When the encoding was already loaded before running `Ractor.new`, then it works and doesn't block: ``` ruby -e "''.encode(Encoding::ISO8859_2); Ractor.new{}.take; Encoding.default_internal = Encoding::ISO8859_2" ``` When the encoding is not assigned as default encoding, but used otherwise, it works too: ``` ruby -e "Ractor.new{}.take; ''.encode(Encoding::ISO8859_2)" ``` -- https://bugs.ruby-lang.org/

1 year, 1 month

2
1
0 0

[ruby-core:113114] [Ruby master Feature#19579] Remove !USE_RVARGC code

by peterzhu2118 (Peter Zhu)

Issue #19579 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19579: Remove !USE_RVARGC code https://bugs.ruby-lang.org/issues/19579 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7655 The Variable Width Allocation feature was turned on by default in Ruby 3.2. Since then, we haven't received bug reports or backports to the non-Variable Width Allocation code paths, so we assume that nobody is using it. We also don't plan on maintaining the non-Variable Width Allocation code, so we would like to remove it. -- https://bugs.ruby-lang.org/

1 year, 1 month

1
0
0 0

[ruby-core:113077] [Ruby master Bug#19568] Windows mingw rust, failures with test/rubygems/test_gem_ext_cargo_builder.rb

by MSP-Greg (Greg L)

Issue #19568 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #19568: Windows mingw rust, failures with test/rubygems/test_gem_ext_cargo_builder.rb https://bugs.ruby-lang.org/issues/19568 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * ruby -v: master * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The Windows ucrt & mingw builds recently started failing tests in: test/rubygems/test_gem_ext_cargo_builder.rb TestGemExtCargoBuilder Checking changed files from the last good build showed: array.c gems/bundled_gems iseq.c lib/irb.rb lib/irb/cmd/nop.rb lib/irb/completion.rb lib/irb/ext/tracer.rb lib/irb/extend-command.rb lib/ruby_vm/rjit/compiler.rb lib/ruby_vm/rjit/context.rb lib/ruby_vm/rjit/insn_compiler.rb lib/ruby_vm/rjit/jit_state.rb rjit_c.c rjit_c.h rjit_c.rb test/irb/test_cmd.rb tool/leaked-globals tool/rjit/bindgen.rb vm_callinfo.h yjit.c yjit/bindgen/src/main.rs yjit/src/codegen.rs yjit/src/cruby_bindings.inc.rs There have been no changes to ruby-loco during this time. ruby-loco uses rust installed by dtolnay/rust-toolchain@stable, which are the tools provided by the Rust organization. I also tried MSYS2 rust. I've created two files showing the errors logs: https://github.com/MSP-Greg/ruby-loco/releases/download/error_logs/windows_… https://github.com/MSP-Greg/ruby-loco/releases/download/error_logs/windows_… I'm not familiar with Rust, so I have no idea what the issue is. I'm guessing this might be an MSYS2 issue, but I'm not sure... -- https://bugs.ruby-lang.org/

1 year, 1 month

3
3
0 0

[ruby-core:113104] [Ruby master Bug#19574] [BUG] Bus Error at 0x0000000102a7c000

by haneul (Haneul Kihm)

Issue #19574 has been reported by haneul (Haneul Kihm). ---------------------------------------- Bug #19574: [BUG] Bus Error at 0x0000000102a7c000 https://bugs.ruby-lang.org/issues/19574 * Author: haneul (Haneul Kihm) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ---Files-------------------------------- ruby-2023-04-04-181657.ips (13.5 KB) ruby-2023-04-04-182522.ips (13.5 KB) -- https://bugs.ruby-lang.org/

1 year, 1 month

2
1
0 0

[ruby-core:112990] [Ruby master Bug#19545] lp/hp logic parsing inconsistency

by hurricup (Alexandr Evstigneev)

Issue #19545 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19545: lp/hp logic parsing inconsistency https://bugs.ruby-lang.org/issues/19545 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- As far as i get it, low precedence logic should behave the same as high precedence. But: This is ok: ``` puts(false || !false) ``` And this is not: ``` puts(false or not false) ``` Feels like in latter case there is some mess with comma precedence. -- https://bugs.ruby-lang.org/

1 year, 1 month

2
5
0 0

[ruby-core:112445] [Ruby master Bug#19441] Closing an IO#dup behaviour

by stac47 (Laurent Stacul)

Issue #19441 has been reported by stac47 (Laurent Stacul). ---------------------------------------- Bug #19441: Closing an IO#dup behaviour https://bugs.ruby-lang.org/issues/19441 * Author: stac47 (Laurent Stacul) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.1 (2023-02-08 revision 31819e82c8) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello amazing ruby folks! I classified that ticket as a "Bug" although it is perhaps something I did not understand. Here is a ruby session: ``` ruby irb(main):001:0> file = Tempfile.new => #<File:/var/folders/m2/bljzrgq160vbf0vk466k_7gw0000gn/T/20230216-39664-davfmj> irb(main):002:0> file.fileno => 9 irb(main):003:0> dup = file.dup => #<File:/var/folders/m2/bljzrgq160vbf0vk466k_7gw0000gn/T/20230216-39664-davfmj> irb(main):004:0> dup.fileno => 10 irb(main):005:0> dup.close => nil irb(main):006:0> dup.closed? => false irb(main):007:0> file.closed? => true ``` The two last lines are unexpected to me. I would have expected the converse: ```ruby irb(main):006:0> dup.closed? => true irb(main):007:0> file.closed? => false ``` I tried this scenario in latest ruby but also in ruby 2.7. Thanks in advance for helping me to understand this behaviour. -- https://bugs.ruby-lang.org/

1 year, 1 month

3
5
0 0

[ruby-core:113022] [Ruby master Bug#19548] Ambiguous and confusing syntax for alias/undef arguments

by hurricup (Alexandr Evstigneev)

Issue #19548 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Bug #19548: Ambiguous and confusing syntax for alias/undef arguments https://bugs.ruby-lang.org/issues/19548 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This was introduced in https://bugs.ruby-lang.org/issues/8851 and looks really confusing at least because of bare `/`. Here are 3 semantically similar methods, but feels like first two should not be valid: ``` def method1 undef :*,<<,/,[] alias :* / end def method2 undef :*, <<, /, [] alias :* / end def method3 undef :* undef :<< undef :/ undef :[] alias :* :/ end puts RubyVM::InstructionSequence.of(method :method1).disasm puts RubyVM::InstructionSequence.of(method :method2).disasm puts RubyVM::InstructionSequence.of(method :method3).disasm ``` -- https://bugs.ruby-lang.org/

1 year, 1 month

2
1
0 0

2024

2023

2022

ruby-core April 2023