00:48 lizmat joined 01:17 quotable6 joined 02:58 ilbot3 joined 03:57 bloatable6 joined 03:58 unicodable6 joined 04:12 Kaiepi joined
samcv gonna wait for Travis to test which i know it will, then merge my ucd2c.pl changes 04:20
i think i eliminated at least 9 globals in the full changeset 04:23
04:37 Kaiepi joined 05:50 committable6 joined, squashable6 joined, statisfiable6 joined
nine .tell alexk6 indeed! Thanks for pointing it out! 07:37
yoleaux nine: I'll pass your message to alexk6.
07:41 brrt joined 07:55 brrt joined 07:57 domidumont joined 08:02 brrt1 joined 08:10 domidumont joined
samcv Travis for os x seems broke 08:11
Geth MoarVM/master: 20 commits pushed by (Samantha McVey)++
review: github.com/MoarVM/MoarVM/compare/a...a74869e37b		 08:14
08:28 brrt joined 08:31 brrt1 joined 09:10 leont joined 09:28 zakharyas joined 09:34 geekosaur joined 09:36 geekosaur joined 10:10 brrt joined 10:13 brrt joined 11:59 brrt joined 12:15 brrt joined 12:27 harrow` joined 12:28 Ven`` joined 12:29 bisectable6 joined, reportable6 joined, bloatable6 joined 12:36 releasable6 joined, greppable6 joined, benchable6 joined, coverable6 joined, reportable6 joined
nine Another fun fact: the mysterious failure in t/spec/S04-declarations/constant.rakudo.moar no longer appears when I run it with perl 6 directly, but it does when I run it via make t/spec/S04-declarations/constant.t 13:37
Oh, now I get it with MoarVM master! 13:39
Really looks like some memory corruption. That's why elusive. What gets overwritten depends on the exact memory layout. 13:40
timotimo i bet turning valgrind on makes it go away 13:41
nine Of course :) 13:44
timotimo have you tried the various memory debugging #defines in moar's source? 13:47
13:51 zakharyas joined
dogbert2 heh, can't even compile nine's branch 13:55
timotimo it doesn't explode on my end 13:56
dogbert2 it worked for me the other day but now I get
src/spesh/optimize.c: In function ‘merge_bbs’:
src/spesh/optimize.c:2435:17: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < bb->num_succ; i++)
timotimo naughty naughty nine :) 13:57
Geth MoarVM/inline_in_place: 8 commits pushed by (Timo Paulssen)++, (Stefan Seifert)++ 14:00
nine fixed it in place
timotimo because it was introduced so early? 14:05
nine I usually avoid fixup commits as much as possible. IOW I rebase agressively to merge a clean, logical and bisectable history. 14:08
timotimo that's fair
14:14 bisectable6 joined 15:25 zakharyas joined 15:51 domidumont joined 16:12 zakharyas joined 16:18 scovit joined
Geth MoarVM: 4733449165 | (Jonathan Worthington)++ | 2 files
Mark sp_rebless as :noinline

For reasons that are not entirely clear yet, this seems to end up with the target register not updated post-deopt. This workaround deals with
  github.com/rakudo/rakudo/issues/1413 so that we don't suffer
from that issue in the upcoming release, but this warrants further investigation.		 16:36
MoarVM: 85b2c5f82a | (Jonathan Worthington)++ | 3 files
Pay attention to return op in cross-HLL inlines

We have to forbid anything that requires boxing at the point of return for now, since we can get the box type wrong.
jnthn Here's a short note I intend to send to TPF for inclusion with my grant extension application: gist.github.com/jnthn/812c0f4319f2...5d926d785d Feedback welcome (I've gotta go afk now, but will read backlog later). 17:55
timotimo oh? i'd be interested to hear what code gen improvements you envision for the regex compiler 18:00
18:16 domidumont joined 18:18 Kaiepi joined
japhb jnthn: Looks good. 18:21
FWIW I also got the Perl 6 Core Development Fund added to Benevity, so companies that use that as their non-profit registry can donate or gift match to it directly. (Thanks to [Coke] for helping me with that.) 18:24
jnthn cool! 18:33
japhb++
[Coke] ... I think I didn't really do much there, but thanks for setting it up! 18:35
samcv japhb: nice! 18:39
jnthn Forgot, [Coke]++ too :) 18:41
18:41 nativecallable6 joined
jnthn timotimo: There's a bunch of stuff about bstack usage/setup that we could do better on, for one. 18:41
19:36 quotable6 joined 20:51 evalable6 joined 21:16 colomon joined 23:38 Zoffix joined
Zoffix Is there some primer into this MoarVM register stuff? I got a fix for RT#132718 where get a "fresh register" and coerce stuff and then "release" it later, but I'd like to understand more on what it is I'm doing exactly. 23:39
synopsebot RT#132718 [open]: rt.perl.org/Ticket/Display.html?id=132718 BUG: Unhandled kind 3 with int32 argument
jnthn The fresh/release stuff aren't really a MoarVM concept, but rather something the code-generator does 23:41
Its aim is to make sure that within a given sequence of instructions a register is not re-used 23:42
But to allow re-use outside of that, so we get less registers used (and thus smaller call frames, less memory use, etc.)
At the MoarVM level, registers are just working storage locations 23:43
Zoffix Ah
jnthn Used both for QAST::Var with scope local, as well as temporary things
locals typically reserving a register through the whole QAST::Block (exception: the locallifetime op)
(which isn't a real op, just a QAST->MAST compiler hint) 23:44
Zoffix Is coercing stuff to full-width to do ops something that's normally done? Like if I want to call if_i op with int32; I coerce it to int64 register first. Is that normal?
jnthn Yes
Zoffix Cool. Thanks.
jnthn Otherwise we'd have an explosion of such ops
Zoffix :) 23:45
timotimo we can most probably revert that in the expression jit, fwiw 23:48
though the underlying asm might end up looking almost the same?
jnthn Yeah :)
(to the first part)
We I think the expression JIT can do something decent of this
That's why I decided the op explosion wasn't justified: we can deal with this situation at JIT time 23:49
23:49 leont joined
timotimo the perf report for a hundred thousand is-primes looks really strange. i'm valgrinding now. 23:54
callgrinding to be exact
23:56 Zoffix left

Powered by Cro and the Raku® Programming Language.

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

Thank you!