| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
No check is done for the other expectation and they are completely
symmetric as far as I can see.
https://github.com/rubygems/rubygems/commit/4de89e0718
|
|
|
|
|
|
| |
So it can be reused.
https://github.com/rubygems/rubygems/commit/b9fc6e40db
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/babf943144
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/d81ce9e457
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/d92b94f3cf
|
|
|
|
|
|
| |
It will give more useful information.
https://github.com/rubygems/rubygems/commit/efcecb5af5
|
|
|
|
|
|
| |
The `rubygems/security` require already does this.
https://github.com/rubygems/rubygems/commit/bbb444b6f1
|
|
|
|
|
|
| |
It's not that slow.
https://github.com/rubygems/rubygems/commit/9b928a4503
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/1e2c3cf118
|
|
|
|
|
|
|
|
|
|
|
| |
GNU make in MSys is localized to use UTF-8 while Ruby's filesystem
encoding is set to OEM CodePage (e.g., CP932 in Japanese Edition),
the read output from the make has broken encoding and results in
"invalid byte sequence" errors. As `DESTDIR` is set to a US-ASCII
7bit clean string, matching as binary encoding should have no
problems.
https://github.com/rubygems/rubygems/commit/96a5e7523b
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/cbd4abf8cf
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/af3e5f7883
|
|
|
|
|
|
|
|
| |
`Gem::Installer`
Co-authored-by: MSP-Greg <MSP-Greg@users.noreply.github.com>
https://github.com/rubygems/rubygems/commit/710b969b60
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/d722b8b578
|
|
|
|
|
|
|
|
|
| |
It seems like the most common case since it requires no tricks on our
CI environment.
Co-authored-by: MSP-Greg <MSP-Greg@users.noreply.github.com>
https://github.com/rubygems/rubygems/commit/751c475574
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/2cca6714f3
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/9963d33cf2
|
|
|
|
|
|
|
|
|
|
|
| |
with nil path
It's very unlikely to hit this case, but it is possible, as
Thread::Backtrace::Location#path can return nil if the location is
a cfunc with no previous iseq. See location_path in vm_backtrace.c
in Ruby.
https://github.com/rubygems/rubygems/commit/511935645a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* See https://github.com/oracle/truffleruby/issues/2046
* `<internal:` is a common prefix also used by core Ruby files in CRuby.
* test_no_kernel_require_in_*warn_with_uplevel already test this.
* Unfortunately just skipping `<internal:` in the Ruby implementation
is not enough, because RubyGems' #warn would not skip the
`<internal:` require (TruffleRuby defines #require in Ruby),
and the Ruby implementation's #warn would not skip
RubyGems's #require. The #caller_locations(0) look like this:
warnee.rb:1:in `<top (required)>' # where #warn is called
<internal:core> core/kernel.rb:234:in `gem_original_require' # not skipped by RubyGems' warn, skipped by the Ruby impl
rubygems/core_ext/kernel_require.rb:54:in `require' # not skipped by the Ruby impl's warn, what would be shown without this fix
warn.rb:1:in `<main>' # what would be correct
warn.rb is
require "warnee"
warnee.rb is
puts caller_locations(0), nil
warn "oops", uplevel: 1
https://github.com/rubygems/rubygems/commit/7c838f7419
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/694e6afee7
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/f4c4cddb68
|
|
|
|
|
|
|
| |
The `teardown` method doesn't call it either and I don't think it's
necessary.
https://github.com/rubygems/rubygems/commit/ca2a5d485d
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/6e4bef758b
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/d1be8cdb3a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was added 10 years ago on a "146 additions, 170 deletions" commit
named "Deprecation removals and minor cleanup." that didn't explain much
other than that.
This TODO doesn't necessarily apply nowadays. I don't see how anyways.
TODO notes, if useful at all, should include a clear explanation of what
should be done either via the note itself or the commit message. This
note doens't meet any of these.
So I want to remove it because it distracts me every time I go through
it.
https://github.com/rubygems/rubygems/commit/58d81e8a32
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Profiling a simple `ruby -e '1'` I see:
```
==================================
Mode: wall(10)
Samples: 3414 (55.10% miss rate)
GC: 856 (25.07%)
==================================
TOTAL (pct) SAMPLES (pct) FRAME
689 (20.2%) 669 (19.6%) Gem.already_loaded?
462 (13.5%) 462 (13.5%) (marking)
393 (11.5%) 393 (11.5%) (sweeping)
815 (23.9%) 365 (10.7%) Gem::Specification.load
1050 (30.8%) 156 (4.6%) Gem.register_default_spec
100 (2.9%) 84 (2.5%) Gem::Specification#files
64 (1.9%) 64 (1.9%) Gem::BasicSpecification#internal_init
136 (4.0%) 59 (1.7%) <top (required)>
2312 (67.7%) 58 (1.7%) <top (required)>
57 (1.7%) 57 (1.7%) RbConfig.expand
81 (2.4%) 55 (1.6%) Gem::Requirement.parse
191 (5.6%) 51 (1.5%) <top (required)>
128 (3.7%) 47 (1.4%) Gem::Requirement#initialize
41 (1.2%) 41 (1.2%) Gem.suffix_regexp
229 (6.7%) 35 (1.0%) <module:Gem>
260 (7.6%) 34 (1.0%) Kernel#require
```
So clearly `Gem.already_loaded?` is a major hotspot.
After this optimization, it's down to:
```
==================================
Mode: wall(10)
Samples: 2653 (58.21% miss rate)
GC: 718 (27.06%)
==================================
TOTAL (pct) SAMPLES (pct) FRAME
416 (15.7%) 416 (15.7%) (marking)
715 (27.0%) 312 (11.8%) Gem::Specification.load
299 (11.3%) 299 (11.3%) (sweeping)
279 (10.5%) 279 (10.5%) Gem.already_loaded?
564 (21.3%) 106 (4.0%) Gem.register_default_spec
95 (3.6%) 80 (3.0%) Gem::Specification#files
72 (2.7%) 72 (2.7%) Gem::BasicSpecification#internal_init
129 (4.9%) 58 (2.2%) <top (required)>
53 (2.0%) 53 (2.0%) RbConfig.expand
1697 (64.0%) 52 (2.0%) <top (required)>
68 (2.6%) 49 (1.8%) Gem::Requirement.parse
183 (6.9%) 48 (1.8%) <top (required)>
112 (4.2%) 44 (1.7%) Gem::Requirement#initialize
220 (8.3%) 33 (1.2%) <module:Gem>
250 (9.4%) 32 (1.2%) Kernel#require
```
The idea is that the vast majority of the time `already_loaded?` won't match
anything. So by first looking for candidate paths that `end_with?` the file we
look for, we save `default_gem_load_paths.size` iterations and string concatenations.
https://github.com/rubygems/rubygems/commit/c60ce88d49
|
| |
|
|
|
|
|
|
|
|
| |
The previous commit introduces the Gem::Security.create_digest method, allowing to:
- decouple algorithm choice from implementation (OpenSSL or Ruby built-in)
- untangle the SHA512 fallback for TarWriter from the generic hashing digest choice (undoing commit 9471f8ed2bdc12248d2619bbbce6e53cd6c16cb6)
https://github.com/rubygems/rubygems/commit/1bc03231e4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the Gem module's auto-loads will handle loading these as needed,
this started as a redundancy found in *rubygems.rb* which had:
`autoload :Specification, 'rubygems/specification'` as well as
`require 'rubygems/specification'`
https://github.com/rubygems/rubygems/commit/43ceae7ac0
|
|
|
|
| |
https://github.com/rubygems/rubygems/commit/0c0760b734
|
|
|
|
| |
To normalize the code style with `bundler`.
|
|
|
|
| |
Fixes [Bug #10475]
|
| |
|
| |
|
| |
|
|
|
|
| |
https://github.com/ruby/racc/commit/51817ce0f6
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
"requiring version.rb" strategy has some issues.
- cannot work when cross-compiling
- often introduces wrong namespace
- must know the superclasses
- costs at each runtime than at build-time
etc.
|
|
|
|
|
|
|
| |
Both clone & dup returns a new object when executed
on the documentation looks like they are returning the
same object cloned or dup'ed which is true for method
as extend, but not for the above mentioned.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|