2019-02-01 [20:20:35.0000] is there any way to access AsyncFromSyncIteratorPrototype [20:20:44.0000] i've tried various hacky throw techniques but i can't seem to get at it [20:53:38.0000] devsnek: test262 doesn't seem to know how to get to it https://github.com/tc39/test262/blob/ee3715ee56744ccc8aeb22a921f442e98090b3c1/harness/wellKnownIntrinsicObjects.js#L46-L47 [20:53:59.0000] yeah i'm stumped [20:54:40.0000] https://github.com/tc39-transfer/proposal-iterator-helpers/blob/master/polyfill.js#L21 [20:55:18.0000] devsnek: btw by line 12 there do you mean this very question? [20:55:23.0000] because it does have GetIterator [20:55:43.0000] ljharb: GetIterator changed in es2019 [20:55:57.0000] it returns an IteratorRecord instead of the iterator object itself [20:56:01.0000] will change :-) 2019 isn't out yet [20:56:02.0000] gotcha [20:56:10.0000] https://github.com/ljharb/es-abstract/blob/master/GetIntrinsic.js#L60 i don't know how to get to it yet either, ftr [20:56:14.0000] yeah i'll remove all that stuff when es2019 gets finished up [21:25:09.0000] The spec is moving faster it seems. Kind of making me worried. [21:25:50.0000] Sirisian: that seems kind of vague. what are you worried about? [21:26:07.0000] it's improving faster, that's for sure, totally separate from proposals [21:26:16.0000] yeah [21:26:21.0000] but a lot of that is just "being on github" [21:26:43.0000] That something will be added that breaks my type proposal for good. I've been keeping an eye on rbuckton's enum proposal and a few other threads lately. [21:27:27.0000] This might motivate me to learn how to write algorithms in the spec. [21:28:24.0000] imo i don't think a language addition is going to be the thing that makes types unlikely to ever be added to JS [21:29:13.0000] even to start, any such proposal would likely have to have the enthusiastic endorsement of the flow and TS teams [21:29:55.0000] not trying to discourage you :-) just to set expectations based on what i've observed [21:31:22.0000] I find it ironic that ECMA's tools are all written in TS :| [21:32:33.0000] that's just the personal choice of some of the various maintainers [21:32:41.0000] node certainly isn't :-) [21:35:14.0000] even if ts and flow agreed, i don't think types would be up for discussion [21:35:27.0000] they don't really make sense at the interpretation level [21:36:21.0000] right, that'd just be a (very difficult) start [21:36:29.0000] That's one thing I've wondered about for a while. If an interpreter or JIT could meaningful use them. [21:36:47.0000] meaningfully* [21:37:50.0000] well we have some data on that from asm.js [21:37:57.0000] and the answer seems to be "kind of" [21:38:29.0000] the overhead of parsing and verifying all the types generally is more of a concern than the correctness of the code [21:38:41.0000] since you can move the correctness checks to build time [21:40:05.0000] https://groups.google.com/forum/#!topic/strengthen-js/ojj3TDxbHpQ <-- I found this a while ago. It's all I've had to go off of. [21:41:07.0000] I don't want to bother him though. He seems busy. [21:41:27.0000] Sirisian: strong mode got dropped, from my understanding, because it didn't provide enough benefit based on actual code on the web [21:42:28.0000] yeah, the idea of such a mode was debated way before that also. I removed it from my proposal ages ago. There's a good post on esdiscuss on "modes" not being a thing anymore ever. [21:42:36.0000] in today's engines it could have some benefits, but there are still a lot of weird semantics issues [21:42:45.0000] like strong classes interacting with normal mode code [21:51:38.0000] I'm still not 100% sure I understand the concept of a "strong class". I always think it means like freezing the class and the whole prototype chain such that it's simpler? [21:53:37.0000] oh right that description says sealed in the link. I created this a while ago. https://github.com/sirisian/ecmascript-types/issues/29 I have no idea how engines work though or how it would/could benefit. [23:44:36.0000] wasn't there a compiler that would compile type declarations into runtime assertions? đŸ€” [23:51:29.0000] `final` and `sealed`'s meanings in Java/C# are likely because it also affects dynamic dispatching (converts dynamic dispatches into static dispatches) [00:03:26.0000] My dream is where everything that can is using static dispatches. Also hopefully allowing engines to inline code heavily. [00:14:45.0000] bterlson, has anyone brought up changing tables in the spec to CSS grid? There's only 79 of them, so it's probably not a huge deal. They're kind of verbose. [02:52:18.0000] littledan: so basically, private state stays at Stage 3 and is now truly considered the way forward? (re tweets) [02:54:10.0000] That's what I would say [02:54:46.0000] So, this might strengthen the case for Domenic's per realm brand check proposal [02:55:42.0000] I really can't imagine how polyfills would be able to orchistrate non-forgeable cross realm brand checks in practice [02:56:14.0000] You have to polyfill Realm allocation too! [02:56:31.0000] I mean, cross-global [02:56:31.0000] Pointer to that proposal btw? [02:56:41.0000] littledan: yeah me too [02:56:52.0000] Well, it's more like scattered comments in the WebIDL tracker [02:57:03.0000] Probably we should make a more solid proposal [02:58:03.0000] Not sure if Ms2ger might be interested... [03:00:50.0000] littledan: I haven't looked at this in a while, but I guess a subclass doesn't get access to private state of the parent? [03:02:08.0000] littledan: somehow when we design APIs we do grant ourselves that ability (for host-defined subclasses), but not consumers (for user-defined subclasses), which makes sense, but is a little weird, but I guess it can be explained somehow [03:03:08.0000] Well, you can cook yourself up that behavior, it's just a bit obscure. Decorators will improve the ergonomics , and maybe we will have some kind of private declarations for another approach [03:04:00.0000] This particular form of decorators got some criticism at TC39 meeting, but my feeling is the committee remains committed to meeting the use cases [03:04:10.0000] littledan: okay, glad you're all on it 😃 [03:04:18.0000] We just might have to make some tweaks [03:04:45.0000] (they may be big tweaks, it's unclear at this point) [03:05:04.0000] We aren't ready to lay it out in a tweet storm yet, that's for sure [03:05:07.0000] It's mostly comforting to know that the object design being done in hosts is considered [03:05:33.0000] Yes, very much so. I think a lot of us share a vision that these things be aligned [03:06:21.0000] (though I couldn't say everyone believes the current web is JavaScripty...) [03:07:42.0000] heh [03:10:20.0000] Btw the per-realm brand checks are based on the current, not relevant realm, in that the method closes over the realm, and it's not based on the receiver [03:11:03.0000] I'm not sure how we can work out the current vs relevant issue in the web; TC39 is fairly strongly on the "current" side where it makes sense [03:11:29.0000] (and so am I, personally) [03:11:48.0000] Async methods return a Promise in the current realm [03:12:02.0000] I think the main problem is that when you allocate multiple objects through a single allocation you can end up with objects from different realms? [03:12:10.0000] When? [03:12:23.0000] I think that's what bz demonstrated somewhere [03:14:25.0000] Perhaps once JavaScript has native support for multiple realms in an agent it'll feel this more [03:14:25.0000] OK, I'll try to find that [03:14:27.0000] Or maybe not [03:15:00.0000] I am not sure, it depends what we end up for the meaning of multiple realms in an agent [03:15:20.0000] There is some discussion of realms sharing a global (in which case I don't actually understand what a realm is) [03:15:20.0000] Hopefully it's not incompatible with similar-origin window agents! [03:16:24.0000] I will make sure we have this analogy represented when things get more concrete [03:16:50.0000] I suspect Mark Miller is involved? He should know... [03:17:26.0000] Well, Mark has talked about all sorts of different ideas [03:17:36.0000] I don't know which one they want to push forward [03:17:47.0000] hah [08:53:13.0000] leobalter: is Float16 still a thing you wanna do? [08:54:18.0000] leobalter: it could help with https://github.com/whatwg/html/pull/3882 if added [09:56:00.0000] Has there ever been talk within TC39 of standardizing packages made of multiple ES modules, as a way of exposing some modules and hiding others? After all, Class methods can be made private, class methods can be made private, and objects can be exported, but modules today must always be externally visible, even if they’re not meant to be part of a public API... [09:56:31.0000] Whoops, mistakenly repeated a phrase there. [09:59:04.0000] jschoi_: like a parse mode made up of multiple es modules? [10:02:52.0000] More like some kind of way of coupling ES module files with a manifest, Ă  la package.json that controls access to its constituent modules. Cf. Java packages. Such a system could allow compression of multiple module files plus a manifest into a single file, Ă  la JAR files, but I’d care most about the module access control. [10:03:52.0000] isn't that just rollup/webpack [10:05:48.0000] Yes, those essentially do that. But I was wondering about whether TC39 members have been thinking about standardizing module access control in ES itself, after reading https://github.com/tc39/proposal-dynamic-import/issues/35. [10:06:52.0000] like flipping a flag on a module to say whether it can be imported or not? [10:08:46.0000] With Node I usually use index files where I export what I want to be public. I suppose this doesn't work with the regular ESM resolution algorithm? [10:09:00.0000] Yeah, essentially. Modules declare what things they export and what things they keep private, but there is no way to keep a module itself private to within its library, whatever “library” might mean. After all, it is common to split libraries into internal modules that are only meant to be used by the implementation. Other languages have grappled with the same problem in different ways, and I wonder if the problem has been [10:09:00.0000] on TC39’s radar while crafting the module system. [10:09:11.0000] well js doesn't have a concept of filesystem [10:09:16.0000] ESM resolution itself is platform dependent. [10:09:24.0000] As devsnek says. [10:09:50.0000] this sounds like part of the environment specific resolution system [10:10:01.0000] we're actually working on something very similar to what you're saying in node [10:10:13.0000] a field in package.json which says which things you can deep import [10:11:47.0000] Yes, I’ve been watching that good work. But the concept of combining packages module access control would be something that I think might benefit from language-wide standardization...Come to think of it, TC39 has already been pushing around the idea of module maps; I don’t remember if it deals with access control though. [10:12:55.0000] module map is just something that implicitly exists when you link modules together [10:13:32.0000] I mean https://github.com/WICG/import-maps. [10:13:53.0000] I need to reread this. [10:14:20.0000] ah [10:14:25.0000] that's for the web [10:14:33.0000] not for js itself [10:14:56.0000] Yes, that’s right, [10:15:00.0000] Whoops, haha. [10:15:01.0000] (and its likely node would also support the format) [10:15:29.0000] I realized that as soon as I saw that it was now in WICG’s namespace... [10:17:21.0000] In any case, this deals with bare imports anyway and doesn’t block `import "library/private-implementation-logic.mjs"`anyway. [10:20:30.0000] An allowlist of module specifiers at the beginning of a module might also work... [10:22:42.0000] Anyways, it’s a real problem: As the writers of the private-methods proposal often say, if it’s exposed publicly, people will rely on it, and it’s essentially part of your public API. The same goes for internal modules. [10:24:08.0000] Also that should have been `import "./library/private-implementation-logic.mjs"`. [12:48:19.0000] who should i talk to about enabling travis for tc39/proposal-iterator-helpers [13:18:11.0000] devsnek: i believe it should just be on if you add a travis.yml, no? [13:19:30.0000] ljharb: oh I guess I can try that [13:19:57.0000] I was trying to set up the key signing stuff and travis cli was giving errors [13:40:06.0000] ljharb: looks like it needs to be manually turned on by someone with admin perms [13:57:54.0000] devsnek: ah ok, i'll get that taken care of [13:58:01.0000] thx [14:38:22.0000] /me anxiously refreshes https://tc39.github.io/proposal-iterator-helpers [14:39:48.0000] Domenic: shouldn't it be https://tc39.github.io/proposal-iterator-helpers/spec.html [14:40:05.0000] I sure hope devsnek has not done such a weird thing [14:40:24.0000] its index.html [14:40:28.0000] there just hasn't been a valid build yet [14:40:34.0000] travis was being weird [14:40:35.0000] https://github.com/tc39/proposal-iterator-helpers/blob/master/package.json#L5 [14:40:44.0000] ah
 [14:40:58.0000] the next push will be the first build [14:41:04.0000] I find GitHub pages often takes some time to realize that it should be working [14:41:14.0000] `git commit --allow-empty` time? [14:41:17.0000] Even if the branch exists there's some caching layer that doesn't get invalidated [14:41:54.0000] hmm https://travis-ci.com/tc39/proposal-iterator-helpers [14:42:23.0000] oh what [14:42:26.0000] its on travis-ci.org [14:42:42.0000] oh lol [14:42:51.0000] why is it on .org though [14:43:00.0000] eh https://travis-ci.org/tc39/proposal-iterator-helpers/jobs/487675625#L495 [14:43:03.0000] every other repo is on .com [14:43:18.0000] looks like it was running on Node.js v0.10 [14:43:20.0000] doesn't count, travis tried to use node 0.10 to build [14:43:21.0000] yeah [14:46:16.0000] alright lets try this [14:48:10.0000] Domenic: https://tc39.github.io/proposal-iterator-helpers/ [14:48:18.0000] yay! [14:48:36.0000] all that for a single method on iteratorprototype [14:49:24.0000] Nice [14:49:38.0000] What is the deal with the IteratorClose? [14:49:49.0000] (Also _iterator_ is not a declared variable; maybe you mean _iterated_ or _O_) [14:51:04.0000] it calls return when the iterator finishes [14:51:25.0000] But why though [14:51:41.0000] ask whoever designed iterators [14:51:43.0000] (I'm honestly asking; I don't understand return() very much) [14:51:57.0000] afaik it exists for generators [14:51:59.0000] But like isn't it only supposed to do that if the completion is "abruptish" [14:52:06.0000] "The abstract operation IteratorClose ... is used to notify an iterator that it should perform any actions it would normally perform when it has reached its completed state:" [14:52:59.0000] Hmm it is used in more places in the spec than I would have guessed hmm [14:53:19.0000] No but like in https://tc39.github.io/ecma262/#sec-array.from it's only used when there's an error [14:53:35.0000] It isn't used if you get to the end normally [14:54:09.0000] aha [14:54:37.0000] so that means... every ? call probably needs to defer to that now [14:54:46.0000] Yeah... or maybe just the Call() to the mapper? [14:54:53.0000] Like Array.from doesn't do IteratorClose() if IteratorStep() throws [14:54:58.0000] devsnek: should've prototyped in engine262 [14:55:13.0000] lol [14:55:21.0000] build times though [14:55:32.0000] are you presenting today? [14:55:47.0000] no it was presented yesterday [14:55:56.0000] oh [14:55:59.0000] and the meeting ended yesterday [14:56:04.0000] ah [14:56:17.0000] its always tue/wed/thu 2019-02-02 [18:58:51.0000] devsnek: you should write down the "if .throw or .return is called on an iterator produced by one of these iterator methods, it calls that method with the same argument on the underlying iterator" behavior somewhere that isn't the spec [18:59:12.0000] for Object.fromEntries I had a `DETAILS.md` where I wrote down design decisions of that type, so that they'd be easier to identify and review [18:59:44.0000] ok [19:00:04.0000] btw is that more of an opinionated choice than i imagined it to be? [19:08:32.0000] No, probably not. [19:09:30.0000] That is, it's almost certainly right, unless I'm missing something. It's just not something I'd thought about and I needed to stare at the spec for a moment to think about what was going on, and I like to have those things written down. [19:14:48.0000] bterlson, https://github.com/bterlson/ecmarkup/issues/152 I made an issue. mmm elegant. [19:22:36.0000] Sirisian: that takes td items based on the th declared? [19:22:46.0000] yes, magic [19:22:53.0000] took me a minute to figure out [19:23:24.0000] ah, I can probably add a note for that. [19:27:01.0000] I'm adding all the Symbol.operators from my proposal into the tables. This is so verbose. [19:27:21.0000] Symbol.operators [19:29:34.0000] yes, great evil. https://github.com/sirisian/ecmascript-types#classes-and-operator-overloading wcgw [19:30:17.0000] i still don't get why this isn't better suited for build time đŸ€· [19:30:34.0000] you can do more powerful type checks with more time [19:30:42.0000] build time? [19:31:36.0000] yeah [19:31:43.0000] types usually happen at compile time [19:32:55.0000] Sirisian: btw simd was explicitly moved to wasm land [19:33:15.0000] As in ECMAScript can never have it? [19:33:56.0000] I asked about that before and was told by others that wasm isn't designed to replace ECMAScript. [19:34:22.0000] Wait, can ECMAScript use wasm? [19:34:30.0000] ecmascript has no concept of wasm [19:34:42.0000] oh, I thought I missed something. Got excited. [19:34:48.0000] but the people working on the simd api moved all their efforts to wasm [19:39:38.0000] I was hoping when that's finalized it would be more refined for an inclusion into ECMAScript. I mostly just added it to think about language features. Would be nice for math library performance though. Always found matrix operations to be disappointingly slow. Also I think my implementation with types will be cleaner. No accidental conversions to Number and other weird things. [22:57:40.0000] There's no harm if operator overloading is added to allow static operator overloading right? class A { static operator +=(value) { this.constructor.x += value; } } A.x = 0; A += 5; Seems deceptively simple. Makes the grammar change straightforward. http://sirisian.github.io/ecmascript-types/#prod-MethodDefinition I can pitch it to a champion later as "ECMAScript now with more powerful singleton features." Developers love those. [22:59:35.0000] Sirisian: operator overloading has brought up lots of concerns from implementors that it would make *every* operation in the language slower [22:59:47.0000] plus it's not a given that everyone *wants* that feature. [23:00:43.0000] That would be bad. I'm trying to make every operation faster. :| [23:02:22.0000] Operator overloading without a type-checked step means that every operator suddenly becomes less predictable than `==`. [23:02:34.0000] The only reason I want operator overloading is for math libraries. Oddly enough that's all it's generally used for in other languages. Except C++. Those guys are insane. They were right to be wary to add it there. [23:05:34.0000] Sirisian: `a.add(b)` can already be done [23:05:41.0000] Sirisian: or `a['+'](b)` [23:06:04.0000] or ``` math`${a} + ${b}` ``` perhaps [23:06:06.0000] Meaning it's not a concern? [23:06:18.0000] meaning that the tradeoff might not be worth it to add syntax for it [23:06:51.0000] Trust me. I have a ton of math libraries written without it and code. It's a pain. [23:07:28.0000] fair, but if it's going to slow down all the non-math libraries, that's going to be a hard sell [23:08:09.0000] Indeed. [23:08:18.0000] If it slows down the math libraries, it's going to be an even harder sell. ;) [23:09:37.0000] ha, true [11:10:07.0000] should apis check the arguments passed or the validity of the receiver first [12:06:56.0000] Receiver is the precedent I believe [13:30:50.0000] +1 to that [13:31:10.0000] (i think of the receiver as an implicit first argument, so it comes before all the arguments) [15:09:33.0000] I'm not sure I'd want operator overloading, and I've written some mathsy JS code that would have benefitted from it syntactically.. 2019-02-03 [09:26:03.0000] in https://weakrefs.netlify.com/#sec-keepduringjob [09:26:26.0000] why doesn't this give explicit semantics for keeping a set of data on an agent which is cleaned up in RunJobs or something [09:26:47.0000] or explicit semantics adding a set to jobs or whatever 2019-02-04 [11:09:28.0000] Heh, the `math` tag function. Is there anything tagged templates *can't* do? [11:10:29.0000] That does offer... intriguing possibilities for typedOM. cssMath`${el.styleMap.get('width')} + 5px`, anybody? [11:16:51.0000] https://twitter.com/tabatkins/status/1092502187387670528 [11:18:44.0000] TabAtkins: generically have proper syntax highlighting for your arbitrary DSL? [11:19:24.0000] "generically" no. Just recognizing that a tagged string whose tag is named "js", "html", or "css" is likely to be at least *similar* to those languages, enough that highlighting will be useful. [11:19:39.0000] perhaps, but brittle [11:41:58.0000] Vaguely related: the set/get dance to update a value in a Map is annoying. I'd like to fix this for CSS by adding a `update(cb)` method that takes an `oldval=>newVal` callback, so `obj.update('width', old=>old.add(CSS.px(5)))` is the same as `obj.set('width', obj.get('width').add(CSS.px(5)))` [11:43:33.0000] Looking over the Collection Methods proposal, doesn't look like this method exists yet. Any history I should look at before I open an issue? [13:01:22.0000] TabAtkins: I've though about proposing `emplace` (insert if missing), but haven't gotten around to it [13:02:13.0000] we had some talks at last meeting about a variety of things around collections, did seem like some people felt OOP protocols should be invoked for new methods and it caused some friction [13:02:14.0000] That's a different method than what I'm asking for; yours is `setdefault` from Python, right? (A `get`, except it first sets it to the provided default value if it's missing.) [13:02:34.0000] TabAtkins: yes, similar but quite different [13:03:08.0000] the big thing for me is when people argue for calling into OOP hooks using things like .add/.set do in the constructors [13:03:43.0000] that gets really complex if you model it after that, but at the same time subclassing is extremely fragile if you don't [13:10:40.0000] Yeah, as I said in IRC during the meeting, I'm very much for making sure that new methods don't break on subclasses; it sucks if you have to reimplement the entire (gradually growing) suite of built-in methods just to subclass a simple collection class, when the new methods could be built on top of the core methods instead. [13:10:54.0000] But I"m also sensitive to the "we can do it more efficiently if it's custom" argument. :/ [13:11:47.0000] Really feels like protocols are the answer here; a Maplike protocol that depends on some core methods, and provides all the additional methods, but allows custom overriding when necessary. Then you don't need to subclass and worry about the Map-specialized code doing bad things for your subclass. [13:17:18.0000] When does subclassing beat protocols? [13:38:03.0000] annevk: when the protocols already exist subclassing is relatively nice if it can be built upon them [13:39:22.0000] TabAtkins: rekey (now toValue/toKey) took a similar approach on letting you push the logic of core protocol like methods up to the language, i'm not 100% sure on the symbols based approach i've seen elsewhere these days 2019-02-05 [06:24:15.0000] ystartsev: mmm how do I run notes_explorer? its been soo long since I've done prolog that I've forgotten, it seems I need to use load_note -> inspect_discussion ? [06:24:36.0000] yes [06:24:41.0000] do you have swipl installed? [06:25:07.0000] yup [06:25:34.0000] so the basic command is swipl notes_explorer/notes_explorer.pl [06:25:42.0000] if you are in the tc39 notes repo [06:25:49.0000] this will get the environment set up [06:26:06.0000] rlwrap is to make swipl less annoying [06:26:49.0000] then you can load a note, for example: load_note("./es9/2018-11/nov-28"). [06:26:53.0000] this is probably what is wrong [06:26:58.0000] i got the date wrong in the slides! [06:27:22.0000] slides are now fixed bradleymeck ^ [06:27:51.0000] once that works, you can try loading a note using the following: print_info. [06:27:59.0000] it will just print all info thats been loaded so far [06:28:17.0000] from there you can grab a discussion name or a value and inspect its relationship to other things [06:28:28.0000] (i will make the user experience better soon) [06:28:37.0000] (i will also stop abusing format soon 😰 [06:29:31.0000] i wrote the entire thing in one sitting so it isn't perfect -- let me know any issues you run into [06:29:35.0000] i also haven't written all of the viewers [06:34:14.0000] what is notes_explorer [06:34:51.0000] its an experimental .... thing? ... i think thing is the best word .. that combs the notes and creates relationships between discussions [06:35:36.0000] its here : https://github.com/codehag/tc39-notes [06:35:44.0000] its basically a prolog program that looks for tags that I add to the notes [06:37:23.0000] ystartsev: what are the args to print_info, [In/Ins] doesn't seem to take a .md filepath string? [06:37:31.0000] it doesnt take args [06:37:34.0000] it just prints everything it has [06:37:47.0000] oh wait a sec, maybe i got something wrong [06:38:13.0000] ah sorry the cmd is write_to_text. [06:38:17.0000] not print_info [06:38:21.0000] print info is more general [06:38:25.0000] i got the slides wrong, sorry [06:38:46.0000] i updated them again [06:39:01.0000] you can also use write_to_dot. or write_to_json. [06:40:56.0000] i will write up the readme properly in a few days when i have a moment [06:41:19.0000] but if you know prolog, and you load the note -- you can start playing with that world as you like [06:41:22.0000] prolog though [06:42:11.0000] example: findall(X, lookup("Expression", X, tension("Expression, X)), Tensions), print(Tensions). [06:42:15.0000] i really like prolog [06:42:20.0000] its easy to prototype in [06:42:45.0000] you just throw things at it, and its like "oook sure". as long as you dont make any mistakes that is :| [06:42:50.0000] the errors are something else [06:43:11.0000] i messed up typing, should be findall(X, lookup("Expression", X, tension("Expression", X)), Tensions), print(Tensions). [06:43:22.0000] im treating prolog as a relational database and parser [06:43:38.0000] its just for the prototype [06:45:44.0000] html spec builder is also prolog [06:45:46.0000] maybe i should learn it [06:45:50.0000] its fun! [06:46:08.0000] really, the main issue with it is that it gives the most misleading errors [06:46:25.0000] for example, i wrote an assembler in it, and i kept running out of memory [06:46:37.0000] i thought it was because i was compiling an operating system in it and i was just really inefficient [06:46:38.0000] nope. [06:46:41.0000] i had a typo [06:46:50.0000] i've been trying to write an assembler [06:46:57.0000] (nothing that could compile an os) [06:47:17.0000] so i wrote one for a fake machine: https://github.com/codehag/asm_in_prolog [06:47:28.0000] its a 16 bit machine, from the course nand2tetris [06:47:37.0000] if you want to build a computer from scratch, i can recommend that course [06:47:38.0000] i think i'm getting the ops wrong though cuz trying to run the machine code always segfaults [06:48:46.0000] if you are writing for a specific architecture it might be harder -- the 16 bit machine i was working with is quite limited and it made it easier to find my way around [06:49:00.0000] the second half of the course is building the OS that you can compile using that assembler [06:49:15.0000] you also write a compiler for a java like language, and then a game in the java like language [06:49:19.0000] the teachers are really good [06:49:31.0000] i was just trying to emit some x86 [06:50:32.0000] hm, thats much more complicated than what i was doing! [06:50:48.0000] what machine were you working with [06:51:01.0000] its a virtual machine that you build. they call it the HACK computer [06:51:32.0000] they take you through hardware design and you build it yourself from first principles [06:51:54.0000] sounds fun [06:52:12.0000] this is the course: https://www.nand2tetris.org/ [06:52:24.0000] ystartsev: sent PR with README based upon what ya taught me here [06:52:36.0000] thank you bradleymeck ! [06:53:21.0000] i'll take a look at this [06:53:50.0000] devsnek: they have a version of it on coursera as well [06:54:43.0000] but everything is available on their website, so whatever your learning style is is the one you should go with [09:08:42.0000] ystartsev: that always sounded like a neat course indeed [10:33:36.0000] littledan: i was thinking of floating a patch with the web compat hack for the override PR to see a less skewed usage counter, does that make sense? [10:34:20.0000] what do you mean, floating? [10:34:21.0000] i see you just closed it, but the usage counter was pretty wildly out of the norm and largely appeared to be due to 1 library so I'm not convinced it is as dangerous as it may seem at first glance [10:34:40.0000] littledan: node can float a v8 patch and flag to see how much breaks [10:34:42.0000] yeah, that might be the case, but I'm not sure [10:34:51.0000] right now lodash breakage makes usage counters useless [10:35:11.0000] I don't understand what you mean by "useless"; they reflect lodash [10:35:18.0000] doesn't really say much about anything outside of that and it is unclear how much breaks due to lodash's change [10:35:23.0000] there was no V8 patch to change the actual semantics, just to count how often it occurred [10:35:51.0000] to make more progress here, i'd recommend implementing these other semantics, and one or more of these additional fixes, and surfing around to see what breaks [10:36:02.0000] littledan: the usage counters are biased around a bug in older lodash that shows massive breakage if you don't do a compat hack around lodash [10:36:35.0000] I understand that, but I don't know for sure that there aren't other widely used libraries that hit similar issues, but for which the tweak doesn't fix it [10:36:41.0000] littledan: yes, floating the web compat fixes for the older lodash should make the actual impact of the change clearer [10:36:43.0000] at this point, i feel like we should've done a bit more "surfing around and seeing what breaks" before landing the usage counter [10:37:05.0000] so, is someone interested in doing this V8 programming, and then locally running a hacked-up version of Chrome and testing various things? [10:37:09.0000] that's what I'd recommend next [10:37:16.0000] that line of code is not clear just reading the src that it relied on that behavior [10:37:21.0000] I don't really understand what floating on Node would accomplish [10:37:22.0000] idk if surfing around would have helped [10:37:30.0000] well, maybe not [10:37:44.0000] but if we put an assertion, it would've shown that it was hit [10:37:54.0000] actually seeing that this one-off fix fixes it is harder [10:38:07.0000] yup [10:38:36.0000] what caitp is working on in Igalia now is investigating what it would take to make stuff like the frozen realm shim run faster [10:38:41.0000] running local version of node would be my main way of doing this as I don't have experience building chrome [10:38:56.0000] but node hits the same path in lodash [10:40:03.0000] but to put things in perspective [10:40:13.0000] frozen realms etc. are not super usable as it stands [10:40:25.0000] the node PR implementing frozen intrinsics points this out [10:40:30.0000] bradleymeck: can you elaborate? [10:40:59.0000] caitp: lots of things "dont work" if your intrinsics get frozen due to lots of errors or noops occuring around these non-writable properties [10:41:30.0000] mark's work relies on completely changing a lot of properties from data to accessor props to try and work around this [10:41:42.0000] but that isn't how JS specified intrinsic properties [10:42:38.0000] see https://github.com/nodejs/node/pull/25685 , where it shows up from a different party investigating the approach of freezing intrinsics [10:43:02.0000] my understanding is that the proposal is designed to protect against this sort of thing, especially from untrusted code [10:43:21.0000] "this sort of thing"? [10:43:22.0000] would you say there needs to be a layer where it's always allowed? [10:43:30.0000] "it"? [10:43:40.0000] this sort of thing -> changing properties on intrinsics [10:43:45.0000] adding new ones, etc [10:43:48.0000] correct, that is not the problem [10:44:00.0000] the problem is as laid out in that node PR and others, that subclassing can break [10:44:23.0000] and various other things if you have non-writable (such as frozen) properties in your proto chain [10:44:38.0000] even worse, it doesn't always throw [10:44:44.0000] it sometimes just noops [10:44:52.0000] depending on strict/sloppy [10:45:09.0000] ah I see [10:45:23.0000] so, without fixing this, frozen realms are... not as usable [10:46:17.0000] well, subclassing builtins is a relatively recent thing right? not 20 years of legacy code doing that [10:46:31.0000] caitp: not just builtins and not just using class syntax [10:46:38.0000] any way of putting things in the prototype chain [10:46:54.0000] so things like the old fn.prototype.toString = function () {} start throwing [10:47:00.0000] or nooping... [10:47:03.0000] ok, that's fair [10:47:47.0000] hence my pushing node for web compat hacks [10:50:13.0000] to my knowledge the only breakage of importance seems to be lodash but signal/noise ratio is too high without the compat hack (which itself might be breaking) to know if other things are relying on this [10:50:44.0000] even if we just fix it in strict mode, it seems like it would be pref to doing nothing, as frozen prototypes make entire codebases unusable for now [10:53:51.0000] bradleymeck: I mean, you can do this experiment in Node, but I wouldn't be convinced that it demonstrates web compatibility [10:54:03.0000] the only thing it could really demonstrate is likely incompatibility [10:54:07.0000] the compat hack will clearly affect a lot of code, but how much of it would actually become broken? it's hard to estimate [10:54:32.0000] well, if we're talking about Object.prototype.toString fallbacks, I'm pretty comfortable with adding more of those [10:54:34.0000] littledan: showing if the web compat hack is incompatible is of value here [10:54:57.0000] as it would at least let us figure out a way to get a better signal/noise ratio on usage counters [10:55:01.0000] I'd be pretty surprised if adding more of these fallbacks broke anything, but I wouldn't be surprised if it didn't fix enough [10:55:22.0000] but those are just guesses [10:55:56.0000] anyway this takes a nontrivial amount of C++ coding to implement; there's no patch out there that you can just float [10:56:17.0000] littledan: the tostring workaround? [10:56:23.0000] yes [10:56:31.0000] basically we're talking about a partial revert of ES6 here [10:56:47.0000] it is doable in pure JS even if you replace all the refs unless I'm missing something? [10:57:02.0000] sure? I'm not sure what you're trying to get at [10:57:33.0000] there could potentially be angularjs 1.x apps out there which define readonly properties on a $scope, and then try to overwrite them in child scopes --- IIRC doing this with non-readonly properties was a pretty common (accidental) pattern [10:57:55.0000] so if someone did that with a non-readonly property, it could break the app... but it is a big if [10:58:35.0000] caitp: even with that going on the question remains of if strict mode which errors suddenly didn't error would things break [10:58:55.0000] but we just have too much going on [10:59:44.0000] need to reduce noise to get any sort of direction [10:59:46.0000] well I think the only way to really find out is to do an experiment where some % of browsers get the special behaviour and some don't [10:59:58.0000] or put it on a webcrawler or something [11:00:19.0000] we did that with usage counters so that we wouldn't break things [11:00:29.0000] yes but as you say, signal/noise [11:00:36.0000] it doesn't indicate breakage [11:17:21.0000] Hmm. If proxies effectively let you overload the = operator (and a few more), more general operator overloading shouldn't be any slower than that, right? [11:17:58.0000] Or is = already kinda slow, so the fact that you have to check if you need to indirect thru a proxy or a setter not generally a perf hit, but doing the same for + would be? [11:25:39.0000] TabAtkins: they already let you control the Set operation for that, I'm not sure I understand the question [11:26:27.0000] Yes, that's my point. We already have overloading of *some* operators, so I'm curious about if overloading the rest is problematic in new and exciting ways, or just the same ways we already know about? [11:26:36.0000] you can control `proxy = `, but you can't control what ` + ` gives you [11:29:08.0000] yes [11:30:32.0000] ...I'm not sure how my words could be read this way, but just in case: I'm not asking to expand Proxies to handle operator overloading. I'm asking about the perf implications of proxies, and how it compares to the perf implications of more general operator overloading. [11:30:54.0000] Because one of the main objections to general overloading is that it slows down all math, etc. [11:48:52.0000] proxies are noticeably slower last I checked, doubt that will ever change since you have to call into JS which I don't think can be optimized out [11:54:02.0000] littledan: to confirm, https://jsbin.com/qajukupuca/edit?js,console is my understanding of the behavior change that was being talked about? [11:56:10.0000] bradleymeck: mslekova and some others have done a fair bit of work to keep some (maybe all at this point) proxy operations in JS, and I don't think there's any reason we couldn't add some support for the js-inlining pass. it should be possible to be substantially faster than it was originally [12:12:56.0000] that work is unlikely to happen before proxies see heavier use in perf-critical code though, or before there's a demand for that. [12:18:46.0000] bradleymeck: Yep, I agree that this hits the codepath that jridgewell traced in the issue [12:18:52.0000] I just don't know whether this is the only issue out there [12:19:33.0000] littledan: it is probably not the only issue to be clear, but it has soo much noise that no other ones were found on cursory checks [12:22:22.0000] well, sure, but I don't understand how you want to eliminate the noise [12:22:41.0000] if you fix up that piece, it will still be after the UseCounter clicks [12:28:00.0000] littledan: maybe we were using the usage counter for different purposes? [12:29:11.0000] even if the usage is "high", if the behavior doesn't change it wouldn't be problematic? also in the past thrown -> non-thrown has been treated as non-problematic which affects strict mode change [12:48:14.0000] how confident do you think you'd have to be that it wouldn't break the web most of the time to convince maintainers to run a finch trial (or just ship the proposed change in nightly)? [12:48:26.0000] how does a proxy override equality [12:51:59.0000] oh it was the set operation [13:02:45.0000] caitp: I'd have to go through a large test of using local chrome + puppeteer or something so that nothing seems crazy, 15% is enough that top 10k websites should have it show up plenty and that at least might be enough. I'd still be somewhat wary and need to put in more checks just to ensure that we skip the lodash hack when retesting. this feels a bit brutal though [13:04:18.0000] strict mode counter is less concerning but still at that massive 1.5% [13:09:16.0000] lodash is still all over the internet [13:09:17.0000] looking at the origin trials docs, we have done most of what's required for a field test [13:11:24.0000] ok maybe not most of, probably the 2 most passive things, but still [13:19:52.0000] devsnek: updated lodash is not affected and some historically old lodash are not affected [14:08:51.0000] bradleymeck: but there are still versions of it floating around right? [14:12:30.0000] yup, but web compat hack makes it still function correctly even w/ change [14:15:36.0000] web compat hack [14:17:23.0000] a tried and true tradition! [14:17:34.0000] what's the hack [14:18:48.0000] modifying Object.prototype.toString to include typed arrays instead of having typed arrays delegate to the TypedArray.prototype[toStringTag] getter (the fact it was a getter was kind of wild to me) [14:19:20.0000] I see [14:19:47.0000] it's still kind of wild to me that failed sets would walk down the prototype [14:20:40.0000] mmm? [14:20:53.0000] if it fails, it stops [14:21:37.0000] isn't the whole idea that the change would be to go from fail = no set to fail = try on the parent [14:23:03.0000] nope [14:23:21.0000] I'm confused then [14:23:26.0000] non-writable in proto crawl would perform define on reciever [14:23:32.0000] thats the change [14:23:38.0000] currently in sloppy, it noops [14:23:43.0000] currently in strict, it throws [14:24:05.0000] so it goes straight to the receiver [14:24:26.0000] not as weird but still weird [14:24:33.0000] well it delegates up to see if a setter exists [14:25:43.0000] so it does walk back down the prototype? [14:27:02.0000] yup [14:27:18.0000] but it stops walking when it encounters any given descriptor [14:27:22.0000] same as today [14:27:58.0000] so it goes until it finds the prop, and if it's non writable it goes back a steo [14:28:06.0000] step* [14:29:19.0000] idk if it goes back a step, it can take action without rolling anything back [14:29:49.0000] back a prototype [14:30:26.0000] nah [14:30:34.0000] it just places it directly on the reciever [14:30:42.0000] no need to crawl back to find the reciever [14:32:29.0000] but when i said that before [14:32:40.0000] you said "well it delegates up to see if a setter exists" [14:34:49.0000] down/up isn't a good terminology here ;p [14:34:55.0000] it only does it in 1 direction [14:35:21.0000] walk prototype to find property [14:35:26.0000] property isn't writable [14:35:32.0000] do write on receiver instead [14:35:36.0000] yes [14:35:54.0000] what if receiver isn't writable [14:36:34.0000] same behaviour as now? [14:36:52.0000] yup [14:38:31.0000] still feels kinda weird [14:38:41.0000] bradleymeck: Right, proxies are slower. But we still put them in the language. One of the blockers brought up for operator overloading is that it'll be slower. Is it slower in a way that is different from proxies, or worse in some important way? [14:38:42.0000] like why not just explicitly create whatever prop it is on your object [14:40:00.0000] devsnek: because assignment is the expected UX [14:40:06.0000] TabAtkins: depends on how operator overloading is done [14:40:18.0000] bradleymeck: but the assignment failed [14:40:23.0000] because the property wasn't writable [14:40:33.0000] TabAtkins: Proxies allow you to create your own forms of the meta-object protocol / create your own exotics, overloading is something else [14:40:54.0000] Right, but it's also kinda overloading the = operator, right? Is that significantly different than overloading the + operator? [14:40:58.0000] bigint adds a protocol for mathematical operators [14:41:08.0000] (ignoring the issues of right-vs-left operators, etc) [14:41:12.0000] devsnek: not really, getter/setters can still have success even if they are not writable, this isn't really related to some sort of mental model of what "writable" means [14:41:51.0000] TabAtkins: it doesn't overload = really, not sure I understand, = does call the set() trap though [14:41:56.0000] TabAtkins: the usual design of operator overloading would make every operator have to check the operand for an overload [14:42:23.0000] "call the set() trap" sounds a *whole lot* like "check if the LHS has overloaded its = operator" to me [14:42:39.0000] it is [14:42:55.0000] setting is slower than it could be because exotic objects exist [14:43:35.0000] TabAtkins: it doesn't really to my knowledge, `x = 1` doesn't ever fire that trap and `x.y = 1` doesn't mean it fires from `x` and instead could fire from `x.__proto__` [14:43:38.0000] Okay, right, so = is *already* slow for reasons, and proxies don't make it appreciably worse? But + is fast right now, and operator overloading would make it significantly slower (equivalent to = and proxies)? [14:44:01.0000] TabAtkins: I just see them as fundamentally different, so I'm confused mostly [14:44:09.0000] in an interpreter = is slow [14:44:33.0000] optimization can help of course [14:44:43.0000] bradleymeck: Details, details, the point is you're hijacking some syntax forms to magically invoke a special function instead. [14:45:06.0000] TabAtkins: those details are the difference, so i don't understand that comment [14:45:10.0000] bradleymeck: after bigint lands, mathematical operators have their own protocol [14:45:52.0000] so addition goes from an O(3) game to an O(4) game [14:46:01.0000] kind of, but not in the sense of it being exposed / having scaling issues [14:46:19.0000] `x.y = 1` becoming `x.proxySet('y', 1)` (essentially) feels similar to `x + y` becoming `x.operatorAdd(y)`; the difference I'm seeing is that = is already having to do (relatively slow) work because of various exotic objects, while + gets to fast-track more often, so adding an overloading check is a minor penalty for =, but a big penalty for +. [14:46:22.0000] we add things to various algorithms all the time [14:46:56.0000] and it makes interpreters really slow [14:47:18.0000] TabAtkins: I would disagree on that point as x.operatorAdd(y) might not match y.operatorAdd(x), one might state that operatorAdd(x, y) is the less confusing approach [14:47:31.0000] but even then, you probably don't want this on the proxy [14:47:38.0000] bradleymeck: Sure, whatevs on exactly how you figure out what to dispatch. [14:48:30.0000] the dispatch is rather important here, does it live on an operand that the operation is being performed on or independently changes if you need to do the lookup at the site or it can be static [14:48:36.0000] bradleymeck: I'm not saying add this functionality to proxies. I'm using proxies as an example of seemingly-similar functionality that was accepted by the committee, to question one of the objections to overloading. [14:48:44.0000] for member expressions the assignment always does the lookup [14:48:46.0000] right now overloads live on the operator [14:49:46.0000] TabAtkins: i have other objections than speed, but tradeoffs of speed are generally going to be case by case, and introducing more means those tradeoffs become harder to justify over time [14:50:13.0000] the usability aspect of overloading is interesting, but makes many things much harder to reason about [14:51:45.0000] it would probably only work as an uninherited internal field 2019-02-06 [16:39:38.0000] TabAtkins: why do you think proxies result in overloaded = operator? [16:40:24.0000] `foo.bar = 1` does a specific thing, normally. When a proxy is involved, it instead calls a user-defined function that can do anything. [16:40:45.0000] That seems like the same thing, more or less, as overloading the = operator? [16:44:25.0000] technically its just always overloaded [16:44:35.0000] proxies are just another exotic object [16:49:20.0000] I see, I think of that as changing how . works, not = [16:49:20.0000] TabAtkins: that's the same for setters tho, right? [16:51:00.0000] accessors are a subset of object behaviour [17:22:23.0000] ljharb: yup, same deal [17:27:11.0000] Domenic: overloading an operator either way, sure [21:36:13.0000] shouldn't this change x, not add a new property to y https://gc.gy/17136350.png [05:08:17.0000] Personally, I could go either way on user-level operator overloading vs adding more built-in types with overloaded operators, but I think TC39 is in a funny middle state where we don't have consensus on the future plans, which makes it hard for CSS units to be ergonomic either one way or the other way [06:30:45.0000] littledan: I think allowing hosts to overload is different from JS hooks though, so a 3rd option! [06:31:37.0000] yeah, that'd be interesting, so we could have Decimal in TC39, CSS units through host hooks, but no JS-defined stuff, and no ability to polyfill those two [06:32:02.0000] however, when Andrew Paprocki presented on Decimal, some people said, "this must be through JS-level operator overloading" [06:32:20.0000] so, I wanted to think through what that would mean, to understand whether we should go that way, or one of these other ways [06:38:40.0000] i don't think host hooks would be a practical solution, at least thinking of the relationship between chromium and v8 [06:39:02.0000] probably worse than a pure js api [06:43:25.0000] littledan: lots of people want to keep virtualization ;p [06:44:39.0000] i'm also hopeful that now that v8 is working on a jitless mode there will be more focus on how things impact pure interpreters [07:10:33.0000] bradleymeck: I think my operator overloading proposal should be good with virtualization. Do you see problems? [07:11:09.0000] at the same time, you can't write your own Number or BigInt today, so I don't understand what the argument is that you must be able to write your own Decimal if it exists [07:11:13.0000] littledan: nope, but the virtualization invalidates a lot of my stuff around minification XD [07:11:24.0000] which stuff? [07:11:49.0000] folding +b into a number then making other things folded based upon that [07:11:55.0000] like `typeof +b` [07:13:11.0000] idk if unary plus actually is overloadable in your proposal (goes to check) [07:45:21.0000] unary plus has to throw if ToNumber fails [07:45:23.0000] for asm.js reasons [07:45:25.0000] :( [11:18:02.0000] So what are your thoughts on forkable generators? Generators that you could shallow-clone and re-enter from a saved state? I'm thinking of things like encoding decision trees for user actions. In case you're curious, I've got a quick little strawman proposal I scrapped together: https://github.com/isiahmeadows/proposal-generator-fork [11:39:45.0000] mmm, continuations :P [11:41:37.0000] Yeah, that was an inspiration. I just wanted to keep it mutable so it'd integrate a bit better with iteration. [12:04:01.0000] isiahmeadows: might be a better thing to suggest to https://github.com/tc39/proposal-iterator-helpers [12:04:10.0000] a lot of iterator libraries and interfaces already have teeing [12:05:04.0000] I'm not sure if it'd be a good idea to suggest as specifically an extension to `Generator` itself rather than a new subtype of it - not all generators in practice support being split like that. [12:05:42.0000] I can certainly file an issue over there, though. [12:05:42.0000] the prototype a generator returns can override the base tee method đŸ€· [12:15:03.0000] But what about ensuring side effects in the generator side are repeated? [12:50:27.0000] tee though consuming the original/neutering it seems the general approach to avoid some replay confusion, the tee makes a buffered pair of 2 different iterators [12:50:38.0000] not splitting to replay effects 2019-02-08 [19:26:47.0000] we can not fix typeof. Can we make it obsolete, like https://ideone.com/Je4cpU ? [19:30:27.0000] /me waiting for a response [19:34:21.0000] I will say it's part of my own proposal, where I just gave up thinking about. I never use typeof in code. [19:35:30.0000] I take that back. I use it in one place at work. Was kind of ad-hoc though and I could remove it. [00:27:49.0000] https://github.com/tc39/ecma262/pull/1442 mmm "Editorial" changes. +1,781 −5,328. At this rate we might be able to view the diff in github. [06:01:58.0000] Why are there AgentSignifier() and AgentCanSuspend() and not some per-algorithm grab of the surrounding agent on which then fields are inspected? [06:04:18.0000] And then stuff like "If W was notified explicitly by another agent calling NotifyWaiter(WL, W)" is a little weird; normally that kind of thing is managed with state in ECMAScript [06:04:45.0000] And also W is a signifier for an agent... What does it mean to notify a signifier? [06:06:18.0000] I guess I'm gonna file issues [07:00:27.0000] bterlson: do you know if anyone plans to work on https://github.com/tc39/ecma262/issues/1357? [07:00:50.0000] bterlson: how HTML deals with agent clusters needs changes and it'd be nice not to have to change it too many times [10:55:12.0000] annevk: bterlson's on his way out as editor; zenparsing & ljharb would be the point people for new issues like that [10:56:30.0000] annevk: i'm not aware of any plans to work on it, but if you want to make PRs with small easily reviewable commits that would always be appreciated <3 [11:18:14.0000] aklein: ta [11:18:53.0000] ljharb: I wish I had more time, though even then I’m not I grasp this space well enough [11:23:18.0000] not sure* [11:58:44.0000] lol sames, "editor" and "expert" are two very different words :-p 2019-02-09 [21:11:04.0000] why does setting a property traverse the prototype if it always sets on the receiver [21:12:04.0000] for calling setters? 2019-02-11 [13:55:12.0000] bterlson: dunno if you've seen this but it's glorious https://gist.github.com/lhorie/c0d9fd9b2aa215f4984f3ce1c8fd01bf 2019-02-12 [17:32:59.0000] U+2029 PARAGRAPH SEPARATOR begins a new line in JS even if it doesn't display that way, so I call shenanigans on the endpoint there [19:10:41.0000] > Are gists the most misappropriated blogging platform ever? [19:10:41.0000] was the part that made me laugh the most tbqh [19:19:19.0000] devsnek, Stuff like that is driving me a bit insane determining if my grammar changes don't create problems. :| The number of weird expansions of the grammar rules that no one would ever write are amazing. [19:50:50.0000] Also I'm very glad that [] is basically only a valid token sequence for array initialization. Would be a headache if calling arrays with undefined was allowed. [20:01:37.0000] Also since I have to learn how to write algorithms soon for my proposal. http://sirisian.github.io/ecmascript-types/#prod-MemberExpression If you have grammar rules for parsing something like: https://github.com/sirisian/ecmascript-types#array-views It makes more sense to just write the grammar rule as an argument list? I noticed all the built in functions don't assert their argument lengths. Object.getOwnPropertyDescriptor(o, [20:01:37.0000] 'a', 1, 2, 3); Seems like everything is kept dynamic. Seems strange to me to do the same to the array view syntax though as it's not "real" function. [20:03:25.0000] What I mean is it's not something that can be reassigned by the user like most other functions. [09:44:16.0000] hrm [09:44:30.0000] TIL about "hamburger hill" as a metaphor [09:44:36.0000] https://github.com/tc39/proposal-temporal/issues/98 [09:53:45.0000] i find it unlikely that builtin modules will move forward in the next 5 years [09:54:19.0000] i'd say the same, but i'd stop before "in" [09:55:40.0000] i'd assume some future set of delegates will in some way agree to either have it or not have it [09:58:01.0000] What is blocking them? [09:58:18.0000] "consensus" [09:58:39.0000] tho I bet the issue of polyfillability probably looms too [10:00:12.0000] Sure, I guess I’m looking for a pointer explaining both sides trying to get on that hill [10:04:31.0000] from what i can see, if all the polyfill and security constraints are met, then all the advantages over globals go away [10:04:42.0000] at which point, i don't see how the feature would carry its weight [10:04:50.0000] I will admit to not having paid full attention to the builtin modules goo to really expound on it well [10:05:11.0000] globals entail a smallish cost in memory per global object [10:05:27.0000] thousands of cuts, and all [10:05:30.0000] and either way, i have yet to see a language-level solution that allows for the polyfill and security use cases (import maps doesn't count) [10:05:37.0000] (because it's not language level) [10:05:55.0000] jwalden: they could be lazily loaded on use, tho. i think that's how some engines do Intl [10:05:56.0000] jwalden: v8 recently(ish) used some fancy memory mapping and snapshotting to de-duplicate that [10:06:29.0000] ljharb: that's as to the underlying Intl data, not as to the binding functions -- or at least that's how SpiderMonkey does it [10:06:56.0000] jwalden: i guess i don't see why the first reference to `Intl` couldn't lazily create the same thing that `import from 'intl'` could [10:07:32.0000] https://v8.dev/blog/embedded-builtins [10:07:35.0000] but certainly, that'd at least be a benefit of builtin modules (in the world i described above, where polyfill/security needs are met) [10:09:34.0000] fancy memory mapping is *possible* for sure, but it rather constrains implementations and is a bit of a complexity tax, definitely [10:10:52.0000] An idea I quite liked was using builtin modules as a way to expose the world to Wasm [10:11:08.0000] wdym [10:11:45.0000] E.g., as a way for Wasm to get hold of fetch() or some such [10:12:18.0000] isn't that just anyref [10:12:56.0000] If you want to forever require going through JS, sure [10:13:15.0000] how else would js builtins be exposed to wasm [10:14:06.0000] Builtin modules? [10:14:15.0000] so like [10:14:26.0000] add a new api to wasm for the embedder to define builtin modules [10:14:30.0000] which wasm modules can then use [10:20:52.0000] ljharb: thanks for the clear explanation btw [10:29:50.0000] annevk: np, i don't like being so doomsay on it, but so many people seem so (perhaps blindly) bearish on it :-/ [10:30:12.0000] presumably wasm already has a way to get at JS globals, right? [10:31:58.0000] ljharb: only if you pass them in from JS [10:32:39.0000] aiui [10:33:22.0000] annevk: i mean, you can't create a function in wasm in sloppy mode that returns this and invoke it? or use `Function` and invoke it with `'return this'` and invoke the result? [10:33:38.0000] if you can do either of those things then it seems pretty useless to have that restriction in wasm [10:33:42.0000] you can't create a js function in wasm at all [10:33:50.0000] or strings [10:33:54.0000] lol, ok [10:34:09.0000] i mean, it just means a wasm program has to have a js component to provide the global, if it wants it [10:34:10.0000] you could put the chars of return this in memory [10:34:25.0000] then call a function from jsland with the address of those chars [10:34:30.0000] which converts them into a string [10:34:34.0000] and then calls Function() [10:36:25.0000] right, so if it's possible, why force the hoop jumping [10:39:11.0000] đŸ€· [12:48:04.0000] ljharb: because WASM can't do it on its own [12:48:13.0000] it remains in principal of least authority [12:52:21.0000] bradleymeck: can't what, expose the global? why not? [12:52:38.0000] no way to get a hold of it without someone passing it in [12:52:58.0000] wasm modules can mutate undeniable globals tho [12:53:02.0000] even if WASM makes a string, it needs to pass it out and get the global passed back in [12:53:02.0000] like `[].constructor` [12:53:13.0000] ljharb: if you pass in a reference to those [12:53:22.0000] not available w/o being passed in [12:53:24.0000] i'm confused; so you can't make a JS array in a wasm module? [12:53:40.0000] you can, but not without a way of doing so being passed in [12:53:55.0000] interesting, ok [13:57:42.0000] ljharb: wasm currently only has four first-class types: i32, i64, f32, f64 [13:57:48.0000] ah [14:39:26.0000] I don't understand what "hamburger hill" means... [14:39:48.0000] " [14:44:14.0000] Informative! ^_^ [14:45:54.0000] Oh, was that a ditto marker? [14:47:14.0000] i've heard "die on a hill"; google leads me to https://en.wikipedia.org/wiki/Battle_of_Hamburger_Hill for "hamburger hill" but that doesn't help me much [14:52:00.0000] TabAtkins: yes :P [14:52:35.0000] is it like, the McMansion or McJob version of dying on a hill? [14:52:49.0000] (still not sure what that implies but...yeah) [14:59:20.0000] (also I guess that would be "dying on a McHill" so yeah, I got nothin') [15:48:04.0000] hamburger hill is dying on a hill that causes you to lose some larger battle [15:52:26.0000] maximum whoosh 2019-02-13 [16:07:56.0000] indeed 2019-02-14 [09:15:40.0000] somebody should really add some issue guidelines on github to stop people from wasting their time with feature requests [09:17:22.0000] Is there a new issue template? [09:17:32.0000] Also, good point [09:50:00.0000] https://github.com/tc39/ecma262/pull/1449 :) [10:17:50.0000] devsnek++ [10:18:41.0000] i just wish that 1 + 1 bug could be fixed [10:20:59.0000] jmdyck: is the W3C HTML fork still maintained? I thought they had never interacted with TC39 [10:46:07.0000] annevk: Well, at https://github.com/w3c/html , the latest commit was a month ago, so I'd say it's still maintained. The Web Platform WG is certainly still chartered to deliver HTML 5.3, among many other things. [10:46:43.0000] As to their interaction with TC39, I have no idea. [10:48:31.0000] https://www.w3.org/2017/08/webplatform-charter.html#external-groups says they "may also collaborate with" TC39. [10:50:13.0000] jmdyck: anyway, I’m not sure it’s relevant as no impl follows that spec and I wouldn’t wanna ask more of TC39 contributors than actually needed [10:52:56.0000] do all impls violate the W3C spec? [11:13:30.0000] jmdyck: hard to tell as nobody is using it [11:37:16.0000] Interesting. Is that common knowledge? [11:43:42.0000] i wouldn't consider w3c's html an authoritative source [11:45:04.0000] jmdyck: as far as i'm aware w3c's html is a copypaste from whatwg in order to maintain their charter [11:45:41.0000] domenic would probably know more [11:46:14.0000] jmdyck: the W3C has officially stopped maintaining their HTML fork; they announced it on their blog this morning I believe [11:46:30.0000] hmm that's a fun coincidence [11:46:35.0000] https://www.w3.org/blog/2019/02/w3c-strategic-highlights-strengthening-the-core-of-the-web-html/ [11:46:44.0000] It's hidden behind layers of euphemism [11:46:55.0000] "In the recent extension of the Web Platform Working Group, we noted that while the WHATWG and the W3C continue negotiations to provide a single authoritative specification for HTML and DOM, no joint work with the WHATWG would advance on the W3C Recommendation track; we believe that having two distinct HTML and DOM specs claiming to be normative is generally harmful for the community." [11:47:04.0000] "joint work with the WHATWG" = forks of WHATWG work [11:47:28.0000] as far as i'm aware browsers only pay attention to whatwg [11:47:30.0000] so [11:47:32.0000] đŸ€· [11:47:56.0000] Yeah, but I get the sense jmdyck was interested in standards-orgs politics, so I'm spelling that out instead of focusing on reality [11:47:58.0000] Oh nice that got clarified [11:48:05.0000] Yeah it's officially out of the charter now [11:48:16.0000] https://lists.w3.org/Archives/Public/public-webapps/2018JulSep/0024.html [11:48:29.0000] lists all the URLs of things that will no longer advance, including https://www.w3.org/TR/html53/ [13:15:46.0000] Domenic: I actually read that blog post this morning (which is I think what reminded me to ask my question in 1445). The wording you quoted struck me as odd, so I dug into it a bit and came to a different conclusion from you. I'll see if I can find it. [13:17:06.0000] the blog post is confusing (probably because pr) but the email is pretty clearcut [13:21:01.0000] Ah right, the msg you linked to (https://lists.w3.org/Archives/Public/public-webapps/2018JulSep/0024.html) says that html53 (etc) won't advance along the REC track *during this extension* (i.e., during the extension of the charter to 2018-12-31). So given that that period has passed, I looked for what the charter says *now*, and it seemed to indicate that html 5.3 was still a deliverable. [13:23:15.0000] Ah, I guess WebPlat was not showing me the current charter. [13:23:44.0000] Or maybe they were. Hrm. [13:33:31.0000] ok, here's the post-2018 extension of the WebPlat charter: https://lists.w3.org/Archives/Public/public-webapps/2019JanMar/0012.html [13:33:47.0000] "The previous recommendation regarding having no REC track advancement for a subset of the documents still applies." [13:37:41.0000] So it looks like https://www.w3.org/2017/08/webplatform-charter.html *is* the current charter, and it *does* say that HTML is a deliverable, but that's not the full picture. [13:45:11.0000] given what I' [13:47:40.0000] Given what I've seen so far, it looks to me like the AB said "if we don't reach an agreement with WHATWG, there's a fair chance we'll just abandon those specs, so WebPlat should not expend any energy on them". [13:50:39.0000] In the latest WebPlat minutes (https://lists.w3.org/Archives/Public/public-webapps/2019JanMar/0018.html) one of the WG chairs says "As far as I know we are waiting for W3C to get responses from the browser vendors, or vice versa, on the details of the mooted collaboration agreement" [14:08:03.0000] https://github.com/patrickhulce/third-party-web 2019-02-18 [04:55:02.0000] littledan: https://github.com/tc39/ecma262/pull/1445#issuecomment-464692624 is either a private repo or the wrong link [04:55:41.0000] it's a private repo. I can give you access, as you work for a TC39 member organization [04:56:15.0000] I wrote this documentation months ago, but you can see arguments in the TC39 Reflector repo for why it should be held secret for longer [04:56:46.0000] (I mean, arguments from people other than me) [04:58:03.0000] I'm pretty frustrated with the situation. I put a bunch of effort into several pieces of documentation, and don't understand why we can't share them with people who may be helped by it [04:59:06.0000] Do you think sharing documentation about how to contribute to TC39 will encourage trolling against us, if we don't have a full rationale published for the specification? [05:01:49.0000] Annevk, just invited you [05:06:18.0000] littledan: if that were the case W3C/WHATWG would be trolled a lot, which doesn't seem to to be the reality? [05:09:09.0000] littledan: FWIW, I skimmed through that pr.md document, seems great to me [05:09:54.0000] littledan: WHATWG has similar documents, e.g., https://github.com/whatwg/meta/blob/master/COMMITTING.md [05:10:04.0000] littledan: and https://github.com/whatwg/meta/blob/master/MAINTAINERS.md [05:10:29.0000] "Subscribed to 15 tc39 repositories" oops [05:47:33.0000] I just subscribed to HTML and it's already way too much [05:47:48.0000] but at least HTML's activity tends to be really technical [05:48:13.0000] we all like to troll ISO, who has books and books of process documents [05:48:21.0000] but, somehow, that doesn't make it onto Twitter 2019-02-19 [12:24:52.0000] littledan & annevk, regarding yesterday’s conversation, i’m totally ready to #shipit [12:25:26.0000] Awesome! [12:26:58.0000] call it an itchy trigger finger. i’m not gonna unilaterally do it rn or anything, but i am ready to start pushing and pushing [12:35:51.0000] akirose: 🎉 2019-02-21 [15:13:02.0000] a cookie for the first person to find me the source of this section https://tc39.github.io/ecma262/#sec-copyright-and-software-license [15:13:24.0000] and no, the tc39/ecma262 repo on the gh-pages branch does not count. [15:13:46.0000] akirose: inside ecmarkup, i bet [15:13:53.0000] akirose: https://github.com/bterlson/ecmarkup/tree/master/boilerplate [15:14:05.0000] kk i owe you a cookie bterlson [15:14:14.0000] yussss [15:14:16.0000] i'm gonna eat me a cookie anyways [15:14:36.0000] I like ginger snaps (the kind that break your teeth) [15:14:53.0000] that's the only kind [15:14:57.0000] otherwise they're just ginger cookies [15:15:00.0000] AGREE [15:24:11.0000] i’m making all manner of faces at y'all [15:24:15.0000] also i’m gonna go eat a Samoa [15:24:44.0000] Pain is a taste [15:25:09.0000] ^ that one almost deserves a "tc39 out of context" tweet [15:25:12.0000] (don't @ me) [15:25:19.0000] smh [15:25:38.0000] rkirsling: lol yeah, something something no wonder javascript something something [15:25:48.0000] 😂 [15:26:05.0000] akirose: also i'm concerned, please don't eat people from samoa [15:26:41.0000] I think she's eating the country of Samoa, presumably from a map or something [15:26:41.0000] devsnek: that's a Samoan [15:26:47.0000] lol... [15:27:16.0000] https://usercontent.irccloud-cdn.com/file/lhC8xJW2/image.png [15:27:31.0000] they're actually called Caramel deLites in other regions (like WI) [15:27:40.0000] true story [15:28:00.0000] still Samoa in CA [15:28:02.0000] and they’re ever so slightly different, but the difference is irrelevant [15:28:10.0000] and I really want one now [15:28:18.0000] gotta hunt down somebody with daughters [15:28:20.0000] lol [15:28:28.0000] different bakeries [15:28:35.0000] i hate the internet "The Crazy Truth About Samoas vs. Caramel deLites" [15:28:42.0000] rkirsling go to your local Vons/Albertsons/etc [15:28:53.0000] there are always girl scouts selling cookies at the entrances [15:28:56.0000] ah yeah true, they do tend to set up a stand [15:30:38.0000] https://snaps.akibraun.com/h8dwo.gif [15:30:48.0000] my gift to you, south bay friends https://www.girlscouts.org/en/cookies/cookies.html?#94089 [15:31:13.0000] there are 5 within 0.0 miles of me [15:31:20.0000] *checks roof* [15:32:30.0000] they’re allegedly at the grocery store < 1 mile from me every day through 03/10. must buy more cookies. [15:32:39.0000] OMG IT’S ANNUAL BONUS TIME. A BONUS WORTH OF COOKIES. [15:33:05.0000] lol [15:34:53.0000] rkirsling: it's based on the baking company; and they change sometimes [15:35:05.0000] i grew up with peanut butter patties but then they switched to tagalongs [15:42:16.0000] ahh yeah that too [15:43:30.0000] also Trefoils were just Shortbread [15:43:58.0000] (those really aren't the best anyway but still) [15:52:50.0000] i keep girl scout cookies stocked in the freezer, so i can have them year round :-) 2019-02-22 [18:02:13.0000] the cookie 1 year challenge is always fun. Buy a box, wait a year buy a 2nd box and then try to guess which of the cookies are new vs old [18:12:12.0000] lol fascinating [19:50:57.0000] bradleymeck: not even frozen? [19:51:00.0000] interesting [19:51:24.0000] i know that tagalong chocolate gets relatively stale after 4-6 months, so that one'd be easy [19:51:34.0000] (when unfrozen) [06:22:17.0000] ljharb: in the refrigerator is my game [08:55:50.0000] what are people's opinions on a js runtime that crashes when a promise rejects without a rejection handler [09:04:28.0000] littledan: I don't understand why an explicit RunJobs is needed [09:04:51.0000] After each job, the job queue will be emptied automatically, at least in HTML. [09:04:58.0000] Are you running script without using a job? [09:05:05.0000] hey, thanks for the quick review, Domenic [09:05:22.0000] I guess I'm missing the part where HTML gets involved here, in InnerModuleEvaluation [09:05:42.0000] I thought that spun around in JS a bunch without HTML coming into play, once the module graph was all pulled down and executing [09:06:03.0000] Step 13.g.i does PerformPromiseThen() [09:06:07.0000] Which will enqueue a job [09:06:18.0000] Which, when that job finishes, will perform a microtask checkpoint [09:06:39.0000] It currently does do that. But with the changes in top-level await, evaluating a module now does promise things, so HTML gets back into the loop [09:06:53.0000] s/13.g.i/13.g.iv/ [09:08:05.0000] sorry, 13.g.iv of which algorithm? [09:08:15.0000] https://tc39.github.io/proposal-top-level-await/#sec-innermoduleevaluation [09:08:50.0000] how can queuing a job run the job queue [09:09:00.0000] so, yeah, when all the microtask queue items are done, there's a checkpoint. But I don't see why we'd get to a checkpoint if we have a big glob of modules running [09:09:18.0000] I mean, a bunch of things will get queued, due to stuff happening in launching the evaluation of different modules [09:09:41.0000] the insertion of a microtask queue checkpoint (via the willful violation by HTML noted in FlushJobs) would sort these out [09:10:04.0000] Hmm [09:10:09.0000] there's a standing disagreement between HTML and JS on layering; I'm not trying to say things are resolved in one way or the other, just explain it with both mechanisms at once [09:10:28.0000] So the problem is that you are queuing A, B, C, D, E but you want to run things in... what order? [09:10:45.0000] Let me do better letters [09:11:20.0000] Given https://github.com/tc39/proposal-top-level-await/issues/47#issuecomment-464488593 [09:11:23.0000] Are you not queuing jobs in order a1-1, a-2, a, b, main? [09:11:28.0000] What order are you queuing the jobs in? [09:11:48.0000] the microtask queue congestion issue comes up because of the Promise.all at the beginning of modules that import things [09:12:05.0000] the "right" tree might end up being run before the "left" tree if it's less deep [09:12:39.0000] so, that's why a ends up running after b [09:12:46.0000] Right, I got that. But I'm trying to root cause. Is the issue you are queuing jobs in a different order than a-1, a-2, a, b, main? [09:13:06.0000] well, we're telling the modules to start in the right order [09:13:25.0000] it's just, when we tell a to start, it has to work through a bunch of Promise reactions first [09:14:04.0000] It seems like you could add an a-1.then(a-2) chain to do this [09:14:18.0000] Like, add a-1 to a-2's promise.all [09:15:54.0000] I'm just leery of essentially inserting a "rearrange the job queue here" step. [09:16:13.0000] Instead of ensuring the evaluation jobs get queued in the right order in the first place. [09:16:35.0000] isn't that going back to "variant A"? [09:16:45.0000] I think that would be adding more synchronous behavior than what I'm doing here [09:16:49.0000] Hmm [09:17:02.0000] flushing the microtask queue is only about the parts that run synchronously, so it's a lot lighter weight [09:17:14.0000] Yeah, that would be variant A, bad. [09:17:22.0000] I'm just having a fundamental confusion: [09:17:34.0000] HTML ensures that whenever the stack is empty, the job queue is drained [09:17:35.0000] but, a lot of people have had this kind of reaction, that it doesn't smell right to flush the microtask queue [09:17:50.0000] If you have to manually flush the job queue, then that means you are doing so when the stack is not empty [09:17:56.0000] I don't understand why that would be necessary. [09:18:16.0000] when you say stack, do you mean that there's no JS running? [09:18:23.0000] Right. [09:18:33.0000] E.g. when we're waiting on a promise reaction [09:18:45.0000] well, this algorithm is being driven by something that's not JS; there's no JS running [09:19:08.0000] maybe we can do something at the JS level that explains that, duh, the job queue is clearly drained, no need for FlushJobs [09:19:11.0000] Hmm [09:19:23.0000] Maybe that is what I'm missing [09:20:45.0000] We are using jobs and promises, but there is no JS execution context stack, where emptying it triggers the microtask checkpoint... hmmm... [09:21:12.0000] yeah, when you say HTML ensures this, do you mean in https://html.spec.whatwg.org/#event-loop-processing-model ? [09:21:28.0000] I guess the issue is (again) that JS doesn't really have a "processing model" [09:21:49.0000] and this algorithm is one of the few that runs when there's no JS active [09:22:06.0000] No, I mean in https://html.spec.whatwg.org/#clean-up-after-running-script [09:23:52.0000] hmm, so an interesting thing about this algorithm is that we might not actually invoke JavaScript, we might just work our way through some Then reactions and find ourselves still blocked [09:24:55.0000] oh, I guess that will still run the "clean up after running script" algorithnm [09:25:21.0000] right, since that algorithm is run after each microtask [09:25:24.0000] Wait a minute [09:25:34.0000] Are all calls to InnerModuleEvaluation() synchronous? [09:25:38.0000] yes [09:25:47.0000] Oh then it seems this is already aligned with HTML [09:25:55.0000] HTML already calls "clean up after running script" after it calls Evalaute() [09:26:10.0000] that's not the right time, since Evaluate() is only called once, and we need it called after loading each module [09:26:18.0000] No, nevermind, yeah [09:26:50.0000] Right because you are using the job queue for things that could be synchronous, hmm [09:27:01.0000] OK I have to run to a meeting but I am coming around to draining the job queue [09:27:16.0000] I am hopeful my resolution will be to draft a lengthy non-normative note explaining why it makes sense [09:27:40.0000] why FlushJobs makes sense, or why it's not necessary? [09:27:44.0000] Why it makes sense [09:27:51.0000] OK, great [09:28:24.0000] We may want to tweak things a bit so we can do host setup, not just host teardown, before/after each chunk of graph work [09:32:39.0000] that makes sense; I imagine that there could be other kinds of settings to put in place. The big question to answer at this point is whether we're doing a microtask checkpoint or going for all-synchronous execution. [09:33:05.0000] and, if this seems reasonable to you, I'm leaning microtask checkpoint as well [09:35:21.0000] (turns out my meeting was a half-hour later, but now I need to get lunch in 25 minutes, whee) [09:36:11.0000] On the other hand it's a bit weird to anticipate every host adding very similar hooks just so that ES can use the job queue to do sync work [10:41:00.0000] https://github.com/whatwg/html/issues/4175#issuecomment-466047231 about a no-credentials mode instead of CORS is so weird to me. [10:41:22.0000] If we thought intranets didn't matter, we would've just made no-credentials a requirement for outgoing requests long ago and never had to do the CORS business. [10:41:33.0000] Oops, wrong channel [11:19:03.0000] I just learned that `new Date(undefined)` is not the same thing as `new Date()` and I totally want to flip a table right now đŸ€Ż [11:19:22.0000] ...especially given that `new Date(null)` is treated as `new Date(0)` [11:19:27.0000] :shakes fist at legacy apis: [11:19:36.0000] ┬Temporal┬ノ( Âș _ Âșノ) [11:19:46.0000] ljharb: good answer lol [11:31:09.0000] in other news... mathiasbynens: that "shapes get orphaned on field type change after preventExtensions" bug the React folks discovered is really fascinating [11:31:35.0000] I was trying to poke at exactly why the bug doesn't apply to JSC [11:31:45.0000] what bug? [11:32:20.0000] read from here: https://slidr.io/bmeurer/javascript-engine-fundamentals-the-good-the-bad-and-the-ugly#151 [11:34:04.0000] seems like JSC structures don't have the same "new shape that extends from the existing one" pattern that V8 maps have, maybe that's the crux [11:34:17.0000] not sure if i get it without narration [11:42:57.0000] ljharb: so JSObjects have shapes (on-the-fly interfaces kept by the runtime, called "maps" in V8 and "structures" in JSC), and when you add a new property, a new shape gets extended from the old one (in V8 at least, as I understand it), and preventExtensions (or seal or freeze) makes sort of a final extension on top of that. The bug is that if you initialize a field to a small integer, prevent extensions, and then set it to a [11:42:57.0000] double, you'd end up with a new orphaned shape for *every such object*: https://bugs.chromium.org/p/v8/issues/detail?id=8538 [11:44:23.0000] so they realized that to work around you could initialize the field with NaN or Number.MIN_VALUE (so that it's a double to start with) and then set it to whatever value you wanted (like 0, say) -- https://github.com/facebook/react/pull/14383 [11:44:33.0000] really comical and interesting situation [11:45:42.0000] (note that "smi" is evidently the V8ism for "small int") [14:58:43.0000] that's a fun diff 2019-02-25 [01:48:31.0000] rkirsling, ljharb: i'm working on a written version [01:49:40.0000] rkirsling, ljharb: afaict JSC doesn't suffer from this as much since unlike V8, it uses a uniform value representation for all numbers [09:21:15.0000] annevk: lol i hardly think 18 days is “awhile” :-p [09:21:55.0000] everything is relative [10:18:35.0000] It's definitely... slower than we're used to. [10:19:33.0000] https://tc39.github.io/ecma262/#sec-abstract-module-records is it important that every module have an [[Environment]]? I'm guessing yes, that the concept of bindings and thus lexical environments are pretty intimately tied into the machinery? But for example for built-in modules it seems really awkward to create a synthetic "lexical environment" which doesn't have any code, and just has a bunch of bindings which it looks up from [10:19:33.0000] elsewhere. [11:18:22.0000] Domenic: yea, the wording is pretty tied to bindings. is the concern that you don't want to make bindings themselves but something else? [11:19:16.0000] No, it's more "editorial". It seems like it'd be a ton of ceremony to make a built-in module record from an ordered map of strings -> JS values, involving creating a whole new lexical environment with a customized ResolveBinding() that looks things up in the map. [11:19:37.0000] I was hoping we could instead just override ResolveExport() [11:19:59.0000] But I guess ResolveExport() only gives you back a binding name, which you then look up on the [[Environment]]. [11:23:00.0000] yea, i think actually making an env is the best approach for now, though you could work around and use an object environment or something? [11:23:23.0000] Hmm that might save a bit of work [12:07:03.0000] i took an approach where i eagerly bind all the exports from builtin modules as immutable declarations [14:10:44.0000] What does that look like spec wise [14:12:21.0000] Domenic: i'm not 100% sure where the operations go (i think the end of ParseModule?) but it basically just grabs all the standard imports and directly creates immutable declarations to the values from the builtin [14:12:33.0000] Hrm hrm [14:12:35.0000] this assumes there is a syntax for builtins [14:12:46.0000] Well maybe I'll have you review my spec and see what you think, when I write it [14:12:57.0000] alright 2019-02-26 [08:35:44.0000] Hello all, Alex Vincent from last July's TC39 meeting here. leobalter_: ping :) [08:36:15.0000] (still trying to move forward on the test262-integration repository) [09:02:16.0000] hi! WeirdAl I'm still under the water, I'll talk to Rick today about it [09:02:46.0000] I'm currently supporting a teammate who is going on vacation tomorrow. [09:02:53.0000] that's a good reason :) [10:17:46.0000] Turns out environments aren't so bad. https://proposal-javascript-standard-library-domenic.now.sh/#sec-smr-instantiate [10:18:29.0000] lol [10:20:05.0000] Domenic: looks pretty good [10:24:37.0000] \o/ [10:37:15.0000] littledan: where is your spec for wasm module records? I saw it once, rendered, but can't find it... [10:39:26.0000] https://webassembly.github.io/esm-integration/js-api/index.html#esm-integration [10:39:32.0000] But this needs some work [10:39:52.0000] For one, rebasing on the current ES PR as well as TLA [10:40:12.0000] But also a few refactorings within Wasm [10:40:27.0000] Ahh, there's special branch URLs, got it. Thanks [10:41:17.0000] Domenic, see also https://github.com/whatwg/html/pull/4372 [10:41:38.0000] Right, good source of truth [10:46:18.0000] I should remember to look at that [10:46:44.0000] Nits welcome and everything [10:49:11.0000] Btw, in discussing TLA with Georg and Guy, they had some interesting reasons for why https://github.com/tc39/proposal-top-level-await/pull/49 might be preferable to #51; I am not sure which alternative we should recommend at this point, but my next step is to clean up #49 to never look at Promises synchronously [10:49:28.0000] So that we can consider each [10:49:59.0000] I'm trying to work through TLA because Wasm modules depend on the infrastructure [10:51:39.0000] We are happy to have you in the club of people where the most effective way to get things done is to make them dependencies of your work ^_^ [10:56:28.0000] lol [10:58:00.0000] ^_^ 2019-02-27 [09:20:40.0000] jmdyck: for https://github.com/tc39/ecma262/issues/1458 what is the actual data model? Can it contain lone surrogates? [09:21:29.0000] jmdyck: and by UTF-16 encoding do you mean producing bytes? [09:22:28.0000] "ECMAScript source text is a sequence of code points. All Unicode code point values from U+0000 to U+10FFFF, including surrogate code points, may occur in source text where permitted by the ECMAScript grammars." [09:22:37.0000] https://tc39.github.io/ecma262/#sec-source-text [09:24:31.0000] and by UTF-16 encoding, I mean producing (16 bit) code units, like https://tc39.github.io/ecma262/#sec-utf16encoding does. [09:25:00.0000] I guess there already is an issue on ECMAScript using UTF-16 in a very confusing manner [09:25:10.0000] (the term) [09:27:45.0000] I'm not finding such an issue. [09:28:34.0000] indeed hmm [09:32:33.0000] Wow, ES uses "encode" to mean something different than "go from strings to bytes"?? [09:40:42.0000] Domenic: code point to code unit [09:43:23.0000] Domenic: it also has this phrase "UTF-16 encoded Unicode text" which I think goes from String to scalar values [09:43:49.0000] Domenic: it's all pretty clear though, so I'm conflicted on filing an issue [09:56:20.0000] The phrase "the result of parsing [String value], interpreted as UTF-16 encoded Unicode text" means that you (theoretically) have to UTF-16-decode the String value and then parse the resulting sequence of code points as if it was normal source text. (I assume.) [10:12:50.0000] jmdyck: well, proper UTF-16 decode would throw or replace lone surrogates [10:13:11.0000] jmdyck: the spec has a reference after that text which sorta explains what it means, but it's not the best [12:49:07.0000] I've lost track, are public static class fields shipping in enough places to use them in spec examples yet? [12:49:20.0000] Spec examples for new features [12:50:04.0000] Looks like Chrome-only :( [14:49:49.0000] Domenic: re the heart on my comment in the "define exotic object" issue: is the approach I described particularly amenable to layering concerns? [14:50:17.0000] jmdyck: it just seems to actually be way more precise than anything else suggested so far [14:50:43.0000] And it actually addresses the fact that ObjectCreate()'s steps are useful for everyone [14:53:37.0000] An alternative would be to "reify" the brand (I guess as an internal slot), which you could then pass to ObjectCreate/AllocateBasicObject. But then there's the question: what if the brand doesn't 'agree' with the internal methods? [14:56:18.0000] If the brand isn't there, then there can't be disagreement. [14:57:34.0000] (In the hypothetical, the disagreement could only be for host-defined exotics, I think.) [15:27:09.0000] Yes, I think stating the brand / an object's exoticness in terms of the overridden internal methods is the kind of "first principles" approach annevk was looking for. 2019-02-28 [16:15:07.0000] jmdyck: i'd take the approach that simply having the internal slots of X makes you X [18:56:50.0000] devsnek: *slots* specifically, or slots + methods? [18:57:21.0000] slots and methods [19:10:46.0000] that’s a very different thing [19:11:21.0000] “Has the slots” is the brand check; “has the methods” is “inherits from the expected prototype chain”. Exotic objects are exotic unrelated to their prototype. [19:13:38.0000] ljharb: the mop methods [19:14:01.0000] i generally think of mop methods as slots themselves, which is why i didn't specify [19:15:18.0000] oh. i don’t have as much of an opinion about that since the existence of mop methods isn’t user-observable, but it makes sense that the spec would require both [19:45:03.0000] (devsnek said "internal slots" originally. I was taking "internal" as given when I said "slots + methods".) [10:51:45.0000] I can't believe I got so thoroughly nerd-sniped into spending 1.5 hours fixing this mess. [10:52:02.0000] 👀 [10:52:08.0000] I hope it goes through and doesn't drag on too long or I might come to my senses. [10:52:22.0000] (referring to my latest PR on 262) [10:53:37.0000] also don’t feel Domenic i have a PR that I opened with _just_ this link on 01/10 that’s still WIP https://imgs.xkcd.com/comics/nerd_sniping.png [10:55:02.0000] sometimes, you get the crosswalk and sometimes the truck gets youu [11:07:12.0000] Domenic: nice; I’d remove the former editor jab though [12:47:17.0000] Domenic: btw, your PR obsoletes one of mine [12:47:34.0000] annevk: please to link them :-) [12:47:38.0000] (to each other, i mean) [12:47:41.0000] Domenic: I guess I can add a ref tomorrow