ruby/debug uses `irb/color` selectively:
0ac22406bb/lib/debug/color.rb (L4)
And in that case, `IRB.conf` won't be defined. So Color.colorable? needs
to consider that.
This also fixes the Ruby trunk CI.
b2cd07e795
* Use colorable: argument as the only coloring control
* Centalize color controling logic at Color.colorable?
There are 2 requirements for coloring output:
1. It's supported on the platform
2. The user wants it: `IRB.conf[:USE_COLORIZE] == true`
Right now we check 1 and 2 separately whenever we colorize things.
But it's error-prone because while 1 is the default of `colorable`
parameter, 2 always need to manually checked. When 2 is overlooked, it
causes issues like https://github.com/ruby/irb/pull/362
And there's 0 case where we may want to colorize even when the user
disables it. So I think we should merge 2 into `Color.colorable?` so it
can be automatically picked up.
* Add tests for all inspect modes
* Simplify inspectors' coloring logic
* Replace use_colorize? with Color.colorable?
* Remove Context#use_colorize cause it's redundant
1c53023ac4
When running a command with the `--verbose` flag that ends up raising a
`BundlerError`, Bundler will unnecessarily print the error twice.
This commit fixes the issue by removing the duplicate logging.
689004a164
When outputting a (possibly truncated) value, IRB will query the
window size. However, if IRB was piped to another process, stdout
will no longer be a TTY and will not support the `winsize` method.
This fix ensure that stdout is a TTY.
125de5eeea
While generate_index did clean up temporary directory, when running with
--update flag, that did not happen and the temporary directory was left
behind.
This commit fixes that and modifies tests in order to make sure this is
not reintroduced later on.
Fixes#5635.
9fa34dc329
This is a regression from cf749f8ffa. The
funny thing is that we have a spec for this feature, so it was unclear
how we regressed here. It turns out there was a bug in one of our
negative matchers checking that gems ARE NOT included in a bundle.
This commit fixes the bug in the negative matcher and reverts
cf749f8ffa (with a slightly simpler diff).
3f9a4ff32a
The paths for extensions of gems would contain the hardcoded ruby
version on which the extension was built. This will replace it with
runtime ruby version like the parent version directory. It will make the
standalone script compatible between different ruby version installations.
a9dae93d5d
I was looking at (yet another) flamegraph in speedscope, and used the
'left hand heavy' and was shocked to realize that 0.5s of the 1.7s
is spent in DepProxy#name. This method _only_ delegates the name to an
underlying spec, so it's not complex at all.
It seems to be of how often this line ends up calling it:
next if handled.any?{|d| d.name == dep.name && (match_current_platform || d.__platform == dep.__platform) } || dep.name == "bundler"
The `handled` array is built up as dependencies are handled, so this get
slower as more dependencies are installed.
This change changes how `handled` is track. Instead of just an array, I've
tried using a Hash, with the key being a dep's name, and the value being
a list of deps with that name. This means it's constant time to find
the dependencies with the same name.
I saw a drop from 1.7s to 1.0s against master, and from 0.95s to 0.24s
when used with https://github.com/rubygems/rubygems/pull/5533844dac30d4
Instead, pass sitearchdir and sitelibdir directly to `make`.
This also removes the need to create and use the siteconf file at all
when generating makefiles.
dea41fa2dc
* Returning nil from the `content_range` method instead of raising an
error when the unit in the content-range header is not "bytes".
Fix https://bugs.ruby-lang.org/issues/114500b5030dd86
Co-Authored-By: Nobuyoshi Nakada <nobu@ruby-lang.org>
* Added a nil check in Net::HTTPHeader#initialize_http_header for keys in the header that do not have any value
* Returning nil from the content_range method instead of raising an error when the unit in the content-range header is not bytes
* Modified initialize_http_header to match trunk
fix [Bug #11450]
fix https://github.com/ruby/ruby/pull/1018
It sent the char to check even to non-tty, e.g., pipe.
This causes `unknown command: "\xE2\x96\xBDstart ` warnings on
ruby's parallel test on Windows, where non-standard FDs cannot be
passed to child processes.
0d373647fb
These gemspecs already work most of the times. When they are installed
normally, the require_paths in the gemspec stub line becomes actually
correct, and the incorrect value in the real gemspec is ignored. It only
becomes an issue in standalone mode.
In Ruby 3.2, `Kernel#=~` has been removed, and that means that it
becomes harder for us to gracefully deal with this error in standalone
mode, because it now happens earlier due to calling `Array#=~` for this
invalid gemspec (since require_paths is incorrectly an array of arrays).
The easiest way to fix this is to actually make this just work instead
by automatically fixing the issue when reading the packaged gemspec.
d3f2fe6d26
Previously we would instantiate two different packages and extract the
specification from the package twice for each gem installed. We can
reuse the installer for this so that we just need to do it once.
e454f850b1
