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

[ruby-core:119852] [Ruby master Feature#20882] Provide Boolean(...)
by getajobmike (Mike Perham) 14 Dec '24

14 Dec '24

Issue #20882 has been reported by getajobmike (Mike Perham). ---------------------------------------- Feature #20882: Provide Boolean(...) https://bugs.ruby-lang.org/issues/20882 * Author: getajobmike (Mike Perham) * Status: Open ---------------------------------------- Ruby provides Integer(...) and Float(...) global methods to coerce values. Is there a similar method for Booleans? I'd like to do something like: ``` # ENV["SOME_FEATURE"] is unset Boolean(ENV["SOME_FEATURE"]) # => false # ENV["SOME_FEATURE"] is unset, but allow a default? Boolean(ENV["SOME_FEATURE"], true) # => true # explicitly disable ENV["SOME_FEATURE"] = "0" Boolean(ENV["SOME_FEATURE"], true) # => false # explicitly enable ENV["SOME_FEATURE"] = "1" Boolean(ENV["SOME_FEATURE"]) # => true ``` -- https://bugs.ruby-lang.org/

11 11

[ruby-core:120233] [Ruby master Bug#20952] A weird error message for []= with keyword arguments
by zverok (Victor Shepelev) 13 Dec '24

13 Dec '24

Issue #20952 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #20952: A weird error message for []= with keyword arguments https://bugs.ruby-lang.org/issues/20952 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED ---------------------------------------- Trying to document the new deprecation of `#[]=` with keyword arguments, I wrote this sample code: ```ruby class MyMatrix # ...some implementation def []=(*args, **kwargs) p(args:, kwargs:) # ...some implementation end end matrix = MyMatrix.new matrix[5, axis: :y] = 8 ``` This fails as expected, but the error message is totally unexpected for me: ``` ruby3_4.rb:11:in '<main>': undefined method '[]=' for an instance of Integer (NoMethodError) matrix[5, axis: :y] = 8 ^^^^^^^^^^^^^^^ ``` Am I missing some interpretation peculiarity here?.. ``` $ ruby -v ruby 3.4.0dev (2024-12-11T19:50:20Z master 34e68548d4) +PRISM [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120082] [Ruby master Bug#20927] `{ **{ } }` behaves differently when `shareable_constant_value: experimental_everything`
by tenderlovemaking (Aaron Patterson) 13 Dec '24

13 Dec '24

Issue #20927 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20927: `{ **{ } }` behaves differently when `shareable_constant_value: experimental_everything` https://bugs.ruby-lang.org/issues/20927 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-16 revision 425e468d25) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- These two programs produce different results ```ruby # shareable_constant_value: experimental_everything C = { **{ } } p C ``` ```ruby C = { **{ } } p C ``` The first one prints this: ``` $ ruby test.rb {nil=>{}} ``` The second one prints this: ``` $ ruby test.rb {} ``` I think they should print the same thing. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119769] [Ruby master Feature#20875] Atomic initialization for Ractor local storage
by ko1 (Koichi Sasada) 12 Dec '24

12 Dec '24

Issue #20875 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #20875: Atomic initialization for Ractor local storage https://bugs.ruby-lang.org/issues/20875 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- ## Motivation Now there is no way to initialize Ractor local storage in multi-thread. For example, if we want to introduce per-Ractor counter, which should be protected with a per-Ractor Mutex for multi-threading support. ```ruby def init Ractor[:cnt] = 0 Ractor[:mtx] = Mutex.new end def inc init unless Ractor[:cnt] Ractor[:mtx].synchronize do Ractor[:cnt] += 1 end end ``` In this code, if `inc` was called on multiple threads, `init` can be called with multiple threads and `cnt` can not be synchronized correctly. ## Proposal Let's introduce `Ractor.local_storage_init(sym){ block }` to initialize values in Ractor local storage. If there is no slot for `sym`, synchronize with per-Ractor mutex and call `block` and the slot will be filled with the evaluation with the block result. The return value of this method will be the filled value. Otherwise, returning corresponding value will be returned. The implementation is like that (in C): ```ruby class Ractor def self.local_storage_init(sym) Ractor.per_ractor_mutex.synchronize do if Ractor.local_storage_has_key?(sym) Ractor[:sym] else Ractor[:sym] = yield end end end end ``` The above examples will be rewritten with the following code: ```ruby def inc Ractor.local_storage_init(:mtx) do Ractor[:cnt] = 0 Mutex.new end.synchronize do Ractor[:cnt] += 1 end end ``` ## Discussion ### Approach There are another approach like `pthread_atfork`, maybe like `Ractor.atcreate{ init }`. A library registers a callback which will be called when a new ractor is created. However, there are many Ractors which don't use the library, so that ``atcreate` can be huge overhead for Ractor creation. ### Naming I propose `local_storage_init`, but not sure it matches. I also proposed `Ractor.local_variable_init(sym)`, but Matz said he doesn't like this naming because it should not be a "variable". (there is a `Thread#thread_variable_get` method, though). On another aspect, `lcoal_storage_init` seems it clears all of ractor local storage slots. -- https://bugs.ruby-lang.org/

3 11

[ruby-core:120035] [Ruby master Bug#20918] Prism error indicates line number of `-e` that does not exist
by mame (Yusuke Endoh) 12 Dec '24

12 Dec '24

Issue #20918 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20918: Prism error indicates line number of `-e` that does not exist https://bugs.ruby-lang.org/issues/20918 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` $ ruby -e 'foo(' -e: -e:2: syntax error found (SyntaxError) 1 | foo( > 2 | | ^ unexpected end-of-input; expected a `)` to close the arguments ``` It says `-e:2`, but there is no line 2 in `-e 'foo('`. `eval("foo(")` reports line 1, so I guess this issue is only for `-e`. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118750] [Ruby master Bug#20659] Speed regression of `parse.y` parser after numeric nodes were introduced
by alanwu (Alan Wu) 12 Dec '24

12 Dec '24

Issue #20659 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #20659: Speed regression of `parse.y` parser after numeric nodes were introduced https://bugs.ruby-lang.org/issues/20659 * Author: alanwu (Alan Wu) * Status: Open * ruby -v: ruby 3.4.0dev (2024-07-30T14:01:43Z master 1164b6a7ba) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The [`mail` benchmark from yjit-bench][1] is about 20% slower on `master` compared to commit:98eeadc9 ("Development of 3.4.0 started.") as the baseline, comparing running time of the Ruby process running the benchmark for a single iteration. Much of this workload is Ruby parsing. ``` $ hyperfine -L ruby '3.3-equiv/bin/ruby,before-numeric-nodes/bin/ruby,master/bin/ruby' '~/.rubies/{ruby} -Iharness-once benchmarks/mail/benchmark.rb' Benchmark 1: ~/.rubies/3.3-equiv/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 889.0 ms ± 2.0 ms [User: 776.9 ms, System: 111.7 ms] Range (min … max): 885.7 ms … 892.1 ms 10 runs Benchmark 2: ~/.rubies/before-numeric-nodes/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 891.7 ms ± 1.6 ms [User: 794.5 ms, System: 96.9 ms] Range (min … max): 889.0 ms … 894.7 ms 10 runs Benchmark 3: ~/.rubies/master/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 1.086 s ± 0.003 s [User: 0.951 s, System: 0.134 s] Range (min … max): 1.080 s … 1.091 s 10 runs Summary '~/.rubies/3.3-equiv/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb' ran 1.00 ± 0.00 times faster than '~/.rubies/before-numeric-nodes/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb' 1.22 ± 0.00 times faster than '~/.rubies/master/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb' $ for tag in 3.3-equiv master before-numeric-nodes; do echo $tag: $(~/.rubies/$tag/bin/ruby -v); done 3.3-equiv: ruby 3.4.0dev (2023-12-25T09:13:40Z master 98eeadc932) [x86_64-linux] master: ruby 3.4.0dev (2024-07-30T14:01:43Z master 1164b6a7ba) [x86_64-linux] before-numeric-nodes: ruby 3.4.0dev (2024-01-06T18:26:38Z master 76afbda5b5) [x86_64-linux] ``` Using Valgrind's DHAT reveals that commit:1b8d01136c3ff6c60325c7609d61e19ac42acd9f ("Introduce Numeric Node's") issues roughly 3 times more `malloc` calls compared to the baseline, most of them comping from strdup() calls in set_number_literal(). Comparison with `--parser=prism`, for interest: <details> ``` $ hyperfine -L ruby '3.3-equiv/bin/ruby,before-numeric-nodes/bin/ruby,master/bin/ruby,master/bin/ruby --parser=prism' \ '~/.rubies/{ruby} -Iharness-once benchmarks/mail/benchmark.rb' Benchmark 1: ~/.rubies/3.3-equiv/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 889.7 ms ± 2.6 ms [User: 771.4 ms, System: 118.0 ms] Range (min … max): 885.8 ms … 894.6 ms 10 runs Benchmark 2: ~/.rubies/before-numeric-nodes/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 890.4 ms ± 1.6 ms [User: 776.8 ms, System: 113.3 ms] Range (min … max): 888.4 ms … 892.9 ms 10 runs Benchmark 3: ~/.rubies/master/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 1.087 s ± 0.004 s [User: 0.968 s, System: 0.119 s] Range (min … max): 1.083 s … 1.097 s 10 runs Benchmark 4: ~/.rubies/master/bin/ruby --parser=prism -Iharness-once benchmarks/mail/benchmark.rb Time (mean ± σ): 826.9 ms ± 2.1 ms [User: 725.8 ms, System: 100.7 ms] Range (min … max): 823.6 ms … 830.9 ms 10 runs Summary '~/.rubies/master/bin/ruby --parser=prism -Iharness-once benchmarks/mail/benchmark.rb' ran 1.08 ± 0.00 times faster than '~/.rubies/3.3-equiv/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb' 1.08 ± 0.00 times faster than '~/.rubies/before-numeric-nodes/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb' 1.31 ± 0.01 times faster than '~/.rubies/master/bin/ruby -Iharness-once benchmarks/mail/benchmark.rb' ``` </details> [1]: https://github.com/Shopify/yjit-bench/blob/b8f1bd8931d4757afdae933ef6f11e07… -- https://bugs.ruby-lang.org/

2 4

[ruby-core:119632] [Ruby master Feature#20818] Allow passing a block to Hash#store (to update current value)
by furunkel (Julian Aron Prenner) 12 Dec '24

12 Dec '24

Issue #20818 has been reported by furunkel (Julian Aron Prenner). ---------------------------------------- Feature #20818: Allow passing a block to Hash#store (to update current value) https://bugs.ruby-lang.org/issues/20818 * Author: furunkel (Julian Aron Prenner) * Status: Open ---------------------------------------- I would like to propose a block form for `Hash#store`. In addition to passing a value, it should also be allowed to pass a block. If passed a block instead of a value, the block is called with the current value or, if unset, the hash's default value; the block's return value will be the value that is stored. This is similar to e.g., `computeIfPresent`/`computeIfAbsent` in Java (I think). I can think of several situations where this would be useful, in particular for caches and counters. For instance: ```ruby counts = {} elements.each do |element| counts.store(element){ (_1 || 0) + element.weight} end ``` or even more elegant with a default value: ```ruby counts = {} counts.default = 0 elements.each do |element| counts.store(element){ _1 + element.weight} end ``` Moreover, using the block form we should be able to do operations such as `h[k] ||= x`, `h[k] -= x`, `h[k] += x`, or more generally `h[k] = f(h[k])`, with a single "hashing round-trip". If I'm not mistaken, currently these involve two separate calls to `#[]` and `#[]=` (with two calls to `#hash`?). Finally, this makes `#store` a proper dual of `#fetch` which, similarly, can be passed a block. I have an experimental implementation of this (GitHub PR) at: https://github.com/ruby/ruby/pull/11956 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:120114] [Ruby master Bug#20932] Socket fast_fallback segfaults when fds are > FD_SETSIZE
by jhawthorn (John Hawthorn) 12 Dec '24

12 Dec '24

Issue #20932 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20932: Socket fast_fallback segfaults when fds are > FD_SETSIZE https://bugs.ruby-lang.org/issues/20932 * Author: jhawthorn (John Hawthorn) * Status: Open * Assignee: shioimm (Misaki Shioi) * Target version: 3.4 * ruby -v: ruby 3.4.0dev (2024-12-04T21:46:02Z master bf225feb26) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- When `Socket.tcp_fast_fallback = true` and a socket ends up with an FD over FD_SETSIZE (typically 1024), it results in a buffer overflow and crashes when running FD_SET before select. It may be necessary to update ulimits to be above 1024 before reproducing (`ulimit -n 2048`) ``` require "socket" open_fds = [] loop do file = open(__FILE__) open_fds << file break if file.fileno >= 1010 end #Socket.tcp_fast_fallback=false TCPServer.open("localhost", 0) do |server| port = server.addr[1] sockets = [] 50.times do |i| socket = TCPSocket.open("localhost", port) p socket sockets << socket end end ``` ``` $ ulimit -n 2048 $ ruby test.rb #<TCPSocket:fd 1015, AF_INET6, ::1, 40622> #<TCPSocket:fd 1014, AF_INET6, ::1, 40628> #<TCPSocket:fd 1016, AF_INET6, ::1, 40630> #<TCPSocket:fd 1017, AF_INET6, ::1, 40632> #<TCPSocket:fd 1018, AF_INET6, ::1, 40644> #<TCPSocket:fd 1020, AF_INET6, ::1, 40658> #<TCPSocket:fd 1021, AF_INET6, ::1, 40668> #<TCPSocket:fd 1019, AF_INET6, ::1, 40674> #<TCPSocket:fd 1022, AF_INET6, ::1, 40678> #<TCPSocket:fd 1023, AF_INET6, ::1, 40694> ================================================================= ==3180778==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ae35aadc580 at pc 0x7ae35b1b7449 bp 0x7fffc9af1af0 sp 0x7fffc9af1ae8 READ of size 8 at 0x7ae35aadc580 thread T0 #0 0x7ae35b1b7448 in init_fast_fallback_inetsock_internal /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:912:17 #1 0x60462ff14879 in rb_ensure /home/jhawthorn/src/ruby/eval.c:1053:18 #2 0x7ae35b1b41b9 in rsock_init_inetsock /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:1315:20 #3 0x7ae35b1bae9a in tcp_init /home/jhawthorn/src/ruby/ext/socket/tcpsocket.c:91:12 #4 0x604630178944 in vm_call0_cfunc_with_frame /home/jhawthorn/src/ruby/./vm_eval.c:164:15 #5 0x604630176ade in vm_call0_body /home/jhawthorn/src/ruby/./vm_eval.c:229:15 #6 0x604630146e46 in vm_call0_cc /home/jhawthorn/src/ruby/./vm_eval.c:101:12 #7 0x604630178ffd in rb_call0 /home/jhawthorn/src/ruby/./vm_eval.c:554:12 #8 0x604630147e3a in rb_call /home/jhawthorn/src/ruby/./vm_eval.c:873:12 #9 0x60462ffe15cd in rb_class_new_instance_kw /home/jhawthorn/src/ruby/object.c:2187:5 #10 0x60462ff6c39c in rb_io_s_open /home/jhawthorn/src/ruby/io.c:8126:16 #11 0x604630166e9c in vm_call_cfunc_with_frame_ /home/jhawthorn/src/ruby/./vm_insnhelper.c:3801:11 #12 0x604630134dad in vm_sendish /home/jhawthorn/src/ruby/./vm_insnhelper.c #13 0x60463013c68b in vm_exec_core /home/jhawthorn/src/ruby/insns.def:898:11 #14 0x604630135327 in rb_vm_exec /home/jhawthorn/src/ruby/vm.c:2585:22 #15 0x60463017ba7c in invoke_iseq_block_from_c /home/jhawthorn/src/ruby/vm.c:1615:12 #16 0x60463017ba7c in invoke_block_from_c_bh /home/jhawthorn/src/ruby/vm.c:1629:20 #17 0x60463014b477 in vm_yield_with_cref /home/jhawthorn/src/ruby/vm.c:1666:12 #18 0x604630148937 in rb_yield /home/jhawthorn/src/ruby/./vm_eval.c #19 0x60462ff14879 in rb_ensure /home/jhawthorn/src/ruby/eval.c:1053:18 #20 0x604630166e9c in vm_call_cfunc_with_frame_ /home/jhawthorn/src/ruby/./vm_insnhelper.c:3801:11 #21 0x604630159de6 in vm_call_method_each_type /home/jhawthorn/src/ruby/./vm_insnhelper.c:4779:16 #22 0x604630159afe in vm_call_method /home/jhawthorn/src/ruby/./vm_insnhelper.c #23 0x604630134dad in vm_sendish /home/jhawthorn/src/ruby/./vm_insnhelper.c #24 0x60463013ba52 in vm_exec_core /home/jhawthorn/src/ruby/insns.def:851:11 #25 0x60463015113b in vm_exec_loop /home/jhawthorn/src/ruby/vm.c:2612:22 #26 0x60463013533a in rb_vm_exec /home/jhawthorn/src/ruby/vm.c #27 0x60462ff12f0c in rb_ec_exec_node /home/jhawthorn/src/ruby/eval.c:281:9 #28 0x60462ff12d12 in ruby_run_node /home/jhawthorn/src/ruby/eval.c:319:30 #29 0x60462ff0ed73 in rb_main /home/jhawthorn/src/ruby/./main.c:43:12 #30 0x60462ff0ec47 in main /home/jhawthorn/src/ruby/./main.c:68:12 #31 0x7ae35c5e7e07 in __libc_start_call_main /usr/src/debug/glibc/glibc/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #32 0x7ae35c5e7ecb in __libc_start_main /usr/src/debug/glibc/glibc/csu/../csu/libc-start.c:360:3 #33 0x60462fe2f334 in _start (/home/jhawthorn/.rubies/ruby-asan/bin/ruby+0x174334) Address 0x7ae35aadc580 is located in stack of thread T0 at offset 384 in frame #0 0x7ae35b1b44df in init_fast_fallback_inetsock_internal /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:537 This frame has 14 object(s): [32, 36) 'status' (line 544) [48, 50) 'resolved_type' (line 555) [64, 72) 'pipefd' (line 558) [96, 224) 'readfds' (line 559) [256, 384) 'writefds' (line 559) <== Memory access at offset 384 overflows this variable [416, 456) 'wait_arg' (line 561) [496, 512) 'delay' (line 563) [528, 568) 'resolution_store' (line 567) [608, 624) 'resolution_delay_storage' (line 604) [640, 656) 'connection_attempt_delay_strage' (line 606) [672, 688) 'user_specified_resolv_timeout_storage' (line 608) [704, 720) 'user_specified_connect_timeout_storage' (line 610) [736, 740) 'err' (line 953) [752, 756) 'len' (line 954) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /home/jhawthorn/src/ruby/ext/socket/ipsocket.c:912:17 in init_fast_fallback_inetsock_internal Shadow bytes around the buggy address: 0x7ae35aadc300: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7ae35aadc380: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0x7ae35aadc400: f1 f1 f1 f1 04 f2 02 f2 00 f2 f2 f2 00 00 00 00 0x7ae35aadc480: 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 0x7ae35aadc500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x7ae35aadc580:[f2]f2 f2 f2 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 0x7ae35aadc600: f2 f2 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 f2 f2 0x7ae35aadc680: 00 00 f2 f2 00 00 f2 f2 00 00 f2 f2 f8 f2 f8 f3 0x7ae35aadc700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ae35aadc780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ae35aadc800: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==3180778==ABORTING ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:120217] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by nobu (Nobuyoshi Nakada) 12 Dec '24

12 Dec '24

Issue #6648 has been updated by nobu (Nobuyoshi Nakada). Eregon (Benoit Daloze) wrote in #note-44: > Are you thinking if the directory is removed? In that case there is no way to rerun the command faithfully, so an error like Errno::ENOENT is fine. Removed or renamed. It can rerun fine by removing `-C` options and staying in the current directory. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-110981 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120050] [Ruby master Feature#20922] Should not we omit parentheses in assert calls?
by mame (Yusuke Endoh) 12 Dec '24

12 Dec '24

Issue #20922 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #20922: Should not we omit parentheses in assert calls? https://bugs.ruby-lang.org/issues/20922 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I often see the style of omitting parentheses in assert calls, but it leads to annoying warnings in the following case: ``` assert_equal -1, val #=> warning: ambiguous first argument; put parentheses or a space even after `-` operator assert_match /foo/, str #=> warning: ambiguous `/`; wrap regexp in parentheses or add a space after `/` operator ``` To deal with this warning, it is necessary to add parentheses only to *some* assert calls. ``` assert_equal 1, one assert_equal 0, zero assert_equal(-1, minus_one) ``` Obviously, this is not very cool. I feel that by these warnings, Ruby says "we should not omit parentheses in assert calls". Is this what matz intended? If it is the intent, I would like to add parentheses on all assert calls in tests of Ruby and default gems. If it is not the intent, why don't we remove these warnings? Note that, as far as I recall, I encountered this problem only with `assert_equal` and `assert_match`. I don't write parentheses in `p`, `puts`, `attr_reader`, `include`, etc., but all of them rarely accept `-1` and `//` literally as the first argument in real code. As a milder approach, I came up with an idea to stop the warning only when the method name starts with "assert". It is very ad-hoc, though. -- https://bugs.ruby-lang.org/

2 3