Age | Commit message (Collapse) | Author |
|
This must be definitely removed after we collect the stack traces :-)
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/2245710
|
|
Git is not for direct access to a remote repository.
Most of its operations need a local clone.
|
|
|
|
|
|
It does not seem to have a significant performance impact, hopefully?
```
$ benchmark-driver -v benchmark.yml --rbenv 'before --jit;after --jit' --repeat-count=24 --output=all
before --jit: ruby 2.7.0dev (2019-09-03T21:02:24Z master 77596fb7a9) +JIT [x86_64-linux]
after --jit: ruby 2.7.0dev (2019-09-04T01:54:44Z master 7363e22d79) +JIT [x86_64-linux]
Calculating -------------------------------------
before --jit after --jit
Optcarrot Lan_Master.nes 48.44054595799523 71.67010255902900 fps
71.32797692837639 71.97846863769546
72.51921961607691 78.87360980544105
73.54082925611047 79.80408132389941
74.03503843709451 79.85739528572826
74.04863857926493 79.89850834901381
75.30266276129467 80.34607233076015
75.69063990896244 80.88474397425360
75.70458132587405 81.09234267781642
77.39842764662852 82.13766823612643
77.76922944068329 82.20398304840373
81.17984044023393 82.26722630628272
82.85235776076533 82.71375902781254
83.04906099135320 82.75893420702198
83.10214168136230 82.79668965325972
83.71456007558125 82.85131667916379
84.06658306760725 82.95676565411722
84.25690684305728 83.19972846225775
84.27938663923503 83.28510503845854
84.45467716218090 83.41003730434703
84.51563186125925 83.67773614721280
84.56139892968321 84.02082201151110
84.69819452180658 84.10495346787033
84.78125989622576 84.47867803506055
```
Note for backporter:
test_jit's `success_count` would be 1 in Ruby 2.6, since 2.7 introduced
"MJIT recompile" on JIT-ed code cancel.
[Bug #16139]
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/2420
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
instead of waiting 2 seconds, if possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e.g. `GZIP=-9`
|
|
|
|
This reverts commit 6454808c52fff445ff09fefb0fb96988f82aaa3c.
It is no longer needed, as `VCS::SVN#get_revisions` now returns
`Integer` as revision numbers, and `short_revision` should deal
with it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Since the previous release date, when the starting message is not
found.
|
|
|
|
|
|
|
|
|
|
|
|
https://rubyci.org/logs/rubyci.s3.amazonaws.com/gentoo/ruby-master/log/20190824T153002Z.fail.html.gz
```
/home/gentoo/chkbuild/tmp/build/20190824T153002Z/ruby/tool/lib/vcs.rb:577:in `export_changelog': cannot find the beginning revision of the branch (RuntimeError)
from ./tool/make-snapshot:353:in `block in package'
from ./tool/make-snapshot:351:in `chdir'
from ./tool/make-snapshot:351:in `package'
from ./tool/make-snapshot:523:in `block in <main>'
from ./tool/make-snapshot:523:in `collect'
from ./tool/make-snapshot:523:in `<main>'
```
|
|
https://rubyci.org/logs/rubyci.s3.amazonaws.com/debian8/ruby-master/log/20190824T093005Z.fail.html.gz
```
branches:
* trunk
remotes/origin/trunk
```
and
```
fatal: Remote branch master not found in upstream origin
```
|
|
matser branch not found on some CIs
https://rubyci.org/logs/rubyci.s3.amazonaws.com/debian9/ruby-master/log/20190824T063005Z.fail.html.gz
```
fatal: Remote branch master not found in upstream origin
```
|
|
https://rubyci.org/logs/rubyci.s3.amazonaws.com/debian9/ruby-master/log/20190823T213004Z.fail.html.gz
https://rubyci.org/logs/rubyci.s3.amazonaws.com/debian8/ruby-master/log/20190824T003006Z.fail.html.gz
|
|
Even if they don't ship with any executables. This makes rbinstall
behaviour consistent with rubygems `gem install --default` command.
Notes:
Merged: https://github.com/ruby/ruby/pull/2085
|
|
|
|
|
|
* These seem to consistenly pass already
* Show actual command when running `make test-bundler`
Current the setup command that installs the necessary gems for testing
bundler was printed, but not the actual command that runs the tests.
That was a bit confusing.
* Borrow trick from setproctitle specs
* A title that long doesn't get set sometimes
No idea why, but the test doesn't need that the title is that long.
* Fix most gem helper spec ruby-core failures
* Fix the rest of the gem helper failures
* Fix version spec by improving the assertion
* Remove unnecessary `BUNDLE_RUBY` environment var
We can use `RUBY` when necessary, and `BUNDLE_RUBY` is not a good name
because bundler considers `BUNDLE_*` variables as settings.
* Rename `BUNDLE_GEM` to `GEM_COMMAND`
This is more descriptive I think, and also friendlier for bundler
because `BUNDLE_` env variables are interpreted by bundler as settings,
and this is not a bundler setting.
This fixes one bundler spec failure in config specs against ruby-core.
* Fix quality spec when run in core
Use the proper path helper.
* Fix dummy lib builder to never load default gems
If a dummy library is named as a default gem, when requiring the library
from its executable, the default gem would be loaded when running from
core, because in core all default gems share path with bundler, and thus
they are always in the $LOAD_PATH. We fix the issue by loading lib
relatively inside dummy lib executables.
* More exact assertions
Sometimes I have the problem that I do some "print debugging" inside
specs, and suddently the spec passes. This happens when the assertion is
too relaxed, and the things I print make it match, specially when they
are simple strings like "1.0" than can be easily be part of gem paths
that I print for debugging.
I fix this by making a more exact assertion.
* Detect the correct shebang when ENV["RUBY"] is set
* Relax assertion
So that the spec passes even if another paths containing "ext" are in
the load path. This works to fix a ruby-core issue, but it's a better
assertion in general. We just want to know that the extension path was
added.
* Use folder structure independent path helper
It should fix this spec for ruby-core.
* Fix the last failing spec on ruby-core
* Skip `bundle open <default_gem>` spec when no default gems
|