Re: Shouldn't timers be specified?
process.nextTick already landed in browsers, as concept, it's called
setImmediate
http://msdn.microsoft.com/en-us/library/ie/hh673556(v=vs.85).aspx#setimmediate
About Rhino, that implementation is not the equivalent of what we have in
browsers, where the most useful thing ever is rarely used out there even if
completely cross browsers but IE where de-facto standard is shim amble
without problems.
I am talking about extra arguments any setInterval/Timeout accept, i.e.
setTimeout(callback, 1, some, thing);
where callback is
function callback(some, thing) { ... }
and arguments will be sent when the timeout is burned.
Here fully node.js compatible Rhino timers I have used in wru:
https://github.com/WebReflection/wru/blob/master/src/rhinoTimers.js
Said that, the fact node.js and browsers are sometimes way too much
misaligned is something I have blogged about already and in this case
node.js does not even return an Int32 as any browsers does, it returns an
object, still unique, but not an Number.
It would be nice to have these methods well defined across all platforms
br
On Sun, Jan 22, 2012 at 6:19 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
Absolutely agree. I don't see a place for Node's 1ms resolution in
browsers, which was the impetus for raising the issue. I see a place for
Node (and other non-browser platforms) to implement their own host timers
that provide higher resolution (In fact Node's process.nextTick(callback)
is a good example of host functionality that's useful but wouldn't belong
in a JS spec). But the point is that the lack of specification has already
resulted in incompatible implementations of ostensibly the same basically
required core language functionality.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
Brandon Benvie mailto:bran...@brandonbenvie.com January 21, 2012 9:59 PM Sorry to spam this thread but I wanted to get the relevent points in up front: 'Actually, wait a minute -- I think I disagree with you here. On what? Being past the deadline? Not rushing a de-jure standard before we have synthesized the right semantics from relevant JS embeddings? Spec the unofficial agreement, including the minimal(/maximal if it exists) time constraints, and go from there. This is needed. Why? What goes wrong if we go light on execution model one more time? I think nothing. But in fact we are going to get a little more into execution model in ES6. How much remains to be seen. We discussed it at last week's meeting. But this is not an all-or-nothing proposition, and I do not see the do-or-die requirement. Reality is what it is. HTML5 captures a lot. Node.js conforms. ES6 saying more doesn't alter these facts. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
This is a perfect use case for the forth-coming module system (similar to the way Globalization is being developed). Dave Herman and I had a brief over Twitter exchange that began with my desire for a migration of parseInt and parseFloat to Math, which I followed with a suggestion to do the same with setTimeout and setInterval (despite those currently existing in the realm of DOM APIs) to the imaginary Timer object. Rick On Sun, Jan 22, 2012 at 3:00 PM, Brendan Eich bren...@mozilla.org wrote: Brandon Benvie mailto:brandon@brandonbenvie.**combran...@brandonbenvie.com January 21, 2012 9:59 PM Sorry to spam this thread but I wanted to get the relevent points in up front: 'Actually, wait a minute -- I think I disagree with you here. On what? Being past the deadline? Not rushing a de-jure standard before we have synthesized the right semantics from relevant JS embeddings? Spec the unofficial agreement, including the minimal(/maximal if it exists) time constraints, and go from there. This is needed. Why? What goes wrong if we go light on execution model one more time? I think nothing. But in fact we are going to get a little more into execution model in ES6. How much remains to be seen. We discussed it at last week's meeting. But this is not an all-or-nothing proposition, and I do not see the do-or-die requirement. Reality is what it is. HTML5 captures a lot. Node.js conforms. ES6 saying more doesn't alter these facts. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
On 22/01/2012, at 21:00, Brendan Eich wrote: Brandon Benvie mailto:bran...@brandonbenvie.com January 21, 2012 9:59 PM Sorry to spam this thread but I wanted to get the relevent points in up front: 'Actually, wait a minute -- I think I disagree with you here. On what? Being past the deadline? Not rushing a de-jure standard before we have synthesized the right semantics from relevant JS embeddings? Spec the unofficial agreement, including the minimal(/maximal if it exists) time constraints, and go from there. This is needed. Why? What goes wrong if we go light on execution model one more time? I think nothing. But in fact we are going to get a little more into execution model in ES6. How much remains to be seen. We discussed it at last week's meeting. But this is not an all-or-nothing proposition, and I do not see the do-or-die requirement. Reality is what it is. HTML5 captures a lot. Node.js conforms. ES6 saying more doesn't alter these facts. Now isn't that ~ the opposite of what you said on 2011-03-18 in David Bruants' Bringing setTimeout to ECMAScript thread ? quote Add to that the fact that Netscape and Microsoft failed, or chose not to, standardize the DOM level 0, and we have the current split where setTimeout is in HTML5 but the core language is embedded with increasing success in non-browser, no-DOM host environments *that want setTimeout*. I'm open to Ecma TC39 absorbing setTimeout and the minimum machinery it entrains. We should ping Hixie. /quote Why ? What has changed ? P.S. Node.js does *not* conform. Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order ! -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
Rick Waldron mailto:waldron.r...@gmail.com January 22, 2012 12:50 PM This is a perfect use case for the forth-coming module system (similar to the way Globalization is being developed). Dave Herman and I had a brief over Twitter exchange that began with my desire for a migration of parseInt and parseFloat to Math, or Number -- IIRC, Crock proposed making better-behaved parse methods live there. which I followed with a suggestion to do the same with setTimeout and setInterval (despite those currently existing in the realm of DOM APIs) to the imaginary Timer object. Right :-P. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
Node.js does *not* conform. Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order ! Is there a reference or test case you can cite for this? Thanks! Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
On Jan 22, 2012, at January 22, 20121:35 PM, Jorge wrote: . Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order ! node.js does not conform to the 4ms clamp because that would be silly. It does not fire timers out of order, that I know of. If you have a case where that is not true then it's a bug in libuv (setTimeout's event system is in libuv now) that we need to have fixed. -Mikeal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
var d = new Date, i = setInterval(function () {console.log(new Date - d); d
= new Date;}, 1);
most likely gonna fire a sequence of
10
0
11
0
12
0
10
0
11
0
10
0
... not really reliable, even if delay is specified to 10 o 20, does not
look that consistent
with setTimeout, I have tried delay 3 and it's never less than 10 or 11,
but with delay 1 is almost always 0:
var d = new Date, delay = 3, i = setTimeout(function t() {console.log(new
Date - d); d = new Date; i = setTimeout(t, delay);}, delay);
br
On Mon, Jan 23, 2012 at 4:43 AM, Rick Waldron waldron.r...@gmail.comwrote:
Node.js does *not* conform. Not at all. Not only it doesn't clamp to 4ms
(which happens to be a good thing, IMO), but its timers often fire out of
order !
Is there a reference or test case you can cite for this? Thanks!
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
On 23/01/2012, at 04:57, Mikeal Rogers wrote: On Jan 22, 2012, at January 22, 20121:35 PM, Jorge wrote: . Not at all. Not only it doesn't clamp to 4ms (which happens to be a good thing, IMO), but its timers often fire out of order ! node.js does not conform to the 4ms clamp because that would be silly. Exactly http://groups.google.com/group/nodejs-dev/msg/788492357732e93e It does not fire timers out of order, that I know of. http://groups.google.com/group/nodejs-dev/browse_thread/thread/922a30cf88a1b784 If you have a case where that is not true then it's a bug in libuv (setTimeout's event system is in libuv now) that we need to have fixed. The test that's been disabled: https://github.com/joyent/node/blob/master/test/simple/test-next-tick-ordering.js#L50-54 -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
Correction: it is specified in HTML5 here http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers . Suffice to say that a DOM specification isn't sufficient for something so central to JavaScript, nor is it the specification currently followed by browsers anyway. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
Absolutely agree. I don't see a place for Node's 1ms resolution in browsers, which was the impetus for raising the issue. I see a place for Node (and other non-browser platforms) to implement their own host timers that provide higher resolution (In fact Node's process.nextTick(callback) is a good example of host functionality that's useful but wouldn't belong in a JS spec). But the point is that the lack of specification has already resulted in incompatible implementations of ostensibly the same basically required core language functionality. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Shouldn't timers be specified?
Sorry to spam this thread but I wanted to get the relevent points in up front: 'Actually, wait a minute -- I think I disagree with you here. WHATWG specifies the specific event queue of the browser. Node.js has its own event queue. Others may as well. The unofficial agreement of JS has always been, no matter where you embed it, it should never have pre-emption. So what we would be specifying is the rough concurrency framework required of any JS embedding. In other words, it would be a more abstract specification of event queues, of which WHATWG event queues are a valid implementation.' Spec the unofficial agreement, including the minimal(/maximal if it exists) time constraints, and go from there. This is needed. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
