02:13 sivoais joined 02:23 sivoais joined 02:34 sivoais joined 02:46 sivoais joined 02:48 ilbot3 joined 03:03 zakharyas joined 03:22 japhb joined 03:36 japhb joined 03:55 japhb joined 04:45 vendethiel joined 05:46 vendethiel joined 06:37 domidumont joined 06:44 domidumont joined 06:47 zakharyas joined 06:52 vendethiel joined 07:09 domidumont joined 08:01 Ven joined 08:11 FROGGS joined 08:55 vendethiel joined 08:59 Ven joined 09:58 vendethiel joined 10:00 kjs_ joined 10:17 zakharyas joined 10:56 kjs_ joined 11:04 Ven joined 11:25 harrow joined, ingy joined 11:38 vendethiel joined 12:55 Ven joined
timotimo now that i'm thinking even more about all that heap explorer stuff, we'd probably really want to be able to inspect objects more closely, so perhaps a piece of GDB integration would be necessary :\ 13:19
because GDB knows about structs and stuff
13:25 kjs_ joined 13:37 vendethiel joined 14:03 Ven joined 14:11 vendethiel joined 14:30 FROGGS joined 14:44 vendethiel joined 14:57 kjs_ joined 15:05 Ven_ joined 15:28 vendethiel joined, kjs_ joined 15:34 brrt joined
brrt \o 15:35
yesterday i got an interesting article about register-allocation-on-ssa-form
www.christianwimmer.at/Publications...mer10a.pdf
interesting because it shows how the phi-deconstruction follows from ssa reduction 15:36
another interesting bit was that it became a bit more obvous how to implement real global register allocation with a possibly-looping cfg
loops are currently impossible in the expression jit
but, it might be possible to join together multiple basic blocks in a loop, and then we could do them 15:37
15:53 vendethiel joined 15:58 kjs_ joined 16:09 tadzik1 joined 16:34 vendethiel joined 16:46 vendethiel joined 17:05 kjs_ joined 17:06 brrt joined 17:37 domidumont joined 17:38 vendethiel joined 18:15 kjs_ joined 18:23 vendethiel joined 19:11 kjs_ joined 19:39 vendethiel joined 19:48 cognominal joined 20:55 Ven joined 21:03 Ven joined
jnthn I just looked at perl6-m -e "say(1)" under valgrind with --full-cleanup. It's not actually anything like so bad as I feared. 21:35
22:10 vendethiel joined
dalek arVM: b6e0e2a | jnthn++ | src/spesh/graph.c:
Fix leak involving inlining handlers.
 22:12
arVM: 2c2cc80 | jnthn++ | src/strings/decode_stream.c:
Don't leak "empty" buffers.

These could end up being the size of a slurped file, meaning we could leak a large amount of memory in programs that were slurp-heavy, and an amount not proportional to file size in various other forms of I/O.		 22:39
jnthn That one *was* bad.
22:39 sivoais joined 22:43 vendethiel joined
lizmat jnthn++ 22:44
jnthn First 18 tests in the NQP test suite now only leak the 1KB related to the standard handles (which will take a little thought to fix). 22:47
19 leaks a tad more...will look into that next time :)
(Plan is to get NQP's test suite leak clean, then move on to Rakudo) 22:48
'night
lizmat jnthn: if you could look into getting the utf8-c8 (was that the name) encoding working, you would make Tux really happy
jnthn lizmat: Yeah, that needs a bit more brane :) 22:49
22:49 Ven joined
lizmat seems like if the first byte is not utf-8, it fails 22:49
jnthn Hopefully in the next couple of weeks I'll be feeling up for it :)
lizmat ok
jnthn Yeah, utf8-c8 seems oddly fragile.
I think I need to re-think the approach a bit.
Rather than keep patching it up 22:50
lizmat I see...
jnthn If it's this broken either I was having a really bad day when coding it up, or something's off with the approach it takes.
lizmat I was under the impression it was an initialization issue 22:51
jnthn It may be
lizmat ok, enough nudging from my end :-) 22:52
jnthn It's just had quite a few bugs so far, for a not huge amount of code, which makes me suspect I'm doing it in a bad way.
Anyway, rest :)
o/ 22:53
lizmat good night, jnthn
23:02 Ven joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!