On Mon, Feb 12, 2018 at 11:27 AM, Алексей wrote:
> I think there is something we could have right now to solve the problem of
> missing `await` without changes to the ES - it should be collored
> differently in IDE or texteditor you are using. Not like an error - because
> it's actually not. But
expressed more quickly and be
> less prone to bugs. The `autoasync` `background` concept makes this even
> more so. Retaining all the functionality, increasing rate of productivity.
> That's the whole point.
>
> On Thu, 7 Dec 2017 at 20:36 Florian Bösch wrote:
>
>> On Th
On Thu, Dec 7, 2017 at 2:34 PM, Naveen Chawla wrote:
> How has using async await made you type more? Can you give an example? I
> suspect you're not using it in the way it was intended to be
>
See example OP pasted. It's nothing but async/await. It doesn't add any
semantic, syntactic or logic th
as I predicted once you use it, await/async infests all calls/funcdefs, and
has now become pointless line-noise that you need to remember to write or
you will get into trouble, but serves no discernable semantic, syntactic or
logical function other than making you type more.
solution: write a tran
On Thu, Nov 2, 2017 at 4:43 AM, kai zhu wrote:
> > the primary reason is because traditional oop skills gained from
> c#/c++/java/python/etc translate poorly to javascript.
>
I've never found that to be the case.
>in javascript, class-instantiated objects are inferior to plain-objects,
> because
I use a simple build script/requirement/module system I wrote myself in a
few dozen lines that does things the way I like it. I find the permanent
churn of pointless new flavors of the same thing annoying and distracting,
whatever happened to writing code and be done with it, programming isn't
spen
On Thu, Jul 27, 2017 at 12:18 AM, Brendan Eich
wrote:
> The solution is not to hate JS. It's not going to change incompatibly.
> Rather, you can use linters, "transpilers", compilers, voluntary unchecked
> subsets -- all possible today.
>
So basically "the best way to use JS is to not use JS". A
On Wed, Jul 26, 2017 at 11:41 PM, Brendan Eich
wrote:
>
> Those languages forked and some modernized (I remember Fortran 77). Those
> are all quite a bit older than JS. I would also suggest they are for the
> most part stunning successes. We've learned a lot from them.
>
Yes, but we'll also want
On Wed, Jul 26, 2017 at 9:47 PM, Bruno Jouhier wrote:
> JavaScript is often referred to as the "assembly language of the web". Did
> any instruction ever get removed from the x86 instruction set? Will this
> ever happen?
>
There are some features of x86 which where ditched. The more well known
e
On Wed, Jul 26, 2017 at 9:00 PM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
>
> keeping it alive and healthy beyond its browser-limited existence.
>
Many languages (including Python and Perl) concluded that at some point
things have to be "cleaned up". The track record of languages th
On Tue, Jul 25, 2017 at 11:50 PM, Brendan Eich
wrote:
>
> Core language changes are different in kind from sync touch events. It's
> very hard to plan to remove anything on a practical schedule or
> order-of-work basis. Engine maintainers likely still hate more modes, and
> users should too. New s
On Sun, Jul 23, 2017 at 6:49 AM, Jordan Harband wrote:
> There's lots of other threads on why no new modes are likely to ever be
> introduced.
>
And here we see the language evolution committee in its natural habitat
setting itself the impossible goal to support everything every introduced,
stil
wrote:
> On Thu, Jun 29, 2017 at 9:19 AM, Florian Bösch wrote:
> > > Improve performance
> >
> > I doubt that this sequence of calls:
> >
> > min = Math.min(min, value)
> > max = Math.max(max, value)
> >
> >
> > Is slower than this:
> >
>
>
>- Improve performance
>
>
I doubt that this sequence of calls:
min = Math.min(min, value)
max = Math.max(max, value)
Is slower than this:
[min,max] = Math.minmax([min,max,value])
Because while the former can get inlined by JIT, the latter can't, and on
top, it allocates 2 objects wh
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
<
tj.crow...@farsightsoftware.com> wrote:
> I'd missed that this was the continuation of a thread. Florian Bösch
> [started it](https://esdiscuss.org/topic/float16array#content-0) with
> interop in mind, in fact. So that makes sense.
>
> -- T.J. Crowder
>
>
>
>
On Wed, May 17, 2017 at 2:05 PM, Leo Balter
wrote:
> Why?
>
Adding just because it's cool is not enough to make it through the staging
> process.
>
Because Float16 is a widely used format present on nearly all computers
GPUs sold the last 10 years. It's widely used to improve performance and
mem
On Sun, Feb 26, 2017 at 5:30 PM, Codefined
wrote:
> I'll be interested to see what you guys consider the
> advantages/disadvantages of this method, which I hope to be "the middle
> between two ends" on whether to go fully into promises or fully into
> co-routines. Neither of which are in my opin
await/async are de-facto co-routines. await/async will infect all code by
necessity of software engineering. At which point they're actual
co-routines, implemented badly, without a proper API.
On Sun, Feb 26, 2017 at 3:26 PM, Jerald Cohen
wrote:
> Florian,
>
> You sure you're not just adding mor
On Sun, Feb 26, 2017 at 2:51 PM, Codefined
wrote:
> What I feel we need is some way of making an asynchronous function
> "appear" to be synchronous.
>
That's what co-routines are. Best practices for co-routines is usually to
have some sort of API to spawn them (like new Routine(somefunction)), to
On Sun, Feb 26, 2017 at 2:17 PM, Codefined
wrote:
> Because `d()` is no longer an asynchronous function, you can call it like
> normal, surely?
>
Only async functions can await. Only await pauses execution to wait on
async.
___
es-discuss mailing list
On Sun, Feb 26, 2017 at 2:08 PM, Jerald Cohen
wrote:
> (although, at the moment, I fail to see why one can't just use a normal
> "return").
>
You're probably unaware of this, but there is a fixation in this community,
and many adjacent ones, that if you sprinkle syntax magic dust atop
co-routine
nd that my "theory" on actual use is therefore not
just idle speculation, it's actual use reality, and you should consider
that.
On Sun, Feb 26, 2017 at 1:43 PM, Florian Bösch wrote:
> It would be nice if there even was an argument, but there isn't. There
> isn't b
n Sun, Feb 26, 2017 at 12:05 PM, Alexander Jones wrote:
> Florian, you shouldn't pass the argument of explicit vs implicit
> coroutines off as being so simple. There are many compelling arguments for
> both! Please Google them!
>
>
> On Sun, 26 Feb 2017 at 00:01, Florian Bös
On Sat, Feb 25, 2017 at 11:55 PM, Codefined
wrote:
> This seems to be so very confusing for anybody new studying this language,
> almost everyone I talk to gets stuck up on some part of it.
>
Promises are bad, and mixing them with async/await is worse. Should never
have been added to any kind of
On Sun, Nov 6, 2016 at 9:29 PM, Isiah Meadows
wrote:
> My main focus on this was CPU scheduling and time sharing. Most runtimes
> already shove most outside I/O to another thread, so I wasn't that
> concerned about that. (You could use some indirection and deferral to
> implement cooperative mult
On Sun, Nov 6, 2016 at 6:57 AM, Isiah Meadows
wrote:
> TL;DR: I'm proposing a completely different threading model,
> supporting lightweight and cooperative multitasking while allowing
> synchronous, thread-safe communication and inspection. Apologies for
> the length.
>
Cooperative multitasking
On Wed, Nov 2, 2016 at 6:16 PM, Bradley Meck wrote:
> I'm fine with co-routines, just explicit ones (which we currently have via
> generators and async functions). Implicit ones make it hard to reason about
> if a variable needs to place guards prior to performing any action if
> actions pop the
On Wed, Nov 2, 2016 at 5:59 PM, Bradley Meck wrote:
> Multiple threads are fine, but the "seamless" shared mutable variables are
> a no go on my end.
>
You already have concurrent threads of execution accessing shared mutable
variables with either Promises or async/await. OS level threads are a
p
op if you wish to do so.
On Wed, Nov 2, 2016 at 4:25 PM, Florian Bösch wrote:
> On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck
> wrote:
>
>> Florian, one of the great aspects of generators and async functions in
>> ECMAScript is that they are explicit. It makes understandin
On Wed, Nov 2, 2016 at 4:13 PM, Bradley Meck wrote:
> Florian, one of the great aspects of generators and async functions in
> ECMAScript is that they are explicit. It makes understanding where
> synchronization might need to occur very easy to find. I am unsure what
> your proposal to prevent in
What I meant to illustrate is that concurrency always leads to race
conditions, and that neither promises nor async/await are free of them, and
so it's silly to argue against co-routines on that basis, because of all
the continuation mechanisms, they're the most convenient to use with the
least dra
I'd like to quickly point out that Promises, async/await are actually
implementations of co-routines. Unlike true co-routines however they're
infective (once something down the call stack becomes a promise or an
async, it infects upwards). They have none of the conveniences of actual
co-routines (n
On Sun, Mar 13, 2016 at 10:18 PM, Boris Zbarsky wrote:
>
> Adding some more flexible ways to deal with GC'ing beyond "just making
>> it better" would be highly welcome.
>>
>
> Yes, this I agree on.
Maybe some kind of API to 1) inform the GC about what strategy of GC'ing
you would prefer and 2) i
I'd like to chime in here on the GC. I make my living writing WebGL code
for a living. JS'es stop-the-world mark&sweep for however long it takes
approach to GC'ing is very troublesome.
A new frame has to be produced every 16.6ms (and in some cases as in the
merging WebVR implementations every 11.1
On Fri, Jan 1, 2016 at 3:51 PM, Norbert Korodi
wrote:
>
> As I reread my letter I have to admit that I might sound arrogant /
> offensive (and I am sorry for that , at least I am honest ) but I am really
> tired of reading about "new"-ish es features which are only new to this
> platform.
>
While
On Sun, Oct 25, 2015 at 10:13 AM, Carl Smith wrote:
> Thanks for the link, Florian. I hadn't seen that. I don't think you can
> emulate the mouse with pointerlock. It works differently.
>
You cannot emulate the mouse for two reasons:
- You can't synthesize the necessary events to make it wo
There is an API called "pointerlock" whose purpose is to allow you to
capture the mouse. An equivalent API is (as of yet) lacking in the gamepad
API, but it is requested as a feature:
https://github.com/w3c/gamepad/blob/gh-pages/FeatureRequests.md
On Sun, Oct 25, 2015 at 2:13 AM, Carl Smith wrote
I'm a python user and I dislike using **, it just becomes rather noisy.
Expressing formulas in text based programming languages has always been
kind of a drag. On the other hand, often the mathematical expression of a
formula would be quite inefficient because they lack the ability to keep
tempora
Float16 isn't a "legacy" format to Float32 much in the same way that
unsigned int16 isn't a "legacy" format to unsigned int32.
Float16 is a mandatorily supported format in OpenGL ES 3.0 textures and
vertex attributes.
If more precision than byte is required, but less than float32 precision is
acc
Ah and don't forget that allocating ram till the machine swaps is also a
DOS.
On Mon, Dec 1, 2014 at 10:49 AM, Florian Bösch wrote:
> well, just because you don't DOS the main thread, doesn't mean making a
> machine 800% busy isn't a DOS.
>
> On Mon, Dec 1
well, just because you don't DOS the main thread, doesn't mean making a
machine 800% busy isn't a DOS.
On Mon, Dec 1, 2014 at 10:43 AM, Michał Wadas wrote:
> WebWorker with blocked XHR, importScript, WebSockets, creating new
> WebWorkers should be appropriate and secure against while(true) ;
>
_
A proper solution really is a separate VM, that isolates the complete
environment watertight and by default denies all interaction except for
those which have been defined as interaction points (alas it would also see
to it a DOS attack with a while(1){} appropriately times out).
Anything else is
On Sun, Nov 30, 2014 at 1:41 AM, Thaddee Tyl wrote:
> You can do a lot more. You can prevent the issues you point out (and
>
many others) by mocking all built-in object's prototypes that you want
> to feed the sandbox (so that modifications are actually performed on a
> throwaway prototype), and
On Mon, Nov 24, 2014 at 9:00 AM, Brandon Andrews <
warcraftthre...@sbcglobal.net> wrote:
> float32/64
- float16: common name: half, IEEE 754-2008: binary16, often used on GPUs
- float32: common name: float, IEEE 754-2008: binary32
- float64: common name: double, IEEE 754-2008: binary64
On Sun, Nov 23, 2014 at 12:27 PM, Michał Wadas
wrote:
> literal_eval description:
> >The string or node provided may only consist of the following Python
> literal structures: strings, numbers, tuples, lists, dicts, booleans, and
> None.
>
Also known as JSON.parse.
> My proposition is "safe eva
Typed arrays today are specified with support for Float32Array,
Float32Array.
A useful additional data type would be Float16Array. It's useful because
GPUs (particularly mobiles) have support for it, and because VRAM and
bandwidth limits are a legitimate concern (particularly for mobiles).
GPU su
On Thu, Oct 30, 2014 at 6:44 PM, Steve Fink wrote:
> Now there is %TypedArray%.prototype.fill. But I've become generally
> skeptical about it as an answer to performance concerns. I would rather
> see engines hyperoptimize
>
> for(var i=0; i
> based on observed type information. Which is not to
On Thu, Oct 30, 2014 at 1:41 PM, Allen Wirfs-Brock
wrote:
> Performance optimizatiuon in an implementation issues. That’s where you
> should apply performance pressure.
>
That's true, but if there's only bad APIs to do certain tasks, it doesn't
help.
_
The usecases:
*1) Filling with custom data*
When writing WebGL or physics or many other things todo with large
collections of data, it's not unusual to have to fill arrays with custom
data of some kind.
someArray.set([
> x0, y0, 1, 0, 0,
> x1, y0, 0, 1, 0,
> x1, y1, 0, 0, 1,
> x0, y0, 1, 0, 0,
On Fri, Sep 12, 2014 at 8:00 AM, Tom Van Cutsem wrote:
>
> While this refactoring may be tedious (no disagreement there), it forces
> you to review all affected code, which is good, because the dependencies of
> that code may have changed (i.e. side-effect the client previously thought
> would exe
er wrote:
> On Thu, Sep 11, 2014 at 7:22 AM, Florian Bösch wrote:
>
>> A -> B -> C -> D -> E changes to
>>
>> A -> B -> C -> D -> async E and causes
>>
>> A await -> B await -> C await -> D await -> async E
>>
&g
Furthermore, since await is call graph infectious, for those really wanting
to use it, it means that before long, await is written before every single
function call. Which makes no sense.
On Thu, Sep 11, 2014 at 4:22 PM, Florian Bösch wrote:
> A -> B -> C -> D -> E changes to
t just for those pieces of code that contain mentions of "bar", or
that reference code that contains "bar" to the Nth degree, you'd accuse me
of trying to introduce a purposefully unusable feature. How is await/async
not an unusable feature?
On Thu, Sep 11, 2014 at 4:00 PM,
await has also another problem in that if somewhere, deep down the call
stack, something is intending to do async, then up the entire call stack
everywhere you've got to insert await. It's a bit of a headache for code
maintenance (hello bicycle repair man jam session), and it's also fairly
unfriend
Python, Coffeescript and VB use the "is" operator for object identity, not
for instanceof like functionality. Dart uses the is operator analogous to
instanceof. It would seem to me it'd be beneficial to pick a different
operator name, in order to avoid the fuddled meaning this operator has
taken to
I'd like to point out a example where using different sources (from older
and newer versions of a language) inside one runtime environment is used
fairly successfully.
Each OpenGL version comes with a new version of the GLSL language, which
may break things. On top of my head this was the case in:
I'd like to point to the grand experiment of python 3 to introduce a new
language, that breaks with the old one. This didn't work out to be exactly
popular, and to this day, python 3 struggles to gain acceptance.
A major roadblock for python 3 is that you cannot combine it with python 2
modules. T
Well, it is a thread on bytecode, that had a discussion on bytecode, but
sure, whatever.
On Mon, May 19, 2014 at 4:07 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Mon, May 19, 2014 at 3:55 PM, Florian Bösch wrote:
>
>> So just so I get this straight. You&
.
On Mon, May 19, 2014 at 3:53 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Mon, May 19, 2014 at 3:46 PM, Florian Bösch wrote:
>
>> Well, if you're simply going to come up with a bytecode to match JS, then
>> you're gonna have the same kind
ly discuss what
that actually means.
On Mon, May 19, 2014 at 3:43 PM, Till Schneidereit <
t...@tillschneidereit.net> wrote:
> On Mon, May 19, 2014 at 3:32 PM, Florian Bösch wrote
>
>> Far as I see it, the discussion isn't really about bytecode. It's about
>>
On Fri, May 16, 2014 at 10:18 PM, C. Scott Ananian wrote:
> On Fri, May 16, 2014 at 12:49 PM, Mameri, Fred (HBO)
> wrote:
>
>> maintaining performance and debuggability would be nice. But for me,
>> the main benefit of the bytecode is having my engineering team be able to
>> adopt newer versions
I'd like highlight the fact that binary data handling in JS these days is
mainly done via ArrayBuffers and TypedArrayViews. To that end, I've written
a base64 to Uint8Array decoder like so:
https://gist.github.com/pyalot/4530137
I don't quite see how atob/btoa without a usable binary type (indexab
On Sat, Mar 8, 2014 at 6:10 PM, John Barton wrote:
> You may like to take a look at how the traceur compiler (
> https://github.com/google/traceur-compiler) works. It allows one to write
> code like
> var statement = parseStatement `${result}[${index}++] =
> ${expression};`;
> where the ${} s
On Fri, Mar 7, 2014 at 8:52 PM, Peter van der Zee wrote:
> I think you want to take a look at "source maps". They're specifically
> designed to deal with this problem.
>
The problem is that a function like compileShader would look like this:
var compileShader(source){
var shader = gl.createS
On Fri, Mar 7, 2014 at 8:36 AM, Claude Pache wrote:
> We precisely discussed templates on es-discuss tonight. If I believe what
> I just read on [1], you will be able to write:
>
Ah cool, sorry :)
A follow up question on that has to do with line number/column.
If you're doing things like this i
I'm sorry if that's been asked before (I looked trough the archives trough
to 2012 and couldn't find a thread on it).
Are there any plans on adding multiline strings?
Some examples of multiline strings below.
Lua:
foo = [[A
Multiline
String]]
Python:
foo = '''A
Multiline
String'''
Coffeescript
67 matches
Mail list logo
