Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-09-04

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

All times shown according to UTC.

Time Nick Message
00:07 colomon joined #moarvm
00:20 colomon joined #moarvm
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:22 ShimmerFairy joined #moarvm
03:42 lizmat_ joined #moarvm
06:24 vendethiel joined #moarvm
06:34 lizmat joined #moarvm
06:39 FROGGS joined #moarvm
07:05 virtualsue joined #moarvm
07:55 kjs_ joined #moarvm
07:59 virtualsue joined #moarvm
08:00 _itz_ joined #moarvm
08:42 kjs_ joined #moarvm
08:52 zakharyas joined #moarvm
08:58 Ven joined #moarvm
08:59 FROGGS joined #moarvm
09:08 lizmat joined #moarvm
09:33 zakharyas joined #moarvm
10:04 zakharyas joined #moarvm
10:07 virtualsue joined #moarvm
10:08 kjs_ joined #moarvm
10:36 btyler_yapc joined #moarvm
10:44 Ven joined #moarvm
10:45 btyler_yapc hi folks. this is probably a more appropriate place than #perl6 to chat about a MVM segfault: https://gist.github.com/kanatohodets/6642786a927c2616f6f2 (updated with some digging I did). it reproduces very nearly every time, but a sleep solves it, so I think it's a race between closing/freeing the handle and writing to it
10:53 btyler_yapc (will backlog, leaving venue for a bit)
11:35 colomon joined #moarvm
11:38 kjs_ joined #moarvm
12:13 Ven joined #moarvm
12:35 JimmyZ joined #moarvm
12:38 btyler_yapc joined #moarvm
12:48 dalek MoarVM: d78c018 | (Jimmy Zhuo)++ | src/core/threads.c:
12:48 dalek MoarVM: remove a needless MVMROOT
12:48 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d78c018d80
12:50 dalek MoarVM: ff26781 | paultcochrane++ | src/core/nativecall_dyncall.c:
12:50 dalek MoarVM: Add missing break statement to callback_handler switch cascade
12:50 dalek MoarVM:
12:50 dalek MoarVM: It seems that a break statement is missing in the MVM_NATIVECALL_ARG_*
12:50 dalek MoarVM: cascade of case statements.  This adds the missing break.  The NQP tests
12:50 dalek MoarVM: pass.
12:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ff267815ca
12:50 dalek MoarVM: e6d1074 | (Jimmy Zhuo)++ | src/core/nativecall_dyncall.c:
12:50 dalek MoarVM: Merge pull request #249 from paultcochrane/pr/add-missing-break-statement
12:50 dalek MoarVM:
12:50 dalek MoarVM: Add missing break statement to callback_handler switch cascade
12:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e6d107455b
13:10 btyler_yapc joined #moarvm
13:41 Ven_ joined #moarvm
14:12 Ven_ joined #moarvm
14:15 btyler_yapc I think this: https://github.com/MoarVM/MoarVM/pull/255 resolves the segfault I mentioned earlier. Unfortunately you can still make things explode by doing $sock.close and $sock.print("stuff"), but I'll poke at that next :)
14:22 timotimo btyler_yapc: oh, is your github user kanatohodets?
14:23 btyler_yapc yep, that's me
14:24 timotimo i totally didn't know that
14:25 lizmat joined #moarvm
14:26 kjs_ joined #moarvm
14:29 FROGGS joined #moarvm
14:45 kjs_ joined #moarvm
14:59 Ven_ joined #moarvm
15:07 hoelzro proc async has some race conditiony stuff in it; I wouldn't be surprised if async socket did too
15:08 lizmat hoelzro: me neither  :-)
15:09 hoelzro as long as I'm here...I've been working on updating nqp-js' deserializer to work with MoarVM serialization format 15, but the final solution seems to be eluding me.  Is there a way to get --dump to tell me how many objects/stables/etc are in an SC, and where in the SC they are sleeping?
15:10 zakharyas joined #moarvm
15:11 njmurphy joined #moarvm
15:12 hoelzro btyler_: does $sock.close work instantly on the socket? or does it get scheduled in the async queue?
15:12 hoelzro it should probably do the latter
15:19 timotimo if it's an async socket, then yeah, totally should
15:41 rarara joined #moarvm
15:46 JimmyZ jnthn: it would be nice to take a quick review to PR 255 :)
15:52 jnthn I think that "if" becomes kinda redundant if we remove the NULLing, but we probably also remove a race by pushing things off to the event loop thread to deal with
15:53 jnthn Hm, actually there probably ain't a race.
15:53 jnthn But yeah, the if check is redundant
15:53 jnthn (if the NULL-ing goes away)
15:53 jnthn And it probably does have to go away.
15:55 JimmyZ so we can merge it and remove the if check
15:57 jnthn I think I'm good with that
16:03 dalek MoarVM: afbc27a | (Ben Tyler)++ | src/io/asyncsocket.c:
16:03 dalek MoarVM: Fix write to null handle on async socket.
16:03 dalek MoarVM:
16:03 dalek MoarVM: This NULL-ing in close_socket was premature, since MVM_free catches this same
16:03 dalek MoarVM: handle when the task is processed by the event loop in
16:04 dalek joined #moarvm
16:08 dalek MoarVM: 38d153d | (Jimmy Zhuo)++ | src/io/asyncsocket.c:
16:08 dalek MoarVM: remove redundant if check
16:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/38d153d220
16:09 btyler_yapc joined #moarvm
16:10 btyler_yapc hi -- saw the backlog. the close already is scheduled on the event loop
16:11 btyler_yapc thanks for taking a look!
16:12 btyler_yapc it isn't obvious that it's an async close at first glance, because nqp::closefh eventually winds up in MVM_io_close, which wraps different kinds of closing for different things; async sockets implement that API with a uv scheduled close (at least, this is my understanding)
16:18 JimmyZ jnthn: btw: I  think I found a bug which is in fixed allocation . FYI.
16:19 JimmyZ jnthn: issues/234, that's it
16:21 jnthn Possibly, but it's equally likely that the different memory layout achieved by turning on FSA_DEBUG just hides the issue
16:21 jnthn It should make the issue more ASAN-able though
16:22 JimmyZ yeah.
16:24 JimmyZ FAS_DEBUG looks like always malloc()
16:24 timotimo jnthn: can you help me figure out why our code-gen would produce a lexicalref-decl'd var for things like "my int $foo; while $foo < 10 { $foo++ }"?
16:25 jnthn Uh...well, the ++ operator will have one.
16:25 timotimo i can see why it'd want to use a lexicalref scoped mention of it later on, but why is that in the declaration?
16:25 timotimo oh, my example code doesn't actually ++, it just says the value
16:26 timotimo and i don't entirely understand why the lexicalref decl'd var actuallly works, as there's no lexical it can refer to :|
16:27 timotimo in "my int $foo" the code we generate is basically assign_i(my lexicalref int $foo, 0)
16:28 timotimo BBIAB
17:49 timotimo last time i looked at the code, it looked like it was supposed to never set lexicalref when it created the QAST::Var when $*IN_DECL was set to something specific
17:49 * timotimo looks again
17:50 timotimo ah, yes, $*IN_DECL ne 'variable'
17:52 timotimo that surprised me quite a bit, as it was actually a variable declaration that was resulting in a lexicalref var
17:52 timotimo and even then it'd only set it if the lexical is marked ro
18:05 timotimo this may actually be the wrong piece of code i'm looking at, but there's not many other places that set lexicalref
18:13 pyrimidine joined #moarvm
18:13 dalek joined #moarvm
19:21 colomon joined #moarvm
19:35 dalek MoarVM: fe40cbf | FROGGS++ | / (9 files):
19:35 dalek MoarVM: re-apply patch to add C++/NativeCall support
19:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fe40cbfc85
20:12 timotimo oh, huh, we just always set the scope to lexicalref if we have a non-object, huh?
20:14 timotimo that doesn't unify with how i understand lexicalref'd vars are code-gen'd
20:15 diakopte1 joined #moarvm
21:03 Ven joined #moarvm
21:08 ShimmerFairy joined #moarvm
21:10 ashleydev joined #moarvm
21:11 diakopter joined #moarvm
21:16 lizmat joined #moarvm
21:16 lizmat_ joined #moarvm
21:55 Ven joined #moarvm
23:02 japhb joined #moarvm
23:07 japhb joined #moarvm

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