01:48 ilbot3 joined 03:46 nwc10 joined 03:50 hoelzro joined 03:51 japhb joined 05:43 zostay_ joined 05:49 JimmyZ joined 07:30 brrt joined 07:44 zakharyas joined 09:57 TheLemonMan joined
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
ask away! :)
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: rt.perl.org/rt3//Public/Bug/Displa...?id=127767
timotimo hm, let's see 10:08
you should be able to get the name through the current frame, i believe?
yeah, go through the currently executing frame's static frame. that one has a "name" field, which is an MVMString 10:09
jnthn Actually that looks more like a backtrace formatting issue 10:11
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
And so the top frame in the backtrace
For some reason, the Backtrace class (in Backtrace.pm) seems to have stripped that line out
Which would tell you which routine you were in 10:13
TheLemonMan hm, you mean the subname variable ? 10:23
10:58 brrt joined
jnthn Well, more that 10:59
m: sub foo() { }; foo(:x)
camelia rakudo-moar 9bfbab: OUTPUTĀ«Unexpected named parameter 'x' passedā¤ in sub foo at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
jnthn Notice the "in sub foo"
For some reason the "in sub ..." line is getting filtered out in the case mentioned in the RT
There is logic for simplifying backtraces, and I suspect it's being a bit over-eager in this case.
TheLemonMan yep, I dug up a bit more and am trying to figure out where it's being filtered out 11:00
brrt morepypy.blogspot.nl/2016/08/pypy-...r-and.html 11:11
i'd like a JitViewer too
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)
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
brrt nwc10: i'm oldfashioned and use an rss reader :-) 11:14
11:23 brrt joined 12:17 [Coke] joined 16:33 TimToady joined
nwc10 jnthn: 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:49
ASAN did not offer an opinion. 19:50
20:29 zakharyas joined
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? 20:53
jnthn nwc10: Hmmm 21:23
I wonder if that's because another thread does flatten_ropes at just that moment
*sigh* Guess I should get to the great hash refactor, once the array one is done... 21:24
timotimo oh, damn, flatten_ropes isn't threadsafe 21:27
jnthn Yeah, I kinda knew we had that coming at home point :)
*at some
Thing is, MVMHash suffers the same things as MVMArray in terms of being crashable by mis-use too 21:28
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
So yeah, lots of attention due there.
.oO( Like everywhere... )