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

[ruby-core:118681] [Ruby master Bug#20651] `false && (1 in 1)` produces argument stack underflow (-1)
by tompng (tomoya ishida) 02 Sep '24

02 Sep '24

Issue #20651 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20651: `false && (1 in 1)` produces argument stack underflow (-1) https://bugs.ruby-lang.org/issues/20651 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-07-24T19:55:04Z master 30eba40f9c) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `false && (1 in 1)` and `true || (1 in 1)` produces argument stack underflow since ruby 3.0 ~~~ # ruby -v ruby 3.4.0dev (2024-07-24T19:55:04Z master 30eba40f9c) [x86_64-linux] # ruby -e "false && (1 in 1)" -- raw disasm-------- trace: 1 0000 putobject false ( 1) 0002 leave ( 1) <L004> [sp: 1, unremovable: 1, refcnt: 1] <L002> [sp: 1, unremovable: 0, refcnt: 0] 0003 pop ( 1) * 0004 pop ( 1) 0005 putobject false ( 1) 0007 leave ( 1) --------------------- -e:1: argument stack underflow (-1) -e: compile error (SyntaxError) ~~~ -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118797] [Ruby master Bug#20668] [3.3] shareable_constant_value: literal crash
by byroot (Jean Boussier) 02 Sep '24

02 Sep '24

Issue #20668 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20668: [3.3] shareable_constant_value: literal crash https://bugs.ruby-lang.org/issues/20668 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin23] * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- The following test script crashes in the parser: ```ruby # shareable_constant_value: literal FORM_STRATEGIES = { 'product' => Object, 'storefront_password' => String, 'contact' => Class, } ``` The entire 3.3.x series is affected but not `master` nor 3.2. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118686] [Ruby master Bug#20653] Memory leak in String#start_with? when regexp times out
by peterzhu2118 (Peter Zhu) 02 Sep '24

02 Sep '24

Issue #20653 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20653: Memory leak in String#start_with? when regexp times out https://bugs.ruby-lang.org/issues/20653 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: WONTFIX, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/11247 This commit refactors how Onigmo handles timeout. Instead of raising a timeout error, onig_search will return a ONIGERR_TIMEOUT which the caller can free memory, and then raise a timeout error. This fixes a memory leak in String#start_with when the regexp times out. For example: ```ruby regex = Regexp.new("^#{"(a*)" * 10_000}x$", timeout: 0.000001) str = "a" * 1000000 + "x" 10.times do 100.times do str.start_with?(regex) rescue end puts `ps -o rss= -p #{$$}` end ``` Before: ``` 33216 51936 71152 81728 97152 103248 120384 133392 133520 133616 ``` After: ``` 14912 15376 15824 15824 16128 16128 16144 16144 16160 16160 ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118637] [Ruby master Bug#20641] `lib/bundled_gems.rb` makes `Kernel.require` over 100x slower
by byroot (Jean Boussier) 02 Sep '24

02 Sep '24

Issue #20641 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20641: `lib/bundled_gems.rb` makes `Kernel.require` over 100x slower https://bugs.ruby-lang.org/issues/20641 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- I just discovered this while profiling Active Record's test suite, and I noticed 40% of the runtime was in `$LOAD_PATH.resolve_feature_path`, so much I thought it was a profiler bug. But it turns out it's real. Various APIs do call `require` late, for instance Psych calls `require 'date'` every single time it parses a date: https://github.com/ruby/psych/blob/be0ba74e5613c20f213403e15914d24944c2652d… I've put together a quick benchmark: ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report(RUBY_VERSION) { require "erb" } x.save! "/tmp/require.bench" x.compare! end ``` And the difference is massive: ``` Calculating ------------------------------------- 3.2.2 6.450M (± 1.2%) i/s - 32.822M in 5.089538s Comparison: 3.2.2: 6449899.4 i/s 3.3.3: 46996.8 i/s - 137.24x slower ``` And that's with a small `$LOAD_PATH`, the bigger the application, the worse it is, if I add: ```ruby 100.times do |i| $LOAD_PATH.unshift("/tmp/empty-#{i}") end ``` ``` Calculating ------------------------------------- 3.3.3 6.198k (± 6.1%) i/s - 30.968k in 5.018955s Comparison: 3.2.2: 3380939.6 i/s 3.3.3: 6198.4 i/s - 545.46x slower ``` I'm looking at a way to speed this up, but this is big enough that I believe we should backport the fix. cc @hsbt -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118983] [Ruby master Bug#20706] Can't build Ruby on macOS Sonoma and Sequoia due to: ignoring duplicate libraries, archive member '/' not a mach-o file in libruby.3.3-static.a
by wkoszek (Adam Koszek) 30 Aug '24

30 Aug '24

Issue #20706 has been reported by wkoszek (Adam Koszek). ---------------------------------------- Bug #20706: Can't build Ruby on macOS Sonoma and Sequoia due to: ignoring duplicate libraries, archive member '/' not a mach-o file in libruby.3.3-static.a https://bugs.ruby-lang.org/issues/20706 * Author: wkoszek (Adam Koszek) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, I had the same problems with macOS Sonoma and (after an upgrade) Sequoia -- something about my macOS makes it impossible to build Ruby. Upon an upgrade to Sequoia, I did Xcode upgrade, and then CommandLine tools download. Then I did "sudo xcode-select --reset" I'm trying ruby-3.3.4 and ruby-3.2.5 -- both have the same result from below. Steps: wget https://cache.ruby-lang.org/pub/ruby/3.3/ruby-3.3.4.tar.gz tar xzf ruby-3.3.4.tar.gz cd ruby-3.3.4 script ./configure make -j Last lines: linking shared-object -test-/scan_args.bundle linking shared-object -test-/string.bundle linking shared-object objspace.bundle linking shared-object digest/bubblebabble.bundle linking shared-object stringio.bundle linking transcoder big5.bundle linking shared-object json/ext/generator.bundle making ends make[1]: Nothing to be done for `encs'. linking shared-object nkf.bundle linking shared-object ripper.bundle file2lastrev.rb: does not seem to be under a vcs: . revision.h unchanged config.status: creating ruby-runner.h ln -sf ../../rbconfig.rb .ext/arm64-darwin24/rbconfig.rb linking ruby ld: warning: ignoring duplicate libraries: '-ldl', '-lobjc', '-lpthread' ld: archive member '/' not a mach-o file in '/Users/wk/tmp/rubyc/ruby-3.3.4/libruby.3.3-static.a' clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [ruby] Error 1 make[1]: *** [ruby] Error 2 make: *** [build-ext] Error 2 [07:35:03][wk@wkoszek_mba:~/tmp/rubyc/ruby-3.3.4]$ exit exit Script done, output file is typescript file /Users/wk/tmp/rubyc/ruby-3.3.4/libruby.3.3-static.a /Users/wk/tmp/rubyc/ruby-3.3.4/libruby.3.3-static.a: current ar archive I'm attaching the transcript. This ticket has this warning too: https://bugs.ruby-lang.org/issues/20283 But looks like it's a warning. For me it's somehow an error. ---Files-------------------------------- typescript (54.7 KB) -- https://bugs.ruby-lang.org/

4 6

[ruby-core:118964] [Ruby master Bug#20700] `warn_cr_in_shebang()` doesn't fire if there's no `\n`
by AMomchilov (Alexander Momchilov) 28 Aug '24

28 Aug '24

Issue #20700 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Bug #20700: `warn_cr_in_shebang()` doesn't fire if there's no `\n` https://bugs.ruby-lang.org/issues/20700 * Author: AMomchilov (Alexander Momchilov) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The `warn_cr_in_shebang()` function looks for `\r\n` together, but the `\r` should emit a warning, regardless if there's also a `\n` or not. ```ruby #!/usr/bin/ruby require "tempfile" require "open3" def run_rb(ruby_src) puts "===== Output of #{ruby_src.inspect}:" Tempfile.create("script.rb") do |f| f.print(ruby_src) f.close stdout_and_stderr_str, status = Open3.capture2e("/opt/rubies/3.3.4/bin/ruby", f.path) raise unless status.success? puts stdout_and_stderr_str end end run_rb("#!ruby") # ✅ no warning run_rb("#!ruby\r") # ❌ no warning! run_rb("#!ruby\r\n") # ✅ warns run_rb("#!ruby -Eutf-8\r\n123") # ✅ warns ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114645] [Ruby master Bug#19865] Segfault when calling user signal handlers during VM shutdown
by ivoanjo (Ivo Anjo) 27 Aug '24

27 Aug '24

Issue #19865 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19865: Segfault when calling user signal handlers during VM shutdown https://bugs.ruby-lang.org/issues/19865 * Author: ivoanjo (Ivo Anjo) * 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 ---------------------------------------- Howdy 👋! I work for Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb) . I've found this issue while investigating a [customer crash report](https://github.com/DataDog/dd-trace-rb/issues/2980). ### Background The original issue was found in a production app. A number of things need to be in play to cause it. The [`ruby-odbc`](https://rubygems.org/gems/ruby-odbc) gem provides a way of accessing databases through the ODBC API. It wraps a database connection as a Data object, with a free function that, prior to freeing the native resources, disconnects from the database if the connection was still active. Because disconnecting from the database is a blocking operation, the gem (reasonably, in my opinion), releases the global VM lock before disconnecting. The trigger for the crash is: 1. The app in question used puma, and puma installs a `Signal.trap('TERM')` 2. The database object was still connected when the app started to shut down 3. A VM shutdown starts... 4. Half-way through shutdown, the VM received a SIGTERM signal, and queued it for processing 5. The VM calls the free function on all objects 6. The ruby-odbc gem sees there's an active database connection, and tries to release the GVL to call the blocking disconnect 7. Before releasing the GVL, the VM checks for pending interruptions 8. The VM tries to run the Ruby-level signal handler method half-way through VM shutdown, when you can no longer run Ruby code 9. Segfault ### How to reproduce (Ruby version & script) I was able to reproduce on a minimal example on Ruby 3.2.2 (`ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]`) and recent master (`ruby 3.3.0dev (2023-08-17T07:30:01Z master d26b015e83) [x86_64-linux]`). I've put the test-case up on github as well <https://github.com/DataDog/signal-bug-testcase>, but here's the important bits: `signal-bug-testcase.rb`: ```ruby require 'signal_bug_testcase' Signal.trap("TERM") { puts "Hello, world" } FOO = SignalBugTestcase.new ``` `signal_bug_testcase.c`: ```ruby #include <ruby.h> #include <ruby/thread.h> #include <signal.h> #include <unistd.h> typedef struct { int dummy; } BugTestcase; void *test_nogvl(void *unused) { fprintf(stderr, "GVL released!\n"); return NULL; } static void bug_testcase_free(void* ptr) { fprintf(stderr, "Free getting called! Sending signal...\n"); kill(getpid(), SIGTERM); fprintf(stderr, "SIGTERM signal queued, trying to release GVL...\n"); rb_thread_call_without_gvl(test_nogvl, NULL, NULL, NULL); fprintf(stderr, "After releasing GVL!\n"); free(ptr); } const rb_data_type_t bug_testcase_data_type = { .wrap_struct_name = "SignalBugTestcase", .function = { NULL, bug_testcase_free, NULL }, .flags = RUBY_TYPED_FREE_IMMEDIATELY }; VALUE bug_testcase_alloc(VALUE klass) { BugTestcase* obj = calloc(1, sizeof(BugTestcase)); return TypedData_Make_Struct(klass, BugTestcase, &bug_testcase_data_type, obj); } void Init_signal_bug_testcase(void) { VALUE cBugTestcase = rb_define_class("SignalBugTestcase", rb_cObject); rb_define_alloc_func(cBugTestcase, bug_testcase_alloc); } ``` ### Expectation and result No segfault happens. Interestingly, on Ruby 2.7, the VM exits half-way through but doesn't always segfault, but running it a few times always triggers the issue. On 3.2+ it crashes every time for me. I suspect the right thing here is to no longer accept/try to run any Ruby-level signal handlers after VM shutdown starts. Here's what I see with this test-case: ``` $ bundle exec ruby lib/signal-bug-testcase.rb Free getting called! Sending signal... SIGTERM signal queued, trying to release GVL... lib/signal-bug-testcase.rb:3: [BUG] Segmentation fault at 0x0000000000000007 ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0011 e:000010 CFUNC :puts c:0002 p:0005 s:0006 e:000005 BLOCK lib/signal-bug-testcase.rb:3 [FINISH] c:0001 p:0000 s:0003 E:0001a0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- lib/signal-bug-testcase.rb:3:in `block in <main>' lib/signal-bug-testcase.rb:3:in `puts' -- Machine register context ------------------------------------------------ RIP: 0x000070aa64cedbe7 RBP: 0x000070aa648e8fd0 RSP: 0x00007ffc5c057608 RAX: 0x0000000000004171 RBX: 0x00007ffc5c057630 RCX: 0x0000000000000001 RDX: 0x00007ffc5c057630 RDI: 0x0000000000000007 RSI: 0x0000000000004171 R8: 0x000000000000021b R9: 0x0000000000000000 R10: 0x000070aa63eff048 R11: 0x0000000000000000 R12: 0x000070aa648e8fd0 R13: 0x0000000000004171 R14: 0x0000000000000007 R15: 0x000070aa648e8ff0 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- ruby-3.2.2/lib/libruby.so.3.2(rb_print_backtrace+0xd) [0x70aa64d5bb5f] ruby-3.2.2/vm_dump.c:785 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_bugreport) ruby-3.2.2/vm_dump.c:1080 ruby-3.2.2/lib/libruby.so.3.2(rb_bug_for_fatal_signal+0xf4) [0x70aa64b52164] ruby-3.2.2/error.c:813 ruby-3.2.2/lib/libruby.so.3.2(sigsegv+0x4d) [0x70aa64cab0fd] ruby-3.2.2/signal.c:964 /lib/x86_64-linux-gnu/libc.so.6(0x70aa64642520) [0x70aa64642520] ruby-3.2.2/lib/libruby.so.3.2(hash_table_index+0x0) [0x70aa64cedbe7] ruby-3.2.2/symbol.h:72 ruby-3.2.2/lib/libruby.so.3.2(rb_id_table_lookup) ruby-3.2.2/id_table.c:230 ruby-3.2.2/lib/libruby.so.3.2(cached_callable_method_entry+0x24) [0x70aa64d356bb] ruby-3.2.2/vm_method.c:1295 ruby-3.2.2/lib/libruby.so.3.2(callable_method_entry_or_negative) ruby-3.2.2/vm_method.c:1365 ruby-3.2.2/lib/libruby.so.3.2(callable_method_entry) ruby-3.2.2/vm_method.c:1402 ruby-3.2.2/lib/libruby.so.3.2(rb_callable_method_entry) ruby-3.2.2/vm_method.c:1409 ruby-3.2.2/lib/libruby.so.3.2(gccct_method_search_slowpath+0x38) [0x70aa64d36258] ruby-3.2.2/vm_eval.c:434 ruby-3.2.2/lib/libruby.so.3.2(rb_call0+0x267) [0x70aa64d4e877] ruby-3.2.2/vm_eval.c:483 ruby-3.2.2/lib/libruby.so.3.2(rb_call+0x32) [0x70aa64d4f406] ruby-3.2.2/vm_eval.c:877 ruby-3.2.2/lib/libruby.so.3.2(rb_funcallv_kw) ruby-3.2.2/vm_eval.c:1074 ruby-3.2.2/lib/libruby.so.3.2(vm_call_cfunc_with_frame+0x127) [0x70aa64d30277] ruby-3.2.2/vm_insnhelper.c:3268 ruby-3.2.2/lib/libruby.so.3.2(vm_sendish+0x97) [0x70aa64d407a4] ruby-3.2.2/vm_insnhelper.c:5080 ruby-3.2.2/lib/libruby.so.3.2(vm_exec_core) ruby-3.2.2/insns.def:820 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_exec+0xd3) [0x70aa64d460d3] ruby-3.2.2/vm.c:2374 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_invoke_proc+0x5f) [0x70aa64d4bfcf] ruby-3.2.2/vm.c:1603 ruby-3.2.2/lib/libruby.so.3.2(vm_call0_body+0x5df) [0x70aa64d4c5cf] ruby-3.2.2/vm_eval.c:274 ruby-3.2.2/lib/libruby.so.3.2(vm_call0_cc+0x77) [0x70aa64d4e7e7] ruby-3.2.2/vm_eval.c:87 ruby-3.2.2/lib/libruby.so.3.2(rb_call0) ruby-3.2.2/vm_eval.c:551 ruby-3.2.2/lib/libruby.so.3.2(rb_call+0x32) [0x70aa64d4f406] ruby-3.2.2/vm_eval.c:877 ruby-3.2.2/lib/libruby.so.3.2(rb_funcallv_kw) ruby-3.2.2/vm_eval.c:1074 ruby-3.2.2/lib/libruby.so.3.2(rb_eval_cmd_kw+0x142) [0x70aa64d4f562] ruby-3.2.2/vm_eval.c:1923 ruby-3.2.2/lib/libruby.so.3.2(signal_exec+0xf6) [0x70aa64caae16] ruby-3.2.2/signal.c:1064 ruby-3.2.2/lib/libruby.so.3.2(rb_threadptr_execute_interrupts+0x36b) [0x70aa64cf7078] ruby-3.2.2/thread.c:2334 ruby-3.2.2/lib/libruby.so.3.2(rb_threadptr_execute_interrupts) ruby-3.2.2/thread.c:2291 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_check_ints+0xb) [0x70aa64cf7ac5] ruby-3.2.2/vm_core.h:1994 ruby-3.2.2/lib/libruby.so.3.2(rb_vm_check_ints) ruby-3.2.2/vm_core.h:1985 ruby-3.2.2/lib/libruby.so.3.2(unblock_function_set) ruby-3.2.2/thread.c:320 ruby-3.2.2/lib/libruby.so.3.2(blocking_region_begin) ruby-3.2.2/thread.c:1485 ruby-3.2.2/lib/libruby.so.3.2(rb_nogvl+0xbf) [0x70aa64cf90cf] ruby-3.2.2/thread.c:1548 signal-bug-testcase-2/lib/signal_bug_testcase.so(fprintf+0x0) [0x70aa6518f299] ../../../../ext/signal_bug_testcase/signal_bug_testcase.c:17 signal-bug-testcase-2/lib/signal_bug_testcase.so(bug_testcase_free) ../../../../ext/signal_bug_testcase/signal_bug_testcase.c:18 ruby-3.2.2/lib/libruby.so.3.2(run_final+0xf) [0x70aa64b73172] ruby-3.2.2/gc.c:4388 ruby-3.2.2/lib/libruby.so.3.2(finalize_list) ruby-3.2.2/gc.c:4407 ruby-3.2.2/lib/libruby.so.3.2(finalize_deferred_heap_pages) ruby-3.2.2/gc.c:4436 ruby-3.2.2/lib/libruby.so.3.2(rb_objspace_call_finalizer+0x350) [0x70aa64b80d70] ruby-3.2.2/gc.c:4573 ruby-3.2.2/lib/libruby.so.3.2(rb_ec_finalize+0x2a) [0x70aa64b5d6d1] ruby-3.2.2/eval.c:168 ruby-3.2.2/lib/libruby.so.3.2(rb_ec_cleanup) ruby-3.2.2/eval.c:262 ruby-3.2.2/lib/libruby.so.3.2(ruby_run_node+0x9d) [0x70aa64b5d91d] ruby-3.2.2/eval.c:330 ruby-3.2.2/bin/ruby(rb_main+0x21) [0x5d5d1295f187] ./main.c:38 ruby-3.2.2/bin/ruby(main) ./main.c:57 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x80) [0x70aa64629d90] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x70aa64629e40] ../csu/libc-start.c:392 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:379 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x5d5d1295f1d5] ``` ---Files-------------------------------- signal-bug-testcase-main.zip (7.73 KB) -- https://bugs.ruby-lang.org/

2 3

[ruby-core:118963] [Ruby master Feature#11273] [PATCH] Make it possible to `load` from a FIFO file
by alanwu (Alan Wu) 26 Aug '24

26 Aug '24

Issue #11273 has been updated by alanwu (Alan Wu). Status changed from Open to Closed Closing as we carry a test since commit:bc8687acd62584bf2ba9a951289f3f25a4de7229 that exercises this functionality. ---------------------------------------- Feature #11273: [PATCH] Make it possible to `load` from a FIFO file https://bugs.ruby-lang.org/issues/11273#change-109535 * Author: cesario (Franck Verrot) * Status: Closed ---------------------------------------- Revision #50887 (https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/50887) avoided `load` from blocking the VM when accessing a FIFO file, but loading from a FIFO doesn't work (raises `LoadError`). This patch makes it possible. PS: I wasn't sure it was a bug or a feature so I've set it to bug. Of course, feel free to fix this. ---Files-------------------------------- 0001-file.c-load-now-supports-reading-from-a-FIFO-file.patch (3.18 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118954] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 25 Aug '24

25 Aug '24

Issue #18368 has been updated by zverok (Victor Shepelev). Here we go: https://github.com/ruby/ruby/pull/11454 In the absence of further discussion, I went with option (3): String ranges support both “old” and “new” behavior. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-109527 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- 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:118953] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by nobu (Nobuyoshi Nakada) 25 Aug '24

25 Aug '24

Issue #6648 has been updated by nobu (Nobuyoshi Nakada). `-C` option arguments are cumulative and can be relative paths. I don't think `ruby -C subdir -e 'exec(*Process.argv)'` would work as expected. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109526 * 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