🦋 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.
00:04 reportable6 left 00:07 reportable6 joined 00:18 dogbert17 joined
japhb CBOR Capture is now officially IANA registered! :-) 00:49
timo cool 00:56
japhb ... and just uploaded CBOR::Simple 0.1.1 which includes support for Capture as well as packed native (u)int arrays 00:58
timo nice 01:01
01:35 frost joined 03:12 linkable6 left, evalable6 left 03:13 linkable6 joined 03:14 evalable6 joined 03:46 MasterDuke left, Xliff joined
Geth rakudo: vrurg++ created pull request #4635:
Get either parametric or concrete roles in MRO when requested
roast: vrurg++ created pull request #772:
Add tests for :concretizations parameter of .mro
04:46 linkable6 left, evalable6 left 04:57 Xliff left 06:02 reportable6 left 06:04 reportable6 joined 08:49 evalable6 joined 09:47 linkable6 joined 10:37 frost left 10:39 frost joined 10:46 frost left 10:59 frost joined 11:50 Altai-man joined
Altai-man releasable6, status 11:52
releasable6 Altai-man, Next release in ≈9 days and ≈7 hours. 3 blockers. Changelog for this release was not started yet
Altai-man, Details: gist.github.com/5a794b193733c47bd8...43146bfdcb
Altai-man it's maybe a nice idea to mention we need a new release manager in the weekly 11:54
lizmat weekly: <Altai-man>it's maybe a nice idea to mention we need a new release manager in the weekly 11:57
notable6 lizmat, Noted! (weekly)
lizmat note to self: I *knew* I had forgotten something :-(
12:03 reportable6 left 12:09 frost left
lizmat wonder what causes this difference in performance: 13:53
m: say ($_,$_+2) given (^Inf).map({$_ if .is-prime && ($_+2).is-prime}).skip(99999).head; say now - INIT now
camelia (18409199 18409201)
lizmat m: say ($_,$_+2) given (^Inf).grep({.is-prime && ($_+2).is-prime}).skip(99999).head; say now - INIT now 13:54
camelia (18409199 18409201)
lizmat aka .map: { $_ if condition } is about 2x as fast as .grep: { condition } ??
afk for a bit& 13:55
ugexe well map isnt filtering out any elements 14:54
it would have to be like .map({ $_ if condition }).grep(*.defined) 14:55
15:00 linkable6 left, evalable6 left 15:01 linkable6 joined, evalable6 joined
JRaspass Pretty sure it is, false if should return Empty which collapses down: (^10).map({ $_ if .is-prime }).say # (2 3 5 7) 15:04
15:06 vrurg left
JRaspass { .is-prime ?? $_ !! Empty } and { .is-prime ?? $_ !! |() } all work the same afaict 15:06
15:07 vrurg joined
ugexe ouch 15:17
lizmat .map: { $_ if condition } *does* filter 15:41
m: say (^10).map: { $_ if $_ %% 2 }
camelia (0 2 4 6 8)
16:28 cognominal left 16:34 patrickb joined 16:35 Kaipi left, Kaipi joined 17:05 reportable6 joined
Geth rakudo: 57387455dd | timo++ (committed using GitHub Web editor) | src/core.c/Int.pm6
Very simple ACCEPTS for Int:D vs Int:D (#4625)

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.
17:25 linkable6 left 17:53 MasterDuke joined 18:02 reportable6 left 18:06 Altai-man left 18:54 casaca left, casaca joined 19:17 casaca left 19:22 casaca joined
Geth nqp: 9a4d5d0349 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for the latest fixes
rakudo/master: 5 commits pushed by (Vadim Belman)++ 19:34
roast: 0446925acc | (Vadim Belman)++ | S12-class/mro-6e.t
Add tests for :concretizations parameter of .mro

In support of rakudo/rakudo#4635
roast: e8edc8bd99 | (Vadim Belman)++ (committed using GitHub Web editor) | S12-class/mro-6e.t
Merge pull request #772 from vrurg/rework-mro-roles

Add tests for :concretizations parameter of .mro
rakudo: b9611b6327 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM fixes
nqp: 9bd4cbdda4 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for alloca changes
japhb Does that need a matching Rakudo bump again? 20:05
20:05 reportable6 joined
Geth rakudo: 3d80bec7c9 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get latest alloca MoarVM fixes
lizmat japhb 20:09
invoking the [Tux] for another test-t :) 20:14
japhb :-) 20:18
lizmat it's inching closer 1 sec on my machine 20:20
1.017 best so far
vrurg Would be interesting to compare compilation times. For the first time in many months I saw parse stage <60s prior to the bump. 20:21
lizmat Stage parse : 57.557 # last one 20:24
Stage parse : 57.328 # the one before that 20:25
MasterDuke Stage parse : 40.945 # my latest
vrurg 58.26 vs. 58.86 – about the same.
MasterDuke: your AMD, aha... :D 20:26
MasterDuke nine and jnthn have even newer/faster machines
i think they're around 33s 20:27
lizmat 58.055 55.264 56.307 56.561 55.951 53.752 57.522 59.874 56.997 56.283 # going back in tme
20:27 linkable6 joined
vrurg I guessed from jnthns words that he's anticipating <60sec compile time. 20:27
MasterDuke i think once a long time ago i checked out all the releases since christmas and built them and graphed the compile time, but that was years ago 20:28
vrurg lizmat: my usual for parse was 63+. So, seeing 58 was a pleasant surprise. And the codebase doesn't get any less. 20:29
MasterDuke: have courage to repeat?
MasterDuke probably can, but not right away, going out of town for a couple days 20:30
vrurg do you have the script on your hands? 20:31
Or there was no script, all by bare hands?
MasterDuke i probably just did it manually, it's not that complicated (and there were fewer releases at the time) 20:32
vrurg Ok, if I get so tired that could do nothing else, I'd try it. Should be fun. 20:33
20:52 MasterDuke left
tonyo are you guys testing Stage parse on a branch? on master i get 73s here and around 25 or 26 on the M1 20:53
lizmat my times were on master 20:54
so the M1 is faster even without JIT ?
tonyo yea 20:55
this machine is 2.4ghz 20 core, 256gb ram
lizmat wow
well, 20 core doesn't mean much for building, right ?
tonyo: that's a MacMini or what ? 20:58
tonyo in this case not really
20:58 MasterDuke joined
tonyo nope, just a machine i put together to smoke fez eco and provide scores/compatibility matrices for some BSD, some linux, windows, and osx 20:58
lizmat with an M1 ? 20:59
tonyo osx works as a hackintosh via qemu
nine Stage parse : 33.672
tonyo oh, no. the m1 is an airbook
lizmat aaaahhh ok *phew* :-) 21:00
tonyo ?
lizmat I got the impression you got a 20core M1 with 256G RAM, and I was wondering where on the Apple site I could order that :-) 21:02
tonyo you're trying to go to space? 21:04
i'd probably order one too, that thing is fast
Geth rakudo/add-Any.infer: 48e5595631 | (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
rakudo/add-Any.infer: 513ad8920d | (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.
rakudo/add-Any.infer: 8feb3e773d | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Simplify .infer logic, vrurg++

Now with .^mro(:roles), we don't need to handle them separately.
lizmat (a rebase + a fix)
22:49 dogbert11 joined, dogbert17 left 23:19 patrickb left