If a gem is located in a different drive than the Gemfile, standalone
mode will fail to generate the `bundler/setup` script, failing with an
error like
```
ArgumentError: different prefix: "C:/" and "D:/a/rubygems/rubygems/bundler/tmp/2/bundled_app/bundle/bundler"
C:/hostedtoolcache/windows/Ruby/3.0.5/x64/lib/ruby/3.0.0/pathname.rb:528:in `relative_path_from'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:58:in `gem_path'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:33:in `block (2 levels) in paths'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:32:in `map'
D:/a/rubygems/rubygems/bundler/tmp/2/gems/system/gems/bundler-2.4.20/lib/bundler/installer/standalone.rb:32:in `block in paths'
```
I'm fixing this by falling back to using a full path in this case.
This was caught by a failing spec, so I'm not adding new specs.
https://github.com/rubygems/rubygems/commit/3cb9b9ab7a
Rails uses IPAddr#include? to evaluate what it should use as the
client's remote ip by filtering potential ips against a trusted list
of internal ips. In a _very_ minimal app, #include? was showing up in
a profile as ~1% of request time.
The issue is that #include? was converting itself and the other value
passed in to ranges of IPAddr. This mean as a worst case (where other is
a non-IPAddr, like a String) then there would be 5 IPAddr instances
created (other -> IPAddr, and two each for the conversions to ranges).
However, wrapping the begin and end values as IPAddr is not needed
because they are necessarily fixed addresses already.
This patch extracts the logic for getting the begin_addr and end_addr
from the #to_range method so that they can be used in #include? without
having to instantiate so many IPAddr.
Benchmark:
```ruby
net1 = IPAddr.new("192.168.2.0/24")
net2 = IPAddr.new("192.168.2.100")
net3 = IPAddr.new("192.168.3.0")
net4 = IPAddr.new("192.168.2.0/16")
Benchmark.ips do |x|
x.report("/24 includes address") { net1.include? net2 }
x.report("/24 not includes address") { net1.include? net3 }
x.report("/16 includes /24") { net4.include? net1 }
x.report("/24 not includes /16") { net1.include? net4 }
x.compare!
end
```
Before:
```
Comparison:
/24 not includes /16: 175041.3 i/s
/24 not includes address: 164933.2 i/s - 1.06x (± 0.00) slower
/16 includes /24: 163881.9 i/s - 1.07x (± 0.00) slower
/24 includes address: 163558.4 i/s - 1.07x (± 0.00) slower
```
After:
```
Comparison:
/24 not includes /16: 2588364.9 i/s
/24 not includes address: 1474650.7 i/s - 1.76x (± 0.00) slower
/16 includes /24: 1461351.0 i/s - 1.77x (± 0.00) slower
/24 includes address: 1425463.5 i/s - 1.82x (± 0.00) slower
```
```
==> memprof.after.txt <==
Total allocated: 673.08 kB (7644 objects)
Total retained: 107.35 kB (1018 objects)
==> memprof.before.txt <==
Total allocated: 739.12 kB (9140 objects)
Total retained: 138.61 kB (1695 objects)
```
Savings will scale by the number of lines in the lockfile
https://github.com/rubygems/rubygems/commit/f6abf4439c
We were setting the wrong `extension_dir` for git specs stubs
Additionally, the call to `self.extension_dir` was loading the
remote spec, which was avoidable since the stub had an extension dir
(and in fact its #gem_build_complete_path does exactly what we want
anyway)
Finally, now set the base_dir when loading the remote_spec from a
stub specification, since the git source sets the base dir for stubs
based on where the spec _will_ be installed to, and we want to preserve
that so the base_dir for the loaded spec & the stub are the same
https://github.com/rubygems/rubygems/commit/a94acb465b
Reduces allocations in a bundle install --full-index by an order of magnitude
Main wins are (a) getting rid of exessive string allocations for exception message stack
(b) Avoiding hash allocations caused by kwargs for #initialize
(c) avoid using unpack to do bit math, its easy enough to do by hand
(d) special case the most common elements so they can be read without an allocation
(e) avoid string allocations every time a symbol->string lookup is done by using symbol#name
https://github.com/rubygems/rubygems/commit/7d2ee51402
* Add $YARP_SERIALIZE_ONLY_SEMANTICS_FIELDS to control where to serialize location fields at templating time,
this way there is no overhead for either case and nothing to check at runtime.
* Add a byte in the header to indicate whether location fields are included as expected.
* Fixes https://github.com/ruby/yarp/issues/807
* Simplify the build-java CI job now that the FFI backend is available so JRuby can serialize.
* Support keeping some location fields which are still needed until there is a replacement
https://github.com/ruby/yarp/commit/fc5cf2df12
This helps with memory usage during application boot time
```
==> memprof.after.txt <==
Total allocated: 1.43 MB (18852 objects)
Total retained: 421.12 kB (4352 objects)
==> memprof.before.txt <==
Total allocated: 2.43 MB (28355 objects)
Total retained: 469.69 kB (5425 objects)
```
See https://bugs.ruby-lang.org/issues/19890 about the readline
allocations
https://github.com/rubygems/rubygems/commit/d7eb66eee3
Although the specification for UUIDv7 is still in draft, the UUIDv7
algorithm has been relatively stable as it progresses to completion.
Version 7 UUIDs can be very useful, because they are lexographically
sortable, which can improve e.g: database index locality. See section
6.10 of the draft specification for further explanation:
https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/
The specification allows up to 12 bits of extra timestamp precision, to
make UUID generation closer to monotonically increasing. This provides
between 1ms and ~240ns of timestamp precision. At the cost of some code
complexity and a small performance penalty, a kwarg may specify any
arbitrary precision between 0 and 12 extra bits. Any stronger
guarantees of monotonicity have considerably larger tradeoffs, so
nothing more is implemented. This limitation is documented.
Ruby issue: https://bugs.ruby-lang.org/issues/19735https://github.com/ruby/securerandom/commit/34ed1a2ec3
Kevin Newton
Ry Biesemeyer
David Rodriguez
krororo
elfham
Hartley McGuire
Haldun Bayhantopcu
BurdetteLamar
Stan Lo
Samuel Giddins
Jemma Issroff
Benoit Daloze
nick evans
0x1eef
Yoshiki Takagi
Jeremy Evans