|
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... ) |
|||