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|
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 ?|
|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