| Age | Commit message (Collapse) | Author |
|
Gem::DependencyInstaller#find_gems_with_sources
https://github.com/ruby/rubygems/commit/1b3f3bf194
|
|
https://github.com/ruby/rubygems/commit/94d4e633d1
|
|
https://github.com/ruby/rubygems/commit/728269cc4a
|
|
validate_dependencies and validate_permissions
https://github.com/ruby/rubygems/commit/fbf38fc190
|
|
https://github.com/ruby/rubygems/commit/84ceaff1b7
|
|
https://github.com/ruby/rubygems/commit/f4b4f12f91
|
|
https://github.com/ruby/rubygems/commit/96cef34041
|
|
Gem::BasicSpecification.default_specifications_dir
https://github.com/ruby/rubygems/commit/60f0b87d47
|
|
https://github.com/ruby/rubygems/commit/3f5330c9fc
|
|
https://github.com/ruby/rubygems/commit/be3b09c786
|
|
https://github.com/ruby/rubygems/commit/74c9eaf1f0
|
|
https://www.unicode.org/Public/emoji/ReadMe.txt
> This directory contains data files for versions 1.0 to 16.0 of Unicode Emoji.
> Starting with Unicode 17.0.0, the data files for Unicode Emoji are published in
> https://www.unicode.org/Public/<version>/emoji/
> together with the related files in
> https://www.unicode.org/Public/<version>/ucd/emoji/
|
|
|
|
While the latter creates an intermediate array of all method names
including all ancestors, the former just traverse the inheritance
chain and can stop if found once.
https://github.com/ruby/rubygems/commit/b291070b3b
|
|
If we are using multiple Ractors, other Ractors may allocate objects after
rb_gc_impl_before_fork is ran because it does not lock the VM. This can cause
the GC to be in a bad state since rb_gc_impl_before_fork may have terminated
GC threads so a GC cannot run until rb_gc_impl_after_fork is ran.
https://github.com/ruby/mmtk/commit/e4bea5676d
|
|
Fix the
```
write(2, "ruby: ZJIT has panicked. More info to follow...\n", 48) = 48
write(2, "\nthread '<unnamed>' panicked at zjit/src/backend/lir.rs:160:17:\nassertion failed: num_bits <= out_num_bits\n", 107) = 107
```
based on
```
#25 0x0000aaaaaae8fb14 in zjit::backend::lir::Opnd::mem (num_bits=64, base=..., disp=0) at zjit/src/backend/lir.rs:160
#26 zjit::backend::arm64::{impl#3}::arm64_split::split_memory_address (asm=<optimized out>,
opnd=<error reading variable: Cannot access memory at address 0x0>) at zjit/src/backend/arm64/mod.rs:260
#27 zjit::backend::arm64::{impl#3}::arm64_split::split_load_operand (asm=<optimized out>, opnd=...) at zjit/src/backend/arm64/mod.rs:273
```
|
|
|
|
|
|
|
|
`brace_block` is `'{' brace_body '}'` or `k_do do_body k_end`.
Both of them are not null so no need to check `$5`.
|
|
```
$ rake spec:regular
Successfully built RubyGem
Name: bundler
Version: 4.0.0.dev
File: bundler-4.0.0.dev.gem
```
https://github.com/ruby/rubygems/commit/8f0ca5eefa
|
|
|
|
https://github.com/ruby/rubygems/commit/a65a4b775e
|
|
https://github.com/ruby/rubygems/commit/d3baf4110e
|
|
We were seeing segfaults when calling `pthread_detach`. Apparently in
some versions of glibc there is a race between when this is called
(usually right after starting a thread) and a short-lived thread's
shutdown routine. The bug has been reported to glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=19951
I haven't been able to reproduce it on my Linux desktop but apparently
it's easier to reproduce on certain kinds of servers.
As a workaround, we can set the thread's detach state before thread
start. I don't know of a platform that doesn't have
`pthread_attr_setdetachstate`, but to be safe we check for it in
`extconf.rb` and use `pthread_detach` as a backup if it isn't available.
Fixes [Bug #21679]
|
|
|
|
https://github.com/ruby/net-http/commit/9d65391f54
|
|
https://github.com/ruby/net-http/commit/a3a5bc45f6
|
|
Update uri dependency to version 0.11.0 or later to use `URI::HTTP#authority` and `URI#parse` without scheme
https://github.com/ruby/net-http/commit/3d4f06bd7f
Co-authored-by: 0x1eef <0x1eef@users.noreply.github.com>
Co-authored-by: Sorah Fukumori <sora134@gmail.com>
|
|
These two class are most common sources of infinite sequences. This change should effectively prevent accidental infinite loops when calling to_set on them. [Bug #21513]
|
|
This reverts commit d4020dd5faf28486123853e7f00c36139fc07793, which introduced performance regression for objects like ActiveRecord::Relation by calling the costly #size method on them.
|
|
|
|
https://github.com/ruby/rubygems/commit/93b8492bc0
|
|
|
|
|
|
Always build gems with RubyGems programmatically
https://github.com/ruby/rubygems/commit/5cc0c34e64
|
|
|
|
|
|
- I'd like to be able to see how long bundler takes for basic
operations such as downloading a gem from Rubygems.org and
installing a gem.
It will now be possible with this commit by running
`DEBUG=true bundle install` and have output that looks like:
Fetching rack-test 2.2.0
Downloaded rack-test in: 50.523s
Installing rack-test 2.2.0
Installed rack-test in: : 0.003s
https://github.com/ruby/rubygems/commit/46386d43e1
|
|
The path already used in tool/test/test_sync_default_gems.rb .
Try to fix errors on Windows.
https://github.com/ruby/ruby/actions/runs/19316448613/job/55248700110
|
|
- ### Problem
This limit is used when Bundler fallback to getting a dependency
list from a server `/dependencies?gem=` endpoint. Bundler uses
this API endpoint fallback when a server doesn't expose the compact
index API.
This is not used for Rubygems.org, only private servers.
This limit is then divided by the number of dependency to get
and the result is the number of request we'll be doing.
The bottleneck on the client is the network roundtrip. On the
server, getting the info of 50 or 100 gems is a bit more expensive
but this operation is heavily cached.
This is an example of Rubygems.org implementation at the time the
dependencies API wasn't deprecated
https://github.com/rubygems/rubygems.org/blob/5a3a3ec02acc3a4e3aba077953a393ad20a06842/app/models/gem_dependent.rb#L15
### Context
This limit used to be 100 a while ago but got changed
to 50 in https://github.com/ruby/rubygems/commit/e745f8dc901dd419e7dc8aede3e8d49569fc7b1e
I don't know why.
### Solution
50 gems to query seems arbitrary low. By doubling this number, we
make twice as less API requests which ultimately can shove up to two
seconds on application relying on a large number of gems.
https://github.com/ruby/rubygems/commit/831894043c
|
|
This reverts commit 35783854244f8dc6a9f7fb4dfae752f8361c66bd.
|
|
|
|
I use `commit.gpgsign=true`, so I want to ignore it in tests.
|
|
I split this off from https://github.com/ruby/ruby/pull/14999 to land the JSON component earlier.
Iongraph's viewer is (as mentioned in the article above) a few notches above graphviz for viewing large CFGs. It also allows easily inspecting different compiler optimization passes and multiple functions in the same browser window. Since Spidermonkey is using this format, it may be beneficial to use it for our own JIT development.
The requirement for JSON is downstream from that of the Iongraph format. As for writing the implementation myself, ZJIT leans towards having fewer dependencies, so this is the preferred approach.
|
|
|
|
https://github.com/ruby/rubygems/commit/0cf49e22af
|
|
https://github.com/ruby/io-wait/commit/ad6f47fd3a
|
|
https://github.com/ruby/rubygems/commit/18f64c6b29
|
|
https://github.com/ruby/rubygems/commit/b59917447c
|