|
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. |
11:25 | |
|
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. |
13:00 | |
| 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. |
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& | |||
|
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
|
|||