Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-20

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

All times shown according to UTC.

Time Nick Message
00:10 LLamaRider joined #moarvm
01:36 jepeway joined #moarvm
01:45 dalek MoarVM: 6698db9 | timotimo++ | src/6model/reprs/CStruct.c:
01:45 dalek MoarVM: guard against absent "inlined" keys in CStruct composition
01:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6698db9aa0
01:47 dalek MoarVM: aab1400 | timotimo++ | src/6model/reprs/CUnion.c:
01:47 dalek MoarVM: also guard against absent "inlined" key in CUnion composition
01:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/aab140000c
01:48 timotimo these two commits can most probably be reverted when nqp gets its cunion branch merged
01:49 timotimo because then it will invariably have the inlined flag set (right?)
04:23 vendethiel joined #moarvm
05:07 vendethiel joined #moarvm
05:11 FROGGS[mobile] ohh, had not tested and thought about that
05:12 FROGGS[mobile] timotimo++
07:02 Ven joined #moarvm
07:11 zakharyas joined #moarvm
07:47 FROGGS joined #moarvm
08:02 FROGGS timotimo: I hope you did not lose too much time on the repr compose fix :S
08:09 Ven joined #moarvm
08:12 vendethiel joined #moarvm
09:39 vendethiel joined #moarvm
10:07 vendethiel joined #moarvm
10:07 lizmat joined #moarvm
10:14 lizmat_ joined #moarvm
10:52 Ven joined #moarvm
12:00 Ven joined #moarvm
12:04 vendethiel joined #moarvm
12:53 vendethiel joined #moarvm
13:31 brrt joined #moarvm
13:31 brrt \o
13:33 jnthn o/
13:35 brrt \o/
13:36 brrt i really really should put something on my blog now, shouldnt i
13:36 brrt oh, also
13:37 brrt i've taken it on myself to study at least one compiler-related paper each week until I start my project
13:37 jnthn Cool :)
13:37 brrt so I was wondering if anyone had any papers left :-)
13:37 jnthn I got sick around the weekend, and have been mostly devoting my time to taking care of things I really have needed to do and sleeping.
13:38 nwc10 "sleeping" is not by default in the list of "things I really have needed to do"? :-) [or is that :-(]
13:38 brrt sleeping is reducing technical mental debt :-P
13:38 brrt apparantly, some people have pretty large mental credits
13:38 jnthn It is in the default list, it's more a matter of quantity. :)
13:39 jnthn (And yeah, I'm a lot better by now, I just need to take good care of myself to make sure I stay that way.)
13:41 brrt yes, that's a pretty good idea
13:49 timotimo FROGGS: only like ten minutes
13:49 timotimo before i fell asleep i was thinking about the profiler and how it logs allocations
13:49 timotimo and i thought perhaps the logging instruction is keeping allocating instructions alive simply by wanting to mark the allocation
13:50 timotimo so i'll investigate that today
13:55 JimmyZ brrt: : maybe http://wiki.luajit.org/Home#LuaJIT-Internals ?
13:57 brrt yes, i've been looking at that :-)
13:58 vendethiel joined #moarvm
14:52 vendethiel joined #moarvm
14:54 timotimo hmm. what's a good piece of code to run to figure out if allocations can be spesh'd out?
15:06 FROGGS joined #moarvm
15:15 vendethiel joined #moarvm
15:24 jnthn timotimo: I don't think logging instructions bump usage
15:24 jnthn timotimo: Especially as they don't make it into the final code ever
15:24 jnthn timotimo: And we dont' do any opts needing usage until after we tossed the logging instrs
15:25 timotimo logging, no; but prof_allocated yes
15:25 jnthn Also, note that create is marked as :pure, so those allocations that simply go unused get tossed already
15:25 jnthn Oh...
15:25 timotimo :)
15:25 jnthn True. :)
15:25 jnthn That's an interesting composition problem. :)
15:25 timotimo agreed
15:25 timotimo i have no data to back up my theory of "profiling increases allocations", however
15:26 timotimo i do have a patch already, though. because that was pretty easy to write the first version of
15:26 timotimo and i don't really have test code that could show if any problems exist :(
15:26 jnthn timotimo: I suspect you may be right about it.
15:26 jnthn timotimo: An NQP sub that does "sub foo() { my @x; 1 }" should show a create being eliminated
15:26 timotimo great
15:27 timotimo but i'll be AFK for a bit first
15:33 jnthn dinner &
15:56 timotimo um ... in the spesh log i don't see any prof_ ops at all
15:57 timotimo even after throwing out my local changes
15:59 timotimo the create actually gets thrown out already
16:02 timotimo maybe the profiling stuff gets added after a frame has been spesh'd, rather than before?
16:08 Ven joined #moarvm
16:51 vendethiel joined #moarvm
17:18 vendethiel joined #moarvm
17:33 timotimo now i'm out of cool ideas again
17:43 vendethiel joined #moarvm
18:19 dalek MoarVM: 6abbb1a | FROGGS++ | src/6model/reprs/CStruct.c:
18:19 dalek MoarVM: fix handling of inlined CStructs
18:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6abbb1a2de
18:25 vendethiel joined #moarvm
18:30 dalek MoarVM: 3898ac4 | FROGGS++ | src/6model/reprs/CUnion. (2 files):
18:30 dalek MoarVM: handle CUnions in CUnions
18:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3898ac4e03
18:42 timotimo maybe i'll just have a quick no-strings-attached look at deopt mechanisms
18:53 timotimo hmm, so the implementations of guard* directly call into deopt_one
18:54 timotimo so it's not quite as easy as making them look at an annotation right in front of them or something like that
18:54 timotimo maybe i should build a mirrored set of those instructions that branch instead of deopting
19:02 timotimo i probably don't want to compile a bridge for every guard, so making the guard* just branch and then having a generic deoptone/deoptall instruction isn't a good option IMO
19:03 timotimo i'll still want the generic deoptone/deoptall instruction for the end of the bridge, of course
19:08 zakharyas joined #moarvm
19:11 dalek MoarVM: 4102a25 | FROGGS++ | src/6model/reprs/CStruct.c:
19:11 dalek MoarVM: round CStruct up to a multiple of void*
19:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4102a25b1a
19:57 brrt joined #moarvm
20:08 nwc10 jnthn: http://paste.scsys.co.uk/480880 -- the same backtrace, attempting to get a mutex from within the GC
20:11 nwc10 problem is that tc->instance->sc_weakhash is locked
20:11 nwc10 line 15 of sc.c
20:11 nwc10 and agan, attempted at line 93 of SCRef.c
20:12 nwc10 comment at line 22 of sc.c explicitly thinks that this is impossible.
20:12 nwc10 clearly not quite foolproof
20:15 nwc10 bogosity seems to be this:     MVMObject *obj = REPR(type)->allocate(tc, STABLE(type));
20:16 nwc10 I assume that that's a pointer to MVM_gc_allocate_object
20:16 nwc10 and that *that* is ignoring the "use gen2, dammit" flag
20:28 brrt uhm, lets see
20:30 brrt nwc10 - do you have a live gdb session
20:31 brrt (i'd pay money for a service that let you share debugging sessions.)
20:32 brrt otherwise i'd ask you questions about it
20:35 brrt if you do have it live, can you give me the output of *tc
20:38 colomon joined #moarvm
20:45 btyler brrt: tmux on a host you can both shell to? :)
20:46 brrt hmmm
20:46 brrt that would work, but there is probably no such host
20:46 btyler nothing in p6 ecosystem space?
20:47 btyler some folks have shell accounts for running irssi, I seem to recall
20:47 brrt i don't :-)
20:49 btyler ingy actually has some application for precisely this purpose. it fires up a cheap digital ocean or AWS host, imports bash/tmux profiles and ssh keys for both participants
20:50 btyler https://github.com/ingydotnet/pairup there it is
20:50 btyler and with that I'll stop going offtopic here
20:50 japhb screen will work as well as tmux.  In fact, I have specifically used screen to do multi-user debugging many times in the past
20:50 btyler yes, apologies, no implied "tmux > screen"
20:51 japhb (Bloody necessary when you're sharing the serial console of the one hardware dev kit you could get your hands on.)
20:51 japhb btyler: I wasn't taking it that way.  I meant "if you can't install tmux somewhere, screen will do for this application, and it's more often already installed"
20:52 btyler ah of course
20:52 japhb It's like being an emacs person and knowing you can always fallback to vi, because it's hard to find a *nix machine without it.  :-)
20:53 brrt yes, that is the great feature of vi
20:55 brrt ok, but the point is
20:55 brrt i don't have to pay money for that
20:55 brrt but in about 18 months time
20:55 brrt somebody will make a startup out of it
20:56 brrt and they'll be valuated at a billion dollars
20:56 brrt if and only if they say they'll kill e-mail
21:43 timotimo tmux is way better, btw :)
21:47 lizmat I once had Jesus tell me I should use tmux  :-)
21:48 lizmat (it's a long story)
21:49 colomon joined #moarvm
21:59 brrt that i can imagine
21:59 brrt how long
22:25 timotimo was i the jesus?
22:27 timotimo brrt: what do you think: a complete duplication of all guard instructions + a generic deopt_one and deopt_all instruction? (i'm not sure if we can construct bridges for deopt_inline? but i haven't given it much thought)
22:28 brrt well...
22:29 brrt i think deopt_inline is never called directly
22:29 brrt but wait a minute, because there's something that's been bothering me for some time
22:29 brrt and i have to check it
22:31 brrt nah, i'm wrong
22:31 brrt deopt is not the problem
22:31 brrt but yes, that would be my plan of approach too
22:37 timotimo cool
22:38 timotimo cat was just about to paste some more text
22:44 brrt :-)
22:44 brrt i'm going to sleep, by the way
22:51 timotimo oh
22:51 timotimo sleep
22:51 timotimo a thing i haven't tried in a long time

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