IE Error "Stop Running This Script"

[Thomas 'PointedEars' Lahn]

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

 

[Andrew Poulos]

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

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>

 

[Thomas 'PointedEars' Lahn]

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]

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]

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 ?

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.

It isn't.

It is.

 

[Lasse Reichstein Nielsen]

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

That's a browser choice, not a CPU requirement. Most browsers put a lower
limit on the delay of setTimeout in order to prevent the page from hogging
the CPU, but, e.g., Google Chrome currently doesn't.

/L

 

[Dr J R Stockton]

That's a browser choice, not a CPU requirement. Most browsers put a lower
limit on the delay of setTimeout in order to prevent the page from hogging
the CPU, but, e.g., Google Chrome currently doesn't.

That **may** be **slightly** misleading.

The clock resolution is often 10ms. The effect of providing a small-
value second argument will depend on the exact way in which the number
is used. In the apparent absence (judging by <https://developer.mozilla
..org/en/DOM/window.setTimeout>) of a very clear definition of exactly
how a delay parameter of X ms should be used in a system where the timer
resolution is Y ms, and in the presence of variations in exactly what
the scheduling calls of various OSs actually do, ISTM that there's scope
for a considerable degree of variation of behaviour even without deep
insight, incompetence, or malice.

The limit may exist, or not exist, in a system without anything as
positive as is suggested by "put" or "not put" having occurred.

Perhaps some test code should be developed and announced here.

 

[Jorge]

That's a browser choice, not a CPU requirement. Most browsers put a lower
limit on the delay of setTimeout in order to prevent the page from hogging
the CPU, but, e.g., Google Chrome currently doesn't.

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

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

 

[Thomas 'PointedEars' Lahn]

That's a browser choice, not a CPU requirement. Most browsers put a lower
limit on the delay of setTimeout in order to prevent the page from hogging
the CPU,

How can you know that, given that "most browsers" are Closed Source?
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.

but, e.g., Google Chrome currently doesn't.

Gecko-based UAs do, as I have showed before.


PointedEars

 

[Thomas 'PointedEars' Lahn]

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.

Which "Mac" do you have? Which Mac OS version do you use?


PointedEars

 

[Lasse Reichstein Nielsen]

How can you know that, given that "most browsers" are Closed Source?

Ok, I don't know why they do it, but I have been given as explanation
for why in particular Mozilla does not use high precission timers, that
they don't want the page to be able to hog the processor by using very
low timeouts. For IE, it's more likely that they didn't bother doing
anything about the default.

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.

Gecko-based UAs do, as I have showed before.

I am aware of that, as do IE, 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.

/L

 

[Thomas 'PointedEars' Lahn]

Ok, I don't know why they do it, but I have been given as explanation
for why in particular Mozilla does not use high precission timers, that
they don't want the page to be able to hog the processor by using very
low timeouts.

That would seem to be a reasonable approach.

For IE, it's more likely that they didn't bother doing
anything about the default.

Arguing with unfounded likelihoods is a logical fallacy.

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.

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.

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.

So, since the least common denominator is normalization, it is safe to say
that the test case is bogus. I said that from the start, didn't I?


PointedEars

 

[Jorge]

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]

This proves nothing.

ROTFL

 

[Jorge]

(...)



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/

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

 

[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

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.

 

[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

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.

 

[Jorge]

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




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;