This probably should have been `#bar` on the instance of class `Undef2` all along
[Fix GH-2015]
From: Alex Snaps <alex.snaps@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65757 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
BDIGIT can be unsigned int or unsigned short, depending on BDIGIT_DBL.
Given that, unsigned int and unsigned short are different in how
integer promotion works. BOGLO assumes its argument is wider than
BDIGIT, which is not always true. We have to force that explicitly.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65753 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In ASCII, 'a' is bigger than 'A'. Which means 'A' - 'a' is a negative
number (-32, to be precise). In C, the type of 'a' and 'A' are signed
int (cf: ISO/IEC 9899:1990 section 6.1.3.4). So 'A' - 'a' is also a
signed int. It is `(signed int)-32`.
The problem is, OnigCodePoint is unsigned int. Adding a negative
number to a variable of OnigCodepoint (`code` here) introduces an
unintentional cast of `(unsigned)(signed)-32`, which is
4,294,967,264. Adding this value to code then overflows, and the
result eventually becomes normal codepoint.
The series of operations are not a serious problem but because
`code >= 'a'` holds, we can `(code - 'a') + 'A'` to reroute this.
See also: https://github.com/k-takata/Onigmo/pull/107
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65752 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
By definition, the logarithm of 0 is negative infinity. This is a
pole error (cf: cf: ISO/IEC 9899:1999 section 7.12.1 paragraph 3) and
of course, cannot fit into an `int` value. We have to resort to
INT_MIN.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65743 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
OK, nobody is actively willing to maintain this configuration. Just
stop annoying people by build failures. See:
https://travis-ci.org/ruby/ruby/jobs/455377387
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65742 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Now that ccache is enabled. Compilations are made IO heavy, not CPU
bound. This means parallel jobs beyond CPU count could gain more
speed. From my experiment, I can conclude the good old "number of
cores plus one" tactics works the best.
The experiment: https://travis-ci.org/shyouhei/ruby/builds/454891855
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65741 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
When a negative double is casted into an unsigned type, that operation
is undefined (cf: ISO/IEC 9899:1990 section 6.2.9.3). Recent versions
of C kindly footnotes that "The remaindering operation performed when
a value of integer type is converted to unsigned type need not be
performed when a value of real floating type is converted to unsigned
type" (cf: ISO/IEC 9899:1999 section 6.3.1.4 footnote 50).
So it is a wrong idea to just cast a double to st_data_t.
The intention of the code is commented as "mix the actual float value
in". It seems we should do a reinterpret_cast and rule out
static_cast.
Confirmed this changeset does not affect `make benchmark`.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65737 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In C, signed + unsigned of the same size results in unsigned (cf:
ISO/IEC 9899:1990 section 6.2.1.5). However `num` is signed here.
Which means the addition must be done in signed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65734 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Travis has `cache: ccache` feature so let us enable it. Also, because
`config.cache` is generated during the compilation why not cache that
file for a later use. [fix GH-2013]
Caveats:
- When something went wrong, cache entries can be deleted from
https://travis-ci.org/ruby/ruby/caches (requires login).
- See `ccache(1)` manual page for the new environment variables.
- `ccache` thinks two compilations are not identical if they produce
different diagnostics. The -fno-diagnostics-color option is to
prevent such cache missihts only because TTY is present / absent at
the compilation time.
- In this changeset two "ccache --show-stats" invocations are inserted
before and after the compilation to measure cache hit rates etc.
Will revisit their outputs once the cache is warmed up.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65731 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
There was incorrect backticks (`) instead of plus signs to denote method
references, and a typo.
[Fix GH-2016]
From: Olivier Lacan <hi@olivierlacan.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65729 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
select() is a crap API for even sleeping on sigwait_fd, so favor
the native_sleep-based functions when there are no FDs, instead.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65718 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
for now. This seems to get unstable after r65691.
test/excludes/_travis/osx: renamed from test/excludes/_travis because
it's only for osx builds.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65713 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
it seems to be more stable than the timing we upgraded travis image.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65711 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Sorry, seen the failures again. Was a wrong idea to delete
the --exclude.
See https://travis-ci.org/ruby/ruby/jobs/454329443#L2233
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65708 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
