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

[ruby-core:117390] [Ruby master Feature#20404] `2pi`
by mame (Yusuke Endoh) 09 Apr '24

09 Apr '24

Issue #20404 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #20404: `2pi` https://bugs.ruby-lang.org/issues/20404 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- I propose a new Float literal: `2pi`. ```ruby p 2pi #=> 6.283185307179586 == 2 * Math::PI ``` I am not proposing `1pi`, `3pi` or `4pi`. I do only `2pi`. Because in most cases, all you need is `2pi`. Any other multiple of pi is rarely needed. I've got the statistics. GitHub code search revealed that more than 80% of the occurrences of `n * Math::PI` and `Math::PI * n` had n = 2. [1] | n |`n * Math::PI`|`Math::PI * n`|sum | % | |--:|-------------:|-------------:|----:|---:| | 0 | 48| 1| 49|1.4%| | 1 | 58| 3| 61|1.7%| | 2 | 2300| 534| 2834|80.4%| | 3 | 218| 17| 235|6.7%| | 4 | 200| 23| 223|6.3%| | 5 | 24| 2| 26|0.7%| | 6 | 41| 3| 44|1.2%| | 7 | 14| 0| 14|0.4%| | 8 | 6| 2| 8|0.2%| | 9 | 8| 0| 8|0.2%| |10 | 17| 0| 17|0.5%| |11 | 2| 0| 2|0.1%| |12 | 2| 0| 2|0.1%| Here is the PIe chart ![](https://gist.github.com/assets/21557/1c077af3-f753-4ee1-bc75-5b38a3bd6487) I know that a new constant name "Tau" is proposed (#4897, #17496). But notice: "2pi" and "Tau" have the same number of characters. Then, it is obvious that familiarity is better. In fact, `2 * Math::PI` is 4 times more than `Math::PI * 2`, indicating that all programmers are copying "2pi" in their textbook. The idea of 2pi came up regularly in chats among committers. The discussion quickly shifted to its generalization: should we treat `3e` as `3 * Math::E`, or even `42foo` as `42 * foo`? However, I noticed such a generalization is unnecessary because all we need is 2pi. Unneeded generalization is evil. Here is a patch. ```diff diff --git a/parse.y b/parse.y index 55619273b8..93b16a16ac 100644 --- a/parse.y +++ b/parse.y @@ -10208,6 +10208,13 @@ parse_numeric(struct parser_params *p, int c) return set_number_literal(p, tINTEGER, suffix, 10, 0); } } + else if (c == '2' && peek(p, 'p') && peek_n(p, 'i', 1)) { + tokadd(p, c); + tokadd(p, nextc(p)); + tokadd(p, nextc(p)); + tokfix(p); + return set_number_literal(p, tFLOAT, 0, 0, 0); + } for (;;) { switch (c) { diff --git a/ruby_parser.c b/ruby_parser.c index 6d85a72c5b..3a6e0b5704 100644 --- a/ruby_parser.c +++ b/ruby_parser.c @@ -936,6 +936,9 @@ VALUE rb_node_float_literal_val(const NODE *n) { const rb_node_float_t *node = RNODE_FLOAT(n); + if (strcmp(node->val, "2pi") == 0) { + return DBL2NUM(2 * M_PI); + } double d = strtod(node->val, 0); if (node->minus) { d = -d; P I Happy a r l fool ``` [1] I used these queries: [`/[^.]\b2 ?\* ?Math::PI/ language:Ruby`](https://github.com/search?type=code&q=%2F%5B%5E.%5D%5Cb2+%3… and [`/Math::PI *\* *2\b *[^.\/]/ language:Ruby`](https://github.com/search?type=code&q=%2FMath%3A%3API+*%5C*… -- https://bugs.ruby-lang.org/

7 8

[ruby-core:117034] [Ruby master Misc#20320] Using OSU Open Source Lab native ppc64le/s390x CI services trigged on pull-requests
by jaruga (Jun Aruga) 08 Apr '24

08 Apr '24

Issue #20320 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20320: Using OSU Open Source Lab native ppc64le/s390x CI services trigged on pull-requests https://bugs.ruby-lang.org/issues/20320 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- We have been using Travis CI to run unit tests the native arm64/ppc64le/s390x in the ruby/ruby, ruby/zlib and ruby/prism repositories in the Ruby project. One of the challenges is Travis CI's chronic unstable infra issues. To be fair, folks at Travis CI support are helpful, usually responding quickly, sometimes not. And I hope Travis CI will find the root causes of the issues. However, I would like to find alternative way to run the native ppc64le/s390x pipelines on pull-requests to change the current challenge fundamentally. And I heard from folks at IBM that the there were CI services that we could run on the pull-requests. The CI services are Jenkins services provided by Oregon State University (OSU) Open Source Lab below. The CI services are the only alternative of running the native ppc64le/s390x pipelines on pull-requests as far as I know. As a note, we are already using SSH-accessing servers provided by OSU Open Source Lab. * PowerPC64 (ppc64le): https://osuosl.org/services/powerdev/ - POWER Continuous Integration (POWER CI) * IBM Z (s390x): https://osuosl.org/services/ibm-z/ - IBM Z Continuous Integration (IBM Z CI) Today I requested the CI services from the request form pages above. And I will try the services by myself first. Then if it looks good to us, I want to migrate the Travis CI ppc64le/s390x pipelines to the OSU Open Source Lab's ones. I will comment on this ticket when there are updates. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:115649] [Ruby master Bug#20050] Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
by martinemde (Martin Emde) 08 Apr '24

08 Apr '24

Issue #20050 has been reported by martinemde (Martin Emde). ---------------------------------------- Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash) https://bugs.ruby-lang.org/issues/20050 * Author: martinemde (Martin Emde) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi, In the rubygems & bundler repositories we've now had two segfaults in the same exact code within days of merging a change to that code, both on ruby 3.2.2 on darwin20. 1. https://github.com/rubygems/rubygems/actions/runs/7110489973/job/1935706778… 2. https://github.com/rubygems/rubygems/actions/runs/7131889001/job/1942130416… The specific error seems to happen when calculating the hash of the array in Gem::NameTuple#hash. The array contents that is being `.hash`ed both times should be exactly: `["has_metadata", "1.0", "ruby"]`. If I'm reading this correctly, this indicates that the crash is related either to creating this hash or storing this hash in the hash table (I'm not quite sure which is triggering the crash). An excerpt of the C backtrace shows the same backtrace for both crashes: ``` -- C level backtrace information ------------------------------------------- /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_bugreport+0x7c4) [0x10cb0f994] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x1d0) [0x10c9158c0] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(sigsegv+0x5b) [0x10ca609ab] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff810c14dfd] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_id_table_lookup+0x16) [0x10caa2a56] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(callable_method_entry_or_negative+0x5e) [0x10cae9c8e] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_check_funcall_basic_kw+0x129) [0x10caf0039] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(obj_any_hash+0x3c) [0x10c94bd2c] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(any_hash+0x52) [0x10c94bc12] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_st_add_direct+0x1d) [0x10ca69b7d] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ar_try_convert_table+0x85) [0x10c94d015] /Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_hash_aset+0x18f) [0x10c94e26f] ``` I'm not sure how to follow this instruction in this case on GitHub actions: "Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports." I have not been able to reproduce this locally with the same version of ruby (but I'm on darwin22 instead of 20). I will follow up if we continue to see this same crash. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:115952] [Ruby master Bug#20102] Introduce `Fiber#resuming?`
by ioquatix (Samuel Williams) 07 Apr '24

07 Apr '24

Issue #20102 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20102: Introduce `Fiber#resuming?` https://bugs.ruby-lang.org/issues/20102 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- There are some tricky edge cases when using `Fibre#raise` and `Fiber#kill`, e.g. ```ruby fiber = nil killer = Fiber.new do fiber.raise("Stop") end fiber = Fiber.new do killer.resume end fiber.resume # 4:in `raise': attempt to raise a resuming fiber (FiberError) # 4:in `block in <main>' ``` Async has to deal with this edge case explicitly by rescuing the exception: https://github.com/socketry/async/blob/ffd019d9c1d547926a28fe8f36bf7bfe91d8… I'd like to avoid doing that and instead just ask "Can I kill/raise on this fiber right now?" which is determined by whether the fiber itself can be resumed or transferred to. To address this, I'd like to introduce `Fiber#resuming?`: ```c /* * call-seq: fiber.resumed? -> true or false * * Whether the fiber is currently resumed. */ VALUE rb_fiber_resuming_p(VALUE fiber_value) { struct rb_fiber_struct *fiber = fiber_ptr(fiber_value); if (FIBER_TERMINATED_P(fiber)) return RUBY_Qfalse; return RBOOL(fiber->resuming_fiber); } ``` See the PR: https://github.com/ruby/ruby/pull/9382 -- https://bugs.ruby-lang.org/

3 6

[ruby-core:117071] [Ruby master Bug#20327] Time.new behaves differently when passing a zone as timezone object
by davekaro (Dave Kroondyk) 07 Apr '24

07 Apr '24

Issue #20327 has been reported by davekaro (Dave Kroondyk). ---------------------------------------- Bug #20327: Time.new behaves differently when passing a zone as timezone object https://bugs.ruby-lang.org/issues/20327 * Author: davekaro (Dave Kroondyk) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Time.new with a timezone object for the zone argument produces incorrect utc_offset when passing seconds as a Rational. ``` ruby require "tzinfo" # This correctly outputs 0 as the utc_offset puts Time.new(2024, 1, 1, 23, 59, 59.9r, "UTC").utc_offset # => 0 # Inspecting the time looks correct puts Time.new(2024, 1, 1, 23, 59, 59.9r, "UTC").inspect # => "2024-01-01 23:59:59.9 UTC" # Using a timezone object for the zone, results are different puts Time.new(2024, 1, 1, 23, 59, 59.9r, TZInfo::Timezone.get("Etc/UTC")).utc_offset # => (9/10) # Inspecting the time object reveals the odd offset puts Time.new(2024, 1, 1, 23, 59, 59.9r, TZInfo::Timezone.get("Etc/UTC")).inspect # => "2024-01-01 23:59:59.9 +000001" ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113195] [Ruby master Bug#19592] Unable to statically link a single extension in 3.2.x and >3.1.4
by npic1 (Nat Pic1) 07 Apr '24

07 Apr '24

Issue #19592 has been reported by npic1 (Nat Pic1). ---------------------------------------- Bug #19592: Unable to statically link a single extension in 3.2.x and >3.1.4 https://bugs.ruby-lang.org/issues/19592 * Author: npic1 (Nat Pic1) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi, I need to statically link a single extension (not all of them) by adding it to ext/Setup. This worked until version 3.1.4 and 3.2.x. It appears that this change broke it: [https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/79… [https://github.com/ruby/ruby/pull/6756](https://github.com/ruby/ruby/pull/6…. I have attached a script to reproduce the issue. When running the script, `ldd` fails with: ``` ext/extinit.o: in function `Init_ext': extinit.c:(.text+0x10): undefined reference to `ruby_init_ext' ``` ---Files-------------------------------- ruby_static_test.sh (1.57 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115831] [Ruby master Bug#20076] M:N scheduler crashes on macOS with RUBY_MN_THREADS=1
by hsbt (Hiroshi SHIBATA) 03 Apr '24

03 Apr '24

Issue #20076 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20076: M:N scheduler crashes on macOS with RUBY_MN_THREADS=1 https://bugs.ruby-lang.org/issues/20076 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This is known issue. I already shared this to ko1. The version of https://github.com/ruby/ruby/commit/28e3886689c71b22487dd5d0cb62f3b5ed0a77cc is crashed with `make exam`. This is happend with webrick test on `make test-tool`. My environment is macOS Sonoma 14.3 beta1 and ``` $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 15.1.0.0.1.1700200546 volume: / location: / install-time: 1702331495 ``` -- https://bugs.ruby-lang.org/

2 6

[ruby-core:116534] [Ruby master Bug#20231] Don't wait in io_binwrite_string if not necessary.
by ioquatix (Samuel Williams) 01 Apr '24

01 Apr '24

Issue #20231 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20231: Don't wait in io_binwrite_string if not necessary. https://bugs.ruby-lang.org/issues/20231 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- PR: https://github.com/ruby/ruby/pull/9792 Writing to a buffered IO can result in the entire internal buffer being flushed, which causes `io_binwrite_string_internal` to return 0. In that case, we were setting `errno = EAGAIN`. This causes `rb_io_maybe_wait_writable` to be invoked, however we should immediately retry `io_binwrite_string_internal` instead. The reason why calling `rb_io_maybe_wait_writable` is a bad idea in general, is that not all IO can go via this mechanism in every situation - in other words, `kqueue` does not support `kevent("/dev/null", writable)` and returns errno=22 `EINVAL`. The same applies to some kinds of pipes, TTYs, etc. Indirectly responsible for <https://github.com/socketry/async/issues/301>. -- https://bugs.ruby-lang.org/

3 7

[ruby-core:117388] [Ruby master Bug#20403] TestResolvDNS#test_query_ipv4_address_truncated_tcp_fallback can flake if TCP port is in use
by kjtsanaktsidis (KJ Tsanaktsidis) 31 Mar '24

31 Mar '24

Issue #20403 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20403: TestResolvDNS#test_query_ipv4_address_truncated_tcp_fallback can flake if TCP port is in use https://bugs.ruby-lang.org/issues/20403 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The test TestResolvDNS#test_query_ipv4_address_truncated_tcp_fallback wants to make a TCP and UDP DNS server on the same port. It achieves this by binding to a random UDP port (with `:0`), and then trying to bind to that TCP port. However, just because the UDP port was free, does not mean the TCP port was, so this can fail. This leads to test failures like this one: https://github.com/ruby/ruby/actions/runs/8497267556/job/23275642160 ``` 1) Error: TestResolvDNS#test_query_ipv4_address_truncated_tcp_fallback: Errno::EACCES: Permission denied - bind(2) for "127.0.0.1" port 49701 D:/a/ruby/ruby/src/test/resolv/test_dns.rb:48:in 'TCPServer#initialize' D:/a/ruby/ruby/src/test/resolv/test_dns.rb:48:in 'IO.new' D:/a/ruby/ruby/src/test/resolv/test_dns.rb:48:in 'TestResolvDNS#with_tcp' D:/a/ruby/ruby/src/test/resolv/test_dns.rb:181:in 'block in TestResolvDNS#test_query_ipv4_address_truncated_tcp_fallback' D:/a/ruby/ruby/src/test/resolv/test_dns.rb:61:in 'TestResolvDNS#with_udp' D:/a/ruby/ruby/src/test/resolv/test_dns.rb:179:in 'TestResolvDNS#test_query_ipv4_address_truncated_tcp_fallback' Finished tests in 401.425882s, 64.4851 tests/s, 15534.2649 assertions/s. 25886 tests, 6235856 assertions, 0 failures, 1 errors, 502 skips ``` (note - it's EACCESS, not EADDRINUSE, because of this issue on Windows, I think: https://stackoverflow.com/questions/48478869/cannot-bind-to-some-ports-due-…) -- https://bugs.ruby-lang.org/

1 2

[ruby-core:116622] [Ruby master Bug#20245] Crash when checking symbol encoding
by peterzhu2118 (Peter Zhu) 31 Mar '24

31 Mar '24

Issue #20245 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #20245: Crash when checking symbol encoding https://bugs.ruby-lang.org/issues/20245 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/9871 We sometimes pass in a fake string to sym_check_asciionly. This can crash if sym_check_asciionly raises because it creates a CFP with the fake string as the receiver which will crash if GC tries to mark the CFP. For example, the following script crashes: ```ruby GC.stress = true Object.const_defined?("\xC3") ``` -- https://bugs.ruby-lang.org/

3 2