| Age | Commit message (Collapse) | Author |
|
https://github.com/ruby/prism/commit/073e8ba307
|
|
|
|
https://github.com/ruby/prism/commit/86cf82794a
|
|
https://github.com/ruby/prism/commit/bf16ade7f9
|
|
https://github.com/ruby/prism/commit/08a71f6259
|
|
https://github.com/ruby/prism/commit/9f12a56fd6
|
|
https://github.com/ruby/prism/commit/4cc0eda4ca
|
|
https://github.com/ruby/prism/commit/fb7e1ebb7f
|
|
This allows the user to specify exception classes to treat as regular
exceptions instead of being swallowed. Among other things, it is
useful for having Logger work with Timeout.
Fixes Ruby Bug 9115.
https://github.com/ruby/logger/commit/436a7d680f
|
|
https://github.com/ruby/open-uri/commit/4a247e5ca1
|
|
https://github.com/ruby/open-uri/commit/5d29e626bc
|
|
https://github.com/rubygems/rubygems/commit/356726bd1a
|
|
https://bugs.ruby-lang.org/issues/16482
https://github.com/ruby/net-http/commit/ae2d83f88b
|
|
https://github.com/ruby/net-http/commit/fed3dcd0c2
|
|
https://github.com/ruby/net-http/commit/7191bb923b
|
|
frozen mode
If there's a lockfile, but it's out of sync with the Gemfile because a
dependency has been deleted, and frozen mode is set, Bundler will print
the following strange error:
```
$ bundle add rake
, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile:
* rake (~> 13.2)
Run `bundle install` elsewhere and add the updated Gemfile to version control.
```
This commit changes the error to:
```
Some dependencies were deleted from your gemfile, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile:
* rake (~> 13.2)
Run `bundle install` elsewhere and add the updated Gemfile to version control.
```
https://github.com/rubygems/rubygems/commit/452da4048d
|
|
mode set
If Gemfile is empty and there's no lockfile (situation after `bundle init`), and
`frozen` is configured, running `bundle add` will result in an strange
error, like this:
```
$ bundle add rake
, but the lockfile can't be updated because frozen mode is set
You have deleted from the Gemfile:
* rake (~> 13.2)
Run `bundle install` elsewhere and add the updated Gemfile to version control.
```
This commit fixes the problem to instead print
https://github.com/rubygems/rubygems/commit/152331a9dc
|
|
when locked for a specific platform
If they are already in the lockfile as the most specific variant for a
platform, we shouldn't change that unless explicitly unlocking.
https://github.com/rubygems/rubygems/commit/a901660498
|
|
https://github.com/rubygems/rubygems/commit/bcbbff5149
|
|
Instead of having to do a complete pass after resolve.
To do this, we add to the ruby group all the platform specs with the
same dependencies as the ruby specs.
https://github.com/rubygems/rubygems/commit/e50415f2a6
|
|
It's just for debugging and a simple method, so no need.
https://github.com/rubygems/rubygems/commit/3230425a9a
|
|
https://github.com/rubygems/rubygems/commit/e2c1bc1b6c
|
|
It results in more consistent error messages.
https://github.com/rubygems/rubygems/commit/a4b34361cc
|
|
This RubyGems feature is being released as 3.5.15, so we can stop
monkeypatching RubyGems once support for the previous version is
dropped.
https://github.com/rubygems/rubygems/commit/36f146840d
|
|
https://github.com/rubygems/rubygems/commit/b07e46820d
|
|
We also need to protect prior removal of the binstub, otherwise it can
happen that:
* Process A removes prior binstub FOO.
* Process B removes prior binstub FOO (does nothing actually because Process A already removed it).
* Process A writes binstub FOO for gem BAR from the beginning of file.
* Process B writes binstub FOO for gem BAZ from the beginning of file.
Similarly as before, if binstub FOO for gem BAR is bigger that binstub
FOO for gem BAZ, garbage bytes will be left around at the end of the
file, corrupting the binstub.
The solution is to also protect removal of the previous binstub. To do
this, we use a file lock on an explicit `.lock` file.
https://github.com/rubygems/rubygems/commit/d99a80e62d
|
|
There's an issue when multiple processes try to write the same binstub.
The problem is that our file locking mechanism is incorrect because
files are truncated _before_ they are locked. So it can happen that:
* Process A truncates binstub FOO.
* Process B truncates binstub FOO.
* Process A writes binstub FOO for gem BAR from the beginning of file.
* Process B writes binstub FOO for gem BAZ from the beginning of file.
If binstub FOO for gem BAR is bigger than binstub FOO for gem BAZ, then
some bytes will be left around at the end of the binstub, making it
corrupt.
This was not a problem in our specs until the spec testing binstubs with
the same name coming from different gems changed from using gems named
"fake" and "rack" to using gems named "fake" and "myrack". Because of
the difference in gem name length, the generated binstub for gem
"myrack" is now longer, causing the above problem if binstub for gem
myrack is written first.
The solution is to make sure when using flock to always use modes that
DON'T truncate the file when opening it. So, we use `r+` if the file
exists previously (it requires the file to exist previously), otherwise
we use `a+`.
https://github.com/rubygems/rubygems/commit/ce8bcba90f
|
|
https://github.com/rubygems/rubygems/commit/2a9d347d29
|
|
https://github.com/rubygems/rubygems/commit/2df7560ade
|
|
All other `chmod` usages in the file use `File.chmod`, so keep it
consistent.
https://github.com/rubygems/rubygems/commit/3dc0cf8703
|
|
(https://github.com/ruby/irb/pull/980)
https://github.com/ruby/irb/commit/6a9e129714
|
|
argument
(https://github.com/ruby/irb/pull/973)
The command only takes command names as arguments, so we should only
return command names as candidates.
This will help users find a command faster as completion will be
another useful hint too.
https://github.com/ruby/irb/commit/7b6557cc24
|
|
https://github.com/rubygems/rubygems/commit/14c4c16e96
|
|
(https://github.com/ruby/irb/pull/971)
It's essentially a combination of pushws and popws commands that are
easier to use.
Help message:
```
Usage: cd ([target]|..)
IRB uses a stack of workspaces to keep track of context(s), with `pushws` and `popws` commands to manipulate the stack.
The `cd` command is an attempt to simplify the operation and will be subject to change.
When given:
- an object, cd will use that object as the new context by pushing it onto the workspace stack.
- "..", cd will leave the current context by popping the top workspace off the stack.
- no arguments, cd will move to the top workspace on the stack by popping off all workspaces.
Examples:
cd Foo
cd Foo.new
cd @ivar
cd ..
cd
```
https://github.com/ruby/irb/commit/4a0e0e89b7
|
|
https://github.com/ruby/shellwords/commit/53e6ef2e71
|
|
https://github.com/ruby/shellwords/commit/fa50d40a33
|
|
https://github.com/ruby/shellwords/commit/08c87a964e
|
|
options
https://github.com/rubygems/rubygems/commit/d4360c9032
|
|
resolution
If it has been explicitly added by `bundle lock --add-platform`, we
don't want to remove it.
https://github.com/rubygems/rubygems/commit/09cf921dd6
|
|
https://github.com/rubygems/rubygems/commit/1c80c6072f
|
|
https://github.com/rubygems/rubygems/commit/0236cb6191
|
|
(https://github.com/ruby/rdoc/pull/1114)
It's hard to distinguish code object classes by their file names alone.
And given that we have 18 such classes, it'd make the codebase a lot
easier to understand if we grouped them into a single directory.
Given that these classes are all autoloaded in `lib/rdoc.rb` instead
of required individually, this change should have minimum impact on
projects using RDoc as they generally just require `rdoc`, not individual
files. An example is Rails' `sdoc`:
https://github.com/rails/sdoc/blob/main/lib/sdoc/rdoc_monkey_patches.rb
https://github.com/ruby/rdoc/commit/4211292ffe
|
|
* constist ==> consist
* Tidyness ==> Tidiness
* Currentry ==> Currently
* valus ==> values
https://github.com/ruby/rdoc/commit/8412705721
|
|
with command
(https://github.com/ruby/irb/pull/961)
https://github.com/ruby/irb/commit/00603d470f
|
|
|
|
https://github.com/rubygems/rubygems/commit/88e3f1d23c
|
|
https://github.com/rubygems/rubygems/commit/91274128a8
|
|
https://github.com/rubygems/rubygems/commit/8f34396af6
|
|
permission bit
https://github.com/rubygems/rubygems/commit/979cd898f9
|
|
RubyGems >= 3.5 no longer raises `Gem::FilePermissionError` explicitly.
https://github.com/rubygems/rubygems/commit/df54b9fd90
|