02:03 colomon joined 03:02 MadcapJake` joined
ugexe i opened a PR to the distribution proposals ive been going on about 04:14
[Tux] test 22.106 06:23
test-t 12.376
csv-parser 25.764
lizmat And finally, another Perl 6 Weekly hits the net: p6weekly.wordpress.com/2016/03/29/...heapsters/ 08:34
08:35 RabidGravy joined
lizmat hopes jnthn liked the reference 10:25
jnthn lizmat++ 10:26
It started out as a pun on "happy easter" and then took on a life of its own :P 10:27
lizmat I'm not sure whether people got that I was referring to the CLI of the heap inspection tool 10:28
10:54 colomon joined
dalek kudo/nom: a424f07 | lizmat++ | src/core/Order.pm:
Make Object:D cmp Object:D 2x as fast

The basic version was testing for Inf/-Inf. By adding candidates for Real/Any and Any/Real and moving the test for Inf/-Inf in there, we no longer need to do that in the basic version. Also added a very cheap test for identity, so comparing with itself should be a lot faster as well.
Also nqpified the ORDER helper sub, just in case it would make a difference.		 11:15
lizmat sometimes I think we should make sort() an iterator as well 11:18
with the push-all case using the current sort 11:19
and the pull-one case using an algorithm based on min
jnthn That'd accidentally n**2 things if you did for @foo.sort { }, no? 11:20
lizmat so that if you're only interested in the top 5 of a 10000 list, it would only "sort" 5 elements
jnthn: depends on where you would store the result 11:21
my @a = @foo.sort
jnthn imho it's algorithmically different enough that it'd want a different method name
lizmat would use the push-all, so current algortithm
jnthn Right, for the `for` loop wouldn't
lizmat true
jnthn And for %h.sort(-*.value) { } is pretty common
lizmat perhaps .top :-) 11:22
for @scores.top(5) { }
lizmat stops with wandering thoughts :-) 11:23
nine Well if the iterator returned by .sort had a .top method, it would know which way to choose. 11:25
jnthn @foo.top(5) reads pretty nice...
I guess .head(5, :by(...)) is another option...
Then you'd get naturally end up with .tail(5, :by(...)) too 11:26
nine +1 for new .head and .tail candidates 11:27
Having .head and .first is already confusing enough. Adding .top wouldn't help there at all :)
jnthn Yeah :) 11:28
lizmat we don't have any native binary chop function, right ? 11:29
s/native/builtin/
nine jnthn: my "Code ref '' does not exist in serialization context" error is about this one: github.com/rakudo/rakudo/blob/nom/....nqp#L2008 11:31
jnthn: any idea how this can happen when in line 2021 we call add_root_code_ref? 11:32
jnthn nine: I'm assuming EVAL now shares the parent SC? 11:34
(In the context you're fixing...)
nine yes
jnthn And you share the root code refs I guess? 11:36
I wonder if it's something to do with the fact that compilation causes fixups of the stubs to the real thing 11:37
And then it gets confused because we added the stub into the root set but didn't update it with the real thing later
Which is what github.com/rakudo/rakudo/blob/nom/....nqp#L2332 takes care of for the compile_in_context case 11:38
But maybe isn't happening in the code-path you're taking?
nine I'll have a look when I'm at home. 11:39
I've tried sharing everything but @!fixup_tasks and @!load_dependency_tasks as those would trigger the unwanted serialization 11:40
Oh and of course $!precomp_mode which I set to 0 for compile time EVALs
jnthn *nod* 11:41
Yeah, the symptoms fit pretty well with what I described then.
nine So it's good that I asked, because the chance of me discovering this by myself was close to 0 :) 11:43
12:33 |Tux| joined 12:57 Skarsnik joined 13:14 RabidGravy joined
dalek kudo/nom: 330f814 | lizmat++ | tools/build/makeMAGIC_INC_DEC.pl6:
Some more WIP on magic inc/dec opts
 13:35
13:52 skids joined 14:21 colomon joined 16:23 vendethiel- joined 17:03 vendethiel joined 17:06 Hotkeys_ joined 17:07 sortiz_ joined 17:08 timotimo joined 17:17 vendethiel- joined 18:16 FROGGS joined 18:32 AlexDaniel joined 20:06 Ven joined
timotimo jnthn: should i invest any time into a "only keep the latest heap snapshot" flag? (env var or something) 20:23
because long-running processes are impossible to heap-analyze, as the memory usage rises constantly and so does the time for a gen2 collection, AFAICT
jnthn I don't think so 20:38
I think we'll want to solve that with some vm-exposes-a-socket approach later 20:39
timotimo so you can "vacuum up" results at any time and make older snapshots disappear from the gen2?
jnthn don't understand the gen2 thing 20:41
We don't store snapshots in gen2 20:42
We only do any gen2 allocations right at the end to get the results back into VM space
Which you'd not need to do if you were shoving them off over a socket.
Though we might also consider writing that server in NQP or even Perl 6, and having it run in a seprate MoarVM instance in the same process :) 20:45
nine jnthn: very weird. The stub in question is never executed and thus never replaced by the real thing. Also note that the EVAL actually compiles and executes successfully. It's the outermost comp unit that fails (A.pm in A uses B uses C). 20:48
20:50 Ven joined
timotimo oh, ok 21:12
i must have been wrong, then. it looked like memory usage was growing rather rapidly and every new snapshot take was taking longer and longer, so i assumed something about the heap profiler wasn't scaling well. must have been the program, instead
jnthn timotimo: Um, actualy program memory use will, but the GC'd heap size won't, if that makes sense :) 21:14
*actual
nine: But...we replace all the things in fixup?
timotimo next step for me will be a "more" command for the heapanalyzer shell 22:04
now it's implemented :) 22:39
it doesn't handle "there weren't any more results" very well, but oh well :)
23:27 skids 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!