| Age | Commit message (Collapse) | Author |
|
https://github.com/ruby/erb/commit/b0ccb1e317
|
|
https://github.com/ruby/erb/commit/b629d578c0
|
|
https://github.com/ruby/erb/commit/3e57b27566
|
|
https://github.com/ruby/erb/commit/9b16b2d553
|
|
https://github.com/ruby/erb/commit/dd6db81d43
|
|
https://github.com/ruby/erb/commit/7556e6817c
|
|
https://github.com/ruby/erb/commit/7fed01c4de
|
|
The documentation must be just before the definition.
https://github.com/ruby/erb/commit/62282e32d9
|
|
(https://github.com/ruby/erb/pull/78)
https://github.com/ruby/erb/commit/de0f18579e
|
|
https://github.com/ruby/erb/commit/dee5dd4da8
|
|
https://github.com/ruby/erb/commit/d5f6f65a89
|
|
https://github.com/ruby/erb/commit/77830cb205
|
|
(https://github.com/ruby/erb/pull/75)
https://github.com/ruby/erb/commit/8dc0eacaad
|
|
When we're extracting a gem, it should be extracted to an empty
directory. Trying to remove every file before extracting the file
greatly slows the tar extraction process.
This change increases tar extraction speed by about 10%:
Master branch:
```
aaron@tc ~/g/tartest (main)> ruby -I../rubygems/lib:../vernier/lib test.rb
{MEAN: 0.https://github.com/rubygems/rubygems/commit/670195550005}
{stddev: 0.https://github.com/rubygems/rubygems/commit/029875687861}
{"mib/s": 20.https://github.com/rubygems/rubygems/commit/889425481677}
```
This commit:
```
aaron@tc ~/g/tartest (main)> ruby -I../rubygems/lib:../vernier/lib test.rb
{MEAN: 0.https://github.com/rubygems/rubygems/commit/600223749969}
{stddev: 0.https://github.com/rubygems/rubygems/commit/037224226667}
{"mib/s": 23.https://github.com/rubygems/rubygems/commit/324635189326}
```
https://github.com/rubygems/rubygems/commit/e40a153560
|
|
https://github.com/rubygems/rubygems/commit/ccb65ce0ea
|
|
https://github.com/rubygems/rubygems/commit/feb258c712
|
|
For consistency with the other deprecations.
https://github.com/rubygems/rubygems/commit/28e300cee1
|
|
https://github.com/rubygems/rubygems/commit/444022cfd3
|
|
(https://github.com/ruby/erb/pull/74)
https://github.com/ruby/erb/commit/125ce1f897
|
|
(https://github.com/ruby/erb/pull/73)
https://github.com/ruby/erb/commit/04bb746fc7
|
|
(https://github.com/ruby/erb/pull/71)
https://github.com/ruby/erb/commit/f4abab7195
|
|
(https://github.com/ruby/erb/pull/72)
https://github.com/ruby/erb/commit/df7bdcd5cb
|
|
https://github.com/ruby/erb/commit/aae3a5be34
|
|
It's a term from times with multiple remote sources, let's move on :)
https://github.com/rubygems/rubygems/commit/6439b8944e
|
|
https://github.com/rubygems/rubygems/commit/8f9d6c54a1
|
|
https://github.com/rubygems/rubygems/commit/1bc5e74281
|
|
https://github.com/rubygems/rubygems/commit/4c110d3289
|
|
https://github.com/rubygems/rubygems/commit/0a2f5ed717
|
|
Before this patch we would use `IO.copy_stream` with the tar entry
object rather than just straight to the IO. That means every time
copy_stream wanted data, we would have to proxy the call.
The reason we did this is because every tar entry object _shares_ the
same IO object, and previous to https://github.com/rubygems/rubygems/commit/8927533b0a47
we would call `IO.copy_stream` _without_ a size. Without passing a
size, copy_stream will just read until there is nothing left to read, so
these proxy object emulate finding "the end of the file" (where "end of
file" means "end of tar chunk"). Without emulating this "end of file"
behavior, copy_stream would just keep reading past the end of the tar
chunk.
However, now that we're passing the size to copy_stream, we can bypass
the proxy object overhead and just use the IO object directly because
copy_stream knows exactly the number of bytes it needs to read and will
stop when it reaches the goal.
https://github.com/rubygems/rubygems/commit/857002c135
|
|
And let the feature always be enabled, so I'm not sure why we'd need
this configurable.
https://github.com/rubygems/rubygems/commit/5a27f0c1e3
|
|
If the CLI flags are used, we abort early as usual.
As per the settings, I decided to ignore them. We've been migrating them
automatically to the new name for a long time and we don't yet have a
standard way to deprecate and remove settings (we should probably use
the existing setting validators). So I think it's fine for now to do
what we normally do (ignore the setting).
https://github.com/rubygems/rubygems/commit/8311de6e69
|
|
https://github.com/rubygems/rubygems/commit/2c16b0e11e
|
|
In Bundler 4, configuration will no longer be updated.
https://github.com/rubygems/rubygems/commit/33a4718d7a
|
|
When extracting tar files, the tar header actually knows the exact size
of the file we need to extract. Before this commit, we would read the
file from the tar file until it returned `nil`. We can be a little more
efficient when copying by passing the size to copy_stream
https://github.com/rubygems/rubygems/commit/8927533b0a
|
|
We already have the open file descriptor, so we can avoid the overhead
of resolving the filepath (as well as the overhead inside `FileUtils`)
by just calling `chmod` on the file descriptor itself.
https://github.com/rubygems/rubygems/commit/60c14bbeee
|
|
(https://github.com/ruby/erb/pull/69)
* [DOC] More on class
ERB
* [DOC] More on class
ERB
* More
* More
* More
https://github.com/ruby/erb/commit/d9d73ed58e
|
|
Symbol#name is only a thing since Ruby 3.0
https://github.com/ruby/prism/commit/2de82b15fc
|
|
The performances are: block > proc > method object.
https://github.com/ruby/optparse/commit/9ec5d1d582
|
|
An unspecified uplevel is not the same as an uplevel of 1:
```
$ irb
irb(main):001> warn("foo")
foo
=> nil
irb(main):002> warn("foo", uplevel: 1)
/home/user/.rbenv/versions/2.7.8/lib/ruby/gems/2.7.0/gems/irb-1.14.0/lib/irb/workspace.rb:121: warning: foo
=> nil
```
https://github.com/ruby/prism/commit/dcedd14357
|
|
(https://github.com/ruby/erb/pull/68)
https://github.com/ruby/erb/commit/9591b5d23b
|
|
Make it clear that it parses with the most recent version of Ruby
syntax.
https://github.com/ruby/prism/commit/7285d1fbab
|
|
https://github.com/ruby/prism/commit/cac5118884
|
|
(https://github.com/ruby/erb/pull/67)
https://github.com/ruby/erb/commit/7646ece279
|
|
https://github.com/ruby/prism/commit/194edab827
|
|
changes
When the source used to be git and switches back to rubygems,
it is possible that the git source contains a version that
ruybgems doesn't know about yet.
So don't add the locked spec to the base resolve, and also don't add a
lower bound requirement on the version, since the version in the new
source may actually be lower.
https://github.com/rubygems/rubygems/commit/85514e3a1e
|
|
It matches the comment above more naturally and it's consistent with how
the same thing is checked in other places.
https://github.com/rubygems/rubygems/commit/59ec6b4b29
|
|
It sounds like this should apply to all git sources at this point.
https://github.com/rubygems/rubygems/commit/b1817f91de
|
|
https://github.com/rubygems/rubygems/commit/744b35412e
|
|
If the file option is given but the file not found, raise a GemfileError
with a message indicating the file was not found.
Currently this is raising a generic Errno::ENOENT error.
https://github.com/rubygems/rubygems/commit/db61de6b21
|
|
The same also applies to `break`/`next`.
https://bugs.ruby-lang.org/issues/21540
https://github.com/ruby/prism/commit/3a38b192e3
|