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

[ruby-core:114869] [Ruby master Feature#13933] Add Range#empty?
by duerst 22 Sep '23

22 Sep '23

Issue #13933 has been updated by duerst (Martin Dürst). Dan0042 (Daniel DeLorme) wrote in #note-9: > because `true<=>true` is 0 (and arguably it should be nil but that's another topic). Are you saying that true shouldn't be equal to true? That would be strange, at least to me. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104717 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114866] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by ccaviness (Clay Caviness) 21 Sep '23

21 Sep '23

Issue #18286 has been updated by ccaviness (Clay Caviness). https://github.com/ruby/ruby/pull/7367 fixes this, and just needs to be merged. ---------------------------------------- Bug #18286: Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64 https://bugs.ruby-lang.org/issues/18286#change-104714 * Author: ccaviness (Clay Caviness) * Status: Open * Priority: Normal * ruby -v: 3.0.2 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- A universal arm64/x86_84 ruby binary for macOS built on a x86_64 machine segfaults/is killed when executed on an arm64 machine. To reproduce: * On an Intel Mac: `git clone https://github.com/ruby/ruby && cd ruby && git checkout v3_0_2 && ./autogen.sh && ./configure --with-arch=arm64,x86_64 && make -j$(sysctl -n hw.ncpu)` * Copy the built `./ruby` binary to an Apple Silicon machine * Attempt to execute it Expected: The universal `ruby` binary works correctly on both devices Actual: The universal `ruby` binary crashes with either `Segmentation fault: 11` or `Killed: 9` (this seems to occur if `arm64e` is used instead of `arm64`). Details: I'm attempting to build a universal Ruby for macOS that will run on both Intel (x86_64) and Apple Silicon (arm64) machines. It seemed initially that this was as easy as adding `--with-arch=arm64,x86_64` to `./configure` would do it, as it produced a `ruby` binary that reports as `Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]` This `ruby` works correctly on the Intel machine I built in on, but does not work when copied to an Apple Silicon device. The reverse, however, seems to work. That is, if I build the universal ruby on an Apple Silicon machine, the `ruby` binary that's built seems to work correctly on both Intel and Apple Silicon machines. Intel: ``` $ ./ruby -v ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [universal.x86_64-darwin21] ``` Apple Silicon: ``` $ ./ruby -v Segmentation fault: 11 $ lldb ./ruby (lldb) target create "./ruby" Current executable set to '/Users/crc/ruby' (arm64). (lldb) run Process 77071 launched: '/Users/crc/ruby' (arm64) Process 77071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: 0x00000001002176b8 ruby`ruby_vm_special_exception_copy + 16 ruby`ruby_vm_special_exception_copy: -> 0x1002176b8 <+16>: ldr x0, [x0, #0x8] 0x1002176bc <+20>: bl 0x10011fed8 ; rb_class_real 0x1002176c0 <+24>: bl 0x10012070c ; rb_obj_alloc 0x1002176c4 <+28>: mov x20, x0 Target 0: (ruby) stopped. (lldb) ^D ``` I also attempted the same thing with ruby 2.7.4 source, with the same result. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114865] [Ruby master Bug#18911] Process._fork hook point is not called when Process.daemon is used
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #18911 has been updated by Dan0042 (Daniel DeLorme). Note for future readers coming here from the `Process._fork` documentation. If you need to restart threads, you should override both `_fork` and `daemon` ```ruby module RestartWatcherThread def _fork pid = super restart_thread if pid == 0 pid end def daemon(...) super.tap{ restart_thread } end prepend_features(Process.singleton_class) end ``` ---------------------------------------- Bug #18911: Process._fork hook point is not called when Process.daemon is used https://bugs.ruby-lang.org/issues/18911#change-104713 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal * Assignee: akr (Akira Tanaka) * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin20] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Hello there! I'm working at Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb), and we need to hook into fork operations to make sure that our products work correctly/automatically even in environments that fork. As part as #17795 a new `Process._fork` method was added to allow libraries and frameworks to easily hook into fork operations. I was investigating its use in `ddtrace` and noticed the following gap: the `Process.daemon` API internally makes use of `fork`, but the new hook point is not called for that API. Testcase: ```ruby puts RUBY_DESCRIPTION module ForkHook def _fork(*args) puts " #{Process.pid} Before fork!" res = super puts " #{Process.pid} After fork!" res end end Process.singleton_class.prepend(ForkHook) puts "#{Process.pid} Regular fork:" fork { exit } Process.wait puts "#{Process.pid} Process.daemon:" Process.daemon(nil, true) puts "#{Process.pid} Finishing!" ``` Testcase output: ``` ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin20] 48136 Regular fork: # <-- original process 48136 Before fork! 48136 After fork! # <-- original process 48137 After fork! # <-- child process 48136 Process.daemon: # <-- original process 48139 Finishing! # <-- forks and pid changes, but the hook isn't called ``` This was surprising to me since the advantage of this hook point would not not needing to hook into the many other places where `fork` can get called from. Thanks a lot :) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114863] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). akr (Akira Tanaka) wrote in #note-8: > Range#empty? should work with them. Ok for `Float::INFINITY, [], ""`, but I don't think `true, false, Object.new` are relevant. A Range object normally has a begin and end, and if the values are not comparable (like `"a"..1`) we get "ArgumentError (bad value for range)". With `true..true` we happen to coincidentally pass that validation because `true<=>true` is 0 (and arguably it should be nil but that's another topic). But semantically, as a range, `true..true` doesn't mean anything. The introduction of beginless/endless ranges also mean that we can now create all kinds of ranges that skip the normal validation. `(true..true)` and `(true..)` and `(..true)` are not semantically meaningful ranges, there is no use case for them, and therefore it doesn't matter that `#include?` raises an error, and it shouldn't matter what is returned by `#empty?` But unlike `true`, arrays truly are comparable. The Comparable module is not mixed in, but <=> can return -1 and 1. So `[]` is truly a minimum value for arrays. It could be special-cased. Although I'm not sure it's worth the trouble. Or maybe we can define a range "r" as empty if `r.begin.nil? and r.exclude_end? and r.end.respond_to?(:empty?) and r.end.empty?` Random idea: beginless/endless ranges may only be created for objects that mix in `Comparable`. So `(Time.now..)` is ok but `(Object.new..)` raises "ArgumentError (bad value for range)" ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104711 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114862] [Ruby master Feature#13933] Add Range#empty?
by akr (Akira Tanaka) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by akr (Akira Tanaka). I described that this is difficult to implement in https://bugs.ruby-lang.org/issues/19839#note-18. The problem is not only with -Float::INFINITY. There are many minimum values other than -Float::INFINITY : [], "", true, false, Object.new, etc. Of course, a user may define a class with a minimum value. Range#empty? should work with them. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104710 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114332] [Ruby master Bug#19794] Ruby 3.2.2 fails to build on macOS Sonoma betas
by jhaungs (Jim Haungs) 21 Sep '23

21 Sep '23

Issue #19794 has been reported by jhaungs (Jim Haungs). ---------------------------------------- Bug #19794: Ruby 3.2.2 fails to build on macOS Sonoma betas https://bugs.ruby-lang.org/issues/19794 * Author: jhaungs (Jim Haungs) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- With Big Sur, Apple deprecated putting dylibs in /usr/local/lib. In Sonoma (beta 4), this directory has disappeared completely. However, ruby's configure script depends on its existence. So, virtually every ruby installer (RVM, rbenv, asdf, ruby-build, and even building from source tarball) fails. When building ruby 3.2.2 from source, the configure step outputs the irritatingly useless "something wrong with LDFLAGS" error message and fails to build. The solution was to `cd /usr/local; sudo mkdir lib` to create the missing lib directory under /usr/local. It would be nice to remove this dependency from the configure script. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:114855] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). It was an ad-hoc example that just seemed to me like it should return true. As to how to define it... maybe we can say that numeric ranges are equivalent to `begin == -Float::INFINITY` if beginless, and `end == +Float::INFINITY` if endless. Then it would be like saying `(k...k).empty?` with `k == -Float::INFINITY` ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104702 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114853] [Ruby master Feature#13933] Add Range#empty?
by nobu (Nobuyoshi Nakada) 21 Sep '23

21 Sep '23

Issue #13933 has been updated by nobu (Nobuyoshi Nakada). Dan0042 (Daniel DeLorme) wrote in #note-5: > ```ruby > (...-Float::INFINITY).empty? #=> true > ``` How do you define this? `Range#empty?` must know if the element is a `Float`, and negative infinity? ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104699 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114846] [Ruby master Bug#19895] Memory leak in Ripper#sexp_raw called with invalid syntax
by jemmai (Jemma Issroff) 20 Sep '23

20 Sep '23

Issue #19895 has been reported by jemmai (Jemma Issroff). ---------------------------------------- Bug #19895: Memory leak in Ripper#sexp_raw called with invalid syntax https://bugs.ruby-lang.org/issues/19895 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is a memory leak in `Ripper#sexp_raw` with invalid syntax I used [the ruby_memcheck gem](https://github.com/Shopify/ruby_memcheck) to find this leak. # Script to reproduce: ``` $ ruby_memcheck -e 'require "ripper"; Ripper.sexp_raw("break 1,;")' ``` # Stack trace ``` 64 bytes in 1 blocks are definitely lost in loss record 8,335 of 11,879 malloc (at /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) objspace_xmalloc0 (gc.c:11465) *vtable_alloc_gen (ripper.y:6209) *local_push.constprop.0 (ripper.y:12587) *ripper_yyparse (ripper.y:1329) *ripper_parse0 (ripper.y:13817) rb_ensure (eval.c:997) *ripper_parse (ripper.y:13855) vm_call_cfunc_with_frame (vm_insnhelper.c:3037) vm_sendish (vm_insnhelper.c:4751) vm_exec_core (insns.def:778) rb_vm_exec (vm.c:2220) rb_ec_exec_node (eval.c:280) ruby_run_node (eval.c:321) main (main.c:47) 88 (24 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 8,508 of 11,879 malloc (at /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) objspace_xmalloc0 (gc.c:11465) *vtable_alloc_gen (ripper.y:6206) *local_push.constprop.0 (ripper.y:12586) *ripper_yyparse (ripper.y:1329) *ripper_parse0 (ripper.y:13817) rb_ensure (eval.c:997) *ripper_parse (ripper.y:13855) vm_call_cfunc_with_frame (vm_insnhelper.c:3037) vm_sendish (vm_insnhelper.c:4751) vm_exec_core (insns.def:778) rb_vm_exec (vm.c:2220) rb_ec_exec_node (eval.c:280) ruby_run_node (eval.c:321) main (main.c:47) Valgrind reported errors (e.g. memory leak or use-after-free) (RuntimeError) ``` # Expected behavior The [`Ripper#sexp_raw` docs](https://docs.ruby-lang.org/en/master/Ripper.html#method-c-sexp_raw) state that "By default, this method does not handle syntax errors in src, returning nil in such cases." Expected behavior, according to the documentation, would be `nil` returned without any memory leak -- https://bugs.ruby-lang.org/

1 1

[ruby-core:114845] [Ruby master Feature#13933] Add Range#empty?
by Dan0042 (Daniel DeLorme) 20 Sep '23

20 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). Since 6 years ago, beginless and endless ranges have been added, so `#none?` is no longer sufficient. ```ruby (nil..0).none? #=> TypeError (can't iterate from NilClass) ``` And as mentioned above `Range#size` doesn't work for String ranges. So I think it would be good to have `Range#empty?`, with cover-based semantics rather than succ-based: ```ruby (1..0).empty? #=> true (1..1).empty? #=> false (1...1).empty? #=> true ("a".."b").empty? #=> false ("b".."a").empty? #=> true (nil..0).empty? #=> false (..-Float::INFINITY).empty? #=> false (...-Float::INFINITY).empty? #=> true ``` ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104692 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Range already responds to #size. It would be nice if it also responded to predicate #empty? :-) -- https://bugs.ruby-lang.org/

1 0