Hi all,
Just put this patch together to add clickable error messages to the XCode bundle:
Have a nice day.
- Ben
On 5. Apr 2007, at 00:41, Benjamin Jackson wrote:
Just put this patch together to add clickable error messages to the XCode bundle:
This is for the console output, i.e. the output from the program being run, right?
I am puzzled by why only lines having ‘Contents/Resources’ in the line is an error.
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».
On Apr 5, 2007, at 12:26 AM, Allan Odgaard wrote:
On 5. Apr 2007, at 00:41, Benjamin Jackson wrote:
Just put this patch together to add clickable error messages to the XCode bundle:
This is for the console output, i.e. the output from the program being run, right?
I am puzzled by why only lines having ‘Contents/Resources’ in the line is an error.
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.
Gerd
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.
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).
Would this be a useful implementation for the Xcode runner? Basically that runner would then only need to create a pipe and set the write- end’s file descriptor as an environment variable, for the process we launch (and then start a JS reader process that takes output for the pipe and inserts it in a special div).
We could offer a standard filter that greps the program output for «file»:«line»(:«column»)?:«error» and writes a HTML’yfied version to the $TM_FD file descriptor.
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
On 3. May 2007, at 06:44, Chris Thomas wrote:
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.
I think it’s the responsibility of the sending app to guarantee valid HTML, similar to how we also expect it to send valid UTF-8 sequences etc.
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>>?
Mainly for the nicer presentation. But I guess moving presentation to the app which produce the stack dump (or similar) is not an ideal design decision.
On May 2, 2007, at 9: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.
You know, I still haven't forgiven you for removing that output option where one could enter a pattern. Since then my tools spend a lot more code on formatting output then on getting their job done. And now you want me to replace NSLog(@"I am here") with something that opens some stupid file handle, then has to write (to get a line break) something like NSLog(@"<ihateallan>I am here</ ihateallan>")? I hope you are kidding!
BTW for long-running processes the output window needs a clear button/ shortcut/context menu entry.
Gerd
«file»:«line»(:«column»)?:«error>> sequences are now clickable, modulo any lurking bugs. Underpinning this feature is new reusable infrastructure:
• Add raw HTML markup (to be interpreted as HTML) to the output. • Given only the basename, find the full path of the source file in the Xcode project. This being the difficult part.
It should now be relatively easy to add different link formats as needed (and to support HTML output).
Chris
On 4. May 2007, at 04:04, Chris Thomas wrote:
«file»:«line»(:«column»)?:«error>> sequences are now clickable, modulo any lurking bugs. Underpinning this feature is new reusable infrastructure:
Great work Chris! I did a few changes to also scan sub-projects, as I have most of my code placed in those. We probably should also check system headers, e.g. some of my stack traces include STL headers.
Unfortunately it seems I quite frequently get the PTY exception while formatting, e.g.:
==> Exception during output formatting: PTY::ChildExited: pty - exited: 945 run_xcode_target.rb:267:in `each_pair' run_xcode_target.rb:143:in `path_for_basename' run_xcode_target.rb:159:in `path_for_basename' run_xcode_target.rb:143:in `path_for_basename' run_xcode_target.rb:159:in `path_for_basename' run_xcode_target.rb:143:in `path_for_basename' run_xcode_target.rb:159:in `path_for_basename' run_xcode_target.rb:143:in `path_for_basename' run_xcode_target.rb:353:in `run' run_xcode_target.rb:350:in `run' run_xcode_target.rb:270:in `run' run_xcode_target.rb:267:in `run' run_xcode_target.rb:314:in `run' run_xcode_target.rb:344:in `run' parse_build.rb:203 format_build.rb:571
On May 4, 2007, at 5:41 AM, Allan Odgaard wrote:
Unfortunately it seems I quite frequently get the PTY exception while formatting, e.g.:
I wish the PTY class wouldn't do that.
I'm not sure if there's a good solution. It's possible that running the process on a different Ruby thread would solve the problem.
Chris
On 3. May 2007, at 16:37, Gerd Knops wrote:
[...] You know, I still haven't forgiven you for removing that output option where one could enter a pattern. Since then my tools spend a lot more code on formatting output then on getting their job done.
Here’s an idea: write your own tool and use that:
«my command»|«my tool that catches output»
You could do that tool in a dozen lines of perl and use tm_dialog to open the output console. Within a few hours, you should have something vastly superior to that crappy window I killed.
And now you want me to replace NSLog(@"I am here") with something that opens some stupid file handle, then has to write (to get a line break) something like NSLog(@"<ihateallan>I am here</ihateallan>")? I hope you are kidding!
No, I wanted to enable programs to optionally do richer error reporting (during development). Look at the runners we have for AppleScript, Ruby, Python, etc. and how they present errors to the user. This looks much better than a simple “some_file.cc: 85:5:Warning: bla bla bla”.
On May 5, 2007, at 4:10 AM, Allan Odgaard wrote:
On 3. May 2007, at 16:37, Gerd Knops wrote:
[...] You know, I still haven't forgiven you for removing that output option where one could enter a pattern. Since then my tools spend a lot more code on formatting output then on getting their job done.
Here’s an idea: write your own tool and use that:
«my command»|«my tool that catches output»You could do that tool in a dozen lines of perl and use tm_dialog to open the output console. Within a few hours, you should have something vastly superior to that crappy window I killed.
While true (and I have done that), the key here is "Within a few hours" * languages/compilers/whatever used... The old method, while it may have been crappy, allowed me to get something reasonable within a minute or three.
Anyhow, my actual point was: I'd much rather have the added value of TM doing something smart with some carefully crafted (eg matching an expression) ascii debug output then having to write a custom filter (which makes my program dependant on it, bad when others using other environments work with it), or, gasp, actually have to emit my debug messages in html. I *hate* handcrafting html. Debugging output is often very short-lived. It should require minimum effort to add and remove to/from code.
Gerd
On 6. May 2007, at 18:17, Gerd Knops wrote:
On May 5, 2007, at 4:10 AM, Allan Odgaard wrote:
On 3. May 2007, at 16:37, Gerd Knops wrote:
[...] You know, I still haven't forgiven you for removing that output option where one could enter a pattern. Since then my tools spend a lot more code on formatting output then on getting their job done.
Here’s an idea: write your own tool and use that:
«my command»|«my tool that catches output»You could do that tool in a dozen lines of perl and use tm_dialog to open the output console. Within a few hours, you should have something vastly superior to that crappy window I killed.
While true (and I have done that), the key here is "Within a few hours" * languages/compilers/whatever used... The old method, while it may have been crappy, allowed me to get something reasonable within a minute or three.
If you did the tool as I outlined, that is just as re-usable as the old system.
-
Allan Odgaard -
Benjamin Jackson -
Chris Thomas -
Gerd Knops