| Age | Commit message (Collapse) | Author |
|
https://github.com/rubygems/rubygems/commit/babf943144
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/d81ce9e457
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/d92b94f3cf
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
It will give more useful information.
https://github.com/rubygems/rubygems/commit/efcecb5af5
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
The `rubygems/security` require already does this.
https://github.com/rubygems/rubygems/commit/bbb444b6f1
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
It's not that slow.
https://github.com/rubygems/rubygems/commit/9b928a4503
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/1e2c3cf118
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/cbd4abf8cf
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/af3e5f7883
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
`Gem::Installer`
Co-authored-by: MSP-Greg <MSP-Greg@users.noreply.github.com>
https://github.com/rubygems/rubygems/commit/710b969b60
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/d722b8b578
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/2cca6714f3
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/9963d33cf2
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
* 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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/694e6afee7
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/f4c4cddb68
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
The `teardown` method doesn't call it either and I don't think it's
necessary.
https://github.com/rubygems/rubygems/commit/ca2a5d485d
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/6e4bef758b
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/d1be8cdb3a
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
https://github.com/rubygems/rubygems/commit/0c0760b734
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
To normalize the code style with `bundler`.
Notes:
Merged: https://github.com/ruby/ruby/pull/3379
|
|
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.
Notes:
Merged: https://github.com/ruby/ruby/pull/3375
|
|
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.
Notes:
Merged: https://github.com/ruby/ruby/pull/3192
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3354
|
|
Notes:
Merged-By: marcandre <github@marc-andre.ca>
|
|
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3370
|
|
|
|
|
|
|
|
|