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

[ruby-core:115188] [Ruby master Bug#19977] (nil..nil) === x can raise an exception, differing from Range#cover?
by kyanagi (Kouhei Yanagita) 22 Dec '23

22 Dec '23

Issue #19977 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #19977: (nil..nil) === x can raise an exception, differing from Range#cover? https://bugs.ruby-lang.org/issues/19977 * Author: kyanagi (Kouhei Yanagita) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I investigated Range#=== and Range#cover?, and found that the only difference in behavior between them would be that `(nil..nil) === x` could throw an exception. ``` % ~/tmp/ruby-master/bin/ruby -v ruby 3.3.0dev (2023-10-27T03:13:17Z master f9f0cfe785) [arm64-darwin22] ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil) === "a"' -e:1:in `===': cannot determine inclusion in beginless/endless ranges (TypeError) p (nil..nil) === "a" ^^^ from -e:1:in `<main>' ``` ``` % ~/tmp/ruby-master/bin/ruby -e 'p (nil..nil).cover?("a")' true ``` Is this difference intended? According to NEWS, `Range#===` uses `cover?` since Ruby 2.6 (For `String`, since Ruby 2.7). Following this, `(nil..nil) === x` should not throw an exception in the same way as `(nil..nil).cover?(x)`. history: `(nil..nil) === "a"` throws an exception since https://github.com/ruby/ruby/commit/04a92a6. For "linear objects" (`Integer`, `Float`, `Numeric`, `Time`), it has beed fixed not to throw an exception on https://github.com/ruby/ruby/commit/fb17c83. related issues: * [Bug #15449] Range#=== is not using cover in Ruby 2.6 * [Bug #18580] Range#include? inconsistency for beginless String ranges * [Bug #19533] Behavior of ===/include? on a beginless/endless range (nil..nil) changed in ruby 3.2 -- https://bugs.ruby-lang.org/

2 5

[ruby-core:115824] [Ruby master Bug#20074] IRB/Pry search up arrow in 3.3 changed behaviour "\e[A": history-search-backward
by oleg_antonyan (Oleg Antonyan) 21 Dec '23

21 Dec '23

Issue #20074 has been reported by oleg_antonyan (Oleg Antonyan). ---------------------------------------- Bug #20074: IRB/Pry search up arrow in 3.3 changed behaviour "\e[A": history-search-backward https://bugs.ruby-lang.org/issues/20074 * Author: oleg_antonyan (Oleg Antonyan) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0rc1 (2023-12-11 master a49643340e) +YJIT [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In 3.3 since preview 1 this handy readline feature is kind of broken ``` shell $ cat ~/.inputrc "\e[A": history-search-backward "\e[B": history-search-forward ``` It supposed to search history by starting typing substring, you hit up arrow and it brings the line starting from this substring from the history. And it does that, but the problem is when you don't type anything and just hit up arrow it brings the latest history item and places the cursor at the beginning of line. Previously (up to 3.2.2) it used to put cursor at the end of the line. This is how it works pretty much everywhere (bash, for example, or in test C program that loops over `readline("> ")`), so the problem is in the way Ruby 3.3+ uses readline, but not readline itself. openSUSE Timbleweed 64bit kernel 6.6.6-1-default Ruby 3.3.0-rc1 (installed via rbenv or manually from source tarball - same behavior) libreadline 8.2 (but tried version 7 with teh same outcome) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115550] [Ruby master Bug#20031] Regexp using greedy quantifier and unions on a big string uses a lot of memory
by FabienChaynes (Fabien Chaynes) 21 Dec '23

21 Dec '23

Issue #20031 has been reported by FabienChaynes (Fabien Chaynes). ---------------------------------------- Bug #20031: Regexp using greedy quantifier and unions on a big string uses a lot of memory https://bugs.ruby-lang.org/issues/20031 * Author: FabienChaynes (Fabien Chaynes) * 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 ---------------------------------------- Trying to match on some regexp using a greedy quantifier on any character (`.*`) and unions (`foo|bar`) uses a lot of memory if the string we want to match on is big. # Reproduction code ```ruby puts RUBY_DESCRIPTION unless File.exist?("/tmp/fake_email.eml") content = "Accept-Language: fr-FR, en-US#{"0" * 50_000_000}" File.write("/tmp/fake_email.eml", content) end content = File.read("/tmp/fake_email.eml") def print_size(context, sike_kb) puts "#{context}: #{(sike_kb / 1024.0).round(1)} MB" end print_size("baseline", `ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"`.strip.split.map(&:to_i).last) print_size("content", content.bytesize / 1024) REGEXP_UNION = Regexp.union( "Accept-Language:", "Thread-Topic:", ).freeze reg = /.*#{REGEXP_UNION}/ p reg GC.start print_size("before match?", `ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"`.strip.split.map(&:to_i).last) allocated = GC.stat(:total_allocated_objects) p content.match(reg) p GC.stat(:total_allocated_objects) - allocated GC.start print_size("after match?", `ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"`.strip.split.map(&:to_i).last) p "---" ``` Output: ```bash $ /usr/bin/time -v ruby full_repro.rb ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux] baseline: 71.3 MB content: 47.7 MB /.*(?-mix:Accept\-Language:|Thread\-Topic:)/ before match?: 71.3 MB #<MatchData "Accept-Language:"> 14 after match?: 71.6 MB "---" Command being timed: "ruby full_repro.rb" User time (seconds): 1.15 System time (seconds): 0.74 Percent of CPU this job got: 100% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.89 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2423108 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 609575 Voluntary context switches: 52 Involuntary context switches: 12 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 ``` strace: ```bash $ sudo strace -p 588834 strace: Process 588834 attached [...] mmap(NULL, 249856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e92dd3000 mremap(0x7f8e92dd3000, 249856, 495616, MREMAP_MAYMOVE) = 0x7f8e92d5a000 mremap(0x7f8e92d5a000, 495616, 987136, MREMAP_MAYMOVE) = 0x7f8e92c69000 mremap(0x7f8e92c69000, 987136, 1970176, MREMAP_MAYMOVE) = 0x7f8e92a88000 mremap(0x7f8e92a88000, 1970176, 3936256, MREMAP_MAYMOVE) = 0x7f8e926c7000 mremap(0x7f8e926c7000, 3936256, 7868416, MREMAP_MAYMOVE) = 0x7f8e91f46000 mremap(0x7f8e91f46000, 7868416, 15732736, MREMAP_MAYMOVE) = 0x7f8e91045000 mremap(0x7f8e91045000, 15732736, 31461376, MREMAP_MAYMOVE) = 0x7f8e8a8af000 mremap(0x7f8e8a8af000, 31461376, 62918656, MREMAP_MAYMOVE) = 0x7f8e86cae000 mremap(0x7f8e86cae000, 62918656, 125833216, MREMAP_MAYMOVE) = 0x7f8e7f4ad000 mremap(0x7f8e7f4ad000, 125833216, 251662336, MREMAP_MAYMOVE) = 0x7f8e704ac000 mremap(0x7f8e704ac000, 251662336, 503320576, MREMAP_MAYMOVE) = 0x7f8e524ab000 mremap(0x7f8e524ab000, 503320576, 1006637056, MREMAP_MAYMOVE) = 0x7f8e164aa000 mremap(0x7f8e164aa000, 1006637056, 2013270016, MREMAP_MAYMOVE) = 0x7f8d9e4a9000 mremap(0x7f8d9e4a9000, 2013270016, 4026535936, MREMAP_MAYMOVE) = 0x7f8cae4a8000 mmap(NULL, 12500992, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8e92224000 munmap(0x7f8cae4a8000, 4026535936) = 0 munmap(0x7f8e92224000, 12500992) = 0 writev(1, [{iov_base="#<MatchData \"Accept-Language:\">", iov_len=31}, {iov_base="\n", iov_len=1}], 2) = 32 [...] ``` We can see that the memory retained by Ruby is low (71.6 MB), but `content.match(reg)` used 2_423_108 kbytes (~2.4 GB) in the regex engine. # Findings To reproduce we need: - a greedy quantifier on any character (`.*`) - a union with at least two members (`foo|bar`). More members won't increase the memory consumption further - to perform the match on a long string The memory seems to increase linearly against the string size: |String size |Memory consumed | |--|--| | 11.9 MB | 629_988 kbytes | | 23.8 MB | 1_235_976 kbytes | | 47.7 MB | 2_423_076 kbytes | I was able to reproduce it on old Ruby versions as well. @byroot helped me to put all this together and according to his investigation the memory allocation would be coming from `regexec.c:4100` (https://github.com/ruby/ruby/blob/85092ecd6f5c4d12d0cb1d6dfa7040337a4f558b/…) ``` size_t match_cache_buf_length = (num_match_cache_points >> 3) + (num_match_cache_points & 7 ? 1 : 0) + 1; uint8_t* match_cache_buf = (uint8_t*)xmalloc(match_cache_buf_length * sizeof(uint8_t)); ``` It seems surprising to use that much memory compared to the string size. Is it expected? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115459] [Ruby master Bug#20017] 3.3.0dev `rb_thread_profile_frames` crashes when `RUBY_MN_THREADS=1`
by byroot (Jean Boussier) 20 Dec '23

20 Dec '23

Issue #20017 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20017: 3.3.0dev `rb_thread_profile_frames` crashes when `RUBY_MN_THREADS=1` https://bugs.ruby-lang.org/issues/20017 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.3.0dev (2023-11-19T03:01:05Z shopify 9aee12cc28) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I discovered this while running our internal CI with MaNy enabled, our application crash when trying to profile with StackProf (with postponed jobs disabled): ``` [BUG] Segmentation fault at 0x0000000000000010 ruby 3.3.0dev (2023-11-19T03:01:05Z shopify 9aee12cc28) +MN [x86_64-linux] -- C level backtrace information ------------------------------------------- /usr/local/ruby/bin/ruby(rb_print_backtrace+0x14) [0x55c8f16333e1] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/vm_dump.c:812 /usr/local/ruby/bin/ruby(rb_vm_bugreport) /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/vm_dump.c:1143 /usr/local/ruby/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x55c8f17e559c] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/error.c:1065 /usr/local/ruby/bin/ruby(sigsegv+0x4d) [0x55c8f158091d] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/signal.c:920 /lib/x86_64-linux-gnu/libc.so.6(0x7ff3db333520) [0x7ff3db333520] /usr/local/ruby/bin/ruby(thread_profile_frames+0x10) [0x55c8f162efd0] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/vm_backtrace.c:1587 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_buffer_sample+0x28) [0x7ff3b7d2435c] /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:622 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_buffer_sample) /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:604 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_buffer_sample) (null):0 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler+0x5) [0x7ff3b7d24545] /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:767 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler) /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:722 /lib/x86_64-linux-gnu/libc.so.6(0x7ff3db333520) [0x7ff3db333520] /lib/x86_64-linux-gnu/libc.so.6(pthread_cond_wait+0x24a) [0x7ff3db384a7a] /usr/local/ruby/bin/ruby(rb_native_cond_wait+0xb) [0x55c8f15c8cbb] /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/thread_pthread.c:214 /usr/local/ruby/bin/ruby(ractor_sched_deq) /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/thread_pthread.c:1230 /usr/local/ruby/bin/ruby(nt_start) /tmp/ruby-build/ruby-3.3.0-9aee12cc28cbca40306784e54e38558688caa9f7/thread_pthread.c:2209 ``` For additional context, as far as I know `rb_thread_profile_frames` isn't officially async signal safe, but it happens to be since 3.0 for the interpreter, and 3.3 for YJIT, so StackProf tries not to use postponed jobs for profiling when it can as it leads to much more accurate profiling results. Ref: https://github.com/tmm1/stackprof/issues/221 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115458] [Ruby master Bug#20016] 3.3.0dev `rb_postponed_job_register_one` crashes when `RUBY_MN_THREADS=1`
by byroot (Jean Boussier) 20 Dec '23

20 Dec '23

Issue #20016 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #20016: 3.3.0dev `rb_postponed_job_register_one` crashes when `RUBY_MN_THREADS=1` https://bugs.ruby-lang.org/issues/20016 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.3.0dev (2023-11-22T17:01:13Z shopify c1fc1a00ea) +MN [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I discovered this while running our internal CI with MaNy enabled, our application crash when trying to profile with StackProf: ``` [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.0dev (2023-11-22T17:01:13Z shopify c1fc1a00ea) +MN [x86_64-linux] -- Machine register context ------------------------------------------------ RIP: 0x000055df5fe38489 RBP: 0x00007f517bc59000 RSP: 0x00007f5123f3c6d0 RAX: 0x0000000000000000 RBX: 0x00007f51596554e0 RCX: 0x00007f517bdb6b40 RDX: 0x0000000000000001 RDI: 0x00007f517bc59000 RSI: 0x0000000000000000 R8: 0x0000000000000000 R9: 0x00000000ffffffff R10: 0x0000000000000000 R11: 0x0000000000000246 R12: 0x0000000000000000 R13: 0x0000000000000000 R14: 0x0000000000001ea5 R15: 0x00007f517bc59104 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /usr/local/ruby/bin/ruby(rb_print_backtrace+0x14) [0x55df5fe328e1] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_dump.c:812 /usr/local/ruby/bin/ruby(rb_vm_bugreport) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_dump.c:1143 /usr/local/ruby/bin/ruby(rb_bug_for_fatal_signal+0xfc) [0x55df5ffe509c] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/error.c:1065 /usr/local/ruby/bin/ruby(sigsegv+0x4d) [0x55df5fd7f19d] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/signal.c:920 /lib/x86_64-linux-gnu/libc.so.6(0x7f517c277520) [0x7f517c277520] /usr/local/ruby/bin/ruby(rbimpl_atomic_or+0x0) [0x55df5fe38489] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1691 /usr/local/ruby/bin/ruby(postponed_job_register) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1693 /usr/local/ruby/bin/ruby(postponed_job_register) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1675 /usr/local/ruby/bin/ruby(rb_postponed_job_register_one) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/vm_trace.c:1746 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler+0x2d) [0x7f5159655434] /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:763 /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/lib/stackprof/stackprof.so(stackprof_signal_handler) /tmp/bundle/ruby/3.3.0+0/gems/stackprof-0.2.25/ext/stackprof/stackprof.c:722 /lib/x86_64-linux-gnu/libc.so.6(0x7f517c277520) [0x7f517c277520] /lib/x86_64-linux-gnu/libc.so.6(0x7f517c2c6117) [0x7f517c2c6117] /lib/x86_64-linux-gnu/libc.so.6(pthread_cond_wait+0x211) [0x7f517c2c8a41] /usr/local/ruby/bin/ruby(rb_native_cond_wait+0xb) [0x55df5fdc75fb] /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/thread_pthread.c:214 /usr/local/ruby/bin/ruby(ractor_sched_deq) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/thread_pthread.c:1230 /usr/local/ruby/bin/ruby(nt_start) /tmp/ruby-build/ruby-3.3.0-c1fc1a00ea9633961153451d0e927db49c1b268d/thread_pthread.c:2209 /lib/x86_64-linux-gnu/libc.so.6(0x7f517c2c9ac3) [0x7f517c2c9ac3] ``` Ref: https://github.com/tmm1/stackprof/issues/221 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:115648] [Ruby master Feature#20049] Destructive drop_while for Array and Hash
by chucke (Tiago Cardoso) 20 Dec '23

20 Dec '23

Issue #20049 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #20049: Destructive drop_while for Array and Hash https://bugs.ruby-lang.org/issues/20049 * Author: chucke (Tiago Cardoso) * Status: Open * Priority: Normal ---------------------------------------- I propose a "drop_while!" variant for arrays and hashes, which changes the current instance. ```ruby h = {foo: 0, bar: 1, baz: 2} h.drop_while!{|element| key, value = *element; value < 2 } h #=> # => { baz: 2 } ``` -- https://bugs.ruby-lang.org/

4 7

[ruby-core:112262] [Ruby master Feature#19422] Make `--enabled-shared` mandatory on macOS
by nobu (Nobuyoshi Nakada) 20 Dec '23

20 Dec '23

Issue #19422 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #19422: Make `--enabled-shared` mandatory on macOS https://bugs.ruby-lang.org/issues/19422 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal ---------------------------------------- From the troubles around linker on macOS, I propose `--enable-shared` option mandatory on macOS. This patch enables the option by default, and abort if `--disable-shared` option is given explicitly. ```diff diff --git i/configure.ac w/configure.ac index 7db2ab5257c..923ac7d1199 100644 --- i/configure.ac +++ w/configure.ac @@ -504,6 +504,11 @@ AS_CASE(["$target_os"], rb_cv_binary_elf=no : ${enable_shared=yes} ], +[darwin*], [ + AS_IF([test "${enable_shared=yes}" = no], [ + AC_MSG_ERROR([--disable-shared is not supported on this platform]) + ]) +], [hiuxmpp*], [AC_DEFINE(__HIUX_MPP__)]) # by TOYODA Eizi <toyoda(a)npd.kishou.go.jp> AC_PROG_LN_S @@ -3055,14 +3060,7 @@ AC_SUBST(EXTOBJS) : ${LDFLAGS=""} : ${LIBPATHENV=DYLD_FALLBACK_LIBRARY_PATH} : ${PRELOADENV=DYLD_INSERT_LIBRARIES} - AS_IF([test x"$enable_shared" = xyes], [ - # Resolve symbols from libruby.dylib when --enable-shared - EXTDLDFLAGS='$(LIBRUBYARG_SHARED)' - ], [test "x$EXTSTATIC" = x], [ - # When building exts as bundles, a mach-o bundle needs to know its loader - # program to bind symbols from the ruby executable - EXTDLDFLAGS="-bundle_loader '\$(BUILTRUBY)'" - ]) + EXTDLDFLAGS='$(LIBRUBYARG_SHARED)' rb_cv_dlopen=yes], [aix*], [ : ${LDSHARED='$(CC)'} AS_IF([test "$GCC" = yes], [ @@ -3356,10 +3354,6 @@ AS_IF([test x"$cross_compiling" = xyes], [ AC_SUBST(XRUBY_RUBYLIBDIR) AC_SUBST(XRUBY_RUBYHDRDIR) PREP='$(arch)-fake.rb' - AS_CASE(["$enable_shared:$EXTSTATIC:$target_os"], [no::darwin*], [ - # darwin target requires miniruby for linking ext bundles - PREP="$PREP"' miniruby$(EXEEXT)' - ]) RUNRUBY_COMMAND='$(MINIRUBY) -I`cd $(srcdir)/lib; pwd`' RUNRUBY='$(RUNRUBY_COMMAND)' XRUBY='$(MINIRUBY)' ``` -- https://bugs.ruby-lang.org/

4 7

[ruby-core:115667] [Ruby master Bug#20052] reline behaves oddly with redirect (non tty)
by mtasaka (Mamoru Tasaka) 20 Dec '23

20 Dec '23

Issue #20052 has been reported by mtasaka (Mamoru Tasaka). ---------------------------------------- Bug #20052: reline behaves oddly with redirect (non tty) https://bugs.ruby-lang.org/issues/20052 * Author: mtasaka (Mamoru Tasaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-09 master 1cbe114d1c) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Forwarded from cucumber/aruba testsute issue https://github.com/cucumber/aruba/issues/910 Looks line reline behaves oddly with redirect (non tty) With `ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]` and `Readline`: ``` $ echo 'foo' | ruby -e 'require "readline"; puts Readline.readline(">")' > bar.log ; cat bar.log >foo foo ``` With `ruby 3.3.0dev (2023-12-09 master 1cbe114d1c) [x86_64-linux]` and `Reline`: ``` $ echo 'foo' | ruby -e 'require "reline"; puts Reline.readline(">")' > bar.log ; cat bar.log >>>f>f>fo>fo>foo>foofoo ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-core:115669] [Ruby master Feature#20053] M:N Threads, now w/ macOS support (kqueue)
by jpcamara (JP Camara) 20 Dec '23

20 Dec '23

Issue #20053 has been reported by jpcamara (JP Camara). ---------------------------------------- Feature #20053: M:N Threads, now w/ macOS support (kqueue) https://bugs.ruby-lang.org/issues/20053 * Author: jpcamara (JP Camara) * Status: Open * Priority: Normal ---------------------------------------- I have a PR here that adds support for macOS to M:N threads using `kqueue`: https://github.com/ruby/ruby/pull/9178 It adds in `kqueue`/`kevent` calls when present in the OS. Technically this would open up support for FreeBSD as well, but I don't have a way of testing that so i'm not sure how well it does or doesn't work there. I wanted to get support going for macOS so more devs can try out M:N threads and test it. I do think there should be a larger discussion around the potential relationship between this and some of the awesome fiber scheduler work over the last few years (and the potential of utilizing anything from io-event?). But that can be a topic for another day - let's get macOS support in the meantime! Disclaimer: C isn't my day-to-day language, so I could definitely use feedback there. I'm also more of a kernel event queue (kqueue, epoll, io_uring) _enthusiast_, but `kqueue` isn't something I have specific experience writing with - just lots of reading code and small toy code up until this point. So someone like @ioquatix would probably be a good person to get eyes on it. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:115814] [Ruby master Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by Quintasan 20 Dec '23

20 Dec '23

Issue #18915 has been updated by Quintasan (Michał Zając). matz (Yukihiro Matsumoto) wrote in #note-14: > #note-13 explains my opinion well. What name candidate do you have? > > Matz. How about `AbstractMethodError` - the same as Java? ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-105763 * Author: Quintasan (Michał Zając) * Status: Open * Priority: Normal ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0