| 04:40 | <devsnek> | shu: would my item methods CL be good to continue with the new consensus? |
| 04:41 | <shu> | devsnek: yep, should be a simple rename |
| 04:41 | <devsnek> | cooleo |
| 04:43 | <devsnek> | shu: rename is `at` right? notes don't say |
| 04:43 | <shu> | yep, at |
| 04:43 | <shu> | if that is also not web compat, i floated itemAt and didn’t hear any opposition |
| 04:44 | <rkirsling> | fyi https://trac.webkit.org/changeset/270005/webkit |
| 04:45 | <devsnek> | i'm gonna just call this flag `--harmony-indexing-methods` |
| 04:46 | <shu> | relative-indexing? |
| 04:47 | <devsnek> | `Genesis::InitializeGlobal_harmony_relative_indexing_methods` probably not the longest method name but its up there |
| 04:48 | <rkirsling> | I mean "at method" is unlikely to clash with another feature proposal tbh |
| 04:48 | <devsnek> | i just don't want to rename the flag again, it causes v8 to fully rebuild 😫 |
| 08:57 | <haxjs> | Have we started? |
| 08:58 | <robpalme> | 2 mins until we start |
| 09:02 | <robpalme> | we have started hax with Extensions for Stage 1 |
| 09:19 | <michaelficarra> | I appreciate how well the history of this proposal was researched |
| 09:23 | <akirose> | yeah same, ⭐️gold star⭐️ for haxjs the research is fantastic |
| 09:23 | <wsdferdksl> | Why did the administrator disable video? |
| 09:23 | <akirose> | ? |
| 09:23 | <wsdferdksl> | On Teams. |
| 09:24 | <wsdferdksl> | "Video sharing is disabled by the administrator." |
| 09:24 | <akirose> | sounds like a bug or something. recommend restart client i guess? |
| 09:25 | <wsdferdksl> | Restarting the client fixed it. |
| 09:25 | <wsdferdksl> | Thanks! |
| 09:33 | <rbuckton> | I wonder how feasible overriding `.` dispatch might be in JS if we used syntax similar to some of these other languages, especially if we're considering something like `with operators from M`, would `with extensions from M` allow implementations to optimize property lookup given what's known about the lexical scope and current running environment, or would this be just as bad as legacy `with (x) {}`? |
| 09:36 | <michaelficarra> | okay 1::px is a pretty cool use |
| 09:37 | <Bakkot> | +1 michaelficarra's queue item |
| 09:37 | <rbuckton> | At one point I proposed infix `'` for that kind of notation, which is something C++ considered (i.e., `1'px`) |
| 09:39 | <ljharb> | sorry i'm late, forgot to set an alarm :-/ |
| 09:41 | <michaelficarra> | I think this proposal is much too worked out for this early stage, but I'm pretty excited for how much mileage we can get out of a single feature |
| 09:42 | <shu> | i've taken the opposite gut reaction about readability than the intended one |
| 09:43 | <ljharb> | haxjs: is there a slides iink? |
| 09:43 | <rbuckton> | We also could have gotten that from the prior `::` bind proposal, or the various `|>` proposal versions. |
| 09:43 | <rricard> | it is in the notes |
| 09:43 | <ljharb> | rricard: thanks |
| 09:43 | <rricard> | http://johnhax.net/2020/tc39-nov-ext/slide |
| 09:43 | <rbuckton> | i.e., `1|>px` is just as terse. |
| 09:44 | <michaelficarra> | I mean pipeline is cool too |
| 09:44 | <shu> | rbuckton: i would be uncomfortable for this to coexist with pipeline proposals at stage 2+ |
| 09:45 | <shu> | this is already a different way to do dispatch |
| 09:45 | <michaelficarra> | shu: they are different precedence, which makes uage considerably different |
| 09:45 | <shu> | to add to the matrix a different way to do function composition as well only compounds my readability worries |
| 09:46 | <michaelficarra> | shu: you should state your concerns about the proposal overlap though, because I agree it should at least be researched and addressed |
| 09:46 | <shu> | sure |
| 09:47 | <rbuckton> | shu: `::` and `|>` (F# style) are similar operators except that `::` calls the RHS with the LHS as `this`, and `|>` calls the RHS with the LHS as the first argument. They both serve a need, although I do see `|>` being more flexible (regardless of the version). |
| 09:49 | <gibson042> | the point is that it's easier to convert `this` to an argument than vice versa, right? |
| 09:49 | <rbuckton> | `o::f()` to bind `this` is much shorter than the partial application approach of `o |> f.call(?)` |
| 09:50 | <gibson042> | and actually more powerful, since Function.prototype.call is deniable |
| 09:52 | <michaelficarra> | Very good point, gibson042. I am always very aware of that and saving my own copies of such built-ins for these purposes. Would love to not have to do that. |
| 09:54 | <rbuckton> | Though I've had other thoughts on how the `::` token could be used in absence of bind/call. I've been thinking about native events and event subscription in a way that can work with either `EventTarget` and `EventEmitter`. Using `::` for events has some slight precedent due to JScript's old `function window::onload() {}` syntax (though what I'm considering is nothing along those lines). |
| 09:56 | <shu> | gibson042: is this not deniable? |
| 09:56 | <shu> | gibson042: i thought there was a hooking point via @@extension proposed but i was sleepy |
| 09:56 | <gibson042> | hmm, maybe I misunderstood |
| 09:57 | <shu> | maybe i did as well |
| 09:57 | <rbuckton> | I think that's for the ternary variant. |
| 09:57 | <rbuckton> | s/./? |
| 09:57 | <shu> | what is the ternary variant again? |
| 09:57 | <rbuckton> | `a :: b : c ()` |
| 09:58 | <michaelficarra> | yeah that part that introduced a new protocol lost me as well |
| 09:58 | <shu> | okay i completely missed that, what does that do |
| 09:58 | <rbuckton> | Looks up `c` via `b` somehow. |
| 09:58 | <ljharb> | did i also miss an explanation of why `const ::foo =` is needed? |
| 09:58 | <ljharb> | (ie, why a special identifier form) |
| 09:59 | <michaelficarra> | ljharb: yes |
| 09:59 | <ljharb> | michaelficarra: thanks, can someone tldr, or give me a few words to grep for in the notes? |
| 09:59 | <michaelficarra> | we may touch on it again with waldemar's topic |
| 10:00 | <ljharb> | kk |
| 10:00 | <ljharb> | ty |
| 10:00 | <ystartsev> | I share shu's concern |
| 10:00 | <drousso> | ljharb I've been trying to grok <http://johnhax.net/2020/tc39-nov-ext/slide#10>; |
| 10:00 | <drousso> | i entered the queue because of it |
| 10:00 | <rbuckton> | I believe `|>` is far more flexible than `::`. Hopefully we can eventually sort out the `|>` variants. |
| 10:01 | <ljharb> | drousso: that slide also confuses me, i'll wait for your queue item |
| 10:01 | <ljharb> | littledan: to be clear, the committee discussion i recall was that *stage 2* for pipeline would constitute deciding that most of the bind operator did not proceed, it certainly wouldn't block stage 1 for this proposal |
| 10:02 | <ljharb> | s/block/obstruct |
| 10:02 | <rbuckton> | That slide, with pipeline/papp would just be `o |> Ext.method(?, ...args)` |
| 10:02 | <rbuckton> | The difference is precedence. |
| 10:03 | <littledan> | ah right, I agree with this all, sorry for my misunderstanding |
| 10:03 | <littledan> | mostly I wanted to clarify the status of pipeline; sorry for getting off on that tangent |
| 10:04 | <littledan> | I do think it's a good idea to talk through these scenarios, and don't want to foreclose on that either! |
| 10:04 | <ljharb> | relevant notes: https://github.com/tc39/notes/blob/7b2de881081abd34b02bc87bcdb662fd97555795/meetings/2017-09/sept-26.md#11iia-pipeline-operator |
| 10:04 | <ljharb> | conclusion "Before Stage 2: investigate strawman for method extraction, which may simply be prefix form of ::" |
| 10:05 | <ystartsev> | Clarifying regarding what dan just mentioned in case anyone is unclear on mozilla's position: at the moment -- we don't see enough use cases for pipeline operator at present. After careful review of the syntax benefit, and the examples in the propsals, it became clear that there are existing ways to address the ergonomics concerns that are solved by the pipeline operator. We already have an implementation of |
| 10:05 | <ystartsev> | pipeline -- its not an implementation concern -- we are not convinced that this is worth its weight. |
| 10:05 | <rbuckton> | At some point I'd like to bring pipeline back to plenary. |
| 10:05 | <ljharb> | iow, only the unary form of the bind operator was expected to proceed after/if pipeline hit stage 2 |
| 10:06 | <littledan> | for me, the big thing that makes this not extension methods is that it can't dispatch on the receiver |
| 10:06 | <rbuckton> | The pipeline form that's easily reproduced using `_` and `,` is less flexible than the one I am hoping for, and is a mess for static type systems since you are constantly having to evolve the type of the `_` topic. |
| 10:06 | <gibson042> | my go-to example for pipeline is "construct a map by filtering entries from another map": `map |> Array.from |> (entries => entries.filter(fn)) |> (filtered => new Map(filtered))`. It suffers a little from cumbersome concise functions, but I think bind is even worse for it: `(map::pipe(Array.from)).filter(fn)::(function(){ return new Map(this) })` (suffering from cumbersome full functions, _and_ also requires keyboard backtr |
| 10:07 | <shu> | +1 to waldemar's concern about rift |
| 10:08 | <drousso> | +1 as well |
| 10:09 | <shu> | this (and pipeline, tbh) strikes as favoring writability over readability for those who are opinionated about they want composed code to look, but perhaps i'm missing something |
| 10:09 | <ljharb> | +1 also |
| 10:10 | <shu> | about how they* |
| 10:10 | <rbuckton> | ``` |
| 10:10 | <rbuckton> | let _; |
| 10:10 | <rbuckton> | let a = ( |
| 10:10 | <rbuckton> | _= map, |
| 10:10 | <rbuckton> | _= Array.from(_), |
| 10:10 | <rbuckton> | _= _.filter(fn), |
| 10:10 | <rbuckton> | _= new Map(_), |
| 10:10 | <rbuckton> | _); |
| 10:10 | <rbuckton> | ``` |
| 10:10 | <rbuckton> | Works but hard to correctly type `_`. The two other variants of pipeline have more power and flexibility. |
| 10:10 | <drousso> | +1 to what shu said |
| 10:10 | <drousso> | also, honestly this just feels like a fancy way of saying `Function.prototype.call` :/ |
| 10:11 | <ljharb> | drousso: that's actually a thing that we need |
| 10:11 | <Bakkot> | tcq feature request: close the queue (except for points of order) |
| 10:11 | <ljharb> | drousso: since `.call` can be deleted/forged |
| 10:11 | <ljharb> | drousso: that's the "method extraction" part of the old bind operator |
| 10:12 | <drousso> | IMO that's not something that should be solved by the language |
| 10:12 | <drousso> | i also think that having something be unforgeable is a possibly bad thing |
| 10:12 | <ljharb> | drousso: the unary form actually provides an unforgeable `.bind`, which means you can use normal call approaches, to be more accurate |
| 10:13 | <ljharb> | i'd suggest a temp check for the separate namespace, but that's a stage 1 concern so we shouldn't discuss it now |
| 10:13 | <ystartsev> | I would also but agreee with ljharb |
| 10:14 | <michaelficarra> | ljharb: I think it just needs more research at this point |
| 10:14 | <ystartsev> | i also have similar concerns about the rift raised by wsdferdksl |
| 10:14 | <ljharb> | michaelficarra: agreed |
| 10:14 | <littledan> | +1 to clarifying the relationship |
| 10:14 | <littledan> | I think it's legitimate to see this as "taking over" that other proposal |
| 10:14 | <michaelficarra> | rbuckton: that is not even close to a stage 1 concern |
| 10:15 | <littledan> | it's not a Stage 1 concern, we just have to clarify this as a committee |
| 10:15 | <littledan> | I think we should decide, as a committee, that this subsumes that other proposal |
| 10:15 | <littledan> | this follows the process in our process doc to take over a dropped proposal |
| 10:15 | <rbuckton> | That's fine. I just wanted to make sure. We didn't fork `|>` into 3 proposals, and we've had other proposals that we've said need to be combined in the past. |
| 10:20 | <drousso> | haxjs in the future, could you please make sure to include a link to your slides in the agenda before the first day of meeting begins? |
| 10:21 | <haxjs> | drousso: oh. sorry i forgot to add link! |
| 10:21 | <ljharb> | other than js module blocks, and extensions, has anything advanced a stage this meeting that i overlooked? |
| 10:22 | <ljharb> | ystartsev: other than links, do you have any examples of when the proposals repo has not been up to date or correct by the end of a given plenary? |
| 10:23 | <ljharb> | thank you |
| 10:23 | <akirose> | JSCIG HEROES |
| 10:24 | <littledan> | I think it's really important that subgroups of TC39 be formed openly, by informing the committee in the Reflector, so that everyone who wants to can participate. I was unaware of the JSCIG |
| 10:25 | <akirose> | JSCIG formed independently |
| 10:25 | <littledan> | sure, I'm suggesting that when things form, the committee is kept in the loop |
| 10:26 | <shu> | is data being out of date a problem? |
| 10:27 | <littledan> | shu: yes |
| 10:27 | <littledan> | not just out of date, but different data sources disagreeing with each other |
| 10:27 | <shu> | different data sources within tc39/ ? |
| 10:28 | <ljharb> | doesn't designating a single source of truth (which we've done) ensure eventual consistency? |
| 10:28 | <michaelficarra> | ljharb: chinese interest group, you can remove your queue item |
| 10:28 | <ljharb> | iow, the source of truth is plenary, which the notes document, and the proposals repo includes |
| 10:28 | <ljharb> | michaelficarra: was it in the notes? |
| 10:28 | <ljharb> | michaelficarra: i missed the explanation if so |
| 10:28 | <michaelficarra> | oh, not sure |
| 10:28 | <shu> | not sure if there was an explanation other than that's what it stands for |
| 10:28 | <michaelficarra> | we can add a parenthetical after its first use in the notes |
| 10:29 | <littledan> | I don't think this is trying to change how we make decisions/what the "source of truth" is, but more ensure that the decisions are propagated to documentation sources properly, so we can avoid confusing people |
| 10:30 | <ljharb> | sgtm |
| 10:30 | <shu> | that's what i'm confused about, who is confused by what |
| 10:30 | <ljharb> | rbuckton: can i give you a teams ipad app complaint to take to the right people? :-) |
| 10:30 | <shu> | like a README for a particular proposal being out of date? |
| 10:30 | <littledan> | the proposals repo, notes, proposal repos, and website, all owned by TC39, sometimes disagree with each other |
| 10:31 | <littledan> | this is a current problem |
| 10:31 | <ljharb> | rbuckton: specifically, a VC call isn't a phone call, and tapping my airpods (which happens by accident) shouldn't hang up my meeting and cause me to leave it. |
| 10:31 | <littledan> | people get confused in practice, frequently |
| 10:31 | <ljharb> | proposal repos sometimes lag, this is true |
| 10:31 | <shu> | yes, that i agree with for individual proposal repos lagging |
| 10:31 | <ljharb> | notes and the proposals repo, modulo links which change of their own accord, have remained in sync as far as i'm aware |
| 10:31 | <ljharb> | (and modulo minor human errors which occasionally occur, ofc) |
| 10:32 | <littledan> | as Yulia is explaining, there's lots of important information. I've definitely seen human errors. The goal here is to address the errors. |
| 10:32 | <littledan> | I'm a big fan of this proposal |
| 10:32 | <akirose> | me toooooooo |
| 10:36 | <littledan> | it's certainly true that we have disagreements between the proposals repo and test262 in terms of documenting status |
| 10:36 | <littledan> | where the proposals repo makes it soundl ike there isn't test coverage |
| 10:38 | <ljharb> | littledan: ah, fair, "has tests" is something that also lags |
| 10:39 | <ljharb> | that's something that's been left to proposal champions (or the test PR author) and does get missed not infrequently |
| 10:39 | <rbuckton> | ljharb: I have a list I've been maintaining. I'll add that to it. |
| 10:39 | <ljharb> | rbuckton: thanks |
| 10:42 | <littledan> | right, I think that's an accurate explanation of what's happening, and I like Yulia's efforts to improve it |
| 10:44 | <michaelficarra> | the note takers aren't just rushed currently, they often just skip the conclusion entirely |
| 10:44 | <shu> | robpalme: akirose: could i get the usual 10-15 mins for incubator call chartering? |
| 10:44 | <shu> | didn't see it on the TCQ agenda |
| 10:44 | <ljharb> | it seems reasonable, after each item, to explicitly checklist that the notes have a conclusion |
| 10:45 | <akirose> | my b. yes shu. |
| 10:45 | <ljharb> | notetakers already often ask to verify that sometimes |
| 10:45 | <shu> | thanks |
| 10:46 | <michaelficarra> | yeah and writing down the conclusion helps us solidify our own understanding as well, it's a win-win |
| 10:46 | <ljharb> | +1 |
| 10:46 | <brad4d> | I think the idea is just to formally ask the note takers "are you ready" before proceeding to the next topic. |
| 10:46 | <brad4d> | seems like a good idea anyway |
| 10:46 | <shu> | ljharb: i agree with your point about individual repos lagging and shouldn't be source of truth, my take on that is why even include stage info in the individual repos then |
| 10:47 | <rbuckton> | Have we considered YAML frontmatter in markdown? I don't think github supports it currently, but we could ask. A lot of doc tools use YAML frontmatter with markdown, so its not a stretch to consider. |
| 10:47 | <shu> | make a little pill or something that just displays the proposals repo info |
| 10:47 | <ljharb> | shu: that sounds like an amazing countersuggestion, let's do that |
| 10:47 | <ljharb> | shu: altho it is useful for the individual proposal's ecmarkup build to contain the stage number |
| 10:47 | <shu> | that could be done via ecmarkup as well |
| 10:47 | <ljharb> | sold |
| 10:48 | <shu> | even easier, really, with ecmarkup |
| 10:48 | <shu> | than telling champions to copy/paste something into README.md |
| 10:48 | <rbuckton> | But the README itself wouldn't contain it? |
| 10:48 | <shu> | rbuckton: it would, but it'd require copy/pasting some pill code like CI status pills, instead of actually saying "stage: N" |
| 10:48 | <ljharb> | rbuckton: unless frontmatter could be used to autogenerate the relevant prose, it'd be annoying to enter it twice. also since i'm usually the one updating the list, i hate yaml :-p |
| 10:48 | <rbuckton> | That has the downside of having to look somewhere else to understand proposal status when looking at the proposal itself. |
| 10:48 | <rbuckton> | shu: Ah, that's not a bad idea. |
| 10:49 | <shu> | ljharb: anyway please suggest that in my stead during your item, i don't wanna extend the queue |
| 10:49 | <ljharb> | shu: done |
| 10:49 | <rbuckton> | There's one issue though. If stage consensus is reached pending changes (which has happened numerous times), it could be misleading if the README update for the changes lags behind the stage status in the main proposals repo. That could cause confusion. |
| 10:50 | <ljharb> | that's true |
| 10:50 | <rbuckton> | There should be a single source of truth, but it might be better for that to be the proposal itself. |
| 10:51 | <ljharb> | proposal champions are in no way consistent enough about updating the proposal repo for that to be a good idea, unfortunately |
| 10:51 | <shu> | rbuckton: that's a good point, yes |
| 10:51 | <rbuckton> | Otherwise you have to stage two changes, one for the repo AND one for the /proposals repo, which we have to do anyways. |
| 10:51 | <shu> | rbuckton: but no worse than status quo, i guess? |
| 10:51 | <rbuckton> | ljharb: guilty, unfortunately. |
| 10:51 | <ljharb> | ystartsev: my queue item ran out of time, but for reference: "individual proposal repos are much slower to update than the main list; they should not become the source of truth" |
| 10:51 | <rbuckton> | shu: The same idea about CI status pills applies, if the source of truth is the repo and the pill appears on `/proposals` instead. |
| 10:54 | <littledan> | akirose: Were you going to drop a link in the chat here? |
| 10:54 | <ystartsev> | ljharb: noted -- as mentioned in the slides, the "proposal" repo will read from "proposals" -- a given individual proposal repo would be the detailed information, and gather it's meta data from the "proposals" repository |
| 10:54 | <akirose> | littledan: in the call |
| 10:54 | <akirose> | but here https://snaps.akibraun.com/dbzqq.png |
| 10:54 | <ljharb> | ystartsev: ah ok, i thought the arrow on that case pointed in the opposite direction |
| 10:55 | <ystartsev> | yeah thats the one case where the arrow points in the other direction, i should have done the diagram differently |
| 10:56 | <rbuckton> | Two TCQ suggestions: 1. Let chairs scroll through the agenda history and reintroduce previous topics (i.e., drag/drop or cut/copy/paste). 2. When the mouse is over the button chairs use to advance the queue, "lock" the UI so that clicking a button doesn't accidentally advance the queue if the speaker clicks the "i'm done speaking" button causing the race condition we saw earlier. |
| 10:57 | <akirose> | rbuckton: https://github.com/bterlson/tcq |
| 10:57 | <rbuckton> | Yeah, I'll file them. |
| 10:57 | <michaelficarra> | rbuckton: file them? send PRs :-P |
| 10:58 | <drousso> | oh snap it's on github 🤯 |
| 11:02 | <ljharb> | dandclark: did your queue item get skipped? |
| 11:02 | <akirose> | yeah that's not even a microsoft-funded project. if i understand correctly it's an off-hours bterlson special |
| 11:05 | <michaelficarra> | I mean, they employ bterlson and they own GitHub, so… |
| 11:06 | <rbuckton> | michaelficarra: Last time I talked to bterlson about it (about a month ago) he said TCQ needed some updates before features could be added. I was fairly surprised to see the room temp functionality, tbh. |
| 11:07 | <akirose> | i think yulia contributed it |
| 11:07 | <rbuckton> | And that was just to fix the issue with the login redirect losing the current meeting ID (which seems to have been fixed since) |
| 11:08 | <Bakkot> | was rpamely pro-mutable or pro-immutable? |
| 11:08 | <ljharb> | Bakkot: pro-immutable |
| 11:08 | <akirose> | yeah i think they fixed that after robpalme broke the database |
| 11:08 | <Bakkot> | er, or whoever just talked |
| 11:08 | <Bakkot> | thanks |
| 11:08 | <robpalme> | immuble |
| 11:13 | <rricard> | bakkot: stop transcribe |
| 11:13 | <rricard> | as always won't be able to work on notes during the second part |
| 11:16 | <gibson042> | isn't the immutable form achievable with an intermediate `import data from ...; export default Object.freeze(data)`? |
| 11:16 | <Bakkot> | I snuck in a `Json` -> `JSON` auto-correct just before that section, if anyone was wondering why it suddenly stopped doing that |
| 11:17 | <Bakkot> | I think we'll end up with a pretty extensive collection of such corrections over time, which hopefully will improve the experience |
| 11:17 | <Bakkot> | gibson042 yeah, people mentioned that a few times. (though the deep freeze is a little more painful than just that) |
| 11:18 | <gibson042> | ah, right. Yep. |
| 11:18 | <Bakkot> | the same is true of mutable, of course, just with `import data from ...; export default JSON.parse(JSON.stringify(data))` |
| 11:18 | <Bakkot> | (which sounds ugly but is probably faster than a deep freeze) |
| 11:21 | <littledan> | Let's continue the discussion about mutability in https://github.com/tc39/proposal-json-modules/issues/1#issuecomment-730305544 |
| 11:22 | <Bakkot> | my position on mutability continues to be that there are very good arguments for both sides and hence I am ok with either outcome |
| 11:22 | <littledan> | yeah I guess I feel that way too |
| 11:24 | <gibson042> | are we sure that `JSON.parse(JSON.stringify(data))` is guaranteed to return exactly the same data in this case? I'm wondering in particular about numerical precision |
| 11:24 | <littledan> | I hope so!!! |
| 11:24 | <Bakkot> | numerical precision is not an issue, I guarantee |
| 11:26 | <Bakkot> | and, yeah, even if you have a `toJSON` property in your data it can't be a function |
| 11:27 | <Bakkot> | so yes, I am confident it is guaranteed to return exactly the same data |
| 11:27 | <Bakkot> | even property enumeration order is guaranteed to be the same now :D |
| 11:29 | <littledan> | phew! |
| 12:01 | <robpalme> | we are starting now! |
| 12:12 | <shu> | PDF beautification seems like a most legit budget ask from ecma, they remain the main stakeholder for caring about PDFs anyhow |
| 12:23 | <rbuckton> | FYI: Since there won't be time to address this during this meeting, if anyone would like to discuss mitigations for performance in RegExp Match Indices, I've filed https://github.com/tc39/proposal-regexp-match-indices/issues/47 as a place to discuss the possible alternatives. |
| 12:24 | <shu> | rbuckton: i was gonna propose an incubator call for it for personal reasons |
| 12:24 | <shu> | i want the engines and champions to just hash it out |
| 12:24 | <shu> | since it's been stage 3 for a while and now that we have 2 engines' experience i want us to zero in on a solution quickly |
| 12:25 | <rbuckton> | That's fine with me as well. And I completely agree. |
| 12:26 | <shu> | though that's somewhat an abuse of the incubator call mechanism |
| 12:26 | <shu> | maybe i'll just schedule a one-off call |
| 12:26 | <shu> | let's do that instead |
| 12:27 | <rbuckton> | That works for me as well. |
| 12:40 | <michaelficarra> | drousso or whoever's taking notes, please try to attribute using the assigned abbreviations, not just the initials of the speaker |
| 12:40 | <drousso> | yeah im trying but i dont know them all 😅 |
| 12:41 | <drousso> | i was gonna go back and fix it later |
| 12:49 | <drousso> | michaelficarra is there a list somewhere of the mappings? |
| 12:51 | <michaelficarra> | drousso: https://github.com/tc39/notes/blob/master/delegates.txt |
| 12:51 | <michaelficarra> | it's linked at the top of the notes |
| 12:51 | <drousso> | awesome ty\ |
| 12:51 | <drousso> | ah |
| 12:52 | <Bakkot> | PRs welcome but it's faster to just tell me them and I can try to hotswap it during a pause in audio |
| 12:54 | <Bakkot> | i feel like hte thing to do would be to give error cause ten minutes and start batch preloading five minutes late |
| 12:55 | <michaelficarra> | Bakkot: I was thinking the same thing |
| 12:55 | <Bakkot> | i strongly suspect error cause could get stage 2 in ten minutes |
| 12:55 | <Bakkot> | it is not a large design space |
| 12:55 | <michaelficarra> | just because you've requested 60 minutes max doesn't mean you're entitled to 60 minutes min |
| 12:59 | <shu> | it's a reasonable expectation |
| 12:59 | <rbuckton> | I've been wondering if we need something like ECMA-402 for RegExp. There are a lot of things that I and others have expressed interest in adding to RegExp and it might be worth having a regular discussion about all of these ideas, if not an actual separate group. |
| 13:00 | <shu> | i'd like to see more subgroups in general |
| 13:00 | <shu> | hard to see us scaling otherwise as many folks have pointed out in the past |
| 13:01 | <michaelficarra> | oh, cause is a string, not an optional error? |
| 13:01 | <shu> | wonder why |
| 13:02 | <Bakkot> | shu https://github.com/tc39/proposal-error-cause#differences-with-aggregateerror |
| 13:02 | <Bakkot> | no, cause is an optional error |
| 13:03 | <Bakkot> | the default property does not make sense |
| 13:03 | <Bakkot> | I commented on the issue |
| 13:03 | <Bakkot> | it is not a string |
| 13:04 | <michaelficarra> | Bakkot: k |
| 13:22 | <michaelficarra> | I am a big fan of the idea of signed exchanges (no experience using/implementing them), and I'd love to know why Dan doesn't like them |
| 13:25 | <michaelficarra> | I don't understand the tracking concerns that Dan is talking about |
| 13:26 | <michaelficarra> | if a request for a module is authenticated (or otherwise identified), can't the actions of that script be similarly identified? |
| 13:32 | <michaelficarra> | oh okay, I think he means like HTTP-level tracking, accomplished by just associating the request with the identifier |
| 13:41 | <wsdferdksl> | michaelficarra: To see examples of Dan's concerns about SXG: https://brave.com/webbundles-harmful-to-content-blocking-security-tools-and-the-open-web/ |
| 13:45 | <michaelficarra> | ystartsev: can you get Ted Campbell added to delegates.txt? |
| 13:45 | <ystartsev> | yes |
| 13:45 | <ystartsev> | michaelficarra: can we use TCL for now and i will adjust if its already in use? |
| 13:45 | <shu> | nice, TCL |
| 13:47 | <Bakkot> | who's speaking? for the notes |
| 13:47 | <shu> | Yoav Weiss |
| 13:47 | <shu> | YWS i think is what i added to delegates, let me check |
| 13:48 | <shu> | yep, YWS |
| 13:48 | <shu> | (from Google) |
| 13:51 | <Bakkot> | can someone copy the mentioned link to the notes? |
| 13:51 | <ystartsev> | Copied from Yoav here: https://docs.google.com/document/d/11t4Ix2bvF1_ZCV9HKfafGfWu82zbOD7aUhZ_FyDAgmA/edit# |
| 13:52 | <ystartsev> | Bakkot: ^ |
| 13:52 | <ystartsev> | (sorry don't ahve notes open) |
| 14:02 | <Bakkot> | later all |
| 14:02 | <ystartsev> | hope that wasn't too little ceremony |
| 14:02 | <Bakkot> | less ceremony more sleep wfm |
| 14:03 | <michaelficarra> | that was a lot of notes |
| 14:18 | <littledan> | Brave's blog post is about WebBundles, not really about signed exchange |
| 14:19 | <littledan> | This post is more aligned with my concerns https://trib.tv/2019/05/28/cake-or-death-amp-and-the-worrying-power-dynamics-of-the-web/ |
| 14:19 | <littledan> | but really, I just wanted to underscore that this proposal does not enable signed exchange; it's just unrelated |
| 14:19 | <devsnek> | I still don't understand the extension proposal syntax |
| 14:20 | <devsnek> | littledan: "amp is for the carousel" is a good summary |
| 14:22 | <littledan> | michelficarra: You can find Apple's tracking concern at https://github.com/WICG/webpackage/issues/422 |
