Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-08-11

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

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:46 nwc10 joined #moarvm
03:50 hoelzro joined #moarvm
03:51 japhb joined #moarvm
05:43 zostay_ joined #moarvm
05:49 JimmyZ joined #moarvm
07:30 brrt joined #moarvm
07:44 zakharyas joined #moarvm
09:57 TheLemonMan joined #moarvm
10:01 TheLemonMan hello, I'm trying to get my feet wet by picking a (apparently) easy ticket on the P6 bug tracker and after some digging I found out that the problem lies in MoarVM. Is this the right channel to ask some questions about it ?
10:01 timotimo yup
10:01 timotimo ask away! :)
10:07 TheLemonMan for reference, #127767 is the ticket I'm talking about, I promise I did read the docs/ but had not much luck in understanding how to retrieve the invocant name from MVM_args_assert_nameds_used for the purpose of showing it to the user. My best guess right now is that this piece of information is stored in a stack frame lodged somewhere
10:07 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=127767
10:08 timotimo hm, let's see
10:08 timotimo you should be able to get the name through the current frame, i believe?
10:09 timotimo yeah, go through the currently executing frame's static frame. that one has a "name" field, which is an MVMString
10:11 jnthn Actually that looks more like a backtrace formatting issue
10:12 timotimo also a good point
10:12 jnthn I don't think it warrants a MoarVM change. The frame with the problem is always the one at the top of the call stack
10:12 jnthn And so the top frame in the backtrace
10:12 jnthn For some reason, the Backtrace class (in Backtrace.pm) seems to have stripped that line out
10:13 jnthn Which would tell you which routine you were in
10:23 TheLemonMan hm, you mean the subname variable ?
10:58 brrt joined #moarvm
10:59 jnthn Well, more that
10:59 jnthn m: sub foo() { }; foo(:x)
10:59 camelia rakudo-moar 9bfbab: OUTPUT«Unexpected named parameter 'x' passed␤  in sub foo at <tmp> line 1␤  in block <unit> at <tmp> line 1␤␤»
10:59 jnthn Notice the "in sub foo"
10:59 jnthn For some reason the "in sub ..." line is getting filtered out in the case mentioned in the RT
10:59 jnthn There is logic for simplifying backtraces, and I suspect it's being a bit over-eager in this case.
11:00 TheLemonMan yep, I dug up a bit more and am trying to figure out where it's being filtered out
11:11 brrt https://morepypy.blogspot.nl/2016/08/pypy-tooling-upgrade-jitviewer-and.html
11:11 brrt i'd like a JitViewer too
11:12 TheLemonMan hmm, the prefix<!> is marked as a setting (whatever that means) and $setting is undefined in next-interesting-index
11:12 nwc10 gosh, that hadn't even hit planet python (yet)
11:13 timotimo TheLemonMan: the setting is the lexical environment that has all the builtins, and that's considered to be outside of the user's program
11:13 TheLemonMan timotimo, oh, gotcha
11:14 brrt nwc10: i'm oldfashioned and use an rss reader :-)
11:23 brrt joined #moarvm
12:17 [Coke] joined #moarvm
16:33 TimToady joined #moarvm
19:49 nwc10 jnthn: http://paste.scsys.co.uk/530646 -- t/spec/S17-promise/start.t failed after a lot of loops with moar: src/strings/ops.c:33: copy_strands: Assertion `from->body.storage_type == 3' failed.
19:50 nwc10 ASAN did not offer an opinion.
20:29 zakharyas joined #moarvm
20:53 timotimo can you get it to explode a few times more so we can see if it's the same kind of b0rk every time?
21:23 jnthn nwc10: Hmmm
21:23 jnthn I wonder if that's because another thread does flatten_ropes at just that moment
21:24 jnthn *sigh* Guess I should get to the great hash refactor, once the array one is done...
21:27 timotimo oh, damn, flatten_ropes isn't threadsafe
21:27 jnthn Yeah, I kinda knew we had that coming at home point :)
21:27 jnthn *at some
21:28 jnthn Thing is, MVMHash suffers the same things as MVMArray in terms of being crashable by mis-use too
21:29 jnthn And we should get our story on object hashes straight too, and at least having the VM plumbing for native hashes would hardly be bad
21:29 jnthn So yeah, lots of attention due there.
21:29 jnthn .oO( Like everywhere... )

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