| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
https://rubyci.s3.amazonaws.com/solaris10-sunc/ruby-master/log/20220428T000004Z.fail.html.gz
```
linking static-library libruby-static.a
/bin/sh: syntax error at line 8: `(' unexpected
gmake: *** [Makefile:318: libruby-static.a] Error 2
exit 2
failed(make)
```
|
|
|
|
|
|
|
|
| |
The shell in Solaris 10 has trouble understanding the syntax I used in
YJIT's library merging script.
This commit reduces the code the shell needs to parse before exiting on
non-YJIT builds to hopefully fix the error on Solaris.
|
| |
|
|
|
|
| |
https://github.com/ruby/net-http/commit/0017cc64c0
|
|
|
| |
Fix configure line in YJIT build instructions
|
| |
|
|
|
|
|
|
| |
Thanks to suggestion from bjorn3 on GitHub.
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
|
|
|
|
|
|
| |
Thanks to suggestions from Stranger6667 on GitHub.
Co-authored-by: Dmitry Dygalo <dmitry@dygalo.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In December 2021, we opened an [issue] to solicit feedback regarding the
porting of the YJIT codebase from C99 to Rust. There were some
reservations, but this project was given the go ahead by Ruby core
developers and Matz. Since then, we have successfully completed the port
of YJIT to Rust.
The new Rust version of YJIT has reached parity with the C version, in
that it passes all the CRuby tests, is able to run all of the YJIT
benchmarks, and performs similarly to the C version (because it works
the same way and largely generates the same machine code). We've even
incorporated some design improvements, such as a more fine-grained
constant invalidation mechanism which we expect will make a big
difference in Ruby on Rails applications.
Because we want to be careful, YJIT is guarded behind a configure
option:
```shell
./configure --enable-yjit # Build YJIT in release mode
./configure --enable-yjit=dev # Build YJIT in dev/debug mode
```
By default, YJIT does not get compiled and cargo/rustc is not required.
If YJIT is built in dev mode, then `cargo` is used to fetch development
dependencies, but when building in release, `cargo` is not required,
only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer.
The YJIT command-line options remain mostly unchanged, and more details
about the build process are documented in `doc/yjit/yjit.md`.
The CI tests have been updated and do not take any more resources than
before.
The development history of the Rust port is available at the following
commit for interested parties:
https://github.com/Shopify/ruby/commit/1fd9573d8b4b65219f1c2407f30a0a60e537f8be
Our hope is that Rust YJIT will be compiled and included as a part of
system packages and compiled binaries of the Ruby 3.2 release. We do not
anticipate any major problems as Rust is well supported on every
platform which YJIT supports, but to make sure that this process works
smoothly, we would like to reach out to those who take care of building
systems packages before the 3.2 release is shipped and resolve any
issues that may come up.
[issue]: https://bugs.ruby-lang.org/issues/18481
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
Co-authored-by: Noah Gibbs <the.codefolio.guy@gmail.com>
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
|
|
|
| |
Treats #Integer; fixes an error in #String.
|
|
|
|
| |
see https://github.blog/changelog/2022-04-25-git-io-deprecation/
|
|
|
|
|
|
|
|
|
|
|
| |
Treats:
#path
::stat
::lstat
#lstat
::directory?
Also adds section "Example Files" that explains assumptions about example files. I'm using t.txt already, and I'm pretty sure I'll need t.dat (binary data). I don't know whether I'll need t.rus (Russian text).
|
|
|
|
|
| |
This uses the RCLASS_SUPERCLASSES array to quickly find the next
SUPERCLASS of klass which is a T_CLASS.
|
| |
|
|
|
|
| |
Capitalize creates
|
|
|
|
|
|
|
|
| |
[Feature #18683]
This allows parsers and similar libraries to create Hashes of
a certain capacity in advance. It's useful when the key and values
are streamed, hence `bulk_insert()` can't be used.
|
|
|
|
|
|
|
| |
Treats:
#Array
#Hash
#String
|
| |
|
| |
|
|
|
| |
Previously, GCC 11 with -O2 LTO issues -Wmaybe-uninitialized here.
|
|
|
|
|
|
| |
Previously, since the `optflags` environment variable was set to `-O1`
and `optflags` comes after the flags appended as `CC`, we were doing LTO
builds with `-O1`.
|
|
|
|
|
|
| |
Rdoc [build] of `master` did not have this method but the reference manual [did].
[build]: https://docs.ruby-lang.org/en/master/RbConfig.html
[did]: https://docs.ruby-lang.org/ja/master/class/RbConfig.html#S_RUBY
|
| |
|
| |
|
|
|
|
|
|
| |
Revises intro.
Adds "What's Here".
Revises methods doc.
|
| |
|
| |
|
| |
|
|
|
|
| |
[Bug #18753]
|
|
|
|
| |
https://github.com/ruby/rdoc/commit/b42c4a2fe2
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Because `Dir.[]` returns the sorted results since Ruby 3.0.
|
|
|
|
|
|
|
|
|
| |
Should fix issues with parallel testing sometimes not running all
tests.
This should be viewed skipping whitespace changes.
Fixes [Bug #18731]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pointing `Gem.ruby` to the newly installed ruby gives mkmf the right
inputs to build extensions in bundled gems. Previously, this patching
was only done for compressed bundled gems.
This patch also prevents `tool/fake.rb` from propagating to the child
process running mkmf for the native extension. The way `tool/fake.rb`
changes mkmf variables using `Kernel#trace_var` created spooky action at
a distance which made debugging difficult.
AppVeyor Windows CI started to fail starting with
8a3663789c52ec5635194656af6b69d3d03120ee because it enabled extension
building for bundled gems on mswin. This patch should address the CI
failures.
|
|
|
|
|
|
|
|
|
| |
`rb_thread_t` contained `native_thread_data_t` to represent
thread implementation dependent data. This patch separates
them and rename it `rb_native_thread` and point it from
`rb_thraed_t`.
Now, 1 Ruby thread (`rb_thread_t`) has 1 native thread (`rb_native_thread`).
|
| |
|
|
|
|
|
|
| |
* `th_init` accepts vm and ractor.
* remove `ruby_thread_init` because it is duplicated with `th_init`.
* add some comments.
|
|
|
|
|
|
|
|
| |
Not sure if this is the correct fix. It does raise LocalJumpError in
the yielding thread as you would expect, but the value yielded to the calling
thread is still yielded without an exception.
Fixes [Bug #18649]
|
| |
|
|
|
|
|
|
|
| |
REGEXP is defined as RFC2396_REGEXP in lib/uri/common.rb. If we include
REGEXP then a broken URL is generated in rdoc for URI and URI::MailTo.
https://github.com/ruby/uri/commit/ed6ded9c80
|
|
|
|
|
|
|
|
| |
There was a file for WSS so I added one line of `require_relative`
to make it work.
Now `URI.parse('wss://example.com')` returns `URI::WS`.
https://github.com/ruby/uri/commit/ff8a103564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now GVL is not process *Global* so this patch try to use
another words.
* `rb_global_vm_lock_t` -> `struct rb_thread_sched`
* `gvl->owner` -> `sched->running`
* `gvl->waitq` -> `sched->readyq`
* `rb_gvl_init` -> `rb_thread_sched_init`
* `gvl_destroy` -> `rb_thread_sched_destroy`
* `gvl_acquire` -> `thread_sched_to_running` # waiting -> ready -> running
* `gvl_release` -> `thread_sched_to_waiting` # running -> waiting
* `gvl_yield` -> `thread_sched_yield`
* `GVL_UNLOCK_BEGIN` -> `THREAD_BLOCKING_BEGIN`
* `GVL_UNLOCK_END` -> `THREAD_BLOCKING_END`
* removed
* `rb_ractor_gvl`
* `rb_vm_gvl_destroy` (not used)
There are GVL functions such as `rb_thread_call_without_gvl()` yet
but I don't have good name to replace them. Maybe GVL stands for
"Greate Valuable Lock" or something like that.
|
|
|
|
| |
https://github.com/ruby/pathname/commit/268cb5acff
|
| |
|