rails5 uses the listen gem to watch for changes from autoload directories
and from i18n directories. Changes there would be reflected by the
running app, in development mode usually.
However, files outside of the application directory or locally installed
gems should not change during development, and rails does not need to
reflect changes there if they do.
This change makes sure only those paths that do not originate from
the app itself are watched. This can help especially with the situation on
OSX, where rb-fsevent - which implements file watching - is quite a
resource hog.
Previously `ActiveSupport::Duration.parse` used `Time.current` and
`Time#advance` to calculate the number of seconds in the duration
from an arbitrary collection of parts. However as `advance` tries to
be consistent across DST boundaries this meant that either the
duration was shorter or longer depending on the time of year.
This was fixed by using an absolute reference point in UTC which
isn't subject to DST transitions. An arbitrary date of Jan 1st, 2000
was chosen for no other reason that it seemed appropriate.
Additionally, duration parsing should now be marginally faster as we
are no longer creating instances of `ActiveSupport::TimeWithZone`
every time we parse a duration string.
Fixes#26941.
- When `as_json` returns `Infinity` or `NaN` as the value of any of the key,
we don't used to call `as_json` on it as it was treated as primitive.
- This used to pass `Infinity` or `NaN` to `JSON.generate` and Ruby used
to throw an error for `Infinity/NaN not allowed in JSON.`
- This patch changes the code to call `as_json` on these primitives so
that they are converted to proper values before being passed to
`JSON.generate`.
- Fixes#26877.
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
On Ruby 2.4, naitive `Hash#transform_values` is implemented.
`Hash#transform_values` uses an instance of Hash (`rb_hash_new`) to
collect returned values of a block.
For ensuring `#transform_values` of HWIDA to return HWIDA, we should
define `#transform_values` on HWIDA.
This reverts commit a01cf703 as explained in the comment to #26826:
Realized that this PR caused the following warning in Travis CI:
```
/home/travis/build/rails/rails/activesupport/lib/active_support/dependencies.rb:293: warning: loading in progress, circular require considered harmful - /home/travis/build/rails/rails/activesupport/lib/active_support/core_ext/hash/indifferent_access.rb
```
Indeed, `active_support/core_ext/hash/indifferent_access.rb` **needs** to require `active_support/hash_with_indifferent_access.rb` in order to access the class `ActiveSupport::HashWithIndifferentAccess`.
The other way around, though, is not _strictly_ required, unless someone tries (like I did in the [gist above](https://gist.github.com/claudiob/43cc7fe77ff95951538af2825a71e5ec)) to use `ActiveSupport::HashWithIndifferentAccess` by only requiring `active_support/hash_with_indifferent_access.rb` without first requiring `active_support/core_ext/hash/indifferent_access.rb`.
I think the solution to this is to revert this PR and instead change the documentation to explicitly state that **developers should not require 'active_support/hash_with_indifferent_access'** if all they want is to use `ActiveSupport::HashWithIndifferentAccess` – instead they should require `active_support/core_ext/hash/indifferent_access.rb`.
In https://bugs.ruby-lang.org/issues/12860 I argue that MRI's
execution order here is incorrect. The splatting of the 'c' args
should happen before the shift, but it happens after. On JRuby, it
behaves the way you would expect, leading to the 'c' args splat
still containing the block and producing an error like "cannot
convert proc to symbol" when the send attempts to coerce
it.
This patch makes the unpacking order explicit with a multi-assign,
which behaves properly on all implementations I tested.
This is a follow up to #25681, specifically this comment:
https://github.com/rails/rails/pull/25681#issuecomment-238294002
The way the thread local variable is stored is an implementation detail
and subject to change. It makes no sense to only generate a reader or
writer as you'd have to know where to read from or where it writes to.
`copy_time_to` is a helper function for date and time calculations.
It's being used by `prev_week`, `next_week` and `prev_weekday` to keep
the time fraction when jumping around between days.
Previously the nanoseconds part was lost during the operation. This
lead to problems in practice if you were using the `end_of_day`
calculation. Resulting in the time fraction of `end_of_day` not being
the same as next week's `end_of_day`.
With this fix `copy_time_to` doesn't forget the `nsec` digits.
The methods Hash#transform_values and Hash#transform_values! have been
implemented in Ruby and they'll be available as part of the standard
library.
Here's the link to the discussion in Ruby's issue tracker:
https://bugs.ruby-lang.org/issues/12512
These methods are implemented in C so they're expected to perform
better.
@amatsuda, during his RailsConf talk this past year, presented a
benchmark that showed `Time.zone.now` (an Active Support joint)
performing 24.97x slower than Ruby's `Time.now`. Rails master appears to
be a _bit_ faster than that, currently clocking in at 18.25x slower than
`Time.now`. Here's the exact benchmark data for that:
```
Warming up --------------------------------------
Time.now 127.923k i/100ms
Time.zone.now 10.275k i/100ms
Calculating -------------------------------------
Time.now 1.946M (± 5.9%) i/s - 9.722M in 5.010236s
Time.zone.now 106.625k (± 4.3%) i/s - 534.300k in 5.020343s
Comparison:
Time.now: 1946220.1 i/s
Time.zone.now: 106625.5 i/s - 18.25x slower
```
What if I told you we could make `Time.zone.now` _even_ faster? Well,
that's exactly what this patch accomplishes. When creating `ActiveSupport::TimeWithZone`
objects, we try to convert the provided time to be in a UTC format. All
this patch does is, in the method where we convert a provided time to
UTC, check if the provided time is already UTC, and is a `Time` object
and then return early if that is the case, This sidesteps having to continue on,
and create a new `Time` object from scratch. Here's the exact benchmark
data for my patch:
```
Warming up --------------------------------------
Time.now 124.136k i/100ms
Time.zone.now 26.260k i/100ms
Calculating -------------------------------------
Time.now 1.894M (± 6.4%) i/s - 9.434M in 5.000153s
Time.zone.now 301.654k (± 4.3%) i/s - 1.523M in 5.058328s
Comparison:
Time.now: 1893958.0 i/s
Time.zone.now: 301653.7 i/s - 6.28x slower
```
With this patch, we go from `Time.zone.now` being 18.25x slower than
`Time.now` to only being 6.28x slower than `Time.now`. I'd obviously love some
verification on this patch, since these numbers sound pretty interesting... :)
This is the benchmark-ips report I have been using while working on this:
```ruby
require 'benchmark/ips'
Time.zone = 'Eastern Time (US & Canada)'
Benchmark.ips do |x|
x.report('Time.now') {
Time.now
}
x.report('Time.zone.now') {
Time.zone.now
}
x.compare!
end
```
cc @amatsuda
cc performance folks @tenderlove and @schneems
In #25880 we tried to cache localtime to fix the performance
regression but that proved to be difficult due to the fact that
localtime/getlocal can take a utc_offset argument. We tried
caching based on the argument but since the argument can be nil
sometimes that meant that if the TZ environment variable changed
then the cached value for nil became invalid. By moving the
caching to DateAndTime#compatibility we don't have to worry about
arguments since it doesn't take any.
There is a possible edge condition where preserve_timezone is set
to false and the system timezone changes then it could result in
a cached value being incorrect but the only way to fix this would
be to remove all caching and live with the performance issue.
Turns out trying to cache on localtime with arguments is too hard
so we'll do it on DateAndTime::Compatibility#to_time instead.
This reverts commit 3132fa6b7d9585e04eb44b25b55d298391b040b5, reversing
changes made to 6949f8e5e7dc901d4e04ebab6c975afb33ca44c9.
Turns out trying to cache on localtime with arguments is too hard
so we'll do it on DateAndTime::Compatibility#to_time instead.
This reverts commit 9ce2d1b1a43fc4ef3db59849b7412d30583a4074, reversing
changes made to 53ede1aff2025d4391d0e05ba471fdaf3110a99c.
Previously memoization in `localtime` wasn't taking the `utc_offset`
parameter into account when returning a cached value. It now caches the
computed value depending on the `utc_offset` parameter, e.g:
Time.zone = "US/Eastern"
t = Time.zone.local(2016,5,2,11)
# => Mon, 02 May 2016 11:00:00 EDT -04:00
t.localtime(-7200)
# => 2016-05-02 13:00:00 -0200
t.localtime(-3600)
# => 2016-05-02 14:00:00 -0100
Callbacks are everywhere, so it's better if we can avoid making a mess
of the backtrace just because we've passed through a callback hook.
I'm making no effort to the before/after invocations: those only affect
backtraces while they're running. The calls that matter are the ones
that remain on the call stack after run_callbacks yields: around
callbacks, and internal book-keeping around the before/afters.
The Rails test runner supports three ways to run tests: directly, via rake, or ruby.
When Running with Ruby ala `ruby -Itest test/models/post_test.rb` our test file would
be evaluated first, requiring `test_helper` and then `active_support/testing/autorun`
that would then require the test file (which it hadn't been before) thus reevaluating
it. This caused exceptions if using Active Support's declarative syntax.
Fix this by shifting around when we set the how we're run to closer mimick the require
order.
If we're running with `bin/rails test` the test command file is run first and we then
set `run_with_rails_extension`, later we hit `active_support/testing/autorun` and do
nothing — because we've been run elsewhere.
If we at this point haven't set `run_with_rails_extension` we've been running with
`ruby` this whole time and thus we set that.
We should always trigger `Minitest.autorun` as it doesn't hurt to call it twice.
Consolidate the two methods into a single one that better brings out the intent of
why they're there.
Previously calls to `in` were being sent to the non-DST aware
method `Time#since` via `method_missing`. It is now aliased to
the DST aware `ActiveSupport::TimeWithZone#+` which handles
transitions across DST boundaries, e.g:
Time.zone = "US/Eastern"
t = Time.zone.local(2016,11,6,1)
# => Sun, 06 Nov 2016 01:00:00 EDT -05:00
t.in(1.hour)
# => Sun, 06 Nov 2016 01:00:00 EST -05:00
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
Currently mongrel is not maintained.
And it couldn't be built with any Ruby versions that
supported by Rails.
It is reasonable to remove the word "mongrel" in order to avoid
confusion from newcomer.
Recently, the Rails team made an effort to keep the source code consistent, using Ruboco
(bb1ecdcc677bf6e68e0252505509c089619b5b90 and below). Some of the case
statements were missed.
This changes the case statements' formatting and is consistent with changes
in 810dff7c9fa9b2a38eb1560ce0378d760529ee6b and db63406cb007ab3756d2a96d2e0b5d4e777f8231.
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But heredocs was still kept absolute position. This commit aligns
heredocs indentation for consistency.
As demonstrated in #25880 the to_time method converts the utc time
instance to a local time instance which is an expensive operation.
Since to_datetime involves similar expensive operations we should
also cache it to speed up comparison with lots of values.
ActiveSupport::Testing::Assertions.
We have a separate module in which have defined Rails' own custom
assertions. So it would be good to keep all custom Rails' assertions in
one place i.e. in this module.
A performance regression was introduced by commit b79adc4323ff289aed3f5787fdfbb9542aa4f89f
from Rails 4.0.0.beta1, in which `TimeWithZone#to_time` no longer returns a
cached instance attribute but instead coerces the value to `Time`. This
coerced value is not cached, and recomputation degrades the performance
of comparisons between TimeWithZone objects.
See b79adc4323 (diff-3497a506c921a3a3e40fd517e92e4fe3R322)
for the change in question.
The following benchmark, which reverts the change linked above, demonstrates
the performance regression:
require 'active_support/time'
require 'benchmark/ips'
utc = Time.utc(2000, 1, 1, 0)
time_zone = ActiveSupport::TimeZone['Eastern Time (US & Canada)']
twz = ActiveSupport::TimeWithZone.new(utc, time_zone)
twz2 = ActiveSupport::TimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
patchedTimeWithZone = Class.new(ActiveSupport::TimeWithZone) do
def to_time
utc
end
end
patched_twz = patchedTimeWithZone.new(utc, time_zone)
patched_twz2 = patchedTimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
Benchmark.ips do |x|
x.report("comparison out of the box") { twz <=> twz2 }
x.report("comparison reverting to_time") { patched_twz <=> patched_twz2 }
x.compare!
end
The results, when run in rails-dev-box, are as follows:
Warming up --------------------------------------
comparison out of the box
24.765k i/100ms
comparison reverting to_time
57.237k i/100ms
Calculating -------------------------------------
comparison out of the box
517.245k (± 4.7%) i/s - 2.600M in 5.038700s
comparison reverting to_time
2.624M (± 5.0%) i/s - 13.050M in 4.985808s
Comparison:
comparison reverting to_time: 2624266.1 i/s
comparison out of the box: 517244.6 i/s - 5.07x slower
The change made to run the benchmark, however, is not possible, as it would
undo the intent to standardize the return value of `to_time` to `Time` in
the system timezone.
Our proposed solution is to restore the caching behaviour of `to_time`
as it existed prior to the change linked above.
Benchmark of our solution:
require 'active_support/time'
require 'benchmark/ips'
patchedTimeWithZone = Class.new(ActiveSupport::TimeWithZone) do
def to_time
@to_time ||= super
end
end
utc = Time.utc(2000, 1, 1, 0)
time_zone = ActiveSupport::TimeZone['Eastern Time (US & Canada)']
twz = ActiveSupport::TimeWithZone.new(utc, time_zone)
twz2 = ActiveSupport::TimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
patched_twz = patchedTimeWithZone.new(utc, time_zone)
patched_twz2 = patchedTimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
Benchmark.ips do |x|
x.report("TimeWithZone comparison - existing implementation") { twz <=> twz2 }
x.report("TimeWithZone comparison - caching implementation") { patched_twz <=> patched_twz2 }
x.compare!
end
Results in rails-dev-box:
Warming up --------------------------------------
TimeWithZone comparison - existing implementation
26.629k i/100ms
TimeWithZone comparison - caching implementation
59.144k i/100ms
Calculating -------------------------------------
TimeWithZone comparison - existing implementation
489.757k (± 4.2%) i/s - 2.450M in 5.011639s
TimeWithZone comparison - caching implementation
2.802M (± 5.3%) i/s - 13.958M in 4.996116s
Comparison:
TimeWithZone comparison - caching implementation: 2801519.1 i/s
TimeWithZone comparison - existing implementation: 489756.7 i/s - 5.72x slower
This code has too much duplication and the rationale for the concatenation
may not be obvious to the reader. You define the ones at class-level, explain
why does the code concatenates there, and then the convenience ones at
instance-level just delegate.
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
The current implementation of `thread_mattr_accessor` set variable
sharing superclass with subclass. So the method doesn't work as documented.
Precondition
class Account
thread_mattr_accessor :user
end
class Customer < Account
end
Account.user = "DHH"
Account.user #=> "DHH"
Customer.user = "Rafael"
Customer.user # => "Rafael"
Documented behavior
Account.user # => "DHH"
Actual behavior
Account.user # => "Rafael"
Current implementation set variable statically likes `Thread[:attr_Account_user]`,
and customer also use it.
Make variable name dynamic to use own thread-local variable.
Since 434df00 week durations are no longer converted to days. This means
we need to add :weeks to the parts that ActiveSupport::TimeWithZone will
consider being of variable duration to take account of DST transitions.
Fixes#26039.
AEAD modes like `aes-256-gcm` provide both confidentiality and data authenticity, eliminating the need to use MessageVerifier to check if the encrypted data has been tampered with.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
Those are assertions that I really do miss from the standard
`ActiveSupport::TestCase`. Think of those as a more general version of
`assert_difference` and `assert_no_difference` (those can be implemented
by assert_changes, should this change be accepted).
Why do we need those? They are useful when you want to check a
side-effect of an operation. `assert_difference` do cover a really
common case, but we `assert_changes` gives us more control. Having a
global error flag? You can test it easily with `assert_changes`. In
fact, you can be really specific about the initial state and the
terminal one.
```ruby
error = Error.new(:bad)
assert_changes -> { Error.current }, from: nil, to: error do
expected_bad_operation
end
```
`assert_changes` follows `assert_difference` and a string can be given
for evaluation as well.
```ruby
error = Error.new(:bad)
assert_changes 'Error.current', from: nil, to: error do
expected_bad_operation
end
```
Check out the test cases if you wanna see more examples.
🍻
Fix for issue https://github.com/rails/rails/issues/25784
Prior to this commit the lazy_load_hooks.rb file contained important lazy load
hooks. Since [7c90d91](7c90d91c3c) the [documentation](http://api.rubyonrails.org/files/activesupport/lib/active_support/lazy_load_hooks_rb.html) did not display
the comments in this file as the docs for load hooks.
This commit wraps the code within this file in a module so we can display the
documentation for `ActiveSupport` load hooks. By extending `ActiveSupport` with
this module, all the methods within it should still be accessible through
`ActiveSupport`.
The current implementation serializes zero-length durations incorrectly (it serializes as `"-P"`), and cannot un-serialize itself:
```
[1] pry(main)> ActiveSupport::Duration.parse(0.minutes.iso8601)
ActiveSupport::Duration::ISO8601Parser::ParsingError: Invalid ISO 8601 duration: "-P" is empty duration
from /Users/rando/.gem/ruby/2.3.1/gems/activesupport-5.0.0/lib/active_support/duration/iso8601_parser.rb:96:in `raise_parsing_error'
```
Postgres empty intervals are serialized as `"PT0S"`, which is also parseable by the Duration deserializer, so I've modified the `ISO8601Serializer` to do the same.
Additionally, the `#normalize` function returned a negative sign if `parts` was blank (all zero). Even though this fix does not rely on the sign, I've gone ahead and corrected that, too, in case a future refactoring of `#serialize` uses it.
as this can lead to confusing time stubbing.
Instead of:
travel_to 2.days.from_now do
# 2 days from today
travel_to 3.days.from_now do
# 5 days from today
end
end
preferred way to achieve above is:
travel_to 2.days.from_now
# 2 days from today
travel_back
travel_to 5.days.from_now
# 5 days from today
Closes#24690Fixes#24689
KeyGenerator is used in other contexts, and we cannot change its
output... even if it does accidentally default to generating excess key
material for our primary internal usage.
ruby < 2.4 allowed accepting these values, as extra key bits were ignored. Since ce635262f5 this now has a strict checking on key length.
Default to key length 32 bytes, to match the compatible length for aes-256-cbc
Fixes#25185
When the Pathname object is converted as JSON,
it should be a string that means itself.
Expected:
```
>> Pathname.new('/path/to/somewhere.txt').as_json
"/path/to/somewhere.txt"
```
Actual:
```
>> Pathname.new('/path/to/somewhere.txt').as_json
{"path"=>"/path/to/somewhere.txt"}
```
When the URI object is converted as JSON,
it is expected that it is a string that means its URI.
Expected:
```
>> URI.parse('http://example.com').as_json
"http://example.com"
```
Actual:
```
>> URI.parse('http://example.com').as_json
{"scheme"=>"http",
"user"=>nil,
"password"=>nil,
"host"=>"example.com",
"port"=>80,
"path"=>"",
"query"=>nil,
"opaque"=>nil,
"fragment"=>nil,
"parser"=>
{"regexp"=>
{"SCHEME"=>"(?-mix:\\A[A-Za-z][A-Za-z0-9+\\-.]*\\z)",
"USERINFO"=>"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=A-Z_a-z~])*\\z)",
"HOST"=>
"(?-mix:\\A(?:(?<IP-literal>\\[(?:(?<IPv6address>(?:\\h{1,4}:){6}(?<ls32>\\h{1,4}:\\h{1,4}|(?<IPv4address>(?<dec-octet>[1-9]\\d|1\\d{2}|2[0-4]\\d|25[0-5]|\\d)\\.\\g<dec-octet>\\.\\g<dec-octet>\\.\\g<dec-octet>))|::(?:\\h{1,4}:){5}\\g<ls32>|\\h{,4}::(?:\\h{1,4}:){4}\\g<ls32>|(?:(?:\\h{1,4}:)?\\h{1,4})?::(?:\\h{1,4}:){3}\\g<ls32>|(?:(?:\\h{1,4}:){,2}\\h{1,4})?::(?:\\h{1,4}:){2}\\g<ls32>|(?:(?:\\h{1,4}:){,3}\\h{1,4})?::\\h{1,4}:\\g<ls32>|(?:(?:\\h{1,4}:){,4}\\h{1,4})?::\\g<ls32>|(?:(?:\\h{1,4}:){,5}\\h{1,4})?::\\h{1,4}|(?:(?:\\h{1,4}:){,6}\\h{1,4})?::)|(?<IPvFuture>v\\h+\\.[!$&-.0-;=A-Z_a-z~]+))\\])|\\g<IPv4address>|(?<reg-name>(?:%\\h\\h|[!$&-.0-9;=A-Z_a-z~])*))\\z)",
"ABS_PATH"=>
"(?-mix:\\A\\/(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])*(?:\\/(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])*)*\\z)",
"REL_PATH"=>
"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])+(?:\\/(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])*)*\\z)",
"QUERY"=>"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~\\/?])*\\z)",
"FRAGMENT"=>"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~\\/?])*\\z)",
"OPAQUE"=>"(?-mix:\\A(?:[^\\/].*)?\\z)",
"PORT"=>
"(?-mix:\\A[\\x09\\x0a\\x0c\\x0d ]*\\d*[\\x09\\x0a\\x0c\\x0d ]*\\z)"}}}
```
Time.new is a Ruby method that uses system timezone. Traveling in time
using it is a recipe for confusion. Instead, Time.zone.local should
be used since it uses the Rails timezone.
Some files like routes.rb may be very large and vary between the initialization of the app and the first request. In these scenarios if we are using a forked process we cannot rely on the files to be unchanged between when the code is booted and the listener is started.
For that reason we start a listener on the main process immediately, when we detect that a process does not have a listener started we force the updated state to be true, so we are guaranteed to catch any changes made between the code initialization and the fork.
We need one file checker booted per process as talked about in #24990. Before we do a check to see if any updates have been registered by the listener we first check to make sure that the current process has booted a listener.
We are intentionally not starting a listener when the checker is created. This way we can avoid #25259 in which puma warns of multiple threads created before fork. As written the listener for each process will be invoked by the `ActionDispatch::Executor` middleware when the `updated?` method is called. This is the first middleware on the stack and will be invoked before application code is read into memory.
The downside of this approach is that the API is a little less obvious. I.e. that you have to call `updated?` to get the listener to start is not intuitive. We could make `boot!` not private if we want to make the API a little nicer. Alternatively we could boot when the checker is initialized however this reintroduces the puma threads warning, and also means that in cases of `rails server` or when using `preload!` that we have extra threads notifying of changes on a process that we don't care about.
[close#24990] [close#25259]
The related option of this method, `expires_in` is documented
as expecting an `ActiveSupport::Duration` value. To minimize any sort of
ambiguity between duration options, this change also documents
`race_condition_ttl` accepting `ActiveSupport::Duration`.
We are currently using `%e` which adds a space before the result if the
digit is a single number. This leads to strings like `February 2, 2016`
which is undesireable. I've opted to replace with 0 padding instead of
removing the padding entirely, to preserve compatibility for those
relying on the fact that the width is constant, and to be consistent
with time formatting.
Fixes#25251.
This reverts commit 28492204ee59a5aca2f3bc7b161d45724552686d.
Reason: `suppress` without an argument doesn't actually tell what is
supressing. Also, it can be confused with ActiveRecord::Base#suppress.
* Add default exceptions affected by suppress
suppress { do_something_that_might_fail }
# instead of
begin
do_something_that_might_fail
rescue
end
# or
do_something_that_might_fail rescue nil
* Do not add default exceptions list constant
[Rafael Mendonça França + Alexey Zapparov]
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
Follows the same pattern as controllers and jobs. Exceptions raised in
delivery jobs (enqueued by `#deliver_later`) are also delegated to the
mailer's rescue_from handlers, so you can handle the DeserializationError
raised by delivery jobs:
```ruby
class MyMailer < ApplicationMailer
rescue_from ActiveJob::DeserializationError do
…
end
```
ActiveSupport::Rescuable polish:
* Add the `rescue_with_handler` class method so exceptions may be
handled at the class level without requiring an instance.
* Rationalize `exception.cause` handling. If no handler matches the
exception, fall back to the handler that matches its cause.
* Handle exceptions raised elsewhere. Pass `object: …` to execute
the `rescue_from` handler (e.g. a method call or a block to
instance_exec) against a different object. Defaults to `self`.
Useful for queries like:
Item.where(created_at: Date.current.all_day)
There was already a Time#all_day with the same behaviour, but for
queries like the above, Date is more convenient.
Use original `Array#sum` when calculating Numeric sum.
This commit is related #24804 issue.
Issue #24804 reports `Array#sum` becomes much slower when
ActiveSupport is included.
This commit tries to use original method as far as possible.
```shell
$ cat array_sum.rb
class Array
alias core_sum sum
end
require 'benchmark/ips'
require 'active_support/core_ext/enumerable'
ary = [1.0] * 1_000_000
Benchmark.ips do |x|
x.report("core sum") { ary.core_sum }
x.report("AS's sum") { ary.sum }
x.compare!
end
$ bundle exec ruby -v -I lib array_sum.rb
ruby 2.4.0dev (2016-05-01 master 54867) [x86_64-darwin14]
Calculating -------------------------------------
core sum 4.000 i/100ms
AS's sum 5.000 i/100ms
-------------------------------------------------
core sum 50.492 (± 7.9%) i/s - 252.000
AS's sum 50.116 (± 6.0%) i/s - 250.000
Comparison:
core sum: 50.5 i/s
AS's sum: 50.1 i/s - 1.01x slower
```
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
This commit undoes 54243fe.
Reason: Further investigation has shown the benefit is not so clear
generally speaking.
There is a long discussion and several benchmarks in the PR #24658
if you are interested in the details.
This can be an issue when TZInfo::TimeZone#current_period is refreshed
due to timezone period transition, but it's not reflected in
ActiveSupport::TimeZone object.
For example, on Sun, 26 Oct 2014 22:00 UTC, Moscow changed its TZ from
MSK +04:00 to MSK +03:00 (-1 hour). If ActiveSupport::TimeZone['Moscow']
happens to be initialized just before the timezone transition, it will
cache its stale utc_offset even after the timezone transition.
This commit removes cache and fixes this issue.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
To suppress warning ('warning: method redefined; discarding old sum')
remove the method before override it.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
Awaken waiting threads even if the current thread (the previously
exclusive thread) hadn't taken a share lock.
This only happens in code that wasn't run within an executor, since that
always take an outermost share lock.
Previously these methods could return either a DateTime or a Time
depending on how the ActiveSupport::TimeWithZone instance had
been constructed. Changing to always return an instance of Time
eliminates a possible stack level too deep error in to_time where
it was wrapping a DateTime instance.
As a consequence of this the internal time value is now always an
instance of Time in the UTC timezone, whether that's as the UTC
time directly or a representation of the local time in the timezone.
There should be no consequences of this internal change and if
there are it's a bug due to leaky abstractions.
`DateTime#getlocal` is newly added public API.
It's responsible is same as `DateTime#utc`, so `calculations.rb` is
a best plase to define this method.
For keeping consistency with `DateTime#utc`, defines `#localtime` and
defines `getlocal` as an alias method.
In Ruby 2.4 the `to_time` method for both `DateTime` and `Time` will
preserve the timezone of the receiver when converting to an instance
of `Time`. Since Rails 5.0 will support Ruby 2.2, 2.3 and later we
need to introduce a compatibility layer so that apps that upgrade do
not break. New apps will have a config initializer file that defaults
to match the new Ruby 2.4 behavior going forward.
For information about the changes to Ruby see:
https://bugs.ruby-lang.org/issues/12189https://bugs.ruby-lang.org/issues/12271Fixes#24617.
When you come here without context, it is important to hightlight that
checking the predicate is worthwhile due to the observation that blank
strings are often empty. So you complicate the code (which has a cost
in terms of readability and aesthetics), but statistically makes sense.
Then, you also need to explain why the second operand is so convoluted.
Otherwise, you wonder why this line is written precisely this way. That
is what code comments are for.
This commit updates `delegate` to use the keyword argument syntax added in Ruby 2. I left the `ArgumentError` when `to` is missing, because it better explains how to correctly use `delegate`. We could instead rely on the default `ArgumentError` that would be raised if `to` were a required keyword argument.
Follow up on 697384df36 (commitcomment-17184696).
The regex to detect a blank string `/\A[[:space:]]*\z/` will loop through every character in the string to ensure that all of them are a `:space:` type. We can invert this logic and instead look for any non-`:space:` characters. When that happens, we would return on the first character found and the regex engine does not need to keep looking.
Thanks @nellshamrell for the regex talk at LSRC.
By defining a "blank" string as any string that does not have a non-whitespace character (yes, double negative) we can get a substantial speed bump.
Also an inline regex is (barely) faster than a regex in a constant, since it skips the constant lookup. A regex literal is frozen by default.
```ruby
require 'benchmark/ips'
def string_generate
str = " abcdefghijklmnopqrstuvwxyz\t".freeze
str[rand(0..(str.length - 1))] * rand(0..23)
end
strings = 100.times.map { string_generate }
ALL_WHITESPACE_STAR = /\A[[:space:]]*\z/
Benchmark.ips do |x|
x.report('current regex ') { strings.each {|str| str.empty? || ALL_WHITESPACE_STAR === str } }
x.report('+ instead of * ') { strings.each {|str| str.empty? || /\A[[:space:]]+\z/ === str } }
x.report('not a non-whitespace char') { strings.each {|str| str.empty? || !(/[[:^space:]]/ === str) } }
x.compare!
end
# Warming up --------------------------------------
# current regex
# 1.744k i/100ms
# not a non-whitespace char
# 2.264k i/100ms
# Calculating -------------------------------------
# current regex
# 18.078k (± 8.9%) i/s - 90.688k
# not a non-whitespace char
# 23.580k (± 7.1%) i/s - 117.728k
# Comparison:
# not a non-whitespace char: 23580.3 i/s
# current regex : 18078.2 i/s - 1.30x slower
```
This makes the method roughly 30% faster `(23.580 - 18.078)/18.078 * 100`.
cc/ @fxn
See the rationale in the comment in this patch.
To benchmark this I ran a number of variations, ultimately narrowing to
require 'benchmark/ips'
str = ''
regexp = /\A[[:space:]]*\z/
Benchmark.ips do |x|
x.report('regexp') { regexp === str }
x.report('empty') { str.empty? || regexp === str }
x.compare!
end
This benchmark has consistently reported speedups around 3.5x:
Calculating -------------------------------------
regexp 69.197k i/100ms
empty 115.468k i/100ms
-------------------------------------------------
regexp 2. 6.3%) i/s - 13.839M
empty 9. 8.8%) i/s - 47.804M
Comparison:
empty: 9642607.6 i/s
regexp: 2768351.9 i/s - 3.48x slower
Sometimes even reaching 4x.
Running the same bechmark on strings of 10 or 100 characters (with
whitespace or present) has shown a slowdown of just about 1.01/1.02.
Marginal, we seem to have a worthwhile trade-off here.
That helper will return time zones for any country that tzdata knows about.
So it will be much simpler for non-US people to list own country time zones
in HTML selects or anywhere.
Ruby 2.4 introduces `Array#sum`, but it only supports numeric elements,
breaking our `Enumerable#sum` which supports arbitrary `Object#+`.
To fix, override `Array#sum` with our compatible implementation.
Native Ruby 2.4:
%w[ a b ].sum
# => TypeError: String can't be coerced into Fixnum
With `Enumerable#sum` shim:
%w[ a b ].sum
# => 'ab'
We tried shimming the fast path and falling back to the compatible path
if it fails, but that ends up slower even in simple causes due to the cost
of exception handling. Our only choice is to override the native `Array#sum`
with our `Enumerable#sum`.
```ruby
ActiveSupport::Duration.parse('P3Y6M4DT12H30M5S')
(3.years + 3.days).iso8601
```
Inspired by Arnau Siches' [ISO8601 gem](https://github.com/arnau/ISO8601/)
and rewritten by Andrey Novikov with suggestions from Andrew White. Test
data from the ISO8601 gem redistributed under MIT license.
(Will be used to support the PostgreSQL interval data type.)
Before this commit
`NoMethodError: undefined method `form_name' for Time:Class` is raised
when an invalid argument is passed.
It is better to raise `ArgumentError` and show list of valid arguments
to developers.
Note that the fact that mtimes in the future are ignore was documented
just a few lines above. Since we know this has to be done, and the code
is quite clear due to variable naming, I think we can get rid of the
comment in the middle of the loop and shorten it even further.
- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.
Reverts 8fc97d198e .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.
Previously `String#to_time` returned the midnight of the current date
in some cases where there was no relavant information in the string.
Now the method returns `nil` instead in those cases.
Fixes#22958.
The native DateTime#<=> implementation can be used to compare instances
with numeric values being considered as astronomical julian day numbers
so we should call that instead of returning nil.
Fixes#24228.
