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.

[Conrad Lender]

On 2008-10-20 20:19, Sunny wrote:

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
iterations. Repeat and rinse.

([0] There are actually at least two raytracing implementations in
javascript. People are really going crazy these days. Not sure about the
protein folding, but I wouldn't be surprised.)
- Conrad

[David Mark]

On Oct 20, 5:48*pm, Conrad Lender <[e-mail]:

On 2008-10-20 20:19, Sunny wrote:

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]

David Mark wrote:

On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:

>[...]
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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[David Mark]

On Oct 22, 2:57*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:

[...]
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]

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

>David Mark wrote:

>>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
[...]
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
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[David Mark]

On Oct 22, 4:22*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

David Mark wrote:
On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
[...]
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]

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

>David Mark wrote:

>>Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
>[...]
>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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>

[Rik Wasmus]

On Wed, 22 Oct 2008 22:22:35 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.dewrote:

David Mark wrote:

>Thomas 'PointedEars' Lahn wrote:

>>David Mark wrote:
On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
[...]
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)'
--
Rik

[Conrad Lender]

On 2008-10-22 23:24, Thomas 'PointedEars' Lahn wrote:

>>>>>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]>
>wrote:
>>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. What I wrote
was just an example, but even so I should have used a function reference
instead of a string. I thought the string would be easier to understand
in this particular case. So, it's my fault - can we settle this now?
- Conrad

[David Mark]

On Oct 22, 7:41*pm, "Rik Wasmus" <[e-mail]:

On Wed, 22 Oct 2008 22:22:35 +0200, Thomas 'PointedEars' Lahn

<[e-mail]:

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
[...]
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. Somebody is having a bad day.

[Dr J R Stockton]

In comp.lang.javascript message <opadnezbeb83YWHVnZ2dnUVZ8umdnZ2d@supern
ews.com>, Mon, 20 Oct 2008 23:48:29, Conrad Lender <cr******@yahoo.com>
posted:

>On 2008-10-20 20:19, Sunny wrote:

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

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.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE7 FF2 Op9 Sf3
news:comp.lang.javascript FAQ <URL:http://www.jibbering.com/faq/index.html>.
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[Thomas 'PointedEars' Lahn]

David Mark wrote:

"Rik Wasmus" wrote:

>Thomas 'PointedEars' Lahn wrote:

>>David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
>>[...]
>>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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

[Thomas 'PointedEars' Lahn]

Conrad Lender wrote:

On 2008-10-22 23:24, Thomas 'PointedEars' Lahn wrote:

>>>>>>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
>>>
>>>
>>>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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Andrew Poulos]

Thomas 'PointedEars' Lahn wrote:

It was an inept attempt at tetrapilotomy, nothing more.

Its spelt "tetrapylotomy" :-)

Andrew Poulos

[David Mark]

On Oct 23, 3:05*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

"Rik Wasmus" wrote:

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
>[...]
>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]

On Oct 24, 1:35*am, David Mark <[e-mail]:

On Oct 23, 3:05*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

"Rik Wasmus" wrote:
>Thomas 'PointedEars' Lahn wrote:
>>David Mark wrote:
>>>Thomas 'PointedEars' Lahn wrote:
>>>>David Mark wrote:
>>>>>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
>>>>>>[...]
>>>>>>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.

--
Jorge.

--
Jorge.

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

Thomas 'PointedEars' Lahn wrote:

>It was an inept attempt at tetrapilotomy, nothing more.

Its spelt "tetrapylotomy" :-)

^ ^
I don't think so :)
F'up2 poster

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[John W Kennedy]

Thomas 'PointedEars' Lahn wrote:

Andrew Poulos wrote:

>Thomas 'PointedEars' Lahn wrote:

>>It was an inept attempt at tetrapilotomy, nothing more.

Its spelt "tetrapylotomy" :-)

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

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

>David Mark wrote:

>>"Rik Wasmus" wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
>Thomas 'PointedEars' Lahn wrote:
>>David Mark wrote:
>>>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]>
>>>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.

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

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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Jorge wrote:

David Mark wrote:

>Thomas 'PointedEars' Lahn wrote:

>>David Mark wrote:
"Rik Wasmus" wrote:
Thomas 'PointedEars' Lahn wrote:
>David Mark wrote:
>>Thomas 'PointedEars' Lahn wrote:
>>>David Mark wrote:
>>>>On Oct 20, 5:48 pm, Conrad Lender <[e-mail]:
>>>>>[...]
>>>>>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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[sasuke]

On Oct 24, 7:08*am, Jorge <[e-mail]:

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

/sasuke

[Thomas 'PointedEars' Lahn]

sasuke wrote:

Jorge wrote:

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

s/global//

However, that is _not_ different with a Function object reference. What is
different is that the Function object reference as an argument *may* refer
to another object than the same identifier in a string literal.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Andrew Poulos]

Thomas 'PointedEars' Lahn wrote:

Andrew Poulos wrote:

>Thomas 'PointedEars' Lahn wrote:

>>It was an inept attempt at tetrapilotomy, nothing more.

Its spelt "tetrapylotomy" :-)

^ ^
I don't think so :)

You're right I should've written "tetrapyloctomy".
<url: http://www.answers.com/topic/tetrapyloctomy >
Unless you mean some other word.

Andrew Poulos

[sasuke]

On Oct 25, 12:01*am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

sasuke wrote:

Jorge wrote:

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.

s/global//

However, that is _not_ different with a Function object reference.

It seems to be different with the Function Object reference given that
the reference is resolved in current context rather than the global
context.

------------------------------------------------
<script type="text/javascript">
function b() {
alert("inside b() of the global context");
}
window.onload = function() {
function b() {
alert("Inside b() of onload");
}
function a() {
alert("inside a() of onload");
}
setTimeout("b()", 2000);
setTimeout(b, 1000);
}
</script>
------------------------------------------------

/sasuke

[Thomas 'PointedEars' Lahn]

sasuke wrote:

Thomas 'PointedEars' Lahn wrote:

>sasuke wrote:

>>Jorge wrote:
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.

s/global//

However, that is _not_ different with a Function object reference.

It seems to be different with the Function Object reference given that
the reference is resolved in current context rather than the global
context.

Read again.

[example]

No, thanks.
PointedEars

[Jorge]

On Oct 24, 9:01*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

sasuke wrote:

Jorge wrote:

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.

s/global//

However, that is _not_ different with a Function object reference. *What is
different is that the Function object reference as an argument *may* refer
to another object than the same identifier in a string literal.

And that it may have access to a closure.

--
Jorge.

[Jorge]

On Oct 24, 7:47*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Jorge wrote:

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:
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).

It's not that "timeouts may accumulate" it's that they are accumulated
purposedly and are being called in a row one after the other "on the
same ms slot". Perhaps you don't understand the way it works ?

Perhaps your cpu "normalizes 0 to 10 ms" and you got the funny idea
that others do as well ?

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.

WOW ! How come ? Of course I can. If 1404000 calls happen in a minute
a child can tell you that there are 23.4 calls per millisecond... and
that a call takes 42.735 µs... all that with just a *minutes* counter.

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.

It is.

--
Jorge.

[Jorge]

On Oct 25, 7:25*pm, Dr J R Stockton <[e-mail]:

>
Perhaps some test code should be developed and announced here.

http://jorgechamorro.com/cljs/023/

(2nd attempt to post it, GoogleGroups is hanged for 2 days now, ISTM)
--
Jorge.

[Jorge]

On Oct 26, 11:02*am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>

Right. And must be an OS choice as well: (it's all green in my Mac
with "A" browsers) :

http://jorgechamorro.com/cljs/023/

This proves nothing.

ROTFL

--
Jorge.

[Jorge]

On Oct 26, 12:31 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <[e-mail]:

(...)

Specifically, in Windows NT a browser needs to make a special Timer API call
to lower the default timer resolution of 10 ms to 1 to 9 ms; there is little
reason why it should do that, given the latency of DOM operations.

<http://technet.microsoft.com/en-us/sysinternals/bb897569.aspx>

Perhaps. It might also increase the precission of Date objects, if you
want to perform fine-grained timing.

ACK. No such high precision has been observed to date, though.

In a Mac: any browser: Date() resolution: 1ms

Measure Date() resolution: http://jorgechamorro.com/cljs/024/

>but, e.g., Google Chrome currently doesn't.
Gecko-based UAs do, as I have showed before.

[...] as do IE,

How can you know that? The normalization *may* be performed by the UA, but
it may also be performed by the OS or the CPU.

The chip makers put right into the hardware an "if (JavaScript timer)
then { cheat() }" ?
M$ puts right into the OS an "if (JavaScript timer && !(Chrome | FF3))
then { cheat() }" ?

LOL.

and probably also Safari on Windows.
Google Chrome is merely an example that there is a browser running on
a 32-bit CPU that doensn't normalize a delay of 0 to 10 ms (i.e., your
original statment was too broad a generalization). Whether it will
stop doing that in the future, or other browser will start doing it,
is impossible to tell.

--
Jorge.

[Dr J R Stockton]

In comp.lang.javascript message <f8e8b37e-1f72-4e2e-85a1-8d68da1f377f@k1
6g2000hsf.googlegroups.com>, Mon, 27 Oct 2008 14:13:21, Jorge
<jo***@jorgechamorro.composted:

>On Oct 25, 7:25*pm, Dr J R Stockton <[e-mail]:

>>
Perhaps some test code should be developed and announced here.

http://jorgechamorro.com/cljs/023/

(2nd attempt to post it, GoogleGroups is hanged for 2 days now, ISTM)

With somewhat more text, that could be a useful FAQ Note. In the list,
how about a blank line marking the steps in "executed at"? One could do
a best-fit straight line to express "step position" in terms of "step
number"; assuming the fit is always good, the slope would indicate the
timer resolution and the intercept maybe something about the overhead.
Those figures could be collected for different systems; I get a slope of
about 16 ms, as expected (Win XP sp3 IE7), with red/blue/green boxes.
For Chrome 0.2 (Win XP sp3) all boxes are green and there is thus no
list.

My js-dates.htm has a part which could be a contribution : it reports
the resolution and update interval, without using timeOut.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)

[Dr J R Stockton]

In comp.lang.javascript message <a9b48027-1259-456e-8f09-e0c21c38a82e@k7
g2000hsd.googlegroups.com>, Tue, 28 Oct 2008 01:51:29, Jorge
<jo***@jorgechamorro.composted:

>
Measure Date() resolution: http://jorgechamorro.com/cljs/024/

Forty loops, instead of 500, would be enough ! The core of that is like
that in my js-dates.htm.

Consider count[t] = (count[t] || 0 ) + 1 though there may be
something still better.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

[Jorge]

On Oct 28, 8:11*pm, Dr J R Stockton <[e-mail]:

In comp.lang.javascript message <a9b48027-1259-456e-8f09-e0c21c38a82e@k7
g2000hsd.googlegroups.com>, Tue, 28 Oct 2008 01:51:29, Jorge
<[e-mail]:

Measure Date() resolution:http://jorgechamorro.com/cljs/024/

Forty loops, instead of 500, would be enough ! *The core of that is like
that in my js-dates.htm.

Yep. I've lowered it to 100. Now it also tells how many samples are
being taken per ms: note Chrome's excellent 8k samples / ms !

So, the Date() resolution bussiness seems to be right now:

All Macs, all browsers: 1ms.

Win XP: Chrome, FF3, Safari: 1ms. IE, Opera, FF2 : 10ms.

Consider * * *count[t] = (count[t] || 0 ) + 1 * * *though there may be
something still better.

Thanks. Beautiful code is always welcomed: t0+= (count[n] || 0) *
n; :-)

--
Jorge.