June 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113587] [Ruby master Misc#19684] DevMeeting-2023-06-08
by mame (Yusuke Endoh) 08 Jun '23

08 Jun '23

Issue #19684 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19684: DevMeeting-2023-06-08 https://bugs.ruby-lang.org/issues/19684 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/06/08 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 2023/06/05. 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/

6 5

[ruby-core:113786] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by nobu (Nobuyoshi Nakada) 07 Jun '23

07 Jun '23

Issue #18743 has been updated by nobu (Nobuyoshi Nakada). Your PR makes `stop_exc` to be overwritten for each `StopIteration`. IMO, it should not change and the `cause` of all subsequent `StopIteration`s should be the same first exception. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103434 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113714] [Ruby master Bug#19700] TestProcess#test_execopts_redirect_open_fifo_interrupt_print is flaky on macOS
by kjtsanaktsidis (KJ Tsanaktsidis) 07 Jun '23

07 Jun '23

Issue #19700 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #19700: TestProcess#test_execopts_redirect_open_fifo_interrupt_print is flaky on macOS https://bugs.ruby-lang.org/issues/19700 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The test `TestProcess#test_execopts_redirect_open_fifo_interrupt_print` in `test_process.rb` is flaky on macOS for me. Sometimes, it just hangs forever. This test is testing what happens when: * You have two processes * One is blocked opening a FIFO for reading (to redirect to a child process) * The other one sends a signal to that process * And then opens the FIFO for writing (which should unblock the child process) When this test hangs forever, for me, * The child process is blocked on opening the FIFO (i.e. it's waiting for a writer) * But the parent process successfully wrote data to the FIFO already somehow (this shouldn't be possible - the parent should have been blocked opening the FIFO until the open succeeded in the child). Actually I believe this is a bug in macOS. The following program will fail with `write (parent): Broken pipe` on macOS when run in a loop, but works correctly on Linux: https://gist.github.com/KJTsanaktsidis/fc84b006cfff1bb0b55a2571df825d80 I'm going to open a PR to skip this test on macos because I believe the operating system is broken here, and as far as I can tell Ruby is doing the correct thing. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:113778] [Ruby master Feature#12737] Module#defined_refinements
by shugo (Shugo Maeda) 06 Jun '23

06 Jun '23

Issue #12737 has been updated by shugo (Shugo Maeda). Eregon (Benoit Daloze) wrote in #note-15: > `Refinement#refined_class` is a bit strange given it can return a module. > How about adding `Refinement#refined_module` as an alias for clarity? I'm for it, but it may be better to create another issue. ---------------------------------------- Feature #12737: Module#defined_refinements https://bugs.ruby-lang.org/issues/12737#change-103427 * Author: shugo (Shugo Maeda) * Status: Closed * Priority: Normal * Assignee: shugo (Shugo Maeda) ---------------------------------------- How about to provide Module#defined_refinements, which returns the refinements defined in the receiver as a Hash, as follows: ``` module M refine String do $M_String = self end refine Integer do $M_Integer = self end end p M.defined_refinements #=> {String => $M_String, Integer => $M_Integer} ``` By `Module#defined_refinements`, you can activate refinements globally: ``` for klass, refinement in M.defined_refinements klass.prepend(refinement) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113777] [Ruby master Feature#12737] Module#defined_refinements
by Eregon (Benoit Daloze) 06 Jun '23

06 Jun '23

Issue #12737 has been updated by Eregon (Benoit Daloze). `Refinement#refined_class` is a bit strange given it can return a module. How about adding `Refinement#refined_module` as an alias for clarity? ---------------------------------------- Feature #12737: Module#defined_refinements https://bugs.ruby-lang.org/issues/12737#change-103426 * Author: shugo (Shugo Maeda) * Status: Closed * Priority: Normal * Assignee: shugo (Shugo Maeda) ---------------------------------------- How about to provide Module#defined_refinements, which returns the refinements defined in the receiver as a Hash, as follows: ``` module M refine String do $M_String = self end refine Integer do $M_Integer = self end end p M.defined_refinements #=> {String => $M_String, Integer => $M_Integer} ``` By `Module#defined_refinements`, you can activate refinements globally: ``` for klass, refinement in M.defined_refinements klass.prepend(refinement) end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113773] [Ruby master Bug#19713] Off-by-one error when computing very large Integer numbers
by bannable (Joe Truba) 06 Jun '23

06 Jun '23

Issue #19713 has been reported by bannable (Joe Truba). ---------------------------------------- Bug #19713: Off-by-one error when computing very large Integer numbers https://bugs.ruby-lang.org/issues/19713 * Author: bannable (Joe Truba) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby computes this Elliptic Curve result incorrectly when using Integer operations, but has the correct result when using Rational: ``` a = 154476802108746166441951315019919837485664325669565431700026634898253202035277999 b = 36875131794129999827197811565225474825492979968971970996283137471637224634055579 c = 4373612677928697257861252602371390152816537558161613618621437993378423467772036 int = a / (b + c) + b / (a + c) + c / (a + b) a = a.to_r rational = a / (b + c) + b / (a + c) + c / (a + b) puts [RUBY_VERSION, int == 4, rational == 4].join(' ') ``` Unfortunately, I'm not sure how to minimize this to something simpler than an EC computation. ## Actual ``` ➜ ~ asdf local ruby latest && ruby foo.rb 3.2.1 false true ➜ ~ asdf local ruby 3.1.3 && ruby foo.rb 3.1.3 false true ➜ ~ ``` ## Expected ``` ➜ ~ asdf local ruby latest && ruby foo.rb 3.2.1 true true ➜ ~ asdf local ruby 3.1.3 && ruby foo.rb 3.1.3 true true ➜ ~ ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113770] [Ruby master Feature#19056] Introduce `Fiber.annotation` for attaching messages to fibers.
by ioquatix (Samuel Williams) 05 Jun '23

05 Jun '23

Issue #19056 has been updated by ioquatix (Samuel Williams). I understand your concerns. Every production system I've worked on has some kind of APM, and I've never heard anyone complain about the overhead - it's usually minuscule in comparison to the actual work being done. I'm fine for it to be a gem, but it will limit the application to core libraries. Careful application of such a feature can be incredibly helpful for debugging. One way to mitigate the performance is to use things like `prepend` to inject annotations to existing code. But it's clunky at best. ---------------------------------------- Feature #19056: Introduce `Fiber.annotation` for attaching messages to fibers. https://bugs.ruby-lang.org/issues/19056#change-103420 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- It's useful to know what a fiber is doing especially when they have a temporal execution (i.e. sockets connecting vs connected, binding vs accepting, queue popping, etc) Let's introduce `Fiber.annotate` and `Fiber#annotation` for logging a short message attached to Fibers. ```ruby Fiber.annotate "Counting to 10" 10.times{|I| puts I} # Fiber.current.annotation => "Counting to 10" ``` Pull Request: https://github.com/ruby/ruby/pull/6554 ---Files-------------------------------- clipboard-202210160132-n7lzp.png (865 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113769] [Ruby master Feature#19056] Introduce `Fiber.annotation` for attaching messages to fibers.
by Eregon (Benoit Daloze) 05 Jun '23

05 Jun '23

Issue #19056 has been updated by Eregon (Benoit Daloze). Probably not, but I also think net-http shouldn't use it. There is overhead to e.g. call Addrinfo#inspect (or #to_s) in your screenshot above. Also for such logging to be useful one most likely needs string interpolation, which means string allocations even when the annotations are not used. And non-Fiber users probably have little to no use for those annotations. ---------------------------------------- Feature #19056: Introduce `Fiber.annotation` for attaching messages to fibers. https://bugs.ruby-lang.org/issues/19056#change-103419 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- It's useful to know what a fiber is doing especially when they have a temporal execution (i.e. sockets connecting vs connected, binding vs accepting, queue popping, etc) Let's introduce `Fiber.annotate` and `Fiber#annotation` for logging a short message attached to Fibers. ```ruby Fiber.annotate "Counting to 10" 10.times{|I| puts I} # Fiber.current.annotation => "Counting to 10" ``` Pull Request: https://github.com/ruby/ruby/pull/6554 ---Files-------------------------------- clipboard-202210160132-n7lzp.png (865 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113768] [Ruby master Feature#19056] Introduce `Fiber.annotation` for attaching messages to fibers.
by ioquatix (Samuel Williams) 05 Jun '23

05 Jun '23

Issue #19056 has been updated by ioquatix (Samuel Williams). If it's not in core, can we still use it in `net-http` and other gems like that? ---------------------------------------- Feature #19056: Introduce `Fiber.annotation` for attaching messages to fibers. https://bugs.ruby-lang.org/issues/19056#change-103418 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- It's useful to know what a fiber is doing especially when they have a temporal execution (i.e. sockets connecting vs connected, binding vs accepting, queue popping, etc) Let's introduce `Fiber.annotate` and `Fiber#annotation` for logging a short message attached to Fibers. ```ruby Fiber.annotate "Counting to 10" 10.times{|I| puts I} # Fiber.current.annotation => "Counting to 10" ``` Pull Request: https://github.com/ruby/ruby/pull/6554 ---Files-------------------------------- clipboard-202210160132-n7lzp.png (865 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113767] [Ruby master Feature#19056] Introduce `Fiber.annotation` for attaching messages to fibers.
by Eregon (Benoit Daloze) 05 Jun '23

05 Jun '23

Issue #19056 has been updated by Eregon (Benoit Daloze). Why not use a fiber-local variable for this? Then there is much less risk of conflict between libraries, and of course you can define convenience methods as you like. Or as you implemented it in that gem, as an attribute + `annotate(message) { ... }`. IMO this is good to be in a gem. I don't think it needs to be in core. ---------------------------------------- Feature #19056: Introduce `Fiber.annotation` for attaching messages to fibers. https://bugs.ruby-lang.org/issues/19056#change-103417 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- It's useful to know what a fiber is doing especially when they have a temporal execution (i.e. sockets connecting vs connected, binding vs accepting, queue popping, etc) Let's introduce `Fiber.annotate` and `Fiber#annotation` for logging a short message attached to Fibers. ```ruby Fiber.annotate "Counting to 10" 10.times{|I| puts I} # Fiber.current.annotation => "Counting to 10" ``` Pull Request: https://github.com/ruby/ruby/pull/6554 ---Files-------------------------------- clipboard-202210160132-n7lzp.png (865 KB) -- https://bugs.ruby-lang.org/

1 0