00:06 skids joined
[Coke] (hesi 00:24
timotimo he what? 00:26
geekosaur ...hesiod? 00:40
[Coke] weird. 01:08
01:18 stmuk_ joined
geekosaur (for maximum confusion that probably should have been "odd." :p ) 01:20
[Coke] he! 01:25
02:11 lizmat_ joined 07:11 FROGGS joined
[Tux] test 21.727 07:59
test-t 12.210
csv-parser 25.203
08:57 RabidGravy joined
dalek ast: 4626476 | lizmat++ | S03-operators/buf.t:
Add some Blob/Buf.allocate/reallocate tests
ast: 90c27df | lizmat++ | S03-operators/buf.t:
Also check Blob.reallocate failure

And some better messaging
13:56 RabidGravy joined
lizmat afk for the next 10 hours or so& 14:07
15:04 skids joined
[Coke] I'll get the release out the door tomorrow; sorry, busy day or three at work. 15:26
perlpilot [Coke]++ 16:54
jnthn m: say 1.87 / 69.83 17:39
camelia rakudo-moar 54ce66: OUTPUT«0.026779␤»
jnthn m: say 1.87 R/ 69.83
camelia rakudo-moar 54ce66: OUTPUT«37.342246␤»
jnthn wow :)
timotimo i really want to see what that wow is for now :) 17:48
17:48 geekosaur joined
timotimo .o( maybe the size of a heap dump vs the size of a program that doesn's dump ) 17:49
perlpilot whatever it is is 37 times better/faster/stronger ;)
jnthn No, nothing to do with heap dumps directly
More that I'm going to write my heap dump analyzer in Perl 6. 17:50
timotimo what, really?
jnthn And checked one thing I thought would bottleneck it
And now am fixing it somewhat
timotimo impressed
jnthn timotimo: Yes, because we really need to be able to handle this size of data.
timotimo yeah, we do have to 17:51
jnthn And since I'm working on performance stuff, it makes sense that I bang my own head against the places we're just too slow
timotimo aye 17:52
so this ratio was one thing you tried in your script vs another thing, eh?
jnthn Will push soon when spectest is done...provided it comes out ok :)
[Coke] jnthn: better you than most other people, for sure. ;)
dalek p: 034121e | jnthn++ | src/vm/moar/HLL/Backend.nqp:
Put "my" heap snapshot output in place.

This replaces the timotimo++ work on this with the format I had in mind and was still putting together locally.
p: 0a8327f | jnthn++ | tools/build/MOAR_REVISION:
Bump MOAR_REVISION for heap snapshot support.
jnthn timotimo: If there's anything you're unhappy about in my run of it, let me know :)
timotimo only if i get to also change your analyzer script at the same time :) 17:56
psch m: .say for $*ARGFILES 17:57
camelia rakudo-moar 54ce66: OUTPUT«write string requires an object with REPR MVMOSHandle␤ in block <unit> at /tmp/HYZGP9ziKa line 1␤␤»
psch happens locally with or without a file as @*ARGS[1] 17:58
timotimo too optimized, eh?
psch not even sure what it wants to write there...
timotimo well, you're calling .say on a file handle
m: .say("hi") for $*ARGFILES
camelia rakudo-moar 54ce66: OUTPUT«write string requires an object with REPR MVMOSHandle␤ in block <unit> at /tmp/WD1_JfyQjX line 1␤␤»
psch hm, still at 2016.02-194-g5eaa15d locally
dalek kudo/nom: 72ba5a1 | jnthn++ | src/core/Str.pm:
Add a fast-path for simples cases of Str.Int.

This gets a factor of 37 speedup for things like '100'.Int.
jnthn As you might imagine, the heap analyzer will need the .Int a lot of Strs :) 17:59
timotimo *neat*
we recently had a little benchmark in the channel that read a file of an-int-per-line and sorted that 18:00
[Coke] jnthn: doesn't Perl 6 need that also?
timotimo i imagine that becomes a bit faster now
but it'll not handle a - at the beginning
jnthn [Coke]: Need what also?
[Coke] the ability to convert a string to an int when parsing perl 6.
Just wondering if that speeds up the compiler itself. 18:01
timotimo hm, the compiler will go via nqp's built-in
jnthn [Coke]: I think the parser already figures out what it's looking at and manages to do the same thing already. :)
(So, it already has the win.) 18:02
timotimo jnthn: you don't get all the warnings from the heap compiler about incompatible pointer types? 18:04
jnthn Nope
timotimo src/profiler/heapsnapshot.c:15:13: note: expected ‘void **’ but argument is of type ‘MVMHeapSnapshotCollectable ** {aka struct MVMHeapSnapshotCollectable **}’
static void grow_storage(void **store, MVMuint64 *num, MVMuint64 *alloc, size_t size) {
^- this times ten or twenty :)
jnthn wtf
I thought the point of a void pointer was to not bitch :/
MSVC doesn't :) 18:05
Wonder if void ** doesn't count
timotimo that's a possibility 18:06
jnthn Guess we could try taking that and casting to ** :)
But then you lose the wrong indirection warnings which are useful :/
timotimo taking void * and casting to void **?
jnthn Yeah
Anyways, time for a break :) 18:08
19:03 sortiz joined 19:22 FROGGS joined
nine Oh, it seems like I've made it through compilation of the EVAL itself and it's now dieing on serializing the outer comp unit 19:43
[Coke] progress? 19:53
20:12 synopsebot6 joined
nine I like to think so :) 20:14
[Coke] \o/ 20:43
22:49 AlexDaniel joined 23:11 Woodi joined 23:55 Ben_Goldberg joined