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

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

18 Jun '23

Hi Fedor, Okay. Thanks for the info, and for sharing the issue ticket below. https://github.com/cirruslabs/cirrus-ci-docs/issues/1177 Jun On Thu, Jun 15, 2023 at 8:39 PM Fedor Korotkov <fedor(a)cirruslabs.org> wrote: > Yes, we had some issues with the migration but everything should be > working now even better than before. Please check this > <https://github.com/cirruslabs/cirrus-ci-docs/issues/1177#issuecomment-15935…> > comment for details. > > On Thu, Jun 15, 2023 at 10:13 AM Jun Aruga (he / him) <jaruga(a)redhat.com> > wrote: > >> 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. >> > > > -- > > 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:113931] [Ruby master Bug#18686] Regexp supporting unexpected age properties in Ruby < 3.2
by janosch-x 18 Jun '23

18 Jun '23

Issue #18686 has been updated by janosch-x (Janosch Müller). this no longer occurs in ruby 3.2 or 3.3 so IMO this bug can be closed @duerst @jeremyevans0 ```ruby RUBY_DESCRIPTION # => "ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [arm64-darwin22]" [*0..1000].product([*0..100]).each_with_object([]) do |(n1, n2), acc| n = "#{n1}.#{n2}" acc << n if (/\p{age=#{n}}/ rescue nil) end # => ["1.1", "2.0", "2.1", "3.0", "3.1", "3.2", "4.0", "4.1", "5.0", "5.1", "5.2", "6.0", "6.1", "6.2", "6.3", "7.0", "8.0", "9.0", "10.0", "11.0", "12.0", "12.1", "13.0", "14.0", "15.0"] ---------------------------------------- Bug #18686: Regexp supporting unexpected age properties in Ruby < 3.2 https://bugs.ruby-lang.org/issues/18686#change-103586 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I've encountered this on GitHub Actions running Ubuntu 20. I cannot reproduce it locally on Darwin/arm64. It is a weird bug and far from critical, but it might indicate some underlying problem. I've found that ... - all Ruby versions below 3.1 allow `/\p{age=14.0}/` - this is unexpected because age 14 was only added in Ruby 3.2 - Ruby seems to parse this as `age=10.0`, at least it matches exactly these codepoints - all Ruby versions below 3.2 allow *some* unexpected values for age - allowed values are e.g. `age=21.0`, `age=41.0`, `age=99.0` (depending on Ruby version) - on Ruby 3.1, `age=99.0` matches exactly the same codepoints as `age=11.0` - ruby-head doesn't seem to allow unexpected age values (i've only tested values ending in `.0`) I've set up a minimal reproduction here: https://github.com/jaynetics/ruby_age_property_bug_repro with the unexpected results visible here: https://github.com/jaynetics/ruby_age_property_bug_repro/actions/runs/21155… and here: https://github.com/jaynetics/ruby_age_property_bug_repro/actions/runs/21167… CC @duerst -- https://bugs.ruby-lang.org/

1 0

[ruby-core:113925] [Ruby master Feature#19734] Let `File` be a subclass of `Dir`
by sawa (Tsuyoshi Sawada) 18 Jun '23

18 Jun '23

Issue #19734 has been reported by sawa (Tsuyoshi Sawada). ---------------------------------------- Feature #19734: Let `File` be a subclass of `Dir` https://bugs.ruby-lang.org/issues/19734 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- I propose to let `File` class be a subclass of `Dir` class. Motivations are as follows. When we want to do something with a file (for example `File.read` or `File.write`), we quite often want to achieve the home directory. If we are in the mode of thinking in the ream of `File`, we would likely come up with `File.expand_path("~")`. However, this is cumbersome, and actually, `Dir.home` is simpler. But my experience is that switching the mind to `Dir` when thinking about `File` require extra cognitive load. Also, many methods defined in `File` work for both a file or a directory. When we are doing something with a directory, we have to stop and think whether the method we want to use is defined in `File` or in `Dir`. It is possible to do that, but that also requires extra cognitive load. I thought things would become simpler if we do not need to switch between these two classes in mind, and keep using `File`. There are a few singleton methods that are defined on both `File` and `Dir`: ``` delete/unlink, empty?, exist?, new/open ``` but I think there would be no problem in choosing the appropriate class depending on the need. Semantically, maybe it makes more sense to let `Dir` be a subclass of `File` because directories are special cases of files. However, in Ruby, `File` and `Dir` have ancestors ``` File < IO < Enumerable < File::Constants < Object < ... Dir < Enumerable < Object < ... ``` respectively, and `File` inherits `IO` and `File::Constants`, beside their common ancestors, so I though that letting `File` be a subclass of `Dir` would be more practical. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113715] [Ruby master Bug#19701] The rb_classext_t::classpath field is not marked for T_ICLASS
by wks (Kunshan Wang) 18 Jun '23

18 Jun '23

Issue #19701 has been reported by wks (Kunshan Wang). ---------------------------------------- Bug #19701: The rb_classext_t::classpath field is not marked for T_ICLASS https://bugs.ruby-lang.org/issues/19701 * Author: wks (Kunshan Wang) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I am hacking Ruby to dump information about some objects, and I found that the `rb_classext_t::classpath` field for `T_ICLASS` objects sometimes contains dangling references to dead objects. The commit https://github.com/ruby/ruby/commit/081cc4eb283cb01ddffb364397e5175dbfacab66 set the `classpath` field of `rb_mRubyVMFrozenCore` to a string "FrozenCore" so that it can be dumped using the `rb_dump_literal` function. However, in `gc_mark_children`, if the `obj` is a `T_ICLASS`, the `RCLASS_EXT(obj)->classpath` will not be marked. As a result, if `rb_mRubyVMFrozenCore` is the only object that holds a reference to the string "FrozenCore", the string will be considered garbage and reclaimed during a GC, and the `classpath` will contain a dangling pointer. There are two solutions to this problem. We can take *one* of the approaches below (not both). 1. Let the GC mark the `classpath` field. I drafted a pull request here: https://github.com/ruby/ruby/pull/7875 2. Revert the commit https://github.com/ruby/ruby/commit/081cc4eb283cb01ddffb364397e5175dbfacab66 Marking the `classpath` field in GC will keep the `rb_dump_literal` function working. For debug purposes, we can also use that field to identify what object a given `T_ICLASS` is. Adding one marked field may make GC slower, but I don't think it will be observable because there are far less `T_ICLASS` objects than ordinary objects. If we reverting the commit above, the `classpath` will always be blank for all `T_ICLASS` objects. (Question: How do we enforce it?) It will also save some memory by keeping less strings alive. However, currently, "FrozenCore" seems to be the only `T_OBJECT` that has its classpath set, and it may not result in significant memory saving. I don't know what purpose the `rb_dump_literal` function originally served. Maybe it is still important. Maybe it is safe to remove now. Which of the two approaches should we take? It looks like each of them has its pros and cons. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:113924] [Ruby master Feature#16833] Add Enumerator#empty?
by ioquatix (Samuel Williams) 17 Jun '23

17 Jun '23

Issue #16833 has been updated by ioquatix (Samuel Williams). Assignee set to ioquatix (Samuel Williams) ---------------------------------------- Feature #16833: Add Enumerator#empty? https://bugs.ruby-lang.org/issues/16833#change-103577 * Author: f3ndot (Justin Bull) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- It was surprising to me that Enumerator, something mixed into Array, does not include `#empty?`. I think it is reasonable to assume people may have to guard iterating and other logic based on the emptiness of an enumerator, such was my case. ``` ruby # pretend there's convoluted enumerator logic to produce this structure table_rows = [{ data: ['First', 'Second', 'Third'], config: {} }, { data: [4, 5, 6], config: { color: 'red' } }].to_enum return if table_rows.empty? table_header = table_rows.first[:data] # requires an empty guard # ... ``` I propose that it simply behaves as `#take(1).to_a.empty?` instead of aliasing to something like `#none?` because of falsey elements or `#size == 0` because of potential `nil` returns: ```ruby [].to_enum.empty? # => true [false].to_enum.empty? # => false [nil].to_enum.empty? # => false [0].to_enum.empty? # => false [1, 2, 3].to_enum.empty? # => false ``` ---Files-------------------------------- add-enumerable-empty.patch (1.99 KB) -- https://bugs.ruby-lang.org/

1 0

[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