Forum OpenACS Q&A: What happened to servername-error.log

we're running open acs 3/aolserver 3.2 and doing heavy tcl/sql
development of a number of new modules using adp pages, and tcl
we're doing the usual - window 1 browser, window 2, tail -f
servername.log.  The issue is that the sql errors get swallowed up in
the noise and its tough to find -
We had a classic ACS 3.5/Oracle install that had 2 logs -
servername.log and servername-error.log - what ever happened to that?
AND as long as we're on this topic - theres gotta be a better way to
debug code.
Posted by C. R. Oldham on
theres gotta be a better way to debug code.
Yes--in another thread today someone was using TclPro to debug, but the code needed some massaging before you could break into it with TclPro.  That really excites me--is there an (easy) way we could make that work with the templating system?
Posted by Jerry Asher on
I never got TclPro and AOLserver to work 100% of the time.  It seemed that every other breakpoint was caught, but I suspect that was due to operator error.
Yes there has got to be a better way to debug code.  When developing pages, I feel that I've fallen back 20 years to
I have a bit more sophisticated version of that.  The combination of <tt>nscp</tt>, emacs, and David Lutterkort's emacs server log module, <a href='';></a>, are a win for me.
I typically have one emacs window on the code, an emacs window shelled into AOLserver itself through <tt>nscp</tt>, an emacs window serving the log, and an emacs window in <tt>SQL</tt> mode.
Truly the big win is <tt>nscp</tt> mode which lets me evaluate arbitrary AOLserver tcl expressions and communicate with the running AOLserver itself.  It's a Lisp Interaction buffer supported by AOLserver.
I also find that having browsers open to the Tcl manual at activestate, the aolserver manual at aolserver, and a Guide to Semiconductor Physics at is also helpful.
Posted by Mat Kovach on
Actually I've spend some much time in the "older languages" (FORTRAN, COBOL) that I'm usually using:






900 FORMAT('DEBUG: INPUT 1: ' F19.8 ' INPUT 2: ' E10.4)

So, I'm quite use to it.  Sometimes it takes wrapping things with easily grepped syntax.

tail -f error.log | grep 'STRING' works fairly good to clear the noise.

Posted by S. Y. on
Jerry, you forgot to mention the Cisco documentation at: