As pointed out in the
[comment](https://github.com/ruby/reline/pull/413#issuecomment-1168033973),
the code is actually a control sequence and not only for colors.
To make the dialog color APIs safer to use, we should restrict its
usages and extract away the bg/fg concept from the input.
So in this commit, I made these changes:
1. The dialog_*_bg/fg_color APIs only takes and returns color names (symbol):
- :black
- :red
- :green
- :yellow
- :blue
- :magenta
- :cyan
- :white
2. Add additional dialog_*_bg/fg_color_sequence APIs to access the raw code.
https://github.com/ruby/reline/commit/b32a977766
Prior to this change, we were measuring object allocation as well
as setting instance variables within ivar benchmarks. With this
change, we now only measure setting instance variables within
ivar benchmarks.
This commit implements Objects on Variable Width Allocation. This allows
Objects with more ivars to be embedded (i.e. contents directly follow the
object header) which improves performance through better cache locality.
example.org is used mirror URL as an example, not to make access to
a (potential) third-party domain.
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
https://github.com/rubygems/rubygems/commit/31230f850c
When configuring with `--disable-rpath` and `--static-linked-ext` (e.g.
building for WASI), `extmk.rb` doesn't build exts under bundled gems,
and `.bundle/gems/#{gemname}-#{ver}` are not created due to no call of
`extmake`.
b2491783986084770f6f97552f27b868622730cf starts creating symlink at
`.bundle/gems/#{gemname}-#{ver}/lib`, but the parent dir is not created,
so configuration aginst debug and rbs gems were failed.
Since #6006, we no longer avoid executing GC on mjit_worker.c and thus
there's no need to carefully change how we write code whether you're in
mjit.c or mjit_worker.c anymore.
When retrying in ruby's test, it seems possible that `Gem` is not
loaded.
```
1) Error:
TC_Set_Builtin#test_to_set:
NameError: uninitialized constant TC_Set_Builtin::Gem
/export/home/chkbuild/chkbuild-gcc/tmp/build/20220708T070011Z/ruby/test/test_set.rb:844:in `should_omit?'
/export/home/chkbuild/chkbuild-gcc/tmp/build/20220708T070011Z/ruby/test/test_set.rb:869:in `test_to_set'
2) Error:
TC_Set_Builtin#test_Set:
NameError: uninitialized constant TC_Set_Builtin::Gem
/export/home/chkbuild/chkbuild-gcc/tmp/build/20220708T070011Z/ruby/test/test_set.rb:844:in `should_omit?'
/export/home/chkbuild/chkbuild-gcc/tmp/build/20220708T070011Z/ruby/test/test_set.rb:849:in
`test_Set'
```
This is by `Gem::Version` only, just compare as array of integers
instead.
https://github.com/ruby/set/commit/cde0a4bbc7
Previously if `~/.bundle/cache/compact_index/rubygems.org.*/version`
were owned by root with read-only access, `bundle install` would fail
with a misleading error message. For example:
```
There was an error while trying to write to `/tmp/bundler-compact-index-20220711-1823-npllre/versions`. It is
likely that you need to grant write permissions for that path.
```
This happened because the EACCESS error was caught by
`SharedHelpers.filesystem_access`, which makes it look like the target
directory is at fault instead of the source.
We can't simply drop this guard because that causes the opposite
problem: the permission error appears to come from the source instead of
the target, since `CompactIndexClient::Cache#lines` also wraps read
access errors.
Instead, bring a minimal implementation of `FileUtils.cp` and nest calls
to `SharedHelpers.filesystem_access` properly.
https://github.com/rubygems/rubygems/commit/320822c070
Co-authored-by: Stan Hu <stanhu@gmail.com>
The default gems have not been installed yet in the build directory,
bundled gems depending on them can not work. As those dependencies
should be usable there even without rubygems, make temporary gemspec
files without the dependencies, and use them in the build directory.
Since extension libraries can not be built in the source directory,
rubygems warns gems have extension libraries as the extensions are not
built. To order to suppress this warnings, extract such gemspec files
under each gem directories instead of the common `specifications`
directory.
Since a few commits ago, we no longer call `Gem::Specification.reset`
after each invocation of `Gem::Installer#install`. This means we don't
call it when the default Bundler is installed during `gem update
--system`. This causes no issues until the end of the upgrade process
when:
* The previous default Bundler spec is removed from disk.
* All specification stubs are turned into real specifications by loading
them from disk. But the one for Bundler no longer exists so
materializes to `nil` and regenerating binstubs crashes like this:
```
Bundler 2.4.0.dev installed
RubyGems 3.4.0.dev installed
Regenerating binstubs
ERROR: While executing gem ... (NoMethodError)
undefined method `platform' for nil:NilClass
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `block in execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:981:in `block in each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:980:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/specification.rb:980:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `map'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `each'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `select'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/pristine_command.rb:116:in `execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:323:in `invoke_with_build_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:301:in `invoke'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/setup_command.rb:604:in `regenerate_binstubs'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/commands/setup_command.rb:183:in `execute'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command.rb:323:in `invoke_with_build_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:185:in `process_args'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/command_manager.rb:149:in `run'
/Users/deivid/Code/rubygems/rubygems/lib/rubygems/gem_runner.rb:51:in `run'
setup.rb:33:in `<main>'
```
We fix it by more carefully managing the removal of the previous default
Bundler gem.
https://github.com/rubygems/rubygems/commit/9989f6d5af
We saw the following failure:
```
TestThreadInstrumentation#test_thread_instrumentation [/tmp/ruby/v3/src/trunk-random3/test/-ext-/thread/test_instrumentation_api.rb:25]:
Expected 0..3 to include 4.
```
Which shouldn't happen unless somehow there was a leaked thread.
An error message is primarily rendered in a terminal emulator, but is
also shown in a browser by converting it to a HTML fragment.
However, the conversion would be unreasonably difficult if the message
includes any escape sequence (such as cursor move or screen clear).
This change adds a guideline about escape sequences in
`Exception#detailed_message`:
* Use widely-supported escape sequences: bold, underline, and basic
eight foreground colors (except white and black).
* Make the message readable if all escape sequences are ignored.
Splits certain guidelines for singleton and instance method.
Calls for instance method to not prefix anything (like RDoc itself for a Ruby-coded instance method); e.g.:
count -> integer, not array.count,.
<=> other -> integer or nil, not hash <=> other -> integer or nil.
Groups previous guidelines into Arguments, Block, Return types, Aliases.
`rb_thread_wait_for_single_fd` needs to mutate the `waiting_fds` list
that is stored on the VM. We need to delete the FD from the list before
returning, and deleting from the list requires a VM lock (because the
list is a global).
[Bug #18816] [ruby-core:108771]
Co-Authored-By: Alan Wu <alanwu@ruby-lang.org>
In a small script the speed of this feature isn't really noticeable but
on Rails it's very noticeable how slow this can be. This PR aims to
speed up two parts of the functionality.
1) The Rust exit recording code
Instead of adding all samples as we see them to the yjit_raw_samples and
yjit_line_samples, we can increment the counter on the ones we've seen
before. This will be faster on traces where we are hitting the same
stack often. In a crude measurement of booting just the active record
base test (`test/cases/base_test.rb`) we found that this improved the
speed by 1 second.
This also results in a smaller marshal dump file which sped up the test
boot time by 4 seconds with trace exits on.
2) The Ruby parsing code
Previously we were allocating new arrays using `shift` and
`each_with_index`. This change avoids allocating new arrays by using an
index. This change saves us the most amount of time, gaining 11 seconds.
Before this change the test boot time took 62 seconds, after it took 47
seconds. This is still too long but it's a step closer to faster
functionality. Next we're going to tackle allowing you to collect trace
exits for a specific instruction. There is also some potential slowness
in the GC code that I'd like to take a second look at.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
