| 01:10 | <ljharb> | gibson042: can you mute? |
| 01:11 | <shu> | i cannot understand hax, can everyone check their mic? |
| 01:11 | <shu> | oh it's better now |
| 01:11 | <shu> | wait, not yet |
| 01:12 | <shu> | this has been delayed a meeting already for no new information learned, i am very unhappy about delaying another 2 months |
| 01:12 | <shu> | this is not a good precedent |
| 01:13 | <michaelficarra> | shu: agreed :-( |
| 01:13 | <wsdferdksl> | shu: I agree |
| 01:13 | <devsnek> | very unfortunate |
| 01:13 | <rkirsling> | yeah this doesn't feel procedurally acceptable |
| 01:13 | <wsdferdksl> | And I couldn't figure out what hax's point was over the last ten minutes |
| 01:13 | <ljharb> | if that's a common opinion, it'd be great to get the chairs to weigh in on it. |
| 01:15 | <jorendorff> | hax, haxjs: would you please mute? I think there is a little background noise where you are |
| 01:15 | <haxjs> | oh i forgot |
| 01:15 | <haxjs> | sorry |
| 01:16 | <haxjs> | muted. |
| 01:16 | <michaelficarra> | our process just isn't scaling that well, there's some work to be done |
| 01:16 | <michaelficarra> | but I also don't think we should subvert it just because it's not working for us right now |
| 01:17 | <ljharb> | i agree with that too, as inconvenient it is for my own proposal. |
| 01:19 | <michaelficarra> | if you look at it optimistically, we are getting more examples of exactly the kinds of situations we'd like our process changes to address |
| 01:19 | <michaelficarra> | "S.p.item: never again" |
| 01:20 | <michaelficarra> | our current process was modeled around "PTCs: never again" |
| 01:24 | <haxjs> | Sorry i thought I could finish my summarize in 5 mins, but obviously it's a wrong estimation just like the case i estimate how long i need to finish a feature when programming :( |
| 01:35 | <devsnek> | can't engines just add these as new objects that appears as existing arraybuffers? like how they have many internal kinds of arrays or whatever |
| 01:37 | <rickbutton> | as in, secretly use a resizable buffer internally if needed? |
| 01:38 | <rickbutton> | like, a big IF around `useResizable`, old one or new one |
| 01:38 | <devsnek> | sort of lol |
| 01:38 | <devsnek> | basically don't touch the code inside one of those branches |
| 01:38 | <rickbutton> | right |
| 01:38 | <devsnek> | but idk dan's point seems interesting |
| 01:39 | <rickbutton> | would be weird if there were divergent bugs between the two impls |
| 01:39 | <devsnek> | i think people are overestimating how often js people use arraybuffers/typedarrays directly |
| 01:39 | <rickbutton> | well web developers rarely use them, but crypto miners and other various bad actors can freely use them |
| 01:39 | <devsnek> | and even when they do use them, they're almost always treated as an opaque type |
| 01:40 | <devsnek> | rickbutton: yeah i mean people saying more types is bad dev ux |
| 01:40 | <rickbutton> | ah yeah |
| 01:40 | <littledan> | the invariant about the length being fixed is a JS developer-facing one, not just an implementation one |
| 01:41 | <devsnek> | indeed |
| 01:41 | <devsnek> | i'm saying i think serving the immediate security stuff is worth having a bad api in this case |
| 01:41 | <devsnek> | because hardly anyone uses the api |
| 01:41 | <rickbutton> | I see what you mean now devsnek, I agree |
| 01:41 | <littledan> | Waldemar's idea seems fine; the difference would be superficial |
| 01:41 | <Bakkot> | I like wsdferdksl's idea |
| 01:42 | <devsnek> | what did he say |
| 01:42 | <Bakkot> | seems like something to resolve between now and stage 3 |
| 01:42 | <littledan> | +1 |
| 01:42 | <Bakkot> | have arraybuffers be frozen-len by default but have an overload allowing you to get an unfrozen one |
| 01:42 | <Bakkot> | rather than a whole new type |
| 01:42 | <Bakkot> | engines would treat them as different types, users wouldn't have to |
| 01:42 | <devsnek> | isn't that what mark said |
| 01:42 | <devsnek> | and sort of what i said i guess |
| 01:42 | <rickbutton> | that is what devsnek said |
| 01:42 | <rickbutton> | haha |
| 02:03 | <shu> | Bakkot: what do you think about the tooling argument shane gave for different types? |
| 02:04 | <Bakkot> | shu: to my knowledge TS does not give you any help for bounds checks right now, it just assumes all accesses are in bounds (or, with a new flag, that they are all out of bounds unless checked immediately before access) |
| 02:05 | <shu> | i see |
| 02:05 | <devsnek> | is yulia here today |
| 02:05 | <Bakkot> | I may not have understood the point, but if it's just about bounds checks I don't know that it matters |
| 02:05 | <Bakkot> | ystartsev ^ |
| 02:05 | <rickbutton> | devsnek: she is around in the evening half |
| 02:05 | <Bakkot> | I think she's only in the afternoon sessions? |
| 02:05 | <Bakkot> | yeah |
| 02:05 | <shu> | jorendorff is standing in for the earlier session |
| 02:05 | <devsnek> | ah ok |
| 02:05 | jorendorff | waves |
| 02:05 | <devsnek> | 👋🏻 |
| 02:06 | <ljharb> | bterlson: queue? |
| 02:06 | <rkirsling> | rickbutton: there's an evening half? |
| 02:06 | <rickbutton> | for many it's always the evening half |
| 02:06 | <rkirsling> | indeed |
| 02:07 | <devsnek> | queue needs to move |
| 02:07 | <devsnek> | i still don't think this proposal is worth it |
| 02:09 | <ljharb> | queue's moved, thanks |
| 02:14 | <rkirsling> | Berlin was 2019, but it has been a long long year |
| 02:15 | <ljharb> | also i never went to berlin |
| 02:15 | <ljharb> | but i may have remoted into that one |
| 02:16 | <shu> | man, 2018, really? |
| 02:16 | <shu> | i thought we were in berlin last year |
| 02:16 | <rkirsling> | we were |
| 02:16 | <rkirsling> | see above |
| 02:16 | <ljharb> | hard to remember travel, or how time works |
| 02:17 | <rbuckton> | Just to check, its not still March right? Because march was looong... |
| 02:18 | <rkirsling> | my computer says it's September but who knows whether that can be trusted |
| 02:19 | <ljharb> | it seems like it'd be nice to create the notes docs from a *gmail* account, so that non-org members' names are allowed to show up |
| 02:20 | <michaelficarra> | ljharb: yeah that'd be nice |
| 02:29 | <mmarchini> | But where |
| 02:29 | <devsnek> | everything has to be available sync anyway |
| 02:29 | <mmarchini> | Ahh i see, in the agenda the link is updated, but in the notes it’s still the old link |
| 02:30 | <devsnek> | because of the script api |
| 02:30 | <devsnek> | i don't get this proposal |
| 02:35 | <devsnek> | if there's a GetBuiltinSync api for scripts |
| 02:35 | <devsnek> | and it must work for everything (i assume) |
| 02:35 | <devsnek> | how does the "load async" argument fit into this |
| 02:39 | <jorendorff> | polyfilling has this drawback in browsers today! |
| 02:39 | <littledan> | bradleymeck: My queue item is about this shimming thing |
| 02:39 | <jorendorff> | nobody really notices, it seems |
| 02:39 | <jorendorff> | it forces things to be loaded |
| 02:40 | <littledan> | I really think that, if we do this right, we can reduce this cost of polyfilling |
| 02:40 | <bradleymeck> | i would love reduced polyfilling cost |
| 02:40 | <Bakkot> | async APIs on the global could be polyfilled asynchronously |
| 02:40 | <littledan> | (and proposed an API in https://github.com/tc39/proposal-built-in-modules/issues/62 + 63 |
| 02:40 | <bradleymeck> | but i'm unclear on how we can do that if we have to load the source text of polyfill itself |
| 02:40 | <jorendorff> | ...i think if this were the biggest problem with the proposal, yes, it's fixable |
| 02:41 | <littledan> | import map-based polyfilling also had this benefit, but we could do it with an imperative API as well |
| 02:41 | <littledan> | I think this is something that we could do much more effectively through built-in modules than through globals with promise-based APIs |
| 02:42 | <michaelficarra> | littledan: why? |
| 02:42 | <bradleymeck> | banning using static import syntax also would work to make the Script/Module support the same matrix |
| 02:42 | <devsnek> | +1 |
| 02:42 | <littledan> | since users don't have to explicitly await the promise, just import it |
| 02:42 | <bradleymeck> | Dealing with global invalidation is a serious pain in my modules |
| 02:43 | <Bakkot> | littledan why does that matter, with regards to how readily they can be polyfilled? |
| 02:44 | <littledan> | Bakkot: Because it reduces the overhead incurred by newer browsers that don't need the polyfill |
| 02:44 | <littledan> | the fetch for the polyfill code could be conditional |
| 02:45 | <littledan> | ljharb doesn't seem to be convinced that this would be practical to deploy, in the issues, however |
| 02:45 | <Bakkot> | littledan: it can be conditional with an async API, too |
| 02:45 | <littledan> | Bakkot: Yes. The benefit over an async API is that you just import it, you don't have to await a promise. So it's practical to apply more broadly |
| 02:45 | <littledan> | I think it'd be pretty bad ergonomics if you needed to await a Promise to use Temporal, but shipping a Temporal polyfill is still heavy |
| 02:46 | <ljharb> | it's possible for the polyfill itself to sync-load the detection code, and async-load the replacement implementation, but the original module is still synchronously needed to *decide* if polyfilling is needed |
| 02:46 | <Bakkot> | with TLA I don't think it makes much difference in modules, and it makes no difference at all in scripts |
| 02:47 | <Bakkot> | ljharb disagree |
| 02:47 | <Bakkot> | your sync shim replaces the async API with a thing with waits for the built-in API, checks if it's good, and then either returns immediately or fetches the polyfill and applies it |
| 02:47 | <Bakkot> | users see no difference |
| 02:48 | <Bakkot> | that is, "a thing which waits for the built-in API [when invoked]" |
| 02:48 | <devsnek> | what if browsers had `importScripts` in the main thread |
| 02:48 | <Bakkot> | ... I can reword that if you want, that kind of got away from me |
| 02:48 | <ljharb> | Bakkot: ah true, that's reasonable if the thing is only available async, and i can intercept all requests for it |
| 02:48 | <ljharb> | Bakkot: nah i think i got you, and you're right |
| 02:49 | <littledan> | I would not want all Temporal users to have to write `let myTemporal = await Temporal.get()` at the top of their program |
| 02:49 | <ljharb> | that would be very unfortunate |
| 02:50 | <Bakkot> | littledan: it is not obvious to me that that would be so much worse than `import { Temporal } from 'js:temporal'` that it warrants this much machinery |
| 02:51 | <littledan> | well, in practice, we're not going to give Temporal this Promise-based API, whereas as a built-in module, we would do that |
| 02:51 | <devsnek> | what qualifies a builtin as important enough to be its own global |
| 02:52 | <rickbutton> | there are entire categories of APIs and libraries that other programming languages provide through imports of various kinds |
| 02:53 | <Bakkot> | most other languages do not have a concept of the global |
| 02:53 | <Bakkot> | all their stuff is in imports, whereas all our stuff is on the global |
| 02:53 | <littledan> | I don't think it makes much sense to make an optional view of things as a module |
| 02:54 | <littledan> | our role here is to define a single javascript language |
| 02:54 | <shu> | i think appeals to other languages fall short because there're decades of history here |
| 02:55 | <shu> | littledan: yes, and if "1JS" is the prioritized property to maintain, then we shouldn't have built-in modules |
| 02:56 | <littledan> | I don't understand the purpose of raising this alternative. Hosts already have the machinery they need to define their own built-in modules. |
| 02:56 | <shu> | littledan: moddable wants to use it, and they're already not caring about web compatible |
| 02:56 | <devsnek> | moddable's whole "we want it to be standard and we don't care about the wider ecosystem" thing irks me |
| 03:03 | <ljharb> | littledan: your suggestion is an api that's zalgo? |
| 03:05 | <michaelficarra> | just to get a feel for the room, this doesn't appear to have enough justification for stage 2, right? |
| 03:05 | <devsnek> | that's how it seems to me |
| 03:05 | <rkirsling> | feeling pretty icy by my thermometer |
| 03:07 | <littledan> | ljharb: Yes :) |
| 03:08 | <ljharb> | littledan: thanks, ṷ̵̫̺̲͌͊͐̀͜͞͞ñ͍̮̭̘̹͔̪̋̓̾͗̑̔̕͟d̫͇͓͕̋̊̀͒͆̽̈́̚̕͢e̲͍̲̼͉̐͛̋͂̒͢r̛͕̠̬̙͇̤̜̼̿̾̌͑͆̋̉̀s̴̛̠͉̣͓͈̯̞͎͉̋̈́͌̏̉̐̕͢͝t͇̝̱̼̩͇͓̥͈͇̂̈́͆̀̚͠ö̡͚̹͔̭̬̃̿̾̃́͛͐̌͡ỏ͓̤̞̟̯̯̉̋̓̕͢ͅḑ̲͇̣̗̘̟̘͓͊̏́̉̂͌̈͐ |
| 03:12 | <Bakkot> | devsnek: remind me why your proposal does `dbg!(x)` instead of `debugger(x)`? |
| 03:12 | <devsnek> | Bakkot: existing rust feature |
| 03:12 | <devsnek> | i'm not proposing any specific function or syntax |
| 03:12 | <Bakkot> | gotcha |
| 03:13 | <Bakkot> | it should be `debugger (x)` :) |
| 03:13 | <devsnek> | that's one of the options on the last slide iirc |
| 03:13 | <Bakkot> | approximately yes |
| 03:13 | <Bakkot> | anyway I like it |
| 03:13 | <devsnek> | 🎉 |
| 03:13 | <Bakkot> | I think using the rust syntax is going to trip some people up |
| 03:13 | <Bakkot> | e.g. waldemar |
| 03:13 | <Bakkot> | since it's so weird |
| 03:14 | <Bakkot> | from a JS perspective, and has ASI implications and so on |
| 03:14 | <devsnek> | i can swap it out |
| 03:15 | <rkirsling> | yeah like, I'm plenty familiar with Rust but ! in a JS function call is so jarring that it's hard to not get hung up on |
| 03:16 | <devsnek> | oh god i used screenshots |
| 03:16 | <devsnek> | noooooooo |
| 03:17 | <bradleymeck> | D used binary ! for compile time features, I loved it |
| 03:18 | <rickbutton> | big fan of ! for indicating mutation ala ruby/scheme |
| 03:19 | <devsnek> | lul |
| 03:20 | <shu> | i do miss ? for predicates, that is nice readability |
| 03:20 | <shu> | especially because it was pronounced "huh", like "integer huh" |
| 03:21 | <rkirsling> | lol |
| 03:21 | <rickbutton> | I don't think I've ever heard of that. In my head I've always heard it like you were asking a question, like *integer?* |
| 03:22 | <rkirsling> | IIRC linear logic ? is pronounced "why not" |
| 03:23 | <shu> | rickbutton: maybe it was just the PLT Scheme folks, since i ran with those folks as an undergrad |
| 03:24 | <rickbutton> | to be fair I don't run with any scheme folks so I'm not the authority |
| 04:00 | <ljharb> | from ruby i've also used the rising tone thing |
| 04:01 | <rickbutton> | it means you should yell when you say `mutate!` |
| 04:02 | <devsnek> | this is a good proposal |
| 04:02 | <devsnek> | linked lists of errors ftw |
| 04:04 | <ptomato> | FYI, I am in the rotation for taking notes during this shift, but I seem to have lost my sound over the break. I will try to get it working during the presentation |
| 04:07 | <devsnek> | ljharb: aggregate errors are not inherently causally related |
| 04:08 | <devsnek> | in fact the opposite is generally implied, due to where aggregate errors come from |
| 04:08 | <ljharb> | and exceptions need not be an object either |
| 04:08 | <ljharb> | extend my queue question to include "or a userland subclass" |
| 04:08 | <devsnek> | you should never throw something that is not an instance of an error class provided by the engine |
| 04:08 | <devsnek> | ok |
| 04:09 | <ljharb> | that's an opinion you can have but not one the language may enshrine, i can throw null if i wanna |
| 04:09 | <robpalme> | I am +1ing this proposal |
| 04:09 | <devsnek> | also +1 |
| 04:09 | <Bakkot> | it is fine to build convenience methods which are only convenient if you obey that discipline even if the language does not enforce that discipline |
| 04:09 | <devsnek> | can the queue be advanced |
| 04:09 | <devsnek> | bterlson: ^ |
| 04:09 | <robpalme> | the queue is good |
| 04:10 | <devsnek> | jordan is talking |
| 04:10 | <devsnek> | i can't put in a reply |
| 04:10 | <robpalme> | got it |
| 04:10 | <devsnek> | thanks! |
| 04:10 | <ljharb> | Bakkot: fair |
| 04:11 | <ptomato> | I have sound again, so I'll take notes now. so sorry about that |
| 04:11 | <robpalme> | I wonder if we have Netflix folk in the meeting. They have a library that does rich errors (way beyond this proposal) called "nerror" |
| 04:12 | <robpalme> | thank you @ptomato! |
| 04:12 | <Bakkot> | this issue has an example of how it looks in Java: https://github.com/wallabyjs/public/issues/2069 |
| 04:12 | <Bakkot> | (note that in an IDE you could click on the line number in any of the lines to go to that line, including in the "caused by" lines) |
| 04:13 | <rickbutton> | someone unmuted? |
| 04:13 | <michaelficarra> | should we mute jack-works? |
| 04:15 | <robpalme> | done |
| 04:17 | <robpalme> | Can anyone contact Kris Kowal? |
| 04:17 | <robpalme> | (we had to skip him) |
| 04:20 | <mmarchini> | Uhuuuuuuuuuuuuul <3 |
| 04:21 | <devsnek> | wut |
| 04:21 | <rickbutton> | very excited to add error.cause support to the actual product i work on |
| 04:22 | <devsnek> | very excited to add error.cause support to util.inspect |
| 04:22 | <rkirsling> | oh wow didn't see that Rust syntax before |
| 04:23 | <robpalme> | We do the same thing as amp on the error mutation. |
| 04:24 | <rickbutton> | yep I just had to fix a couple of cases where we didn't do that and instead did a weird wrapping like yesterday |
| 04:25 | <michaelficarra> | I'm excited to see where this proposal goes |
| 04:26 | <devsnek> | double ended iterators are +1 |
| 04:27 | <Bakkot> | this should definitely be stage 1, in that it definitely outlines a problem we should solve |
| 04:27 | <devsnek> | agree |
| 04:27 | <gibson042> | I like everything about this proposal except its name |
| 04:27 | <Bakkot> | I will need to think more about the the specific proposal to fix the problem presented here |
| 04:27 | <michaelficarra> | infinite iterators should not be double-ended lol |
| 04:27 | <devsnek> | michaelficarra: stop shutting down my use cases 😭 |
| 04:28 | <gibson042> | oh, never mind it got weird |
| 04:28 | <devsnek> | i was just about to say |
| 04:28 | <rkirsling> | lol |
| 04:28 | <michaelficarra> | double-ended iterator should be its own protocol, surely |
| 04:28 | <devsnek> | ^ |
| 04:28 | <michaelficarra> | Iterator.from better not give me a double-ended |
| 04:29 | <michaelficarra> | or at least I shouldn't be expecting one |
| 04:29 | <devsnek> | well i would say |
| 04:29 | <ljharb> | double-ended iterator is basically https://github.com/tc39/proposal-reverseIterator (which oops, we never filled in past the initial presentation) |
| 04:29 | <devsnek> | its like a subclass |
| 04:29 | <devsnek> | a double ended iterator can be used anywhere expecting a normal iterator |
| 04:29 | <devsnek> | but not vice versa |
| 04:29 | <michaelficarra> | devsnek: yeah that's what I meant |
| 04:30 | <rkirsling> | ljharb: he did notice at least :P https://github.com/tc39/proposal-reverseIterator/issues/1#issuecomment-581320556 |
| 04:30 | <devsnek> | +1 shu |
| 04:30 | <ljharb> | rkirsling: lol yes |
| 04:30 | <devsnek> | well i understand how they *could* but it isn't how they *should* |
| 04:32 | <rickbutton> | +1 to that |
| 04:33 | <michaelficarra> | for the double-ended destructuring, which has precedence? [a, b, …, c, d] = [0, 1] |
| 04:34 | <Bakkot> | I would assume the early ones |
| 04:34 | <devsnek> | i assume it would fill `a` and `b` and then hit the ellipsis and switch to taking from the back |
| 04:34 | <devsnek> | and at that point throw because it was empty |
| 04:35 | <devsnek> | that being said `d` filling before `c` is terrible and should be illegal |
| 04:35 | <Bakkot> | [a, b, c] = [0, 1] doesn't throw |
| 04:35 | <ljharb> | not throw, just give undefined, right? |
| 04:35 | <michaelficarra> | [a, b, … c, d] = [0, 1, 2]? |
| 04:35 | <michaelficarra> | yeah should be undefined, not throw |
| 04:35 | <devsnek> | whatever it does |
| 04:35 | <ljharb> | michaelficarra: a is 0, b is 1, d is 2, c is [] |
| 04:35 | <Bakkot> | that case is fun |
| 04:35 | <devsnek> | surprised that doesn't throw in a declaration |
| 04:35 | <devsnek> | assignment is whatever |
| 04:36 | <michaelficarra> | a = 0, d = 2, b and c are 0.5 |
| 04:36 | <ljharb> | michaelficarra: oh wait no comma, hmm |
| 04:36 | <michaelficarra> | ljharb: typo |
| 04:36 | <ljharb> | michaelficarra: ok so if it's `...c` then what i said |
| 04:36 | <Bakkot> | oh this is a good point waldemar is making |
| 04:36 | <ljharb> | michaelficarra: if it's `..., c` then i'd expect `[0, 1, [], undefined, 2]` |
| 04:37 | <rickbutton> | what if [a, b, ...c, d] = arr |
| 04:37 | <rickbutton> | [...a] = arr |
| 04:37 | <ljharb> | rickbutton: `[0th, 1st, slice(2), 2nd]` |
| 04:37 | <michaelficarra> | rickbutton: that was ljharb's first answer |
| 04:38 | <ljharb> | that you can write confusing patterns doesn't necessarily mean that "what it does" is actually hard to unravel, given the rules suggested above |
| 04:38 | <rickbutton> | oh i see |
| 04:39 | <michaelficarra> | nice presentation, haxjs! |
| 04:40 | <rickbutton> | yeah im a big fan of more expressive destructuring |
| 04:40 | <haxjs> | Thank u everyone! |
| 04:41 | <mmarchini> | +10000 to gus proposal |
| 04:42 | <ptomato> | yes, love this |
| 04:42 | <ptomato> | I am a big fan of https://github.com/zestyping/q |
| 04:42 | <rickbutton> | +999 |
| 04:42 | <rkirsling> | +Math.E |
| 04:43 | <mmarchini> | +Infinity |
| 04:43 | <michaelficarra> | can't you just write `let debug = (x) -> { console.log(x); return x };` at the top of your file? |
| 04:43 | <Bakkot> | the thing hax wants sound more like `console.tap`, which browsers should absolutely add |
| 04:44 | <mmarchini> | michaelficarra: at the top of every file I ever debug? |
| 04:44 | <rickbutton> | you could but this is a really common desire, providing a common set of debug utilities seems useful |
| 04:45 | <michaelficarra> | it's not even like it's hard to work out how to do it yourself |
| 04:45 | <Bakkot> | I didn't realize this was just logging |
| 04:45 | <Bakkot> | I am way less in support of this if it is just logging |
| 04:45 | <michaelficarra> | I dunno, it seems really easy to do if you want it |
| 04:45 | <mmarchini> | It is |
| 04:45 | <ljharb> | `console.tap` seems great |
| 04:45 | <mmarchini> | It’s also easy as a language thing |
| 04:45 | <rickbutton> | I didn't think it was just logging, I assumed "implementation defined" meant that you could break on it |
| 04:45 | <michaelficarra> | I thought it would auto-thunk and conditionally evaluate or something |
| 04:45 | <ljharb> | mmarchini: logging isn't easy, there's no i/o in the language |
| 04:46 | <Bakkot> | (pedant hat: except for Date, which is I) |
| 04:46 | <ljharb> | troo |
| 04:46 | <michaelficarra> | eww Date |
| 04:47 | <bradleymeck> | jridgewell: no debugger is a statement |
| 04:47 | <Bakkot> | bradleymeck which means we could introduce it in expression position |
| 04:47 | <michaelficarra> | we'd need a NLTH but it should work |
| 04:47 | <bradleymeck> | sure |
| 04:47 | <gibson042> | metaproperty on debugger? |
| 04:47 | <ljharb> | michaelficarra: do we? you can't have a variable named debugger |
| 04:47 | <michaelficarra> | gibson042: why? no need |
| 04:47 | <ljharb> | oh but because of `debugger;` |
| 04:48 | <ljharb> | we could require `debugger(…)` |
| 04:48 | <michaelficarra> | ljharb: we definitely do |
| 04:48 | <ljharb> | yeah sorry, i realized you're right |
| 04:48 | <michaelficarra> | ljharb: even still |
| 04:48 | <Bakkot> | debugger\n(0) |
| 04:48 | <ljharb> | and even with the parens we'd need a NLTH yeah |
| 04:48 | <mmarchini> | I don’t think the proposal is intended for production logging shu |
| 04:49 | <michaelficarra> | I'm interested to hear this Kotlin solution |
| 04:49 | <shu> | mmarchini: oh, am i misunderstanding the examples? |
| 04:49 | <mmarchini> | I’m not speaking for Gus, but i wouldn’t except it to be used for prod logging |
| 04:49 | <shu> | okay |
| 04:49 | <shu> | that's fine, if the primary use case is actually debugging |
| 04:50 | <rickbutton> | yeah I'm thinking this is a trap in expression position |
| 04:50 | <mmarchini> | If we use the debugger statement it would be good if implementations _can_ log though |
| 04:50 | <rickbutton> | but your devtools could disable that or just log or whatever if you wanted |
| 04:50 | <mmarchini> | Most of the time I’m debugging nodejs I don’t have the debugger open |
| 04:50 | <rkirsling> | debugger() expr sgtm |
| 04:50 | <devsnek> | yeah don't use this in production logging lmao |
| 04:50 | <ljharb> | surely it'd be implementation-defined what it does |
| 04:50 | <rickbutton> | just like you can disable breakpoints |
| 04:50 | <shu> | devsnek: people do use console.log for production logging, no? |
| 04:50 | <mmarchini> | Also: don’t use console.log in production logging |
| 04:50 | <shu> | oh |
| 04:50 | <shu> | i stand corrected then |
| 04:51 | <devsnek> | lol |
| 04:51 | <ljharb> | shu: oh no, they do, all the time |
| 04:51 | <mmarchini> | Oh people definitely do. Don’t mean they should |
| 04:51 | <shu> | okay i unstand |
| 04:51 | <rickbutton> | nothin wrong with me using console.log on my meme website |
| 04:52 | <mmarchini> | I do read production as Node.js server, my bias definitely shows |
| 04:52 | <shu> | i read production as "sre's problem" |
| 04:52 | <mmarchini> | Gotta love be on the team that is SRE + developer |
| 04:53 | <rickbutton> | pl people |
| 04:53 | <devsnek> | lol |
| 04:53 | <rickbutton> | 's production is "getting it published" |
| 04:53 | <rickbutton> | whoops |
| 04:55 | <Bakkot> | it should have an argument |
| 04:55 | <Bakkot> | so that there is a sensible behavior when the devtools aren't open |
| 04:58 | <michaelficarra> | no please no I/O in the language |
| 04:59 | <michaelficarra> | positional parameters were a mistake |
| 04:59 | <rbuckton> | `(...[, , b]) => { }` |
| 05:00 | <michaelficarra> | functions get 1 parameter, use an options bag if you want "more" |
| 05:00 | <michaelficarra> | (or curry) |
| 05:00 | <rickbutton> | only good part of Objective-C |
| 05:00 | <shu> | michaelficarra: i can't have this conversation right now |
| 05:02 | <rkirsling> | this might be a tough Stage 2 but it's an easy Stage 1, from my perspective |
| 05:02 | <ljharb> | ystartsev: the same thing we gain from optional catch, and eliding identifiers from array destructuring |
| 05:02 | <shu> | rkirsling: i agree with that sentiment |
| 05:02 | <ystartsev> | ljharb: comment from our end is that this seems like a paper cut, and doesn't seem worth introducing syntax to remove identifier names |
| 05:03 | <Bakkot> | I dunno, I am not convinced this identifies a problem worth solving |
| 05:03 | <shu> | i am not neutral on this being a problem worth solving |
| 05:03 | <shu> | if all possibilities have technical issues, that makes me want to drop it than push harder |
| 05:03 | <Bakkot> | ... in which direction? |
| 05:03 | <shu> | Bakkot: -0 |
| 05:03 | <drousso> | why not just use `a`, `b`, ... or any random character? |
| 05:03 | <ljharb> | shu: what technical issues does elision have? |
| 05:03 | <ljharb> | drousso: unneeded bindings are not good |
| 05:03 | <shu> | ljharb: i don't know, i haven't looked or reviewed the grammars in depth |
| 05:03 | <ljharb> | kk |
| 05:04 | <shu> | ljharb: but there was also a comment about it being confusing |
| 05:04 | <shu> | i don't have a gut intuition on if *i* think it is yet |
| 05:04 | <ljharb> | i don't see how `(_, _, _, x)` is perfectly clear but `(, , , x)` is confusing |
| 05:04 | <shu> | i'd like to hear from jack works why he thinks it's confusing |
| 05:04 | <shu> | cause i don't think i got that |
| 05:05 | <michaelficarra> | I don't hate this proposal, but I am afraid of the refactoring hazard where you accidentally leave an extra comma hanging around |
| 05:05 | <ljharb> | especially when `const [, , , x] = arr` is a thing |
| 05:06 | <mmarchini> | In practice unused Params just end up as _ today |
| 05:06 | <ystartsev> | michaelficarra: thats a good dpoint |
| 05:06 | <mmarchini> | Not even _varName, just _ |
| 05:06 | <ljharb> | accurate |
| 05:06 | <Bakkot> | ljharb: that should't've been a thing, just like holes shouldn't've been a thing, and no one should ever write it, so people should not need to know what it is, which means it is not a good argument for expecting people to understnad it |
| 05:07 | <rbuckton> | `_`, `__`, ... or `_paramName` which is a waste to write for an unused binding. |
| 05:07 | <ystartsev> | mmarchini: then we don't really gain anything here |
| 05:07 | <mmarchini> | I’ve seen `fn(a, _ /* unused foo */, b)` |
| 05:07 | <ljharb> | Bakkot: on holes we agree violently |
| 05:07 | <shu> | michaelficarra: i agree with that worry |
| 05:07 | <rbuckton> | ystartsev: We gain the ability to lose things from our code we don't need. |
| 05:07 | <ljharb> | Bakkot: people use elision in array destructuring all the time, it's quite useful |
| 05:07 | <michaelficarra> | mmarchini: you can't duplicate names |
| 05:08 | <Bakkot> | :( |
| 05:08 | <mmarchini> | As a user, `fn(a, /* unused foo */, b)` seems a lot clearer that it’s not used |
| 05:08 | <rbuckton> | Its primarily useful for callbacks. |
| 05:08 | <ljharb> | Bakkot: `const [, match] = str.match(re)` |
| 05:08 | <shu> | mmarchini: more than `fn(a, unused_foo, b)`, how come? |
| 05:08 | <Bakkot> | ljharb `const match = str.match(re)[1]`, every time |
| 05:08 | <rkirsling> | I mean duplicability of `_` would be one solution |
| 05:08 | <Bakkot> | well, actually, these days named capturing groups and named destructuring instead |
| 05:08 | <rkirsling> | hence I think this is a worthy topic |
| 05:09 | <mmarchini> | shu: idk i’m just showing what I see in the wild |
| 05:09 | <ljharb> | Bakkot: a) widely used eslint rules force array destructuring instead of `[1]`, and b) many people prefer the destructuring form |
| 05:09 | <ljharb> | Bakkot: but yeah named groups is unarguably better |
| 05:09 | <mmarchini> | The vast majority of time |
| 05:09 | <shu> | mmarchini: i'm not sure i follow, elisions aren't a thing in the wild, so what are you seeing? |
| 05:09 | <Bakkot> | ljharb those are dumb rules; I stand by "no one should ever write that" even if there is a lint rule which tells them to |
| 05:09 | <mmarchini> | _ being used as the sole way of shadowing an unused param (instead of _varName) |
| 05:09 | <rbuckton> | ystartsev: This is about parameters, not arguments though |
| 05:10 | <michaelficarra> | rbuckton: the problem exists, even if she's mischaracterising it a bit |
| 05:10 | <shu> | mmarchini: sorry, i was replying to that `fn(a, /* unused foo */, b)` is clearer than a dummy named parameter |
| 05:11 | <shu> | rbuckton: yulia's point stands for parameters |
| 05:11 | <michaelficarra> | when removing an internal parameter name, you could leave its comma and wind up with bad offsets on the successive parameters |
| 05:11 | <mmarchini> | Yeah, what I meant is that elision with a comment is more clear than a _ or _ with a comment |
| 05:11 | <shu> | +1 |
| 05:11 | <shu> | +1 to michaelficarra |
| 05:11 | <rbuckton> | I understand that, but we already have existing semantics for how trailing `,` is handled in arrays and in destructuring, we would just need to be consistent. |
| 05:11 | <shu> | it's not trailing that i'm worried about |
| 05:11 | <shu> | it's the preceding ones |
| 05:11 | <michaelficarra> | so I would prefer explicit syntax but I don't think it's worth the new syntax for this kind of problem |
| 05:12 | <michaelficarra> | rbuckton: we're not talking about trailing commas here |
| 05:12 | <rbuckton> | I see elision as a benefit to callbacks. I wouldn't generally want to use it for named functions. |
| 05:12 | <shu> | michaelficarra: i think your point on readability puts me at a -0.5 from a -0 |
| 05:12 | <michaelficarra> | oh wow, the empty binding pattern is a good idea |
| 05:13 | <Bakkot> | has to be `{} = {}` to avoid errors though |
| 05:13 | <michaelficarra> | one of those doesn't accept null/undefined though |
| 05:13 | <Bakkot> | which sucks |
| 05:13 | <ljharb> | fails on null, same reason empty catch was needed |
| 05:13 | <Bakkot> | oh right |
| 05:13 | <ljharb> | *optional catch |
| 05:13 | <mmarchini> | :( |
| 05:13 | <rkirsling> | :( |
| 05:13 | <rbuckton> | :( |
| 05:14 | <devsnek> | :( |
| 05:14 | <michaelficarra> | I think we could reevaluate if entirely different possible solutions were presented |
| 05:14 | <rbuckton> | You can already elide trailing parameters in callbacks, you just don't bind them. There's just no way to do it for leading parameters. |
| 05:15 | <rbuckton> | sorry, "no way" is incorrect, there's still `(...[, , x]) => {}` |
| 05:16 | <rkirsling> | this really just feels like "I'm blocking Stage 1 because I can't envision this reaching Stage 2" |
| 05:16 | <bradleymeck> | that fires off Array[Symbol.iterator] though which if you are being defensive might not be viable (stares angrily at node internals) |
| 05:16 | <michaelficarra> | rkirsling: if you believe strongly enough that it *can't*, not just that it's unlikely, I think that's fine |
| 05:16 | <Bakkot> | rkirsling for my part I wasn't going to block, but I did think this did not successfully identify a problem worth solving |
| 05:16 | <Bakkot> | which is the criteria I use for stage 1 |
| 05:16 | <rkirsling> | alright |
| 05:17 | <rkirsling> | just feels mildly unfair |
| 05:17 | <ystartsev> | yep, thats what we identified as well |
| 05:17 | <michaelficarra> | I personally think the problem was worth solving, but only if there was very little cost. New explicit syntax was too much cost, and adding elision was too risky IMO. |
| 05:18 | <rkirsling> | I felt like I didn't hear a reason why making `_` duplicable would be so unreasonable |
| 05:18 | <devsnek> | queue needs to be advanced |
| 05:18 | <devsnek> | rkirsling: mark and yulia said unnamed parameters are bad |
| 05:18 | <ljharb> | rkirsling: i find making _ special wildly unreasonable |
| 05:18 | <michaelficarra> | rkirsling: yeah I think a solution like that could be possible, so I would've supported at least stage 1 |
| 05:18 | <ljharb> | rkirsling: identifiers are identifiers |
| 05:18 | <ljharb> | rkirsling: allowing duplication of anything tho, i'd love |
| 05:19 | <rkirsling> | fair enough |
| 05:20 | <michaelficarra> | devsnek: you could try going the route ljharb suggests as an alternative to your proposal |
| 05:21 | <devsnek> | michaelficarra: that was open |
| 05:21 | <ystartsev> | devsnek: one comment on your proposals: It is hard to tell what you are actually proposing |
| 05:21 | <ystartsev> | part of the reason i didn't say anything about debug is that the repo had so little information |
| 05:21 | <michaelficarra> | divmod <3 |
| 05:21 | <ystartsev> | and i was suprised by what was being proposed in the end, but couldn't think fast enough to actually say anything |
| 05:21 | <ljharb> | ystartsev: what problem is proposed to be solved? or what solution is being suggested |
| 05:22 | <ystartsev> | ljharb: devsnek just said that deduplication was an option for this |
| 05:22 | <ystartsev> | but that, in my opinion, is a wildly different proposal |
| 05:22 | <ljharb> | proposals prior to stage 2 are about problems, not solutions |
| 05:22 | <gibson042> | it is weird to have Math.imul |
| 05:22 | <devsnek> | i tried to be clear about it being "lets do something about duplicated parameters" |
| 05:23 | <devsnek> | i bring potential solutions to jog the room but this is just stage 1 |
| 05:23 | <devsnek> | er |
| 05:23 | <ystartsev> | devsnek: duplicated parameters don't exist right now, so there isn't anything to be done about them |
| 05:23 | <devsnek> | "lets do something about unused parameters" |
| 05:23 | <ystartsev> | yes |
| 05:23 | <devsnek> | sorry reading while writing :P |
| 05:24 | <ystartsev> | and based on what was proposed, and the readme, it is not clear that this isn't actually to the detriment of the language. the problem is small and all of the proposed solutions had significant problems |
| 05:24 | <michaelficarra> | FWIW I understood that we were trying to solve the unused leading parameters problem |
| 05:24 | <michaelficarra> | the debug one, however.... |
| 05:24 | <ystartsev> | presenting allowing duplicating *any* parameter is very different and requires a different review |
| 05:24 | <michaelficarra> | ^ |
| 05:24 | <ljharb> | ystartsev: i don't understand how a potential solution requires review prior to seeking stage 2 advancement |
| 05:25 | <devsnek> | so in the future, lean harder into enumerating actual solutions for stage 1? |
| 05:25 | <ystartsev> | ljharb: this isn't a solution, its an entirely different problem |
| 05:25 | <michaelficarra> | devsnek: please no |
| 05:25 | <ljharb> | ystartsev: duplicating any param addresses the same problem, "how do i avoid creating a bunch of unused bindings when i want unused params" |
| 05:25 | <ystartsev> | devsnek: i think the problem was well stated in this case, it just wasn't one that we saw as significant enough to solve right now |
| 05:25 | <ljharb> | (deduping creates 1 useless binding instead of n) |
| 05:25 | <devsnek> | ystartsev: that's fine |
| 05:25 | <devsnek> | i'm more concerned about my proposals being unclear |
| 05:26 | <ystartsev> | ljharb: then we would block it on it causing such far reaching implications for the language for so small a gain. our block stands |
| 05:26 | <mmarchini> | But that’s stage 1 |
| 05:26 | <ljharb> | ystartsev: right but again, that's a "seeking stage 2" concern |
| 05:26 | <ystartsev> | devsnek: that is related to the debug proposal, which had no explanatory text |
| 05:26 | <ljharb> | solutions *don't exist* prior to seeking stage 2 |
| 05:26 | <ljharb> | blocking stage 1 means "the problem isn't worth any solution" |
| 05:26 | <rkirsling> | I'm specifically uncomfortable with this *in the context of* the current process document revision |
| 05:27 | <ystartsev> | ljharb: as i said above, the problem is noted, but doesn't seem significant enough and our current solution is better |
| 05:27 | <rkirsling> | I have no expectation that this proposal would reach stage 2 |
| 05:27 | <ljharb> | like, things like this have gotten stage 1 with "it will never get to stage 2 unless the solution is wildly different" |
| 05:27 | <haxjs> | I think there is a good motivation to allowed unused param, it seems we create a too high bar for things like that. |
| 05:27 | <michaelficarra> | can this proposal go straight to stage 3? |
| 05:27 | <devsnek> | michaelficarra: why stop there |
| 05:27 | <michaelficarra> | devsnek: have you already implemented it? |
| 05:27 | <devsnek> | lol, no |
| 05:28 | <gibson042> | that has definitely happened in the history of this committee, though |
| 05:28 | <michaelficarra> | 1 to 4? I don't think so |
| 05:28 | <michaelficarra> | 1 to 3? maybe once |
| 05:29 | <michaelficarra> | 0 to 3? I don't think so either |
| 05:30 | <devsnek> | i think stage 2 would be completely reasonable here |
| 05:30 | <ljharb> | 0 to 3 has happened |
| 05:30 | <michaelficarra> | devsnek: me too |
| 05:30 | <haxjs> | i think api like that could advance fast, but complicated feature (for example, syntax involved) should be very careful |
| 05:30 | <ljharb> | didn't optional catch do that? or did it only do 0 to 2 |
| 05:30 | <ljharb> | nothing has ever skipped 3 that i'm aware of |
| 05:31 | <devsnek> | ljharb: ptc |
| 05:31 | <michaelficarra> | ljharb: I don't think optional catch skipped |
| 05:31 | <michaelficarra> | devsnek: that was pre-stage process |
| 05:31 | <rkirsling> | while this is about as uncontroversial as it gets, that kind of leap gives me a lot of pause |
| 05:31 | <devsnek> | michaelficarra: yeah was more a jab at it not having two implementations |
| 05:31 | <michaelficarra> | rkirsling: really what's being proposed here is a specific solution, so it should be fine |
| 05:32 | <rkirsling> | yeah I mean like if the spec is there, it does seem to be already implementable |
| 05:32 | <ljharb> | michaelficarra: https://github.com/tc39/notes/blob/8e8bfcbddcb29c09a10b0845a55af2e0d31b6f49/meetings/2017-07/summary.md says "advanced straight to Stage 3" |
| 05:32 | <ptomato> | geez, the notes doc is freezing for like 30 seconds at a time |
| 05:32 | <ptomato> | is that happening for anyone else? |
| 05:33 | <haxjs> | yes ! i also lagged when i was presenting |
| 05:33 | <haxjs> | make me very nervous...because i can't see the notes to catch all the questions... |
| 05:34 | <michaelficarra> | ljharb: straight from stage 2! I dunno |
| 05:35 | <ljharb> | michaelficarra: that was the first presentation as far as i can tell |
| 05:36 | <michaelficarra> | ljharb: damn I'm good |
| 05:36 | <ljharb> | :-p |
| 05:36 | <rickbutton> | should start a fantasy league |
| 05:36 | <ptomato> | it's especially hard when you're trying to take the notes :-P |
| 05:38 | <gibson042> | I can't unmute, but I'm also still interested |
| 05:43 | <michaelficarra> | ljharb: is that something that can be worked out between you and hax and only involve the rest of committee if you make progress that needs additional eyes? |
| 05:44 | <ljharb> | michaelficarra: specifically, it's "would a generic class brand check proposal obviate the need for `in`" - https://github.com/tc39/proposal-private-fields-in-in/issues/13 |
| 05:44 | <ljharb> | if issue discussion can persuade folks that either a) no, `in` is needed regardless or b) the more general proposal is not viable, i think that'd do it |
| 05:45 | <devsnek> | i don't agree that class brand checks replace the need |
| 05:45 | <ystartsev> | rkirsling: re the process document. I had included a line that stage 1 blocking was limited, but several delegates objected to that and it was removed |
| 05:45 | <ljharb> | devsnek: comments to that effect appreciated |
| 05:45 | <ystartsev> | so part of us blocking here was in line with the most recent reading of the document |
| 05:45 | <devsnek> | you could, in theory, have several different objects sharing some private fields but not others |
| 05:45 | <devsnek> | tying them together seems unfortunate |
| 05:45 | <ljharb> | devsnek: examples of just that would be helpful, i couldn't come up with one |
| 05:46 | <Bakkot> | with the private-decls proposal that would be common, even |
| 05:46 | <ystartsev> | i spoke to devsnek, that if he wanted to try to advance it I would back down -- but it is unlikely to get to stage 2 |
| 05:46 | <rkirsling> | hmm alright |
| 05:46 | <rkirsling> | yeah I certainly agree about stage 2 |
| 05:46 | <michaelficarra> | chairs: TCQ isn't updated |
| 05:47 | <Bakkot> | they're working on it |
| 05:47 | <robpalme> | it was a marathon |
| 05:48 | <Bakkot> | ljharb did you want to say your thing about disliking video? |
| 05:48 | <ljharb> | y |
| 05:48 | <rbuckton> | I wanted to try out Teams' transcription. I tried it very briefly a few days ago, but I think there are issues with transcriptions for Guests (due to permissions) |
| 05:48 | <Bakkot> | should get on the queue I guess |
| 05:48 | <devsnek> | lets make sure we're not just throwing tech at a problem |
| 05:48 | <devsnek> | we are better than the orange site |
| 05:49 | <Bakkot> | throwing tech at the problem is great |
| 05:49 | <Bakkot> | that is what tech is for |
| 05:49 | <Bakkot> | alleviating human suffering |
| 05:49 | <mmarchini> | It’s great, you usually get another problem :) |
| 05:49 | <devsnek> | lol i'm definitely saying tech can't help |
| 05:49 | <devsnek> | er |
| 05:49 | <devsnek> | i'm definitely ***not*** saying tech can't help |
| 05:49 | <ljharb> | Bakkot: super good job it's done so far |
| 05:49 | <michaelficarra> | rbucton: you can't be suggesting we use Teams for future meetings, have you seen how it has been (not) working for so many people? |
| 05:49 | <mmarchini> | Jk i think there’s room for improvements in the note taking area |
| 05:50 | <Bakkot> | ljharb https://ourworldindata.org/child-mortality |
| 05:50 | <mmarchini> | I helped a few times and oof it’s hard |
| 05:50 | <rbuckton> | michaelficarra: I've been collecting some feedback to provide to the team. |
| 05:50 | <michaelficarra> | Bakkot: that got dark quick |
| 05:50 | <ljharb> | lol i can't really counter "less kids die", so bailing out of that one |
| 05:50 | <Bakkot> | michaelficarra I dunno, that's probably the single most hopeful chart I have ever seen |
| 05:51 | <devsnek> | fewer* |
| 05:51 | <michaelficarra> | ^ |
| 05:51 | <rkirsling> | yeah exactly, it's like writing down every word in a lecture |
| 05:52 | <devsnek> | hitting the play button on those charts is insanely satisfying |
| 05:52 | <devsnek> | the animation is top notch |
| 05:52 | <mmarchini> | Video + auto generated transcript is probably the best compromise we can get to alleviate note taking from delegates |
| 05:52 | <akirose> | does everyone else not just cmd+f their linitialism? |
| 05:52 | <ljharb> | that's what i do |
| 05:53 | <rkirsling> | mmarchini: agree |
| 05:53 | <devsnek> | someone had the idea to hire dedicated note taker(s) |
| 05:53 | <ljharb> | it'd take a lot of talking before reviewing my own comments for all 4 days takes even close to an hour |
| 05:53 | <devsnek> | can stenotypes do codeblocks |
| 05:53 | <akirose> | yeah |
| 05:53 | <akirose> | let's hire mirabai |
| 05:53 | <rickbutton> | we should investigate hiring professionals |
| 05:53 | <Bakkot> | I am really hoping we can get live transcriptions into a google doc |
| 05:53 | <Bakkot> | from google speech or whatever |
| 05:53 | <Bakkot> | with note takers just fixing errors |
| 05:54 | <Bakkot> | and doing attribution |
| 05:54 | <akirose> | http://stenoknight.com 😍 |
| 05:54 | <rickbutton> | imagine paying people to take complete notes and formatting them well and categorizing them |
| 05:54 | <Bakkot> | i don't know how well it will work, but if it works as well as google meet's transcriptions it would be _incredible_ |
| 05:54 | <devsnek> | i can film my phone adding live captions, then OCR those into notepad and copy them into google drive |
| 05:54 | <rkirsling> | I would be willing to help _post-edit_ notes but I find the current procedure intensely stressful |
| 05:55 | <mmarchini> | Yeah same |
| 05:55 | <michaelficarra> | rkirsling: same |
| 05:55 | <rkirsling> | that's why I never volunteer, in spite of feeling awful for not volunteering |
| 05:55 | <mmarchini> | When I help I can’t pay attention to the discussion as I’m just trying to type as fast as folks talk |
| 05:55 | <Bakkot> | chairs: I would really like to say my thing about my proposal before the end of this meeting, since it determines if I try to do the work before the next meeting |
| 05:56 | <michaelficarra> | note-taking has made me miss opportunities to contribute and also just not fully follow the actual technical content of the conversation, so I just don't volunteer anymore |
| 05:56 | <devsnek> | https://cloud.google.com/speech-to-text/docs/streaming-recognize#speech-streaming-recognize-nodejs |
| 05:56 | <mmarchini> | + not being native English speaker I easily lose the discussion flow while typing |
| 05:56 | <Bakkot> | devsnek yeah that's the one I'm referring to |
| 05:56 | <devsnek> | not sure if their api supports real time |
| 05:56 | <Bakkot> | it does |
| 05:56 | <michaelficarra> | Bakkot: you can try it out at the next meeting regardless, just point it at the notes google doc |
| 05:56 | <devsnek> | it looks like it expects chunks of data |
| 05:56 | <Bakkot> | michaelficarra I need permission from everyone |
| 05:56 | <Bakkot> | legally |
| 05:56 | <Bakkot> | if someone's going to object I want to know before doing the work |
| 05:57 | <michaelficarra> | just ask at the beginning of the meeting then? |
| 05:57 | <michaelficarra> | POO it |
| 05:57 | <devsnek> | ask right now in your queue item |
| 05:57 | <devsnek> | i'd be happy to help btw |
| 05:57 | <michaelficarra> | waldemar is right |
| 05:57 | <ljharb> | even an interim artifact that results in public notes? |
| 05:58 | <ljharb> | k |
| 05:58 | <devsnek> | technically if we're streaming voice data to google we're not recording it |
| 05:59 | <Bakkot> | devsnek re: chunks: https://cloud.google.com/speech-to-text has a demo you can see it does live |
| 05:59 | <Bakkot> | (also their examples have the same thing) |
| 05:59 | <Bakkot> | (their code samples, that is) |
| 05:59 | <devsnek> | i was reading the nodejs example |
| 05:59 | <littledan> | Bakkot: I haven't reviewed the PR yet, I'm sorry. I don't want to hold it up if this will cause extra work for you, but I don't understand why it is coupled or in a hurry. I won't be rejoining the call as I am exhausted and will go back to sleep. |
| 05:59 | <Bakkot> | littledan no worries, it's not too much a burden, go back to sleep |
| 05:59 | <Bakkot> | I'll revisit next meeting |
| 05:59 | <michaelficarra> | littledan: too late, it's already held up |
| 06:00 | <devsnek> | aha you can do it via ws |
| 06:01 | <michaelficarra> | FYI google speech to text is *amazingly* accurate |
| 06:02 | <michaelficarra> | also FYI we will still have to do our own attribution |
| 06:02 | <devsnek> | Bakkot: streaming requests cut off after around 5 minutes |
| 06:02 | <devsnek> | according to the docs |
| 06:02 | <Bakkot> | devsnek their code samples deal with that |
| 06:03 | <Bakkot> | they cut it off and make a new stream before the timeout |
| 06:03 | <devsnek> | oh ok |
| 06:03 | <Bakkot> | (at least, from what i've read; I haven't done the work yet) |
| 06:03 | <rickbutton> | Bakkot: if you hook into the meet call with an extension you could auto detect the person speaking |
| 06:03 | <devsnek> | inb4 the hardest part is getting the text into google docs |
| 06:03 | <Bakkot> | rickbutton yeah, though that will not be in v1.0 |
| 06:04 | <Bakkot> | devsnek nah I've done that before, it's super easy |
| 06:04 | <rickbutton> | sure don't need it in an mvp |
| 06:04 | <Bakkot> | hardest part is getting the audio to the speech API |
| 06:04 | <Bakkot> | by far |
| 06:04 | <devsnek> | Bakkot: like via an api or like puppeteering |
| 06:04 | <Bakkot> | devsnek an API |
| 06:04 | <devsnek> | nice |
| 06:04 | <Bakkot> | gdocs api is good/free |
| 06:04 | <rickbutton> | does webaudio let you do redirection shenanigans? |
| 06:04 | <Bakkot> | not that I've seen, and also I can't figure out how to connect to the speech api from websockets |
| 06:05 | <devsnek> | RE the demo on the site |
| 06:05 | <rickbutton> | probably will need to use one of those virtual audio devices |
| 06:05 | <Bakkot> | yeah I can't figure out how their demo works |
| 06:05 | <rickbutton> | ill stop backseating |
| 06:05 | <Bakkot> | rickbutton that's my current plan! specifically https://github.com/ExistentialAudio/BlackHole |
| 06:05 | <rickbutton> | nice |
| 06:05 | <devsnek> | Bakkot: just reverse engineer zoom's protocol smh |
| 06:06 | <Bakkot> | devsnek someday, someday |
| 06:06 | <devsnek> | v2 |
| 06:06 | <rickbutton> | just invent a new voice chat application that has this built in |
| 06:06 | <devsnek> | call it meet |
| 06:06 | <Bakkot> | lol |
| 06:06 | <rickbutton> | just invent a new internet that is specifically used for routing our call |
| 06:06 | <Bakkot> | we can call it "telephones" |
| 06:07 | <devsnek> | vonage |
| 06:07 | <rickbutton> | man using landlines would make the delay so much nicer |
| 06:07 | <Bakkot> | btw if someone else wants to build this google speech api -> google docs thing, please reach out |
| 06:07 | <devsnek> | i'd be interested in helping |
| 06:07 | <devsnek> | as long as you use semicolons, that is |
| 06:08 | <rickbutton> | you have to use standardjs |
| 06:08 | <Bakkot> | ofc, I'm not a heathen |
| 06:08 | <rickbutton> | prettier with 2 spaces |
| 06:08 | <rickbutton> | the horror |
| 06:08 | <shu> | do people still use coffeescript |
| 06:08 | <Bakkot> | prettier has approximately the correct defaults |
| 06:08 | <Bakkot> | this is partly because I maintain it |
| 06:08 | <rickbutton> | Bakkot: false |
| 06:08 | <rickbutton> | :) |
| 06:08 | <devsnek> | shu: at least one very loud person does |
| 06:08 | <shu> | devsnek: oh? who? |
| 06:08 | <devsnek> | the guy who maintains it |
| 06:09 | <michaelficarra> | who maintains it nowadays? |
| 06:09 | <devsnek> | geoffrey booth |
| 06:09 | <michaelficarra> | oh, hmm |
| 06:09 | <devsnek> | most of the crazy stuff in node's current esm is due to his constraints for coffeescript |
| 06:09 | <devsnek> | its a very weird story |
| 06:10 | <robpalme> | I don't think that coffeescript is the main cause of Node's ESM quirks |
| 06:11 | <devsnek> | robpalme: not all of them |
| 06:11 | <devsnek> | but you would be surprised |
| 06:12 | <ljharb> | robpalme: coffeescript → babel |
| 06:12 | <ljharb> | robpalme: but also, what gus said |
| 06:13 | <rkirsling> | I like coffee and javascript |
| 06:13 | <rkirsling> | as two separate things |
| 06:13 | <robpalme> | I'd generalize it more to be "the code written by folk that loved ESM so much they wanted to use it to author CJS ahead of native support", rather than pinning it on any one tool |
| 06:14 | <devsnek> | robpalme: i sat through *years* of node esm meetings i'm too cynical |
| 06:14 | <robpalme> | i have sat through the same ones |
| 06:15 | <robpalme> | again, I would refrain from blaming specific tools - they are just reflecting positive healthy demand for ESM. maybe it's just a point of view thing. |
| 06:16 | <devsnek> | well there's a rabbit hole there but we can leave it at demand for esm |
| 06:16 | <devsnek> | anyway its 1am i'm going to log off, later folks |
| 06:16 | <rickbutton> | have a good night |
| 22:05 | <shu> | dandclark: hi! could you please PM your email? |
| 22:05 | <shu> | dandclark: i'd like to sync up on implementation work for import assertions in chromium |
| 22:22 | <dandclark> | shu: Sent you a PM |