Touch/Trackpad finger position

Hi. If I'm being too crazy here, please let me know! What would it require for us to have an API to get the exact position of fingers/touches from the trackpad? (even it not pressed) For example, let's say someone wants to write a WebApp in which you could sign something, or simply use a (good)

Re: Question of the Day: What about all this asynchrony?

Hi. Michael, the JavaScript (and Web in general) communities are very open and always queen to help. I just think you hit the wrong mailing list to discuss all that. For new comers, indeed, there is plenty to work on, practice and study. But keep in mind that many of those features came from

Re: Touch/Trackpad finger position

Very interesting. Thanks :) It was so close, Isiah! The problem with the current API is that you can "jump" from one place to another. Let's say I draw an "A" in the left side of my trackpad, then I draw a "B" in the right side of the trackpad. On the screen, they will overlap, with both letters

Re: Question of the Day: What about all this asynchrony?

Oh, you're right :-\ empty async functions return a promise, interesting... On Tue, Nov 7, 2017 at 2:27 PM, Michael Lewis wrote: > > async functions create a new promise for you upon every invocation, > which you resolve via `await`, but that's all invisible in the background >

Re: Question of the Day: What about all this asynchrony?

Michael, You've spent a considerable amount of time putting your thoughts into writing, so I don't intend to be dismissive of them, but this doesn't seem to be the right distribution channel for whatever you're getting at. As it stands, you've thrown quite a few questions out that don't seem to

Re: Question of the Day: What about all this asynchrony?

Making things simpler, clearer, and more visual has obvious benefits. I think I was very clear from the beginning that this was *NOT* a concrete proposal. And I've seen many posts on here that are not. From now on, I'll title my posts to more clearly indicate that *reading is abstract,

Re: Question of the Day: What about all this asynchrony?

:( Apologies, I didn't intend to reply-all on that. :\ I'll keep this one public too, since I just subjected everyone to the previous email as well. On Tue, Nov 7, 2017 at 4:03 PM, Jeremy Martin wrote: > Michael, > > You've spent a considerable amount of time putting your

Re: Question of the Day: What about all this asynchrony?

Correct, `for..of` instead of `forEach` On Wed, 8 Nov 2017 at 01:21 Logan Smyth wrote: > A nit, but that would have to be `for (const move of moves) await > doMoveAsync()` > since the `forEach` callback is a normal function. > > On Tue, Nov 7, 2017 at 11:47 AM, Naveen

Re: Question of the Day: What about all this asynchrony?

> async functions create a new promise for you upon every invocation, which you resolve via `await`, but that's all invisible in the background Is that correct? I thought async functions simply await promises. `await something()` works because something() returns a promise. But is there a

Re: Question of the Day: What about all this asynchrony?

*Side note about loading/defining Modules *(somewhat related to asynchrony) I've been writing a Module loader that's a hybrid between require.js and webpack. And in doing so, the obvious end-game solution for modules is a *GUI*. A GUI to help you scaffold the folders, files, import statements,

Re: Question of the Day: What about all this asynchrony?

I'm confused. You don't have time to read "The General Theory of Reactivity", yet (1) you have time to write this long, rambling email about your kids, and (2) expect people on this mailing list to spend their valuable time reading it? Please stay on topic for the list. Bob On Tue, Nov 7, 2017

Re: Question of the Day: What about all this asynchrony?

The email wasn't about my kids, and you don't have to read it (duh). If your time is so valuable, maybe you shouldn't be picking fights with rambling parents. Where is the list of approved topics? On Tue, Nov 7, 2017 at 5:44 AM, Bob Myers wrote: > I'm confused. You don't have

Question of the Day: What about all this asynchrony?

Good morning JavaScript world, Maybe I'll start my mornings with a cup of coffee, and a discussion prompt. We'll see how long it lasts. It's 4:39am. I live in Aurora, Illinois, about an hour outside of Chicago. My kids will wake up in an hour or two, so I don't have long, and should be

Re: Touch/Trackpad finger position

The ECMAScript language deals with semantics around the specific programming language, while native interactions are supplied by the host environment, e.g. Node.js and the browser. This is why interactions like window and document events are defined by W3C and friends, and strictly-language items

Re: Touch/Trackpad finger position

Also, for future reference, these kinds of feature requests belong in the WHATWG's mailing lists, not here. On Tue, Nov 7, 2017, 18:59 Eli Perelman wrote: > The ECMAScript language deals with semantics around the specific > programming language, while native interactions

Re: Touch/Trackpad finger position

The best place to ask about this is probably somewhere here: github.com/whatwg. I'm not sure which repo this topic would be in, but you can kindly ask about which repo to post in once you've opened an issue in the repo you think is most related. My guess would be github.com/whatwg/dom.

Re: Question of the Day: What about all this asynchrony?

Also, if you've made it this far, I think it's worth mentioning that these async strings are basically all you need for a realtime file system. File("newFile.ext").append(File("fileA"), File("fileB"), ...).transpile().save(); // --> automatically watches, all inputs (fileA, fileB, etc), caches

Re: Question of the Day: What about all this asynchrony?

For me the future is async functions (the present actually). I asked a question about possible support for async streams / observables here: https://esdiscuss.org/topic/stream-async-await and I realized that my use case was much better served by just using async functions to process each input

Re: Question of the Day: What about all this asynchrony?

I'm not experienced in async/await enough to know what "using async functions to process [streams]" would look like. You would have to create a new promise for every iteration? Even if performance isn't an issue, it just doesn't make sense to me. It's like, you could use `obj.value = "my

Re: Question of the Day: What about all this asynchrony?

async functions create a new promise for you upon every invocation, which you resolve via `await`, but that's all invisible in the background. It's basically: async function doMovesAsync(){ moves.forEach( move=>{ doMoveAsync(); //another async function } );

Re: Question of the Day: What about all this asynchrony?

... that should be `await doMoveAsync()` On Wed, 8 Nov 2017 at 01:16 Naveen Chawla wrote: > async functions create a new promise for you upon every invocation, which > you resolve via `await`, but that's all invisible in the background. It's > basically: > > async

Re: Question of the Day: What about all this asynchrony?

A nit, but that would have to be `for (const move of moves) await doMoveAsync()` since the `forEach` callback is a normal function. On Tue, Nov 7, 2017 at 11:47 AM, Naveen Chawla wrote: > ... that should be `await doMoveAsync()` > > On Wed, 8 Nov 2017 at 01:16 Naveen