AOLserver's documentation woes and its future

On Sep 5, 2006, at 6:00 PM, Jeff Hobbs wrote:
>> One thing I really miss in the Aolserver/Tcl world
is a good debugger
>> -- "puts" isn't such a good
alternative . 
Javascript, I believe,   
>> has nice development environments and debuggers
available.  It'd also
>> be nice to have a wider world of source code
available to us, as Tcl
>> has a lot, but nothing compared to the Perl/PHP
world.
>
> The Tcl Dev Kit Debugger should be able to be inserted
into the  
> AOLServer
> environment for effective debugging.  You currently
couldn't do  
> that with
> Komodo, but if there was demand, we could make some
modifications.   
> However,
> TDK can handle multiple simultaneous debugging
sessions, so it  
> should really
> be adept at the debugging needs of something like
AOLServer.

Jeff, I agree, BUT feel free to express my vote for a Mac
OSX version  
of Tcl Dev Kit.  <grin>

Komodo is on OSX, but as you indicated, the Komodo Tcl
debugger won't  
work with aolserver (I worked with your activestate tech
support  
folks and they said it wasn't supported)

As to "why a debugger for aolserver"?

Any large web-based application shares many of the same
complexity  
problems of traditional applications, and from my C++ days,
I learned  
that I should never leave code in that I hadn't stepped
through at  
least once.

Lots of the bugs on BookMooch (22,000 lines of Tcl procs at
launch)  
have been logic errors, and in the beta and first month of
launching  
BookMooch, my bug database reports 414 separate bugs fixed. 
That's a  
lot of code, and a proper debugger is nice.

One nice thing tclhttpd has is a debug mode that gives you a
stack  
track, and a few other introspection features when a Tcl
error  
occurs. Might be worth borrowing the concept.

If it weren't for Komodo doing syntax checks as I type my
Tcl code,  
I'm sure I'd have many more bugs (that's an amazing
feature, folks,  
if you don't know about it)

-john


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email
message. You can leave the Subject: field of your email
blank.

On 9/5/06, John Buckman <johnmagnatune.com> wrote:

>
> As to "why a debugger for aolserver"?
>
> Any large web-based application shares many of the same
complexity
> problems of traditional applications, and from my C++
days, I learned
> that I should never leave code in that I hadn't
stepped through at
> least once.
>
> Lots of the bugs on BookMooch (22,000 lines of Tcl
procs at launch)
> have been logic errors, and in the beta and first month
of launching
> BookMooch, my bug database reports 414 separate bugs
fixed.  That's a
> lot of code, and a proper debugger is nice.
>
> One nice thing tclhttpd has is a debug mode that gives
you a stack
> track, and a few other introspection features when a
Tcl error
> occurs. Might be worth borrowing the concept.
>

I rely on automated tests to catch this kind of stuff (Now
totally off
topic!) Feel free to start another discussion if you are
interested in
how we use automated testing in OpenACS.

Dave

-- 
Dave Bauer
davethedesignexperience.org
http://www.thedes
ignexperience.org/


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email
message. You can leave the Subject: field of your email
blank.

In most cases the only thing that I have found helpful for
debugging is lots 
of data (maybe even a little data). Nothing tests your
assumptions more than 
lots of examples. I think the main reason is that code is
tested with the 
same dataset, found to be error free and then the developer
moves on. Once 
the error is found, it shows up when you are not looking for
it, and you have 
the added assumption that 'that code works'. 

No debugger can ever help too much with this, automated
tests can never be 
extensive enough to test this because the main issue is that
the developer 
screwed up and made an assumption. If s/he made it when
writing the code, why 
wouldn't s/he make the same assumption when writing the
test?

The only thing that a debugger has shown to me is that I'm
an idiot, that is, 
if I could read/write code better, I wouldn't need the
debugger. 

More important is to avoid the anti-debugger in Tcl: catch.
There are only a 
few places where this command has any use. If you don't
overdose on catch, 
the usual AOLserver stacktrace usually locates the error. 

tom jackson

On Tuesday 05 September 2006 17:10, Dave Bauer wrote:
> On 9/5/06, John Buckman <johnmagnatune.com> wrote:
> > As to "why a debugger for aolserver"?
> >
> > Any large web-based application shares many of the
same complexity
> > problems of traditional applications, and from my
C++ days, I learned
> > that I should never leave code in that I hadn't
stepped through at
> > least once.
> >
> > Lots of the bugs on BookMooch (22,000 lines of Tcl
procs at launch)
> > have been logic errors, and in the beta and first
month of launching
> > BookMooch, my bug database reports 414 separate
bugs fixed.  That's a
> > lot of code, and a proper debugger is nice.
> >
> > One nice thing tclhttpd has is a debug mode that
gives you a stack
> > track, and a few other introspection features when
a Tcl error
> > occurs. Might be worth borrowing the concept.
>
> I rely on automated tests to catch this kind of stuff
(Now totally off
> topic!) Feel free to start another discussion if you
are interested in
> how we use automated testing in OpenACS.
>
> Dave


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
<listservlistserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email
message. You can leave the Subject: field of your email
blank.