On 21/03/2011, at 00:21, Bradley Meck wrote:
It isn't in the past though, it is scheduled to be run as soon as
possible past a certain point. That being said `as soon as possible`
may not be in a particular order (os schedulers / threads / event
listeners in js for example). I view this close
On 20/03/2011, at 04:11, Brendan Eich wrote:
We need to be careful about order, though.
Of course, yes, please.
If setTimeout(f1, 1000) schedules f1 to be called at t1, and setTimeout(f2,
0) schedules f2 at t2, then if t2 = t1, f1 should be called first. I'm not
sure all browsers
Le 20/03/2011 04:11, Brendan Eich a écrit :
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich bren...@mozilla.com wrote:
setTimeout does not introduce threads, shared memory among them, or even
non-determinism if we spec carefully (browsers
On 20/03/2011, at 12:08, David Bruant wrote:
Le 20/03/2011 04:11, Brendan Eich a écrit :
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich bren...@mozilla.com wrote:
setTimeout does not introduce threads, shared memory among them, or even
On Sun, Mar 20, 2011 at 6:03 AM, Jorge jo...@jorgechamorro.com wrote:
will eventually fire g() before f() is nodejs:
https://github.com/joyent/node/pull/604
I've never seen that in any browser.
This sounds like a bug in Node's clamping algorithm.
Wes
--
Wesley W. Garland
Director,
On 20/03/2011, at 13:51, Jorge wrote:
On 20/03/2011, at 12:08, David Bruant wrote:
Le 20/03/2011 04:11, Brendan Eich a écrit :
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich bren...@mozilla.com wrote:
setTimeout does not introduce
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
On 20/03/2011, at 13:51, Jorge wrote:
On 20/03/2011, at 12:08, David Bruant wrote:
Le 20/03/2011 04:11, Brendan Eich a écrit :
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich
On 20/03/2011, at 14:00, Wes Garland wrote:
On Sun, Mar 20, 2011 at 6:03 AM, Jorge jo...@jorgechamorro.com wrote:
will eventually fire g() before f() is nodejs:
https://github.com/joyent/node/pull/604
I've never seen that in any browser.
This sounds like a bug in Node's clamping algorithm.
On 20/03/2011, at 15:18, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
A timer that expires is an event, and I would expect events to be serviced
in the order they happen. As when I click twice, I'd expect the first click
to be serviced before the second click.
So
when you're in strict mode and you do
setTimeout(alert(this), 0). Is this string interpreted as strict eval
code? There is a spec hole here. Bringing setTimeout to ECMAScript would
be an occasion to answer the question and not let implementors do
whatever they prefer or even to forget
Le 20/03/2011 16:04, Jorge a écrit :
On 20/03/2011, at 15:18, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
A timer that expires is an event, and I would expect events to be serviced
in the order they happen. As when I click twice, I'd expect the first
click to be
I don't see why you can't verify your expectation.
If you think you can verify your expectation, please write ECMAScript
interoperable test cases that show how to test whether an ECMAScript
engine is conform to your scheduling policy or not. It will be enough to
convince me.
Testing one timer
it within ECMAScript.
I suppose so.
It could be an occasion to
specify what happens when you're in strict mode and you do
setTimeout(alert(this), 0). Is this string interpreted as strict eval
code? There is a spec hole here. Bringing setTimeout to ECMAScript would
be an occasion to answer
Le 20/03/2011 16:56, David Herman a écrit :
This is giving me a (terrible) idea to implement setTimeout.
We could have two vats. One asks the second to resolve some promise
after a certain amout of time. The second loops and resolve the promise
when the delay is passed (measured as a delta
On Sun, Mar 20, 2011 at 9:17 AM, David Bruant david.bru...@labri.fr wrote:
Le 20/03/2011 16:56, David Herman a écrit :
This is giving me a (terrible) idea to implement setTimeout.
We could have two vats. One asks the second to resolve some promise
after a certain amout of time. The second
On 20/03/2011, at 16:57, David Bruant wrote:
Le 20/03/2011 16:04, Jorge a écrit :
On 20/03/2011, at 15:18, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
A timer that expires is an event, and I would expect events to be
serviced in the order they happen. As when I click
Le 20/03/2011 17:25, Jorge a écrit :
On 20/03/2011, at 16:57, David Bruant wrote:
Le 20/03/2011 16:04, Jorge a écrit :
On 20/03/2011, at 15:18, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
A timer that expires is an event, and I would expect events to be
serviced in
Le 20/03/2011 17:14, Kyle Simpson a écrit :
I don't see why you can't verify your expectation.
If you think you can verify your expectation, please write ECMAScript
interoperable test cases that show how to test whether an ECMAScript
engine is conform to your scheduling policy or not. It will
On 3/20/11 1:19 PM, David Bruant wrote:
I agree that some properties of a scheduling policy can be tested (like
you can test that times moves forward with two sequential calls to
Date.now() or testing statistical properties of Math.rand()) but there
is something in the time that code uses to
On Mar 20, 2011, at 7:18 AM, David Bruant wrote:
Le 20/03/2011 14:33, Jorge Chamorro a écrit :
On 20/03/2011, at 13:51, Jorge wrote:
So given 2 timers, expiring at t0 and t1 with t0 t1, if Date.now() is =
t0 and = t1, I would expect t0 to be serviced first, yes.
The difference is that
On 20/03/2011, at 18:11, David Bruant wrote:
Le 20/03/2011 17:25, Jorge a écrit :
In order to know *exactly* the target time (Date.now() +ms) that a given
setTimeout() has been scheduled for, setTimeout() would have to return it
(it doesn't currently):
function newSetTimeout ( f, ms ) {
On 11:59 AM, Boris Zbarsky wrote:
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
they really mean run this at 10Hz and if you run it with no delay
then they swamp your event loop and possible render wrong (e.g. the
text disappears before the user has a chance to read
On Mar 20, 2011, at 9:14 AM, Mark S. Miller wrote:
On Sun, Mar 20, 2011 at 8:56 AM, David Herman dher...@mozilla.com wrote:
But that alone should probably not stop us from moving ahead with
concurrency. If an engine wants to provide a sequential JS, they can probably
just do so and say
Im not a member of any group, but I follow closely and fwiw, I would like to
offer an outside +1 to Brendan's comments above. Differences and
versioning problems and things are going to arise naturally no matter how
well things are planned, better to introduce as few of them upfront as
possible
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
they really mean run this at 10Hz and if you run it with no delay then
they swamp your event loop and possible render wrong (e.g. the text
disappears before the user has a chance to read it).
I'm not convinced that this is
If it has been more than 20 milliseconds i expect both of them to be
able to be fired, so sure. In some ways this is similar how i don't
rely on the order of event listeners being fired.
On Sun, Mar 20, 2011 at 10:15 AM, Jorge jo...@jorgechamorro.com wrote:
Hi Bradley,
So, do you *really* say
On 3/20/2011 12:03 PM, Kyle Simpson wrote:
...
Multiple repeated calls to |setTimeout(f,0)| are bugs
I don't agree with that assertion at all. Two different functions
might queue up two different snippets to happen as soon as
possible, later, each of them using their own setTimeout(..., 0).
On Sun, Mar 20, 2011 at 3:03 PM, Kyle Simpson get...@gmail.com wrote:
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when they
really mean run this at 10Hz and if you run it with no delay then they
swamp your event loop and possible render wrong (e.g. the text disappears
On 3/20/11 1:55 PM, John J. Barton wrote:
On 11:59 AM, Boris Zbarsky wrote:
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
they really mean run this at 10Hz and if you run it with no delay
then they swamp your event loop and possible render wrong (e.g. the
text
On Sun, Mar 20, 2011 at 4:05 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/20/11 1:55 PM, John J. Barton wrote:
On 11:59 AM, Boris Zbarsky wrote:
Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
they really mean run this at 10Hz and if you run it with no delay
then
For an event with multiple listeners you can't rely on a certain order because
it's spec'ed that you shouldn't.
But given two events of the same kind and a single listener, you'd expect them
to be dispatched in order, won't you ?
A timer that times out is an event, and timers in the farther
It doesn't, so we're going to need a non-clamping alias. Perhaps an [ugly]
setTimeout ( ƒ, -1 ) ?
I posit that the clamping behaviour and timer resolution are domain-specific
(embedding-specific) implementation details. Browser makers have been able
to deal with run-away CPU scripts, even the
On Sun, Mar 20, 2011 at 6:19 PM, Wes Garland w...@page.ca wrote:
It doesn't, so we're going to need a non-clamping alias. Perhaps an
[ugly] setTimeout ( ƒ, -1 ) ?
I posit that the clamping behaviour and timer resolution are
domain-specific (embedding-specific) implementation details.
It isn't in the past though, it is scheduled to be run as soon as
possible past a certain point. That being said `as soon as possible`
may not be in a particular order (os schedulers / threads / event
listeners in js for example). I view this close to even listeners in
the respect that schedule of
On Sun, Mar 20, 2011 at 12:24 PM, John J. Barton
johnjbar...@johnjbarton.com wrote:
Looping as fast as possible is likely to be a bug. It's not similar to
queuing events.
It's the behaviour intentionally (if unwisely) requested by a lot of
animations and games, for what it's worth. There are
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists. Another part is
introducing new concepts and features to the language (like promises and vats).
I want to hear what Mark has to say at the TC39 meeting, but my
On Sat, Mar 19, 2011 at 1:13 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 18, 2011, at 5:54 AM, Peter van der Zee wrote:
+1 to standardizing the timer family.
I always thought this wasn't in because the specification didn't have
any asynchronism and specifying timers would open
Le 19/03/2011 07:02, David Herman a écrit :
It seems to me there are a couple pieces to Mark's concurrency
proposal. One part is formalizing the event queue that already exists.
Is this already done in the current proposal? Because I haven't found it.
Regardless, this work of formalizing the
I can't think of a single way to simulate setTimeout in ES5. Correct me if
I'm wrong, but I don't think ES5 exposes a single way of defining a
mechanism like:
--
var x = 4;
function f(){ x = 5; print(x); }
timer(f, 1);
print(f);
--
Such that it would output 4 before 5. That's what I
never write code on no sleep.
that code sample should be :
timers= (function () {
var timers = [];
var id=0;
timer=function (f,t) {
timers.push({func:f, interval:t, id:id++});
return id;
}
return timers;
})
runScript(env.js);
On 19 Mar 2011 14:43, Breton Slivka z...@zenpsycho.com wrote:
I can't think of a single way to simulate setTimeout in ES5. Correct me
if
I'm wrong, but I don't think ES5 exposes a single way of defining a
mechanism like:
--
var x = 4;
function f(){ x = 5; print(x); }
timer(f, 1);
What I was saying is, if I run this program through V8 right now (with
its theoretical future support of setTimeout() included), then what will
happen:
function fn() {
print(hello);
}
for (var i=0; i10; i++) {
setTimeout(fn,i*1000);
}
That for-loop will finish very quickly (probably 1 ms).
It seems to me there are a couple pieces to Mark's concurrency proposal. One
part is formalizing the event queue that already exists.
Is this already done in the current proposal? Because I haven't found it.
Sorry, I guess I should say, we can't add concurrency without having it be
On Sat, Mar 19, 2011 at 5:59 AM, David Bruant david.bru...@labri.fr wrote:
Le 19/03/2011 07:02, David Herman a écrit :
It seems to me there are a couple pieces to Mark's concurrency proposal.
One part is formalizing the event queue that already exists.
Is this already done in the current
? There is a spec hole here. Bringing setTimeout to ECMAScript would
be an occasion to answer the question and not let implementors do
whatever they prefer or even to forget the question. This would avoid
yet another de facto standard.
However, the tiny brick/element/component/part that is missing
Le 19/03/2011 17:58, Mark S. Miller a écrit :
On Sat, Mar 19, 2011 at 5:59 AM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
I fully agree that the current proposal and all related work
(yours included) offer very powerful mecanisms and solutions to
interpreted as strict eval code?
There is a spec hole here. Bringing setTimeout to ECMAScript would be an
occasion to answer the question and not let implementors do whatever they
prefer or even to forget the question. This would avoid yet another de facto
standard. However, the tiny brick/element
to specify what happens when you're in
strict mode and you do setTimeout(alert(this), 0). Is this string
interpreted as strict eval code? There is a spec hole here. Bringing
setTimeout to ECMAScript would be an occasion to answer the question and not
let implementors do whatever they prefer
On Sat, Mar 19, 2011 at 12:58 PM, Mark S. Miller erig...@google.com wrote:
The idea is not stupid at all. It's perfectly sound. For example, the delay
example you noticed could be made primitive and setTimeout built out of
that. Either can be built from the other. The advantage of layering
On Sat, Mar 19, 2011 at 10:57 AM, David Bruant david.bru...@labri.frwrote:
Le 19/03/2011 17:58, Mark S. Miller a écrit :
[...] The two things I'd fix in this lower layer abstraction:
* No clamping. Time runs as fast as the platform lets it run.
* The return value is not an integer but a
On Sat, Mar 19, 2011 at 2:49 PM, Breton Slivka z...@zenpsycho.com wrote:
never write code on no sleep.
that code sample should be :
timers= (function () {
var timers = [];
var id=0;
timer=function (f,t) {
timers.push({func:f, interval:t, id:id++});
return
On Sat, Mar 19, 2011 at 1:05 PM, Mark S. Miller erig...@google.com wrote:
On Sat, Mar 19, 2011 at 10:57 AM, David Bruant david.bru...@labri.frwrote:
Le 19/03/2011 17:58, Mark S. Miller a écrit :
[...] The two things I'd fix in this lower layer abstraction:
* No clamping. Time runs as
On Sat, Mar 19, 2011 at 1:34 PM, Peter van der Zee e...@qfox.nl wrote:
[...]
And re: return value. Some scripts might rely on the fact that the timers
return a number (an int, even). So if backwards compat is important (and it
always is), you can't really break with `typeof token ==
On 19/03/2011, at 17:58, Mark S. Miller wrote:
(...)
Layering the other way, with setTimeout at the bottom, would mean the event
loop could never run faster than 4ms per turn. This is unacceptable, and
probably has been since the mid '70s. Should we clamp our fast our CPUs can
execute
Le 19/03/2011 21:05, Mark S. Miller a écrit :
On Sat, Mar 19, 2011 at 10:57 AM, David Bruant david.bru...@labri.fr
mailto:david.bru...@labri.fr wrote:
I think there would be a need to wrapped the passed callback in
order to achieve garbage collection.
I didn't understand that.
On Mar 19, 2011, at 7:57 AM, Kyle Simpson wrote:
What I was saying is, if I run this program through V8 right now (with its
theoretical future support of setTimeout() included), then what will happen:
function fn() {
print(hello);
}
for (var i=0; i10; i++) {
setTimeout(fn,i*1000);
}
* No clamping. Time runs as fast as the platform lets it run.
* The return value is not an integer but a unique unforgeable object for
canceling the event. No one without
that object can cancel that event.
This last point is something I was about to raise when starting to think
about
Kyle: If there was a way to determine which timers are currently queued,
would that solve your problem? That's probably the only thing I'm missing
right now from the timer api: Some array with all queued
timeouts/intervals. Maybe that's to prevent the clear attack mentioned
before, looping all
On Sat, Mar 19, 2011 at 5:21 PM, Kyle Simpson get...@gmail.com wrote:
* No clamping. Time runs as fast as the platform lets it run.
* The return value is not an integer but a unique unforgeable object for
canceling the event. No one without
that object can cancel that event.
This last
On Mar 19, 2011, at 4:20 PM, Sam Tobin-Hochstadt wrote:
On Sat, Mar 19, 2011 at 6:50 PM, Brendan Eich bren...@mozilla.com wrote:
setTimeout does not introduce threads, shared memory among them, or even
non-determinism if we spec carefully (browsers have to implement carefully
already).
+1 to standardizing the timer family.
I always thought this wasn't in because the specification didn't have
any asynchronism and specifying timers would open Pandora's box.
- peter
On Fri, Mar 18, 2011 at 1:51 PM, David Bruant bru...@enseirb-matmeca.frwrote:
Hi,
_Foreword_
Each time I
Hi David, I think this is an excellent idea. I will add it to the
concurrency strawman.
However, since the concurrency strawman is on he agenda for May and I'm
currently overloaded preparing for next week's March meeting, I won't get to
this till April. Once I have a draft, further feedback would
On 18 March 2011 17:25, Wes Garland w...@page.ca wrote:
Right: the barrier to setTimeout functionality is that ECMAscript does not
define a concurrency model.
If we can define a concurrency model, then we can build setTimeout.
Two things off the top of my head to consider:
- timer
As I understand it, this type of thing was kept out of the language
proper intentionally, because of its strong dependency on host
environment. Some host environments may require tight and overriding
control of any event handling system, and exactly which types of
events (such as timeouts) are
On Mar 18, 2011, at 9:25 AM, Wes Garland wrote:
Right: the barrier to setTimeout functionality is that ECMAscript does not
define a concurrency model.
If we can define a concurrency model, then we can build setTimeout.
See my previous reply. JS with setTimeout has only pseudo-concurrency
On Mar 18, 2011, at 5:54 AM, Peter van der Zee wrote:
+1 to standardizing the timer family.
I always thought this wasn't in because the specification didn't have any
asynchronism and specifying timers would open Pandora's box.
How so? I created JS and its run-to-completion execution model
"Asynchronous" has a good (Greek) meaning but it is overused and abused. JS setTimeout is in fact not truly "without time" but more nearly "synchronous" to some resolution lower bound (4ms in the new HTML5 world), or "isochronous" in some virtual timeline.With setTimeout and setInterval and
On Mar 18, 2011, at 7:18 PM, David Bruant wrote:
As I said, one way to bring setTimeout would be to standardized a
lower-level mechanism based on which setTimeout could be implemented.
Now you've got two problems...
It is not precisely understood why setTimeout(..., 0) breaks the web if run
Speaking as someone who has written and currently maintains a
*synchronous* server-side JavaScript environment (based on V8), I attest
to the statement that I would *not* like it if V8 had `setTimeout()`
(...etc) in it, because unless V8 were going to take care of that
completely black-box for
On Fri, Mar 18, 2011 at 4:26 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 18, 2011, at 9:25 AM, Wes Garland wrote:
Right: the barrier to setTimeout functionality is that ECMAscript does
not define a concurrency model.
If we can define a concurrency model, then we can build
On 3/19/11 12:24 AM, Mark S. Miller wrote:
Is this 4ms codified in spec language somewhere? I couldn't find it by
casual searching.
http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-settimeout
step 5 (though note also step 9, which is the part that makes
Kyle;
On Fri, Mar 18, 2011 at 11:53 PM, Kyle Simpson get...@gmail.com wrote:
Speaking as someone who has written and currently maintains a *synchronous*
server-side JavaScript environment (based on V8),
I resemble this description, except that my platform is built on
SpiderMonkey rather than
On Mar 18, 2011, at 8:53 PM, Kyle Simpson wrote:
What I was saying is, if I run this program through V8 right now (with its
theoretical future support of setTimeout() included), then what will happen:
function fn() {
print(hello);
}
for (var i=0; i10; i++) {
setTimeout(fn,i*1000);
}
On Mar 18, 2011, at 9:43 PM, Wes Garland wrote:
I don't have breaks the web data, but executing f before setTimeout()
returns (rather than wait for us to get back in the event loop) changes the
semantics of the program. This might seem obvious, but I have seen the
analogue in suggestions
74 matches
Mail list logo
