May 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:115117] [Ruby master Bug#19967] Already installed libruby.dylib is used for test on macOS
by nobu (Nobuyoshi Nakada) 24 Jan '25

24 Jan '25

Issue #19967 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19967: Already installed libruby.dylib is used for test on macOS https://bugs.ruby-lang.org/issues/19967 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- On macOS, in the case of `--enable-shared` and `--disable-load-relative`, already install libruby.dylib is used during tests if exists. This is because since [Bug #14992], `DYLD_FALLBACK_LIBRARY_PATH` is used instead of `DYLD_LIBRARY_PATH`. The latter environment variable is used preferentially, whereas the former is used as a fallback, as the name implies. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:116640] [Ruby master Feature#20249] Print only backtraces in rb_bug(), by default
by osyoyu (Daisuke Aritomo) 23 Jan '25

23 Jan '25

Issue #20249 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #20249: Print only backtraces in rb_bug(), by default https://bugs.ruby-lang.org/issues/20249 * Author: osyoyu (Daisuke Aritomo) * Status: Open * Priority: Normal ---------------------------------------- ## Background When a segfault or some unexpected situation occurs, `rb_bug()` is called and prints some few hundred to thousands of lines. The most helpful parts are (arguably) "Ruby level backtrace information" and "C-level backtrace information", but those parts are buried in the very lengthy report. In particular, the "Other runtime information" which contains the list of loaded features (scripts?) and the process memory map could be extremely long despite it does not come very useful, at least when developing C extensions. Even a minimal report from a simple script would consist of 250 lines and require 7 PgUps on my MacBook Air (13 inch) to reach the backtrace part, which contains all the information I need. ## Proposal My proposal is to default to a "minimal report" mode with a limited set of sections, perhaps only "Ruby level backtrace information" and "C level backtrace information" only When a full report is desired (i.e. for bug reports), the user could re-run the script with an special environment variable, such as `RUBY_FULL_CRASH_REPORT=1`. Rust implmements a similar pattern. It doesn't print the full backtrace on panics by default; instead, it guides the user to re-run the program with `RUST_BACKTRACE=1`. It might be hard to reproduce some crashes and segfaults, especially in long-running daemons. It might be nice to default to the "full" mode when stdout is not a tty, since daemons tend to run in non-tty environments. ## Appendix A typical crash report would look like this: ``` ../../example.rb: [BUG] ruby 3.4.0dev (2024-01-20T15:27:19Z master 366b14c0cd) [arm64-darwin23] -- Crash Report log information -------------------------------------------- (5 lines) -- Control frame information ----------------------------------------------- (~50 lines) -- Ruby level backtrace information ---------------------------------------- (depends on program; typically ~50 lines in Rails) -- C level backtrace information ------------------------------------------- (50+-ish lines, depends on program) -- Machine register context ------------------------------------------------ (~10 lines) -- Threading information --------------------------------------------------- (2 lines) -- Other runtime information ----------------------------------------------- * Loaded script (1 line) * Loaded features (depends on program; 800+ lines in Rails) * Process memory map (depends on environment; around 200 lines?) -- https://bugs.ruby-lang.org/

5 10

[ruby-core:111121] [Ruby master Bug#19165] Method (with no param) delegation with *, **, and ... is slow
by matsuda (Akira Matsuda) 16 Jan '25

16 Jan '25

Issue #19165 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19165: Method (with no param) delegation with *, **, and ... is slow https://bugs.ruby-lang.org/issues/19165 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-01T08:05:41Z master 4e68b59431) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I found that method delegation via Forwardable is much slower than normal method call when delegating a method that does not take parameters. Here's a benchmark that explains what I mean. ``` require 'forwardable' require 'pp' require 'benchmark/ips' class Obj extend Forwardable attr_accessor :other def initialize @other = Other.new end def foo_without_splat @other.foo end def foo_with_splat(*) @other.foo(*) end def foo_with_splat_with_name(*args) @other.foo(*args) end def foo_with_splat_and_double_splat(*, **) @other.foo(*, **) end def foo_with_triple_dots(...) @other.foo(...) end delegate :foo => :@other end class Other def foo() end end o = Obj.new Benchmark.ips do |x| x.report 'simple call' do o.other.foo end x.report 'delegate without splat' do o.foo_without_splat end x.report 'delegate with splat' do o.foo_with_splat end x.report 'delegate with splat with name' do o.foo_with_splat_with_name end x.report 'delegate with splat and double splat' do o.foo_with_splat_and_double_splat end x.report 'delegate with triple dots' do o.foo_with_triple_dots end x.report 'delegate via forwardable' do o.foo end end (result) simple call 38.918M (± 0.9%) i/s - 194.884M delegate without splat 31.933M (± 1.6%) i/s - 159.611M delegate with splat 10.269M (± 1.6%) i/s - 51.631M delegate with splat with name 9.888M (± 1.0%) i/s - 49.588M delegate with splat and double splat 4.117M (± 0.9%) i/s - 20.696M delegate with triple dots 4.169M (± 0.9%) i/s - 20.857M delegate via forwardable 9.204M (± 2.1%) i/s - 46.295M ``` It shows that Method delegation with a splat is 3-4 times slower (regardless of whether the parameter is named or not), and delegation with a triple-dot literal is 9-10 times slower than a method delegation without an argument. This may be because calling a method taking a splat always assigns an Array object even when no actual argument was given, and calling a method taking triple-dots assigns five Array objects and two Hash objects (this is equivalent to `*, **`). Are there any chance reducing these object assignments and making them faster? My concern is that the Rails framework heavily uses this kind of method delegations, and presumably it causes unignorable performance overhead. -- https://bugs.ruby-lang.org/

6 8

[ruby-core:112005] [Ruby master Bug#19374] Issue with Ractor.make_shareable with curried procs
by luke-gru (Luke Gruber) 14 Jan '25

14 Jan '25

Issue #19374 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19374: Issue with Ractor.make_shareable with curried procs https://bugs.ruby-lang.org/issues/19374 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This works, but shouldn't: ```ruby class Worker def start(&blk) blk = blk.curry # bug in ruby allows sharing of non-shareable proc Ractor.make_shareable(blk) @ractor = Ractor.new(blk) do |b| main = b.call p "from ractor: #{main}" end end def work @ractor.take end end worker = Worker.new a = self # unshareable main object p "from main: #{a}" worker.start { a } worker.work ``` The curried proc has a reference to the original proc and it's not checked for shareability. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:117826] [Ruby master Bug#20480] Complie failure for unable to configure NET_LUID using msys2 mingw64-gcc
by nekoyama32767 (Jinsong Yu) 10 Jan '25

10 Jan '25

Issue #20480 has been reported by nekoyama32767 (Jinsong Yu). ---------------------------------------- Bug #20480: Complie failure for unable to configure NET_LUID using msys2 mingw64-gcc https://bugs.ruby-lang.org/issues/20480 * Author: nekoyama32767 (Jinsong Yu) * Status: Open * ruby -v: ruby 3.4.0dev (2024-05-10T04:54:31Z master 2f915e729a) [x64-mingw32] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Master commit:`2f915e729ac8c66f4009f4b28a57773923d7e7d1` NET_LUID is not successfully checked in win32 configure. When try to compile in msys2 mingw64-gcc there will be a error message like follow. ``` win32/win32.c:4365:7: error: conflicting types for 'NET_LUID'; have 'struct <anonymous>' 4365 | } NET_LUID; | ^~~~~~~~ In file included from D:/msys64/mingw64/include/iptypes.h:17, from D:/msys64/mingw64/include/iphlpapi.h:17, from ./include/ruby/win32.h:40, from ./include/ruby/internal/dosish.h:38, from ./include/ruby/defines.h:78, from ./include/ruby/ruby.h:25, from win32/win32.c:24: D:/msys64/mingw64/include/ifdef.h:106:3: note: previous declaration of 'NET_LUID' with type 'NET_LUID' 106 | } NET_LUID, *PNET_LUID; | ^~~~~~~~ ``` Mingw64-gcc has NET_LUID, when comment out line 4357-line 4367 in `win32/win32.c` in follow, compile will be successed. ``` #ifndef HAVE_TYPE_NET_LUID typedef struct { uint64_t Value; struct { uint64_t Reserved :24; uint64_t NetLuidIndex :24; uint64_t IfType :16; } Info; } NET_LUID; #endif ``` mingw64-gcc version ``` gcc --version gcc.exe (Rev4, Built by MSYS2 project) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:117929] [Ruby master Feature#20498] Negated method calls
by MaxLap (Maxime Lapointe) 05 Jan '25

05 Jan '25

Issue #20498 has been reported by MaxLap (Maxime Lapointe). ---------------------------------------- Feature #20498: Negated method calls https://bugs.ruby-lang.org/issues/20498 * Author: MaxLap (Maxime Lapointe) * Status: Open ---------------------------------------- I want to propose the following syntax: `foo.!bar`. I know it's already valid syntax, but please read on for details. When someone write a somewhat long line of code that is negated, the main way I've seen of doing it is: ``` must_create_user = !User.where(somelong: :condition, even_more: "thing").exists? ``` I personally highly dislike it, as I must keep the "not" in the back of my mind as I read the line. When quickly reading a line like this, it's super easy to misread and understand the opposite result. The current ways around this I can think of are: * rename the variable (can be annoying) * Use `unless` (only possible when in a condition; some people, like me, have a hard time grapsping a `unless`) * use a `.!`in the end (`foo.exists?.!`), I've never seen that and it looks ugly to me (this is subjective). * create a new method name with the negated meaning (not always possible) My proposal would look like this: ``` must_create_user = User.where(somelong: :condition, even_more: "thing").!exists? ``` You cannot forget the bang that you saw 15 words ago, it's right there. It also basically reads as English: "user where ... doesn't exists". The main argument against this I can think of is that it's technically already a valid syntax. I believe it's frowned upon to override the bang operator and I'm not aware of places where it is overridden to with also having a parameter. I made a prototype in RubyNext, which you can try here: https://ruby-next.github.io/#gist:0e133bf6f27f2437193dc034d58083dc -- https://bugs.ruby-lang.org/

8 9

[ruby-core:117618] [Ruby master Feature#20437] Could be the licensing conditions be made less ambiguous?
by vo.x (Vit Ondruch) 03 Jan '25

03 Jan '25

Issue #20437 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #20437: Could be the licensing conditions be made less ambiguous? https://bugs.ruby-lang.org/issues/20437 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- # Current state The current [COPYING](https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88… file says the following: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or the conditions below: 1. You may make and give away verbatim copies of the source form of the ... snip ... ~~~ And this is quite ambiguous. Let me show a few examples: # Ambiguous examples ## lib/net/protocol.rb https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88bef56159/… ~~~ # This program is free software. You can re-distribute and/or # modify this program under the same terms as Ruby itself, # Ruby Distribute License or GNU General Public License. ~~~ So what is the license? Is it 2-clause BSDL + Ruby + GPL? Or is is just Ruby + GPL but not 2-clause BSDL? ## Racc https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd884ebcabf/… ~~~ Racc is distributed under the same terms of ruby. (see the file COPYING). ~~~ where the [COPYING](https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd8… contains just 2-clause BSDL. Not even mentioning that Ruby used to be GPLv2 licensed: https://github.com/ruby/racc/commit/cc7fe952a6b1fc2ef43477674fa13f2d9d99e818 ## Rubygems https://github.com/rubygems/rubygems/blob/master/LICENSE.txt The license is obviously modeled after Ruby COPYING file, but if it could say "licensed under MIT or Ruby", it would be much better. ## Gettext https://github.com/ruby-gettext/gettext/blob/8d84132efd888e68fffbce41331645… The license note is so old that it is not obvious what that means and what was the intention. Did the Ruby relicensing from "GPLv2 or Ruby" to "GPLv2 or BSD" influenced this project? ## SPDX https://spdx.org/licenses/Ruby.html It quotes just the "conditions below" as a Ruby license, while referring to [Ruby license file](https://www.ruby-lang.org/en/about/license.txt) mentioning also 2-clause BSDL # Proposal To me it seems that the whole world recognizes "Ruby" license, except Ruby. Therefore I think it would be nice if Ruby project recognized the "Ruby" license. There are two possibilities I can think of: ## Refer the license by name ~~~diff $ git diff diff --git a/COPYING b/COPYING index 48e5a96de7..a2d179a8a9 100644 --- a/COPYING +++ b/COPYING @@ -1,6 +1,6 @@ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the -2-clause BSDL (see the file BSDL), or the conditions below: +2-clause BSDL (see the file BSDL), or the conditions of the Ruby license below: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the ~~~ ## Extract the "conditions below" into "Ruby" license file The "conditions below" text could be extracted into separate file (e.g. "RUBY_LICENSE") and the "COPYING" file rephrased to say: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or Ruby license (see the file RUBY_LICENSE) ~~~ -- https://bugs.ruby-lang.org/

2 4

[ruby-core:111450] [Ruby master Bug#19268] Mingw64 Build Failure
by cfis (Charlie Savage) 31 Dec '24

31 Dec '24

Issue #19268 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #19268: Mingw64 Build Failure https://bugs.ruby-lang.org/issues/19268 * Author: cfis (Charlie Savage) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x64-mingw-ucrt] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- For both Ruby 3.1.3 and Ruby 3.2.0, building on msys2/ucrt64 fails: ``` c linking miniruby.exe /usr/bin/sh: -c: line 1: syntax error near unexpected token `(' /usr/bin/sh: -c: line 1: `/usr/local/ruby/bin/ruby --disable=gems -n -e BEGIN{version=ARGV.shift;mis=ARGV.dup} -e END{abort "UNICODE version mismatch: #{mis}" unless mis.empty?} -e (mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o 15.0.0 ./enc/unicode/15.0.0/casefold.h ./enc/unicode/15.0.0/name2ctype.h' make: *** [uncommon.mk:878: .rbconfig.time] Error 2 ``` The fix that works for me is changing: ``` c -e '(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o' \ ``` To ``` c -e "(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +\"#{Regexp.quote(version)}\"/o" \ ``` ``` -- https://bugs.ruby-lang.org/

1 4

[ruby-core:116009] [Ruby master Bug#20147] FreeBSD libyaml
by kaiquekandykoga 31 Dec '24

31 Dec '24

Issue #20147 has been reported by kaiquekandykoga (Kaíque Koga). ---------------------------------------- Bug #20147: FreeBSD libyaml https://bugs.ruby-lang.org/issues/20147 * Author: kaiquekandykoga (Kaíque Koga) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I use ruby-install to manage multiple Ruby versions. Some time ago I had issues installing Ruby 3.2.2 https://github.com/postmodern/ruby-install/issues/463, and the same issue was open for ruby-build in https://github.com/rbenv/ruby-build/issues/2184. I am trying to install Ruby 3.3.0 using ruby-install, and the same behaviour is occurring. Please, take a look in the links I have provided for detailed information. ``` shell /usr/home/kandy/src/ruby-3.3.0/lib/yaml.rb:3: warning: It seems your ruby installation is missing psych (for YAML output). To eliminate this warning, please install libyaml and reinstall your ruby. uh-oh! RDoc had a problem: cannot load such file -- psych run with --debug for full backtrace *** Error code 1 Stop. make: stopped in /usr/home/kandy/src/ruby-3.3.0 !!! Compiling ruby 3.3.0 failed! ``` Thank you. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:115438] [Ruby master Misc#20013] Travis CI status
by jaruga (Jun Aruga) 23 Dec '24

23 Dec '24

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 49