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

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

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

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

> 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

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

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

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 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

> 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