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

[ruby-core:115480] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 26 Nov '23

26 Nov '23

Issue #18368 has been updated by zverok (Victor Shepelev). I am sorry that only now I had time to further work on the feature. I understand it is almost Decemeber and the feature might not make it in the 3.3 (though I would be happy if it would). The generic backward iteration was implemented: ```ruby (Time.utc(2022, 3, 1)..Time.utc(2022, 2, 24)).step(-24*60*60) { puts _1 } # Prints: # 2022-03-01 00:00:00 UTC # 2022-02-28 00:00:00 UTC # 2022-02-27 00:00:00 UTC # 2022-02-26 00:00:00 UTC # 2022-02-25 00:00:00 UTC # 2022-02-24 00:00:00 UTC ``` The coercion for numeric values and custom objects works as expected: ```ruby val = Struct.new(:val) do def coerce(num) = [num, val] end p (1..3).step(val.new(1)).to_a # => [1, 2, 3] ``` So I believe the feature is ready for the final review/merge. Two nuances I am currently aware of: **1. I didn't change the behavior of numeric iteration, but it might be considered inconsistent:** ```ruby (1r..).step(1).take(3) #=> [(1/1), 2.0, 3.0] (1r..).step(1.0).take(3) #=> [1.0, 2.0, 3.0] ``` One might expect that those examples would return `[1r, 2r, 3r]`, but **that's how it always worked**. **2. The `rbs` tests are [broken](https://github.com/ruby/ruby/actions/runs/6994686558/job/1902872834… That's not because the RBS itself is broken by the change, but because one of the tests [uses](https://github.com/ruby/rbs/blob/master/test/stdlib/Range_test.rb#L10… string range with the default and numeric steps, which are now incorrect. I don't think it represents some realistic use case, and RBS tests should be fixed. I will be grateful for the instruction how to do that (I mean, what's the process to adjust bundled gem's tests that became irrelevant for the new Ruby version). ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-105411 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- 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:115465] [Ruby master Bug#20019] Ruby 3.3 GVL instrumentation events are fired out of order
by jpcamara (JP Camara) 23 Nov '23

23 Nov '23

Issue #20019 has been reported by jpcamara (JP Camara). ---------------------------------------- Bug #20019: Ruby 3.3 GVL instrumentation events are fired out of order https://bugs.ruby-lang.org/issues/20019 * Author: jpcamara (JP Camara) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-23T14:39:30Z fix-thread-instrum.. 285a41d793) +MN [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The order of instrumentation events is incorrect, and inconsistent with Ruby 3.2 ordering. You can find a spec to reproduce the broken behavior here: https://github.com/ruby/ruby/pull/9019. ### Steps to reproduce 1. Pull down this PR: https://github.com/ruby/ruby/pull/9019 2. Run `make test-all TESTS="../test/-ext-/thread/test_instrumentation_api.rb --name=TestThreadInstrumentation#test_order_of_events"` 3. Run `RUBY_MN_THREADS=1 make test-all TESTS="../test/-ext-/thread/test_instrumentation_api.rb --name=TestThreadInstrumentation#test_order_of_events"` ### Expected behavior It should pass the spec, and the events for each thread should match the array `%w[started ready resumed suspended exited]`. That is the consistent behavior on Ruby 3.2. ### Actual behavior When running `make test-all TESTS="../test/-ext-/thread/test_instrumentation_api.rb --name=TestThreadInstrumentation#test_order_of_events"`, the array of events is `%w[ready resumed started exited suspended]`. When running with `RUBY_MN_THREADS=1`, the array of events is `%w[ready started exited suspended]`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115463] [Ruby master Bug#17807] "Segmentation fault at 0x0000000000000008" crash when accessing instance variables of Process::Waiter instances (Ruby 2.3 to 2.6)
by ivoanjo (Ivo Anjo) 23 Nov '23

23 Nov '23

Issue #17807 has been updated by ivoanjo (Ivo Anjo). Randomly, I found today that right around when I was trying to debug this, the puma folks also independently ran into it: https://github.com/puma/puma/issues/2566 ---------------------------------------- Bug #17807: "Segmentation fault at 0x0000000000000008" crash when accessing instance variables of Process::Waiter instances (Ruby 2.3 to 2.6) https://bugs.ruby-lang.org/issues/17807#change-105391 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal * ruby -v: ruby 2.6.7p197 (2021-04-05 revision 67941) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- Hey there! I'm in [Datadog's ddtrace gem](https://github.com/DataDog/dd-trace-rb) team and one of our customers was running into this crash. Reproducing it is trivial: `ruby -e 'Process.detach(fork {}); Thread.list.last.instance_variable_get(:@kaboom)'`. The issue seems to be that some of the internal structures of the `Process::Waiter` are not properly initialized, and so trying to access instance variables on an instance of that very special class triggers the crash. This seems to affect Ruby from 2.3 up to 2.6, on both Linux and macOS. I've attached a crash log, but probably running the reproducer example is faster :) As I said above, this crash is gone on 2.7 and 3.0. I could not find any mention of this crash, so I suspect the fix may have been a happy side effect of some refactoring, rather than a deliberate thing. Furthermore, I know that out of the affected versions, only 2.6 is the only one still not EOL, and I am not sure if this can be qualified as a security issue. I decided to report it anyway, in the spirit of documenting what I learned. Feel free to close the ticket if indeed there's no plans of fixing it. Finally, here's some hints, if someone out there also needs to work around this issue: * `defined?` (from inside the class) or `instance_variable_defined?` (from the outside) seem to work, so if you "look before you jump", you can avoid the crash * Writing once to any instance variable on any instance of a `Process::Waiter` seems to initialize whatever was missing; afterwards, any instance of this class will behave correctly * You can always check the `.class` of the thread to see if you should skip whatever you were trying to do with it ---Files-------------------------------- crash-log.txt (16 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115445] [Ruby master Bug#20014] Ruby command line exection ignores what inside of command {}
by henry.maestu＠gmail.com (Henry Maestu) 22 Nov '23

22 Nov '23

Issue #20014 has been reported by henry.maestu(a)gmail.com (Henry Maestu). ---------------------------------------- Bug #20014: Ruby command line exection ignores what inside of command {} https://bugs.ruby-lang.org/issues/20014 * Author: henry.maestu(a)gmail.com (Henry Maestu) * Status: Open * Priority: Normal * ruby -v: 2.3.0, 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby command line executions ignore what inside of {} ``` ruby storage_info = `df -h --exclude={tmpfs,devtmpfs,squashfs} --total` puts storage_info # Same with System command. Seems everything inside {} is ignored r, w = IO.pipe system('df', '-h', '--exclude={tmpfs,devtmpfs,squashfs}','--total', out: w) w.close output = r.read puts output ``` Ruby outout: ``` Filesystem Size Used Avail Use% Mounted on udev 16G 0 16G 0% /dev tmpfs 3,2G 11M 3,2G 1% /run /dev/sdc2 212G 194G 6,4G 97% / tmpfs 16G 11M 16G 1% /dev/shm tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/loop1 64M 64M 0 100% /snap/core20/2015 /dev/loop2 64M 64M 0 100% /snap/core20/1974 /dev/loop4 82M 82M 0 100% /snap/gtk-common-themes/1534 /dev/loop0 148M 148M 0 100% /snap/figma-linux/169 /dev/loop5 165M 165M 0 100% /snap/gnome-3-28-1804/194 /dev/loop3 56M 56M 0 100% /snap/core18/2796 /dev/loop8 165M 165M 0 100% /snap/gnome-3-28-1804/198 /dev/loop10 148M 148M 0 100% /snap/figma-linux/178 /dev/loop7 425M 425M 0 100% /snap/kde-frameworks-5-qt-5-15-3-core20/8 /dev/loop9 497M 497M 0 100% /snap/gnome-42-2204/141 /dev/loop12 497M 497M 0 100% /snap/gnome-42-2204/132 /dev/loop11 106M 106M 0 100% /snap/core/16091 /dev/loop14 219M 219M 0 100% /snap/gnome-3-34-1804/93 tmpfs 16G 5,0M 16G 1% /tmp /dev/loop13 117M 117M 0 100% /snap/robo3t-snap/8 /dev/loop16 205M 205M 0 100% /snap/rpi-imager/465 /dev/sdc1 300M 5,9M 294M 2% /boot/efi /dev/loop15 74M 74M 0 100% /snap/core22/858 /dev/loop18 219M 219M 0 100% /snap/gnome-3-34-1804/90 /dev/loop6 168M 168M 0 100% /snap/postman/231 /dev/loop17 350M 350M 0 100% /snap/gnome-3-38-2004/143 /dev/loop19 350M 350M 0 100% /snap/gnome-3-38-2004/140 /dev/loop20 437M 437M 0 100% /snap/kde-frameworks-5-96-qt-5-15-5-core20/7 /dev/loop21 258M 258M 0 100% /snap/rubymine/81 /dev/loop23 116M 116M 0 100% /snap/bitcoin-core/145 /dev/loop22 167M 167M 0 100% /snap/spotify/70 /dev/loop24 205M 205M 0 100% /snap/rpi-imager/520 /dev/loop25 117M 117M 0 100% /snap/robo3t-snap/9 /dev/loop26 74M 74M 0 100% /snap/core22/864 /dev/loop28 128K 128K 0 100% /snap/bare/5 /dev/loop27 168M 168M 0 100% /snap/postman/234 /dev/loop29 92M 92M 0 100% /snap/gtk-common-themes/1535 /dev/loop30 159M 159M 0 100% /snap/spotify/68 /dev/loop31 106M 106M 0 100% /snap/core/16202 /dev/loop32 56M 56M 0 100% /snap/core18/2790 tmpfs 3,2G 80K 3,2G 1% /run/user/1000 total 287G 200G 76G 73% - ``` Example on terminal, expected output: ``` henry@development:~$ df -h --exclude={tmpfs,devtmpfs,squashfs} --total Filesystem Size Used Avail Use% Mounted on /dev/sdc2 212G 194G 6,4G 97% / /dev/sdc1 300M 5,9M 294M 2% /boot/efi total 212G 194G 6,7G 97% - ``` Have tested this on both 2.3.1 and 3.2.2 version on Ruby, same result, using Debian 10 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115386] [Ruby master Bug#20004] Release CI is broken with Ruby master
by hsbt (Hiroshi SHIBATA) 21 Nov '23

21 Nov '23

Issue #20004 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20004: Release CI is broken with Ruby master https://bugs.ruby-lang.org/issues/20004 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- From 3 week ago, Release action of master is broken. https://github.com/ruby/actions/actions/runs/6599016994/job/17927644579#ste… ``` Invoking `/Users/runner/work/actions/actions/snapshot-master/ruby -rrubygems /Users/runner/work/actions/actions/snapshot-master/bin/gem --backtrace build lib/bundler/bundler.gemspec` failed with output: ---------------------------------------------------------------------- dyld[42417]: Library not loaded: '/usr/local/lib/libruby.3.3.dylib' Referenced from: '/Users/runner/work/actions/actions/snapshot-master/ruby' Reason: tried: '/usr/local/lib/libruby.3.3.dylib' (no such file), '/usr/lib/libruby.3.3.dylib' (no such file) ---------------------------------------------------------------------- ``` It is related with #19422 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115425] [Ruby master Bug#20010] Backport: Fix compile error on older systems without clock_get*
by Bo98 (Bo Anderson) 21 Nov '23

21 Nov '23

Issue #20010 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #20010: Backport: Fix compile error on older systems without clock_get* https://bugs.ruby-lang.org/issues/20010 * Author: Bo98 (Bo Anderson) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Commit 84a12d657848dfb54f8cc556d344f017a793e95a This fixes a build regression in 3.2. 3.1 and earlier are not affected. Cherry-pick is trivial: https://github.com/ruby/ruby/pull/8948 and the risk is very low. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115139] [Ruby master Bug#19969] Regression of memory usage with Ruby 3.1
by hsbt (Hiroshi SHIBATA) 20 Nov '23

20 Nov '23

Issue #19969 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19969: Regression of memory usage with Ruby 3.1 https://bugs.ruby-lang.org/issues/19969 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Our company that is ANDPAD, Inc. encountered to increase memory usage after upgrading Ruby 3.2 from 3.0 on our Rails application. This increase size is about 20%. My colleague found this [root cause](https://bugs.ruby-lang.org/issues/16996) and reproduction code: ``` $ ruby -v -rset -e 's1 = Set.new(10000.times); s2 = Set.new(9999.times); Array.new(10000) { s1 - s2 - [0] }; puts `ps -o rss= -p #{$$}`.to_i' ruby 3.0.6p216 (2023-06-29 revision bdfe1958a8) +JIT [arm64-darwin22] 248096 $ ruby -v -rset -e 's1 = Set.new(10000.times); s2 = Set.new(9999.times); Array.new(10000) { s1 - s2 - [0] }; puts `ps -o rss= -p #{$$}`.to_i' ruby 3.2.2 (2023-07-05 revision 2f603bc4d7) +YJIT [arm64-darwin22] 2949280 ``` Should we revert #16996 for Ruby 3.1 or later? I'm not sure this increased memory usage is reasonable with performance improvement. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:115410] [Ruby master Bug#20007] prism test begain to fail on s390x
by mtasaka (Mamoru Tasaka) 18 Nov '23

18 Nov '23

Issue #20007 has been reported by mtasaka (Mamoru Tasaka). ---------------------------------------- Bug #20007: prism test begain to fail on s390x https://bugs.ruby-lang.org/issues/20007 * Author: mtasaka (Mamoru Tasaka) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-18 master ef72970a04) [s390x-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- As of commit:3bc41f4f0b testsuite was successful on both x86_64 and s390x, but as of commit:ef72970a04 testsuite fails on s390x (note that s390x is big endian): ``` .... .... 87) Skipped: TestIRB::DebugCommandTest#test_multi_irb_commands_are_not_available_after_activating_the_debugger [/builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/irb/helper.rb:94]: This test works only under ruby/irb 88) Skipped: TestIRB::DebugCommandTest#test_prompt_irb_name_is_kept [/builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/irb/helper.rb:94]: This test works only under ruby/irb 89) Skipped: TestIRB::DebugCommandTest#test_delete [/builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/irb/helper.rb:94]: This test works only under ruby/irb 90) Skipped: TestIRB::DebugCommandTest#test_long_stepping [/builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/irb/helper.rb:94]: This test works only under ruby/irb 91) Error: Prism::ParseTest#test_filepath_seattlerb/call_dot_parens.txt: ArgumentError: offset outside of string <internal:pack>:29:in `unpack1' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:216:in `load_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:233:in `load_required_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:284:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `block in load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `initialize' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `new' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:150:in `load_nodes' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:154:in `load_result' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:41:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism.rb:65:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/prism/parse_test.rb:152:in `block (2 levels) in <class:ParseTest>' 92) Error: Prism::ParseTest#test_filepath_unparser/corpus/literal/yield.txt: ArgumentError: offset outside of string <internal:pack>:29:in `unpack1' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:216:in `load_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:233:in `load_required_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:284:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:256:in `block in load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:256:in `initialize' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:256:in `new' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:256:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:183:in `load_optional_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:535:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `block in load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `initialize' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `new' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:150:in `load_nodes' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:154:in `load_result' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:41:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism.rb:65:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/prism/parse_test.rb:152:in `block (2 levels) in <class:ParseTest>' 93) Error: Prism::ParseTest#test_filepath_seattlerb/f_kw__required.txt: ArgumentError: offset outside of string <internal:pack>:29:in `unpack1' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:216:in `load_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:233:in `load_required_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:333:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `block in load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `initialize' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `new' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:511:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:150:in `load_nodes' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:154:in `load_result' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:41:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism.rb:65:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/prism/parse_test.rb:152:in `block (2 levels) in <class:ParseTest>' 94) Error: Prism::ParseTest#test_filepath_whitequark/masgn.txt: ArgumentError: offset outside of string <internal:pack>:29:in `unpack1' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:216:in `load_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:233:in `load_required_constant' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `block in load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `initialize' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `new' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:475:in `load_node' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:150:in `load_nodes' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:154:in `load_result' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism/serialize.rb:41:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/lib/prism.rb:65:in `load' /builddir/build/BUILD/ruby-3.3.0-ef72970a04/test/prism/parse_test.rb:152:in `block (2 levels) in <class:ParseTest>' ... ... Finished tests in 608.001668s, 43.2581 tests/s, 10825.4473 assertions/s. 26301 tests, 6581890 assertions, 0 failures, 774 errors, 90 skips ruby -v: ruby 3.3.0dev (2023-11-18 master ef72970a04) [s390x-linux] make: Leaving directory '/builddir/build/BUILD/ruby-3.3.0-ef72970a04/redhat-linux-build' RPM build errors: make: *** [uncommon.mk:945: yes-test-all] Error 6 ``` Maybe due to commit:7c99e43c3f050244b06dbd18de4f605ea70d234c ? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:115404] Ruby 3.2.2 - rbconfig.rb's MAKEFILE_CONFIG
by Jay Mav 17 Nov '23

17 Nov '23

Hello Ruby Dev Team, With Ruby 3.2.2, gem install fails because in rbconfig.rb, MAKEFILE_CONFIG's $(target_os) is not expanded (whereas CONFIG's is expanded correctly). The inline doc in mkconfig.rb states that the caller can expand MAKEFILE_CONFIG's values by calling RbConfig::expand(). However, ruby-shadow gem's Makefile generator -- extconf.rb -- does not call expand and directly uses mkmf.rb's CONFIG instance (which is RbConfig::MAKEFILE_CONFIG), because of which $(target_os) does not get expanded. This causes ruby-shadow gem install to fail with Ruby 3.2.2. Would the Ruby Dev Team accept the following proposal to fix mkconfig.rb, so that the generated rbconfig.rb instantiates MAKEFILE_CONFIG AFTER CONFIG's values have been expanded? # Existing code... CONFIG.each_value do |val| RbConfig::expand(val) end # Move instantiation of MAKEFILE_CONFIG after expanding CONFIG's values. MAKEFILE_CONFIG = {} CONFIG.each{|k,v| MAKEFILE_CONFIG[k] = v.dup} If we fix it in mkconfig.rb, we can avoid callers having to explicitly call expand for MAKEFILE_CONFIG's values. Thanks.

2 3

[ruby-core:115403] [Ruby master Bug#7968] Poor UDPSocket#send performance in ruby 2.0.0 on windows
by cs96and (Alan Davies) 16 Nov '23

16 Nov '23

Issue #7968 has been updated by cs96and (Alan Davies). k0kubun (Takashi Kokubun) wrote in #note-14: > Just in case, could you measure the time spent on the loop instead of a whole Ruby command? The prelude script sometimes takes a lot of time, the performance varies across different versions, and `time` command would benchmark that as well. You can just call `Time.new` before and after the loop, subtract them, and report the result for each version. I also increased the loop by a factor of 10 (to 1,000,000) so it runs for longer. Times are in seconds... **1.9.3 send:** ``` ruby-1.9.3\bin\ruby.exe socketsendtest.rb 10.495193 ``` **1.9.3 print:** ``` ruby-1.9.3\bin\ruby.exe socketsendtest.rb 10.384035 ``` **3.2.2 send** ``` ruby-3.2.2\bin\ruby.exe socketsendtest.rb 17.3447397 ``` **3.2.2 print** ``` ruby-3.2.2\bin\ruby.exe socketsendtest.rb 9.8053804 ``` Out of interest I ran the code through the profile module as well... **1.9.3 send** ``` ruby-1.9.3\bin\ruby.exe -rprofile socketsendtest.rb 19.520433 % cumulative self self total time seconds seconds calls ms/call ms/call name 56.95 6.03 6.03 1000000 0.01 0.01 UDPSocket#send 43.05 10.59 4.56 1 4561.00 10594.00 Integer#times 0.00 10.59 0.00 1 0.00 0.00 UDPSocket#bind 0.00 10.59 0.00 10 0.00 0.00 Class#inherited 0.00 10.59 0.00 40 0.00 0.00 BasicObject#singleton_method_added 0.00 10.59 0.00 104 0.00 0.00 Module#method_added 0.00 10.59 0.00 2 0.00 0.00 Kernel.gem_original_require 0.00 10.59 0.00 2 0.00 0.00 Kernel.require 0.00 10.59 0.00 4 0.00 0.00 Module#private 0.00 10.59 0.00 2 0.00 0.00 Module#attr_reader 0.00 10.59 0.00 1 0.00 0.00 UDPSocket#initialize 0.00 10.59 0.00 1 0.00 0.00 IO#new 0.00 10.59 0.00 2 0.00 0.00 Hash#empty? 0.00 10.59 0.00 1 0.00 0.00 UDPSocket#connect 0.00 10.59 0.00 2 0.00 0.00 Time#initialize 0.00 10.59 0.00 2 0.00 0.00 Class#new 0.00 10.59 0.00 4 0.00 0.00 IO#set_encoding 0.00 10.59 0.00 2 0.00 0.00 Gem.unresolved_deps 0.00 10.59 0.00 1 0.00 0.00 Float#/ 0.00 10.59 0.00 1 0.00 0.00 Float#quo 0.00 10.59 0.00 1 0.00 0.00 Time#- 0.00 10.59 0.00 1 0.00 0.00 Float#to_s 0.00 10.59 0.00 2 0.00 0.00 IO#write 0.00 10.59 0.00 1 0.00 0.00 IO#puts 0.00 10.59 0.00 1 0.00 0.00 Kernel.puts 0.00 10.59 0.00 1 0.00 10594.00 #toplevel ``` **1.9.3 print** ``` ruby-1.9.3\bin\ruby.exe -rprofile socketsendtest.rb 25.818462 % cumulative self self total time seconds seconds calls ms/call ms/call name 38.19 6.18 6.18 1000000 0.01 0.01 IO#print 33.27 11.56 5.38 1000002 0.01 0.01 IO#write 28.45 16.16 4.60 1 4600.00 16156.00 Integer#times 0.09 16.17 0.01 2 7.50 15.00 Kernel.require 0.00 16.17 0.00 1 0.00 0.00 UDPSocket#bind 0.00 16.17 0.00 104 0.00 0.00 Module#method_added 0.00 16.17 0.00 2 0.00 7.50 Kernel.gem_original_require 0.00 16.17 0.00 4 0.00 0.00 IO#set_encoding 0.00 16.17 0.00 4 0.00 0.00 Module#private 0.00 16.17 0.00 2 0.00 0.00 Module#attr_reader 0.00 16.17 0.00 1 0.00 0.00 UDPSocket#initialize 0.00 16.17 0.00 1 0.00 0.00 IO#new 0.00 16.17 0.00 40 0.00 0.00 BasicObject#singleton_method_added 0.00 16.17 0.00 1 0.00 0.00 UDPSocket#connect 0.00 16.17 0.00 2 0.00 0.00 Time#initialize 0.00 16.17 0.00 2 0.00 0.00 Class#new 0.00 16.17 0.00 10 0.00 0.00 Class#inherited 0.00 16.17 0.00 2 0.00 0.00 Hash#empty? 0.00 16.17 0.00 2 0.00 0.00 Gem.unresolved_deps 0.00 16.17 0.00 1 0.00 0.00 Float#/ 0.00 16.17 0.00 1 0.00 0.00 Float#quo 0.00 16.17 0.00 1 0.00 0.00 Time#- 0.00 16.17 0.00 1 0.00 0.00 Float#to_s 0.00 16.17 0.00 1 0.00 0.00 IO#puts 0.00 16.17 0.00 1 0.00 0.00 Kernel.puts 0.00 16.17 0.00 1 0.00 16171.00 #toplevel ``` **3.2.2 send** ``` ruby-3.2.2\bin\ruby.exe -rprofile socketsendtest.rb 32.9209883 % cumulative self self total time seconds seconds calls ms/call ms/call name 39.03 7.72 7.72 1000000 0.01 0.02 nil# 38.17 15.27 7.55 1000000 0.01 0.01 UDPSocket#send 22.72 19.77 4.50 1 4495.00 19766.00 Integer#times 0.08 19.78 0.02 4 4.00 16.00 Kernel#require 0.00 19.78 0.00 2 0.00 0.00 Kernel#respond_to? 0.00 19.78 0.00 2 0.00 0.00 Hash#[] 0.00 19.78 0.00 2 0.00 0.00 Gem.find_unresolved_default_spec 0.00 19.78 0.00 2 0.00 0.00 Gem::Specification.unresolved_deps 0.00 19.78 0.00 2 0.00 0.00 Hash#empty? 0.00 19.78 0.00 2 0.00 0.00 Monitor#exit 0.00 19.78 0.00 378 0.00 0.00 Module#const_added 0.00 19.78 0.00 13 0.00 0.00 Class#inherited 0.00 19.78 0.00 50 0.00 0.00 BasicObject#singleton_method_added 0.00 19.78 0.00 141 0.00 0.00 Module#method_added 0.00 19.78 0.00 2 0.00 0.00 Monitor#enter 0.00 19.78 0.00 1 0.00 0.00 Module#method_defined? 0.00 19.78 0.00 1 0.00 0.00 Module#protected 0.00 19.78 0.00 1 0.00 0.00 String#=~ 0.00 19.78 0.00 3 0.00 0.00 Module#private 0.00 19.78 0.00 2 0.00 0.00 Module#attr_reader 0.00 19.78 0.00 1 0.00 0.00 UDPSocket#initialize 0.00 19.78 0.00 1 0.00 0.00 IO.new 0.00 19.78 0.00 1 0.00 0.00 UDPSocket#bind 0.00 19.78 0.00 1 0.00 0.00 UDPSocket#connect 0.00 19.78 0.00 2 0.00 0.00 Time#initialize 0.00 19.78 0.00 2 0.00 0.00 Class#new 0.00 19.78 0.00 2 0.00 0.00 Gem.discover_gems_on_require 0.00 19.78 0.00 4 0.00 0.00 IO#set_encoding 0.00 19.78 0.00 1 0.00 0.00 TracePoint#enable 0.00 19.78 0.00 1 0.00 0.00 Float#/ 0.00 19.78 0.00 1 0.00 0.00 Float#fdiv 0.00 19.78 0.00 1 0.00 0.00 Time#- 0.00 19.78 0.00 1 0.00 0.00 Float#to_s 0.00 19.78 0.00 1 0.00 0.00 IO#write 0.00 19.78 0.00 1 0.00 0.00 IO#puts 0.00 19.78 0.00 1 0.00 0.00 Kernel#puts 0.00 19.78 0.00 1 0.00 0.00 TracePoint#disable 0.00 19.78 0.00 1 0.00 19782.00 #toplevel ``` **3.2.2 print** ``` ruby-3.2.2\bin\ruby.exe -rprofile socketsendtest.rb 29.3270973 % cumulative self self total time seconds seconds calls ms/call ms/call name 33.07 6.50 6.50 1000000 0.01 0.01 IO#print 27.12 11.84 5.34 1000000 0.01 0.02 nil# 21.52 16.08 4.23 1 4234.00 19672.00 Integer#times 18.28 19.67 3.60 1000001 0.00 0.00 IO#write 0.00 19.67 0.00 2 0.00 0.00 Kernel#respond_to? 0.00 19.67 0.00 2 0.00 0.00 Hash#[] 0.00 19.67 0.00 2 0.00 0.00 Gem.find_unresolved_default_spec 0.00 19.67 0.00 2 0.00 0.00 Gem::Specification.unresolved_deps 0.00 19.67 0.00 2 0.00 0.00 Hash#empty? 0.00 19.67 0.00 2 0.00 0.00 Monitor#exit 0.00 19.67 0.00 378 0.00 0.00 Module#const_added 0.00 19.67 0.00 13 0.00 0.00 Class#inherited 0.00 19.67 0.00 50 0.00 0.00 BasicObject#singleton_method_added 0.00 19.67 0.00 141 0.00 0.00 Module#method_added 0.00 19.67 0.00 2 0.00 0.00 Gem.discover_gems_on_require 0.00 19.67 0.00 1 0.00 0.00 Module#method_defined? 0.00 19.67 0.00 1 0.00 0.00 Module#protected 0.00 19.67 0.00 1 0.00 0.00 String#=~ 0.00 19.67 0.00 3 0.00 0.00 Module#private 0.00 19.67 0.00 2 0.00 0.00 Module#attr_reader 0.00 19.67 0.00 1 0.00 0.00 UDPSocket#initialize 0.00 19.67 0.00 1 0.00 0.00 IO.new 0.00 19.67 0.00 1 0.00 0.00 UDPSocket#bind 0.00 19.67 0.00 1 0.00 0.00 UDPSocket#connect 0.00 19.67 0.00 2 0.00 0.00 Time#initialize 0.00 19.67 0.00 2 0.00 0.00 Class#new 0.00 19.67 0.00 2 0.00 0.00 Monitor#enter 0.00 19.67 0.00 4 0.00 0.00 IO#set_encoding 0.00 19.67 0.00 4 0.00 0.00 Kernel#require 0.00 19.67 0.00 1 0.00 0.00 TracePoint#enable 0.00 19.67 0.00 1 0.00 0.00 Float#/ 0.00 19.67 0.00 1 0.00 0.00 Float#fdiv 0.00 19.67 0.00 1 0.00 0.00 Time#- 0.00 19.67 0.00 1 0.00 0.00 Float#to_s 0.00 19.67 0.00 1 0.00 0.00 IO#puts 0.00 19.67 0.00 1 0.00 0.00 Kernel#puts 0.00 19.67 0.00 1 0.00 0.00 TracePoint#disable 0.00 19.67 0.00 1 0.00 19672.00 #toplevel ``` 3.2.2 seems to be spending a fair amount of time in a function called `nil#`. Though the 3.2.2 print() version does as well, but doesn't suffer the slowdown. ---------------------------------------- Bug #7968: Poor UDPSocket#send performance in ruby 2.0.0 on windows https://bugs.ruby-lang.org/issues/7968#change-105341 * Author: cs96and (Alan Davies) * Status: Assigned * Priority: Normal * Assignee: windows * ruby -v: ruby 2.0.0p0 (2013-02-24) [x64-mingw32] ---------------------------------------- I have noticed that the performance of UDPSocket#send on ruby 2.0.0 on windows is much poorer than that of 1.9.3 or 1.8.7. Running the attahced script on 2.0.0 gives the following... d:\scripts>bash -c "ruby --version" ruby 2.0.0p0 (2013-02-24) [x64-mingw32] d:\scripts>bash -c "time ruby socketsendtest.rb" real 0m2.572s user 0m0.000s sys 0m0.016s However, running the same test with 1.9.3 is much faster... d:\scripts>pik 193 d:\scripts>bash -c "ruby --version" ruby 1.9.3p374 (2013-01-15) [i386-mingw32] d:\scripts>bash -c "time ruby socketsendtest.rb" real 0m0.993s user 0m0.015s sys 0m0.016s Additionally, if I change the send call to a print (commented out in the script), then the performance is fine on 2.0.0.... d:\scripts>pik 200 d:\scripts>bash -c "ruby --version" ruby 2.0.0p0 (2013-02-24) [x64-mingw32] d:\scripts>bash -c "time ruby socketsendtest.rb" real 0m0.907s user 0m0.000s sys 0m0.015s What is send() doing that print() doesn't do that is causing the massive performance drop? Thanks Alan. ---Files-------------------------------- socketsendtest.rb (266 Bytes) -- https://bugs.ruby-lang.org/

1 0