Silly Newbie Mistake

[Gene Wirchenko]

Dear JavaScripters:

At the best of time, I have found debugging JavaScript code to be
such a bother. I have been using IE's F12, but it does not handle (or
I have not figured out how) debugging an included file (<script
src=...). (If you know how, would you please let me know?) As a
consequence, I did not get immediate feedback on my silly error and
wasted a couple of hours.

You see, I have done a lot of programming in Visual FoxPro. Its
line comment token is "&&". Somehow, I typed that, instead of "//",
and I did not see it as an error for some time.

Go ahead and laugh, but it could be you next time.

Sincerely,

Gene Wirchenko

[Evertjan.]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:

> At the best of time, I have found debugging JavaScript code to be
> such a bother. I have been using IE's F12, but it does not handle (or
> I have not figured out how) debugging an included file (<script
> src=...). (If you know how, would you please let me know?)

Debugging can easily be done with setting breakpoints:

.....
alert( 'line 12: ' + myValueToBeRead )
.....

.....
if (myValueToBeRead>12) alert( 'line 345: ' + myValueToBeRead )
.....

and commenting it out when not needed:

// alert( 'line 12: ' + myValueToBeRead )

Yes, I know this is not a Remedium Totalis,
breaking up time-sensitive code for instance,
but using your brain's logical programme will get you there,
as long as you understand your code-to-be-debugged in the first place.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Steve Wakeford]

If you can use Firefox there is a great add-on called FireBug http://getfirebug.com/

It has an integrated line debugger with support for breakpoints, watch expressions, visible call stack. It also can be just as simple as outputting the JavaScript error that halted script execution, usually this will be all you need. Great plugin and definitely industry standard for web development.

[Jacob Block]

I really like using Google Chrome's web tools. Just hit ctrl+shift+I
and you can look at scripts, set breakpoints and reload and trace
through programs. It gives you great information in tool-tips on all
variables and you can do some fancier stuff too. I am new at
Javascript and was wondering if there is anything better than
developing just in Chrome too (yeah I've tried Firefox's plugins, but
they don't seem as fluid). Based on these replies it seems like there
isn't. I have experience with Eclipse and haven't really looked in to
doing web development in it. I know there are some plugins, but Chrome
just seemed easier for the small stuff I've been doing.

Jacob

[Jacob Block]

On Dec 6, 9:32 pm, Gene Wirchenko <ge...@ocis.net> wrote:

I should also add that you can monitor HTML and javascript in real-
time. I was reviewing a JQuery plugin slideshow plugin and HTML tags
were popping up and disappearing as I was doing the hovering. I
thought that was really cool/helpful. Not sure if other environments
can handle that. You can also make changes in real-time like someone
above mentioned of Firefox. Definitely check it out!

Jacob

[Gene Wirchenko]

On 07 Dec 2011 08:43:43 GMT, "Evertjan."

<exjxw.ha...@interxnl.net> wrote:

>Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
>
>> At the best of time, I have found debugging JavaScript code to be
>> such a bother. I have been using IE's F12, but it does not handle (or
>> I have not figured out how) debugging an included file (<script
>> src=...). (If you know how, would you please let me know?)
>
>Debugging can easily be done with setting breakpoints:

When it works. When it does not, it is a bother.

[snip]

>Yes, I know this is not a Remedium Totalis,
>breaking up time-sensitive code for instance,
>but using your brain's logical programme will get you there,
>as long as you understand your code-to-be-debugged in the first place.

Since I am following a text to learn JavaScript, that is not
necessarily the case. I have found bugs in the code examples, too. It
is rather time-consuming at times.

Sincerely,

Gene Wirchenko

[Richard Cornford]

On Dec 7, 2:32 am, Gene Wirchenko wrote:
> Dear JavaScripters:
>
> At the best of time, I have found debugging JavaScript code
> to be such a bother.

It gets easier. There is an inevitably (because we are dealing with
machines) close relationship between the error messages generated by
javascript engines so eventually the specific message text will pretty
much tell you what you need to be looking for (and where), which makes
it fairly trivial to find and fix it.

> I have been using IE's F12, but it does not handle (or
> I have not figured out how) debugging an included file (<script
> src=...).

Not being able to debug included resources would be so useless for a
javascript debugger that this extremely unlikely to be the case.

> (If you know how, would you please let me know?) As a
> consequence, I did not get immediate feedback on my silly
> error and wasted a couple of hours.

But your "silly error" was (almost certainly) a syntax error, so if
set up to do so IE would have popped up its error dialog as soon as it
spotted the syntax error. Trying to develop on IE while not having pop-
up its error dialog for every error will waste a great deal of time.

> You see, I have done a lot of programming in Visual FoxPro.
> Its line comment token is "&&". Somehow, I typed that, instead
> of "//", and I did not see it as an error for some time.

That type of mistake is pretty common. The version I have seen most
often has been people used to writing VBScript trying to use its
comment delimiter in javascript. That is always going to be a syntax
error, but even though your - && - is a javascript operator it is
still unlikely that you could both semicolon terminate the statement
being commented on and/or write a worthwhile comment without the
result being a syntax error.

Remember that a syntax error will be identified when the code is
parsed, the result will never be executable, and so a debugger, as
such, will be of no use in identifying that problem because it will
not have anything executable to work with.

> Go ahead and laugh, but it could be you next time.

Mistakes are inevitable, but syntax errors are not that difficult to
find and fix.

Richard.

[Mel Smith]

Hi:

I too use IE (actually IE7) as my test bed because my small set of users
are older people with IE as the browser.

In any case, *my* error was using the assignment operator := instead
of =

(altho I have used FoxBase, FoxPlus, and later FoxPro, for the last ten
years I've used Harbour/xHarbour for web site development. This language
uses := as the assignment operator.)

I spent two hours wondering why nothing was happening as I modified code
in my Javascript. Even the Alert() messages were not displaying.

After *finally* locating this faulty assignment operator and correcting
it, my javascript started working again.

So, altho I have Chrome and FF on my dev machine, I do most of my
primary development using IE and Javascript.

I guess I'll have to use more Chrome or FF for development.

(but again, the biggest confusion is syntactic because my language is so
much like Javascript, but again different in many small ways -- and I
program in both languages every day -- a brain buster !)

-Mel Smith

[Gene Wirchenko]

On Thu, 8 Dec 2011 03:56:38 -0800 (PST), Richard Cornford
<Ric...@litotes.demon.co.uk> wrote:

>On Dec 7, 2:32 am, Gene Wirchenko wrote:
>> Dear JavaScripters:
>>
>> At the best of time, I have found debugging JavaScript code
>> to be such a bother.
>
>It gets easier. There is an inevitably (because we are dealing with
>machines) close relationship between the error messages generated by
>javascript engines so eventually the specific message text will pretty
>much tell you what you need to be looking for (and where), which makes
>it fairly trivial to find and fix it.

I am not getting error messages. I simply get no page display.
This makes tracking down errors considerably more difficult and
time-consuming.

>> I have been using IE's F12, but it does not handle (or
>> I have not figured out how) debugging an included file (<script
>> src=...).
>
>Not being able to debug included resources would be so useless for a
>javascript debugger that this extremely unlikely to be the case.

The probability is 1. Note that I stipulated "(or I have not
figured out how)". A feature that I can not figure out how to use
might as well not exist. How does it work?

>> (If you know how, would you please let me know?) As a
>> consequence, I did not get immediate feedback on my silly
>> error and wasted a couple of hours.
>
>But your "silly error" was (almost certainly) a syntax error, so if
>set up to do so IE would have popped up its error dialog as soon as it
>spotted the syntax error. Trying to develop on IE while not having pop-
>up its error dialog for every error will waste a great deal of time.

Yes. I have looked. Where is that setting?

>> You see, I have done a lot of programming in Visual FoxPro.
>> Its line comment token is "&&". Somehow, I typed that, instead
>> of "//", and I did not see it as an error for some time.
>
>That type of mistake is pretty common. The version I have seen most
>often has been people used to writing VBScript trying to use its
>comment delimiter in javascript. That is always going to be a syntax
>error, but even though your - && - is a javascript operator it is
>still unlikely that you could both semicolon terminate the statement
>being commented on and/or write a worthwhile comment without the
>result being a syntax error.

Which is not reported on my system.

>Remember that a syntax error will be identified when the code is
>parsed, the result will never be executable, and so a debugger, as
>such, will be of no use in identifying that problem because it will
>not have anything executable to work with.
>
>> Go ahead and laugh, but it could be you next time.
>
>Mistakes are inevitable, but syntax errors are not that difficult to
>find and fix.

They can be if the error is not reported.

Sincerely,

Gene Wirchenko

[Evertjan.]

Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:

> On 07 Dec 2011 08:43:43 GMT, "Evertjan."
> <exjxw.ha...@interxnl.net> wrote:
>
>>Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
>>
>>> At the best of time, I have found debugging JavaScript code to be
>>> such a bother. I have been using IE's F12, but it does not handle
(or
>>> I have not figured out how) debugging an included file (<script
>>> src=...). (If you know how, would you please let me know?)
>>
>>Debugging can easily be done with setting breakpoints:
>
> When it works. When it does not, it is a bother.

Why a bother? Debugging is just the way to unbother.

>
> [snip]
>
>>Yes, I know this is not a Remedium Totalis,
>>breaking up time-sensitive code for instance,
>>but using your brain's logical programme will get you there,
>>as long as you understand your code-to-be-debugged in the first place.
>
> Since I am following a text to learn JavaScript, that is not
> necessarily the case. I have found bugs in the code examples, too. It
> is rather time-consuming at times.

If you "follow a text",
is understanding the code less necessary for debugging?



> Sincerely,
>
> Gene Wirchenko

[Gene Wirchenko]

On 08 Dec 2011 21:28:51 GMT, "Evertjan."

<exjxw.ha...@interxnl.net> wrote:

>Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:

[SNIP]

>Why a bother? Debugging is just the way to unbother.

I have pages crash with no error message. It is then a bother to
hunt down errors. Perhaps, you have your browser set up with all of
the nifty settings for detecting AND REPORTING errors. Despite
looking for them repeatedly, I have been unable to find them.

[snip]

>> Since I am following a text to learn JavaScript, that is not
>> necessarily the case. I have found bugs in the code examples, too. It
>> is rather time-consuming at times.
>
>If you "follow a text",
>is understanding the code less necessary for debugging?

No. My point is that I do not necessarily understand the code at
the time I have the problem, especially right after I have typed it
in. Did I type it in wrong? Is there a bug?

I also tend to make changes to bring the code in line with the
way I prefer for formatting, naming conventions, robustness, etc. For
example, the code often uses hard references such as parent.frames[0].
I change these by naming the frame and using the name. Sometimes,
this causes problems though less than right after typing the code in.

Sincerely,

Gene Wirchenko

[Ross McKay]

On Tue, 06 Dec 2011 18:32:58 -0800, Gene Wirchenko wrote:

> At the best of time, I have found debugging JavaScript code to be
>such a bother. I have been using IE's F12, but it does not handle (or
>I have not figured out how) debugging an included file (<script
>src=...). (If you know how, would you please let me know?) As a
>consequence, I did not get immediate feedback on my silly error and
>wasted a couple of hours.

I highly recommend you learn JavaScript in either Firefox with the
Firebug extension[1] or Google Chrome. The debugging tools are much
better. I guess you can also throw in Opera, as Dragonfly is pretty good
too (but slower on starting). Just load the page once, navigate to the
included scripts in the debugger, set your breakpoints, then reload.

Keep IE's tools for debugging IE-specific problems.

Also learn how to make good use of the console logging tools.[2][3]

> You see, I have done a lot of programming in Visual FoxPro. Its
>line comment token is "&&". Somehow, I typed that, instead of "//",
>and I did not see it as an error for some time.

You might find greater happiness (less Risk!) in returning to an edit /
"compile" / test cycle, where "compile" is actually a lint pass to check
for such basic mistakes.[4][5] You'll probably need to tinker with the
config files to suppress some screaming though, as linters can be
excessively fussy at times :)


[1] https://addons.mozilla.org/en-US/firefox/addon/firebug/
[2] https://developer.mozilla.org/en/Using_the_Web_Console
[3] http://getfirebug.com/wiki/index.php/Console_API
[4] http://www.jslint.com/
[5] http://www.javascriptlint.com/
--
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin

[Evertjan.]

Gene Wirchenko wrote on 08 dec 2011 in comp.lang.javascript:

> On 08 Dec 2011 21:28:51 GMT, "Evertjan."
> <exjxw.ha...@interxnl.net> wrote:
>
>>Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
>
> [SNIP]
>
>>Why a bother? Debugging is just the way to unbother.
>
> I have pages crash with no error message. It is then a bother to
> hunt down errors. Perhaps, you have your browser set up with all of
> the nifty settings for detecting AND REPORTING errors. Despite
> looking for them repeatedly, I have been unable to find them.

I mostly do not use [your nifty] browser debuggers.

I just told you I set the necessary alert() breakpoints.

If the code does not run for syntactical reasons,
I remark out all the lines of code that could be the culprit,
and reinsert them in groups, using

//.... or /*...*/,

or my preference when debugging clientside js on an asp-page:

<script type='text/javascript'>
<% debug = true %>
.....
<% if not debug then %>
...
...
<% end if %>
...
</script>

>>> Since I am following a text to learn JavaScript, that is not
>>> necessarily the case. I have found bugs in the code examples, too.
>>> It is rather time-consuming at times.
>>
>>If you "follow a text",
>>is understanding the code less necessary for debugging?
>
> No. My point is that I do not necessarily understand the code at
> the time I have the problem, especially right after I have typed it
> in. Did I type it in wrong? Is there a bug?
>
> I also tend to make changes to bring the code in line with the
> way I prefer for formatting, naming conventions, robustness, etc. For
> example, the code often uses hard references such as parent.frames[0].
> I change these by naming the frame and using the name.

Right

> Sometimes,
> this causes problems though less than right after typing the code in.

Why would that cause problems [stipulating that you understand the code?

[Dr J R Stockton]

In comp.lang.javascript message <nojtd7pb39ofku9j7a1bi6pog635kga2ua@4ax.
com>, Tue, 6 Dec 2011 18:32:58, Gene Wirchenko <ge...@ocis.net> posted:

> At the best of time, I have found debugging JavaScript code to be
>such a bother. I have been using IE's F12, but it does not handle (or
>I have not figured out how) debugging an included file (<script
>src=...). (If you know how, would you please let me know?) As a
>consequence, I did not get immediate feedback on my silly error and
>wasted a couple of hours.

But we here are smarter, and so use other browsers.

Note that the reported market share for other browsers is now
considerably greater than that for IE.

Of course, once the author's sillies have been dealt with by using other
browsers, one should use IE and try to deal with its sillies.

For code not reliant on a GUI and I/O, it may well be worth testing in
JScript under WSH. That at least gives a clear indication, in your
choice of font size, of where it thinks the error is or becomes
detectable.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike 6.05 WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[Gene Wirchenko]

On Thu, 08 Dec 2011 22:39:52 +0000, Tim Streater
<timst...@greenbee.net> wrote:

>In article <1ae2e7lj274chonhf...@4ax.com>,

> Gene Wirchenko <ge...@ocis.net> wrote:
>
>> On 08 Dec 2011 21:28:51 GMT, "Evertjan."
>> <exjxw.ha...@interxnl.net> wrote:
>>
>> >Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
>>
>> [SNIP]
>>
>> >Why a bother? Debugging is just the way to unbother.
>>
>> I have pages crash with no error message. It is then a bother to
>> hunt down errors. Perhaps, you have your browser set up with all of
>> the nifty settings for detecting AND REPORTING errors. Despite
>> looking for them repeatedly, I have been unable to find them.
>

>The browsers will report errors by default.

If that were true, I would not be having the trouble that I am
having.

>Have you been looking in the error consoles as I have been suggesting?

I can not find anything called that.

I am using IE 9.

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On 08 Dec 2011 23:41:03 GMT, "Evertjan."

<exjxw.ha...@interxnl.net> wrote:

>Gene Wirchenko wrote on 08 dec 2011 in comp.lang.javascript:
>
>> On 08 Dec 2011 21:28:51 GMT, "Evertjan."
>> <exjxw.ha...@interxnl.net> wrote:
>>
>>>Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
>>
>> [SNIP]
>>
>>>Why a bother? Debugging is just the way to unbother.
>>
>> I have pages crash with no error message. It is then a bother to
>> hunt down errors. Perhaps, you have your browser set up with all of
>> the nifty settings for detecting AND REPORTING errors. Despite
>> looking for them repeatedly, I have been unable to find them.
>
>I mostly do not use [your nifty] browser debuggers.
>
>I just told you I set the necessary alert() breakpoints.

And I have said a number of times that some errors do not get
picked up by that. The page simply does not render.

>If the code does not run for syntactical reasons,
>I remark out all the lines of code that could be the culprit,
>and reinsert them in groups, using
>
>//.... or /*...*/,

I have done similarly. I think that you can understand that
having to do so is much much more effort than getting a message such
as:
Syntax error in line 47 of somepage.html
and proceeding from there.

[snip]

>> Sometimes,
>> this causes problems though less than right after typing the code in.
>
>Why would that cause problems [stipulating that you understand the code?

Oh, come on! Typos, and of course, if I am experimenting with
features, your stipulation is silly: it is not a safe bet that I
understand the code totally.

Sincerely,

Gene Wirchenko

[kiran]

LOL I am already there.

[Gene Wirchenko]

On Thu, 08 Dec 2011 21:35:09 +0000, Tim Streater
<timst...@greenbee.net> wrote:

>In article <3u42e7d2uq84hj3hn...@4ax.com>,
> Gene Wirchenko <ge...@ocis.net> wrote:
>
>[snip]

>
>> I am not getting error messages. I simply get no page display.
>> This makes tracking down errors considerably more difficult and
>> time-consuming.
>

>[snip]

>
>> They can be if the error is not reported.
>

>No decent browser is going to detect an syntax error, and then not
>report it.

I am using IE 9. I do not care if you consider it then to be not
a decent browser. It is the one that I have to use. I think it
highly likely that it can report errors, but I am not getting that.

[snip]

>If in your case the page isn't being loaded you might have no syntax
>error, instead a logic error that means what you think is a pointer to
>some DOM item is in fact null, and execution stops right there (I'm
>assuming your JS loads the page, otherwise you'd see it - in my error
>case the page load completes but because JS execution doesn't, various
>buttons are not disabled as normal).

There are those sorts of errors at times, too, but I have
execution stopping dead due to syntax errors.

>Have you looked in the FF error console? (Tools -> Web Developer -.
>Error Console)

As stated previously, I am using IE 9. I have seen the F12
tools, but they do not work reliably for me (or I am missing
something).

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Thu, 8 Dec 2011 19:40:43 +0000, Dr J R Stockton
<repl...@merlyn.demon.co.uk> wrote:

>In comp.lang.javascript message <nojtd7pb39ofku9j7a1bi6pog635kga2ua@4ax.
>com>, Tue, 6 Dec 2011 18:32:58, Gene Wirchenko <ge...@ocis.net> posted:
>
>> At the best of time, I have found debugging JavaScript code to be
>>such a bother. I have been using IE's F12, but it does not handle (or
>>I have not figured out how) debugging an included file (<script
>>src=...). (If you know how, would you please let me know?) As a
>>consequence, I did not get immediate feedback on my silly error and
>>wasted a couple of hours.
>
>But we here are smarter, and so use other browsers.

I prefer Firefox myself, but company standard is IE.

>Note that the reported market share for other browsers is now
>considerably greater than that for IE.

IE still has a considerable plurality, not that that makes a
difference to me. The company standard is IE.

>Of course, once the author's sillies have been dealt with by using other
>browsers, one should use IE and try to deal with its sillies.

I will be developing a complex system in IE. I need to learn it
inside out.

>For code not reliant on a GUI and I/O, it may well be worth testing in
>JScript under WSH. That at least gives a clear indication, in your
>choice of font size, of where it thinks the error is or becomes
>detectable.

??? How would a Webpage not be reliant on I/O?

Sincerely,

Gene Wirchenko

[Gene Wirchenko]

On Fri, 09 Dec 2011 09:47:00 +1100, Ross McKay
<au.org.zet...@invalid.invalid> wrote:

>On Tue, 06 Dec 2011 18:32:58 -0800, Gene Wirchenko wrote:
>
>> At the best of time, I have found debugging JavaScript code to be
>>such a bother. I have been using IE's F12, but it does not handle (or
>>I have not figured out how) debugging an included file (<script
>>src=...). (If you know how, would you please let me know?) As a
>>consequence, I did not get immediate feedback on my silly error and
>>wasted a couple of hours.
>
>I highly recommend you learn JavaScript in either Firefox with the
>Firebug extension[1] or Google Chrome. The debugging tools are much
>better. I guess you can also throw in Opera, as Dragonfly is pretty good
>too (but slower on starting). Just load the page once, navigate to the
>included scripts in the debugger, set your breakpoints, then reload.

I do not have the option. The company standard is IE.

[snip]

Sincerely,

Gene Wirchenko

[Ross McKay]

On Thu, 08 Dec 2011 17:26:32 -0800, Gene Wirchenko wrote:

> I do not have the option. The company standard is IE.

Which is fine when you know what you are doing, but while you are
learning the language you should use good learning tools -- the IE
developer tools are passable for debugging real like IE problems, but
you should not be writing solely for IE9 (lock in anyone?) and you will
get better diagnostic information from Firefox+Firebug and Google
Chrome.

Also, a JS lint tool does not care about what browser you are using, it
looks at your source files:

>>You might find greater happiness (less Risk!) in returning to an edit /
>>"compile" / test cycle, where "compile" is actually a lint pass to check
>>for such basic mistakes.[4][5] You'll probably need to tinker with the
>>config files to suppress some screaming though, as linters can be
>>excessively fussy at times :)

>>[...]

>>[4] http://www.jslint.com/
>>[5] http://www.javascriptlint.com/
--
Ross McKay, Toronto, NSW Australia

"If ye cannae see the bottom, dinnae complain if ye droon"

[Evertjan.]

Gene Wirchenko wrote on 09 dec 2011 in comp.lang.javascript:

> [snip]
>
>>> Sometimes,
>>> this causes problems though less than right after typing the code
>>> in.
>>
>>Why would that cause problems [stipulating that you understand the
>>code?
>
> Oh, come on! Typos, and of course,

Modular programming even on the minute scale of common browser
javascript prograsmes, will prevent that.

function tempModule(arguments) {
alert(arguments);
return tempReturnValues; // replace with absolute test-value;
};

If this works, then replace the fmodule with it's dynamic equivlent.

> if I am experimenting with features, your stipulation is silly:

This is not a stipulation, it is an advice from years of experience.

> it is not a safe bet that I understand the code totally.

It should not be a "safe bet", it should be your effort.
your code cann't be sound, if you don' understand it,
and an added bonus is that you learn from this added understanding.

Trying to debug code that you do not understand is futile,
because it is error-prone. Just testing a ununderstood code can never
reach the level of stability that you usually would expect of your
programming and that can be reached by understood and debugged code.

Total understanding is easuier if you understand your modular modules
and the compilation of those modules in your total design.

Experimenting with say! new DOM-features in a large code without first
having tested and understood that feature on a small scale on a simple
test-page seems inadvisable.

[Norman Peelman]

On 12/08/2011 08:15 PM, Gene Wirchenko wrote:
> On 08 Dec 2011 23:41:03 GMT, "Evertjan."
> <exjxw.ha...@interxnl.net> wrote:
>
>> Gene Wirchenko wrote on 08 dec 2011 in comp.lang.javascript:
>>
>>> On 08 Dec 2011 21:28:51 GMT, "Evertjan."
>>> <exjxw.ha...@interxnl.net> wrote:
>>>
>>>> Gene Wirchenko wrote on 07 dec 2011 in comp.lang.javascript:
>>>
>>> [SNIP]
>>>
>>>> Why a bother? Debugging is just the way to unbother.
>>>
>>> I have pages crash with no error message. It is then a bother to
>>> hunt down errors. Perhaps, you have your browser set up with all of
>>> the nifty settings for detecting AND REPORTING errors. Despite
>>> looking for them repeatedly, I have been unable to find them.
>>
>> I mostly do not use [your nifty] browser debuggers.
>>
>> I just told you I set the necessary alert() breakpoints.
>
> And I have said a number of times that some errors do not get
> picked up by that. The page simply does not render.
>

Are you saying that you don't even get the "page has completed but
with errors" message at the bottom of the browser window, which when
clicked on brings up a small pop-up window with an error message?

>> If the code does not run for syntactical reasons,
>> I remark out all the lines of code that could be the culprit,
>> and reinsert them in groups, using
>>
>> //.... or /*...*/,
>
> I have done similarly. I think that you can understand that
> having to do so is much much more effort than getting a message such
> as:
> Syntax error in line 47 of somepage.html
> and proceeding from there.
>
> [snip]
>
>>> Sometimes,
>>> this causes problems though less than right after typing the code in.
>>
>> Why would that cause problems [stipulating that you understand the code?
>
> Oh, come on! Typos, and of course, if I am experimenting with
> features, your stipulation is silly: it is not a safe bet that I
> understand the code totally.
>
> Sincerely,
>
> Gene Wirchenko

Googling 'ie javascript debugger' brought up links that include these
links.

http://www.debugbar.com/

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18359

http://projects.nikhilk.net/WebDevHelper/


--
Norman
Registered Linux user #461062
AMD64X2 6400+ Ubuntu 10.04 64bit

[Mike Duffy]

"Evertjan." <exjxw.ha...@interxnl.net> wrote in
news:Xns9FB665A...@194.109.133.133:

> Trying to debug code that you do not understand is futile,

It does force you to learn. But you do have a point. Sometimes, what you
learn is wrong. If those wrong ideas are close to the root of the knowledge
tree you build on a particular subject, pruning the bad branches can
sometimes cause the whole tree to collapse.

--
http://pages.videotron.ca/duffym/index.htm

[Richard Cornford]

On Dec 8, 7:49 pm, Gene Wirchenko wrote:
> On Thu, 8 Dec 2011 03:56:38 -0800 (PST), Richard Cornford

>>On Dec 7, 2:32 am, Gene Wirchenko wrote:
>>> Dear JavaScripters:
>
>>> At the best of time, I have found debugging JavaScript code
>>> to be such a bother.
>
>> It gets easier. There is an inevitably (because we are dealing with
>> machines) close relationship between the error messages generated
>> by javascript engines so eventually the specific message text will
>> pretty much tell you what you need to be looking for (and where),
>> which makes it fairly trivial to find and fix it.
>
> I am not getting error messages. I simply get no page display.

"No page display", if taken literally, sounds more like a problem with
HTML or the browser's ability to access the page. Obviously if either
of those where the case then there is no chance of any javascript
executing at all, so there won't even be syntax errors.

> This makes tracking down errors considerably more difficult and
> time-consuming.

The difficult and time consuming part is learning how things should
work and how to verify when/that they are. "No page display" is such
an extreme symptom that it won't have more than a dozen or so possible
causes, which would come into play in a certain order and so can be
tested for and either eliminated or identified as pertinent with a
shortish sequence of tests.

>>> I have been using IE's F12, but it does not handle (or
>>> I have not figured out how) debugging an included file (<script
>>> src=...).
>
>> Not being able to debug included resources would be so useless
>> for a javascript debugger that this extremely unlikely to be
>> the case.
>
> The probability is 1.

The probability of what exactly?

> Note that I stipulated "(or I have not figured out how)".

I noticed, and it struck me as likely to be the case here.

> A feature that I can not figure out how to use
> might as well not exist.

True, but it is unlikely that the limits of your comprehension will be
restrictive in this context.

> How does it work?
>
>>> (If you know how, would you please let me know?) As a
>>> consequence, I did not get immediate feedback on my silly
>>> error and wasted a couple of hours.
>
>> But your "silly error" was (almost certainly) a syntax error, so
>> if set up to do so IE would have popped up its error dialog as
>> soon as it spotted the syntax error. Trying to develop on IE

>> while not having pop-up its error dialog for every error will

>> waste a great deal of time.
>
> Yes. I have looked. Where is that setting?

<snip>

Tools->Internet Options...->Advanced(tab)->Settings(list)-
>Browsing(sublist)->Display a notification about every script
error(checkbox); should be checked, and also any "Disable script
debugging" checkboxes above it (these checkboxes don't refer to F12
debugging, apparently).

Richard.

[Thomas 'PointedEars' Lahn]

Mike Duffy wrote:

> "Evertjan." wrote:
>> Trying to debug code that you do not understand is futile,
>
> It does force you to learn. But you do have a point. Sometimes, what you
> learn is wrong. If those wrong ideas are close to the root of the
> knowledge tree you build on a particular subject, pruning the bad branches
> can sometimes cause the whole tree to collapse.

[x] Sigged.


PointedEars
--

Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.

-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

[Evertjan.]

Mike Duffy wrote on 09 dec 2011 in comp.lang.javascript:

> "Evertjan." <exjxw.ha...@interxnl.net> wrote in
> news:Xns9FB665A...@194.109.133.133:
>
>> Trying to debug code that you do not understand is futile,
>
> It does force you to learn. But you do have a point. Sometimes, what
> you learn is wrong. If those wrong ideas are close to the root of the
> knowledge tree you build on a particular subject, pruning the bad
> branches can sometimes cause the whole tree to collapse.

That depends on what you mean by "what you learn".

I suggest that what you learn cannot be wrong,
as aquiring wrong ideas cannot be called "learning".

"Learning" is the dynamic and interactive process of aquiring knowledge and
skills by hearing, discussing and finding out new ideas, and adapting those
ideas to the results of those discussions, logical thinking and testing.

For such learning one needs to have a firm believe in the final doubt of
the scientific process.

Clientside javascript is just like the real world:
- there is no trustable manual.
- the inner workings are not always the same but depend on partly unknown
factors like place [which engine/browser?] and time [what version, what
DOM/OS].

[Mike Duffy]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote in
news:1348416.W...@PointedEars.de:

> [x] Sigged.

Danke, Herr Lahn.

--
http://pages.videotron.ca/duffym/index.htm

[Thomas 'PointedEars' Lahn]

Mike Duffy wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> wrote in
> news:1348416.W...@PointedEars.de:
>
>> [x] Sigged.
>
> Danke, Herr Lahn.

It is customary in Usenet to use the informal "you", the equivalent of which
is "Du" in German, not "Sie" or "Herr" (mister), unless impoliteness has
been detected. This differs from common German usage, of course.

Unfortunately, your From header value does not comply with RFC 5536, so I
have to write this publicly, and the sig is going to be the only text I will
see from you from now on.


F'up2 poster

[Gene Wirchenko]

On Fri, 09 Dec 2011 06:44:55 -0500, Norman Peelman
<npeel...@cfl.rr.com> wrote:

[snip]

> Are you saying that you don't even get the "page has completed but
>with errors" message at the bottom of the browser window, which when
>clicked on brings up a small pop-up window with an error message?

That is right. I have since solved my problem though.

[snip]

Sincerely,

Gene Wirchenko

.

[Dr J R Stockton]

In comp.lang.javascript message <3u42e7d2uq84hj3hnqjs2o774lk0dh1mt2@4ax.
com>, Thu, 8 Dec 2011 11:49:04, Gene Wirchenko <ge...@ocis.net> posted:

> I am not getting error messages. I simply get no page display.
>This makes tracking down errors considerably more difficult and
>time-consuming.

The biggest mistake made by beginners, and you are manifestly a beginner
here, whatever else you may have done before, is to change too much
between tests.

If, between two tests, you only change one line of code (keeping the old
line as comment), then, when it no longer does what you expect, the
fault must have something to do with the difference between the two
lines.

Another general trick, in a language where undeclared variables are
permissible, is to write "banana" just after the new part (assuming that
you are not programming vegetably). You know then that you should be
getting an error message (unless you have written an infinite loop);
and, if it is banana, at least your code above had a measure of
acceptability. That also serves to prevent subsequent code interfering
with any visible evidence that there may be.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.

.

[Gene Wirchenko]

On 09 Dec 2011 08:59:36 GMT, "Evertjan."

<exjxw.ha...@interxnl.net> wrote:

>Gene Wirchenko wrote on 09 dec 2011 in comp.lang.javascript:
>
>> [snip]
>>
>>>> Sometimes,
>>>> this causes problems though less than right after typing the code
>>>> in.
>>>
>>>Why would that cause problems [stipulating that you understand the

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>code?
^^^^

>> Oh, come on! Typos, and of course,
>
>Modular programming even on the minute scale of common browser
>javascript prograsmes, will prevent that.
>
>function tempModule(arguments) {
> alert(arguments);
> return tempReturnValues; // replace with absolute test-value;
>};
>
>If this works, then replace the fmodule with it's dynamic equivlent.
>
>
>> if I am experimenting with features, your stipulation is silly:
>
>This is not a stipulation, it is an advice from years of experience.

*You* used the word "stipulating" above.

>> it is not a safe bet that I understand the code totally.
>
>It should not be a "safe bet", it should be your effort.
>your code cann't be sound, if you don' understand it,
>and an added bonus is that you learn from this added understanding.

Perhaps, you have missed the point. I am learning JavaScript.
Note the word "learning". That means that I do not know as much about
it as I would like. I have been entering code from a text and working
with it. If I already understand the code, there is little or no
point to entering it. If I do not, then there is from the opportunity
to learn.

Having entered some code, it might not work due to:

1) bugs: I have found more than one bug in the code. I am an
experienced P/A, just not in JavaScript yet.

2) language/browser/other changes since the text was published: The
copyright is 1999, but it is the best text that I have found so far as
to level of detail, and despite its minor errors, it has not flipped
the bozo bit.

3) my typos: These can be nasty.

>Trying to debug code that you do not understand is futile,
>because it is error-prone. Just testing a ununderstood code can never
>reach the level of stability that you usually would expect of your
>programming and that can be reached by understood and debugged code.

It is hardly futile. I do get it debugged, and at this point, I
also learn more about the language. Among other things, knowing
language failure patterns is useful in debugging.

>Total understanding is easuier if you understand your modular modules
>and the compilation of those modules in your total design.

Sure.

>Experimenting with say! new DOM-features in a large code without first
>having tested and understood that feature on a small scale on a simple
>test-page seems inadvisable.

How fatuous! That is exactly what I am doing. However, I am at
the point where some of these exercises are not short bits of code.
Some of them depend on the interaction of many bits. Besides, it is
not enough to be able to handle small bits of code; I need to be able
to handle larger aggregations of code.

Sincerely,

Gene Wirchenko

.

[Evertjan.]

Gene Wirchenko wrote on 09 dec 2011 in comp.lang.javascript:

> On 09 Dec 2011 08:59:36 GMT, "Evertjan."
>

>>Gene Wirchenko wrote on 09 dec 2011 in comp.lang.javascript:
>>
>>> [snip]
>>>
>>>>> Sometimes,
>>>>> this causes problems though less than right after typing the code
>>>>> in.
>>>>
>>>>Why would that cause problems [stipulating that you understand the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>code?
> ^^^^
>
>>> Oh, come on! Typos, and of course,
>>
>>Modular programming even on the minute scale of common browser
>>javascript prograsmes, will prevent that.
>>
>>function tempModule(arguments) {
>> alert(arguments);
>> return tempReturnValues; // replace with absolute test-value;
>>};
>>
>>If this works, then replace the fmodule with it's dynamic equivlent.
>>
>>
>>> if I am experimenting with features, your stipulation is silly:
>>
>>This is not a stipulation, it is an advice from years of experience.
>
> *You* used the word "stipulating" above.

Quite, but not in the sense in can be called silly, as my stipulation is
just an hypothetical inference to state my hypothesis, not a statement of
fact.

>>> it is not a safe bet that I understand the code totally.
>>
>>It should not be a "safe bet", it should be your effort.
>>your code cann't be sound, if you don' understand it,
>>and an added bonus is that you learn from this added understanding.
>
> Perhaps, you have missed the point. I am learning JavaScript.
> Note the word "learning". That means that I do not know as much about
> it as I would like.

This goes for most of us. We all learn. As said I reserve the word learn
for aquiring the right knowledge and/or skill.

By "understanding your code" I mean that you understand what it *should*
do, terribly absent when copying a [voluminous] script code from the web
or book.

> I have been entering code from a text

Script code just being text,
and javascript being a scripting language??

Oh, you must mean a printed page?

> and working
> with it. If I already understand the code, there is little or no
> point to entering it. If I do not, then there is from the opportunity
> to learn.

So you are trying out script code where both [1] you you do know what it
should do and [2] needs to be debugged, because it is not a correctly
working code?

> Having entered some code, it might not work due to:
>
> 1) bugs: I have found more than one bug in the code. I am an
> experienced P/A, just not in JavaScript yet.

As I surmized.

> 2) language/browser/other changes since the text was published: The
> copyright is 1999, but it is the best text that I have found so far as
> to level of detail, and despite its minor errors, it has not flipped
> the bozo bit.

Are you sure you want to learn from code from last century?

> 3) my typos: These can be nasty.

So you don't copy from the web but from a last century book, it seems.

Sinse most present day javascript books are not of high quality, and last
century's ones are even worse, the best you can learn from them is sound
debugging.

And that is what I started to explain in this thread, how to do simple
debugging by inserting breakpoints and remarking out code lines.

>>Trying to debug code that you do not understand is futile,
>>because it is error-prone. Just testing a ununderstood code can never
>>reach the level of stability that you usually would expect of your
>>programming and that can be reached by understood and debugged code.
>
> It is hardly futile. I do get it debugged, and at this point, I
> also learn more about the language. Among other things, knowing
> language failure patterns is useful in debugging.
>
>>Total understanding is easuier if you understand your modular modules
>>and the compilation of those modules in your total design.
>
> Sure.
>
>>Experimenting with say! new DOM-features in a large code without first
>>having tested and understood that feature on a small scale on a simple
>>test-page seems inadvisable.
>
> How fatuous! That is exactly what I am doing. However, I am at
> the point where some of these exercises are not short bits of code.
> Some of them depend on the interaction of many bits. Besides, it is
> not enough to be able to handle small bits of code; I need to be able
> to handle larger aggregations of code.

At this point you should try modular programming, very feasable in
javascript, and making the testing and understanding of your programme
possible.

Declare the input to output and the interface effects of each module and
make and test that module for all values within the required range. When
satisfied treat that module as a black box and use your modules to
compile a module of the next higher level of modularity.

Is this 1999 code up to this level of loguic or is it just a Gordian knot
of interloping parts of all too linear programing?

[J.R.]

On 07/12/2011 00:32, Gene Wirchenko wrote:
> Dear JavaScripters:
>
> At the best of time, I have found debugging JavaScript code to be

> such a bother. I have been using IE's F12, but it does not handle (or

> I have not figured out how) debugging an included file (<script

> src=...). (If you know how, would you please let me know?) As a

> consequence, I did not get immediate feedback on my silly error and
> wasted a couple of hours.

Of course, you haven't figured it out. Check this out:
<http://msdn.microsoft.com/en-us/library/gg699336(v=vs.85).aspx>

MSDN has loads of information concerning the F12 Developer Tools:
<http://msdn.microsoft.com/en-us/library/gg589500(v=vs.85).aspx>

Cheers,
Joao Rodrigues (J.R.)

>
> You see, I have done a lot of programming in Visual FoxPro. Its
> line comment token is "&&". Somehow, I typed that, instead of "//",
> and I did not see it as an error for some time.
>

> Go ahead and laugh, but it could be you next time.

[Dr J R Stockton]

In comp.lang.javascript message <lmo2e757mar0dn9vgb1osnhmh98fl5lj14@4ax.
com>, Thu, 8 Dec 2011 17:24:58, Gene Wirchenko <ge...@ocis.net> posted:

>On Thu, 8 Dec 2011 19:40:43 +0000, Dr J R Stockton
><repl...@merlyn.demon.co.uk> wrote:
>
>>In comp.lang.javascript message <nojtd7pb39ofku9j7a1bi6pog635kga2ua@4ax.
>>com>, Tue, 6 Dec 2011 18:32:58, Gene Wirchenko <ge...@ocis.net> posted:
>>
>>> At the best of time, I have found debugging JavaScript code to be
>>>such a bother. I have been using IE's F12, but it does not handle (or
>>>I have not figured out how) debugging an included file (<script
>>>src=...). (If you know how, would you please let me know?) As a
>>>consequence, I did not get immediate feedback on my silly error and
>>>wasted a couple of hours.
>>
>>But we here are smarter, and so use other browsers.
>
> I prefer Firefox myself, but company standard is IE.

That suggests that you have access to Firefox. If the company allows
you to install Firefox at work, do so, and use it as a debugger.
Otherwise, install Firefox at home, and practice there until you can
write code that has a chance of running in IE.

>>Note that the reported market share for other browsers is now
>>considerably greater than that for IE.
>
> IE still has a considerable plurality, not that that makes a
>difference to me. The company standard is IE.

Perhaps you should have chosen a wiser company.

>>Of course, once the author's sillies have been dealt with by using other
>>browsers, one should use IE and try to deal with its sillies.
>
> I will be developing a complex system in IE. I need to learn it
>inside out.

If your coding is for an intranet, or otherwise not exposed to the Great
World Outside, then it would be well to say so, in each new thread at
least. Otherwise, that is a ludicrous, if common, policy, worthy of the
more obstinate governments of lower latitudes.

>>For code not reliant on a GUI and I/O, it may well be worth testing in
>>JScript under WSH. That at least gives a clear indication, in your
>>choice of font size, of where it thinks the error is or becomes
>>detectable.

Then you will need to distinguish between its peculiar ideas, which you
will have to live with until IE 10 (when they will change) and your own
inaccurate ideas, which can be corrected when discovered.

> ??? How would a Webpage not be reliant on I/O?

I wrote "code", not "webpage". It is quite possible to have chunks of
code which manipulate data, without storing them. A simple but
unrealistic illustration would be if you had to sort, into chronological
order, a set of strings each starting with a date/time formatted as in
Sat Dec 10 2034 09:46:05 a.m.
(which is the sort of thing that Middle North Americans like), and it
had to be done without using the Date Object.

That task requires no I/O, and temporary debugging I/O can use
WScript.echo.

--
(c) John Stockton, nr London UK ?@merlyn.demon.co.uk IE8 FF8 Op11 Sf5 Cr15
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.