03:59:34  * jmdyckquit (Quit: Leaving.)
08:26:27  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:10  * mylesborinsquit (Quit: farewell for now)
10:25:40  * mylesborinsjoined
11:29:59  * jmdyckjoined
13:41:45  * caridyquit (Remote host closed the connection)
13:42:16  * caridyjoined
15:35:57  <caitp>ljharb: why did you close that bug? it might be worth considering
15:39:27  * Fishrock123joined
16:23:44  <ljharb>caitp: because proposals don't go on the spec repo
16:24:01  <ljharb>i think it's totally worth considering, but it'd need to go through the process
16:24:05  <caitp>eh, I think it's not a bad place to discuss it
16:24:23  <ljharb>we've actively closed those discussions before, and pointed people to esdiscuss
16:24:23  <caitp>where else are informed ideas going to come from, esdiscuss? paha
16:24:49  <ljharb>anyways closing doesn't mean people can't keep discussing, i didn't lock it or anything
16:27:49  <caitp>true, but it discourages it
16:31:26  * not-an-aardvarkjoined
17:12:45  <bterlson>caitp ljharb if we're talking about that async functions issue, I think it's a bug
17:13:18  <bterlson>my recollection is that originally async functions threw from the params like generators
17:13:24  <bterlson>but we changed it to reject the promise
17:13:34  <bterlson>at that time we should have probably made await legal in the parameter list
18:45:00  * Fishrock123quit (Remote host closed the connection)
19:15:15  <caitp>I agree that it should be legal, but I'm not super stoked abbout making it affect arguments object allocation, which it seems like it would
19:17:12  <caitp>like arguments object unused (except for where needed for parameter initialization), but still allocated even in optimized code
19:21:15  * gskachkovjoined
19:23:25  * Fishrock123joined
19:27:15  <bterlson>caitp: can you explain the impact on arguments allocation more?
19:27:15  * gskachkovquit (Read error: Connection reset by peer)
19:27:30  <bterlson>I don't see how it is made worse by allowing await in params
19:27:32  <ljharb>bterlson: ah, if it's a bug then it should be reopened
19:29:17  <caitp>bterlson: if the generator can be suspended during parameter initialization, you'd need parameters to be on heap rather than on stack
19:29:32  <caitp>otherwise, when the function is resumed, the stack frame is different
19:29:58  <caitp>so it forces us to allocate stuff that we can otherwise get away with not allocating
19:30:05  <bterlson>interesting
19:30:08  <caitp>it's kind of a minor point, but yeah
19:31:20  * gskachkovjoined
19:50:54  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
20:23:40  * Fishrock123quit (Remote host closed the connection)
20:24:22  * Fishrock123joined
20:24:28  * Fishrock123quit (Remote host closed the connection)
20:24:32  * gskachkovquit (Quit: gskachkov)
20:25:09  * Fishrock123joined
20:25:16  * Fishrock123quit (Remote host closed the connection)
20:32:23  * gskachkovjoined
21:07:00  * Fishrock123joined
21:10:51  * gskachkovquit (Quit: gskachkov)
21:21:28  <dherman>bterlson: I want to hack up a quick spec for a small stage-2 proposal. how do I make a proposal repo, generate the spec deltas, etc?
21:21:48  <bterlson>dherman: I can make you a repo, what do you want it to be called?
21:22:06  <bterlson>the rest: https://bterlson.github.io/ecmarkup
21:22:16  <bterlson>although I'd just copy a proposal you like
21:22:25  <dherman>ah interesting idea
21:22:28  <dherman>lemme see
21:22:30  <ljharb>dherman: sorry i haven't had a chance to get the proposal template together; i'm back at work this week so i can get that done sooner :-)
21:22:50  <dherman>ljharb: np, and that'd still be great
21:22:55  <dherman>create-tc39-app
21:23:16  <ljharb>:-p
21:23:26  <ljharb>will ping here whenever i'm done
21:23:42  <bterlson>ecmarkup --init is possible
21:23:52  <bterlson>rather than a separate app I mean
21:24:00  <dherman>ugh this is overwhelming
21:24:31  <dherman>there are _travis config files_???
21:24:35  <ljharb>yup
21:24:39  <dherman>what is even going on here
21:24:47  <dherman>oic
21:24:51  <dherman>it's for deploying the built html
21:24:52  <ljharb>how else would you tell it what constitutes "run tests" or "which platform to test on"
21:25:03  <ljharb>ah right, that, yes
21:25:34  <bterlson>dherman: just ignore that, your goal is to produce a spec.html that when built with ecmarkup (with no options) gives you a nice spec
21:25:54  <bterlson>if you don't expect major updates you can just manually push to the gh-pages branch when you make updates
21:26:01  <bterlson>otherwise the travis stuff can help you set up auto-building
21:26:18  <dherman>ok so every proposal repo I've looked at so far makes no sense
21:26:30  <bterlson>example
21:26:43  <dherman>so you write the spec.html by hand?
21:26:46  <bterlson>yes
21:26:51  <dherman>ok
21:27:01  <bterlson>I mean, you could probably use dreamweaver if you wanted?
21:27:07  <bterlson>I wouldn't recommend it
21:27:21  <dherman>:P
21:32:54  <bterlson>modules pragma!
21:33:15  <Domenic>I wonder how many times this needs to get shot down in committee before it's going to stop coming up... https://github.com/tc39/proposal-modules-pragma
21:35:18  <dherman>Domenic: so, I'm working on that right now
21:35:23  <dherman>and it has not been "shot down in committee"
21:35:33  <Domenic>Really......
21:35:42  <dherman>it has been discussed all of one time
21:36:02  <dherman>some people who'd be useful in the discussion weren't there
21:36:22  <Domenic>OK, well, as long as it's timeboxed...
21:37:03  <dherman>I think I have as much right as anyone to bring things up at tc39
21:37:23  <Domenic>Woah, nobody said you didn't; not sure what's going on here.
21:37:29  <dherman>"as long as it's timeboxed"
21:37:45  <dherman>I think it's as legit a use of committee time as anything
21:58:31  * not-an-aardvarkjoined
22:07:31  * Draggorjoined
22:38:17  <bterlson>littledan: did we actually get consensus for mandating 1ulp for Math n stuff?
22:50:01  <littledan>No, actually I wanted to update it to crib the Java accuracy
22:50:17  <littledan>We seemed to get consensus to set the accuracy reasonably
22:50:50  <littledan>I think everyone's on board to prohibit v8's old behavior, but this patch needs a tweak
22:56:01  <bterlson>littledan: great that was my recollection to
22:56:10  <bterlson>consensus we want something, no consensus on what that was exactly
22:56:19  <bterlson>typical
23:02:44  <littledan>Btw if you want to present await in async function parameters, feel free to push back one of my topics; I think I am presenting too much
23:03:00  <littledan>If it's a matter of being a time crunch
23:05:19  <littledan>Bterlson, can't wait to hear what is feature-complete ES for you
23:06:26  <bterlson>littledan: I am going to change that title lol
23:06:33  <bterlson>setting my bar way too high
23:06:47  <bterlson>for what is essentially me saying "we should work on these things sometime..."
23:07:01  <littledan>Aww
23:11:43  <bterlson>short story: pattern matching, pipeline, bind operator (for partial application not pipelining), method extraction syntax, value types framework, avoid low road
23:12:02  <bterlson>also known as: functional ftw I guess
23:12:43  <bterlson>(and I actually think this gets close to feature complete as by then we'll be out of syntax ;))
23:15:40  <Bakkot>psh, we can add to the standard library forever
23:16:36  <bterlson>I dunno
23:18:00  <Bakkot>not saying we *should*; just that the lack of syntactic space isn't that much of a constraint
23:18:15  <bterlson>seemed to be a lot of pushback on adding new built-ins when Maggie presented on dates
23:33:24  * Fishrock123quit (Remote host closed the connection)
23:34:05  * Fishrock123joined
23:34:12  * Fishrock123quit (Remote host closed the connection)
23:58:35  * Fishrock123joined