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.		 11:25
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.		 13:00
lizmat afk for a few hours& 13:04
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
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
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.		 18:24
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 :-(		 19:13
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&

Powered by Cro and the Raku® Programming Language.

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

Thank you!