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

[ruby-core:116892] [Ruby master Misc#20287] DevMeeting before or after RubyKaigi
by duerst 18 Apr '24

18 Apr '24

Issue #20287 has been reported by duerst (Martin Dürst). ---------------------------------------- Misc #20287: DevMeeting before or after RubyKaigi https://bugs.ruby-lang.org/issues/20287 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal ---------------------------------------- RubyKaigi itself runs from May 15-17 (Wed-Fri) in Naha. It would be nice to have a DevMeeting before or afterwards. We should try to plan ahead, so that people can make the right flight and hotel reservations early. I have never been to Okinawa before and don't know any facilities that would be available. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:117147] [Ruby master Feature#20335] `Thread.each_caller_location` should accept the same arguments as `caller` and `caller_locations`
by byroot (Jean Boussier) 17 Apr '24

17 Apr '24

Issue #20335 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20335: `Thread.each_caller_location` should accept the same arguments as `caller` and `caller_locations` https://bugs.ruby-lang.org/issues/20335 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- `Thread.each_caller_location` was added to Ruby 3.2 as part of [Feature #16663] and is a very useful API for emitting warnings with a proper source location and similar use cases. However in many of the cases where I used it, or seen it used, it was needed to skip the first, or a couple frames: Examples: Sorbet: https://github.com/Shopify/sorbet/blob/b27a14c247ace7cabdf0f348bfb11fdf0b7e… ```ruby def self.find_caller skiped_first = false Thread.each_caller_location do |loc| unless skiped_first skiped_first = true next end next if loc.path&.start_with?("<internal:") return loc if yield(loc) end nil end ``` @fxn's PR: https://github.com/ruby/ruby/blob/9c2e686719a5a4df5ea0b8a3b6a373ca6003c229/… ```ruby frames_to_skip = 2 location = nil Thread.each_caller_location do |cl| if frames_to_skip >= 1 frames_to_skip -= 1 next end # snipp... ``` ### Proposal I think it would be very useful if `Thread.each_caller_location` accepted the same arguments as `caller` and `caller_locations`: ```ruby #each_caller_location(start = 1, length = nil) #each_caller_location(range) ``` @jeremyevans0 what do you think? -- https://bugs.ruby-lang.org/

6 12

[ruby-core:115911] [Ruby master Bug#20089] Fiber#kill transfers to root fiber
by rmosolgo (Robert Mosolgo) 17 Apr '24

17 Apr '24

Issue #20089 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #20089: Fiber#kill transfers to root fiber https://bugs.ruby-lang.org/issues/20089 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I was hoping to use `Fiber#kill` to clean up formerly `.transfer`-d Fibers and work around https://bugs.ruby-lang.org/issues/20081, but I found that `Fiber#kill` has a similar control flow jump behavior. Is this on purpose, or a bug? Here's a script to test the behavior: ```ruby manager = Fiber.new do worker = Fiber.new do puts "2. Begin Worker" manager.transfer puts "This should never print -- killed" end puts "1. Transfer to Worker" worker.transfer puts "3. Killing Worker" worker.kill puts "4. Finished manager" end manager.transfer puts "5. Finished script" ``` I expected items `1` through `5` to be printed in order, but in fact, `4` is never printed: ``` $ ruby fiber_transfer_test.rb 1. Transfer to Worker 2. Begin Worker 3. Killing Worker 5. Finished script ``` It seems like `worker.kill` is transferring control to the top-level fiber instead of giving it back to `manager`. I also tried having the thread kill _itself_, hoping it would return to the fiber that originally `.transfer`ed to it, but it also seems to jump out: ```ruby manager = Fiber.new do worker = Fiber.new do puts "2. Begin Worker" manager.transfer Fiber.current.kill puts "This should never print -- killed" end puts "1. Transfer to Worker" worker.transfer puts "3. Killing Worker" worker.transfer puts "4. Finished manager" end manager.transfer puts "5. Finished script" ``` Prints: ``` 1. Transfer to Worker 2. Begin Worker 3. Killing Worker 5. Finished script ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:117225] [Ruby master Feature#20347] Separate docs task from all
by hsbt (Hiroshi SHIBATA) 17 Apr '24

17 Apr '24

Issue #20347 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #20347: Separate docs task from all https://bugs.ruby-lang.org/issues/20347 * Author: hsbt (Hiroshi SHIBATA) * Status: Assigned * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I would like to migrate RDoc as bundled gems at Ruby 3.5. We need to handle `install-doc` and related task with that. I removed `docs` task from `all` and re-order `docs` task at `install-all`. https://github.com/ruby/ruby/pull/10282 It works with RDoc as bundled gems. We can keep current behavior with this migration. I hope to merge changes for `all` task and re-order `install-all` task at Ruby 3.4. https://github.com/ruby/ruby/pull/10282/commits/b160083175aed062c320b8d76ea… After that, the default `make` task will not generate rdoc. We need to add `make all docs` for that. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:117263] [Ruby master Feature#20351] Optionally extract common GC routines into a DSO
by eightbitraptor (Matthew Valentine-House) 16 Apr '24

16 Apr '24

Issue #20351 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Feature #20351: Optionally extract common GC routines into a DSO https://bugs.ruby-lang.org/issues/20351 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open ---------------------------------------- [Github PR#10302](https://github.com/ruby/ruby/pull/10302) **NOTE: This proposal does not change the default build of Ruby, and therefore should NOT cause performance degradation for Ruby built in the usual way** Our long term goal is to standardise Ruby's GC interface, allowing alternative GC implementations to be used. This will be acheived by optionally building Ruby's GC as a shared object; enabling it to be replaced at runtime using using `LD_LIBRARY_PATH`. eg: ``` LD_LIBRARY_PATH=/custom_gc_location ruby script.rb ``` This ticket proposes the first step towards this goal. A new experimental build option, `--enable-shared-gc`, that will compile and link a module into the built `ruby` binary as a shared object - `miniruby` will remain statically linked to the existing GC in all cases. Similar methods of replacing functionality relied on by Ruby have precedent. `jemalloc` uses `LD_PRELOAD` to replace `glibc` provided `malloc` and `free` at runtime. Although this project will be the first time a technique such as this has been used to replace core Ruby functionality. This flag will be marked as experimental & **disabled by default**. [The PR linked from this ticket](https://github.com/ruby/ruby/pull/10302) implements the new build flag, along with the absolute minimum code required to test it's implementation (a single debug function). The implementation of the new build flag is based on the existing implementation of `--enable-shared` and behaves as follows: - `--enable-shared --enable-shared-gc` This will build both `libruby` and `librubygc` as shared objects. `ruby` will link dynamically to both `libruby` and `librubygc`. - `--disable-shared --enable-shared-gc` This will build `librubygc` as a shared object, and build `libruby` as a static object. `libruby` will link dynamically to `librubygc` and `ruby` will be statically linked to `libruby`. - `--disable-shared-gc` **This will be the default**, and when this case is true the build behaviour will be exactly the same as it is currently. ie. the existing Ruby GC will be built and linked statically into either `ruby` or `libruby.so` depending on the state of `--enable-shared`. We are aware that there will be a small performance penalty from moving the GC logic into a shared object, but this is an opt-in configuration turned on at build time intended to be used by experienced users. Still, we anticipate that, even with this configuration turned on, this penalty will be negligible compared the the benefit that being able to use high performance GC algorithms will provide. This performance penalty is also the reason that **this feature will be disabled by default**. There will be no performance impact for anyone compiling Ruby in the usual manner, without explicitly enabling this feature. We have discussed this proposal with @matz who has approved our work on this project - having a clear abstraction between the VM and the GC will enable us to iterate faster on improvements to Ruby's existing GC. ## Motivation In the long term we want to provide the ability to override the current Ruby GC implementation in order to: * Experiment with modern high-performance GC implementations, such as Immix, G1, LXR etc. * Easily split-test changes to the GC, or the GC tuning, in production without having to rebuild Ruby * Easily use debug builds of the GC to help identify production problems and bottlenecks without having to rebuild Ruby * Encourage the academic memory management research community to consider Ruby for their research (the current work on [MMTk & Ruby]() is a good example of this). ## Future work The initial implementation of the shared GC module in this PR is deliberately small, and exists only for testing the build system integration. The next steps are to identify boundaries between the GC and the VM and begin to extract common functionality into this GC wrapper module to serve as the foundation of our GC interface. ## Who's working on this - Matt Valentine-House (@eightbitraptor) - Aaron Patterson (@tenderlove) - Peter Zhu(@peterzhu2118) - Eileen Uchitelle(@eileencodes) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:117347] [Ruby master Bug#20397] The nkf license in LEGAL file seems to be obsolete
by vo.x (Vit Ondruch) 11 Apr '24

11 Apr '24

Issue #20397 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20397: The nkf license in LEGAL file seems to be obsolete https://bugs.ruby-lang.org/issues/20397 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The LEGAL file seems to contain [obsolete information](https://github.com/ruby/ruby/blob/a69f0047cb489c136001937442c1… about nkf license. It seems that nkf indeed use such license, but in upstream, it was first changed to [MIT](https://github.com/nurse/nkf/commit/c12280757bfb275d6f9e6b0bf6293a28b0… and then immediately to [zlib](https://github.com/nurse/nkf/commit/2ed3e1c270f1deb9487f7bc7d7586030f… license. Ruby has picked up that change with commit:git|13313688b243882aff7815598ddd9fcbae69bc17 Maybe @naruse can comment about this. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:117121] [Ruby master Bug#20332] AFter upgrading to ruby v 3.2.3 rb_scan_args() skips argument value
by praveenrocket (Praveen N) 09 Apr '24

09 Apr '24

Issue #20332 has been reported by praveenrocket (Praveen N). ---------------------------------------- Bug #20332: AFter upgrading to ruby v 3.2.3 rb_scan_args() skips argument value https://bugs.ruby-lang.org/issues/20332 * Author: praveenrocket (Praveen N) * Status: Open * ruby -v: 3.2.3 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, Note: I am not an expert at ruby. I am working on ibm_db gem, its an adapter developed using ruby C extension, which helps ruby & rails applications to connect to DB2 database. Here is a github link for its source https://github.com/ibmdb/ruby-ibmdb/tree/master As of now ibm_db gem is compatible with ruby v 3.1. Now I am trying to make ibm_db gem compatible with ruby v 3.2.3. All my test cases were working for ruby v 3.1, but post upgrading to ruby v 3.2.3, most of my test cases are failing. After debugging using gdb what I see is, my ruby test cases calls ruby C extension API passing required arguments, but inside C extension code arguments are not parsed, indeed nothing is read. Because of this most of test cases are failing. Below is a sample ruby script which when run calls ibm_db extension, `$ irb irb(main):001:0> require 'ibm_db' => true irb(main):002:0> conn = IBM_DB.connect("DATABASE=sample;HOSTNAME=waldevdbclnxtst06.dev.rocketsoftware.com;PORT=60000;PROTOCOL=TCPIP;UID=zurbie;PWD=A2m8test;",'','') (irb):2: warning: undefining the allocator of T_DATA class IBM_DB::Connection => #<IBM_DB::Connection:0x00007ff60314ce58> irb(main):003:0> stmt = IBM_DB.exec conn,'create table abc(C1 int)' => false irb(main):004:0> irb(main):005:0> IBM_DB.close(conn) => true irb(main):006:0> exit ` Above, If you observe IBM_DB.exec is called passing two arguments conn & string with create table query. In extension code https://github.com/ibmdb/ruby-ibmdb/blob/master/IBM_DB_Driver/ibm_db.c, below function will be called VALUE ibm_db_exec(int argc, VALUE *argv, VALUE self) { .... rb_scan_args(argc, argv, "21", &connection, &stmt, &options); ...... } Note: Please refer https://github.com/ibmdb/ruby-ibmdb/blob/master/IBM_DB_Driver/ibm_db.c for complete code. rb_scan_args used to parse arguments very well in ruby v 3.1, but now its failing to do so. I see stmt parameter doesnt hold anything. I just want to know whats issue here, Am I passing arguments in wrong way (in ruby script), or am I not using rb_scan_args properly ? To reproduce, Install ruby v 3.2.3, Install ibm_db gem version 5.4.1 (latest) Run above sample ruby script using IRB. Response at earliest is much appreciated. Thanks Praveen -- https://bugs.ruby-lang.org/

2 2

[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