![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I forget who suggested this, but I have a Firefox extension named
Firebug installed on my work PC. This allows me to do several rather
interesting things. And utterly fails to allow me to do several other
things.
I mainly use it for looking at the document tree. Firefox itself will
only show you the text it loaded from disk. If you use the DOM to modify
the document, there is *no way* to discover what Firefox is actually
rendering. To my great relief, Firebug offers a way to see what the
document tree looks like *now*, not when it was first loaded. So I can
see whether my scripting has built the correct document tree or not.
It also appears to have some facilities related to tracking down
complicated style cascades, which I shall probably never need to use, ever.
A couple of days ago, I discovered that it has a JavaScript debugging
feature. Now that sounds quite useful, but unfortunately it doesn't
appear to actually, you know, *work*.
- There's a button you can press that makes it so that next time a
script runs, it immediately pops up in the script window. Unfortunately,
pressing "step into" has the effect of "step over" approximately 85% of
the time. This is the utter height of uselessness. Click a button and it
says "this would cause Foo() to run". So you click "step into"... and it
steps *over* Foo(), without showing you what's happening. Very helpful.
- As far as I can tell, breakpoints don't work. Like, I have a button
that runs Bar() when you click it. So I put a breakpoint on Bar(), and
click the button. The script runs, but no breakpoint. Again, very helpful.
- It seems Firebug is unable to handle function calls where the function
to be called is not statically known. For example, if there's a Foo()
function defined, and you do
Foo(5);
then you can step into Foo(). However, if instead you do
var Bar = Foo;
Bar(5);
then Firebug apparently has *no clue* what function you just called.
This is extremely limiting when you consider that my entire application
is fundamentally based on this type of thing.
I wonder if any of this is likely to be fixed anytime soon?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 20/10/2010 04:42 PM, Invisible wrote:
> - As far as I can tell, breakpoints don't work. Like, I have a button
> that runs Bar() when you click it. So I put a breakpoint on Bar(), and
> click the button. The script runs, but no breakpoint. Again, very helpful.
OH MY GOD! >_<
It seems breakpoints work, but *only* if the exact line you put the
breakpoint on contains a line of executable code.
So if you put the breakpoint on the function name, nothing happens. If
you put the breakpoint on a line within the function that happens to be
blank, nothing happens. If you put the breakpoint on a line that just
contains a comment, nothing happens. *Only* if the line contains at
least one executable statement does the breakpoint fire. WTF?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> WTF?
This is called "bedding in." It happens in all software (and, for that
matter, in every bit of technology you need to practice with to learn). Now
that you know that, you'll never try to breakpoint a comment again. In a
year from now, when people bitch about how crappy the debugger is, you'll
say "works for me! Must be your problem."
That's why you have to take everything people say about how great or how
crappy some large well-know system is (like an OS or an office suite) with a
grain of salt, especially when it's primarily a UI discussion.
--
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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
> So if you put the breakpoint on the function name, nothing happens. If
> you put the breakpoint on a line within the function that happens to be
> blank, nothing happens. If you put the breakpoint on a line that just
> contains a comment, nothing happens. *Only* if the line contains at
> least one executable statement does the breakpoint fire. WTF?
as Darren said. Works the same in Delphi.
regarding var B = Foo; B(), I have no clue.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Now that you know that, you'll never try to breakpoint a comment again.
Well, so far this has tripped me over at least 17 times since I
discovered what the problem was.
> In a year from now, when people bitch about how crappy the debugger is,
> you'll say "works for me! Must be your problem."
I can't believe that such a trivially fixable issue isn't fixed... In
fact, I can't believe that nobody caught this in testing. 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.
How did this miss this?!
The next thing, of course, is that if I put a breakpoint on line 137, I
now have to guess whether that means execution halts *before* line 137
runs or *after* line 137 runs. In any normal debugger I could just put
the breakpoint on line 136 or line 138 (assuming they're empty), but nooo...
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. I mean, the effort to fix this glitch compared to
the effort of developing the debugger in the first place...
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*!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/20/2010 11:25 AM, nemesis wrote:
>
> as Darren said. Works the same in Delphi.
>
Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
studio does something "clever": It moves the breakpoint if its not on a
valid line to the next valid line once it has the debugging info for the
module the code file belongs to.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford wrote:
> On 10/20/2010 11:25 AM, nemesis wrote:
>>
>> as Darren said. Works the same in Delphi.
>>
>
> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
> studio does something "clever": It moves the breakpoint if its not on a
> valid line to the next valid line once it has the debugging info for the
> module the code file belongs to.
>
I thought it was kind of funky-clever how they figured out when a statement
ended. They analyze the code and count pushes and pops, and a statement
ends when the evaluation stack pops the last value off. That's the
definition of "one statement" in the CIL - the code between the first push
and the matching pop that empties the data/operand stack.
--
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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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!
The next thing I'll be hearing is "patches welcome"...
> 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".
You realise that the UI already highlights the lines that have code on
them, right? So the code to figure this out already exists. All you have
to do is look at where the user put the breakpoint, and select the
nearest line that's executable. The only possibly-tricky thing is having
the breakpoint set on line X+N put appear to be set on line X.
Failing that, you could just refuse to set a breakpoint on a line if it
doesn't contain any executable code. That would be even more trivial to
implement.
And yet Firebug does neither of these things.
>> 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.
I'm still trying to find a way to run CGI binaries (note: binaries, not
scripts) without having to install and configure Apache or something
like it.
It seems there are plenty of light-weight HTTP servers, but all of them
either lack CGI support entirely, or only support CGI *scripts* (usually
in a single language).
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
> studio does something "clever": It moves the breakpoint if its not on a
> valid line to the next valid line once it has the debugging info for the
> module the code file belongs to.
I wouldn't have called that "clever". I would have called that "the most
basic functionality that any non-toy debugger would be expected to
have". Certainly I've never seen a debugger with this limitation
before... (Although I can't claim to have used all that many debuggers.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |