Re: Trouble Getting Started

Steve wrote:
> Hi;
> 
> I am having trouble getting started with venkham.   I think I am
> missing something conceptually which is causing me to skip a needed
> step that other people see by reading between the lines of the
> tutorials.
> 
> Firefox:      2.0.0.11
> Venkahm:  0.9.87.1
> OS:           Microsoft Windows XP Professional Service Pack 2
> 
> I would like to debug a javascript on a JSP site my company has.
> Since any given functioning page is put together dynamically, I went
> to the spot where the JS malfunction is and I saved the JSP as a
> *.html page.  Lets call it "mypage.html".
> 
> 1.  I booted up firefox fresh
> 
> 2.  I booted up venkham
> 
> 3.  In Venkham I went to File | Open to bring up mypage.html
> 
> 4.  I scrolled to the definition for  myfieldlostfocusproc()
> 
> 5.  I tried to set this as a breakpoint, but could only set it as a
> future breakpoint.   I understand it is a "top level" funciton and it
> hasn't been loaded.
> 
> 6. I go back to firefox and open the mypage.html in the browser, from
> my desktop.   "mypage.html" appears in the loaded scripts window.  The
> only node under it is "onblur".
> 
> 7. In firefox, in mypage.html,  I go to "myfield" type in a value and
> leave "myfield" which *SHOULD* fire myfieldlostfocusproc(), and bring
> the debugger to that function.
> 
> This doesn't happen and this is where I am stuck.
> 
> I don't really have a top level function in mypage.html.   It is a
> page of html fields, with each field having its own function that gets
> activated onblur.
> 
> A few times, noodling around, I was able to set a breakpoint on
> "onblur", the only node visible under mypage.html in the loaded script
> window.   That would take me to the very top of the file and would
> finally activate the debugging controls like the continue button so I
> could get going.   Playing around I could get to the point.........by
> accident.......of having myfieldlostfocusproc()  BEING LOADED, active,
> and having a real break point.
> 
> The problem is, when I stopped everything and started from scratch to
> test my understanding I could never intentionally get
> myfieldlostfocusproc() to load.
> 
> myfieldlostfocusproc() is called from the onblur event of the myfield
> html text field in mypage.html.
> 
> LOL.  I need a clue.
> 
> As I understand debuggers:
> 1.  You first bring up the source code and mark some breakpoints
> 2.  You activate the live code
> 3.  Somehow the debugger links what it knows about the source to the
> live code, it comes alive and stops at the breakpoint to let you begin
> debugging.
> 
> I can't intentionally get #3 to happen in my steps 1 - 7 above.
> 
> Any ideas what I am missing?
> 
> Thanks in advance for any info.
> 
> Please reply to the group as the above address is just a spam catcher
> I rarely check.  Im sure other people will find your coments useful
> too.  Thanks
> 
> Steve
> 

Hi Steve, thanks for the detailed feedback.

Unfortunately I don't have the time to try to recreate the exact setup 
you're describing (writing my own html file etc.) - if you can point us 
to an example on the web, that would probably help. I will instead reply 
to your understanding of debuggers, hoping that may clarify things.

The most important thing to understand is that JavaScript is an 
interpreted language. Before the source code is interpreted, there is no 
"live code" to be activated, unlike compiled C or Java programs, where 
the source representation will have a "ready-made" compiled equivalent. 
This is why venkman, when you present it with a new file, will set a 
"future" breakpoint - it will attempt to break on that line if the file 
in question eventually gets loaded, but it can't be sure that line is 
actually executable: it doesn't interpret the files you give it. It 
expects Mozilla's javascript engine to do that for it, which it will as 
soon as you load the file.

Looking at it from the other end, do the following:

1. Open your browser and Venkman
2. Open a random webpage with script in your webbrowser.
3. Look for the associated file which has script in it, and open this in 
venkman from the "loaded scripts" view by double-clicking it.

You will now see the file get loaded, and to the left of the source you 
will see dashes on all lines that venkman can set a breakpoint on. There 
will be no dashes for empty lines, comments, etc. The reason this works 
the way it does is because the result of the interpretation step (which 
was made when you loaded the webpage) is bytecode, which venkman's 
backend APIs need to translate back into actual source lines. Then, when 
you set a breakpoint on a line, Venkman looks at its translation, 
figures out which bit of bytecode it should set a breakpoint at, and 
tells the JS runtime that. You might say "but shouldn't the runtime 
allow you to set a breakpoint by line?" - maybe. But it doesn't. The 
point of the "future" breakpoint, then, is to set a breakpoint in a file 
that's not yet loaded. The "future" means "I'm not sure if I'm going to 
be able to manage stopping here, so don't expect too much".

[warning: less-well-researched stuff coming up:] Other debuggers, like 
Firebug, opt instead to let you break wherever, and this may or may not 
lead to expected results (ie an actual breakpoint). Venkman decided to 
do things the way it does a looong time ago, and I'm not sure whether 
we're up for changing it - the current system works if you get the hang 
of it.



Then, as general advice: have you read Svendt Tofte's guide? ( 
http://www.svendtofte.com/code/learning_venkman/ ) It's quite old by 
now, but still a pretty good guide on how to get started with the debugger.

Oh, and finally: enabling both Venkman and Firebug at the same time 
sometimes gets you into trouble (again, because of the way the backend 
API works - neither add-on can do much about it without breaking some or 
all of its functionality). It's best to avoid doing this.

~ Gijs