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

[ruby-core:113908] [Ruby master Bug#19732] Possible missing header (stdint.h) in event.h
by itarato (Peter Arato) 16 Jun '23

16 Jun '23

Issue #19732 has been reported by itarato (Peter Arato). ---------------------------------------- Bug #19732: Possible missing header (stdint.h) in event.h https://bugs.ruby-lang.org/issues/19732 * Author: itarato (Peter Arato) * Status: Open * Priority: Normal * ruby -v: HEAD * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby's event.h (https://github.com/ruby/ruby/blob/813a5f4fc46a24ca1695d23c159250b9e1080ac7/…) is using type aliases from stdint.h, however it's not directly included. An example where this causes issues is when using `rb_debug_inspector_current_depth()` https://github.com/ruby/ruby/blob/813a5f4fc46a24ca1695d23c159250b9e1080ac7/…. In a gem using a C-extension that already includes `debug.h`, when adding the call `rb_debug_inspector_current_depth()`, the compilation fails with: ``` shell make compiling debug_inspector.c In file included from /home/itarato/.rubies/ruby-master/include/ruby-3.3.0+0/ruby/debug.h:16, from debug_inspector.c:12: /home/itarato/.rubies/ruby-master/include/ruby-3.3.0+0/ruby/internal/event.h:105:9: error: unknown type name ‘uint32_t’ 105 | typedef uint32_t rb_event_flag_t; | ^~~~~~~~ ``` This is on `ruby/ruby` latest commit (813a5f4fc46a24ca1695d23c159250b9e1080ac7), but also tried on tag 3.2 (same error). I've also proposed a fix: https://github.com/ruby/ruby/pull/7945 -- https://bugs.ruby-lang.org/

2 5

[ruby-core:113918] [Ruby master Bug#15428] Refactor Proc#>> and #<<
by Dan0042 (Daniel DeLorme) 16 Jun '23

16 Jun '23

Issue #15428 has been updated by Dan0042 (Daniel DeLorme). Maybe it was already obvious to everyone, but I feel that something important has not been mentioned in this discussion: `(a >> b).call(x)` is equivalent to `b.call(a.call(x))` but **neither a nor b needs to be a Proc**. Either could be a Method, for example. So coercing the argument to Proc is neither needed nor desirable. In the same way that `"" + 2` is a TypeError because `2` is not implicitly converted, `myproc >> :symbol` is a TypeError because `:symbol` is not implicitly converted. That's fully consistent with Ruby as a strongly typed language. I think the proper solution here is `JSON.:parse >> .:symbolize_keys` ... we need to resurrect #12125 and #16264 but with better syntax and a more complete picture around FP. ---------------------------------------- Bug #15428: Refactor Proc#>> and #<< https://bugs.ruby-lang.org/issues/15428#change-103571 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- #6284 introduced `Proc#>>` and `Proc#<<`, but the requirements to the argument is totally inconsistent with ANY other place in Ruby. Currently, it is the **only** place in Ruby where coercing argument to `Proc` is done with `#call` method. Everywhere else it is done with `#to_proc`, and `#call` method never had any special significance except for `.()` sugar. I believe there are two possible actions: 1. change `#>>` and `#<<` to use `#to_proc` (which will give Symbols composability for free), **or, alternatively** 2. state that `#call` from now on has a special meaning in Ruby and probably decide on other APIs that should respect it (for example, auto-define `#to_proc` on any object that has `#call`) Either is OK, the current situation is not. PS: One more problem (that probably should be discussed separately) is that check for `#call` existence is performed pretty late, which can lead to this kind of errors: ```ruby # At code loading time: # I erroneously thought this is correct. It is not, but the line would perform without # any error. PROCESSOR = JSON.method(:parse) >> :symbolize_keys # Later, in runtime: '{"foo": "bar"}'.then(&PROCESSOR) # NoMethodError (undefined method `call' for :symbolize_keys:Symbol) ``` **UPD 2018-12-29:** As this ticket was ignored prior to 2.6 release, I rewrote it in an "actionable" instead of "question" manner. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113936] Re: ruby/ruby Cirrus CI improvement
by Jun Aruga (he / him) 15 Jun '23

15 Jun '23

Hi Febor, Thank you for your help and investigation! It seems your email was not sent to the ruby-core(a)ruby-lang.org mailing list, as the setting of the mailing list only accepts the email from a subscribed person. So, I reply with your email message. > ... Right now it only uses 1 core: This can be improved in our Cirrus CI configuration file. > On a side, within the next week or two we are planning to migrate from Graviton 2 CPUs to more performant offering of Ampere CPUs on Google Cloud. I see. We observed the following Cirrus CI didn't start even after 1 hour. Do you know the reason? https://cirrus-ci.com/build/5470471567704064 I hope that this will be improved after the migration. Jun Aruga On Mon, Jun 12, 2023 at 3:33 PM Fedor Korotkov <fedor(a)cirruslabs.org> wrote: > Hey Jun, > > I was just writing a response when you followed up. :-) > > As far as the configuration, we don't see anything suspicious in it. The > only thing that might be improved is making compilation utilize all the > cores. Right now it only uses 1 core: > > [image: Screenshot 2023-06-12 at 9.24.09 AM.png] > > As for the clang performance, we don't have any insights. From the graphs > it just seems to be working slower than your gcc variant. > > On a side, within the next week or two we are planning to migrate from > Graviton 2 CPUs to more performant offering of Ampere CPUs on Google Cloud. > > On Mon, Jun 12, 2023 at 9:22 AM Jun Aruga (he / him) <jaruga(a)redhat.com> > wrote: > >> Dear Cirrus CI customer support, >> >> Thank you for helping us (Ruby project)! >> Could you check the following message about the issue in Cirrus CI in >> the Ruby project? >> >> I noticed sending an email to the customer support email is better >> than sending an email to a person's email. So, I am sending the >> message to the support email again. >> Long story short, we see Cirrus CI is unstable in our cases (running 4 >> cases in Arm), and we want your advice for our .cirrus.yml file to >> fill our needs. >> >> https://cirrus-ci.org/support/ >> > The best way to ask general questions about particular use cases is to >> email our support team at support+ci(a)cirruslabs.org. Our support team is >> trying our best to respond ASAP, but there is no guarantee on a response >> time unless your organization enrolls in Priority Support. >> >> Kind regards, >> Jun >> >> On Fri, Jun 9, 2023 at 12:57 PM Jun Aruga (he / him) <jaruga(a)redhat.com> >> wrote: >> > >> > Hello Fedor @ Cirrus CI, >> > CC: Ruby Core mailing list. >> > >> > Thank you for helping the Ruby project for adding Cirrus CI. I am >> > sending an email to ask you for help to improve the Cirrus CI. We are >> > running 4 parallel jobs (2 gcc cases ARM, 2 clang cases ARM) in the >> > Cirrus CI. >> > However, I am seeing some challenges such as the queue is stopping, >> > and the clang cases are 2 or 3 times slower than gcc cases. So, today >> > we stopped the 2 clang cases in a compromised way. >> > >> > Could you check our .cirrus.yml file on the reverted commit, and give >> > advice to us and ideally just send a pull-request to the master branch >> > for that? >> > >> > https://github.com/ruby/ruby/blob/master/.cirrus.yml >> > >> > ``` >> > $ git clone https://github.com/ruby/ruby.git >> > $ cd ruby >> > $ git revert 72f07f0a5f882e87e305d668587152fa209a0568. >> > ``` >> > >> > I suspect the current `cpu:` value might not be correct. And we may >> > need the following change. >> > >> > ``` >> > diff --git a/.cirrus.yml b/.cirrus.yml >> > index be76e4ab4a..8b820be1a2 100644 >> > --- a/.cirrus.yml >> > +++ b/.cirrus.yml >> > @@ -16,10 +16,10 @@ task: >> > image: ghcr.io/ruby/ruby-ci-image:$CC >> > # Define the used cpu core in each matrix task. We can use total >> 16 cpu >> > # cores in entire matrix. [cpu] = [total cpu: 16] / [number of >> tasks] >> > - cpu: 8 >> > + cpu: 4 >> > # We can request maximum 4 GB per cpu. >> > # [memory per task] = [memory per cpu: 4 GB] * [cpu] >> > - memory: 32G >> > + memory: 16G >> > env: >> > CIRRUS_CLONE_DEPTH: 50 >> > optflags: '-O1' >> > @@ -71,10 +71,10 @@ yjit_task: >> > image: ghcr.io/ruby/ruby-ci-image:$CC >> > # Define the used cpu core in each matrix task. We can use total >> 16 cpu >> > # cores in entire matrix. [cpu] = [total cpu: 16] / [number of >> tasks] >> > - cpu: 8 >> > + cpu: 4 >> > # We can request maximum 4 GB per cpu. >> > # [memory per task] = [memory per cpu: 4 GB] * [cpu] >> > - memory: 32G >> > + memory: 16G >> > env: >> > CIRRUS_CLONE_DEPTH: 50 >> > optflags: '-O1' >> > ``` >> > >> > Thank you for your help! >> > >> > -- >> > Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic >> > See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for >> > the timezone. >> >> -- >> Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic >> See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for >> the timezone. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Support" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to support+unsubscribe(a)cirruslabs.org. >> To view this discussion on the web visit >> https://groups.google.com/a/cirruslabs.org/d/msgid/support/CAHE_3CiT_59xrbU… >> . >> > > > -- > > Fedor Korotkov > > Founder at *Cirrus Labs* > > @fedor <https://twitter.com/fedor> > -- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for the timezone.

1 0

[ruby-core:113910] [Ruby master Bug#19733] Kernel#Rational does not accept prefix 0
by sawa (Tsuyoshi Sawada) 15 Jun '23

15 Jun '23

Issue #19733 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Bug #19733: Kernel#Rational does not accept prefix 0 https://bugs.ruby-lang.org/issues/19733 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- `Integer` and `Rational` literals accept prefix `0`. There is no difference in this respect. ```ruby 0b10 # => 2 0b10r # => (2/1) ``` However, when it comes to `Kernel#Integer` and `Kernel#Rational`, the former accept prefix `0` while the latter does not. This is confusing. And as I do not see any reason they should behave differently, I think it is a bug. ```ruby Integer("0b10") # => 2 Rational("0b10") # !> ArgumentError ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113895] [Ruby master Bug#19728] Automate (checking of) Regexp character property documentation
by duerst 14 Jun '23

14 Jun '23

Issue #19728 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #19728: Automate (checking of) Regexp character property documentation https://bugs.ruby-lang.org/issues/19728 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This came up in a discussion at https://github.com/ruby/ruby/pull/7923. The documentation at doc/regexp.rdoc currently contains a list of character properties that can be used in regular expressions. But there is no guarantee that this list is updated when the Unicode version is updated. One idea is to create a ruby equivalent of https://github.com/k-takata/Onigmo/blob/master/tool/update-doc.py. Another idea is to just write a test that checks enc/unicode/$UNICODE_VERSION/name2ctype.h against the relevant part of the documentation file. This might make it easier for the documentation to be rewritten while guaranteeing that no properties get forgotten. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113905] [Ruby master Bug#15428] Refactor Proc#>> and #<<
by matz (Yukihiro Matsumoto) 14 Jun '23

14 Jun '23

Issue #15428 has been updated by matz (Yukihiro Matsumoto). I don't feel this proposed extension readable (than explicit one). Is there any example of readable usage of this notation? Matz. ---------------------------------------- Bug #15428: Refactor Proc#>> and #<< https://bugs.ruby-lang.org/issues/15428#change-103557 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- #6284 introduced `Proc#>>` and `Proc#<<`, but the requirements to the argument is totally inconsistent with ANY other place in Ruby. Currently, it is the **only** place in Ruby where coercing argument to `Proc` is done with `#call` method. Everywhere else it is done with `#to_proc`, and `#call` method never had any special significance except for `.()` sugar. I believe there are two possible actions: 1. change `#>>` and `#<<` to use `#to_proc` (which will give Symbols composability for free), **or, alternatively** 2. state that `#call` from now on has a special meaning in Ruby and probably decide on other APIs that should respect it (for example, auto-define `#to_proc` on any object that has `#call`) Either is OK, the current situation is not. PS: One more problem (that probably should be discussed separately) is that check for `#call` existence is performed pretty late, which can lead to this kind of errors: ```ruby # At code loading time: # I erroneously thought this is correct. It is not, but the line would perform without # any error. PROCESSOR = JSON.method(:parse) >> :symbolize_keys # Later, in runtime: '{"foo": "bar"}'.then(&PROCESSOR) # NoMethodError (undefined method `call' for :symbolize_keys:Symbol) ``` **UPD 2018-12-29:** As this ticket was ignored prior to 2.6 release, I rewrote it in an "actionable" instead of "question" manner. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113903] [Ruby master Bug#19731] Can’t call an instance method inside an Endless method definition
by ttanimichi (Tsukuru Tanimichi) 14 Jun '23

14 Jun '23

Issue #19731 has been reported by ttanimichi (Tsukuru Tanimichi). ---------------------------------------- Bug #19731: Can’t call an instance method inside an Endless method definition https://bugs.ruby-lang.org/issues/19731 * Author: ttanimichi (Tsukuru Tanimichi) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Can’t call an instance method inside an Endless method definition. ``` $ ruby -v ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22] $ cat withend.rb class A def show puts 'ok' if params end def params 42 end end A.new.show $ ruby withend.rb ok $ cat endless.rb class A def show = puts 'ok' if params def params 42 end end A.new.show $ ruby endless.rb endless.rb:2:in `<class:A>': undefined local variable or method `params' for A:Class (NameError) def show = puts 'ok' if params ^^^^^^ from endless.rb:1:in `<main>' exit status: 1 ``` But, the example below works fine. Is this an expected behavior? ``` $ cat endless2.rb class A def show = puts params def params 42 end end A.new.show $ ruby endless2.rb 42 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113781] [Ruby master Bug#19715] Coverage oneshot_lines mode is not working after result clear
by ngan (Ngan Pham) 13 Jun '23

13 Jun '23

Issue #19715 has been reported by ngan (Ngan Pham). ---------------------------------------- Bug #19715: Coverage oneshot_lines mode is not working after result clear https://bugs.ruby-lang.org/issues/19715 * Author: ngan (Ngan Pham) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Given a simple Ruby file (`foo.rb`): ```ruby def hello puts "hello" end ``` If I do the following in `irb`, I get unexpected results: ``` irb(main):001:0> require 'coverage' irb(main):002:0> Coverage.setup(oneshot_lines: true) => nil irb(main):003:0> require_relative 'foo' => true irb(main):004:0> Coverage.resume => nil irb(main):005:0> hello hello => nil irb(main):006:0> Coverage.suspend => nil irb(main):007:0> Coverage.result(stop: false, clear: true) => {"/project/foo.rb"=>{:oneshot_lines=>[2]}} irb(main):008:0> Coverage.resume => nil irb(main):009:0> Coverage.suspend => nil irb(main):010:0> Coverage.result(stop: false, clear: true) => {"/project/foo.rb"=>{:oneshot_lines=>[]}} irb(main):011:0> Coverage.resume => nil irb(main):012:0> hello hello => nil irb(main):013:0> Coverage.suspend => nil irb(main):014:0> Coverage.result(stop: false, clear: true) => {"/project/foo.rb"=>{:oneshot_lines=>[]}} ``` You can see that in the third `Coverage.result` call, oneshot_lines did not populate despite me executing `hello`. If I use `lines`, then it works the way I'd expect it to: ``` irb(main):001:0> require 'coverage' irb(main):002:0> Coverage.setup(lines: true) => nil irb(main):003:0> require_relative 'foo' => true irb(main):004:0> Coverage.resume => nil irb(main):005:0> hello hello => nil irb(main):006:0> Coverage.suspend irb(main):007:0> Coverage.result(stop: false, clear: true) => {"/project/foo.rb"=>{:lines=>[0, 1, nil]}} irb(main):008:0> Coverage.resume => nil irb(main):009:0> Coverage.suspend irb(main):010:0> Coverage.result(stop: false, clear: true) => {"/project/foo.rb"=>{:lines=>[0, 0, nil]}} irb(main):011:0> Coverage.resume => nil irb(main):012:0> hello hello => nil irb(main):013:0> Coverage.suspend irb(main):014:0> Coverage.result(stop: false, clear: true) => {"/project/foo.rb"=>{:lines=>[0, 1, nil]}} ``` I get that `oneshot_lines` is only suppose to count the line once, but I'd expect that upon a reset/clear, it should remark the line as executed. I wasn't sure if this is expected behavior or a bug. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113896] [Ruby master Feature#18996] Proposal: Introduce new APIs to reline for changing dialog UI colours
by hasumikin (hitoshi hasumi) 13 Jun '23

13 Jun '23

Issue #18996 has been updated by hasumikin (hitoshi hasumi). I opened a PR to restart this discussion: https://github.com/ruby/reline/pull/552 ---------------------------------------- Feature #18996: Proposal: Introduce new APIs to reline for changing dialog UI colours https://bugs.ruby-lang.org/issues/18996#change-103548 * Author: st0012 (Stan Lo) * Status: Open * Priority: Normal ---------------------------------------- ### TL;DR I want to add APIs to `reline` for changing its dialog item's colors. The APIs I want to add actually have been merged but becaue: 1. This is a design change 2. The maintainer @aycabta is not available to approve nor reject them I want to raise it here to decide if we should: 1. Drop them 2. Modify them 3. Officiallty accept them ### Background After version `1.4`, `irb` provides autocompletion support, which is a great feature and has increased many developers' productivity significantly. But there's an user-experience issue: the completion items' UI colors (set in `reline`) [are not configurable](https://github.com/ruby/reline/blob/9ab5850444b49aff8e360a84e…. So depending on the user's terminal theme, some may find it hard to use because the background and the text having low-contrast colors, like this: ![](https://user-images.githubusercontent.com/3303032/148653612-e3dff786-1a10-4923-a0eb-3975cae10a7f.png) And if that happens, the user has no way to fix it. This caused users to open issues like: - https://github.com/ruby/irb/issues/351 - https://github.com/ruby/irb/issues/328 for being able to change it. Some users even decided to disable it completely because the colors are unreadable to them. I have also seen people sharingtips for disabling this feature: [example](https://twitter.com/sdogruyol/status/1538512030449254400). So I believe it may be bothering many developers. Personally I really like this feature but the background also bothers me: ![Screenshot 2022-09-07 at 22 55 12](https://user-images.githubusercontent.com/5079556/188990620-5ec7ba0c-97… And that's why I want to improve it by making the colors configurable and potentially also by providing simple light/dark themes from `irb`. ### Proposal For the dialog UI, there are 2 element states: `highlighted` and `default`. In `irb`'s case, the selected completion candidate will be `highlighted`, and the rest of options will be `default`. And each state has 2 colors: `foreground (text)` and `background (block)`. This means the `reline` should allow `irb` and/or users to configure: - Default items' foreground color - Default items' background color - Highlighted items' foreground color - Highlighted items' background color That brings us to these APIs: - `Reline.dialog_default_fg_color` - `Reline.dialog_default_bg_color` - `Reline.dialog_highlight_fg_color` - `Reline.dialog_highlight_bg_color` And because `reline` only supports coloring through ANSI sequences, these APIs only has 8 available colors if we exclude their bright variants: - Black - Red - Green - Yellow - Blue - Magenta - Cyan - White Given the limited options and also to prevent users from entering non-color ANSI sequences, these APIs only take color names directly: - :black - :red - :green - :yellow - :blue - :magenta - :cyan - :white Example: ```rb Reline.dialog_default_bg_color = :black puts Reline.dialog_default_bg_color_sequence #=> 40 Reline.dialog_default_fg_color = :white puts Reline.dialog_default_fg_color_sequence #=> 37 Reline.dialog_highlight_bg_color = :blue puts Reline.dialog_highlight_bg_color_sequence #=> 34 Reline.dialog_highlight_fg_color = :black puts Reline.dialog_highlight_fg_color_sequence #=> 30 ``` I have made a [proof of concept PR](https://github.com/ruby/irb/pull/380) on `irb` to show what these APIs can achieve if they or similar ones are adopted. #### Related PRs The related changes are made through multiple PRs: - [Initial APIs PR by @pocari](https://github.com/ruby/reline/pull/413) - [PR to improve the APIs and make them safer to use](https://github.com/ruby/reline/pull/454) - [PR to rename the APIs](https://github.com/ruby/reline/pull/456) #### Other Thoughts This is more of a concern on the `irb` part, but to make the UI looks comfortable, I think it's better to follow these conditions: 1. An item's foreground and background colors should have high contrast with each other so the texts (foreground) are readable. 2. For the `highlighted` item, its background color should be easily distinguishable from the rest of `default` items. 3. When using dark terminal themes, the `default` items' background is better to be dark as well. ---Files-------------------------------- Screenshot 2022-10-18 at 15.25.36.png (9.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113740] [Ruby master Bug#19707] Backport openssl fix to ruby_3_2 branch
by eileencodes (Eileen Uchitelle) 13 Jun '23

13 Jun '23

Issue #19707 has been reported by eileencodes (Eileen Uchitelle). ---------------------------------------- Bug #19707: Backport openssl fix to ruby_3_2 branch https://bugs.ruby-lang.org/issues/19707 * Author: eileencodes (Eileen Uchitelle) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi! While working on backports to fix another bug, I noticed that the openssl tests for Visual Studio code were failing with an unrelated error. I tracked down the fix on master and opened a backport PR for ruby_3_2 here https://github.com/ruby/ruby/pull/7902. The branch where I found this issue was on https://github.com/ruby/ruby/pull/7888 and the build is https://github.com/ruby/ruby/actions/runs/5146819376/jobs/9266401095?pr=788… -- https://bugs.ruby-lang.org/

2 1