| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Add rb_keyword_given_p to the C-API
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, passing to_enum/enum_for a method that was defined in
Lazy itself returned wrong results:
[1,2,3].to_enum(:map).to_a
# => [1, 2, 3]
[1,2,3].lazy.to_enum(:map).to_a
# => []
I'm not sure why methods that are designed to be lazy do not work
with to_enum/enum_for. However, one possible way to work around
this bug is to have to_enum/enum_for use the implementation found
in Enumerable/Enumerator, which is what this commit does.
While this commit works around the problem, it is a band-aid, not a
real fix. It doesn't handle aliases of Enumerable::Lazy methods,
for instance. A better fix would be appreciated.
|
|
|
|
|
| |
This spec should not be checking where methods are defined, only
that the method works as expected (returns a Lazy instance).
|
|
|
|
|
|
|
|
|
|
| |
Previously, Enumerator::Lazy#with_index was not defined, so it
picked up the default implementation from Enumerator, which was
not lazy.
Based on earlier patch from nobu.
Fixes [Bug #7877]
|
|
|
|
|
|
|
|
| |
This has been unstable on AppVeyor mswin since the introduction
3fd83cb6fcc483d2eac0795bc139c521a3a59bd2.
https://ci.appveyor.com/project/ruby/ruby/builds/27103307/job/j7xwjmsos2k22cck
Let's have it in pending.rb to be fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
for simplicity and consistency.
Now SUPPORT_JOKE needs to be prefixed with OPT_ to make the config
visible in `RubyVM::VmOptsH`, and the inconsistency was introduced.
As it has never been available for override in configure (no #ifndef
guard), it should be fine to rename the config.
|
|
|
|
|
| |
to deal with random failures:
https://github.com/ruby/ruby/runs/210617845
|
|
|
|
|
| |
hoping to stabilize:
https://app.wercker.com/ruby/ruby/runs/mjit-test1/5d6df8a8a952c20008acf75b?step=5d6df90e4971a6000714c627
|
| |
|
|
|
|
|
|
|
| |
On Solaris, it seems that the select(3C) in this test works only
when sending 1 byte out-of-band data, though I cannot investigate
the cause. The behavior is observed on a Solaris 10 server in
addition to Solaris 11 on which the test had been skipped.
|
|
|
|
| |
Not used from anywhere.
|
| |
|
|
|
|
| |
[Bug #16134]
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test consistently fails on OpenBSD.
https://rubyci.org/logs/rubyci.s3.amazonaws.com/openbsd-current/ruby-master/log/20190903T010009Z.fail.html.gz
```
1) Failure:
TestFiber#test_fork_from_fiber [/home/chkbuild/chkbuild/tmp/build/20190903T010009Z/ruby/test/ruby/test_fiber.rb:327]:
[ruby-core:41456].
<0> expected but was
<1>.
```
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Previously, Array#uniq would return subclass instance if the
length of the array were 2 or greater, and would return Array
instance if the length of the array were 0 or 1.
Fixes [Bug #7768]
|
|
|
|
| |
consistent with the definition
|
| |
|
| |
|
| |
|
|
|
|
| |
In 91aa8bfff8, my understanding of the branch was inverted.
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, the Travis osx environment has been really unstable.
It failed on today's cron too:
https://travis-ci.org/ruby/ruby/builds/579843163
As we have almost the same test environment (including OpenSSL version)
in GitHub Actions and it seems to be more stable and faster, I think
there's no motivation to maintain Travis osx CI environment.
By removing this, we'd be able to simplify .travis.yml as well.
|
|
|
|
|
| |
travis-ci user does not live in #ruby-ja. Therefore the notification
isn't working anymore.
|
|
|
|
| |
We don't have topic branches on ruby.git anymore.
|
| |
|
|
|
| |
Ignore empty keyword splats in arrays
|
| |
|
|
|
|
| |
It looks like a flag which cannot be enabled on configure.
|
| |
|
|
|
|
| |
This seems to have been broken since 4e15be8bade.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The test seems to have a race condition, which fails on very slow
machine like Solaris10s. So skip it.
In addition, this change restores timeout guard that was removed at
0660d7cb538cf5284d50f66adfcbd78609839715. This is because the test gets
stuck forever when something wrong occurs. It is better to fail the
test than stuck.
|
|
|
|
| |
[Bug #15558]
|
| |
|
| |
|
|
|
|
|
| |
Patch by darkphnx (Dan Wentworth) . Thanks!
[Feature #15964]
|
| |
|
|
|
|
|
|
| |
This reverts commit 83498854eb5a824f1f83c31fac18c9279f9ee10d.
This didn't pass rubyspec.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, Enumerator::Lazy#with_index was not defined, so it
picked up the default implementation from Enumerator, which was
not lazy.
Based on earlier patch from nobu.
Fixes [Bug #7877]
|
|
|
|
|
| |
rb_reg_match expects its first argument to be a Regexp instance.
Should check that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----
trunk: ruby 2.6.0dev (2018-09-18 trunk 64767) [x86_64-darwin15]
ours: ruby 2.6.0dev (2018-09-18 opt_regexpmatch 64775) [x86_64-darwin15]
last_commit=opt_regexpmatch1 is actually making things slower.
Calculating -------------------------------------
trunk ours
Optcarrot Lan_Master.nes 33.877 35.282 fps
Comparison:
Optcarrot Lan_Master.nes
ours: 35.3 fps
trunk: 33.9 fps - 1.04x slower
|
|
|
|
| |
vm2_regexp was for opt_regexpmatch1.
|