IE Error "Stop Running This Script"

[Sunny]

Hi,

Sometime, when your script is too big,
IE Gives you a warning "Stop Running This Script"
A script on this page is causing Internet Explorer to run slowly.

Does anyone knows, How to correct that?

Thanks.

 

[David Mark]

Sometime, when your script is too big,
IE Gives you a warning "Stop Running This Script"
A script on this page is causing Internet Explorer to run slowly.

Does anyone knows, How to correct that?

This is not IE-specific, it happens in all browsers. If a script is
running non-stop for some time, for example because of an endless loop,
(modern) browsers offer you a chance to interrupt it.

If your script really has to work for a very long time, you could split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

Eval is evil.

 

[Thomas 'PointedEars' Lahn]

[...]
If your script really has to work for a very long time, you could split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

Eval is evil.

There is some truth in this, but what does it have to do with what you quoted?


PointedEars

 

[David Mark]

[...]
If your script really has to work for a very long time, you could split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

You don't see that?

 

[Thomas 'PointedEars' Lahn]

[...]
If your script really has to work for a very long time, you could split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

You don't see that?

See what?


PointedEars

 

[David Mark]

David Mark wrote:
[...]
If your script really has to work for a very long time, you could split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

You don't see that?

See what?

I guess you can't then (or you are being deliberately obtuse.)

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
If your script really has to work for a very long time, you could split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n
You don't see that?

See what?

I guess you can't then (or you are being deliberately obtuse.)

Or maybe you're imagining things plus you can't quote properly.
There are just so many possibilities ...


PointedEars

 

[Rik Wasmus]

David Mark wrote:
[...]
If your script really has to work for a very long time, you could
split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations
with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

[unquoted]
David: Eval is Evil
Thomas: What has that got to do with it?
[/unquote]

See what?

Aside from the fact he should indeed have quoted the posts in between:

'setTimeout("continueCalculations()",deal-in-ms)'

vs.

'setTimeout(continueCalculations,deal-in-ms)'

 

[David Mark]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
If your script really has to work for a very long time, you could  
split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations  
with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

[unquoted]
David: Eval is Evil
Thomas: What has that got to do with it?
[/unquote]

See what?

Aside from the fact he should indeed have quoted the posts in between:

'setTimeout("continueCalculations()",deal-in-ms)'

vs.

'setTimeout(continueCalculations,deal-in-ms)'

Thank you Rik. And yes, as Thomas was sure to point out, I mis-quoted
one of the responses. And he knew what I was talking about all
along. Somebody is having a bad day.

 

[Dr J R Stockton]

In comp.lang.javascript message <opadnezbeb83YWHVnZ2dnUVZ8umdnZ2d@supern

This is not IE-specific, it happens in all browsers. If a script is
running non-stop for some time, for example because of an endless loop,
(modern) browsers offer you a chance to interrupt it.

In most applications, ISTM that running for long will be due to a bug,
and the usual pop-up continue/stop is therefore appropriate. But it
would probably be better if the code were to continue running
underneath, and it would also be well if one could choose to continue
longer before the next warning, or continue indefinitely. I often need,
in testing an algorithm, to loop more than 5,700,000 times.

I'd like a FAQ entry on control of this feature. though I suspect that
it's not commonly enough of interest. Browsers vary.

You and the OP seem to have omitted to mention 'eval', which makes David
Mark's follow-up appear somewhat inexplicable.

 

[Thomas 'PointedEars' Lahn]

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
If your script really has to work for a very long time, you could
split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations
with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n

[unquoted]
David: Eval is Evil
Thomas: What has that got to do with it?
[/unquote]

You don't see that?
See what?

Aside from the fact he should indeed have quoted the posts in between:

'setTimeout("continueCalculations()",deal-in-ms)'

vs.

'setTimeout(continueCalculations,deal-in-ms)'

Thank you Rik. And yes, as Thomas was sure to point out, I mis-quoted
one of the responses. And he knew what I was talking about all
along.

No, you don't. eval() does not even enter into it.

Somebody is having a bad day.

Apparently, and it wasn't me.

Now that the point you tried to make can be clearly seen (why did you not
simply say so in the first place? Why all the pointless evading?), it can
be pointed out as clearly that you are utterly mistaken if you think that
the latter has an intrinsic benefit over the former here. In fact, strictly
speaking, the string value is even more compatible than the Function
reference as the first argument.


HTH

PointedEars

 

[Thomas 'PointedEars' Lahn]

setTimeout("continueCalculations()", delay-in-ms) to do
You don't see that?
See what?
I guess you can't then (or you are being deliberately obtuse.)

Or maybe you're imagining things [..]

I suppose Mark was referring to '"continueCalculations()"' vs
'continueCalculations', and he's correct, after a fashion.

It was an inept attempt at tetrapilotomy, nothing more.

What I wrote was just an example, but even so I should have used a
function reference instead of a string.
Nonsense.

I thought the string would be easier to understand in this particular
case. So, it's my fault - can we settle this now?

Not before it was emphasized that you did not make a mistake at all.


PointedEars

 

[Andrew Poulos]

It was an inept attempt at tetrapilotomy, nothing more.

Its spelt "tetrapylotomy"

Andrew Poulos

 

[David Mark]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
If your script really has to work for a very long time, you could 
split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations  
with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n
[unquoted]
David: Eval is Evil
Thomas: What has that got to do with it?
[/unquote]
You don't see that?
See what?
Aside from the fact he should indeed have quoted the posts in between:
'setTimeout("continueCalculations()",deal-in-ms)'
vs.
'setTimeout(continueCalculations,deal-in-ms)'

Thank you Rik.  And yes, as Thomas was sure to point out, I mis-quoted
one of the responses.  And he knew what I was talking about all
along.

No, you don't.  eval() does not even enter into it.

I don't what? And what do you think happens to that string?

[snip]

speaking, the string value is even more compatible than the Function
reference as the first argument.

Gee, no kidding? More compatible? Perhaps your memory is not what it
used to be, if you feel the need to enlighten me about such things.

Regardless, it is stupid to use it unless you need to support some
truly ancient browsers. I myself use it in gateway code, but nowhere
else.

And quite frankly, I'll point out what I like. Whether you consider
it a mistake or not is irrelevant (as always.)

 

[Jorge]

:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
If your script really has to work for a very long time, you could  
split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations  
with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n
[unquoted]
David: Eval is Evil
Thomas: What has that got to do with it?
[/unquote]
You don't see that?
See what?
Aside from the fact he should indeed have quoted the posts in between:
'setTimeout("continueCalculations()",deal-in-ms)'
vs.
'setTimeout(continueCalculations,deal-in-ms)'
Thank you Rik.  And yes, as Thomas was sure to point out, I mis-quoted
one of the responses.  And he knew what I was talking about all
along.

No, you don't.  eval() does not even enter into it.

I don't what?  And what do you think happens to that string?

It takes as much as 10x longer to call "f()" than to call f in
FF3+FireBug:

http://jorgechamorro.com/cljs/022/

But in most modern browsers and in nowadays computers the difference
is negligible (even though it takes 1.5...3x longer) as we're talking
about tens of µs (not milliseconds).

OTOH, unlike setTimeout(f, n), ISTM that a problem with the
setTimeout("f()", n) form is that "f()" is going to be evaluated in a
different context than the one in which you set the timeout.

 

[Thomas 'PointedEars' Lahn]

Its spelt "tetrapylotomy"

^ ^
I don't think so


F'up2 poster

PointedEars

 

[John W Kennedy]

^ ^
I don't think so

Well, actually, it's "tetrathrixotomy", but no one listen to poor
Zathrates.

--
John W. Kennedy
"When a man contemplates forcing his own convictions down another
man's throat, he is contemplating both an unchristian act and an act of
treason to the United States."
-- Joy Davidman, "Smoke on the Mountain"

 

[Thomas 'PointedEars' Lahn]

:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
On Oct 20, 5:48 pm, Conrad Lender <[email protected]>
wrote:
[...] If your script really has to work for a very long
time, you could split up execution into smaller parts.
For example, if you're doing protein folding
calculations, or raytracing, or meteorological
simulations with javascript in a browser[0], you could
run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do
the next $n
[unquoted] David: Eval is Evil Thomas: What has that got to do with
it? [/unquote]
You don't see that?
See what?
Aside from the fact he should indeed have quoted the posts in
between: 'setTimeout("continueCalculations()",deal-in-ms)' vs.
'setTimeout(continueCalculations,deal-in-ms)'
Thank you Rik. And yes, as Thomas was sure to point out, I
mis-quoted one of the responses. And he knew what I was talking
about all along.

No, you don't. eval() does not even enter into it.

I don't what? And what do you think happens to that string?

It certainly does not get passed to eval(). In any case, the performance
gain hat could be expected from not using a string value is negligibly small.

Gee, no kidding? More compatible?

Yes, *strictly speaking*. You started splitting hairs here, remember?

Perhaps your memory is not what it used to be, if you feel the need to
enlighten me about such things.

Perhaps you are on a very bad trip. Who knows ...

Regardless, it is stupid to use it unless you need to support some truly
ancient browsers. I myself use it in gateway code, but nowhere else.

You might be correct there. I thought that IE 5.01, which comes with the
default Windows 2000 setup, was not capable of handling Function object
references there, but apparently (tested with standalone IE 5.01 on Windows
XP SP3) it is.

And quite frankly, I'll point out what I like.

As do I.

Whether you consider it a mistake or not is irrelevant (as always.)

It is not irrelevant if a statement is misleading others into believing that
they made a *mistake* when it is objectively _not_ so, as it happened here.


PointedEars

 

[Thomas 'PointedEars' Lahn]

David Mark wrote:
:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
If your script really has to work for a very long time, you could
split
up execution into smaller parts. For example, if you're doing protein
folding calculations, or raytracing, or meteorological simulations
with
javascript in a browser[0], you could run $n iterations, then call
setTimeout("continueCalculations()", delay-in-ms) to do the next $n
[unquoted]
David: Eval is Evil
Thomas: What has that got to do with it?
[/unquote]
You don't see that?
See what?
Aside from the fact he should indeed have quoted the posts in between:
'setTimeout("continueCalculations()",deal-in-ms)'
vs.
'setTimeout(continueCalculations,deal-in-ms)'
Thank you Rik. And yes, as Thomas was sure to point out, I mis-quoted
one of the responses. And he knew what I was talking about all
along.
No, you don't. eval() does not even enter into it.

I don't what? And what do you think happens to that string?

It takes as much as 10x longer to call "f()" than to call f in
FF3+FireBug:

http://jorgechamorro.com/cljs/022/

Your test case is bogus as timeouts may accumulate if you use 0 as the
second argument (which is normalized to 10 on 32-bit CPUs).

But in most modern browsers and in nowadays computers the difference
is negligible
Exactly.

(even though it takes 1.5...3x longer) as we're talking about tens of
µs (not milliseconds).

You cannot know that, the timer resolution is just not fine enough.

OTOH, unlike setTimeout(f, n), ISTM that a problem with the
setTimeout("f()", n) form is that "f()" is going to be evaluated in a
different context than the one in which you set the timeout.

It isn't.


PointedEars

 

[sasuke]

OTOH, unlike setTimeout(f, n), ISTM that a problem with the
setTimeout("f()", n) form is that "f()" is going to be evaluated in a
different context than the one in which you set the timeout.

More specifically, always in the context of the global window object.

----------------------------------
<script type="text/javascript">
function b() {
alert("inside b()");
}

window.onload = function() {
function a() {
alert("inside a() of onload");
}
setTimeout("b()", 100); // works
setTimeout("a()", 100); // a() not defined
}
</script>