- ruby-core - ml.ruby-lang.org

[ruby-core:122898] [Ruby Feature#21527] Proposal: Math.log1p and Math.expm1
by mame (Yusuke Endoh) 21 Aug '25

21 Aug '25

Issue #21527 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #21527: Proposal: Math.log1p and Math.expm1 https://bugs.ruby-lang.org/issues/21527 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- Let's add `Math.log1p` and `Math.expm1`. * `Math.log1p(x)`: Computes `Math.log(x + 1)` * `Math.expm1(x)`: Computes `Math.exp(x) - 1` These methods are often more accurate than the straightforward computation, especially when `x` is close to zero. ``` # The current approach loses precision p Math.log(1 + 1.0e-16) #=> 0.0 p Math.exp(1.0e-16) - 1 #=> 0.0 # The proposed methods return the accurate result p Math.log1p(1.0e-16) #=> 1.0e-16 p Math.expm1(1.0e-16) #=> 1.0e-16 ``` Note that they are very standard; the C99 even defines `log1p()` and `expm1()`. Other major programming languages (Python, JavaScript, Java, Go, Rust, etc.) also provide them. PR: https://github.com/ruby/ruby/pull/14087 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122993] subscription alert
by NetfIix 20 Aug '25

20 Aug '25

1 0

[ruby-core:122984] Federal High Court Notice To ruby-core@ruby-lang.org
by Federal High Court 19 Aug '25

19 Aug '25

1 0

[ruby-core:122959] [Ruby Bug#21541] make install is failing due to using rdoc repo
by MSP-Greg (Greg L) 19 Aug '25

19 Aug '25

Issue #21541 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21541: make install is failing due to using rdoc repo https://bugs.ruby-lang.org/issues/21541 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: master * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, ruby-dev-builder & ruby-loco are failing due to https://github.com/ruby/ruby/commit/8f6f9e88c70bbae, which changed the rdoc 'bundled gem' install from using a released gem to the repo. This results in an invalid rdoc installation. RDoc contains *.ry and *.kpeg source files that need to be 'compiled' into *.rb files with racc and kpeg. These *.rb files are not contained in the rdoc repo. One possible change would be to have rdoc include the compiled *.rb files in its repo. Puma has a similar issue with ragel files. A GHA workflow (https://github.com/puma/puma/blob/master/.github/workflows/ragel.yml) checks that the compiled *.c file matches its respective *.rl source file. Otherwise, a bit of code would be required in Ruby (and install of kpeg), or, rdoc must be installed from a released gem. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:122960] [Ruby Feature#21542] logger gem: Context API
by chucke (Tiago Cardoso) 19 Aug '25

19 Aug '25

Issue #21542 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Feature #21542: logger gem: Context API https://bugs.ruby-lang.org/issues/21542 * Author: chucke (Tiago Cardoso) * Status: Open ---------------------------------------- Proposal done as a [github issue](https://github.com/ruby/logger/issues/131) with [WIP implementation](https://github.com/ruby/logger/pull/132) for discussion purposes. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122976] [Ruby Feature#12282] Hash#dig! for repeated applications of Hash#fetch
by briankung (Brian Kung) 18 Aug '25

18 Aug '25

Issue #12282 has been updated by briankung (Brian Kung). Agreed, this feature would be useful. I would like to essentially assert that all of the nodes along the path are found. To that end, I would suggest calling it something like `#fetch_path`: ``` ruby object = {foo: {bar: { baz: true}} object.fetch_path(:foo, :bar, :baz) #=> true object.fetch_path(:foo, :baz, :bar) #=> (irb):3:in 'Hash#fetch_path': key not found: :baz (KeyError) ``` ---------------------------------------- Feature #12282: Hash#dig! for repeated applications of Hash#fetch https://bugs.ruby-lang.org/issues/12282#change-114279 * Author: robb (Robb Shecter) * Status: Open ---------------------------------------- A new feature for your consideration: #dig! which is to #fetch as #dig is to #[]. For me and maybe many others, Hash#fetch is used much more than Hash#[]. And traversing multiple fetches isn't very convenient nor Ruby-like, e.g.: places.fetch(:countries).fetch(:canada).fetch(ontario). Here's how it would work: ~~~ruby places = { countries: { canada: true } } places.dig :countries, :canada # => true places.dig! :countries, :canada # => true places.dig :countries, :canada, :ontario # => nil places.dig! :countries, :canada, :ontario # => KeyError: Key not found: :ontario ~~~ Here's an implementation and tests: https://gist.github.com/dogweather/819ccdb41c9db0514c163cfdb1c528e2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122973] [PATCH] Add Gem.default_install
by Felipe Contreras 17 Aug '25

17 Aug '25

We need a way to enable user installs by default so that tools like bundler don't attempt to install to system directories. The configuration Gem.default_user_install was meant to enable user installs, but it only affects `gem install`, not bundler. Distributions were already able to change the defaults of `gem install`, so it didn't change anything, and that's why nobody is using it. Instead we need a method that allows something that is not currently possible: override Gem.dir. Gem.default_install is that method, which allows changing user installs to both gem and bundler. It defaults to Gem.default_dir, so there's no change in functionality: def default_install default_dir end Distributions can then override this to enable user installs by default: def default_install user_dir end This allows for more flexibility than Gem.default_user_install. For example distributions can choose to install to different directories based on the user id: def default_install Process.uid == 0 ? local_dir : user_dir end The current Gem.default_user_install solution is simply not enough. --- lib/rubygems/defaults.rb | 7 +++++++ lib/rubygems/path_support.rb | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/rubygems/defaults.rb b/lib/rubygems/defaults.rb index db07681a17..20f4fcd2f3 100644 --- a/lib/rubygems/defaults.rb +++ b/lib/rubygems/defaults.rb @@ -9,6 +9,13 @@ module Gem @pre_uninstall_hooks ||= [] @pre_install_hooks ||= [] + ## + # Determines the default install directory + + def self.default_install + default_dir + end + ## # An Array of the default sources that come with RubyGems diff --git a/lib/rubygems/path_support.rb b/lib/rubygems/path_support.rb index 13091e29ba..455f413f3d 100644 --- a/lib/rubygems/path_support.rb +++ b/lib/rubygems/path_support.rb @@ -24,7 +24,7 @@ class Gem::PathSupport # hashtable, or defaults to ENV, the system environment. # def initialize(env) - @home = normalize_home_dir(env["GEM_HOME"] || Gem.default_dir) + @home = normalize_home_dir(env["GEM_HOME"] || Gem.default_install) @path = split_gem_path env["GEM_PATH"], @home @spec_cache_dir = env["GEM_SPEC_CACHE"] || Gem.default_spec_cache_dir -- 0.1

2 2

[ruby-core:122724] [Ruby Misc#21508] DevMeeting-2025-08-21
by mame (Yusuke Endoh) 15 Aug '25

15 Aug '25

Issue #21508 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21508: DevMeeting-2025-08-21 https://bugs.ruby-lang.org/issues/21508 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/08/21 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/08/18. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 15 Aug '25

15 Aug '25

Issue #20013 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20013: Travis CI status https://bugs.ruby-lang.org/issues/20013 * Author: jaruga (Jun Aruga) * Status: Open * Priority: Normal ---------------------------------------- I would like to use this ticket to manage our activities to report Travis CI status. Because there is Travis CI status page provided by Travis CI. However, even when the page shows ok, I actually see infra issues. https://www.traviscistatus.com/ I would share my activities and report the Travis CI status on the ticket. The ticket's status is not closed until we stop using Travis CI. The easiest option to fix the Travis infra issue is to email Travis CI support `support _AT_ travis-ci.com`. You can check [this ruby/ruby Travis CI wiki page](https://github.com/ruby/ruby/wiki/CI-Servers#travis-ci) for details. -- https://bugs.ruby-lang.org/

2 50

[ruby-core:122968] [Ruby Misc#21544] CI: Launchable: Early flake detection
by ono-max (Naoto Ono) 15 Aug '25

15 Aug '25

Issue #21544 has been reported by ono-max (Naoto Ono). ---------------------------------------- Misc #21544: CI: Launchable: Early flake detection https://bugs.ruby-lang.org/issues/21544 * Author: ono-max (Naoto Ono) * Status: Open ---------------------------------------- I'm a software engineer at Launchable, and I'd like to propose the mechanism to detect potential flaky tests. ## Background In the current Ruby CI, it's easy for flaky tests to be unintentionally merged into the master branch. Even when tests are known to be flaky, they can often be overlooked because re-running them may yield a passing result. Once flaky tests make it into the master branch, they become much harder to debug, and even reverting the changes can be difficult. Therefore, it's crucial to identify potential flaky tests as early as possible—ideally before merging a pull request into the master branch. If we can detect a flaky test during the PR stage, we can prevent it from being introduced into the codebase. ## How it works Here is the basic flow: 1. After the initial run, Launchable provides a list of tests to re-run. 2. The Ruby test framework executes these tests and uploads the results. 3. Using historical data, Launchable detects new or updated tests and returns an updated list. 4. The Ruby test framework runs the new list of tests and uploads the results. 5. Based on these results, Launchable determines which tests need to be re-run. 6. The Ruby test framework executes the identified tests and uploads the results. 7. Repeat step 5 and 6 until Launchable returns an empty test list. Here is the image: <img src="CI_workflow.png" alt="My Image" style="width:600px;"> ## Concerns * How much will Ruby CI slow down with this change? I don't believe this change significantly slow down the CI process. For example, consider a new test that takes 10 seconds to run. Adding 5 seconds to records to record test results to Launchable and another 5 seconds to provide the test list for re-runs, the total time per attempt becomes: (10 sec + 5 sec + 5 sec) = 20 seconds. With 5 retries, the total execution time would be: 20 seconds × 5 = 100 seconds. ---Files-------------------------------- CI_workflow.png (266 KB) -- https://bugs.ruby-lang.org/

1 0