Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-01-20

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

All times shown according to UTC.

Time Nick Message
00:02 vendethiel joined #moarvm
02:24 vendethiel joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:54 moritz joined #moarvm
05:12 vendethiel joined #moarvm
05:26 vendethiel- joined #moarvm
05:40 leedo joined #moarvm
07:04 vendethiel joined #moarvm
07:09 domidumont joined #moarvm
07:14 domidumont joined #moarvm
07:25 domidumont1 joined #moarvm
07:32 domidumont joined #moarvm
07:37 domidumont1 joined #moarvm
07:53 FROGGS joined #moarvm
08:08 Ven joined #moarvm
08:10 vendethiel joined #moarvm
08:17 kjs_ joined #moarvm
08:30 zakharyas joined #moarvm
08:36 vendethiel joined #moarvm
08:55 vendethiel- joined #moarvm
09:24 kjs_ joined #moarvm
09:39 leont joined #moarvm
10:28 brrt joined #moarvm
10:32 brrt good * #moarvm
10:32 kjs_ joined #moarvm
10:33 vendethiel joined #moarvm
10:37 jnthn o/ brrt
10:38 brrt \o jnthn
10:38 * brrt has started on the implementation of pseudotiles this morning :-)
10:39 brrt and this works except that we're jumping to the wrong space, so that's probably a labelling issue
10:47 brrt how are things, though :-)
10:47 brrt do you have any plans for optimisation work currently?
10:49 FROGGS joined #moarvm
10:50 jnthn brrt: I'm still a bit tired, but gradually starting to get back in to things
10:50 jnthn It seems I need to make some kind of rulings of how we'll do language back/forward compat before I get to doing opts :)
10:51 brrt well..  not meaning to rush you :-)
10:52 brrt yeah, that seems like important work, too
10:52 jnthn I've lots of ideas for opt work. But I just wasn't feeling up to doing much of anything, or distracted with errands, for the first half of January. And now am tied up doing $dayjob things, to make sure I put food on the family this month. :-)
10:52 brrt aye
10:53 brrt well, i for one at least am interested in speculations too :-)
10:53 jnthn (No, the situation isn't *that* bad, but I should still actually do my $dayjob. :))
10:53 jnthn (And it's quite fun at the moment anyway.)
10:53 jnthn Well, got various plans. Reducing the cost of invocation and closures is one big one.
10:53 brrt (that is a lucky position to be in, to have a fun $dayjob)
10:54 brrt oh, ++ for that one
10:54 jnthn Got a gradually congealing design
10:54 nwc10 jnthn: I don't think that it's a good idea to put food onto the family. *Into* the family, maybe. Or onto the table.
10:54 jnthn But not quite sure I can make it work yet.
10:54 brrt i have not measured, but a very strong feeling that invocation is a very major cost currently
10:55 jnthn But overall, the idea is to have a chunk of memory that represents a "stack", and only internal frame references are allowed
10:55 jnthn And if we ever need an external one, the frame is then promoted to the heap, and it then becomes a GC-able.
10:56 jnthn So long-living closures can then be handled by the normal generational scheme, which they ain't at present.
10:56 jnthn (Which costs us a bit in CORE.setting compilation)
10:57 brrt sounds pretty good, and doable eventually, even if pretty complex
10:57 brrt fwiw, i'm going to try and meet andy wingo at fosdem, and see if we can talk a bit about compilers
11:03 Ven joined #moarvm
11:28 vendethiel joined #moarvm
11:51 vendethiel joined #moarvm
12:19 vendethiel joined #moarvm
12:37 llfourn joined #moarvm
13:16 kjs_ joined #moarvm
13:27 vendethiel joined #moarvm
13:30 dalek joined #moarvm
13:38 llfourn joined #moarvm
13:47 pochi_ joined #moarvm
13:47 colomon_ joined #moarvm
13:49 ggoebel8 joined #moarvm
13:51 nine_ joined #moarvm
13:51 moritz_ joined #moarvm
13:51 psch_ joined #moarvm
14:02 tadzik joined #moarvm
14:02 FROGGS joined #moarvm
14:03 mtj_ joined #moarvm
14:03 ingy joined #moarvm
14:03 retupmoca joined #moarvm
14:07 [Coke] this is actually a moarvm config bug: RT #127308
14:09 _longines joined #moarvm
14:23 brrt [Coke]: link?
14:26 vendethiel joined #moarvm
14:27 [Coke] https://rt.perl.org/Ticket/Display.html?id=127308
14:33 brrt thanks
14:39 kjs_ joined #moarvm
14:54 kjs_ joined #moarvm
15:00 synopsebotimo joined #moarvm
15:05 Ven joined #moarvm
15:19 kjs_ joined #moarvm
15:43 FROGGS joined #moarvm
16:37 kjs_ joined #moarvm
16:56 vendethiel joined #moarvm
16:59 ashleydev joined #moarvm
17:10 kjs_ joined #moarvm
17:34 virtualsue joined #moarvm
18:00 FROGGS joined #moarvm
18:03 domidumont joined #moarvm
18:09 kjs_ joined #moarvm
18:12 leont joined #moarvm
18:16 flussenc1 joined #moarvm
18:18 xiaomiao joined #moarvm
18:20 timo joined #moarvm
18:28 tadzik joined #moarvm
19:21 leont joined #moarvm
19:36 Guest72620 RT #12345
21:47 colomon joined #moarvm
22:02 colomon joined #moarvm
22:02 timotimo is turning on link-time-optimization required to make dead code elimination better?
22:05 geekosaur "yes"?
22:06 timotimo a friend is telling me that it's not necessary for statically linked stuff
22:06 geekosaur you can;t eliminate a dead global function unless you can do LTO, eiter manually by putting each function in its own file, creating a .a from them, and linking main() against that, or enabling compiler+inker LTO
22:06 timotimo but i seem to remember something else
22:06 geekosaur static you can do because if it's not used in that file and no pointers to it are leaked, it can be remoed
22:06 geekosaur (the "no pointers" part may be what you are remembering)
22:07 timotimo hmm
22:07 geekosaur again you'd need comiler+linker support to catch that properly
22:07 colomon joined #moarvm
22:13 timotimo mhh
22:33 colomon joined #moarvm
23:29 llfourn joined #moarvm

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