01:00:12  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:10:00  * keith_millerjoined
02:07:58  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:36:58  * gsathyaquit (Ping timeout: 256 seconds)
02:38:11  * gsathyajoined
03:47:54  * gibson042quit (Quit: Leaving.)
04:44:07  * ningujoined
04:48:08  <ningu>hi, srl295 said I should mention that I just wrote (read: hacked together) this interface to ICU's rule based transliterators and number formats: https://github.com/longnow/node-icu-transliterator
04:49:09  <srl295>^ don’t think there’s an issue for this yet in 402
04:49:58  <ningu>I wrote it because no one else had, not because I thought I was the best person to write it in the best way. happy to take suggestions or take pull requests or whatever
04:58:35  * zsocjoined
04:58:40  * jmdyck1quit (Remote host closed the connection)
05:03:59  * Havvyjoined
05:20:19  * AtumT_joined
05:23:08  * AtumTquit (Ping timeout: 256 seconds)
05:33:49  * AtumTjoined
05:35:00  * AtumT_quit (Ping timeout: 260 seconds)
05:44:34  <devsnek>ningu: thats pretty cool
06:05:07  * ninguquit (Quit: Lost terminal)
10:25:28  * mylesborinsquit (Quit: farewell for now)
10:25:58  * mylesborinsjoined
12:42:22  * jmdyckjoined
14:20:57  * regaddijoined
14:58:25  * Fishrock123joined
15:08:13  * keith_millerjoined
15:30:29  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:33:58  * keith_millerjoined
15:47:24  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:12:37  * cloudshujoined
16:15:46  * keith_millerjoined
17:23:59  * jwaldenjoined
17:54:27  * Fishrock123quit (Remote host closed the connection)
17:59:30  * Fishrock123joined
18:22:06  * nin-jinjoined
18:25:50  <nin-jin>Hello, what do you think about this feature? https://gist.github.com/nin-jin/5408ef8f16f43f1b4fe9cbcea577aac6
18:26:40  <devsnek>its been suggested before
18:27:48  <nin-jin>Where can I see results?
18:28:34  <devsnek>wdym results
18:29:34  <ljharb>nin-jin: you should search es-discuss for a discussion on nonblocking json parsing
18:29:59  <ljharb>nin-jin: and there's current proposals for blöcks, and also atomics, that you'd want to build off of
18:31:35  <nin-jin>ljharb, json example demonstrates using fibers with non asynchronous api which takes callbacks. It can be Array.reduce and others.
18:32:15  <ljharb>nin-jin: you should read the discussion. i think it talks about why json parsing can't be done except synchronously
18:32:17  <nin-jin>devsnek, some conclusion of discussion.
18:32:56  <devsnek>i dunno if coro/fibers/threading/etc has ever been like officially proposed
18:33:08  <devsnek>but it gets discussed by lots of people
18:33:15  <ljharb>i also don't think there's consensus that we want it.
18:33:16  <devsnek>webkit had this nice blog post a while ago about it
18:33:44  <devsnek>did they every bring that strawman to a tc39 meeting
18:33:50  <ljharb>nope
18:33:53  <devsnek>weird
18:33:55  <ljharb>it wouldn't go well, i suspect
18:35:09  <nin-jin>devsnek, could you provide a hyperlink to this post?
18:35:17  <devsnek>https://webkit.org/blog/7846/concurrent-javascript-it-can-work/
18:35:41  <devsnek>they propose a thread api not a fiber api but
18:35:45  <devsnek>i think the sentiment is the same
18:36:08  * bradleymeckperks up and then hides again
18:36:14  <devsnek>lol
18:36:39  <bradleymeck>the locking needed to do their proposal is... comprehensive from my rudimentary investigation
18:38:10  <devsnek>if you passed objects between the thread explicitly and they became shared
18:38:24  <devsnek>then again prototypes
18:58:06  <nin-jin>So, how add my proposal to stage-0?
19:23:10  * Fishrock123quit (Remote host closed the connection)
19:33:31  * Fishrock123joined
20:07:16  <ljharb>nin-jin: you'd have to have a committee member champion it.
20:15:09  <nin-jin>How?
20:31:37  <ljharb>nin-jin: convince someone it's developed enough, worth solving, and who has the time to champion it
20:32:42  <akirose>nin-jin: you'l' notice that anyone in this channel with a +v is a TC39 delegate. those are your targets to convince ^_^
20:40:25  <nin-jin>My english is very bad. I don't understand "you'l'" and "+v". What is it?
20:41:04  <nin-jin>Could someone review my proposal and give me feedback? https://gist.github.com/nin-jin/5408ef8f16f43f1b4fe9cbcea577aac6
20:41:54  <nin-jin>I don't understand why fibers isn't implemented yet as in other mature languages.
20:43:45  <ljharb>nin-jin: "you'll" is a contraction for "you will", and `+v` is the "voiced" mode in IRC - there's 23 of us voiced in this channel right now, compared to 69 unvoiced
20:44:06  <bradleymeck>nin-jin: i think a decent amount of why is that generators can serve this purpose while being explicit about when yielding may occur
20:44:20  <bradleymeck>lua is my main experience here, though some with python and d
20:44:51  <bradleymeck>the single threaded message passing nature of JS doesn't lend itself to people who have written code that is safe to yield within
20:45:37  <bradleymeck>I wasn't at the decision making process, but explicit locations for yielding seemed a good compromise so that people can clearly expose where the stack can be paused
20:52:00  <nin-jin>Thank you for explanation.
21:02:56  <nin-jin>Use case: yielding every 16ms for 60fps. With generators (async functions) we need to convert **all** functions and methods to generators. So this explicitness is drammatically useless. People, who don't understand how to use fibers - can don't use fibers. But most of developers who want simple and responsive code - need this feature. This is developers of React, Carberry, $mol, Glimmer, Meteor etc etc.
21:03:19  <ljharb>nin-jin: what's the actual use case tho
21:03:26  <ljharb>"yielding" doesn't tell me why you want to do it
21:03:39  <ljharb>doesn't requestAnimationFrame, setTimeout, etc, allow you to do that?
21:07:30  <nin-jin>Calculation can spend more then 16 ms, so we need to sleep to allow browser update view and handle events. This this example of fibers emulation: http://mol.js.org/fiber/
21:08:09  <ljharb>nin-jin: sure but you can calculate in a web worker
21:08:52  <ljharb>and you can use Atomics to "sleep" the main thread
21:09:07  <nin-jin>I can't modify DOM in web worker.
21:09:36  <ljharb>modifying dom isn't calculations
21:10:02  <nin-jin>All what computer do is calculations :-)
21:10:07  <ljharb>well, it's not pure math i mean
21:10:15  <ljharb>and modifying the DOM always has to be single-threaded afaik
21:11:53  <devsnek>wasm is supposed to have threads iirc
21:12:08  <nin-jin>Compare flame charts of rendering: https://nin-jin.github.io/slides/fibers/flame-chart.png
21:12:08  <devsnek>direct shared memory between workers maybe?
21:12:12  <devsnek>i don't remember exactly what it was
21:15:37  <ljharb>nin-jin: performance in some cases tho, isn't enough to justify adding a language feature if it would break existing invariants, or if it would be very easy to misuse it
21:17:15  <nin-jin>Workers have some limitations: cost of (de)serialization, events can't be processed in worker (because async communacation), cost of worker start (we can't run every computation in separate worker), API limitation(DOM, CSSOM, Canvas, GeoLocation, History, Location, XMLHttpRequest.responseXML, Window)
21:20:55  <nin-jin>So, without native fibers we ($mol, React) have to emulate it through Promise throwing. It has more misuse cases.
21:21:43  <devsnek>you could use wasm
21:22:05  <devsnek>and at a granularity of 16ms the cost of html structured clones isn't really a big deal
21:25:04  <ljharb>nin-jin: if you're going to use React as a motivator, you may want to get the react core team onboard - they're on TC39 as well
21:26:17  <nin-jin>I can't render DOM from WASM. I can't force my users to write all they code in WASM.
21:26:26  <bradleymeck>nin-jin: I think part of the problem is you need to convince people that implementing this feature won't affect people who don't use the feature, if someone writes code not expecting a yield within a function they call, it could be problematic
21:26:50  <bradleymeck>so even if you don't use the feature, you need to account for the possibility that values you are provided do use the feature
21:27:10  <ljharb>nin-jin: specifically, much of my code relies on everything being single-threaded and run-to-completion, so it'd be critical not to break that
21:28:31  <bradleymeck>idk if it is critical, but it needs lots of talk about how to handle it at minimum which will be a long talk
21:30:32  <ljharb>it would break a large part of the web, i suspect.
21:30:42  <ljharb>webkit's blog post implies it wouldn't, but i'm not convinced yet
21:33:47  <nin-jin>No it can break only code that relies on stack and global variables together. In example: $mol_atom, lom_atom, MobX, CellX, KnockOut - all its uses global variables to provide stack-bound context. Its should be patched to use fibers-bound context.
21:35:56  <ljharb>sure. that's lots of code.
21:36:07  <ljharb>nin-jin: for example, tons of code relies on Promise or Array, which are globals
21:36:29  <ljharb>and it's both important that unexpected mutations not be allowed, and also that expected mutations be allowed (think polyfills/shims)
21:40:40  <nin-jin>Could you provide a realistic example that can be broken?
21:41:23  <nin-jin>So no one force you to launch in fiber libs that is not compatible with fibers.
21:41:48  <nin-jin>Just don't use it if not sure.
21:44:45  <ljharb>that's not an option; browsers often run code outside your control
21:45:14  <ljharb>as long as existing code runs first, it should be able to protect itself against any code running after it breaking it
21:46:00  <bradleymeck>nin-jin: `setTimeout(()=>{ee.emit('start')},0);thing_that_yields();return ee;`
21:46:37  <bradleymeck>the problem is `thing_that_yields` can be ~= anything if proper coroutines exist since it is just possible to do that from any function
21:48:03  * Fishrock123quit (Remote host closed the connection)
22:00:11  * Fishrock123joined
22:41:51  * Fishrock123quit (Quit: Leaving...)
23:45:10  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)