Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-04

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

All times shown according to UTC.

Time Nick Message
00:15 committable6 joined #moarvm
00:20 travis-ci joined #moarvm
00:20 travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #713 from MoarVM/fsa_valgrind_error_support
00:20 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/296996584 https://github.com/MoarVM/MoarVM/compare/31024652a025...ac0282af2a98
00:20 travis-ci left #moarvm
00:22 MasterDuke ^^^ just a single github timeout
00:26 jnthn Phew :)
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:45 ugexe joined #moarvm
07:32 domidumont joined #moarvm
08:02 domidumont joined #moarvm
08:54 leont joined #moarvm
09:13 AlexDaniel joined #moarvm
09:30 nine Ok, with disabled eliminate_pointless_gotos optimization and with only ever inlining one callee into a given caller inline_in_place passes the spectests. So there's at least a stable base to continue from.
09:31 nine The restriction to one inlinee only is due to some handler issue. Apparently a handler goto instruction goes missing otherwise. It's found by merge_graph but later we don't encounter the annotation.
09:42 nine And that seems to be fixed now? Which surprises me, because I've tried the exact same change before.
10:05 evalable6 joined #moarvm
10:33 nine The eliminate_pointless_gotos issue seems to be due to an MVM_SPESH_ANN_DEOPT_ALL_INS annotation. It works just fine when I keep gotos with that annotation intact.
10:46 nine This tells me that the "troubled" goto instruction is the one that replaces the invoke op. Moving the annotation doesn't seem to help so I guess we somehow still need that goto.
10:55 nine And there are 3 spec tests that fail unless I skip removal of the MVM_SPESH_ANN_INLINE_END annotated goto as well. Which kinda defeats the purpose of inlining in place :/
11:01 evalable6 joined #moarvm
11:16 nine And there's t/spec/S02-literals/quoting.t which is the only test still broken by eliminate_pointless_gotos
11:19 nine Or it may just be a really weird flapper
11:26 patrickz joined #moarvm
12:22 patrickz joined #moarvm
12:52 jnthn nine: Rememeber to build/spectest with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 which will really torture out any new issues :)
12:53 jnthn nine: Also, in the instruction deletion code, it moves some annotations on delete; may be worth checking if it's doing that here
12:54 nwc10 jnthn: if it's convenient - FSA_SIZE_DEBUG is currently broken (on some compilers) without
12:54 nwc10 -    memcpy(dbg->memory, p + sizeof(MVMuint64), new_bytes > old_bytes ? old_bytes : new_bytes);
12:54 nwc10 +    memcpy(dbg->memory, (char *)p + sizeof(MVMuint64), new_bytes > old_bytes ? old_bytes : new_bytes);
12:54 nwc10 in src/core/fixedsizealloc.c
12:54 nwc10 ie needs that (char *) cast before p, which is void *
12:55 nwc10 (for more torture still)
12:55 jnthn timotimo: ^^
12:55 nwc10 :-)
12:56 nwc10 me-- # not figure out who the actual "culprit" was
12:56 jnthn Pretty sure it was timotimo's PR that I merged
13:00 ilmari joined #moarvm
13:52 patrickz joined #moarvm
14:43 dogbert17 tried to look a bit more at https://github.com/rakudo/rakudo/issues/1202
14:45 dogbert17 when run under load it always hangs after a while. Attaching gdb to the process reveals nothin, i.e. the 'bt' command is unable to display anything.
14:46 dogbert17 I then tried the pstack command instead and it gives a bit more info
14:46 dogbert17 (No symbols found in /lib/i386-linux-gnu/libm.so.6)
14:46 dogbert17 (No symbols found in /lib/i386-linux-gnu/librt.so.1)
14:46 dogbert17 (No symbols found in /lib/i386-linux-gnu/libdl.so.2)
14:46 dogbert17 (No symbols found in /lib/ld-linux.so.2)
14:46 dogbert17 0xb77c4cb0: _fini + 0x31d42c
14:48 dogbert17 dunno how to get symbols on those libraries but the presence of '_fini' and some google gives me the impression that the hang occurs when the code is done and the program is exiting
14:49 MasterDuke dogbert17: if you're interested in some new stuff to debug, https://irclog.perlgeek.de/perl6/2017-11-03#i_15398818
14:49 dogbert17 whether that is a clue is for someone else to decide :)
14:50 MasterDuke more background here https://irclog.perlgeek.de/perl6/2017-11-02#i_15394120
14:50 dogbert17 MasterDuke: looks
14:51 dogbert17 is it a module that's crashing?
14:56 dogbert17 MasterDuke: have run the script once so far, no crash on my 32 bit system
14:57 MasterDuke did you edit the script to use MsgPack instead of Data::MessagePack?
14:59 dogbert17 oops
15:00 * dogbert17 must improve my reading skills :)
15:01 MasterDuke heh, well the background info is kind of spread around...
15:02 dogbert17 hmm, it seems I need to apt-get something as well
15:03 domidumont joined #moarvm
15:30 Geth ¦ MoarVM: 2f0672f745 | (Zoffix Znet)++ | src/io/syncfile.c
15:30 Geth ¦ MoarVM: Fix too-late EOF detection on TTY handles
15:30 Geth ¦ MoarVM:
15:30 Geth ¦ MoarVM: TTY handles aren't seakable so EOF detection on them relies on our
15:30 Geth ¦ MoarVM: `eof_reported` flag that currently gets set if we read zero bytes
15:30 Geth ¦ MoarVM: despite wanting to read more. This causes an issue where a large
15:30 Geth ¦ MoarVM: read that does actually does read some bytes still doesn't set EOF
15:30 Geth ¦ MoarVM: and the code wait until another read of zero bytes to actually set it.
15:30 Geth ¦ MoarVM:
15:30 Geth ¦ MoarVM: Fix by checking whether we read fewer bytes than we wanted instead.
15:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2f0672f745
15:44 evalable6 joined #moarvm
15:45 travis-ci joined #moarvm
15:45 travis-ci MoarVM build passed. Zoffix Znet 'Fix too-late EOF detection on TTY handles
15:45 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/297240208 https://github.com/MoarVM/MoarVM/compare/ac0282af2a98...2f0672f74523
15:45 travis-ci left #moarvm
15:46 dogbert17 MasterDuke: #0  MVM_panic (exitCode=1, messageFormat=0xb7cb8224 "Invalid owner in item added to GC worklist") at src/core/exceptions.c:682
15:46 dogbert17 #1  0xb7bfdfc9 in gc_mark (tc=0x804c5f8, st=0xa10a2e8, data=0xb4f41e8, worklist=0xa0a5c80) at src/6model/reprs/CStruct.c:623
15:46 dogbert17 #2  0xb7bb4076 in MVM_gc_mark_collectable (tc=0x804c5f8, worklist=0xa0a5c80, new_addr=0xb4f41d8) at src/gc/collect.c:428
15:46 dogbert17 #3  0xb7bb22e6 in process_worklist (tc=0x804c5f8, worklist=0xa0a5c80, wtp=0xbfffda18, gen=1 '\001') at src/gc/collect.c:342
15:47 MasterDuke hm, think that's new
15:48 dogbert17 ran this code: https://github.com/azawawi/scripts/blob/master/test-msgpack.pl6 # had changed to MsgPack ofc
15:49 dogbert17 on the next try I got "Zeroed owner in item added to GC worklist"
15:51 * dogbert17 tries valgrind instead
15:52 * dogbert17 which will take forever ...
16:21 zakharyas joined #moarvm
16:22 domidumont joined #moarvm
16:29 Geth ¦ MoarVM: d257df23a9 | (Zoffix Znet)++ | src/io/syncfile.c
16:29 Geth ¦ MoarVM: Revert "Fix too-late EOF detection on TTY handles"
16:29 Geth ¦ MoarVM:
16:29 Geth ¦ MoarVM: This reverts commit 2f0672f74523c6ddfe8a216728bbbea8fc7760ce.
16:29 Geth ¦ MoarVM:
16:29 Geth ¦ MoarVM: https://irclog.perlgeek.de/perl6-dev/2017-11-04#i_15401308
16:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d257df23a9
19:42 evalable6 joined #moarvm
22:07 colomon joined #moarvm
23:02 colomon joined #moarvm
23:56 colomon joined #moarvm

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