00:16 Kaeipi left, Kaeipi joined 00:33 Kaeipi left 00:34 Kaeipi joined 00:50 leont left 02:01 lucasb left 02:22 maggotbrain joined 04:01 squashable6 left 04:03 squashable6 joined 04:37 raku-bridge1 joined, raku-bridge1 left, raku-bridge1 joined 04:38 raku-bridge left 04:39 raku-bridge1 is now known as raku-bridge 04:55 frost-lab joined 06:15 sena_kun joined 06:26 frost-lab left 06:40 frost-lab joined 07:07 Kaeipi left 07:17 Kaiepi joined 07:29 Kaiepi left 07:30 Kaiepi joined 07:35 domidumont joined 08:10 Altai-man joined 08:13 sena_kun left 08:53 domidumont left 08:57 domidumont joined 09:24 domidumont left 09:38 Kaiepi left 09:39 domidumont joined 09:46 domidumont1 joined 09:48 domidumont left 09:59 domidumont1 left 10:01 domidumont joined 10:40 Kaiepi joined 10:41 morayj joined
lizmat Files=1345, Tests=117140, 232 wallclock secs (29.85 usr 8.93 sys + 3193.88 cusr 310.38 csys = 3543.04 CPU) 11:07
lizmat clickbaits rakudoweekly.blog/2020/11/23/2020-...t-release/ 11:08
Geth_ rakudo: 69f3e959b5 | (Elizabeth Mattijsen)++ | 5 files
Change nqp::tostr_I(foo) to faster nqp::base_I(foo,16)

As just discussed on #moarvm, as it is orders of magnitude faster. This most notably affects Int.WHICH, which will now report its value in hex: before 42.WHICH was Int|42, now it is Int|2A
Note that this will only show up as an improvement in certain workloads, that depend heavily on WHICH values, such as using object hashes and set operations.
12:12 sena_kun joined 12:13 Altai-man left 12:34 leont joined
nine Hah! That's an unfortunate regression: build.opensuse.org/package/live_bu...eweed/i586 12:37
lizmat nine: so want me to revert 69f3e959b5 12:45
linkable6 (2020-11-24) github.com/rakudo/rakudo/commit/69f3e959b5 Change nqp::tostr_I(foo) to faster nqp::base_I(foo,16)
lizmat it is *not* bringing as much goodiness as I thought it would
nine But it does? It's clearly my test that's at fault here. I just hope I'm the only one making that mistake 12:46
lizmat a few percent on the raw difference between tostr_I and tobase_I(,16) 12:48
it probably drowns out anyway
and it does not improve readability on Int.WHICH :-)
Geth_ rakudo: ce45754dca | (Elizabeth Mattijsen)++ | 5 files
Revert "Change nqp::tostr_I(foo) to faster nqp::base_I(foo,16)"

This reverts commit 69f3e959b5bf884628813c81215ac0a244b034f3.
This was **NOT** bringing as much efficiency improved as was
  (improperly) benchmarked, and it caused immediate issues with
Inline::Perl5, so reverting for now.
lizmat afk for a few hours& 13:04
13:12 frost-lab left
timotimo hmm. can't use a non-integer time for .batch on a supply, because it uses infix:<div> to do some calculations 13:53
14:18 MasterDuke joined
vrurg m: use nqp; my $foo = "123"; my $n = q<$foo>; say nqp::getlex($n) 14:59
camelia ===SORRY!===
Expected QAST constant, got QAST::Node
vrurg Quite a weird one...
timotimo huh, i wouldn't expect that op to ever be usable in user code
vrurg timotimo: I needed it in Actions.nqp 15:00
timotimo you'd probably want to use a QAST::Var with scope lexical and have the actions/world do all the stuff for you 15:01
vrurg timotimo: of course, it's so stupid of me! Thanks! 15:03
timotimo haha, don't worry :)
vrurg can now get back to dayjob with a clear conscience. ;) 15:06
15:40 maggotbrain left 15:58 MasterDuke left 16:11 Altai-man joined, MasterDuke joined 16:13 sena_kun left 18:02 domidumont left 18:16 domidumont joined 18:20 domidumont left
Geth_ rakudo: aba90b014b | (Elizabeth Mattijsen)++ | 37 files
Another round of nqp::if -> ternaries

Removing nqp::stmts() in a lot of cases, made it easier and clearer to change nqp::if(foo,bar,baz) into foo ?? bar !! baz
Again, no semantic changes nor should there be any noticeable performance loss. This is just recovering core setting source readability.
lizmat timotimo: re hmm. can't use a non-integer time for .batch on a supply, because it uses infix:<div> to do some calculations, what would a non-integer value mean ? 18:28
or are you talking allomorphs ?
timotimo no 18:37
0.1 seconds is just like 1 seconds but 10x shorter 18:38
lizmat aaaah.... could you make an issue for that ? 18:42
lizmat had missed the "time" bit 18:43
Geth_ rakudo: e46a1da29c | (Elizabeth Mattijsen)++ | src/core.c/REPL.pm6
Revert "Stop REPL complaining about "useless use""

This reverts commit eae309a49f5e4274d47e966b6f3fcbf735ce0803.
This is opening another nest of bugs, so closing this for now.
Sadly, the REPL in its current state has a CONTROL block to catch CONTROL messages such as warnings, but sadly this appears to be never called. It looks like warnings are actually captured in NQP and thus not interceptable in Raku :-(
lizmat I wonder why the REPL is not using Raku's EVAL 19:16
aaah... it's actually a compile time warning, generated from the worries 19:31
lizmat goes off to contemplate that for a few hours&
20:12 sena_kun joined 20:13 Altai-man left 20:56 morayj left 21:00 MasterDuke left 21:21 Kaiepi left 21:22 MasterDuke joined, Kaiepi joined 21:31 sena_kun left 22:31 MasterDuke left 23:38 leont left