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

[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:117443] [Ruby master Misc#20410] Backport fix for #19592 to ruby 3.2
by npic1 (Nat Pic1) 05 Apr '24

05 Apr '24

Issue #20410 has been reported by npic1 (Nat Pic1). ---------------------------------------- Misc #20410: Backport fix for #19592 to ruby 3.2 https://bugs.ruby-lang.org/issues/20410 * Author: npic1 (Nat Pic1) * Status: Open ---------------------------------------- Is it possible to backport the fix for this issue in older Ruby versions like 3.2? https://bugs.ruby-lang.org/issues/19592 Thanks -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117408] [Ruby master Misc#20406] Question about Regexp encoding negotiation
by andrykonchin (Andrew Konchin) 04 Apr '24

04 Apr '24

Issue #20406 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Misc #20406: Question about Regexp encoding negotiation https://bugs.ruby-lang.org/issues/20406 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- I am wondering what are the rules to calculate Regexp literal encoding in case an encoding modifier is specified. 1. From the documentstion: > By default, a regexp with only US-ASCII characters has US-ASCII encoding: > ... > A regular expression containing non-US-ASCII characters is assumed to use the source encoding. This can be overridden with one of the following modifiers. > //n ... > //u ... > //e ... > //s ... Looking at the following examples I would assume that these rules are followed except one case: ```ruby p /\xc2\xa1/e .encoding # EUC-JP p /#{ }\xc2\xa1/e .encoding # EUC-JP p /a/e .encoding # EUC-JP p /a #{} a/e .encoding # EUC-JP p /#{} a/e .encoding # US-ASCII ``` The last Regexp `/#{} a/e` is supposed to have `EUC-JP` encoding but has `US-ASCII`. So I am wondering what rule is applied in this case. 2. In case of interpolated Regexp with encoding modifier I suppose there is no any encoding negotiation as far as if a Regexp fragment's encoding doesn't match a fixed encoding a SyntaxError is raised. Is this assumption correct? ```ruby /#{ "фв" } a/e # regexp encoding option 'e' differs from source encoding 'UTF-8' (SyntaxError) ``` -- https://bugs.ruby-lang.org/

4 6

[ruby-core:117432] [Ruby master Feature#20408] Add heap_live_slots to GC.stat_heap
by mk 04 Apr '24

04 Apr '24

Issue #20408 has been reported by mk (Matthias Käppler). ---------------------------------------- Feature #20408: Add heap_live_slots to GC.stat_heap https://bugs.ruby-lang.org/issues/20408 * Author: mk (Matthias Käppler) * Status: Open ---------------------------------------- `GC.stat` exposes a `heap_live_slots` metric that returns the number of live objects occupying eden slots. Because the slot size was fixed to `RVALUE_SIZE`, this allowed for some basic approximations of how many bytes were live/in-use (`heap_live_slots * RVALUE_SIZE`). This could furthermore be "embellished" by adding malloc'ed memory for those objects that were larger than a 40B slot (we track this via a custom CRuby patch). However, with the addition of Variable Width Allocations (https://bugs.ruby-lang.org/issues/18239) this does not work anymore because we don't know how `heap_live_slots` distributes over all pools that use different slot sizes. This could be addressed by also adding `heap_live_slots` (and for symmetry: `heap_free_slots`) to `GC.stat_heap`. The sum of all live slots per pool times its respective slot size should equal `GC.stat[:heap_live_slots]`. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117438] [Ruby master Feature#18459] IRB autocomplete dropdown colour options
by hsbt (Hiroshi SHIBATA) 04 Apr '24

04 Apr '24

Issue #18459 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed https://github.com/ruby/reline/pull/552 fixed this issue. ---------------------------------------- Feature #18459: IRB autocomplete dropdown colour options https://bugs.ruby-lang.org/issues/18459#change-107814 * Author: johansenjaa (Joseph Johansen) * Status: Closed * Assignee: aycabta (aycabta .) ---------------------------------------- It would be great to be able to specify bg/fg colours for the new autocomplete dropdown in irb in ruby 3.1. This could help for accessibility purposes, or for anyone who just wants to make it look more personalised for their terminal 😎 Perhaps irbrc could do the trick? ```ruby IRB.conf[:AUTOCOMPLETE] = { BG_COLOR: 0, FG_COLOR: 15, } ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117425] [Ruby master Feature#4831] Integer#prime_factors
by hsbt (Hiroshi SHIBATA) 03 Apr '24

03 Apr '24

Issue #4831 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed prime is already extracted from ruby repository to https://github.com/ruby/prime. We should move to its place. ---------------------------------------- Feature #4831: Integer#prime_factors https://bugs.ruby-lang.org/issues/4831#change-107800 * Author: mame (Yusuke Endoh) * Status: Closed * Assignee: yugui (Yuki Sonoda) ---------------------------------------- Hello, lib/prime provides Integer#prime_division, but I always forget the name. I think that #prime_factors is more suitable. I'd like to hear opinions of English natives. What do you think? -- Yusuke Endoh <mame(a)tsg.ne.jp> -- https://bugs.ruby-lang.org/

1 0