Hey everyone!
I'm new here, although I often read the mailing list, so, hi!
Anyway, I've been thinking about unblocking sleep semantics for ES, meaning
that you could write functions that you do asynchronous things, while
preserving the code flow. An example could be the require() function,
famil
Yeah, I was aware of the coroutines in generators, that's why I said it
would be sort of sugar. :)
On Tue, Jan 17, 2012 at 10:43 PM, David Bruant wrote:
> Le 17/01/2012 21:38, Axel Rauschmayer a écrit :
> > More
> > material:
> http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the
o this (or to find
out if it already exists :] ).
Cheers,
Jussi
On Tue, Jan 17, 2012 at 11:00 PM, Dean Landolt wrote:
>
>
> On Tue, Jan 17, 2012 at 3:54 PM, Jussi Kalliokoski <
> jussi.kallioko...@gmail.com> wrote:
>
>> Yeah, I was aware of the coroutines in genera
You can get emulate that kind of a feature quite simply in ES5+ (and
earlier, if you have enough polyfills, or make compromises) if you like it,
see https://gist.github.com/1678065 .
Cheers,
Jussi
On Wed, Jan 25, 2012 at 8:49 PM, Herby Vojčík wrote:
> I see more a "cultural" question here. Ther
I'm not sure what to think about this, being a big fan of the UTF-8
simplicity. :) But anyhow, I like the idea of opt-in, actually so much that
I started thinking, why not make JS be encoding-agnostic?
What I mean here is that maybe we could have multi-charset Strings in JS?
This would be useful e
We're working on JS audio decoders, and one huge performance issue atm is
clz() [count leading zeroes], which is a very commonly used algorithm in
decoders. We've tried several different approaches and benchmarked them
[1], however, different approaches work better on different engines, so
optimizi
to namespace these bit-operators in a different
> module?
> Bit.clz() perhaps? The Math module is getting a bit crowded.
>
> On Sat, 03 Mar 2012 23:21:11 -0800, Brendan Eich
> wrote:
> > I'm open to clz/clo. The names perhaps need to be less cryptic... or not.
> &g
(from the left or
> right) as a single number as if the lsb was 1. You can create masks
> for this to & and >>, but it's not as versatile. Also, maybe a
> toString function for binary with leading zero padding (or are we
> getting String#pad now?).
>
> - pete
[0, 1, 2, 3]).multiply(2); // {0: 0, 1: 2, 2: 4, 3: 6}
new Uint8Array([0, 1, 2, 3]).multiply(new Uint8Array([3, 2, 1, 0])); // {0:
0, 1: 2, 2: 2, 3: 0}
Maybe even this, if we want to go crazy:
myFloat32Array.fft();
myFloat32Array.ifft();
myFloat32Array.rfft();
myFloat32Array.irfft();
Imagining th
On Sun, Mar 4, 2012 at 6:44 PM, Allen Wirfs-Brock wrote:
> I agree that there are useful functions when doing bit level decoding.
> Luke has been championing the Math function additions for ES.next so he
> should probably be the one to look at these specifically.
>
> I assume that this function
o guess. This practice
> becomes even better supported by our new module system's
> import-with-renaming.
>
> Let's keep exported names clear. Let's abbreviate if necessary on import.
>
I sort of agree with this, although the JS1K devil in me is trying to figh
standardizing an obscure acronym. This way, for every file that "clz" or
>> "gopd" appears in, there's a declaration at the beginning stating the
>> correspondence with a name whose meaning is easier to guess. This practice
>> becomes even better supported by ou
got modules fully
> spec'd and can start simply defining modules that should be available by
> default.
>
> --Oliver
>
> On Mar 4, 2012, at 2:46 PM, Jussi Kalliokoski wrote:
>
> On Sun, Mar 4, 2012 at 11:50 PM, Oliver Hunt wrote:
>
>> It's worth noting that
Pitching in a bit. Heh, its seems to me like a lot of people will be happy
when/if we eventually get macros in.
If this is really a too long word to type or takes too many characters (I'm
not saying it is, I don't really have an opinion on... this.), what about
this (may be flat out stupid, but ju
> Ironically, with a German keyboard, it is quicker to type "this." than it
> is to type "@".
Alt Gr + 2? Yeah, that's why I'm using a US keyboard, although I'm Finnish.
:) Easier to live with missing umlauts than with alt gr layouts.
___
es-discuss mai
Still not sure if I like this, but I wanted to point out that there's no
syntax conflict between @ as a 'this' and 'this.' shorthand and obj.@name,
as far as I can tell.
The only weirdness would be this:
this.@name
vs
@@name
Otherwise they seem to conflict no more than object literals, labels
While I agree with you on their usefulness, I don't think this will fly, at
least for the browser. This would allow fingerprinting users which is
considered a very bad thing (makes tracking without cookies possible), and
is very much avoided in all browser APIs, especially a problem with APIs
that
17 matches
Mail list logo
