[PD] debugging techniques/tricks for a non-developer?

[Matteo Sisti Sette]

> run pd inside valgrind. it slows down pd by 50 times or so, but it checks
> a lot more memory accesses, and it can make the bugs easier to trigger.

Thanks a lot for the information and advice.
The time has come to stop being lazy and get Linux!


>>  If PD crashes, I need to know: whether there is or not an error in my
>> patch,
>
> a segfault or bus error or other sudden crash is always considered the
> fault of C code, never of patches.

Yes, of course. A program should never ever crash, no matter how bad the
input.
Some of the crasher bugs of PD only produce the crash when there is an error
in the patch, which doesn't mean they are not bugs, nor that they are not
serious bugs (when you have an error in your patch you really need PD to
give you a clear error message!), but it does mean that if you
know it you can get rid of the problem by fixing the patch, and sleep
peacefully.


> an almost-infinite loop involving [until] is considered fault of the user,
> even though the user can't force pd to quit the loop. this would deserve
> some feature to force breaking out of the loop, but in itself it's not a
> bug in pd.

Indeed, you should ALWAYS be able to at least save the patch and close it.
In my opinion, PD simulates a virtual machine, and the patch is the code
executed by the virtual machine. So it's ok that you can write code that
"virtually" crashes the "virtual" machine and/or makes it "virtually"
unresponsive. However, the "simulator" itself, which is a "real" application
running on a "real" machine , should never become unresponsive to user
actions such as closing or saving the file. If it does, it is in my opinion
a bug (or a design flaw), no less than if it crashes.
It is especially important since in this case PD is at the same time the
interpreter and the editor, so if it hangs you may loose your work.