Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-10

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 nwc10 joined #moarvm
00:44 d4l3k_ joined #moarvm
00:49 timotimo joined #moarvm
01:13 colomon_ joined #moarvm
01:49 TimToady joined #moarvm
02:30 colomon joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:32 vendethiel joined #moarvm
05:46 dalek joined #moarvm
06:08 dalek joined #moarvm
06:14 [Coke] joined #moarvm
06:16 mojca joined #moarvm
06:22 mojca_ joined #moarvm
06:48 vendethiel joined #moarvm
06:51 domidumont joined #moarvm
06:56 domidumont joined #moarvm
06:58 FROGGS[mobile] joined #moarvm
07:21 orbus joined #moarvm
07:28 llfourn joined #moarvm
07:28 domidumont joined #moarvm
07:36 domidumont joined #moarvm
07:38 domidumont joined #moarvm
07:44 domidumont joined #moarvm
08:12 domidumont joined #moarvm
08:28 zakharyas joined #moarvm
08:29 brrt joined #moarvm
08:31 brrt wow, jnthn++ has been busy
08:43 ashleydev joined #moarvm
08:59 zakharyas joined #moarvm
09:32 timotimo what's this i hear about a huge memory leak? o_O
09:32 timotimo is that just a consequence of "now i can actually see real leaks when using --full-cleanup"?
09:54 jnthn timotimo: If it's the one I'm hunitng, it's not a leak in that sense.
09:55 timotimo 094956      brrt │ ouch, /me has a huge memory leak on my hand in moar it seems
09:55 timotimo ^- that's the one
09:55 jnthn Oh
09:56 jnthn Would be interested to know about that :)
09:56 jnthn I should prolly do $dayjob bits today... :)
09:56 brrt joined #moarvm
09:57 brrt no, it was in perl6
09:57 brrt rakudo itself
09:57 brrt looping infinitely
09:58 brrt apparantly we don't do TCO yet
09:58 timotimo yeah, we don't :)
09:59 jnthn Uh, no :)
10:00 brrt didn't think so
10:00 brrt :-)
10:01 timotimo i recently leaned out the window claiming that once we have trace jit, it'd only be a little step towards having TCO
10:07 brrt hmmmm
10:07 brrt yeah
10:07 brrt i see what you mean
10:07 brrt we should have had trace jit yesterday and expr jit last year
10:09 brrt well, we almost have expr jit
10:09 jnthn :)
10:09 * jnthn will be glad when that lands :)
10:09 brrt it's just that progress has been much slower than anticipated
10:09 brrt yeah, me too :-)
10:09 brrt i plan to give a presentation on 'how to hack the moarvm jit' to expose all the hackable bits
10:09 brrt because there are plenty
10:10 brrt fwiw, about the json-fast bug
10:10 brrt the issue at hand seems to be that the original jit creates 4! different dynamic-label-loading-codes
10:11 brrt and the expr jit only ones
10:11 brrt one
10:11 brrt which is *weird*
10:11 brrt but can probably be explained somehow
10:13 donaldh joined #moarvm
10:13 brrt the getlex bit works beautifully, fwiw
10:13 brrt already shorter than the corresponding lego-jit
10:15 jnthn Nice
10:17 jnthn I'm keen to look into doing smarter JIT of bigint ops and using CPU overflow flags for the bigint fallback once it's in :)
10:17 jnthn "lego-jit" :D
10:20 timotimo what json-fast bug is that? o_O
10:41 brrt oh, a bug in the expr jit that manifests within json-fast
10:41 timotimo ah, ok
10:41 brrt it's the reason i wrote the jit-bisecter
10:41 timotimo is it in the to-json or from-json part? :D
10:42 timotimo (because i only wrote the latter, not the former)
10:42 timotimo there's a stackoverflow post asking for a way to have wchar_t; what do we need to add to moar to support that "properly"?
10:42 timotimo i imagine from its description "Type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales." on cplusplus.com, it'd be 32bit big?
10:43 jnthn I think 16 bits
10:43 timotimo fortunately, c and cpp both have char16_t andchar32_t. do we want to support "is encoded" for that?
10:44 jnthn Ah, but that 16-bits is probably a Windows-ism
10:44 timotimo probably
10:44 timotimo this question in particular is about ncurses' addwstr(const wchar_t *wstr) function
10:44 timotimo let me lookat what that's defined as
10:44 jnthn Well, I'd expect is encoded('utf-16') or so
10:45 jnthn "The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers"
10:46 timotimo oh, i missed the "see 5 more comments" button
10:48 timotimo in general, that question isn't of high quality ...
10:49 timotimo at least in repl.it, with stddef.h, sizeof(wchar_t) is 4, so 32bit
10:54 * timotimo figured out where "is ctype" is implemented
10:56 timotimo what a garden path ...
10:57 timotimo ah, finally :)
10:58 timotimo so, should i add wchar_t to the list of supported "ctype" values?
10:59 jnthn It seems that's what'd be needed to handle it portably
11:00 timotimo righto
11:00 timotimo good thing we have enough negative numbers to handle most common integer and float types in C
11:04 timotimo ugh. a 19 megabytes profile from --profile-compile of SDL2::Raw's Raw.pm
11:23 timotimo we already seem to have an "id" field in pretty much every object in our profiles; why don't we go ahead and put an id-to-thing-map up front and then deduplicate that stuff out of the rest of the json blob?
11:23 kjs_ joined #moarvm
11:24 timotimo in allocations, that'd get rid of the "type" field, in callframes, i'd expect it'd get rid of file and line
11:28 jnthn It could well make things a lot smaller, yeah
11:28 timotimo i'm feeling like digging into that
11:37 FROGGS[mobile] joined #moarvm
12:24 FROGGS joined #moarvm
12:34 * timotimo also deduplicates filenames in the "id-to-thing" map
12:34 timotimo using negative numbers, neat/evil trick
12:35 timotimo the profile-compile output of SDL2::Raw went from 18 megabytes to 12 megabytes already
12:38 timotimo OK, deduplicating the filenames from the initial "dictionary" gives almost no improvement, which isn't a big surprise
12:44 timotimo er ... json doesn't actually like negative numbers as object keys
12:44 timotimo so i'll just throw the deduplication out of that part
13:00 FROGGS joined #moarvm
13:10 ilmari s/negative // # they have to be strings
13:10 timotimo hm
13:10 ilmari m: from-json(to-json({ 42 => "wat" }))
13:10 camelia rakudo-moar 9aa014: ( no output )
13:11 ilmari m: say from-json(to-json({ 42 => "wat" }))
13:11 camelia rakudo-moar 9aa014: OUTPUT«42 => wat␤»
13:11 ilmari huh?
13:11 timotimo well, => already makes strings
13:11 timotimo from its LHS if it's a literal
13:11 ilmari m: say from-json(to-json( 42 => "wat" ))
13:11 camelia rakudo-moar f0a21b: OUTPUT«Invalid JSON: {␤  42 : "wat"␤}␤  in block <unit> at /tmp/RRzQ7HkbLB line 1␤␤»
13:11 ilmari that was the one
13:12 timotimo mhh
13:12 ilmari a bare pair, not a hash
14:32 kjs_ joined #moarvm
17:13 domidumont joined #moarvm
17:13 FROGGS[mobile] joined #moarvm
17:40 vendethiel joined #moarvm
18:12 domidumont joined #moarvm
18:23 patrickz joined #moarvm
18:29 vendethiel joined #moarvm
18:53 zakharyas joined #moarvm
18:58 vendethiel joined #moarvm
18:59 domidumont joined #moarvm
19:13 kjs_ joined #moarvm
20:27 btyler joined #moarvm
21:32 colomon joined #moarvm
21:37 dalek MoarVM/heap-profiler: 5740e33 | jnthn++ | / (5 files):
21:37 dalek MoarVM/heap-profiler: Sketch in heap profiler data structures.
21:37 dalek MoarVM/heap-profiler: review: https://github.com/MoarVM/MoarVM/commit/5740e33bcc
21:41 vendethiel joined #moarvm
22:32 colomon joined #moarvm
22:36 colomon_ joined #moarvm
22:49 mojca joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary