[L2Ork-dev] call for mentorship: porting tracecall

Jonathan Wilkes jon.w.wilkes at gmail.com
Tue Mar 5 12:10:04 EST 2019


Ok, I'm probably going to implement [tracecall].

One of the important side-effects comes from moving the stack iterator
from the outlet handlers to the inlet handlers. This lets us spot
infinite loops where the messages never touch an outlet. That can
easily happen among iemgui wireless send/receives, probably in message
boxes with semicolons, atom boxes, and almost certainly in other
places I haven't considered.

A user recently reported such a bug a few days ago. Without Pd's
buffer overflow error such loops are pretty difficult to pin down. In
this case having the overflow protection for typedmess would have
saved the user hours of pain.

The one sticking point with tracecall is the potential for crashes if
an object in the trace got destroyed. But I think there may be a way
to check to see if there was any patch mutation during stack
execution, then just refuse to send the trace in that case.



-Jonathan

On 12/20/18, Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
> Hi list,
>
> I'm going to add backtracing to Purr Data:
>
> https://git.purrdata.net/jwilkes/purr-data/tree/port-tracecall
>
> I'd like to start from the ideal UX and whittle back if necessary:
>
> 1. user generates an error
>
> 2. error prints to console, followed by a stack trace in the console
>
> 3. user mouses over the object name of each line in the trace to
> highlight the corresponding object in the patch.
>
> Given the way Pd users generate errors I have the feeling this could
> quickly gum up the console. Especially considering things like a
> buffer overflow downstream from a [metro $small_float].
>
> Another possibility would be to cache traces in a Javascript object,
> then print them out in the console/overlay/sidebar when the user
> clicks the "error" link on an error. That won't gum up the console,
> but it still leaves open the possibility of dropouts due to socket
> chatter where the current error printing may not generate them.
>
> Just leaving it up to the user to plug in a [tracecall] would be ideal
> in terms of performance. But if we do that then most of our users
> won't discover it, or even if they do they won't know how to use it.
>
> -Jonathan
>


More information about the L2Ork-dev mailing list