[L2Ork-dev] call for mentorship: porting tracecall

Jonathan Wilkes jon.w.wilkes at gmail.com
Thu Dec 20 12:29:29 EST 2018


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