Some tests are currently wrapped with
`if Process.respond_to?(:fork)`
but they're still executed on JRuby. The problem is that ForkTracker
unconditionally patches `#fork` so `Process` does indeed
`respond_to? :fork`.
Fix it by installing the patch conditionally with the same check.
Rational values are move precise than float values so when comparing
rationals values may be off by a few units that are hard to assert
equality. Let's make sure we are comparing the float value with float
values.
These failed previously because decimals floats don't make perfect
decimal numbers and Rational represents them exactly (either as decimal
or the inexact float value).
This changes the asserts to match that value.
We were using picoseconds as precision but some Ruby implementations
only support up to nanoseconds. Since that much precision was not needed
to test the feature I decreased the precision.
We hook into Kernel#fork and Process#fork, when they are invoked
we can trigger all the registered callbacks.
There is also a `check!` method that can be called to very cheaply
detect if the process was forked.
* String#+@ is available since Ruby 2.3.
* See the upstream Ruby change making Symbol#to_s return a frozen String
for efficiency: https://github.com/ruby/ruby/pull/2437
We prepend a check against the thread-local level to Logger#add, but because it proceeds to check against the thread-global level, only setting a quieter thread-local level works. The quietest of the two wins. Fix by reimplementing #add entirely.
It's unfortunate to have to do this, but I've already patched upstream Logger to prefer the level instance method over the @level instance variable, so we'll be able to avoid touching #add at all in the future. See https://github.com/ruby/logger/pull/41.
* boot when there is folders to watch
* raise argument error when paths are empty
* add space between curly braces
* Revert "add space between curly braces"
This reverts commit 90cff20c87.
* Revert "raise argument error when paths are empty"
This reverts commit 349adff0f5.
* stop lazy loading listem gem
* back with any?
* require listen gem at top of the file
* improve
* remove scope resolution operator
The previous implementation is pretty much linear.
Delegating 10 methods is 10 times slower than delegating 1 method.
```
old_delegate(1) 27.299k (± 2.7%) i/s - 138.216k in 5.066863s
old_delegate(2) 14.372k (± 2.5%) i/s - 72.879k in 5.074092s
old_delegate(3) 9.434k (± 7.3%) i/s - 47.750k in 5.092412s
old_delegate(4) 6.771k (±10.4%) i/s - 33.810k in 5.060218s
old_delegate(5) 5.733k (± 4.4%) i/s - 28.861k in 5.044486s
```
Beside a few micro-optimizations, this patch mostly try to call `module_eval`
only once, because it has a significant fixed cost every time it's called.
By concatening the method definitions to together, we gain performance when
multiple methods are delegated at once:
```
new_delegate(1) 28.531k (± 2.6%) i/s - 143.052k in 5.017356s
new_delegate(2) 16.751k (± 2.4%) i/s - 85.072k in 5.081371s
new_delegate(3) 12.021k (± 3.0%) i/s - 61.048k in 5.083224s
new_delegate(4) 9.433k (± 3.1%) i/s - 47.944k in 5.087528s
new_delegate(5) 7.745k (± 3.0%) i/s - 38.849k in 5.020850s
```
Which is respectively 5%, 16%, 27%, 39% and 35% improvements.
Solaris returns `true` for `defined?(Process::CLOCK_PROCESS_CPUTIME_ID)` but calling `Process.clock_gettime(Process::CLOCK_PROCESS_CPUTIME_ID)` raises `Errno::EINVAL: Invalid argument - clock_gettime` when `ActiveSupport::Notifications::Event.now_cpu` is called.
IRB invokes `#hash` (via a call to `Hash#include?`) and
`#instance_methods` on each object in `ObjectSpace.each_object(Module)`
when performing tab-completion on chain of method calls. This patch
prevents a deprecation warning from being printed when any of those
objects are a `ActiveSupport::Deprecation::DeprecatedConstantProxy`.
Fixes#37097.
since RedisCacheStore#write_entry takes kwargs, we needed to kwargsify all these methods
in order to eliminate Ruby 2.7 warnings.
It's a little bit bigger patch than I expected, but it doesn't warn on Ruby 3,
and it doesn't introduce any incompatibility on loder rubies, so it may not be a bad thing anyway.
Jean Boussier