Debugging - Better traceback #146
Conversation
Start of implementing a traceback using the debugging extension
So it adds the parent thread to match with the block-utility one.
…into debugging-patch01
This could allow for more stuff to take advantage of the system, as well, it makes it a bit easier to manage since it won't require everything to have events attached.
It's under a different event, now, which should be called more often.
Steve0Greatness
force-pushed
the
debugging-patch01
branch
from
daf870d to
a71cc09
Compare
Known issue: if a singular block is clicked, either in the palette or in the editing area, the output to the debugger will contain two entries to the same block. I was having issues getting it to only have one or the other: this is a tradeoff I think is fair, as it's far more important to know where issues are going on in your codebase than to not see duplicated entries
|
The two tasks I wanted to get done before review are done, now. So... uh, yeah. |
There was a problem hiding this comment.
i dont know too much about what would be good to test here but these are what i found
a few random notes i noticed
- it might be nice to have tracebacks for warnings aswell to see what caused the warning
- as sprite blocks break any deeper part of the stack
- new thread blocks end up getting rid of the stack (thought it was worth mentioning since broadcasts dont do this)
- if its possible, would be nice to see the custom block name instead of procedures_ opcode
- stack is lost with My Blocks+ global blocks and the Scripts extension, but those might not be worth figuring out
|
@SharkPool-SP i would recommend taking a look |
That seems pretty doable. Could get incredibly long with long block names, though. I'll add it to this PR and you can let me know your thoughts.
This, along with scripts and as sprite, likely aren't passing their parent threads to the thread initializer. I'm pretty sure I can make them pass their parent thread. As for MB+, I'm not entirely sure how that's doing things, but I'm pretty sure it'd require a patch there, as well, but that's out of scope for this PR. |
|
Warning traces: 
|
|
Got it to this state. 
Could probably do something with the parent thread to have it get the current running block of the thread at time of passing, but that'd take a bit of work. On another note, due to the way that run as sprite works, I'll need to do a bit more modification than I was initially planning. |
|
Or well, not that much more, but a different kind of modification. |
|
Actually, when the thread is spoofing another target, it doesn't seem to make it accessible in any way what it is spoofing from, which is kinda odd. |
Initially I thought I could simply check the stack of the initializing thread, but it doesn't seem like it works here. |
|
will review after finals |
3 participants
Unfinished ATM, just making a draft PR so feedback is easier.
This PR adds better tracebacking functionality to the debugging extension, with it even (hypothetically) working across targets (although I haven't tested it, yet).
This also adds a reference to the parent thread for the
HATS_STARTEDevent, allowing for this PR to even be possible.TODO
_renderTracebackmethod under the extension itself. I'd like to have it add links to the specific target and script that it references, since I think that'd be useful.