test_memsize_of_iseq fails on repeat tests and it seems to difficult
to solve immediately. Now this test is skipped.
It seems that the result of `memsize_of(Object.new)` are increased.
Why...?
Constant definitions are affect on outer namespace of an anonymous
module. To define constants on the anonymous module, this patch
uses Module#class_eval(str).
Rational literals are those integers suffixed with `r`. They tend to
be a part of more complex expressions like `123/456r`, but in theory
they can live alone. When such "bare" rational literals are passed to
case-when branch, we have to take care of them. Fixes [Bug #17854]
Remove discussion of Ruby 2.7 specific handling of keyword
argument separation. Add a small example of keyword to
positional hash conversion for methods not accepting
keyword arguments.
* Run nmake check on Actions
* Skip tests not working in mswin GitHub Actions
* Override TEMP
* Revert "Skip tests not working in mswin GitHub Actions"
This reverts commit 544d2575fcdf23ae63cd25aa03fce10c28b259f2.
* Revert "Revert "Skip tests not working in mswin GitHub Actions""
This reverts commit e1f8ad7862c9c4be52dc6e1031a004621eb07e6e.
* Fix timeouts
* Skip some more broken tests
* Update windows.yml
* Add a guard for rbasic_spec
* Revert "Update windows.yml"
This reverts commit bc9694b6b3b9594d406378d15ca11723fb052bc8.
* Skip the ensure clause
* Simplify the ensure
Instead of on read. Once it's in the inline cache we never have to make
one again. We want to eventually put the value into the cache, and the
best opportunity to do that is when you write the value.
This change implements a cache for class variables. Previously there was
no cache for cvars. Cvar access is slow due to needing to travel all the
way up th ancestor tree before returning the cvar value. The deeper the
ancestor tree the slower cvar access will be.
The benefits of the cache are more visible with a higher number of
included modules due to the way Ruby looks up class variables. The
benchmark here includes 26 modules and shows with the cache, this branch
is 6.5x faster when accessing class variables.
```
compare-ruby: ruby 3.1.0dev (2021-03-15T06:22:34Z master 9e5105ca45) [x86_64-darwin19]
built-ruby: ruby 3.1.0dev (2021-03-15T12:12:44Z add-cache-for-clas.. c6be0093ae) [x86_64-darwin19]
| |compare-ruby|built-ruby|
|:--------|-----------:|---------:|
|vm_cvar | 5.681M| 36.980M|
| | -| 6.51x|
```
Benchmark.ips calling `ActiveRecord::Base.logger` from within a Rails
application. ActiveRecord::Base.logger has 71 ancestors. The more
ancestors a tree has, the more clear the speed increase. IE if Base had
only one ancestor we'd see no improvement. This benchmark is run on a
vanilla Rails application.
Benchmark code:
```ruby
require "benchmark/ips"
require_relative "config/environment"
Benchmark.ips do |x|
x.report "logger" do
ActiveRecord::Base.logger
end
end
```
Ruby 3.0 master / Rails 6.1:
```
Warming up --------------------------------------
logger 155.251k i/100ms
Calculating -------------------------------------
```
Ruby 3.0 with cvar cache / Rails 6.1:
```
Warming up --------------------------------------
logger 1.546M i/100ms
Calculating -------------------------------------
logger 14.857M (± 4.8%) i/s - 74.198M in 5.006202s
```
Lastly we ran a benchmark to demonstate the difference between master
and our cache when the number of modules increases. This benchmark
measures 1 ancestor, 30 ancestors, and 100 ancestors.
Ruby 3.0 master:
```
Warming up --------------------------------------
1 module 1.231M i/100ms
30 modules 432.020k i/100ms
100 modules 145.399k i/100ms
Calculating -------------------------------------
1 module 12.210M (± 2.1%) i/s - 61.553M in 5.043400s
30 modules 4.354M (± 2.7%) i/s - 22.033M in 5.063839s
100 modules 1.434M (± 2.9%) i/s - 7.270M in 5.072531s
Comparison:
1 module: 12209958.3 i/s
30 modules: 4354217.8 i/s - 2.80x (± 0.00) slower
100 modules: 1434447.3 i/s - 8.51x (± 0.00) slower
```
Ruby 3.0 with cvar cache:
```
Warming up --------------------------------------
1 module 1.641M i/100ms
30 modules 1.655M i/100ms
100 modules 1.620M i/100ms
Calculating -------------------------------------
1 module 16.279M (± 3.8%) i/s - 82.038M in 5.046923s
30 modules 15.891M (± 3.9%) i/s - 79.459M in 5.007958s
100 modules 16.087M (± 3.6%) i/s - 81.005M in 5.041931s
Comparison:
1 module: 16279458.0 i/s
100 modules: 16087484.6 i/s - same-ish: difference falls within error
30 modules: 15891406.2 i/s - same-ish: difference falls within error
```
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
To invalidate some callable method entries, we replace the entry in the
class. Most types of method entries are on the method table of the
origin class, but refinement entries without an orig_me are housed in
the method table of the class itself. They are there because refinements
take priority over prepended methods.
By unconditionally inserting a copy of the refinement entry into the
origin class, clearing the method cache created situations where there
are refinement entry duplicates in the lookup chain, leading to infinite
loops and other problems.
Update the replacement logic to use the right class that houses the
method entry. Also, be more selective about cache invalidation when
moving refinement entries for prepend. This avoids calling
clear_method_cache_by_id_in_class() before refinement entries are in the
place it expects.
[Bug #17806]
Follow https://github.com/ruby/irb/pull/237.
This PR fixes the following `Encoding::ConverterNotFoundError`.
```console
% bin/spring stop && bin/rails c
Spring stopped.
Running via Spring preloader in process 58395
Loading development environment (Rails 6.0.3.7)
irb(main):001:0> "こんにちは".do_something
Traceback (most recent call last):
(snip)
12: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:547:in `eval_input'
11: from /Users/koic/src/github.com/ruby/irb/lib/irb/ruby-lex.rb:232:in `each_top_level_statement'
10: from /Users/koic/src/github.com/ruby/irb/lib/irb/ruby-lex.rb:232:in `catch'
9: from /Users/koic/src/github.com/ruby/irb/lib/irb/ruby-lex.rb:233:in `block in each_top_level_statement'
8: from /Users/koic/src/github.com/ruby/irb/lib/irb/ruby-lex.rb:233:in `loop'
7: from /Users/koic/src/github.com/ruby/irb/lib/irb/ruby-lex.rb:251:in `block (2 levels) in each_top_level_statement'
6: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:548:in `block in eval_input'
5: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:758:in `signal_status'
4: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:586:in `block (2 levels) in eval_input'
3: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:650:in `handle_exception'
2: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:601:in `encode_with_invalid_byte_sequence'
1: from /Users/koic/src/github.com/ruby/irb/lib/irb.rb:601:in `new'
/Users/koic/src/github.com/ruby/irb/lib/irb.rb:601:in `initialize': code
converter not found (UTF-8 to UTF-8) (Encoding::ConverterNotFoundError)
```
First, this patch skips `Encoding::Converter.new` for the same encoding.
170531df19/lib/irb.rb (L601)
Next, this is a talk about the condition for skipping. `IRB.conf[:LC_MESSAGES].encoding`
becomes `"UTF-8"` string when `Reline.encoding_system_needs.name` is set in the below.
170531df19/lib/irb/input-method.rb (L269)
OTOH, `message.encoding` is `Encoding::UTF_8`, so these are compared as a string by this patch.
https://github.com/ruby/irb/commit/6df6e76cfc
... for the output of assert_in_out_err.
This will fix the following failure on many CI machines
http://rubyci.s3.amazonaws.com/arch/ruby-master/log/20210511T030005Z.fail.html.gz
```
1) Failure:
TestIRB::TestRaiseNoBacktraceException#test_raise_exception_with_different_encoding_containing_invalid_byte_sequence [/home/chkbuild/chkbuild/tmp/build/20210511T030005Z/ruby/test/irb/test_raise_no_backtrace_exception.rb:41]:
pid 221531 exit 0.
1. [1/2] Assertion for "stdout"
| invalid byte sequence in US-ASCII.
```
Hiroshi SHIBATA
Koichi Sasada
卜部昌平
Shugo Maeda
Jeremy Evans
Takashi Kokubun
Aaron Patterson
eileencodes
git
Alan Wu
Yusuke Endoh
Koichi ITO