🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
timo because i've got a simple for/when with integers where ACCEPTS is called against an enum 00:01
and that was going via Numeric:D's ACCEPT, which tries to cast via .Numeric first, and then also checks for nan and inf
and putting an ACCEPTS into Int makes it much better 00:02
since the numeric accepts has a body too big to be inlined, the int one is much much smaller
lizmat timo: sounds like a good idea... 00:07
timo 1.74s vs 9.5s user time for my code 00:09
rakudo -e 'enum lmao <first second third fourth>; sub do-my-bidding { for ^2000 { when first { print ">." }; when second { print "." }; when third { print "." }; when fourth { print ".\n" } } }; for ^1000 { do-my-bidding }'
i did not actually check what exact semantics we have for ACCEPTSing between two defined Int objects 00:11
so i just used literally self == other 00:14
spec tests look good so far 00:36
Geth rakudo/int-accepts-int-quickly: 1b63dbf239 | (Timo Paulssen)++ | src/core.c/Int.pm6
Very simple ACCEPTS for Int:D vs Int:D

Otherwise running ACCEPTS on an Enum goes via Numeric's ACCEPTS, which first calls to .Numeric to coerce, and has checks for nan and inf on top of the numeric value comparison.
This new candidate has a bytecode small enough to be inlined, as opposed to the Numeric ACCEPTS method.		 00:44
rakudo: timo++ created pull request #4625:
Very simple ACCEPTS for Int:D vs Int:D		 00:46
timo passed my spec tests 00:49
[Coke] nice. 00:52
timo not sure if much real-world code will actually look much like this 01:00
timo Kaiepi: what's your suggestion, to make it look just like the other one, i.e. hllbool eq_I? 01:14
Kaiepi more or less, yeah
timo and Num gets one that looks just like Numeric's except without .Numeric on the "other" argument? 01:15
how useful is a num other than nan or inf accepting another num, when we have rounding and imprecision and all that to worry about 01:17
Kaiepi that one doesn't quite correspond 01:20
it would need to be similar to Int:D's candidates, but with an extra check for NaN i think 01:21
timo (try my \numeric = a.Numeric).defined 01:22
?? (self.isNaN && numeric.isNaN or numeric == self)
!! False
this one i mean
Geth rakudo/int-accepts-int-quickly: d7ecc018a7 | (Timo Paulssen)++ | src/core.c/Int.pm6
Very simple ACCEPTS for Int:D vs Int:D

Otherwise running ACCEPTS on an Enum goes via Numeric's ACCEPTS, which first calls to .Numeric to coerce, and has checks for nan and inf on top of the numeric value comparison.
This new candidate has a bytecode small enough to be inlined, as opposed to the Numeric ACCEPTS method.		 01:37
timo does that look good to you?
Kaiepi i'm not sure how to type an Any:D coercion for Int.ACCEPTS and Num.ACCEPTS w/o the rounding errors off the top of my head. it would need a more narrow type to consider maybe
m: use nqp; say nqp::iseq_I(1, my $ = 1) 01:39
camelia P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Scalar
in block <unit> at <tmp> line 1
timo i'm not entirely sure what you're looking to do; i'm mostly thinking of putting ACCEPTS for matching types in this spec test
ok, needs a decont
m: use nqp; say nqp::iseq_I(1, my \xyz = 1)
camelia 1
timo or not
Kaiepi it needs the decont i think 01:40
m: use nqp; sub foo(\topic) { nqp::iseq_I(1, topic) }(my $ = 1)
camelia P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Scalar
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
timo indeed 01:41
Geth rakudo/int-accepts-int-quickly: 4d067e360c | (Timo Paulssen)++ | src/core.c/Int.pm6
Very simple ACCEPTS for Int:D vs Int:D

Otherwise running ACCEPTS on an Enum goes via Numeric's ACCEPTS, which first calls to .Numeric to coerce, and has checks for nan and inf on top of the numeric value comparison.
This new candidate has a bytecode small enough to be inlined, as opposed to the Numeric ACCEPTS method.		 01:42
timo that's what i get for using \ sigil 01:51
hold on, perhaps it's actually faster now to use $ sigil
don't actually hold on, tho 02:00
the latest commit passes spec tests, or at least hasn't failed any yet
anyway, feel like hitting merge on the PR if you think it looks good, we can add more ACCEPTS candidates in other places later 02:14
(when the tests pass) 02:15
timo skarsnik's example code with gumbo and XML got slower between 2021.09 and master, but at least int-accepts-int-quickly seems to make it perform better 11:11
Geth rakudo/add-Any.infer: 402d434b7c | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Add an Any(iterable).infer method

Given an iterable thing of values, will return the type / role that is tightest for the values given.
As proposed by jnthn on logs.liz.nl/moarvm/2021-11-09.html#10:25-0001		 13:27
rakudo: lizmat++ created pull request #4626:
Add an Any(iterable).infer method		 13:28
rakudo: MasterDuke17++ created pull request #4627:
Change SetHash.values() from `is rw` to `is raw`		 13:45
Geth rakudo: 6598746027 | (Daniel Green)++ | src/core.c/SetHash.pm6
Change SetHash.values() from `is rw` to `is raw`

Doesn't change the semantics, but makes it consistent with
  (Mix|Bag)Hash.values().		 13:49
rakudo: 4ea2ca2d18 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/SetHash.pm6
Merge pull request #4627 from MasterDuke17/consistently_use_is-raw_for_(Mix|Bag|Set)Hash_.values

Change SetHash.values() from `is rw` to `is raw`
Geth rakudo/replace-attrinited: 6 commits pushed by (Jonathan Worthington)++ 15:09
rakudo: db136bc52d | (Stefan Seifert)++ | 5 files
Fix segfaults when multiple threads initialize dynamics

When multiple threads try to access an uninitialized dynamic like $*PROGRAM-NAME at the same time, they all will run the initialization code. This is mostly benign (just a little wasteful) but the actual assignment into the PROCESS:: stash may lead to segfault as that's unsafe writing into a hash. Indeed, this not only affects PROCESS variables, but stashes in general. Since stashes are ... (7 more lines)		 15:14
rakudo: 09f5069cc5 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 5 files
Merge pull request #4622 from rakudo/fix_stash_threading_issues

Fix segfaults when multiple threads initialize dynamics
Geth rakudo/replace-attrinited: 77720e06e2 | (Jonathan Worthington)++ | 2 files
Fix Array/Hash attribute initialization

We need to clear the UninitializedAttribute descriptor upon a STORE to an array or hash, otherwise we'll consider it uninitialized and wrongly give errors or apply defaults.		 15:49
rakudo/int-accepts-int-quickly: f537ac880e | (Timo Paulssen)++ | src/core.c/Int.pm6
Use sigiled parameter instead of sigil-less
 16:14
timo ^- running spectests right now 16:16
timo spec tests succeeded 16:28
Geth roast: b112eb0f4c | (Jonathan Worthington)++ | S12-class/attributes-required.t
Cover `is required` with @ and % sigils
 17:39
rakudo/replace-attrinited: 10 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/7...049edeebb3		 17:40
Geth rakudo/add-Any.infer: fd16f72bda | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Make .infer take a fast path for all identical types

And fall back to the old algorithm if a different type is detected.
This makes (1,2,3,4,5,6,7,8,9,10).infer about 9x as fast.		 18:32
nqp/new-disp-nativecall: b7c05b2ff0 | (Stefan Seifert)++ | 4 files
API for asking whether the compiler supports a certain nqp op

This can be used to conditionally compile backend specific code in modules like NativeCall		 18:52
nqp/new-disp-nativecall: 3945533f58 | (Stefan Seifert)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Remove last remnant of old invocation protocol
rakudo/new-disp-nativecall: 12 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/5...e5e6a0dfad		 18:53
rakudo: niner++ created pull request #4629:
New disp nativecall		 18:54
Geth rakudo/add-Any.isa-all: 2ca8fddfcb | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Add Any(iterable).isa-all(type) method

This returns a boolean whether all values produced by the iterable match the given type. Intended to be used in e.g. constraints such as:
   sub foo(@a where .isa-all(Int))
... (10 more lines)		 19:12
rakudo: lizmat++ created pull request #4630:
Add Any(iterable).isa-all(type) method
Geth rakudo/add-Any.isa-any: 1a930fd87c | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Add Any(iterable).isa-any(type) method

This returns a boolean whether *any* values produced by the iterable match the given type. Intended to be used in e.g. constraints such as:
   sub foo(@a where .isa-any(Int))
... (5 more lines)		 19:57
rakudo: lizmat++ created pull request #4631:
Add Any(iterable).isa-any(type) method		 19:58
Geth rakudo/add-Any.isa-none: 7fd4deec42 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Add Any(iterable).isa-none(type) method

This returns a boolean whether none of the values produced by the iterable match the given type. Intended to be used in e.g. constraints such as:
   sub foo(@a where .isa-none(Str))
... (5 more lines)		 20:17
rakudo: lizmat++ created pull request #4632:
Add Any(iterable).isa-none(type) method		 20:18
Geth rakudo: jnthn++ created pull request #4633:
Replace nqp::attrinited with a descriptor-based approach		 21:59
rakudo: MasterDuke17++ created pull request #4634:
Make concurrent access to an enum by value safe		 22:33

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!