Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-03-29

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

All times shown according to UTC.

Time Nick Message
02:03 colomon joined #p6dev
03:02 MadcapJake` joined #p6dev
04:14 ugexe i opened a PR to the distribution proposals ive been going on about
06:23 [Tux] test            22.106
06:23 [Tux] test-t          12.376
06:23 [Tux] csv-parser      25.764
08:34 lizmat And finally, another Perl 6 Weekly hits the net: https://p6weekly.wordpress.com/2016/03/29/2016-13-a-language-for-heapsters/
08:35 RabidGravy joined #p6dev
10:25 * lizmat hopes jnthn liked the reference
10:26 jnthn lizmat++
10:27 jnthn It started out as a pun on "happy easter" and then took on a life of its own :P
10:28 lizmat I'm not sure whether people got that I was referring to the CLI of the heap inspection tool
10:54 colomon joined #p6dev
11:15 dalek rakudo/nom: a424f07 | lizmat++ | src/core/Order.pm:
11:15 dalek rakudo/nom: Make Object:D cmp Object:D 2x as fast
11:15 dalek rakudo/nom:
11:15 dalek rakudo/nom: The basic version was testing for Inf/-Inf.  By adding candidates
11:15 dalek rakudo/nom: for Real/Any and Any/Real and moving the test for Inf/-Inf in there,
11:15 dalek rakudo/nom: we no longer need to do that in the basic version.  Also added a
11:15 dalek rakudo/nom: very cheap test for identity, so comparing with itself should be a
11:15 dalek rakudo/nom: lot faster as well.
11:15 dalek rakudo/nom:
11:15 dalek rakudo/nom: Also nqpified the ORDER helper sub, just in case it would make a
11:15 dalek rakudo/nom: difference.
11:15 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a424f07447
11:18 lizmat sometimes I think we should make sort() an iterator as well
11:19 lizmat with the push-all case using the current sort
11:19 lizmat and the pull-one case using an algorithm based on min
11:20 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
11:21 lizmat jnthn: depends on where you would store the result
11:21 lizmat my @a = @foo.sort
11:21 jnthn imho it's algorithmically different enough that it'd want a different method name
11:21 lizmat would use the push-all, so current algortithm
11:21 jnthn Right, for the `for` loop wouldn't
11:21 lizmat true
11:21 jnthn And for %h.sort(-*.value) { } is pretty common
11:22 lizmat perhaps .top  :-)
11:22 lizmat for @scores.top(5) {   }
11:23 * lizmat stops with wandering thoughts  :-)
11:25 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...
11:25 jnthn I guess .head(5, :by(...)) is another option...
11:26 jnthn Then you'd get naturally end up with .tail(5, :by(...)) too
11:27 nine +1 for new .head and .tail candidates
11:27 nine Having .head and .first is already confusing enough. Adding .top wouldn't help there at all :)
11:28 jnthn Yeah :)
11:29 lizmat we don't have any native binary chop function, right ?
11:29 lizmat s/native/builtin/
11:31 nine jnthn: my "Code ref '' does not exist in serialization context" error is about this one: https://github.com/rakudo/rakudo/blob/nom/src/Perl6/World.nqp#L2008
11:32 nine jnthn: any idea how this can happen when in line 2021 we call add_root_code_ref?
11:34 jnthn nine: I'm assuming EVAL now shares the parent SC?
11:34 jnthn (In the context you're fixing...)
11:34 nine yes
11:36 jnthn And you share the root code refs I guess?
11:37 jnthn I wonder if it's something to do with the fact that compilation causes fixups of the stubs to the real thing
11:37 jnthn And then it gets confused because we added the stub into the root set but didn't update it with the real thing later
11:38 jnthn Which is what https://github.com/rakudo/rakudo/blob/nom/src/Perl6/World.nqp#L2332 takes care of for the compile_in_context case
11:38 jnthn But maybe isn't happening in the code-path you're taking?
11:39 nine I'll have a look when I'm at home.
11:40 nine I've tried sharing everything but @!fixup_tasks and @!load_dependency_tasks as those would trigger the unwanted serialization
11:40 nine Oh and of course $!precomp_mode which I set to 0 for compile time EVALs
11:41 jnthn *nod*
11:41 jnthn Yeah, the symptoms fit pretty well with what I described then.
11:43 nine So it's good that I asked, because the chance of me discovering this by myself was close to 0 :)
12:33 |Tux| joined #p6dev
12:57 Skarsnik joined #p6dev
13:14 RabidGravy joined #p6dev
13:35 dalek rakudo/nom: 330f814 | lizmat++ | tools/build/makeMAGIC_INC_DEC.pl6:
13:35 dalek rakudo/nom: Some more WIP on magic inc/dec opts
13:35 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/330f8149d8
13:52 skids joined #p6dev
14:21 colomon joined #p6dev
16:23 vendethiel- joined #p6dev
17:03 vendethiel joined #p6dev
17:06 Hotkeys_ joined #p6dev
17:07 sortiz_ joined #p6dev
17:08 timotimo joined #p6dev
17:17 vendethiel- joined #p6dev
18:16 FROGGS joined #p6dev
18:32 AlexDaniel joined #p6dev
20:06 Ven joined #p6dev
20:23 timotimo jnthn: should i invest any time into a "only keep the latest heap snapshot" flag? (env var or something)
20:23 timotimo 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
20:38 jnthn I don't think so
20:39 jnthn 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?
20:41 jnthn don't understand the gen2 thing
20:42 jnthn We don't store snapshots in gen2
20:42 jnthn We only do any gen2 allocations right at the end to get the results back into VM space
20:42 jnthn Which you'd not need to do if you were shoving them off over a socket.
20:45 jnthn 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:48 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:50 Ven joined #p6dev
21:12 timotimo oh, ok
21:12 timotimo 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
21:14 jnthn timotimo: Um, actualy program memory use will, but the GC'd heap size won't, if that makes sense :)
21:14 jnthn *actual
21:14 jnthn nine: But...we replace all the things in fixup?
22:04 timotimo next step for me will be a "more" command for the heapanalyzer shell
22:39 timotimo now it's implemented :)
22:39 timotimo it doesn't handle "there weren't any more results" very well, but oh well :)
23:27 skids joined #p6dev

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