... instead, just calculate the value unless it is too big.
Also, this change raises an ArgumentError if it is expected to exceed
16 GB in a 64-bit environment.
(It is possible to calculate it straightforward, but it would likely be
out-of-memory, so I didn't think it would make sense.)
[Feature #20811]
We did this because RubyGems `require` would call `gem` on self, so
defining a `gem` method in the CLI would cause conflicts. However, this
is not the case since
439c446489,
so this should no longer be necessary.
https://github.com/rubygems/rubygems/commit/3e5c861046
with -O0 build, prism parser consumes a lot of machine stack and
it doesn't work with minimum machine stack for threads, which
specified with `RUBY_THREAD_MACHINE_STACK_SIZE=1`.
So simply ignore `SystemStackError` for btest.
Many libraries should be loaded on the main ractor because of
setting constants with unshareable objects and so on.
This patch allows to call `requore` on non-main Ractors by
asking the main ractor to call `require` on it. The calling ractor
waits for the result of `require` from the main ractor.
If the `require` call failed with some reasons, an exception
objects will be deliverred from the main ractor to the calling ractor
if it is copy-able.
Same on `require_relative` and `require` by `autoload`.
Now `Ractor.new{pp obj}` works well (the first call of `pp` requires
`pp` library implicitly).
[Feature #20627]
* test_yamatanooroti: close tempfile before unlink
* test_yamatanooroti: omit because of windows does not support job control
* test_yamatanooroti: change startup message detection for windows
* windows.rb: can call win32api using nil as NULL for pointer argument
Exception occurred when interrupted with Ctrl+C on legacy conhost
* windows.rb: fix get_screen_size
return [window height, buffer width] insted of [buffer height, buffer width]
* windows.rb: import scroll_down() from ansi.rb
* windows.rb: add auto linewrap control if VT output not supported (legacy console)
* unfreeze WIN32API pointer arguments
They internally duplicate arguments so api functions write to another place.
This breaks the console mode detection with ruby-head.
* remove useless code from Win32API#call
argument repacking and return value tweaking is not needed for Reline::Windows requirements.
* Correctly handle top of console viewport
* Revert "remove useless code from Win32API#call"
This reverts commit https://github.com/ruby/reline/commit/060ba140ed43.
* Revert "windows.rb: can call win32api using nil as NULL for pointer argument"
This reverts commit https://github.com/ruby/reline/commit/93a23bc5d0c9.
https://github.com/ruby/reline/commit/47c1ffbabe
Benchmark.bm { |x|
x.item("aaaa") { 1 }
x.item("aaaaaaaa") { 0 }
}
After
user system total real
aaaa 0.000005 0.000002 0.000007 ( 0.000003)
aaaaaaaa 0.000001 0.000001 0.000002 ( 0.000002)
Before
user system total real
aaaa 0.000005 0.000001 0.000006 ( 0.000003)
aaaaaaaa 0.000002 0.000001 0.000003 ( 0.000003)
https://github.com/ruby/benchmark/commit/3e74533ead
Previously, it always used stderr. Slight shuffle of the first line
of the crash due to reusing code from rb_bug():
```diff
-Assertion Failed: /ruby/object.c:649:rb_obj_itself:false
+/ruby/object.c:649: Assertion Failed: rb_obj_itself:false
```
Tested locally to confirm that it writes to the file given with
RUBY_CRASH_REPORT. Follow-up for [Feature #19790].
After having a second look at this deprecation, the explanation that
we're giving does not make a lot of sense. When working only with local
gems, Bundler will indeed generate a different lockfile depending on
the latest installed version of each gem is at `bundle install` time.
That's the same situation that happens with remote sources: Bundler will
generate a different lockfile depending on the latest version of each
gem available remotely.
So, I don't think "a consistent lockfile not getting generated" is a
good motivation for deprecating this.
Also, this deprecation brings additional challenges, since for example,
it should arguably not get printed when using `bundle install --local`?
The original problem when this deprecation was introduced was an
incorrect message about a missing gem having been yanked.
So, I think a better solution is to, as long as we give proper error
messages when things go wrong, let users do what's best for them and
undo the deprecation.
https://github.com/rubygems/rubygems/commit/17499cb83f
David Rodríguez
Yusuke Endoh
Koichi Sasada
git
Hiroshi SHIBATA
Daisuke Fujimura (fd0)
Mari Imaizumi
YO4
Kaíque Kandy Koga
Alan Wu
Kouhei Yanagita
Benoit Daloze
Nobuyoshi Nakada