On May 2, 2007, at 10:46 PM, Allan Odgaard wrote:
On 5. Apr 2007, at 18:54, Gerd Knops wrote:
On Apr 5, 2007, at 12:26 AM, Allan Odgaard wrote:
[...]
Related to this, I have an ASSERT() macro which aborts() and does a stack dump from the place where it aborts, this stack dump has files and line numbers, and I’ve been pondering making that into clickable links -- the format though is not the standard: «file»:«line»:«message».
I have done just that, using a small perl postprocessor parsing the output from the run_xcodebuild.sh, looking for patterns and replacing them with txmt links. It is kind of ugly, my current project has source files divided into folders so I devised a small search routine that descends from TM_PROJECT_DIRECTORY to find the source file (ignoring _darcs/.svn repositories). Works fairly well, but just to ugly and specialized to my environment to share.
Ideally we'd come up with a standard pattern for error messages, and add that functionality into the xcode stuff. That way anyone could generate clickable links by just formatting log or error messages in a certain way.
Returning to this subject… the way we deal with it in ScriptMate is by setting a TM_FD variable for the process we launch. This process can then write HTML to that file descriptor, which will be shown as- is (i.e. interpreted) in the HTML output window.
It's an interesting idea. High-bandwidth logging. What if the HTML from the app is corrupt, though? Could screw up rendering, and there's no way to isolate bad HTML within a larger page context. Could do simple validation (checking for correct node nesting), I suppose.
This does put a higher burden on the program which wish to have clickable errors, OTOH it allows for nicer formatting of the output (which is often possible when we’re dealing with stack dumps).
If you have control over the format of the stack trace, why not make it conform to «file»:«line»(:«column»)?:«error>>?
Chris