00:01 nwc10 joined 00:44 d4l3k_ joined 00:49 timotimo joined 01:13 colomon_ joined 01:49 TimToady joined 02:30 colomon joined 02:48 ilbot3 joined 05:32 vendethiel joined 05:46 dalek joined 06:08 dalek joined 06:14 [Coke] joined 06:16 mojca joined 06:22 mojca_ joined 06:48 vendethiel joined 06:51 domidumont joined 06:56 domidumont joined 06:58 FROGGS[mobile] joined 07:21 orbus joined 07:28 llfourn joined, domidumont joined 07:36 domidumont joined 07:38 domidumont joined 07:44 domidumont joined 08:12 domidumont joined 08:28 zakharyas joined 08:29 brrt joined
brrt wow, jnthn++ has been busy 08:31
08:43 ashleydev joined 08:59 zakharyas joined
timotimo what's this i hear about a huge memory leak? o_O 09:32
is that just a consequence of "now i can actually see real leaks when using --full-cleanup"?
jnthn timotimo: If it's the one I'm hunitng, it's not a leak in that sense. 09:54
timotimo 094956 brrt │ ouch, /me has a huge memory leak on my hand in moar it seems 09:55
^- that's the one
jnthn Oh
Would be interested to know about that :) 09:56
I should prolly do $dayjob bits today... :)
09:56 brrt joined
brrt no, it was in perl6 09:57
rakudo itself
looping infinitely
apparantly we don't do TCO yet 09:58
timotimo yeah, we don't :)
jnthn Uh, no :) 09:59
brrt didn't think so 10:00
:-)
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:01
brrt hmmmm 10:07
yeah
i see what you mean
we should have had trace jit yesterday and expr jit last year
well, we almost have expr jit 10:09
jnthn :)
jnthn will be glad when that lands :)
brrt it's just that progress has been much slower than anticipated
yeah, me too :-)
i plan to give a presentation on 'how to hack the moarvm jit' to expose all the hackable bits
because there are plenty
fwiw, about the json-fast bug 10:10
the issue at hand seems to be that the original jit creates 4! different dynamic-label-loading-codes
and the expr jit only ones 10:11
one
which is *weird*
but can probably be explained somehow
10:13 donaldh joined
brrt the getlex bit works beautifully, fwiw 10:13
already shorter than the corresponding lego-jit
jnthn Nice 10:15
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
"lego-jit" :D
timotimo what json-fast bug is that? o_O 10:20
brrt oh, a bug in the expr jit that manifests within json-fast 10:41
timotimo ah, ok
brrt it's the reason i wrote the jit-bisecter
timotimo is it in the to-json or from-json part? :D
(because i only wrote the latter, not the former) 10:42
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"?
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?
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?
jnthn Ah, but that 16-bits is probably a Windows-ism 10:44
timotimo probably
this question in particular is about ncurses' addwstr(const wchar_t *wstr) function
let me lookat what that's defined as
jnthn Well, I'd expect is encoded('utf-16') or so
"The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers" 10:45
timotimo oh, i missed the "see 5 more comments" button 10:46
in general, that question isn't of high quality ... 10:48
at least in repl.it, with stddef.h, sizeof(wchar_t) is 4, so 32bit 10:49
timotimo figured out where "is ctype" is implemented 10:54
what a garden path ... 10:56
ah, finally :) 10:57
so, should i add wchar_t to the list of supported "ctype" values? 10:58
jnthn It seems that's what'd be needed to handle it portably 10:59
timotimo righto 11:00
good thing we have enough negative numbers to handle most common integer and float types in C
ugh. a 19 megabytes profile from --profile-compile of SDL2::Raw's Raw.pm 11:04
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
11:23 kjs_ joined
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:24
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 12:24 FROGGS joined
timotimo also deduplicates filenames in the "id-to-thing" map 12:34
using negative numbers, neat/evil trick
the profile-compile output of SDL2::Raw went from 18 megabytes to 12 megabytes already 12:35
OK, deduplicating the filenames from the initial "dictionary" gives almost no improvement, which isn't a big surprise 12:38
er ... json doesn't actually like negative numbers as object keys 12:44
so i'll just throw the deduplication out of that part
13:00 FROGGS joined
ilmari s/negative // # they have to be strings 13:10
timotimo hm
ilmari m: from-json(to-json({ 42 => "wat" }))
camelia ( no output )
ilmari m: say from-json(to-json({ 42 => "wat" })) 13:11
camelia rakudo-moar 9aa014: OUTPUT«42 => wat␤»
ilmari huh?
timotimo well, => already makes strings
from its LHS if it's a literal
ilmari m: say from-json(to-json( 42 => "wat" ))
camelia rakudo-moar f0a21b: OUTPUT«Invalid JSON: {␤ 42 : "wat"␤}␤ in block <unit> at /tmp/RRzQ7HkbLB line 1␤␤»
ilmari that was the one
timotimo mhh 13:12
ilmari a bare pair, not a hash
14:32 kjs_ joined 17:13 domidumont joined, FROGGS[mobile] joined 17:40 vendethiel joined 18:12 domidumont joined 18:23 patrickz joined 18:29 vendethiel joined 18:53 zakharyas joined 18:58 vendethiel joined 18:59 domidumont joined 19:13 kjs_ joined 20:27 btyler joined 21:32 colomon joined
dalek arVM/heap-profiler: 5740e33 | jnthn++ | / (5 files):
Sketch in heap profiler data structures.
 21:37
21:41 vendethiel joined 22:32 colomon joined 22:36 colomon_ joined 22:49 mojca 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!