| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Minitest expects the first argument in `ARGV` to be the path to a test file.
Because `rails benchmarker` and `rails profiler` define an on-the-fly test-case,
using the first `ARGV` to pass the code to execute this results in:
```
/Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:167:in `block in non_options': file not found: 1000.times{"a string"} (ArgumentError)
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:146:in `map!'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:146:in `non_options'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:207:in `non_options'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:52:in `process_args'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/minitest/unit.rb:891:in `_run'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/minitest/unit.rb:884:in `run'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:21:in `run'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:326:in `block (2 levels) in autorun'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:27:in `run_once'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:325:in `block in autorun'
```
clearing ARGV after defining the test-case solves this issue.
|
| |
|
| |
|
|
|
|
| |
for Rubinius and JRuby and high configurability)
|
|
|
|
|
|
| |
After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.
It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
|
|
|
|
| |
suggestion!
|
|
|
|
| |
There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
|
|
initializing the application on its own. This fixes [#4492 state:resolved] and also avoids the application being initialized twice in some rake tasks.
|