On 10/27/16 4:25 PM, Bergi wrote:
But you've got some good and important points.
Thanks!
Things to note:
- Cancellation is targeted to specific operations (no "cancel chain"
ambition).
I'd however love to be able to cancel specific chaining operations,
i.e. `then` callbacks.
If you try t
On 10/27/16 6:18 PM, Isiah Meadows wrote:
1. Add a new `import.fork(script): Promise` method-like
expression that loads the worker and resolves when done/rejects if it
couldn't for some reason.
What does "done" mean in this case?
- `worker.send(message, sharedBuffers?)` - Send a message and
Here's my idea for a new API, leveraging ES modules and the proposed (stage
2) dynamic `import()` proposal. It also supports the shared memory proposal.
1. Add a new `import.fork(script): Promise` method-like expression
that loads the worker and resolves when done/rejects if it couldn't for
some r
Can we please start talking about Iterators already? The Python community
are laughing at us! Widening the Array prototype is like putting lipstick
on a pig...
On Thursday, 27 October 2016, Bergi wrote:
> Mark M. Young wrote:
>
>> I am proposing a replacement for Array.prototype.reduce and
>> Ar
Jan-Ivar Bruaroey wrote:
I'm posting this here in hopes to bring the discussion back to practical
use cases and minimal needs.
Sorry, did we leave that somewhere? :-)
But you've got some good and important points.
Things to note:
- Cancellation is targeted to specific operations (no "cancel
Mark M. Young wrote:
I am proposing a replacement for Array.prototype.reduce and
Array.prototype.reduceRight.
Nice. Allowing to pass an argument for the `this` value was missing when
folding an array, and your suggestion `accumulate` is a fitting method name.
However, I fear the use cases a
I am proposing a replacement for Array.prototype.reduce and
Array.prototype.reduceRight. The main improvements are 1) iteration always
starts at index 0 (or k-1 in the case of accumulateRight) on non-empty arrays
and 2) it allows definition of callbackFn's ‘this' context just like ‘every’,
‘fi
OK, so if fetch Response can't be cloned that was my bad, sorry for
confusion.
On 27 Oct 2016 8:12 p.m., "Boris Zbarsky" wrote:
> On 10/27/16 1:47 PM, Michał Wadas wrote:
>
>> It's already handled by current specification as structured clone
>> algorithm.
>>
>
> Sort of. Not all things can be s
On 10/27/16 1:47 PM, Michał Wadas wrote:
It's already handled by current specification as structured clone
algorithm.
Sort of. Not all things can be structured cloned. A fetch Response,
for example, can't be, and that's what the example being discussed was
using...
-Boris
It's already handled by current specification as structured clone
algorithm.
Though having binary serialisation format would be cool.
On 27 Oct 2016 6:38 p.m., "Boris Zbarsky" wrote:
> On 10/27/16 10:02 AM, Frankie Bagnardi wrote:
>
>> It doesn't really need to clone anything, you just create a
On 10/27/16 10:02 AM, Frankie Bagnardi wrote:
It doesn't really need to clone anything, you just create a promise on
each side, on top of the normal events.
And how is the resolution value transferred over? This is the cloning step!
-Boris
___
es-di
My example is polyfillable and include cloning final result of promise.
Actually it's RPC built above current worker messaging capabilities.
That's so prevalent use case that I'm convinced it should be built in
language.
On 27 Oct 2016 3:57 p.m., "Boris Zbarsky" wrote:
> On 10/27/16 9:48 AM, Mic
It doesn't really need to clone anything, you just create a promise on each
side, on top of the normal events. The way you'd implement this currently
is a token that gets passed to the worker with the request payload, and
gets sent back with the response payload.
It'd just be nice to save some wor
On 10/27/16 9:48 AM, Michał Wadas wrote:
Currently we put emphasis on request-response model - we request
something from function (returning Promise/taking callback) and we wait
for single return value. Workers are different beasts - they can emit
messages on their own and don't have to emit ANY
Resending, because I forgotten to include es-discuss mail.
Anyway, can you explain it more about mismatch between WebWorker and modern
> js idioms
>
Currently we put emphasis on request-response model - we request something
from function (returning Promise/taking callback) and we wait for single
I originally thought such functionality can be implemented on top of
current event based model, but request-response pattern is such commonly
used for workers so it's worth to consider including this to spec.
But the current event namespace already has it's own usage so how about
something like th
Likely this would be more convincing without a bug. Here is the correct
wait function:
let wait = (ms, cancel = new Promise(() => {})) => {
let id, both = x => [x, x];
cancel.then(...both(() => clearTimeout(id)));
return Promise.race([new Promise(resolve => id = setTimeout(resolve,
ms)),
17 matches
Mail list logo
