Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-08

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

All times shown according to UTC.

Time Nick Message
01:27 MasterDuke_ joined #moarvm
02:13 MasterDuke_ timotimo: i thought this looked interesting: http://ourmachinery.com/post/virtual-memory-tricks/
02:13 MasterDuke_ particularly the idea to use a virtual memory allocator to help debugging
02:14 MasterDuke_ think that's something moarvm could use?
02:21 timotimo reminds me a bit of libefence
02:31 MasterDuke_ isn't that a bit annoying to use?
02:38 timotimo don't think so?
02:38 timotimo don't you literally just LD_PRELOAD it?
02:41 timotimo i'm going to sleep! seeya :)
02:57 ilbot3 joined #moarvm
02:57 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:10 colomon_ joined #moarvm
03:50 colomon joined #moarvm
06:34 Guest26563 joined #moarvm
06:59 domidumont joined #moarvm
07:05 brrt joined #moarvm
07:05 brrt good * #moarvm
07:05 domidumont joined #moarvm
07:10 samcv good * brrt
07:11 brrt ohai samcv
07:11 brrt what's up
07:14 samcv not much. trying to fix some sprintf things in nqp
07:15 samcv really odd. %d returns the number with padding from the method in the grammar but %b doesn't. and that's odd
07:16 samcv since i'm not sure where it's adding the padding on. and as a result it returns 0000-1000 for negative numbers if you use padding
07:44 domidumont joined #moarvm
08:34 zakharyas joined #moarvm
09:36 brrt joined #moarvm
09:45 benchable6 joined #moarvm
09:45 statisfiable6 joined #moarvm
09:45 unicodable6 joined #moarvm
09:49 dogbert2 joined #moarvm
09:54 bartolin samcv: I'm not sure if it is relevant, but I started a branch back in 2015 where I tried to improve the padding for %b. I didn't follow up, though ... https://github.com/perl6/nqp/tree/sprintf
09:55 samcv heh. and the test fixes i just made independently. will look at it though :)
09:57 domidumont joined #moarvm
09:59 brrt i've been trying to put large constants (i.e. pointers) in a separate table
10:01 AlexDaniel` joined #moarvm
10:03 greppable6 joined #moarvm
10:03 squashable6 joined #moarvm
10:03 coverable6 joined #moarvm
10:03 bloatable6 joined #moarvm
10:11 robertle joined #moarvm
10:14 zakharyas joined #moarvm
10:21 brrt hmm, question
10:22 brrt nm, answer
10:22 brrt i'm wondering whether i should split a large constants table from the constant pointers
10:28 brrt the only purpose i can find for that would be to have large constants bigger than 8 bytes
10:29 samcv brrt: what are these constants used for and how often are they used
10:30 brrt the current use is to have pointers
10:30 brrt so 8 bytes on x86-64
10:30 ilmari[m] joined #moarvm
10:30 samcv uh oh
10:30 samcv Error in `/home/samantha/perl6/bin/moar': corrupted double-linked list: 0x00007f7fbc0fe920 ***
10:31 samcv never gotten this before...
10:31 brrt absolute power corrupts
10:32 samcv double power corrupts absolutely?
10:32 samcv idk sounded better in my head
10:33 samcv backtrace is here https://gist.github.com/b0f777b4c21ddea542f8f7a93396019a
10:34 samcv looks like it happening during bind_key
10:36 samcv and i'm getting a failure in IO-Socket-Async.t
10:36 samcv Unhandled exception in code scheduled on thread 4 (and for 6 too) then too few positionals passed
10:36 samcv let me try a make realclean
10:37 samcv nope still failing…
10:37 AlexDaniel joined #moarvm
10:38 stmuk joined #moarvm
11:11 AlexDaniel joined #moarvm
11:46 brrt joined #moarvm
13:31 domidumont joined #moarvm
13:43 dogbert17 joined #moarvm
13:43 dogbert17 I haven't seen this before: MoarVM panic: non-AsyncTask fetched from eventloop active work list
13:45 timotimo but it doesn't output what it is? that's a simple fix, just put the debug name (MVM_6model_get_debug_name(tc, whatever))
13:47 dogbert17 I'll see if I can repro it under gdb, all I have so far is that it happened while running test 62 in t/spec/S17-supply/syntax.t
13:48 dogbert17 that test has the following text 'CLOSE phaser sees correct outer scope'
13:49 [Coke] didn't jnthn -just- touch that?
13:50 timotimo yeah
13:54 timotimo https://gist.github.com/timo/f9fd9cf97f99d5169626b02eded46972 - dogbert17
13:55 dogbert17 sigh, while running it in gdb I got a SEGV while running test 68
13:55 jnthn Yes, I fixed that issue yesterday and added the test
13:55 dogbert17 timotimo: thanks, I'll add it
13:57 dogbert17 here's the SEGV, while running test 68, https://gist.github.com/dogbert17/178c6c6c88438a0ac61c12075d9ac17c  does anything stand out?
13:58 timotimo you surely got jnthn's latest moarvm commit as well?
13:58 timotimo oh, not a moarvm commit
13:59 dogbert17 ... built on MoarVM version 2017.10-57-gd257df23
14:00 dogbert17 btw, both problems turned up while the system was under som stress
14:00 dogbert17 *some
14:04 zakharyas joined #moarvm
14:04 domidumont joined #moarvm
14:05 * dogbert17 trying timotimo's clever patch
14:06 dogbert17 and the result is: MoarVM panic: non-AsyncTask fetched from eventloop active work list: was VMNull
14:07 timotimo that's the most boring way to have that happen
14:08 dogbert17 :)
14:10 AlexDaniel joined #moarvm
14:11 dogbert17 jnthn, timotimo: what about this https://gist.github.com/dogbert17/71d071ab34c69ee123bc1167d6b4bd0f
14:26 yoleaux joined #moarvm
15:16 dogbert17 seems as if that test can fail in a few different ways, i.e. 'MoarVM panic: non-AsyncTask fetched from eventloop active work list' or 'MoarVM panic: use of invalid eventloop work item index -1' or SEGV at
15:16 dogbert17 0xb7bb9b49 in setup_work (tc=0xb36eb448) at src/io/eventloop.c:15
15:17 dogbert17 15     MVMConcBlockingQueue *queue = (MVMConcBlockingQueue *)tc->instance->event_loop_todo_queue;
15:31 * dogbert17 continues his ramblings
15:33 dogbert17 it turns out that valgrind has some comments wrt this test: https://gist.github.com/dogbert17/3a7a6dbaa5cc474275d47a47a5a7e49c
15:45 timotimo that last one looks a bit like a missing MVMROOT
15:49 dogbert17 yeah, perhaps that one is the root :) of all problems above
15:49 dogbert17 but how do you find them
15:50 timotimo gc torture can help narrow it down
15:50 dogbert17 I can try that
15:54 brrt joined #moarvm
15:55 dogbert17 the first invalid read is very consistent, shows up every time
16:05 Geth ¦ MoarVM: d38519364e | (Timo Paulssen)++ | src/6model/reprs/MVMIter.c
16:05 Geth ¦ MoarVM: Don't segfault when MVM_iter on type object
16:05 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d38519364e
16:07 dogbert17 timotimo: did you find something?
16:11 timotimo no, that's unrelated
16:12 dogbert17 timotimo++ anyway :)
16:37 brrt joined #moarvm
17:34 domidumont joined #moarvm
17:45 domidumont joined #moarvm
17:52 releasable6 joined #moarvm
18:04 ugexe what is MoarVM/lib/MAST/Ops.p6 for? it says at the top that tools/update_ops.p6 updates it but that doesn't seem to be the case (so maybe Ops.nqp took its place?)
18:04 zakharyas joined #moarvm
18:10 ugexe also whats the best way to build a rakudo against a moarvm with a new op? usually I build rakudo at its latest commit and edit MoarVM files inside there (doing a `make install` will put everything in the proper spot). but trying to build nqp i'm now getting "operand type 32 does not match register type 56" despite what I thought was thorough make cleans
18:10 [Coke] ugexe: you can explicitly configure it with --gen-moar=master  or --gen-moar=<sha1>
18:10 [Coke] then you don't have to do any of the edits yourself.
18:11 ugexe the edits are source code edits... i do wants those :)
18:55 AlexDaniel joined #moarvm
19:05 AlexDani` joined #moarvm
19:23 Ven joined #moarvm
19:25 Ven_ joined #moarvm
20:37 Ven joined #moarvm
20:49 jnthn ugexe: You'll have to rebuild Rakudo too if you add new ops
20:49 ugexe if I put the op to the bottom of oplist it works, but if i put it in the middle (grouped with getpid) it doesn't
20:49 ugexe should i be trying to group it like that?
20:50 jnthn The docs at the top of the oplist file explain where to add them
20:51 ugexe yeah i guess thats better instructions than git history heh
20:52 jnthn Don't write docs, and everyone asks for the docs. Do write docs, and nobody reads the docs. :P
20:53 * nine doesn't see himself as nobody. Well not all the time anyway ;)
20:55 jnthn :-)
20:56 jnthn Usually the size of the "everybody" asking for docs is 1 or 2 people also ;)
20:56 Ven_ joined #moarvm
20:57 nine jnthn: that's a bug, isn't it? https://github.com/MoarVM/MoarVM/blob/master/src/spesh/manipulate.c#L73
20:59 jnthn ooh
20:59 jnthn Yes, it should be append_to->next = ann;
20:59 nine And append_to may even be NULL
21:00 nine So if (append_to) append_to->next = ann; else prev->annotations = ann;
21:00 jnthn That also
21:01 nine Kinda ironic to see such complex machinery working but finding the bug in code for appending to a linked list. Which is literally a data structures 101 beginner exercise :D
21:02 nine Nicely demonstrates how we're all human I guess :)
21:03 jnthn Indeed. Also why code review is a really good idea.
21:08 nine Unfortunately it doesn't bring me closer to why removing a useless goto carrying a DEOPT_INLINE annotation causes breakage when that annotation is never used anywhere
21:09 jnthn Does the annotation get moved?
21:09 jnthn The inline annotations are really important
21:09 nine Now that the bug is fixed, yes. But it shouldn't make a difference. Not a single code path that checks for that annotation is actually hit even when the goto's still there.
21:10 jnthn Hmm
21:10 timotimo isn't it still used in the code gen to build the handler/uninline table?
21:11 nine The case MVM_SPESH_ANN_DEOPT_INLINE: in src/spesh/codegen.c:116 never gets triggered in the test case
21:18 nine The only logical conclusion I can see is that it's not the DEOPT_INLINE annotation that's important, but the goto itself. The annotation is just the last thing that would keep the goto from getting eliminated.
21:19 nine So something seems to be depending on an inlined basic block always being entered through a goto.
21:36 Ven joined #moarvm
21:56 Ven_ joined #moarvm
22:16 Ven_ joined #moarvm
22:36 Ven joined #moarvm
22:40 jnthn nine: https://github.com/MoarVM/MoarVM/blob/master/src/spesh/deopt.c#L118
22:56 Ven_ joined #moarvm
23:16 Ven_ joined #moarvm
23:23 Geth ¦ MoarVM: ugexe++ created pull request #747: Put op in same order relative to oplist
23:23 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/747
23:26 Geth ¦ MoarVM: ugexe++ created pull request #748: Add getppid op
23:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/748
23:36 jnthn .oO( But is PR 747 jumbo? :) )
23:36 Ven joined #moarvm
23:36 jnthn ugexe: fwiw, I'm in favor of #747 for the same of humans; I suspect compilers are smart enough (and I think somebody here measured that in the past).
23:37 jnthn *the sake of
23:40 ugexe that was just a cut and paste from the comments/docs... now I have an excuse for not reading them
23:41 jnthn ;)
23:42 Geth ¦ MoarVM: 1a8664b2dc | (Nick Logan)++ (committed using GitHub Web editor) | src/core/interp.c
23:42 Geth ¦ MoarVM: Put op in same order relative to oplist
23:42 Geth ¦ MoarVM:
23:42 Geth ¦ MoarVM: The ops should be in the same order here as in the oplist file, so the compiler can can optimize the switch properly.
23:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1a8664b2dc
23:42 Geth ¦ MoarVM: 2ca7e8587b | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/interp.c
23:42 Geth ¦ MoarVM: Merge pull request #747 from ugexe/patch-3
23:42 Geth ¦ MoarVM:
23:42 Geth ¦ MoarVM: Put op in same order relative to oplist
23:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2ca7e8587b
23:42 jnthn Aww. So I merged that and now 748 has a conflict.
23:42 jnthn Which was, I guess predictable.
23:42 ugexe heh yeah i figured
23:49 ugexe i forced pushed the merge conflict fix to my branch
23:50 jnthn Cool. I'm off to rest now; I'll look at it in the morning :-)
23:51 ugexe see ya later

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