On Fri, 21 Sep 2007, Ed Kelly wrote:
I've just been looking through source code from cvs, picking at random, and looking for an example of the void error (char *fmt, ...) from the externals howto. I can't find one anywhere!
A lot of externals use post() instead of error() or pd_error(), but you can also find the last two in some externals... actually quite a few. Use a text search through all files of all folders inside externals/ and you will find a long list of them.
Am I stating the obvious here? It's just that this means that PD patches made using anything other than internals are almost impossible to debug if they're extremely complex like mine is: there simply isn't a way of finding out where the errors are occurring.
It's already troublesome for those that use error() as Miller's pd won't register them with "Find Last Error", and even with pd_error(), you can't find the next-to-last error in case the error you want a trace for is also triggering other errors immediately after, for example.
Could PD or desiredata have a step-trace function, like MAX?
What DesireData offers, is:
1. the ability to Find Last Error with plain error(), and thus pd_error() is deprecated in DesireData and just redirects to error().
2. you actually can get a full stack trace for the last error, instead of just the object that called error(), and you can also get a stack trace anywhere as a sequence of list messages if you use the new [tracecall] class.
What is still upcoming:
3. getting stack trace for the N last errors
4. picking up error messages using the upcoming [rescue] class.
5. figuring out some way to make error messages translatable to other languages (French, German, etc.) and rescuable by a translation-independent name.
6. record a trace of all messages sent from a given starting point, until it comes back to the original point, with a limit of N messages recorded, and some way of visually stepping through that log. I don't know whether that's the feature you are asking for. I'm not sure I'll be able to actually step through the messages being executed as they are executed. Maybe I can figure out a way to do that, but it's tricky.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada