| 00:00 | <rkirsling> | whaa |
| 00:00 | <devsnek> | oh wait it didn't |
| 00:00 | <devsnek> | i lied |
| 00:00 | <rbuckton> | ES logical-ish operators work on boolean-ish values like truthy and falsy. |
| 00:00 | <devsnek> | i was accidentally looking at bitwise ops |
| 00:00 | <rkirsling> | yeah phew |
| 00:01 | <ljharb> | rbuckton: some value selection operators pivot on truthiness. `??` is a value selection operator that pivots on nullishness. |
| 00:01 | <rkirsling> | rbuckton: yeah my point is to be really diligent about not mixing "truthy" and "nullish" terminology willy-nilly |
| 00:01 | <ljharb> | neither are logical. |
| 00:01 | <ljharb> | rkirsling: lol |
| 00:01 | <howdoi> | 6 years ago https://usercontent.irccloud-cdn.com/file/uZGwDHvC/sc |
| 00:01 | <rbuckton> | ljharb: A few meetings ago there was a (possibly joking) proposal to introduce strict-logical operators `|||` and `&&&` |
| 00:01 | <rkirsling> | ljharb: :high-five: |
| 00:02 | <ljharb> | rbuckton: lol yes, and those would be logical |
| 00:02 | <howdoi> | https://esdiscuss.org/topic/shorthand-notation-for-attribute-creation |
| 00:02 | <devsnek> | "object creation" good orthogonality |
| 00:02 | <devsnek> | s/object/attribute/ |
| 00:03 | <howdoi> | true that |
| 00:06 | <ystartsev> | rbuckton: omg |
| 00:09 | <devsnek> | if we go with the one where it doesn't call set |
| 00:10 | <devsnek> | does it block exceptions |
| 00:10 | <devsnek> | like `thisDoesNotExist ||= false` |
| 00:10 | <Bakkot> | michaelficarra by "in this proposal" do you mean the short-circuiting variant? |
| 00:10 | <michaelficarra> | yes |
| 00:10 | <rbuckton> | devsnek: if `thisDoesNotExist` is not defined, it would throw on the attempt to read the binding. |
| 00:10 | <devsnek> | oh true |
| 00:10 | <devsnek> | lol |
| 00:10 | <akirose> | haxjs: do you want to do one of your topics after the break (in about 20-30 minutes)? |
| 00:11 | <howdoi> | 2001! |
| 00:11 | <Bakkot> | I have notes in my closet about adding class fields dating back to 1999 |
| 00:11 | <rbuckton> | sffc: optional chaining doesn't permit assignment. |
| 00:12 | <rbuckton> | (as much as I would rather it did). |
| 00:12 | <howdoi> | Bakkot: wow! |
| 00:13 | <ystartsev> | sffc: optional chaining disallows assignment atm |
| 00:21 | <rbuckton> | That `a?.setValue(b)` works but `a?.value = b` doesn't is unfortunate to me. |
| 00:21 | <devsnek> | seems reasonable to me |
| 00:21 | <Bakkot> | yeah I am really happy that doesn't work |
| 00:23 | <robpalme> | breaking until 14:33 (10 mins) |
| 00:27 | <brad4d> | kiwi IRC keeps dropping my connection - what linux clients are folks using? |
| 00:28 | <akirose> | irssi |
| 00:28 | <akirose> | irssi running in tmux is what i used to use on linux |
| 00:28 | <akirose> | err no it was running in screen |
| 00:29 | <akirose> | i fell in love with tmux only in the past 5 or 10 years |
| 00:39 | <devsnek> | hearing "filter in" confuses me |
| 00:39 | <rkirsling> | ^ |
| 00:39 | <rbuckton> | Do any existing languages use `filterOut`? Scala and Kotlin use `filterNot` |
| 00:39 | <devsnek> | if you start with "filter out" then "filter in" makes sense |
| 00:39 | <devsnek> | but the other way around makes my brain not understand |
| 00:39 | <rkirsling> | I don't like `filterOut` because "filter in" is not an English phrase |
| 00:39 | <rkirsling> | but `filterWithout` might be not unthinkable? |
| 00:39 | <michaelficarra> | brad4d: I use empathy typically, but it's not working here due to blocked ports |
| 00:39 | <rbuckton> | I like `filterNot` because the semantics and name have precedence in other languages. |
| 00:40 | <michaelficarra> | so for now I'm using the freenode webchat |
| 00:40 | <rkirsling> | rbuckton: ditto but Justin doesn't like it |
| 00:40 | <rbuckton> | I would argue for prior art as it helps developers of multiple languages make sense of the feature. |
| 00:41 | <devsnek> | removeIfCallbackReturnsTrue |
| 00:41 | <devsnek> | actually |
| 00:41 | <devsnek> | remove and keep |
| 00:41 | <devsnek> | π |
| 00:42 | <rbuckton> | `.excludeIf` :/ |
| 00:42 | <devsnek> | i don't like having "if" in the name |
| 00:42 | <devsnek> | removeIf and keepIf work though |
| 00:42 | <ljharb> | `.omit`, if we're not calling it filter something? |
| 00:42 | <rbuckton> | Me either. |
| 00:42 | <devsnek> | exclude is also a negative which is not ideal |
| 00:42 | <rbuckton> | `.omit` is interesting. |
| 00:43 | <devsnek> | omit and emit |
| 00:43 | <rbuckton> | devsnek: `exclude` is also the opposite of `include`, which is already used for a different meaning on arrays (i.e. ,`.includes(value)`) |
| 00:43 | <rbuckton> | devsnek: That'll just be another `wake` and `wait` problem. |
| 00:43 | <devsnek> | rbuckton: yeah i being facetious |
| 00:43 | <michaelficarra> | `Function.prototype.not = function() { let self = this; return function() { return !self.apply(this, arguments); }; };` |
| 00:44 | <devsnek> | oh no |
| 00:44 | <michaelficarra> | oh yes |
| 00:44 | <rbuckton> | oh the overhead |
| 00:44 | <rkirsling> | oh the humanity |
| 00:44 | <rkirsling> | (sorry) |
| 00:44 | <devsnek> | bindInverse |
| 00:45 | <rkirsling> | I think I'd support `.omit` |
| 00:45 | <devsnek> | omit is good |
| 00:45 | <devsnek> | assuming its the opposite of what filter does |
| 00:45 | <michaelficarra> | `reject` is fine |
| 00:45 | <devsnek> | i don't know what it does |
| 00:45 | <devsnek> | off the top of my head |
| 00:45 | <michaelficarra> | also I still kinda prefer groupBy/partition, we can kill two birds with one stone |
| 00:45 | <rbuckton> | I dislike `reject` because of possible `Promise.reject`confusion. I like `filterNot`, but `omit` isn't terrible. |
| 00:46 | <rbuckton> | I'd love `groupBy` |
| 00:46 | <rkirsling> | yeah I think the Promise.reject concern is legitimate too |
| 00:46 | <devsnek> | as in |
| 00:46 | <devsnek> | partition into two groups |
| 00:46 | <devsnek> | keep one? |
| 00:46 | <rbuckton> | Then again, my iterable-quer package has `groupBy`, so I'm biased. |
| 00:46 | <rbuckton> | *query |
| 00:46 | <michaelficarra> | devsnek: yeah, a special-cased groupBy |
| 00:47 | <devsnek> | why not just sort and slice |
| 00:47 | <devsnek> | :) |
| 00:47 | <michaelficarra> | justin has argued against groupBy/partition because of the perceived overhead from returning a container and taking out the bit you care about |
| 00:48 | <devsnek> | i wouldn't use partition to filter |
| 00:48 | <devsnek> | if it were a thing |
| 00:48 | <michaelficarra> | but I don't think we should really care about the wrappers that often don't actually have to be realised |
| 00:48 | <devsnek> | i'd use it to partition |
| 00:48 | <rbuckton> | Yeah, if you don't want the `false` values, `partition` would have unnecessary overhead since it would produce both sides of the condition. |
| 00:49 | <michaelficarra> | rbuckton: not necessarily though |
| 00:50 | <michaelficarra> | when you pull the thruthy result out immediately and the falsey result is unobservable, the engine doesn't need to realise it |
| 00:51 | <michaelficarra> | this kind of optimisation (the same we discussed earlier with Object.iterateKeys) seems fairly straightforward to me |
| 00:51 | <devsnek> | lot of overhead for non-jit impls |
| 00:51 | <devsnek> | especially in embedded case |
| 00:51 | <devsnek> | where memory is tight |
| 00:51 | <michaelficarra> | non-jit impls are dog slow ayway, who cares? |
| 00:51 | <michaelficarra> | *anyway |
| 00:51 | <devsnek> | performance isn't the only concern |
| 00:52 | <devsnek> | if you only have 64k of ram you can't be wasting it on unused arrays |
| 00:52 | <rbuckton> | Yeah. Even in a jit impl, you still need to hold onto all of the memory *just in case* the calling code requests it. |
| 00:52 | <michaelficarra> | rbuckton: there's no "just in case" when you can prove there's no way to observe it |
| 00:53 | <devsnek> | it may not always be as simple as partition(xyz)[0] |
| 00:54 | <devsnek> | my point was basically just "jit will make it usable" is not a great choice imo |
| 00:54 | <devsnek> | don't want to get too into the weeds of how things jit |
| 00:54 | <jridgewell> | `filterNot` only works as a name if you understand what `filter` does |
| 00:54 | <rbuckton> | Also depends on engine implementers actually implementing the optimization, which could take time depending on their backlog and other work. |
| 00:55 | <jridgewell> | The "not" doesn't imply what's happening |
| 00:55 | <michaelficarra> | π€· you don't even need a JIT, keith_miller was saying it could probably be done at the interpreter level |
| 00:55 | <michaelficarra> | and I agree |
| 00:55 | <jridgewell> | It's simply inverting `filter`, which is my problem, I can't remember what `filter` does. |
| 00:55 | <rbuckton> | jridgewell: You said your self, every language that uses `filter` has the same semantics as JS, so it seems fairly obvious what `filterNot` would mean to those developers. |
| 00:55 | <devsnek> | interpreter is one of the stages of jit |
| 00:55 | <michaelficarra> | jridgewell: I think that regardless of what comes of this proposal, you're going to start remembering what filter does now |
| 00:55 | <michaelficarra> | problem solved |
| 00:55 | <devsnek> | (i assume no implementations are doing AST walks?) |
| 00:56 | <jridgewell> | Every language is wrong. π |
| 00:56 | <devsnek> | (aside from engine262) |
| 00:56 | <devsnek> | i actually do know what splice does now |
| 00:58 | <devsnek> | michaelficarra: the point is that we shouldn't rely on engines performing optimizations to js code |
| 00:58 | <devsnek> | like something that walks over an ast tree is a valid (but slow) implementation |
| 00:58 | <michaelficarra> | I think we can't make performance-based justifications in the absence of information about performance optimisations |
| 00:59 | <rkirsling> | I think that just means we shouldn't make perf-based justifications for this? |
| 01:02 | <rbuckton> | Aside from perf discussions, it's a high bar to expect developers to reason that the opposite of `filter` is `partition(...)[0]` or `partition(...)[1]`, as they'd likely need to review documentation on `partition` to know which array was which. |
| 01:03 | <rkirsling> | yeah I don't really think those conversations should be merged |
| 01:03 | <michaelficarra> | rbuckton: who said array? |
| 01:03 | <michaelficarra> | `partition(...).true` |
| 01:04 | <michaelficarra> | `groupBy(...).true` |
| 01:04 | <michaelficarra> | same thing |
| 01:04 | <rbuckton> | I'd like `filterNot` (whatever it is named) for perf-critical scenarios, as there are a lot of *positive* filter callbacks out there (like `isString`, etc.), but you rarely see an `isNotString`, so you end up with a lot of `.filter(x => !isString(x))`, which produces more overhead than a `.filterNot(isString)`. |
| 01:05 | <rkirsling> | rbuckton: I mean you could reasonably expect that it would *eventually* lead to better perf but it wouldn't be a spec conformance req |
| 01:05 | <rbuckton> | michaelficarra: Definitely wouldn't use `groupBy` like that (i'd expect to be able to group by other keys besides booleans that may not have a reliable `toString` implementation). `partition` maybe, since all the `partition` implementations I've seen only split on boolean. |
| 01:06 | <littledan> | we've discussed the rationale for BigInt's JSON semantics at length in TC39; I'd be happy to follow up with anyone offline for background here |
| 01:16 | <michaelficarra> | why hasn't there been as much screaming about not being able to round trip undefined values? |
| 01:16 | <ystartsev> | ok folks, im out |
| 01:17 | <michaelficarra> | ECMAScript distinguishes null from undefined pretty consistently, for better or worse |
| 01:17 | <ystartsev> | ill be back in the morning |
| 01:17 | <ljharb> | michaelficarra: i assume because most languages don't have two nil values |
| 01:17 | <jridgewell> | π |
| 01:17 | <michaelficarra> | but in JSON we just convert to null and call it a day |
| 01:17 | <rkirsling> | π |
| 01:17 | <michaelficarra> | ljharb: but we are ECMAScript |
| 01:17 | <jridgewell> | michaelficarra: I've actually written code that depends on undefined not being round-tripped for security |
| 01:18 | <michaelficarra> | jridgewell: the question is why do people care so much about round-tripping of BigInt but not undefined? |
| 01:18 | <ljharb> | because undefined is one value, and it's not that useful to know it's there, but bigint represents infinite values |
| 01:19 | <michaelficarra> | ljharb: finite but very many |
| 01:20 | <ljharb> | sure |
| 01:20 | <apaprocki> | we get questions for NaN all the time |
| 01:20 | <michaelficarra> | infinite strings of characters are not valid JSON I believe |
| 01:20 | <ljharb> | a great many, then, the point stands |
| 01:20 | <michaelficarra> | apaprocki: same thing! |
| 01:21 | <bterlson> | wait, did ecma404 add a size limit?? |
| 01:22 | <michaelficarra> | bterlson: not a finite one, no |
| 01:22 | <devsnek> | lol |
| 01:23 | <devsnek> | ljharb: they have infinite precision but can only represent finite numbers |
| 01:24 | <apaprocki> | philosophical question.. does a string of infinite length have a trailing "? |
| 01:24 | <Bakkot> | "arbitrarily many" |
| 01:24 | <Bakkot> | apaprocki mu |
| 01:25 | <devsnek> | infinity+1 |
| 01:25 | <Bakkot> | oh this is the wrong channel again |
| 01:25 | <michaelficarra> | as the meeting goes on, #tdz slowly merges with #tc39-delegates |
| 01:26 | <akirose> | every time |
| 01:28 | <rkirsling> | truly every time |
| 01:28 | <rkirsling> | this doesn't bode well for tomorrow |
| 01:35 | <littledan> | from remote I can hear Ron very well |
| 01:35 | <littledan> | Brian also talked |
| 01:35 | <littledan> | he's talking now |
| 01:35 | <Bakkot> | thanks littledan |
| 01:35 | <Bakkot> | our speaker is quiet for some reason |
| 01:35 | <Bakkot> | trying to fix it |
| 01:35 | <Bakkot> | fixed! |
| 01:38 | <littledan> | the comment about methods on each TypedArray prototype seems misplaced: the built-in methods are on the shared superclass |
| 01:42 | <cmorningstar> | michaelficarra an infinite string of characters *might* be valid JSON, but it's too soon to tell. |
| 01:43 | <michaelficarra> | I guess we'll just agree that it both is and isn't for now |
| 01:46 | <devsnek> | we are not using webidl |
| 01:46 | <devsnek> | in node core |
| 01:46 | <devsnek> | MylesBorins: |
| 01:47 | <shu> | SDO = standards development body btw |
| 01:49 | <rkirsling> | "org" you mean? |
| 01:50 | <bterlson> | SDO = Software Documentation Outhouse |
| 01:50 | <akirose> | pedant π |
| 01:50 | <bterlson> | wrong channel sorry |
| 01:50 | <littledan> | devsnek: Well, you might benefit in terms of spec compliance if you used a generator, and tests based on idlharness.js |
| 01:50 | <littledan> | my coworker Joyee has been working on applying this in Node.js Core, for existing APIs |
| 01:51 | <rkirsling> | akirose: oh sorry, I was actually making sure myself >_< |
| 01:51 | <devsnek> | littledan: yeah not saying we shouldn't |
| 01:51 | <devsnek> | just that we currently don't |
| 01:51 | <devsnek> | i love what jsdom does |
| 01:51 | <littledan> | oh right of course you know about this already, sorry for being redundant |
| 01:51 | <littledan> | my understanding was that WebCrypto in Node Core was pretty early |
| 01:52 | <devsnek> | currently separate repo https://github.com/nodejs/webcrypto |
| 01:55 | <michaelficarra> | we LITERALLY define subtraction by normative reference to another spec! |
| 01:55 | <michaelficarra> | what is this example?! |
| 01:55 | <Bakkot> | amazing |
| 01:55 | <michaelficarra> | same with Intl and the Unicode data sets |
| 01:59 | littledan | holds self back from clarifying, again, that we don't reference CLDR or ICU |
| 01:59 | <littledan> | oh, I guess I didn't do that right |
| 01:59 | <littledan> | (we do reference the Unicode Character Database) |
| 02:02 | <michaelficarra> | π |
| 02:03 | <littledan> | that comment in the WebCrypto repo was made by a W3C staffer. It's not clear how this relates to other W3C participants think. |
| 02:04 | <littledan> | and it's not clear what's meant by referencing the definition: should it observably call it, as we're talking about UUID doing? |
| 02:04 | <littledan> | https://github.com/w3c/webcrypto/issues/227 |
| 02:04 | <Bakkot> | littledan oh, ok. he has the commit bit on the repo so I assumed he was the maintainer for these purposes |
| 02:07 | <littledan> | the W3C often performs useful functions in terms of releasing specifications and helping with broad review, so commit bits are not surprisng |
| 02:07 | <ljharb> | rbuckton: please lmk when you've renamed the proposal/repo, and i'll update the proposals repo |
| 02:07 | <rbuckton> | Sure. |
| 02:08 | <Bakkot> | littledan is there way to answer the question of what other W3C participants think? |
| 02:09 | <littledan> | Bakkot: Yeah, maybe you could reconvene the WebCrypto WG, whose charter expired? :) |
| 02:09 | <Bakkot> | uh |
| 02:09 | <Bakkot> | would prefer to not do that |
| 02:09 | <Bakkot> | Would reconvening be necessary if it's just a matter of shuffling which things are in which spec? |
| 02:12 | <littledan> | maybe starting with an email to the person who filed that issue (who's been landing things), the person listed as editor, and the other person landing things over the past year? |
| 02:13 | <littledan> | there's an interesting question of whether we care about a new standard being released, or whether it'd be enough to get an update into the editor's draft |
| 02:14 | <littledan> | long-brewing W3C work would enable just updating the editor's draft and not worrying. Lots of people just update the draft and are happy, even in the absence of this procedure. |
| 02:16 | <littledan> | Bakkot: Are we talking about an observable change, or just an editorial one? |
| 02:17 | <Bakkot> | littledan it sounds like Shu would not want changes where were observable from the perspective of web developers |
| 02:21 | <littledan> | Bakkot: Are you suggesting that we have two API entrypoints that reference the same internal algorithm, which is the CSRNG? |
| 02:21 | <ljharb> | that'd be the typical way these things are done; but i assume it's easier to virtualize if there's one, not two entry points that need replacing |
| 02:22 | <Bakkot> | littledan I am suggesting ECMA262 requires hosts to have a global named `crypto` which is required to have a property named `getRandomValues` which is specified to do exactly the thing the W3C crypto.getRandomValues does right now |
| 02:22 | <littledan> | oh, I see |
| 02:22 | <Bakkot> | possibly first make the observable change which would allow you to invoke it without `crypto` being the receiver, which is dumb |
| 02:23 | <jridgewell> | Wouldn't they be more annoyed that we "claimed" their object? |
| 02:23 | <littledan> | this would be slightly complicated to do unobservably--crypto.getRandomValues follows WebIDL, not ECMA-262, conventions. But it sounds possible to me. I'm not sure if the committee might have additional requirements (like this weakening you're suggesting) |
| 02:23 | <jridgewell> | `crypto` is a Web object |
| 02:24 | <rbuckton> | Bakkot: does it today? Unless its a WebIDL thing, I don't see anything in the spec text that enforces that. |
| 02:24 | <Bakkot> | rbuckton it is a webidl thing |
| 02:24 | <Bakkot> | jridgewell well, we'd have to ask |
| 02:24 | <Bakkot> | I would hope not |
| 02:24 | <devsnek> | it wouldn't be the first time a spec left w3c |
| 02:25 | <rbuckton> | My concern is that if ECMAScript ships a global `crypto` object, how would the crypto API make that a `Crypto` object (which also has a `subtle` property for `SubtleCrypto`)? Would we have to specify the prototype is "host defined"? |
| 02:26 | <littledan> | Bakkot: so, I'd lay that option out clearly in the issue, and then ping the people who have been landing patches and who maintain implementations |
| 02:26 | <ljharb> | rbuckton: it'd probably have to ship a CryptoPrototype, so that there was a place for the web to stick stuff on |
| 02:26 | <rbuckton> | Or would the host just augment a theoretical `%cryptoprototype%`? |
| 02:26 | <ljharb> | ^ that |
| 02:26 | <Bakkot> | yeah that |
| 02:26 | <rbuckton> | There's a possible web-compat problem though. |
| 02:27 | <Bakkot> | Is there? |
| 02:27 | <littledan> | WebIDL is specified in terms of stuff that ES exposes |
| 02:27 | <littledan> | we could do just the same things, and make the change unobservable |
| 02:27 | <rbuckton> | Yeah, code that might feature test for `crypto` vs `require("crypto")`. |
| 02:27 | <littledan> | or, we could decide that we don't like the looks of it and it must change |
| 02:27 | <Bakkot> | littledan right, I meant, I want to be able to do `(0, crypto.getRandomValues)()` and have that work |
| 02:27 | <Bakkot> | this was more of an aside |
| 02:27 | <ljharb> | rbuckton: true, but that kind of code would break with any new global |
| 02:27 | <rbuckton> | https://github.com/rbuckton/reflect-metadata/blob/master/Reflect.js#L1099 |
| 02:28 | <littledan> | rbuckton: Sounds like you're talking about a Node-compat problem? But then the WebCrypto-in-Node effort faces that anyway |
| 02:28 | <ljharb> | rbuckton: that wouldn't break, that'd just start working better once the global appeared |
| 02:28 | <Bakkot> | rbuckton that isn't web compate, it's node compat, right? |
| 02:28 | <rbuckton> | Then again, that wouldn't break because it *does* use `getRandomValues`, but there could be others. |
| 02:28 | <littledan> | anyway there could be ecosystem compat problems due partial implementations, yes |
| 02:28 | <ljharb> | if node suddenly added a matching `crypto`, then your code Just Works |
| 02:29 | <wsdferdksl> | rbuckton: I get a 404 on this link from the proposal: https://rbuckton.github.io/proposal-arraybuffer-fillrandom |
| 02:29 | <ljharb> | and if the code needs `crypto.foo` and isn't checking for the presence of `crypto.foo` then it's brittle anyways |
| 02:29 | <rbuckton> | wsdferdksl: I just transferred it to tc39-transfer |
| 02:29 | <littledan> | Bakkot: Right, I'm pretty worried that there are several different things that are different about WebIDL from TC39's work, and making the change unobservable would be controversial for us |
| 02:29 | <rbuckton> | Ah, there's no spec text generated yet. |
| 02:29 | <littledan> | I'd really prefer that, if we do port it, that we don't make these changes |
| 02:29 | <Bakkot> | littledan yeah, it would be a two-step thing |
| 02:30 | <Bakkot> | ideally get them to change, and then port it |
| 02:30 | <littledan> | remember, TC39's changes to TypedArrays still aren't ecosystem reality |
| 02:30 | <Bakkot> | but alternatively just don't worry about it |
| 02:30 | <rbuckton> | Rather, there's no ecmarkup generated spec text yet. |
| 02:30 | <littledan> | some of them are, some of them aren't |
| 02:30 | <Bakkot> | and do the thing W3C says |
| 02:30 | <ljharb> | wsdferdksl: https://tc39-transfer.github.io/proposal-csprng/ |
| 02:30 | <ljharb> | wsdferdksl: the url will change again tho once a chair (akirose robpalme MylesBorins bterlson) bounces it into the tc39 org |
| 02:30 | <akirose> | on it |
| 02:31 | <ljharb> | oh lol the spec is empty anyways |
| 02:31 | <ljharb> | akirose: ty |
| 02:31 | <rbuckton> | There's nothing in there right now though. All of the current spec text exists in the explainer. |
| 02:31 | <Bakkot> | littledan: fwiw the change I want to crypto.getRandomValues is just making a non-error into an error, so I am almost certain is web compat |
| 02:31 | <rbuckton> | I'll clean that up once the transfer process has completed. |
| 02:32 | <wsdferdksl> | The links towards the end point to the rbuckton.github.io version. |
| 02:32 | <michaelficarra> | Bakkot: you mean the other way around? |
| 02:32 | <rbuckton> | I can fix that too. Its surprising GH doesn't auto-forward those like it does for other URLs related to a transfer. |
| 02:32 | <Bakkot> | michaelficarra uh yeah that |
| 02:33 | <littledan> | Bakkot: There's also a question of how much extra work it will be to go and weaken this. And if you look at everything, I bet you'll come up with more changes you feel like making |
| 02:33 | <littledan> | *work in implementations |
| 02:34 | <ljharb> | rbuckton: unfortunately there's no easy way to forward both |
| 02:34 | <Bakkot> | littledan I have looked at everything and that is the only change I think is worth making |
| 02:34 | <ljharb> | rbuckton: if you ever make a new repo with the same name as an old name, it breaks the repo redirects |
| 02:35 | <rbuckton> | ljharb: There wasn't anything substantive in there anyways, so I'll adjust the URL once the transfer finishes. |
| 02:39 | <ljharb> | kk |
| 02:40 | <sffc> | I also added one more 30-min timebox to the end of the agenda of we have time tomorrow |
| 02:42 | <michaelficarra> | sffc: I think we should add agenda items in the appropriate order, regardless of whether they were added late |
| 02:42 | <robpalme> | sffc: we currently have 3hrs 50mins of content to fit into a 5 hour window. so we will probably have time to add your 30min topic |
| 02:42 | <michaelficarra> | leave it to the chairs to prioritise |
| 02:44 | <rbuckton> | I've just redirected the spec link to the #todo section for now. |
| 02:44 | <shu> | slides seem pretty slow to advance |
| 02:44 | <jridgewell> | Dan is always super laggy on calls. |
| 02:45 | <michaelficarra> | I think littledan just always has some delay |
| 02:47 | <littledan> | sorry! were you able to understand me anyway? |
| 02:48 | <littledan> | I'm not sure how to remove the delay? |
| 02:48 | <jridgewell> | It was only the slides |
| 02:49 | <jridgewell> | So your audio seemed fine |
| 02:49 | <jridgewell> | But you were talking about something before we could see the slide you were discussing |
| 02:49 | <Bakkot> | keith_miller https://tc39.es/proposal-weakrefs/#sec-liveness |
| 02:49 | <Bakkot> | "WeakRef.prototype.deref being called on a WeakRef whose referent is obj" |
| 02:49 | <littledan> | oh, well, you know, the slides are linked from the agenda |
| 02:54 | <Bakkot> | shu I am pretty sure the liveness definition doesn't do what you want: if you have `a = {}; b = { a }; a.b = b;` and then WeakRefs to both `a` and `b`, and you lose access to both `a` and `b` but keep access to both WeakRefs, then `a` and `b` are still live, which seems bad |
| 03:59 | <rbuckton> | shu: I put up a draft PR to explore the possibility of devising a web-compatible `crypto` global in place of `ArrayBuffer.fillRandom`: https://github.com/tc39-transfer/proposal-csprng/pull/2 |
| 04:00 | <shu> | thank you |
| 19:40 | <gibson042> | michaelficarra: |
| 19:40 | <gibson042> | $ eshost -se 'Object.keys({[2**32+3]:true, [2**32+2]:true, [2**32+1]:true, [2**32]:true, [2**32-1]:true, [2**32-2]:true, [2**32-3]:true}).map(n => n-2**32)' |
| 19:40 | <gibson042> | #### Chakra, JavaScriptCore, SpiderMonkey, V8, XS |
| 19:40 | <gibson042> | -3,-2,3,2,1,0,-1 |
| 20:01 | <littledan> | note, it was possible to hear Yulia from remote |
| 20:02 | <brad4d> | in the room we have to turn on a microphone next to a zoom speaker to hear remote folks :) |
| 20:02 | <brad4d> | now fixed |
| 20:06 | <littledan> | note, I'd be happy to do this for all of my presentations as well, I'm just not sure how to set it up |
| 20:06 | <devsnek> | recordin? |
| 20:06 | <devsnek> | g |
| 20:06 | <littledan> | yes |
| 20:06 | <littledan> | it's a good idea to help share information around |
| 20:06 | <devsnek> | if you happen to be zooming you can use zoom |
| 20:06 | <devsnek> | otherwise obs works well |
| 20:07 | <littledan> | maybe the committee could help facilitate this recording too, and storing and presenting the uploaded videos |
| 20:12 | <bterlson> | I made this thing using Moddable's stuff: https://twitter.com/bterlson/status/1219461543647039490. This keyboard firmware will allow (safe) extensions too thanks to this SES stuff. |
| 20:12 | <bterlson> | https://gist.github.com/bterlson/c615924c7ef7bb5d45908cdb6417c3be is a code dump from a few weeks ago |
| 20:13 | <michaelficarra> | what non-static scoping is Mark referring to here? |
| 20:13 | <michaelficarra> | I assumed it was globals |
| 20:23 | <gibson042> | I like the Caridy's vocabulary from https://docs.google.com/presentation/d/1pkxAvJQvL-DeiygPFfs4ecdV39Cfv8cBe-zAfunhp5A/edit#slide=id.g75cbab44da_0_106 : "Primordials are the subset of Intrinsics that are reachable by ECMAScript source text" |
| 20:30 | <MylesBorins> | littledan: I can make sure that it is recording |
| 20:30 | <MylesBorins> | module attributes or do you have another presentation? |
| 20:31 | <littledan> | MylesBorins: I'd be happy with this; I probably should've recorded the decimal one |
| 20:34 | <michaelficarra> | for those with difficulty with colours, the MR items are all green, the first CMR item is blue and the rest are red, and the first 3 items of the STMR are blue, the last is red |
| 21:00 | <devsnek> | how does importSync work |
| 21:00 | <devsnek> | that doesn't make sense to me |
| 21:09 | <michaelficarra> | devsnek: different questions |
| 21:09 | <michaelficarra> | nobody answered you because you asked how it works |
| 21:09 | <michaelficarra> | not whether he described how it works |
| 21:09 | <devsnek> | oh fair point |
| 21:11 | <michaelficarra> | https://i.imgflip.com/3oev83.jpg |
| 21:11 | <littledan> | I guess importSync makes sense if modules are provided by a static map. It seems unfortunate to lose the dynamic case, but I can understand that, for some environments, it doesn't make sense |
| 21:11 | <littledan> | so I guess importSync would be unavailable if you provide a host hook for modules rather than the module map |
| 21:11 | <littledan> | (?) |
| 21:12 | <devsnek> | π€·π» |
| 21:13 | <michaelficarra> | I needed this for a time elapsed/remaining display on effectively a video player we were making, just last week |
| 21:13 | <littledan> | this presentation is great |
| 21:13 | <littledan> | concreteness is really good |
| 21:13 | <michaelficarra> | littledan: agreed, I love seeing a variety of justifications up front |
| 21:14 | <michaelficarra> | needs an Oxford comma option though |
| 21:14 | <michaelficarra> | (or just include it always, fine by me) |
| 21:14 | <ljharb> | +1 |
| 21:14 | <mmarchini> | formatting time duration is a pain on every language I had to do it so far |
| 21:15 | <mmarchini> | would love to see it improved on JS |
| 21:16 | <sffc> | jridgewell: yes, I think that's a typo |
| 21:24 | <michaelficarra> | oh man I'm going to miss the desk mics so much when we don't have them |
| 21:35 | <rbuckton> | There's an unfortunate web-compat issue I need to work out for CSPRNG if we intend to bring in part of WebCrypto: https://github.com/tc39/proposal-csprng/issues/5 |
| 21:35 | <rbuckton> | Basically, WebCrypto throws `TypeMismatchError` and `QuotaExceededError`, but my current spec text just reuses `TypeError` and `RangeError`. It wasn't a web-compat issue when the API was attached to `ArrayBuffer` (because it wouldn't break existing code), but *is* a web-compat issue if we chose to bring in the global `crypto` object. |
| 21:36 | <rbuckton> | s/chose/choose |
| 22:16 | <haxjs> | can't find today's notes url... |
| 22:16 | <haxjs> | Could anyone repaste it? |
| 22:17 | <jridgewell> | Donβt paste it here |
| 22:17 | <jridgewell> | Itβs on the reflector |
| 22:17 | <jridgewell> | 1 sec |
| 22:18 | <jridgewell> | https://github.com/tc39/Reflector/issues/271 |
| 22:18 | <haxjs> | ok! thank you! |
| 22:18 | <devsnek> | when are we resuming |
| 22:19 | <jridgewell> | 12:30 |
| 22:33 | <rbuckton> | Are there slides? |
| 22:34 | <Bakkot> | not that we are seeing |
| 23:21 | <shu> | akirose: robpalme: could you double check at the next meeting break that we retained consensus for independent lifetime FinalizationGroups? (retained in the sense this was the original, historical intent of the proposal, if confusing.) this was kind of implied by people saying they're okay with changing the name of the constructor to better reflect independent lifetimes and i'd like it explicitly asked |
| 23:22 | <ljharb> | bradleymeck: that's not a bug, that's by design - everything >= the first default argument is optional |
| 23:23 | <robpalme> | shu: ack |
| 23:26 | <bradleymeck> | ljharb: i'm not arguing the intent, but that bugs in libraries have occured due to misunderstanding and usage in the wild has shown issues |
| 23:28 | <ljharb> | k |
| 23:39 | <ljharb> | can we get istvan set up on the queue |
| 23:43 | <ljharb> | can a chair interrupt him please? there's later queue items about time zones and stuff |
| 23:43 | <ljharb> | akirose: robpalme MylesBorins ^ |
| 23:49 | <ljharb> | akirose: totally fair point about stage 4 :-p |
| 23:49 | <akirose> | it came up in a panel at some point |
| 23:50 | <akirose> | "how fast can you ship a feature" |
| 23:50 | <akirose> | something like that |
| 23:50 | <ljharb> | i guess theoretically a patch to a browser, timed right before a release hits the train, could get out in a matter of weeks, with the cooperation of the browser? |
| 23:53 | <Bakkot> | browsers can ship things before stage 3 if they want |
| 23:53 | <michaelficarra> | I super agree with Saboff's point |
