On osx build https://travis-ci.org/ruby/ruby/jobs/454309945,
```
1) Failure:
Fiddle::TestFunction#test_nogvl_poll [/Users/travis/build/ruby/ruby/test/fiddle/test_function.rb:95]:
slept amount of time.
Expected |200 - 322| (122) to be <= 100.
```
but it succeeds on my macOS machine as is. So it seems that the boundary is
just too strict and prone to random failure by overload.
To make osx Travis build usable, let me loosen the delta requirement.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65705 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
To reduce the amount of output, prefer --tty=no instead of
--color=never. This option not only disables color output but also
kill some tty-related features, like spinners. Travis limits its
output by the physical size of the log, not by the number of lines.
This change should make more room for new logs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65702 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
While we are experiencing build failures, no hangs had been
seen for a while. Also it seems the excluded tests now pass.
I think it's time to delete this line.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65700 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/date/date_core.c (date_initialize): separate from
date_s_civil and obey the allocation framework.
* ext/date/date_core.c (datetime_initialize): ditto.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65699 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/date/date_core.c (d_lite_marshal_load): respect COMPLEX_DAT
bit in the pre-allocated structure.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65698 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/date/date_core.c (d_lite_initialize_copy): do not change
COMPLEX_DAT bit, as the structure does not change. initialize
member-wise instead.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65697 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ext/date/date_core.c (set_to_simple, set_to_complex): always
set/reset COMPLEX_DAT bit, which is very tightly bound to the
structure.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65696 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Since `.revision.time` recipe needs `$(BASERUBY)`, it should not
try to get updated unconditionally, or tarballs fail to build on
environments where BASERUBY is not available.
All developers who build frequently use GNU make anyway, don't
you?
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65695 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Tests are failing due to network timeouts. Temporary allow failrues for them.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65694 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
by making .revision.time PHONY. Prior to this commit, RUBY_DESCRIPTION
has been updated only when version.h (or tool/file2lastrev.rb) is updated.
.revision.time (REVISION_H) target internally has IFCHANGE to update
revision.h. So it doesn't touch revision.h when it's not updated,
and thus it's safe to run every time.
defs/gmake.mk: drop obsoleted reference to REVISION_FORCE
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65692 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
xeinal for Linux and xcode 10.1 for osx. Also deleted few outdated
lines that are no longer necessary.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65691 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The "osx build randomly fails with `-j`" happens on make -j test-all.
Should be safe to do make -j all.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65686 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
space_size can be zero here, under the following script. We would
better bail out before bptr calculation.
% ./miniruby --dump=i -e '* = nil'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,7)> (catch: FALSE)
0000 putnil ( 1)[Li]
0001 dup
0002 expandarray 0, 0
0005 leave
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65685 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
read_escaped_byte() returns values of range -1...256. -1 indicates
error. So the function basically expects char to be 0..255 range.
There is no such guarantee. `char` is not always unsigned. We
need to explicitly declare chbuf to be unsigned char.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65677 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The unary ~ operator excercises integer promotion of the operand
_before_ actually applying bitwise complement (cf: ISO/IEC 9899:1990
section 6.3.3.3). Which means `~buf[i]` is in fact
`(int)~(int)buf[i]`.
The problem is, when buf[i] is 0xFF:
buf[i] 0xFF
(int)buf[i] 0x0000_00FF
~(int)buf[i] 0xFFFF_FF00 This is -256, out of unsigned char range.
The proposed fix is to change the char signed. By doing so,
buf[i] 0xFF
(signed char)buf[i] 0xFF
(int)(signed char)buf[i] 0xFFFF_FFFF
~(int)(signed char)buf[i] 0x0000_0000 This is 0, does not overflow.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65675 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For some reason this very useful method was undocumented since it was added in
493e488974 which makes finding it in the docs
impossible before this change.
I've added a detailed example with sample code because it's one of the most
powerful tools to debug Ruby code and I believe very few people are aware of it
due to the lack of documentation.
[Fix GH-2010]
From: Olivier Lacan <hi@olivierlacan.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65674 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
shyouhei
marcandre
k0kubun
nobu
svn
kazu
hsbt
yui-knk
mame