| 02:05 | <keith_miller> | shu: I commented on the github thread. I'll start working on the slides now |
| 02:05 | <keith_miller> | ๐ฌ |
| 02:05 | <shu> | keith_miller: :+1: |
| 02:37 | <ljharb> | `import.meta` has landed |
| 02:39 | <devsnek> | ๐ |
| 02:47 | <rkirsling> | somebody's excited |
| 17:01 | <akirose> | My computer KPed and is struggling to start |
| 17:15 | <rkirsling> | +1 to "days are more destructive than hours" |
| 17:15 | <ljharb> | +2 |
| 17:16 | <ljharb> | +1 as well that a 3 day travel meeting requires up to 5 days blocked off |
| 17:20 | <jackworks7> | and it's 1am now I'm very sleepy even I had go to sleep 8pm |
| 17:21 | <jackworks7> | stay up for whole night for 4 or 5 days is not acceptable for me :( |
| 17:22 | <ljharb> | no matter how we structure the times, that's going to be a requirement for somebody |
| 17:22 | <ljharb> | during every meeting, i mean |
| 17:23 | <jackworks7> | maybe should collect acceptable time range of everyone and try to find a way to let less people meeting in 0am to 6am |
| 17:24 | <michaelficarra> | what rude response was Waldemar referring to? |
| 17:24 | <ljharb> | michaelficarra: https://github.com/tc39/Reflector/issues/276 iirc |
| 17:25 | <ljharb> | jackworks7: agreed, node TSC has a tool that tries to minimize that, and takes into account everybody's timezone |
| 17:25 | <michaelficarra> | oh I see, I think it was just miscommunication |
| 17:28 | <rkirsling> | yeah I was surprised by the callout |
| 17:36 | <ljharb> | +1 to waldemar/myles' point as well that the remote only works well because we have existing non-remote relationships |
| 17:36 | <rkirsling> | this queue is too long :( but I'll repeat that hallway track doesn't work if it requires you to juggle multiple machines |
| 17:36 | <jackworks7> | I have to say |
| 17:37 | <michaelficarra> | +1 ljharb |
| 17:37 | <jackworks7> | Minecraft with appropriate mods might be a better choice than the hub |
| 17:37 | <michaelficarra> | rkirsling: also if the 1 hour break takes 40 minutes in food prep |
| 17:37 | <michaelficarra> | (for lunch) |
| 17:38 | <michaelficarra> | also no Wednesday dinner, which often was very productive |
| 17:38 | <michaelficarra> | a lot of proposals only exist because of discussion that happened at the dinners |
| 17:38 | <ljharb> | +1000 ^ |
| 17:38 | <rkirsling> | yeah I thought that Weds dinner would've been the sole appropriate time FOR hubs |
| 17:38 | <rkirsling> | but then it didn't happen? |
| 17:38 | <ljharb> | nobody showed up |
| 17:39 | <drousso> | yeah the wednesday dinner |
| 17:39 | <rkirsling> | I didn't show up because we just ended with no remark |
| 17:39 | <ljharb> | hubs is open whenever we're not in plenary, 24/7 :-p |
| 17:45 | <caridy> | At TPAC/WC meeting last week (first time remote for everyone), we did 4 hours per day... worked well (although less people: ~25 delegates) |
| 17:53 | <ystartsev> | rkirsling: srry i fell asleep :| |
| 17:53 | <ystartsev> | for the dinner |
| 17:53 | <littledan> | I *love* bterlson 's idea here! |
| 17:53 | <littledan> | Node collaborator summits are awesome, and I think we could do a lot in something like this |
| 17:53 | <littledan> | it could be adjacent to a normative plenary |
| 17:53 | <rkirsling> | ystartsev: oh sorry, I wasn't mean to blame anybody :( |
| 17:54 | <ystartsev> | ๐ |
| 17:54 | <akirose> | thinking of it more like a "collaborator summit" i think is a great way to think of it |
| 17:54 | <littledan> | also wanted to mention, lots of non-US countries have difficult border policies that would inhibit travel of TC39 delegates. In fact, I doubt there's any rich country we could choose in the world that everyone could just go to. |
| 17:55 | <bterlson> | I messed up by calling it a conf |
| 17:55 | <bterlson> | collaborator summit is a better term |
| 17:55 | <ljharb> | littledan: +1 |
| 17:55 | <ystartsev> | bterlson: i like that idea a lot |
| 17:55 | <littledan> | (multiple Igalians have had trouble getting into Canada for technical conferences, for example) |
| 17:56 | <ljharb> | +1 again, canada is not better than the US here |
| 17:56 | <shu> | i had top drop for a 1:1 for 30 minutes |
| 17:56 | <shu> | was there discussion around short-form vs long-form plenaries and where did folks land? |
| 17:56 | <leobalter> | Today is seems that Canada is easier. Back in 2013 it was not fun for me attending a Mozilla Summit there. |
| 17:57 | <ljharb> | shu: some preferred more days shorter hours, some preferred fewer days |
| 17:57 | <shu> | any clear minority or majority? |
| 17:58 | <ljharb> | not that i saw, but i wasn't keeping tabs |
| 17:58 | <leobalter> | shu IMO not in dense, definitely a subtopic that needs work in the current discussion |
| 17:58 | <shu> | sorry, in dense? |
| 17:58 | <leobalter> | it havent'been discussed extensively |
| 17:58 | <littledan> | yeah, we had some discussion but we didn't have much of a conclusion or even a strong tendency in the room |
| 17:59 | <shu> | okay, thank you |
| 18:02 | <ljharb> | wsdferdksl: ebola doesn't have a cure or vaccine, and zero cases weren't required to avoid restrictions. i'm not sure epidemiologists would agree with your logic here |
| 18:02 | <shu> | this is not a productive discussion |
| 18:02 | <shu> | i suggest chairs get to dan's item |
| 18:02 | <ljharb> | fair |
| 18:03 | <shu> | this can be executive decisioned imo |
| 18:03 | <howdoi> | where can I subscribe myself to the Temporal weekly meetings? |
| 18:04 | <ghmcadams> | I agree. Its not about knowing what will happen and deciding what is best. Its about planning now based on our best guess. |
| 18:05 | <michaelficarra> | maybe I'm dumb, but if a country has 0 cases, we have rapid cheap testing available, and the country requires everyone entering its borders to test negative, can't we theoretically travel safely before a vaccine? |
| 18:05 | <ghmcadams> | its not that simple. tests might be inaccurate or take longer to get a result than we want to wait. |
| 18:06 | <bterlson> | michaelficarra: if you're healthy sure |
| 18:06 | <ljharb> | michaelficarra: we don't even need 0 cases, just thorough and rapid testing |
| 18:06 | <rkirsling> | thank you for PoO |
| 18:06 | <ljharb> | and accurate ofc |
| 18:06 | <rkirsling> | this subtopic needs to stop |
| 18:07 | <ghmcadams> | carriers exist with no symptoms. its not just about safety for us. its about all who we come in contact with while traveling, after traveling, etc. I for one wouldn't travel and put my family at risk |
| 18:07 | <ljharb> | ghmcadams: symptoms don't affect testing, just who you decide to test |
| 18:07 | <ystartsev> | ljharb: you can get false negatives with current tests |
| 18:08 | <ljharb> | sure, current tests aren't good enough |
| 18:08 | <benjamn> | this line of discussion is an absolute waste of time |
| 18:08 | <ystartsev> | yeah i don't think this is useful |
| 18:08 | <benjamn> | do we need another point of order? |
| 18:08 | <benjamn> | maybe he's done |
| 18:09 | <shu> | please, chairs, let's move to dan's item |
| 18:09 | <benjamn> | yes please |
| 18:11 | <ljharb> | here's ES2020 for folks' review: https://github.com/tc39/Reflector/issues/282 |
| 18:11 | <Bakkot> | nice! |
| 18:12 | <wsdferdksl> | ljharb: ebola is very different. This is not a productive discussion. |
| 18:12 | <benjamn> | MylesBorins: thank you, I also disagree |
| 18:12 | <ljharb> | wsdferdksl: agreed, neither are any claims from a non-epidemiologist on how epidemics work. |
| 18:12 | <ljharb> | re ES2020, for those who have had PDF complaints, please check the PDF - it's in A4, with page numbers and a clickable TOC |
| 18:12 | <wsdferdksl> | ljharb: That's incorrect. |
| 18:13 | <wsdferdksl> | It's unproductive to keep bringing up the claim about needing to be an epidemiologist to contribute to the discussion. That's false. |
| 18:13 | <leobalter> | ljharb please let me know what you've used for the page numbers, etc |
| 18:13 | <ljharb> | leobalter: adobe acrobat DC, free trial |
| 18:14 | <leobalter> | yeah, I wondered if there is something beyond acrobat for that. I don't want to personally pay for it to just print the PDF |
| 18:15 | <ljharb> | i printed to PDF just from my mac; then i edited it to add the 4 frontmatter pages, and add page numbers to pages 5+ |
| 18:15 | <Bakkot> | we should figure out a better alternative. |
| 18:15 | <ljharb> | adding the pages i did in Preview; only the page numbers and editing text content required Acrobat |
| 18:15 | <devsnek> | you could probably make a script using pdfkit or something |
| 18:17 | <michaelficarra> | ljharb: the editors list is wrong |
| 18:17 | <Bakkot> | should just have ecmarkup output latex and then run latex2pdf |
| 18:17 | <ljharb> | michaelficarra: for 2020? |
| 18:17 | <michaelficarra> | in the PDF download |
| 18:18 | <ljharb> | michaelficarra: we talked about that on the editor call; that the list would be updated for 2021, not for 2020 |
| 18:18 | <michaelficarra> | oh I forgot that |
| 18:18 | <michaelficarra> | okay that makes sense |
| 18:20 | <littledan> | I'm very much in favor of cancelling the in-person plenaries ahead of time. Having to plan for and incrementally cancel meetings would be stressful and complicated. |
| 18:20 | <caridy> | we have 60 people in this meeting, just ask... |
| 18:21 | <akirose> | it sucks. i know it sucks. |
| 18:21 | <akirose> | but it justโฆ it is what it is. |
| 18:21 | <ljharb> | MylesBorins: i'm not a fan of shutting down any possibility of in-person meetings in 2020, i'm just acking the likelihood that they won't be possible |
| 18:21 | <littledan> | I'm a big fan of providing certainty this year. We have enough to worry about. I'm not a fan of this situation. |
| 18:22 | <apaprocki> | my (elided) queue item was that I can't wait until June to move on Tokyo in September.. I need to make a call on it within a month, as ~1k people /day are dying in NYC, and that call will 99.9% be => cancel |
| 18:22 | <brad4d> | asking here - can drop from tcq if answered |
| 18:22 | <ystartsev> | the situation in budapest is also very problematic |
| 18:22 | <brad4d> | how much lead time is needed to plan an in-person plenary? |
| 18:22 | <apaprocki> | ~180 days it starts |
| 18:22 | <brad4d> | ok, thx |
| 18:22 | <littledan> | and it's not like we could move to Barcelona to solve the problems in Budapest! |
| 18:22 | <apaprocki> | :P |
| 18:24 | <jackworks7> | ljharb: I like the new PDF, I can upgrade from es2018 to es2020 now |
| 18:24 | <ljharb> | MylesBorins: i just hope that after covid is done and everyone's comfortable, we don't need consensus to restart in-person meetings |
| 18:24 | <ljharb> | jackworks7: glad to hear it! |
| 18:24 | <littledan> | +1 to msaboff 's comment |
| 18:24 | <jridgewell> | ++ |
| 18:24 | <ystartsev> | ++ |
| 18:24 | <ystartsev> | + |
| 18:24 | <ystartsev> | :| |
| 18:25 | <jridgewell> | ๐ |
| 18:25 | <shu> | one is unary one is binary |
| 18:25 | <devsnek> | 111 |
| 18:25 | <littledan> | did we move from JS to BF as the language for this channel? |
| 18:26 | <ystartsev> | can find a reason to make :| a valid opeerator? i feel like that emoji expresses my feelings while coding |
| 18:26 | <devsnek> | [>>++] |
| 18:26 | <jackworks7> | just for curious, is there a diff between spec of last year and current year so that the implementer can know what details has changed in a year? |
| 18:26 | <rbuckton> | I've always been partial to :/ |
| 18:26 | <Bakkot> | littledan http://www.jsfuck.com/ |
| 18:26 | <ystartsev> | ^also good |
| 18:26 | <msaboff> | LOL to Mark Cohen's queue item |
| 18:26 | <devsnek> | jackworks7: you can diff it using the github releases, and we also list important changes at the top of the document |
| 18:27 | <wsdferdksl> | :(){ :|:& };: |
| 18:27 | <ljharb> | jackworks7: there's a "commits" link on the github repo |
| 18:27 | <ljharb> | jackworks7: also, the intro summarizes changes in each edition |
| 18:28 | <jackworks7> | oh cool |
| 18:28 | <rwaldron> | MylesBorins akirose shu can I ask a favor? |
| 18:28 | <ljharb> | jackworks7: but i believe most implementers don't use the yearly editions; the instant it lands in master it's in the languge |
| 18:28 | <akirose> | what up |
| 18:28 | <Bakkot> | jackworks7: git log --pretty=oneline --abbrev-commit es2019..es2020 | grep 'Normative:' |
| 18:28 | <rwaldron> | Would we be able to do "Atomics.waitAsync error rejection PR" before my hard 5pm EST stop? |
| 18:28 | <michaelficarra> | ึถ๐ฎโโ๏ธ๐ #tdz |
| 18:29 | <shu> | rwaldron: weakrefs is more pressing |
| 18:29 | <Bakkot> | ljharb a lot of tooling implementors do use the yearly versions |
| 18:29 | <ljharb> | ah that's true, eslint and babel and whatnot |
| 18:29 | <ljharb> | fair |
| 18:29 | <rwaldron> | shu no doubt, but I was hoping that maybe MylesBorins wouldn't mind doing the process change topic at the end of the day |
| 18:29 | <devsnek> | tooling implementations need to stop using yearly versions |
| 18:29 | <shu> | rwaldron: i think we should consider waitAsync bumped until next meeting if schedule is tight. i'm also going to try to do the incubator call chartering in ~10mins |
| 18:30 | <shu> | rwaldron: ah okay, then the only constraint for me is weakrefs don't get bumped |
| 18:30 | <MylesBorins> | I think that process discussion will be super short fwiw |
| 18:30 | <rwaldron> | shu I also need an answer on weakrefs <3 |
| 18:30 | <MylesBorins> | if think we probably can squeeze both in before lunch |
| 18:30 | <akirose> | we have some extra time, just a matter of juggling around some things |
| 18:30 | <rwaldron> | MylesBorins if shu agrees, then I would be very appreciative |
| 18:31 | <jridgewell> | There's a 75min empty slot at the end of today |
| 18:31 | <jridgewell> | We should have time for everything and then some |
| 18:31 | <akirose> | yeah like i said it's all about juggling |
| 18:31 | <shu> | i'm happy to move waitAsync up and try to time it to 15mins, though i feel like it'll overflow to at least 20 or 25 |
| 18:31 | <MylesBorins> | want to do yours first? |
| 18:31 | <MylesBorins> | shu ? |
| 18:32 | <shu> | which of mine? |
| 18:32 | <shu> | the answer is yes though |
| 18:32 | <MylesBorins> | We have 25 minutes ish |
| 18:32 | <MylesBorins> | I'll move process discusssion |
| 18:32 | <rwaldron> | MylesBorins if we could do both the weakrefs and waitAsync before I have to depart for child care, I would be ever so grateful |
| 18:32 | <shu> | weakrefs is going to need more than 25 minutes |
| 18:32 | <shu> | i can try to do either incubator call chartering or waitAsync in 25 minutes, so let's do incubator calls? |
| 18:33 | <shu> | err, i mean waitAsync? |
| 18:33 | <rwaldron> | I don't know what the incubator calls topic is |
| 18:33 | <MylesBorins> | shu are you ok with me swapping incubator and weakrefs? |
| 18:33 | <rwaldron> | yes waitAsync |
| 18:34 | <rwaldron> | Here's my wishlist: can we do weakrefs and waitasync next |
| 18:34 | <shu> | MylesBorins: i'm not up to date on the ordering, what concrete times are we takling about? |
| 18:34 | <MylesBorins> | https://hackmd.io/8Ok_eshBSTCfd8Zh8crQ3Q |
| 18:34 | <MylesBorins> | stomics would be next |
| 18:34 | <MylesBorins> | with 25 minutes |
| 18:34 | <MylesBorins> | then lunch for an hour |
| 18:34 | <MylesBorins> | then weakrefs |
| 18:34 | <rwaldron> | phonetically... stomics will come after whatever we do next |
| 18:34 | <akirose> | -_- |
| 18:34 | <rwaldron> | :D |
| 18:35 | <rwaldron> | akirose gets me |
| 18:35 | <akirose> | lol only begrudgingly |
| 18:35 | <shu> | MylesBorins: that looks okay with me |
| 18:35 | <devsnek> | we have 75m of extra time? |
| 18:35 | <rkirsling> | rwaldron: nice |
| 18:35 | <rwaldron> | :D |
| 18:35 | <MylesBorins> | yup |
| 18:35 | <rwaldron> | rkirsling ^5 |
| 18:35 | <MylesBorins> | I moved stuff around |
| 18:35 | <MylesBorins> | PTAL |
| 18:35 | <akirose> | ๐ |
| 18:36 | <rwaldron> | MylesBorins thank you so much |
| 18:36 | <MylesBorins> | rwaldron you will be done at 1:25 PT |
| 18:36 | <rwaldron> | I really appreciate that |
| 18:36 | <jackworks7> | devsnek: (re: tooling implementations need to stop using yearly versions |
| 18:37 | <rwaldron> | And thank you to everyone else for being so flexible and accamodating |
| 18:55 | <rbuckton> | While it possibly suffers from the same drawback as the `load` workaround, is it feasible to workaround with a `Atomics.wait` with a 0ms timeout for fail-fast, then call `Atomics.waitAsync`? |
| 18:55 | <Bakkot> | that suffers the same drawback as the `load` workaround |
| 18:55 | <Bakkot> | oh actually |
| 18:55 | <Bakkot> | the actual problem is that you cannot `.wait` on the main thread |
| 18:56 | <Bakkot> | the point of waitAsync is that you can do it on the main thread |
| 18:57 | <rbuckton> | You cannot `.wait` on the main thread? or you "should not" `.wait` on the main thread? |
| 18:57 | <Bakkot> | cannot |
| 18:58 | <devsnek> | it throws |
| 18:58 | <rbuckton> | Ah: https://tc39.es/ecma262/#sec-agentcansuspend |
| 18:59 | <devsnek> | "the main thread" is an iffy way to describe it imo |
| 18:59 | <devsnek> | in node's main thread you can use Atomics.wait just fine |
| 18:59 | <rbuckton> | Its agent dependent, so on the web you *cannot*, but in other hosts you might be able to. |
| 18:59 | <rbuckton> | devsnek: that's why I was confused, as I've done this successfully in Node. |
| 19:00 | <devsnek> | had same confusion with shu yesterday :P |
| 19:00 | <Bakkot> | sorry, I should have specified on the web, yes |
| 19:00 | <devsnek> | do things still ship Atomics.wake |
| 19:00 | <Bakkot> | chrome does, looks like |
| 19:01 | <devsnek> | looks like everything still does |
| 19:01 | <jridgewell> | For the uninitiated, Zalgo is: |
| 19:01 | <devsnek> | wasn't that supposed to be removed at the same time as SAB is reenabled |
| 19:01 | <jridgewell> | https://www.irccloud.com/pastebin/p0JJpKT7/zalgo.js |
| 19:01 | <jridgewell> | The logs must always be 'ABC' or 'ACB' |
| 19:01 | <ljharb> | littledan: by "no change" do you mean, sometimes throws sometimes returns a promise? or always returns a promise |
| 19:01 | <littledan> | ljharb: Yes, unfortunately |
| 19:01 | <jridgewell> | If it's sometimes one and sometimes the other, you've unleased Zalgo |
| 19:01 | <littledan> | that it sometimes throws a promise, sometimes not |
| 19:02 | <littledan> | so, tip of tree |
| 19:02 | <ljharb> | littledan: right, that violates the consensus/policy we all agreed on with async functions |
| 19:02 | <Bakkot> | "no I hat thenables" +1 |
| 19:02 | <ljharb> | i'd consider that a blocker |
| 19:02 | <jridgewell> | Returning a sync thenable doesn't solve Zalgo |
| 19:02 | <rbuckton> | Much prefer the tagged/discriminated union approach |
| 19:04 | <devsnek> | the argument validation is definitely a problem |
| 19:05 | <rbuckton> | If you're using `async/await` it's not that bad. I'd argue that returning `Promise | string` is worse. |
| 19:08 | <ljharb> | not that bad anyways imo; `result.async ? result.value.then(doWork) : doWork()` or similar |
| 19:09 | <rbuckton> | -1 to zalgo by way of untagged union, +1 to tagged union |
| 19:10 | <ljharb> | lol, horrible idea: the string constants could instead be well-known frozen Promise objects แ( แ )แ |
| 19:10 | <rbuckton> | ljharb: I'd consign that one to #temporaldeadzone |
| 19:10 | ljharb | slinks away |
| 19:11 | <rbuckton> | /s |
| 19:11 | <devsnek> | this is one weird api |
| 19:11 | <rbuckton> | No kidding. |
| 19:11 | <Bakkot> | atomics get weird fast |
| 19:12 | <rbuckton> | Consensus is `Promise | "ok" | "not-equal" | "timed-out"`? |
| 19:12 | <Bakkot> | no, consensus is tagged |
| 19:12 | <rbuckton> | Ok, good. |
| 19:12 | <shu> | {async:true|false, value:"not-equal"|"timed-out"|Promise} |
| 19:12 | <Bakkot> | { async: true, value: Promise } or { async: false, "ok" | "not-equal" | "timed-out" } |
| 19:12 | <Bakkot> | oh yeah not "ok" in the last branch |
| 19:13 | <shu> | yeah ^ |
| 19:13 | <rbuckton> | `{ async: false, value: "ok" | "not-equal" | "timed-out" } | { async: true, value: Promise<"ok" | "not-equal" | "timed-out"> }` |
| 19:13 | <devsnek> | `any` |
| 19:13 | <rbuckton> | Why would `"ok"` not be valid if the timeout is 0ms? |
| 19:13 | <shu> | rbuckton: almost |
| 19:14 | <shu> | there is no promise resolution of "not-equal" |
| 19:14 | <shu> | there is no slow fail-fast case |
| 19:14 | <rbuckton> | Ah, I see. |
| 19:14 | <Bakkot> | wait shu can you give the actual correct type |
| 19:14 | <Bakkot> | I keep confusing myself |
| 19:14 | <Bakkot> | for which is legal where |
| 19:15 | <shu> | `{async: false, value: "not-equal" | "timed-out" } | { async: true, value: Promise<"ok" | "timed-out"> }` |
| 19:15 | <sffc> | howdoi: if you send me your Gmail I'll add you to the Google Group which comes with the weekly meeting invite |
| 19:15 | <rbuckton> | ๐ |
| 19:15 | <Bakkot> | great |
| 19:16 | <shu> | for async:false to be able to return `"ok"`, the implementation would need to implement a microwait like `pause` to see if it got changed to the value you want in the 1microsecond OS quantum or whatever |
| 19:16 | <shu> | and that is just weird |
| 19:16 | <howdoi> | sffc: sure, thanks! |
| 19:16 | <shu> | and thus not allowed |
| 19:16 | <rbuckton> | shu: Yeah, makes sense. |
| 20:06 | <robpalme> | we will resume in 5 mins |
| 20:11 | <devsnek> | weakrefs ๐ |
| 20:14 | <devsnek> | are there any major engines where allocating an ordinary object isn't just incrementing a pointer |
| 20:15 | <shu> | only young generations tend to be bump allocated |
| 20:16 | <devsnek> | yeah i'm guessing the result of atomics.waitAsync would not be old generation :P |
| 20:16 | <shu> | almost always they will be young |
| 20:17 | <Bakkot> | also there's no way that object allocation is going to be as expensive as a microtask tick from the application's perspective |
| 20:17 | <devsnek> | i know in v8 you can explicitly ask for young or old generation too |
| 20:17 | <devsnek> | actually i don't know if that's exposed to torque yet |
| 20:19 | <ghmcadams> | I noticed that today, people do not have their full name and company showing. Can we all make this change as we did on Tuesday? |
| 20:21 | <ghmcadams> | (in zoom) |
| 20:22 | <MylesBorins> | point of order raised |
| 20:25 | <ghmcadams> | Thank you, Myles |
| 20:27 | <jridgewell> | Is there an example use case that needs sync finalization with long-running task? |
| 20:27 | <jridgewell> | Like, games, but how are the games allocating JS objects? |
| 20:27 | <jridgewell> | And why do they need to be cleaned up? |
| 20:28 | <devsnek> | jridgewell: right now they have to emit manual cleanup |
| 20:28 | <devsnek> | which can introduce subtle leaks and such |
| 20:28 | <jridgewell> | Cleanup of what? |
| 20:29 | <jridgewell> | The thing I don't understand is how they're using JS objects |
| 20:29 | <devsnek> | they're allocating memory in arraybuffers |
| 20:29 | <devsnek> | emscripten/wasm |
| 20:29 | <devsnek> | the memory has to be manually deallocated |
| 20:29 | <jridgewell> | And they're sending individual array buffers to the main thread? |
| 20:29 | <devsnek> | no |
| 20:29 | <jridgewell> | To do what? |
| 20:30 | <devsnek> | you have some native code that does things |
| 20:30 | <devsnek> | it uses a not shared arraybuffer as its memory |
| 20:30 | <devsnek> | when you pass a reference into that memory to js |
| 20:30 | <devsnek> | you have to manually track the lifetime |
| 20:30 | <devsnek> | finalizationregistry means you no longer have to manually track the lifetime |
| 20:30 | <jridgewell> | Yes, I understand that part |
| 20:31 | <jridgewell> | What I don't understand is how they're using the JS objects on the JS side of the bridge |
| 20:31 | <jridgewell> | If they're sending something to JS, what do they use that for? |
| 20:31 | <devsnek> | you usually are wrapping a native lib and calling it from js |
| 20:31 | <jridgewell> | Any explanation of that would be really helpful for me to understand |
| 20:32 | <devsnek> | like `{ ref: n, x() { _binding.x(this.ref) }` |
| 20:32 | <devsnek> | you have instances like that |
| 20:32 | <devsnek> | they're just wrapping native libraries |
| 20:32 | <devsnek> | like native addons in nodejs but using wasm/emscripten instead |
| 20:33 | <devsnek> | (native addons in node get weakref tracking btw) |
| 20:33 | <jridgewell> | > you usually are wrapping a native lib and calling it from js |
| 20:33 | <jridgewell> | Doesn't that mean you live in JS world, and are subject to the JS event loop? |
| 20:34 | <devsnek> | not inherently |
| 20:34 | <devsnek> | the applications are usually a lot more complex |
| 20:34 | <sffc> | Is GitHub down? |
| 20:34 | <mhofman> | it is for me in SF |
| 20:34 | <rickbutton> | yeah |
| 20:34 | <devsnek> | i think the emscripten repo might have some more in-depth examples |
| 20:34 | <devsnek> | yeah it seems down |
| 20:35 | <jridgewell> | Lol, bad timing. |
| 20:35 | <ljharb> | sffc: https://www.githubstatus.com/ |
| 20:35 | <bterlson> | github pages is up at least๐ |
| 20:35 | <ljharb> | gist is down too tho |
| 20:39 | <mmarchini> | +1 thanks gus |
| 20:39 | <devsnek> | lol |
| 20:44 | <devsnek> | a usable decorator api might start from a most scoped api instead of a least scoped api |
| 20:44 | <devsnek> | `const a = with operator Vector { v1 + v2 }` or something |
| 20:44 | <devsnek> | expands out to multiple statements |
| 20:44 | <devsnek> | but encourages you to keep it small so you don't slow down other operations |
| 20:48 | <devsnek> | s/decorator/operator overloading/ lol |
| 20:49 | <rbuckton> | aren't the cases where you do a binary operator like `+` between a number and a non-number already not fast path because of `@@toPrimitive` and `valueOf`? |
| 20:50 | <devsnek> | depends on what you call fast path |
| 20:50 | <devsnek> | engines optimize based on whether those methods exist, have been modified, and whatnot |
| 20:53 | <ljharb> | https://tc39.es/ecma262/2020/ |
| 20:53 | <rbuckton> | Couldn't they also optimize based on whether those operators are present on the object? |
| 20:53 | <bradleymeck> | rbuckton: there are cases where it is a non-fast path yea, but also cases where it is fast |
| 20:54 | <rbuckton> | You shouldn't be able to add operators to an existing primitive, so `1 + 1` would always remain fast-path. |
| 20:55 | <ljharb> | https://usercontent.irccloud-cdn.com/file/uUWGvAJE/ECMA-262%2011th%20edition%20June%202020.pdf |
| 20:55 | <rbuckton> | Depending on how the `struct` proposal I'm working on evolves, if operators are limited to only `struct` values then that becomes a specific heuristic that would reduce the need for a `with operators`-like syntax. |
| 20:56 | <rkirsling> | yay expedited roll call |
| 20:56 | <bradleymeck> | i had to drop due to baby but wanted to say yes |
| 20:57 | <devsnek> | is that an official yes from godaddy |
| 20:59 | <rwaldron> | Ok, I have to roll off for childcare now. Thanks everyone!! |
| 21:00 | <akirose> | wycats: we are missing you this week |
| 21:00 | <ljharb> | MylesBorins: i assume applicant members don't count |
| 21:00 | <MylesBorins> | I don't think so |
| 21:00 | <devsnek> | ๐ |
| 21:01 | <devsnek> | ljharb: how many pages this year |
| 21:01 | <ljharb> | 856 |
| 21:01 | <Bakkot> | 860 pages in the PDF |
| 21:02 | <ljharb> | 4 cover, + 856 from the spec itself |
| 21:02 | <devsnek> | a good amount |
| 21:02 | <MylesBorins> | such spec |
| 21:02 | <ljharb> | 2019 had 764 of spec, 2018 had 801, 2017 had 881 |
| 21:02 | <rkirsling> | many text |
| 21:02 | <devsnek> | 1000 by 2030 |
| 21:03 | <Bakkot> | 46 of those pages are the table of contents |
| 21:03 | <Bakkot> | ljharb wait, we were actually trending down for a while? |
| 21:03 | <bterlson> | btw you cannot re-log in to TCQ |
| 21:03 | <ljharb> | oh lol true, i didn't count TOC pages |
| 21:03 | <devsnek> | ljharb: the fonts in this pdf are iffy |
| 21:03 | <ljharb> | Bakkot: lol yes apparently! |
| 21:03 | <devsnek> | or at least rendered iffy |
| 21:03 | <bterlson> | so I recommend not closing tcq while github is down :) |
| 21:03 | <Bakkot> | devsnek they look great to me |
| 21:03 | <ljharb> | devsnek:in the first 4 pages? or the rest |
| 21:03 | <devsnek> | https://gc.gy/53566426.png |
| 21:03 | <ljharb> | devsnek: ignore the first 4 pages |
| 21:03 | <ljharb> | hm |
| 21:04 | <devsnek> | these letters are too thin |
| 21:04 | <devsnek> | and the bold text for literals is too thick |
| 21:04 | <Bakkot> | devsnek: https://i.imgur.com/yTTpqAt.png |
| 21:04 | <devsnek> | https://gc.gy/53566480.png |
| 21:04 | <Bakkot> | looks fine to me |
| 21:04 | <devsnek> | hm |
| 21:05 | <devsnek> | maybe firefox then? |
| 21:05 | <rkirsling> | linux woes? |
| 21:05 | <devsnek> | i don't have anything custom in linux fontstuff except for fira code |
| 21:05 | <Bakkot> | linux has traditionally had problems with rendering |
| 21:05 | <devsnek> | why is it green |
| 21:06 | <devsnek> | well that shade of green |
| 21:07 | <Bakkot> | historical reasons :P |
| 21:07 | <ljharb> | all color shades were chosen by me and brian 2-3 years ago in the print-only CSS to make the contrast better |
| 21:07 | <devsnek> | i see |
| 21:07 | <ljharb> | give me CSS diffs and i'm happy to change them |
| 21:07 | <devsnek> | nah its fine |
| 21:07 | <ljharb> | (the web colors looked bad on print, so i override them for print) |
| 21:07 | <devsnek> | was just curious |
| 21:07 | <devsnek> | the font thing is annoying though, can you use acrobat to save the fonts in the pdf |
| 21:08 | <ljharb> | not sure |
| 21:08 | <devsnek> | i've done that with illustrator before |
| 21:08 | <devsnek> | i've never used acrobat though |
| 21:08 | <leobalter> | ljharb 262 is 10x bigger than 402 |
| 21:09 | <devsnek> | but not 10x better |
| 21:09 | <ljharb> | but 262 is 1.5 times smaller than 402 |
| 21:09 | <leobalter> | but 402 weights much more in data for sure :) |
| 21:09 | <bterlson> | github is back! |
| 21:10 | <gibson042> | the size of 402 is hidden in phrases like "implementation- and locale-dependent" |
| 21:23 | <mpcsh> | shu: can you put the link to these slides in the agenda and/or in the notes |
| 21:30 | <devsnek> | a few proposal repos need to be archived |
| 21:31 | <devsnek> | optional chaining, import.meta, nullish coalescing |
| 21:31 | <devsnek> | maybe more |
| 21:32 | <Bakkot> | I kinda dislike archiving, because it prevents editing for misinformation while leaving it available for google, but i guess we're going with it |
| 21:32 | <devsnek> | i mean it puts a huge yellow banner on it |
| 21:32 | <ljharb> | we can always unarchive, edit, and rearchive |
| 21:32 | <devsnek> | hopefully people can make the connection |
| 21:33 | <ljharb> | i feel it's much better to discourage driveby issues on totally closed proposal repos |
| 21:33 | <Bakkot> | devsnek the yellow banner does accomplish much of anything |
| 21:33 | <ljharb> | the inability to file issues and PRs is the important part |
| 21:34 | <ljharb> | devsnek: for import.meta, you should be an admin on that repo, so you can take care of it |
| 21:34 | <Bakkot> | in particular, if I state a factual point in an issue, and the repo is then archived, and then I discover the thing I stated was in fact not true, the yellow banner will not inform people of this |
| 21:34 | <devsnek> | ljharb: i'm not |
| 21:34 | <ljharb> | Bakkot: we can unarchive, add your comment, and rearchive for that case |
| 21:34 | <ljharb> | devsnek: ping a chair, as champion you should be |
| 21:35 | <Bakkot> | ljharb yeah with a bunch of overhead, and in the case where it is a member of the committee for whom this arises |
| 21:35 | <ljharb> | true |
| 21:36 | <ljharb> | however people much-later correcting incorrect statements on a merged proposal repo has not, in practice, happened; whereas the async/await repo continues to get people asking how promises work |
| 21:37 | <devsnek> | (it's just domenic manually handling everyone's http requests) |
| 21:38 | <Bakkot> | ljharb yeah I do see the benefit |
| 21:39 | <Bakkot> | I wonder if the github issue template thing lets you just not have any templates |
| 21:39 | <ljharb> | there's no way to disable issue filing, sadly |
| 21:40 | <ljharb> | you can turn off PRs, but then old PRs aren't viewable, which is bad |
| 21:40 | <ljharb> | archival afaik is the only way to prevent new content from being created while leaving all content publicly viewable |
| 21:44 | <Bakkot> | ljharb you can't turn off issues entirely, but: |
| 21:44 | <Bakkot> | see what happens when you got to open an issue on https://github.com/bakkot/misc/ |
| 21:46 | <Bakkot> | sorry, you can turn off issues but that hides the existing ones |
| 21:46 | <shu> | Bakkot: oh damn i got bamboozled into the discourse |
| 21:46 | <Bakkot> | I am much less worried about people creating spurious PRs than spurious issues |
| 21:48 | <ljharb> | in my experience when PRs are on and issues are off, people create a random file to simulate making an issue |
| 21:49 | <Bakkot> | I suspect that would happen far less frequently |
| 21:49 | <ljharb> | stopping new issues is nice, but commenting on old ones is a bigger problem |
| 21:49 | <ljharb> | iow i think the problem i want solved directly conflicts with the ability you want retained :-/ |
| 21:50 | <Bakkot> | hmm |
| 21:50 | <Bakkot> | alas |
| 22:09 | <ghermeto> | it is hard to know who is in the zoom call when they don't have full name and companies. Is that just me? |
| 22:09 | <ljharb> | ghermeto: add a point of order to the queue about it? |
| 22:09 | <msaboff> | We have asked many times for Full names and organization. |
| 22:10 | <keith_miller> | Mine keeps getting cleared because I quit the call and rejoin... |
| 22:10 | <keith_miller> | I wish I could set it for the call # |
| 22:10 | <michaelficarra> | yeah it's hard when Zoom resets it every time you leave... |
| 22:11 | <ghermeto> | just added a point of order... is that too late? |
| 22:11 | <ljharb> | no |
| 22:11 | <ljharb> | thanks |
| 22:15 | <brad4d> | OT: I'm fighting to make my info show up right in IRC - anyone willing to IM me directly to hold my hand on this? |
| 22:15 | <ljharb> | brad4d: sure |
| 22:16 | <apaprocki> | The BIS re-opened the public comment period for extension of the temporary general license |
| 22:16 | <michaelficarra> | I want to thank the note takers for this meeting! |
| 22:16 | <apaprocki> | Are any Ecma members submitting comments? |
| 22:16 | <ljharb> | apaprocki: BIS? what license? |
| 22:17 | <michaelficarra> | the note takers provide an incredibly valuable service, and the quality has really been amazing lately |
| 22:17 | <apaprocki> | ljharb: https://bis.doc.gov/index.php/documents/regulations-docs/federal-register-notices/federal-register-2020/2542-85-fr-17300 |
| 22:18 | <apaprocki> | the 3rd text column on the 1st page |
| 22:19 | <Bakkot> | oh god clicking this link is going to increment a counter |
| 22:19 | <Bakkot> | a very small counter |
| 22:19 | <Bakkot> | "223 downloads" |
| 22:19 | <devsnek> | lol |
| 22:20 | <apaprocki> | you know somewhere in some damp basement are people in suits presenting pdf download statistics |
| 22:20 | <ljharb> | apaprocki: meaning, this is the way to submit comments to ask for more guidance? |
| 22:21 | <apaprocki> | it would seem they'd be open to comments requesting clarification to make the situation easier... whether or not they do it is a different story |
| 22:22 | <ljharb> | right |
| 22:23 | <ljharb> | thanks |
