Orchid XP v8 wrote:
> I can't believe that nobody caught this in testing. 

I can. That's exactly why the people who write the code should not be the 
people to test the code.  And that's exactly why code without documentation 
is worthless.

> When you fire 
> up a debugger with support for breakpoints, literally THE FIRST THING 
> you're going to do is try to stick breakpoints on top-level functions. 

Not if you wrote the debugger yourself and you know it only breakpoints on 
executable code.

> I really can't believe somebody would go to the extreme lengths required 
> to build something as complex as a debugger, and then release it while 
> it's trivially broken. 

Welcome to Open Source!

> I mean, the effort to fix this glitch compared to 
> the effort of developing the debugger in the first place...

I can completely understand a debugger for an interpreted language only 
being able to stop on executable lines. I can understand it especially if 
the interpreter wasn't written with breakpointing it in mind. If the person 
writing the interpreter for example compiled code into bytecodes and then 
marked each bytecode with what line it came from, and the guy writing the 
debugger stopped as soon as you hit a bytecode with the matching line 
number, and he can't tell what lines are valid to breakpoint on before the 
code is running because that's when the bytecode is generated, I'd think it 
would take a crapload of work to fix that "bug".

> Anyway, I guess none of this is going to fix my algorithm. I suppose 
> it's a miracle that you can debug JavaScript at all. But *damn*!

Actually, I thought it was pretty cool when I could put a breakpoint in code 
invoked by a web request and have it breakpoint. Man, I wish I had that 
capability when I was first writing CGI scripts.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message