On 6/23/17 12:39 PM, Boris Zbarsky wrote:
The rest of what you see is because the console API and the internal
error reporting use slightly different mechanisms for notifying about
new messages:
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1375899 to
hopefully align these more, fwiw.
On Fri, Jun 23, 2017 at 5:39 PM, Boris Zbarsky wrote:
> I should note that if you add this to your testcase:
>
> ...
>
> then you will see something like this in Firefox:
Cool, thanks, I never got around to trying that.
> That won't give you the right onerror behavior.
Indeed not, I should hav
> Allocating, filling, accessing and GC'ing the return object will take
more time than calling the underlying C
That seems like the nail in the coffin for this suggestion. Thanks. I
don't have anything to add.
On Fri, Jun 23, 2017 at 9:34 AM, Florian Bösch wrote:
> On Thu, Jun 22, 2017 at 8:
On 6/23/17 7:01 AM, T.J. Crowder wrote:
On Firefox, I get
```
1
2; cancelling
dispatch complete
then
uncaught exception: 1
uncaught exception: 2
```
...where the traces point to the `dispatchEvent` line. So it seems to
store them up and then report them.
I should note that if you add this to
On Thu, Jun 22, 2017 at 8:02 PM, Robert Poor wrote:
>
>function sincos(theta) {
> return { sin: sin(theta), cos: cos(theta) };
>}
>
Allocating, filling, accessing and GC'ing the return object will take more
time than calling the underlying C library function which emits the machine
On Fri, Jun 23, 2017 at 10:38 AM, Robert Poor wrote:
>> `return { sin: sin(theta), cos: cos(theta) };` will add pressure to the
>> nursery of the garbage collector.
>
> True -- forgive my ignorance, but is there a way to return multiple values
> that does not cause heap allocation? That was my i
This looks quite cool but I have a question. Would fixing this allow for non- blocking calls called within a try / catch when throwing an error be caught by that catch statement?
Thanks, Domenic, I had a quick look at that and I hope that other
implementers show some interest. It's certainly a step in the right
direction, although it also suffers from not being able to break on
(caught) exceptions in the debugger.
I know that there are also efforts to allow EventTarget co
> I think that's the answer to your question about `finally`.
Indeed it is, thank you. I'd read before about propagation of exceptions
but I was having trouble pinning down where this happens in the spec text.
> On Chrome, those traces point to our `setTimeout` line; on
> Firefox, they don't hav
Indeed, you cannot replicate dispatchEvent’s behavior, because it catches the
error, then uses a browser-specific primitive “report an exception”. Over in
the HTML spec, we’ve suggested exposing that primitive to users, but it hasn’t
garnered sufficient implementer interest; see
https://github.
> Are thrown errors in a try block considered to be handled
> even if there's no catch block?
An exception propagates out of a function (and thus is ultimately reported
unhandled if unhandled) if it's what terminates the function. If code in
the `finally` block does something to prevent the origin
I previously wrote:
>> most implementations for cos(theta) actually generate sin(theta) as a
"byproduct"
As others several have pointed out, that's not really true. V8, for
example, uses a (different) Taylor series approximation for sin and cos.
But given the amount of work that goes into reduci
Hi Robert,
On Thu, Jun 22, 2017 at 6:02 PM, Robert Poor wrote:
> How often have you seen code that calls Math.sin() and Math.cos() with
> the same argument, e.g:
>
>x = r * Math.cos(theta);
>y = r * Math.sin(theta);
>
> ? This trope is repeated for polar coordinates, complex arithmetic,
A long trip down a rabbit hole has brought me here. Long story short(ish),
I was attempting to replicate how `EventTarget.prototype.dispatchEvent()`
works in plain JavaScript code. A naive implementation (like Node's
EventEmitter) would simply loop over any bound handlers and call them in
turn. Ho
14 matches
Mail list logo
