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
so, the gc algorithm described at
http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#abstract_gc_algorithm
has a worst-case runtime of O(L+W*W)
where L is the number of live objects,
and W is the number of entries in live weak maps.
O(W*W) happens because the algorithm scans all weak-map
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
Hi Felix,
I have a note on the wiki page offering a less algorithmic approach to
specifying weak maps. I don't think we should be putting GC algorithms in the
spec at all; that would be overspecification. Instead, we should just focus on
defining reachability, and leave implementors free to
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
On Sun, Mar 20, 2011 at 5:12 AM, felix feli...@gmail.com wrote:
I haven't tried implementing this, so no idea how well it works in practice.
I thought of this. It would definitely work. However, it requires an
extra conditional branch for each object marked by the GC. So relative
to the
Come to think of it, evaluating implementations for proper tail calls is a
little easier, at least in implementations with fixed-size stacks and stack
overflow exceptions. I'm not quite sure how you write weak map tests that check
memory consumption, unless implementations expose heap size
I said that WHATWG has done some on work specifying what currently
happens in browser (joining with your idea of be[ing] compatible with
existing event queue semantics). One idea would be to see what they've
done, get inspired and specify the event queue in ECMAScript.
OK. I'm on board for
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
Fair enough -- just interpret my email as an aside. :)
Dave
On Mar 20, 2011, at 8:57 AM, Mark S. Miller wrote:
Hi Dave,
I think you misunderstand the purpose of posting this algorithm. Before
Felix's algorithm, to the best of my knowledge all documented and/or
implemented ephemeron
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
On Sun, Mar 20, 2011 at 8:56 AM, David Herman dher...@mozilla.com wrote:
I said that WHATWG has done some on work specifying what currently
happens in browser (joining with your idea of be[ing] compatible with
existing event queue semantics). One idea would be to see what they've
done,
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
Even though I wrote it, I don't think the clone example on the Private Names
pages is very clear so I'll take another trying at explaining the conflict free
extension use cases. Just to make sure that we don't confuse things with any
assumptions about the implicit semantics of a clone
[snip]
Anyway, now that I've confirmed my suspicions, I'm hesitant about the
private names proposal as described. The fact that declaring a certain name
as private affects _all_ property name lookups in that scope (all lookups
that use the dot operator or object literal syntax, at
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
Oops mind fart:
Make that obj.foo===obj[0]
The point is that what follows the dot ia already evaluated differently than
what comes between brackets
Dean Landolt d...@deanlandolt.com wrote:
[snip]
Anyway, now that I've confirmed my suspicions, I'm hesitant about the
private names
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 12:22 PM, Allen Wirfs-Brock wrote:
Oops mind fart:
Make that obj.foo===obj[0]
The point is that what follows the dot ia already evaluated differently than
what comes between brackets
Right; I think Dean and I are saying that this would be the first time obj.foo
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 Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from obj['foo']. And to ascertain that
those two meant different things, I'd have to go searching through the code
for a `private foo`
OK, you lost me.
On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from obj['foo']. And to ascertain that
those two meant
On Sun, Mar 20, 2011 at 3:36 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from obj['foo']. And to ascertain that
those two meant
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
On Sun, Mar 20, 2011 at 3:49 PM, Andrew Dupont mozi...@andrewdupont.net wrote:
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The proposal strongly implies that the `private` declaration affects only a
property name on the right of . or
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
If I can add my point to the discussion, I must admit I don’t like the “Private
Names Proposal” either. I find it confusing and complex. As I thought I was the
only one who had this in mind, I didn’t react before but if more people are
confident it’s a strange proposal, maybe could the proposal
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 Mar 20, 2011, at 12:49 PM, Andrew Dupont wrote:
OK, you lost me.
On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are saying that this would be the first time
obj.foo meant something different from
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The most obvious reason is if the name of the property contains a character
which cannot be an identifier character in the property name... like a
unicode character, for instance.
Without
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.
On Sun, Mar 20, 2011 at 6:21 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 20, 2011, at 12:49 PM, Andrew Dupont wrote:
OK, you lost me.
On Mar 20, 2011, at 2:36 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2011, at 10:55 AM, Andrew Dupont wrote:
Right; I think Dean and I are
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 Mar 20, 2011 3:34 PM, Kyle Simpson get...@gmail.com wrote:
BTW, if you know that a property name is foo, why would you ever code
obj[foo] instead of obj.foo?
The most obvious reason is if the name of the property contains a
character which cannot be an identifier character in the property
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
On Mar 20, 2011, at 4:20 PM, Dean Landolt wrote:
[big top-cite snipped -- folks, please try to cut if you can.]
I think you're missing the distinction. The obj[foo] example is just a
stand-in for `var foo=foo; obj[foo]` -- we would all expect the string key
lookup to be the same as obj.foo,
On Mar 20, 2011, at 4:20 PM, Dean Landolt wrote:
I think you're missing the distinction. The obj[foo] example is just a
stand-in for `var foo=foo; obj[foo]` -- we would all expect the string key
lookup to be the same as obj.foo, and anything less would be a bit
surprising. This is what
typically this is seen as a quality of implementation issue. Note the we (and
most other language specs.) don't say much (or anything) about GC in general.
In one sense we don't need to say anything else about WeakMaps because it would
be a lower quality implementation to retain objects in one
On Mar 20, 2011, at 6:53 PM, David Herman wrote:
typically this is seen as a quality of implementation issue. Note the we
(and most other language specs.) don't say much (or anything) about GC in
general. In one sense we don't need to say anything else about WeakMaps
because it would be
First of all, let me be clear: my objections are only as deep as the syntax
layer. I'm not arguing against the usefulness of private names as a concept.
On Mar 20, 2011, at 6:51 PM, Brendan Eich wrote:
I encourage folks to read the private names thread from late last year, since
we are
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to me.
This gets at my other objection. Code is far harder to debug when every
single property lookup
On Mar 20, 2011, at 11:05 PM, David Herman wrote:
right now, bracket notation is a superset of dot notation, but it would no
longer be under the proposed syntax.
I'm afraid I can't figure out what this means, but it doesn't sound true to
me.
I noticed (in both this thread and the
On Mar 20, 2011, at 9:58 PM, Andrew Dupont wrote:
The revision would address all my concerns — thanks. I'm all for
distinguishing the static case from the dynamic case, as long as we can
maintain the separation between public names and private names, and know
which is which without
60 matches
Mail list logo
