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

[ruby-core:114703] [Ruby master Bug#19875] Ruby 2.7 -> 3.1 Performance regression in String#count
by iz (Illia Zub) 27 Sep '23

27 Sep '23

Issue #19875 has been reported by iz (Illia Zub). ---------------------------------------- Bug #19875: Ruby 2.7 -> 3.1 Performance regression in String#count https://bugs.ruby-lang.org/issues/19875 * Author: iz (Illia Zub) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `String#count` became slower since Ruby 3.1. Originally found by `@Freaky`: https://github.com/ruby/ruby/pull/4001#issuecomment-1714779781 Compared using the [`benchmark-driver` gem](https://github.com/benchmark-driver/benchmark-driver). ``` $ benchmark-driver tmp/string_count_benchmark_driver.yml --rbenv '3.1.1;3.1.4;2.7.2;3.2.2;3.0.6' Calculating ------------------------------------- 3.1.1 3.1.4 2.7.2 3.2.2 3.0.6 count 465.804 463.741 865.783 462.711 857.395 i/s - 10.000k times in 21.468251s 21.563768s 11.550239s 21.611783s 11.663235s Comparison: count 2.7.2: 865.8 i/s 3.0.6: 857.4 i/s - 1.01x slower 3.1.1: 465.8 i/s - 1.86x slower 3.1.4: 463.7 i/s - 1.87x slower 3.2.2: 462.7 i/s - 1.87x slower ``` Benchmark: ```yml $ cat ./tmp/string_count_benchmark_driver.yml loop_count: 10_000 prelude: | html = "\nruby\n" * 1024 * 1024 benchmark: count: html.count($/) ``` -- https://bugs.ruby-lang.org/

5 17

[ruby-core:114884] [Ruby master Bug#19900] Rename YARP to Prism
by kddnewton (Kevin Newton) 27 Sep '23

27 Sep '23

Issue #19900 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19900: Rename YARP to Prism https://bugs.ruby-lang.org/issues/19900 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Following up on the discussion from https://bugs.ruby-lang.org/issues/19772#note-29, we would like to rename the YARP project to `Prism`. For the purposes of this ticket specifically, all functionality will remain the same. That is: * Prism will be a bundled gem with a native extension that will require you to `require "prism"` to access it from Ruby code. * Within CRuby, the C library will continue to be used to provide parsing/compiling functionality, under `RubyVM::InstructionSequence.compile_prism`. At the moment, this API is strictly for testing. Going forward, the C symbol prefix will be `pm_` (as opposed to the existing `yp_`). Assuming all of this is okay, I'll begin working on the rename next week. -- https://bugs.ruby-lang.org/

2 2

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

27 Sep '23

Issue #13933 has been updated by akr (Akira Tanaka). Dan0042 (Daniel DeLorme) wrote in #note-13: > akr (Akira Tanaka) wrote in #note-12: > > From experience with `Float::NAN`, I think it is not a good idea to expand such objects. > > It makes the behavior of `Array#<=>` inconsistent. > > I agree but I think this is a bit different from what I was talking about. Float::NAN is a float that is not comparable with other floats. This is not the same case as a value that is not comparable with anything else. > Float::NAN is not comparable with anything else, not only floats. ``` % ruby -e 'p Float::NAN <=> "foo"' nil % ruby -e 'p Float::NAN <=> []' nil ``` > > > 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?` > > > > You ignored the user-defined classes I mentioned. > > A user may define a class with a minimum value. > > The minimum value may not have `empty?` method. > > How do you define which is the minimum value? I suggested the above as a *possible* way to define this minimum value. So a custom class would need to have #empty? that returns true in order to define "this is the minimum". But it was just a suggestion. Or maybe each class could have a MINIMUM constant like `String::MINIMUM = ""`, etc. I described an idea in https://bugs.ruby-lang.org/issues/19839#note-18 : `minimum?` method. I feel `empty?` can sometimes be a wrong name. `minimum?` represent the property directly. > More importantly, I think that `(...minimum).empty?` is such an edge case of an edge case that it's not worth worrying too much. Are you suggesting that `Range#empty?` should not exist just because it's not possible to perfectly handle this extreme edge case for every possible class? Would it really be so bad if it returned `true` for user-defined classes? I think a bug report like my comment will coming someday. Ruby developers (especially matz) need to respond to it. So, we compare the usefulness of the method and the difficulties of responding to the bug report. Also, this problem can be expanded if we introduce `Range#exclude_begin?` (with neko operator). https://bugs.ruby-lang.org/issues/12133 In that case, we need `maximum?` as well. But we also need a method to check the existence between two objects because `[1] ^..^ [1, ""]` is empty (no objects between `[1]` and `[1, ""]`). ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104767 * 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:114900] [Ruby master Bug#17146] Queue operations are allowed after it is frozen
by jeremyevans0 (Jeremy Evans) 27 Sep '23

27 Sep '23

Issue #17146 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to have `{Queue,SizedQueue}#freeze` raise `TypeError`, as `ENV.freeze` does: https://github.com/ruby/ruby/pull/8515 ---------------------------------------- Bug #17146: Queue operations are allowed after it is frozen https://bugs.ruby-lang.org/issues/17146#change-104765 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- ``` [1] pry(main)> q = Queue.new => #<Thread::Queue:0x000056263683aee8> [2] pry(main)> q.freeze => #<Thread::Queue:0x000056263683aee8> [3] pry(main)> q << 1 => #<Thread::Queue:0x000056263683aee8> [4] pry(main)> q.pop => 1 [5] pry(main)> q.frozen? => true ``` Found by @ko1 in https://bugs.ruby-lang.org/issues/17100#note-28 I think it's a bug, since those are clear mutations. I guess old Thread::Queue implemented in Ruby did not have this bug. -- https://bugs.ruby-lang.org/

1 0

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

25 Sep '23

Issue #13933 has been updated by Dan0042 (Daniel DeLorme). akr (Akira Tanaka) wrote in #note-12: > From experience with `Float::NAN`, I think it is not a good idea to expand such objects. > It makes the behavior of `Array#<=>` inconsistent. I agree but I think this is a bit different from what I was talking about. Float::NAN is a float that is not comparable with other floats. This is not the same case as a value that is not comparable with anything else. > There is no reason to break it. I agree; as I said, I'm not suggesting we change this now. > > 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?` > > You ignored the user-defined classes I mentioned. > A user may define a class with a minimum value. > The minimum value may not have `empty?` method. How do you define which is the minimum value? I suggested the above as a *posssible* way to define the minimum value. So a custom class would need to have #empty? that returns true in order to define "this is the minimum". But it was just a suggestion. Or maybe each class could have a MINIMUM constant like `String::MINIMUM = ""`, etc. More importantly, I think that `(...minimum).empty?` is such an edge case of an edge case that it's not worth worrying too much. Are you suggesting that `Range#empty?` should not exist just because it's not possible to perfectly handle this extreme edge case for every possible class? Would it really be so bad if it returned `true` for user-defined classes? ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104753 * 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:114894] [Ruby master Feature#13933] Add Range#empty?
by akr (Akira Tanaka) 24 Sep '23

24 Sep '23

Issue #13933 has been updated by akr (Akira Tanaka). Dan0042 (Daniel DeLorme) wrote in #note-9: > 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?` There is an actual example of `(x <=> x) = nil`, `Float::NAN`. ``` % ruby -e 'x = Float::NAN; p x <=> x' nil ``` From experience with `Float::NAN`, I think it is not a good idea to expand such objects. It makes the behavior of `Array#<=>` inconsistent. ``` % ruby -e 'a = [Float::NAN]; p a <=> a' 0 ``` Since the (only) element of the array, `Float::NAN`, is not comparable, the array should not be comparable. But `a <=> a` returns 0 which means it is comparable and equal. It is because `Array#<=>` returns 0 if the given argument is the receiver itself, regardless of its elements. We need to choose efficiency or consistency. Ruby chooses efficiency here: `Array#<=>` returns 0 without examining its elements. Expanding `Floag::NAN`'like behavior makes this inconsistency more visible. I agree that objects comparable only with itself have not much usage for range. But their order is well-defined as a partial order. There is no reason to break it. > 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?` You ignored the user-defined classes I mentioned. A user may define a class with a minimum value. The minimum value may not have `empty?` method. ---------------------------------------- Feature #13933: Add Range#empty? https://bugs.ruby-lang.org/issues/13933#change-104752 * 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:114641] [Ruby master Bug#19864] Ruby 3.2 Changed Behavior With One Sided Ranges
by Aesthetikx (John DeSilva) 24 Sep '23

24 Sep '23

Issue #19864 has been reported by Aesthetikx (John DeSilva). ---------------------------------------- Bug #19864: Ruby 3.2 Changed Behavior With One Sided Ranges https://bugs.ruby-lang.org/issues/19864 * Author: Aesthetikx (John DeSilva) * Status: Open * Priority: Normal * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Thank you for taking the time to read my issue. I know there has been some previous discussion here https://bugs.ruby-lang.org/issues/19533 regarding a similar issue, although I think this is different. I apologize if this has already been addressed. Prior to Ruby 3.2, you could use a beginless or endless range, and use === (or a case statement) to determine if a given date matched that range. For example, (..today) === yesterday would have returned true, and (tomorrow..) === today would have returned false. Please see my attached file for a more concrete example. Starting with Ruby 3.2, this results in "`===': cannot determine inclusion in beginless/endless ranges (TypeError)". I can imagine that there is difficulty and ambiguity with these infinite ranges and non numeric objects, however I do feel that these examples with dates should work, especially since (..Date.today).cover?(Date.today) still works as expected. ---Files-------------------------------- range_test.rb (928 Bytes) -- https://bugs.ruby-lang.org/

5 5

[ruby-core:114568] [Ruby master Bug#19853] Segfault when calling `system` from a non-blocking fiber
by rmosolgo (Robert Mosolgo) 24 Sep '23

24 Sep '23

Issue #19853 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #19853: Segfault when calling `system` from a non-blocking fiber https://bugs.ruby-lang.org/issues/19853 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi! I'm trying to improve my Ruby library to support transfer-based fibers (https://github.com/rmosolgo/graphql-ruby/pull/4322) To test parallel I/O, I'm using `system("sleep #{duration}")`, but this causes a segfault sometimes. I'd love to find a way to keep developing this feature but I'm not sure where to go next. I have attached a script which replicates the bug and I have attached the full segfault error dump. I encountered this error by running: ``` ruby fiber_bug.rb 2>out.txt ``` Does that help debug? Please let me know if I can provide anything else that'd be helpful. ---Files-------------------------------- out.txt (121 KB) fiber_bug.rb (624 Bytes) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:114803] [Ruby master Bug#19890] File#realine(chomp: true) slower/more allocations than readline.chomp!
by segiddins (Samuel Giddins) 22 Sep '23

22 Sep '23

Issue #19890 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19890: File#realine(chomp: true) slower/more allocations than readline.chomp! https://bugs.ruby-lang.org/issues/19890 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- On ruby 3.2.2 running the following script: ``` ruby #!/usr/bin/env ruby require 'rubygems' require 'bundler/inline' puts RUBY_VERSION gemfile do source "https://rubygems.org" gem "benchmark-ipsa" end Benchmark.ipsa do |x| x.report("f.readline(chomp: true)") do File.open("/usr/share/dict/words") do |f| f.readline(chomp: true) until f.eof? end end x.report("f.readline.chomp!") do File.open("/usr/share/dict/words") do |f| until f.eof? s = f.readline s.chomp! s end end end x.report("f.readline.chomp") do File.open("/usr/share/dict/words") do |f| until f.eof? f.readline.chomp end end end x.compare! end ``` I get the following (surprising) result: ``` 3.2.2 Allocations ------------------------------------- f.readline(chomp: true) 707931/1 alloc/ret 50/1 strings/ret f.readline.chomp! 235979/1 alloc/ret 50/1 strings/ret f.readline.chomp 471955/1 alloc/ret 50/1 strings/ret Warming up -------------------------------------- f.readline(chomp: true) 1.000 i/100ms f.readline.chomp! 2.000 i/100ms f.readline.chomp 2.000 i/100ms Calculating ------------------------------------- f.readline(chomp: true) 16.165 (± 6.2%) i/s - 81.000 f.readline.chomp! 25.246 (± 7.9%) i/s - 126.000 f.readline.chomp 20.997 (± 9.5%) i/s - 106.000 Comparison: f.readline.chomp!: 25.2 i/s f.readline.chomp: 21.0 i/s - 1.20x slower f.readline(chomp: true): 16.2 i/s - 1.56x slower ``` I would expect `File#readline(chomp: true)` to be comparable to `s = f.readline; s.chomp!; s` at a bare minimum, but it is slower and has more allocations even than `readline.chomp` -- https://bugs.ruby-lang.org/

4 11

[ruby-core:114222] [Ruby master Misc#19772] API Naming for YARP compiler
by jemmai (Jemma Issroff) 22 Sep '23

22 Sep '23

Issue #19772 has been reported by jemmai (Jemma Issroff). ---------------------------------------- Misc #19772: API Naming for YARP compiler https://bugs.ruby-lang.org/issues/19772 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal ---------------------------------------- We are working on the YARP compiler, and have [the first PR ready](https://github.com/ruby/ruby/pull/8042) which introduces the YARP compile method. Our only outstanding question before merging it is about naming. How should we expose the public API for YARP's compile method? Potential suggestions: 1. YARP.compile 2. RubyVM::InstructionSequence.compile(yarp: true) 3. RubyVM::InstructionSequence.compile_yarp 4. Any of the above options, with a name other than yarp (please suggest an alternative) Regarding option 1, which would mirror `YARP.parse`, is the top level constant `YARP` acceptable? cc @matz @ko1 -- https://bugs.ruby-lang.org/

9 30