github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo now the code is really messy from my stuff, but i can probably just stash it off to a never-to-be-used-again branch and redo the trivial fix 00:00
jnthn timotimo++ # clearing up after fixing stuff 00:05
timotimo i guess that part of the grant can now begin 00:13
MasterDuke jnthn: is something like github.com/retupmoca/P6-Compress-Z...42e1b5dfff what you meant for the module to implement?
timotimo it'll be an entire can of happy 00:15
MasterDuke: i'd expect so
MasterDuke good. run time with that patch for `use Compress::Zlib; my $a = gzslurp("/home/dan/p6/100k.txt.gz"); say $a.lines.elems` decreases from ~9s to ~7s 00:16
timotimo nice
ah, of course in the master branch the heapanalyzer was correctly reading the binary format 00:23
jnthn MasterDuke: Yes, but wouldn't the encoding be avoided entirely if it scanned for a newline in the buf before doing the decoding? Of course, that bypasses normalization, but that's not a concern for the default \n 00:25
Or maybe even better: you can use the decoder API! 00:27
Like IO::Handle does
Which will do the line search and buffer management for you, but in carefully optimized code inside of MoarVM :)
MasterDuke jnthn: thanks, i'll take a look. i really don't know those APIs, but will try to base off of IO::Handle 00:29
jnthn: no idea why i was just reminded of this, but did you see my comment here? github.com/MoarVM/MoarVM/commit/d6...ba173bce40 00:30
jnthn MasterDuke: Pretty sure not; I think it just retrieves it from the STable which stores it as a char * rather than MVMString * since we always need it inside of the VM anyway 00:32
timotimo jnthn: were you aware that we never free CStruct's memory? :o 00:33
if you use CStruct in any modules in Cro's dependency chain, that might want a looking at
jnthn timotimo: Uh...ouch o.O 00:34
That might explain SSL leakage
MasterDuke jnthn: cool
jnthn Sorry I missed it, though. 00:35
timotimo no prob
i'm working on a patch
jnthn \o/
timotimo without the ability to influence whether GC will free a CStruct or not it'll probably be useless
jnthn It's probably a hard problem...
Yes, exactly, there's not a "one answer fits all"
timotimo so many options
jnthn Who owns it, etc. 00:36
MasterDuke jnthn: not sure who that sorry was too, but if me, np
timotimo i was ruminating earlier today or yesterday about the idea of having ownership represented by an object that can be passed around
jnthn MasterDuke: It was aimed at you, but I'm going to claim it was multicast :P
timotimo it'd hopefully also make "this CStruct's pointer actually points into another object" situation work out, when the original object gets GC'd
jnthn timotimo: Hm, and you can attach multiple things to that ownership "context"?
timotimo i'd expect the pointer to go the other way 00:37
i.e. objects hold on to the ownership object
and you could use nativecast with "transfer", maybe "share", and you could $object.^release-ownership to say "C now takes care of this"
BBIAB 00:38
the ownership object would be very closely tied to the pointer for the buffer, especially for objects inside other objects that don't want to have to carry an offset around all the time 00:41
but introducing such an API makes me want to make other stuff base on it ...
TBH you can at the moment submethod DESTROY { free(self) } in all of your CStructs 00:44
00:46 patrickb joined 00:50 patrickz left
timotimo i want to re-engineer the binary format, the index and such are all so ad-hoc 00:56
but i can totally use buf's read and write functions now. though my own implementation of them would shift the data out of the buf 01:00
pro: no need to keep an index counter around; con: doesn't work with Blob, unless you use a copy
jnthn Sorry, as busy packing :) 01:15
*was
Yeah, of course manual free call is an option too, but not ideal 01:16
Also it can be nice to have it more timely
Though of course the consumer has to opt in to that
sleep time o/ 01:25
01:29 lucasb left 02:44 patrickb left 03:33 Kaiepi left 04:37 MasterDuke left 05:29 Kaiepi joined 09:03 domidumont joined 11:05 patrickb joined 11:18 dogbert21 left 11:22 lucasb joined 14:03 domidumont left
timotimo would our ConcBlockingQueue benefit from having the nodes allocated with the fixed size allocator? or would the fact that it gets used across threads mean it'd be a bad idea for FSA and perhaps malloc can do a better job? we do have some across-thread-usage-related optimizations in it, though? 15:25
15:39 hoelzro_ left, hoelzro joined 15:45 timewasteable6 joined, ChanServ sets mode: +o timewasteable6, timewasteable6 left
timotimo i don't quite understand why there's a ConcBlockingQueue with a value in it that has an st pointer of null 15:49
15:51 MasterDuke joined 15:52 MasterDuke left, MasterDuke joined
timotimo what does the GC do with this object that describe_ref doesn't to cause it to crash, i wonder 15:53
somehow the node rather than its value ends up in the worklist 16:05
which ... huh?
a node's next is the same as its value ?!!? 16:17
i haven't heard exherbo in like a decade 16:18
MasterDuke i've been seeing a lot of profiles recently (e.g., from the code rindolf just posted in #perl6) that have identity github.com/rakudo/rakudo/blob/mast...ns.nqp#L52 show up pretty high in the routines 16:19
it also has github.com/rakudo/rakudo/blob/mast....nqp#L1607 (which i don't think i've seen before) even higher 16:22
timotimo pah. someone else shall do something about ConcBlockingQueue's refs 16:36
16:40 MasterDuke left 16:41 lucasb left 16:49 MasterDuke joined 16:50 MasterDuke left, MasterDuke joined 18:07 domidumont joined 18:49 domidumont left 19:53 lucasb joined 20:06 bartolin left 20:21 bartolin joined 22:15 Kaiepi 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!