|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |