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

[ruby-core:112577] [Ruby master Bug#18572] Performance regression when invoking refined methods
by Eregon (Benoit Daloze) 24 Feb '23

24 Feb '23

Issue #18572 has been updated by Eregon (Benoit Daloze). Interesting, maybe this is partly the cause for the `13 seconds` mentioned in https://shopify.engineering/the-case-against-monkey-patching. Maybe we should deprecate refinements: my main concern about them is it's a ton of complexity in Ruby implementations (in method lookup and even worse in super method lookup) and it's not really used much or gains much, so it does not seem worth it. It does make every uncached/cache-filling method lookup slower. It shouldn't make cached method lookup slower though when no refinements are active in that scope, at least it does not currently in TruffleRuby. For context-independent JITed code there is no clear solution when using refinements, i.e., it might just be uncached lookups (i.e., several hashmap lookups) for calls affected by refinements (calls after `using`), which is terrible performance-wise. Maybe there is a complex solution to fix it but I'm not sure it's worth the complexity and it of course increases further the maintenance cost of refinements. ---------------------------------------- Bug #18572: Performance regression when invoking refined methods https://bugs.ruby-lang.org/issues/18572#change-102026 * Author: palkan (Vladimir Dementyev) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Since Ruby 3.0, defining a refinement for a method slows down its execution even if we do not activate the refinement: ```ruby require "benchmark_driver" source = <<~RUBY class Hash def symbolize_keys transform_keys { |key| key.to_sym rescue key } end def refined_symbolize_keys transform_keys { |key| key.to_sym rescue key } end end module HashRefinements refine Hash do def refined_symbolize_keys raise "never called" end end end HASH = {foo: 1, bar: 2, baz: 3} class Foo def original end def refined end end module FooRefinements refine Foo do def refined raise "never called" end end end FOO = Foo.new RUBY Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "#symbolize_keys original", %{ HASH.symbolize_keys } x.report "#symbolize_keys refined", %{ HASH.refined_symbolize_keys } end Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "no-op original", %{ FOO.original } x.report "no-op refined", %{ FOO.refined } end ``` The results for Ruby 3.1: ```sh ... Comparison: #symbolize_keys original: 2372420.1 i/s #symbolize_keys refined: 1941019.0 i/s - 1.22x slower ... Comparison: no-op original: 51790974.2 i/s no-op refined: 14456518.9 i/s - 3.58x slower ``` For Ruby 2.6 and 2.7: ```sh Comparison: #symbolize_keys original: 2278339.7 i/s #symbolize_keys refined: 2264153.1 i/s - 1.01x slower ... Comparison: no-op refined: 64178338.5 i/s no-op original: 63357980.1 i/s - 1.01x slower ``` You can find the full code and more results in this [gist](https://gist.github.com/palkan/637dc83edd86d70b5dbf72f2a4d702e5). P.S. The problem was originally noticed by @byroot, see https://github.com/ruby-i18n/i18n/pull/573 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112574] [Ruby master Bug#18572] Performance regression when invoking refined methods
by palkan (Vladimir Dementyev) 24 Feb '23

24 Feb '23

Issue #18572 has been updated by palkan (Vladimir Dementyev). Checked Ruby 3.2—better than Ruby 3.1 but still noticeable: ```sh Comparison: #symbolize_keys original: 4362026.0 i/s #symbolize_keys refined: 3999755.6 i/s - 1.09x slower Comparison: no-op original: 80631273.5 i/s no-op refined: 29181553.6 i/s - 2.76x slower ``` ---------------------------------------- Bug #18572: Performance regression when invoking refined methods https://bugs.ruby-lang.org/issues/18572#change-102023 * Author: palkan (Vladimir Dementyev) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Since Ruby 3.0, defining a refinement for a method slows down its execution even if we do not activate the refinement: ```ruby require "benchmark_driver" source = <<~RUBY class Hash def symbolize_keys transform_keys { |key| key.to_sym rescue key } end def refined_symbolize_keys transform_keys { |key| key.to_sym rescue key } end end module HashRefinements refine Hash do def refined_symbolize_keys raise "never called" end end end HASH = {foo: 1, bar: 2, baz: 3} class Foo def original end def refined end end module FooRefinements refine Foo do def refined raise "never called" end end end FOO = Foo.new RUBY Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "#symbolize_keys original", %{ HASH.symbolize_keys } x.report "#symbolize_keys refined", %{ HASH.refined_symbolize_keys } end Benchmark.driver do |x| x.prelude %Q{ #{source} } x.report "no-op original", %{ FOO.original } x.report "no-op refined", %{ FOO.refined } end ``` The results for Ruby 3.1: ```sh ... Comparison: #symbolize_keys original: 2372420.1 i/s #symbolize_keys refined: 1941019.0 i/s - 1.22x slower ... Comparison: no-op original: 51790974.2 i/s no-op refined: 14456518.9 i/s - 3.58x slower ``` For Ruby 2.6 and 2.7: ```sh Comparison: #symbolize_keys original: 2278339.7 i/s #symbolize_keys refined: 2264153.1 i/s - 1.01x slower ... Comparison: no-op refined: 64178338.5 i/s no-op original: 63357980.1 i/s - 1.01x slower ``` You can find the full code and more results in this [gist](https://gist.github.com/palkan/637dc83edd86d70b5dbf72f2a4d702e5). P.S. The problem was originally noticed by @byroot, see https://github.com/ruby-i18n/i18n/pull/573 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112573] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by benhamilton (Ben Hamilton) 24 Feb '23

24 Feb '23

Issue #18286 has been updated by benhamilton (Ben Hamilton). I also reproduced the `SIGSEGV` from the original bug using a build with debug symbols: ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8) * frame #0: 0x00000001002444b4 ruby`ruby_vm_special_exception_copy [inlined] RBASIC_CLASS(obj=0) at rbasic.h:155:25 frame #1: 0x00000001002444b4 ruby`ruby_vm_special_exception_copy(exc=0) at vm_insnhelper.c:52:42 frame #2: 0x0000000100244584 ruby`ec_stack_overflow(ec=0x0000000100704920, setup=1) at vm_insnhelper.c:65:16 frame #3: 0x0000000100244504 ruby`rb_ec_stack_overflow(ec=0x0000000100704920, crit=0) at vm_insnhelper.c:97:5 frame #4: 0x000000010026b544 ruby`rb_call0(ec=0x0000000100704920, recv=4300956680, mid=3121, argc=1, argv=0x000000016fdff3e0, call_scope=<unavailable>, self=4) at rgengc.h:0:9 frame #5: 0x000000010013ca30 ruby`rb_class_new_instance [inlined] rb_class_new_instance_kw(argc=1, argv=0x000000016fdff3e0, klass=<unavailable>, kw_splat=0) at object.c:2025:5 frame #6: 0x000000010013c9f0 ruby`rb_class_new_instance(argc=1, argv=0x000000016fdff3e0, klass=<unavailable>) at object.c:2033:12 frame #7: 0x00000001000953c0 ruby`rb_exc_new_str(etype=<unavailable>, str=4300956720) at error.c:1145:12 frame #8: 0x000000010025d668 ruby`rb_vm_register_special_exception_str(sp=ruby_error_reenter, cls=<unavailable>, mesg=<unavailable>) at vm.c:2872:17 frame #9: 0x00000001000a1d50 ruby`Init_eval at eval.c:2091:5 frame #10: 0x00000001000d51fc ruby`rb_call_inits at inits.c:41:5 frame #11: 0x000000010009fa14 ruby`ruby_setup at eval.c:89:9 frame #12: 0x000000010009fa90 ruby`ruby_init at eval.c:101:17 frame #13: 0x0000000100004610 ruby`main [inlined] rb_main(argc=1, argv=0x000000016fdff938) at main.c:37:5 frame #14: 0x0000000100004604 ruby`main(argc=1, argv=0x000000016fdff938) at main.c:57:12 frame #15: 0x000000018599be50 dyld`start + 2544 (snip) (lldb) print *ec (rb_execution_context_t) $7 = { vm_stack = 0x0000000108028000 vm_stack_size = 131072 cfp = 0x0000000108127fc0 tag = 0x000000016fdff4b0 interrupt_flag = 0 interrupt_mask = 0 fiber_ptr = 0x00000001007048d0 thread_ptr = 0x0000000100704260 local_storage = NULL local_storage_recursive_hash = 4 local_storage_recursive_hash_for_trace = 4 storage = 4 root_lep = 0x0000000000000000 root_svar = 0 ensure_list = NULL trace_arg = NULL errinfo = 4 passed_block_handler = 0 raised_flag = '\0' method_missing_reason = MISSING_NOENTRY private_const_reference = 0 machine = { stack_start = 0x000000016fdff4ac stack_end = 0x000000016fdff2c0 stack_maxsize = 0 (snip) (lldb) print ec->machine.stack_start (VALUE *) $4 = 0x000000016fdff4ac (lldb) print ec->machine.stack_end (VALUE *) $5 = 0x000000016fdff2c0 (lldb) print ec->machine.stack_end - ec->machine.stack_start (long) $6 = -61 (snip) (lldb) print ruby_stack_length(NULL) (size_t) $8 = 18446744073709551529 ``` Looks like it's got the stack direction backwards. I checked `config.log`, and it's incorrectly detecting the stack length as `+1` (growing towards larger addresses) for `arm64`: ``` | #if defined __x86_64__ | #define STACK_GROW_DIRECTION -1 | #endif /* defined __x86_64__ */ | #if defined __arm64__ | #define STACK_GROW_DIRECTION +1 (snip) rb_cv_stack_grow_dir_arm64=+1 rb_cv_stack_grow_dir_x86_64=-1 ``` Sent PR https://github.com/ruby/ruby/pull/7373 with this fix as well. ---------------------------------------- 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-102022 * 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:112563] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by benhamilton (Ben Hamilton) 23 Feb '23

23 Feb '23

Issue #18286 has been updated by benhamilton (Ben Hamilton). Sent PR https://github.com/ruby/ruby/pull/7367 with a fix. ---------------------------------------- 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-102012 * 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:112562] [Ruby master Bug#13831] error when try to install
by joshc (Josh C) 23 Feb '23

23 Feb '23

Issue #13831 has been updated by joshc (Josh C). We've been carrying a patch for this issue for many years now and I submitted a PR: https://github.com/ruby/ruby/pull/7366 It affects ruby 3.2.1 through 1.9.3. ---------------------------------------- Bug #13831: error when try to install https://bugs.ruby-lang.org/issues/13831#change-102011 * Author: khaledal (khaled alajmi) * Status: Third Party's Issue * Priority: Normal * ruby -v: ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32] C:\Users\K>gem install sass C:/Ruby24-x64/lib/ruby/2.4.0/win32/registry.rb:72:in `find': unknown encoding name - CP720 (ArgumentError) from C:/Ruby24-x64/lib/ruby/2.4.0/win32/registry.rb:72:in `<module:Win32>' from C:/Ruby24-x64/lib/ruby/2.4.0/win32/registry.rb:4:in `<top (required)>' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:46:in `require' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:46:in `iterate_msys_paths' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:69:in `msys_path' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:82:in `mingw_bin_path' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/msys2_installation.rb:92:in `enable_dll_search_paths' from C:/Ruby24-x64/lib/ruby/site_ruby/2.4.0/ruby_installer/runtime/singleton.rb:27:in `enable_dll_search_paths' from C:/Ruby24-x64/lib/ruby/2.4.0/rubygems/defaults/operating_system.rb:3:in `<top (required)>' from C:/Ruby24-x64/lib/ruby/2.4.0/rubygems.rb:1345:in `require' from C:/Ruby24-x64/lib/ruby/2.4.0/rubygems.rb:1345:in `<top (required)>' from <internal:gem_prelude>:4:in `require' from <internal:gem_prelude>:4:in `<internal:gem_prelude>' C:\Users\K> -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112561] [Ruby master Bug#18286] Universal arm64/x86_84 binary built on an x86_64 machine segfaults/is killed on arm64
by benhamilton (Ben Hamilton) 23 Feb '23

23 Feb '23

Issue #18286 has been updated by benhamilton (Ben Hamilton). I think I know what the problem is. During the build, Ruby has special logic to serialize its own `builtin` module to disk using the binary `iseq` format during the build (I assume for speed so it doesn't have to parse `builtin` every time it starts up). However, since `iseq` format is architecture-specific, when building on x86_64 for universal x86_64 + arm64, the serialized `builtin` module is written with the `x86_64` architecture of the build machine, which fails this check whenever `ruby` imports the `builtin` module on arm64: https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/… Thankfully, there's logic to disable this feature for cross-compiled builds: https://github.com/ruby/ruby/blob/1fdaa0666086529b3aae2d509a2e71c4247c3a12/… We just need to enable this for universal builds as well. ---------------------------------------- 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-102010 * 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:112546] [Ruby master Bug#19460] inline method cache won't let class be garbage collected
by luke-gru (Luke Gruber) 23 Feb '23

23 Feb '23

Issue #19460 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19460: inline method cache won't let class be garbage collected https://bugs.ruby-lang.org/issues/19460 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I'm working on something where I need to remove a class and release all memory related to that class. I've stumbled upon a limitation where in some instances I cannot get the class to be GC'd. The problem (I think) is that inline method caches cache the class, and even if the class would otherwise be gone, it stays. For example: ```ruby class A def do_something self.call_other # inline cache caches class A, so now A is marked every time cache is marked end def call_other end end a = A.new a.send(:do_something) # don't make normal call, use send so no inline cache used here a_id = A.object_id a = nil Object.send(:remove_const, :A) # A should be able to be released now. 10.times { GC.start } a_ref = ObjectSpace._id2ref(a_id) rescue nil puts "a_ref: #{a_ref.class}" ```ruby One solution to this would be if inline caches are inside methods, only mark them when the method itself is marked. I'm guessing they're marked independently right now. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:112558] [Ruby master Feature#18070] `attr` should be removed
by rubyFeedback (robert heiler) 23 Feb '23

23 Feb '23

Issue #18070 has been updated by rubyFeedback (robert heiler). There may be backwards compatibility considerations. Personally I never use attr. I use the longer variants, but even these I use less often compared to older code. I tend to put variables for larger classes into an internal hash usually these days. Perhaps if backwards compatibility is a concern, there should be a deprecation window announced, before it may then be removed (if it is decided to remove it)? ---------------------------------------- Feature #18070: `attr` should be removed https://bugs.ruby-lang.org/issues/18070#change-102008 * Author: schwad (Nick Schwaderer) * Status: Open * Priority: Normal ---------------------------------------- I'm digging through some older Ruby versions and discovered that `attr` was deprecated in Ruby 1.9. We still are seeing support for it in Ruby 3.0 Unless there are internals that require its existence, is it time to remove this deprecated feature? If there's agreement, I'm more than happy to fire up the PR myself. (Also happy to be corrected if there's something I'm missing here :) ) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112557] [Ruby master Feature#18136] take_while_after
by rubyFeedback (robert heiler) 23 Feb '23

23 Feb '23

Issue #18136 has been updated by rubyFeedback (robert heiler). I think one big problem with the proposed name such as the three word one is that they are somewhat rare and difficult to remember. In ruby we often have one word, or two words for methods. We may have some three words if I remember correctly, but these are quite rare, and it is a LOT harder to understand "take_while_after" or "do_this_that", than comparable ".upto()" or ".downto()" and so forth. We kind of have combined "instructions" such as: [3,4,5].each.with_index These are a bit different though. We could of course call such a combined instruction via: [3,4,5].each_with_index so just a single method with three words. But I think semantically it is easier to use .each, standalone as we do now, and then "aggregate" onto it, such as via .with_index. That conveys the meaning quite clearly. With three word names, as a single method, I think it quite a lot more difficult to convey meaning. > I'd rather choose an obvious name, like take_until_after. I think it has a very similar problem as take_while_after. ---------------------------------------- Feature #18136: take_while_after https://bugs.ruby-lang.org/issues/18136#change-102007 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Sorry, I already tried that once (#16441) but I failed to produce the persuasive example. So I am back with a couple of them, much simpler and clear than my initial. **The proposal itself:** Have `take_while_after` which behaves like `take_while` but also includes the last element (first where the condition failed). Reason: there are a lot of cases where "the last good item" in enumeration is the distinctive one (one where enumeration should stop, but the item is still good. **Example 1:** Take pages from paginated API, the last page will have less items than the rest (and that's how we know it is the last): ```ruby (0..).lazy .map { |offset| get_page(offset, limit) } .take_while_after { |response| response.count == limit } # the last will have, say, 10 items, but should still be included! .map { process response somehow } ``` **Example 2:** Same as above, but "we should continue pagination" is specified with a separate data key "can_continue": ```ruby (0..).lazy .map { |offset| get_page(offset, limit) } .take_while_after { |response| response['can_continue'] } # the last will have can_continue=false, but still has data .map { process response somehow } ``` **Exampe 3:** Taking a sentence from a list of tokens like this: ```ruby tokens = [ {text: 'Ruby', type: :word}, {text: 'is', type: :word}, {text: 'cool', type: :word}, {text: '.', type: :punctuation, ends_sentence: true}, {text: 'Rust', type: :word}, # ... ] sentence = tokens.take_while_after { !_1[:ends_sentence] } ``` (I can get more if it is necessary!) Neither of those can be solved by "Using `take_while` with proper condition.", as @matz suggested here: https://bugs.ruby-lang.org/issues/16441#note-9 I typically solve it by `slice_after { condition }.first`, but that's a) uglier and b) greedy when we are working with lazy enumerator (so for API examples, all paginated pages would be fetched at once, and only then processed). Another consideration in #16441 was an unfortunate naming. I am leaving it to discussion, though I tend to like `#take_upto` from #16446. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112556] [Ruby master Feature#17859] Start IRB when running just `ruby`
by rubyFeedback (robert heiler) 23 Feb '23

23 Feb '23

Issue #17859 has been updated by rubyFeedback (robert heiler). I don't have a strong opinion on the topic. I am fine either way. Both seem to have a valid point of view, e. g. the "it is convenient" approach. This is kind of true. But, as said, I don't really have any particularly strong pro or con on it, be it a change, or no change. I wanted to comment on two other statements, though: (1) The "it may be slow". Well, one could focus on a "bare irb" or "base irb" behaviour, such as zverok showed (e. g. "python which loads instantaneously, has no syntax highlight, and very simplistic autocomplete"). People could modify the behaviour via irbrc and load add-ons. I once even loaded all my local gems by also using Thread.new {} for loading them, since some took some time, and I thought I could just "insta-start" irb, and type commands, while background loading could proceed. It did not seem to work quite in the way how I thought it would be, so I switched to a "minimal IRB" again, where I really just start the things I need on a daily basis, and load other things only when I need it. I don't know whether irb is slow or not compared to python startup, but I feel that this question can be approached, even if it is just a mini-irb with less functionality. The main question should be whether it is worth to change the default behaviour, e. g. if more newcomers would think this is better, than typing a separate command (e. g. irb). That should be the primary question, the other questions are secondary to that one, I would think. (2) In regards to the "war", let's call it rather a "difference in approach" (irb versus pry). The way how I see it irb adopted what seemed useful from pry, even before the later rewrite that took place, without necessarily going the full introspection route that pry adopted from the get go. So I see these two more as a separate projects really, but irb learning from pry more than pry would learn from irb (since it has a slightly different use case). I don't think this is a bad thing. If anyone remembers, there was a time we did not have BasicObject, and if memory serves me well _why was important in suggesting it, as he was testing an interactive ruby on a website, and there having some "vanilla state" seemed important (probably also with SAFETY or what old security checks were still in place, to get it to work in a browser; of course since then we can do so; I think there is a project on github that does that, hsbt contributed to it if I remember correctly, but I forgot the name of that project). ---------------------------------------- Feature #17859: Start IRB when running just `ruby` https://bugs.ruby-lang.org/issues/17859#change-102006 * Author: deivid (David Rodríguez) * Status: Open * Priority: Normal ---------------------------------------- Compare python: ``` $ python Python 3.8.3 (default, Jul 8 2020, 16:49:12) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ``` To ruby: ``` $ ruby # just hangs ``` I think firing up a console it's a good default behaviour for beginners. -- https://bugs.ruby-lang.org/

1 0