🦋 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 | |
github.com/japhb/cbor-specs/blob/m...capture.md | |||
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 |
04:10 | |
roast: vrurg++ created pull request #772: Add tests for :concretizations parameter of .mro |
04:14 | ||
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) 2.487410392 |
||
lizmat | m: say ($_,$_+2) given (^Inf).grep({.is-prime && ($_+2).is-prime}).skip(99999).head; say now - INIT now | 13:54 | |
camelia | (18409199 18409201) 5.930464612 |
||
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:24 | |
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 |
19:33 | |
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 |
19:50 | ||
nqp: 9bd4cbdda4 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM for alloca changes |
19:53 | ||
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 |
20:07 | |
lizmat | japhb | 20:09 | |
yes | |||
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 |
21:14 | |
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
|