00:07:39  * jwaldenwould prefer not to talk about the first rule of ECMA
00:46:14  * Jayfluxquit (Quit: Leaving)
00:52:31  * amaljoined
00:52:54  * amalchanged nick to Guest43507
00:54:24  * Guest43507quit (Client Quit)
01:05:07  * bradleymeckjoined
01:05:11  * bradleymeckquit (Client Quit)
01:09:35  * jwaldenquit (Quit: back in a bit, exeunt to Caltrain)
01:13:46  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:32:37  * keith_millerjoined
01:34:39  * jwaldenjoined
01:40:58  * AtumTquit (Remote host closed the connection)
01:46:12  * nomadtechiejoined
01:57:43  <nomadtechie>Hi all! My name is Amal Hussein -- I'm an engineer @ Bocoup. I'm working on tests for Atomics and I've got some questions for Lars Hansen. I don't see an obvious handle for Lars here -- is Lars in this channel?
02:00:11  <cloudshu>nomadtechie: hi, lars isn't really active here
02:00:27  <cloudshu>nomadtechie: you can try the mozilla IRC. you can also ask the question and see if anyone knows
02:03:05  <nomadtechie>ok thanks Shu! My questions are mainly around agents and testing that functionality in the context of atomics
02:03:31  <cloudshu>i can try
02:03:39  <nomadtechie>Its best to probably chat real time via hangouts, or slack audio
02:04:07  * gibson042joined
02:04:42  <cloudshu>oh that i cannot do right now
02:05:03  <nomadtechie>are you Shu-yu Goa? If yes, you worked on Atomics.waitAsync with Lars, right?
02:05:18  <cloudshu>Guo, yes
02:05:21  <nomadtechie>oh I didn't mean right now -- I'd like to setup time to discuss it
02:05:23  <cloudshu>i worked on atomics and SAB with lars
02:05:29  <nomadtechie>very cool! :)
02:05:32  <cloudshu>sure, send me an email
02:06:22  <nomadtechie>thanks - will exchange info via dm.
02:16:18  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:18:22  * jwaldenquit (Ping timeout: 256 seconds)
02:37:24  * keith_millerjoined
03:19:36  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:26:01  * howdoijoined
03:47:59  * keith_millerjoined
04:47:52  <devsnek>has making the structured clone algo exposed with an api ever been discussed?
04:48:21  <devsnek>or something similar
04:48:41  <devsnek>a binary format with the speed that structured clone has is very appealing
04:49:04  <devsnek>oh heck wrong channel
05:09:37  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:14:14  * keith_millerjoined
05:26:22  * jmdyckquit (Remote host closed the connection)
05:40:02  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:46:56  * keith_millerjoined
05:47:16  * caridyquit (Remote host closed the connection)
05:57:13  <annevk>devsnek: see whatwg/html PRs; there is a proposal
05:57:40  <devsnek>i guess thats why i didn't find anything heh
05:57:45  <devsnek>was looking around w3c
06:26:57  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:30:57  * keith_millerjoined
07:57:39  * cloudshuquit (Quit: Connection closed for inactivity)
07:57:40  * gibson042quit (Quit: Leaving.)
08:12:21  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:15:59  * keith_millerjoined
09:42:34  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:00:54  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
11:17:00  * AtumTjoined
11:25:11  * mylesborinsquit (Quit: farewell for now)
11:25:47  * mylesborinsjoined
11:50:27  * gskachkovjoined
13:51:27  * keith_millerjoined
14:08:28  <jschoi>If a ECMA262 proposal makes small additions to a section that is predominantly prose, should the proposal‘s specification o, the subsections that it does not modified?
14:08:56  <jschoi>Shouldn’t the proposal’s specification omit the subsections that it does not modify.
14:09:17  <jschoi>Should the proposals specification. Ugh, sorry for the phone-keyboard typos.
14:10:01  <jschoi>If a ECMA262 proposal makes small additions to a section that is predominantly prose, should the proposal‘s ecmarkup specification omit the subsections that it does not modify?
14:37:23  * jmdyckjoined
14:45:13  <jmdyck>jschoi: yes, a proposal typically omits every clause that it doesn't modify. Mostly it just says how it will modify the spec, and for that you only need to include enough unchanged stuff to establish context.
14:45:22  <jmdyck>i think
14:45:48  <jschoi>Thanks.
14:47:31  <jmdyck>At some point you need to integrate the changes into a fork of the spec, but that's usually later.
14:48:41  <jschoi>Yes, I have been wondering how important it was to make unique clause and table IDs.
15:01:15  * gibson042joined
15:28:32  * gibson042quit (Ping timeout: 276 seconds)
15:31:48  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:35:35  * keith_millerjoined
15:36:34  * Fishrock123joined
15:42:11  * gibson042joined
15:51:38  * gskachkovquit (Quit: gskachkov)
15:51:49  * caridyjoined
15:55:41  * gskachkovjoined
16:38:54  * cloudshujoined
17:17:09  * gskachkovquit (Ping timeout: 264 seconds)
18:25:39  * Fishrock123quit (Remote host closed the connection)
18:31:43  <bterlson>jschoi: just to confirm, your proposal spec should be understandable mostly by itself so it should include whatever context it needs, but there is no prescribed amount of context :)
18:32:06  * Fishrock123joined
18:32:33  <jschoi>bterlson: Thanks, will do.
18:54:45  * srl295joined
19:17:00  <aklein>cloudshu: yt? some I have an Atomics question for ya
19:20:13  * howdoiquit (Quit: Connection closed for inactivity)
20:05:57  <cloudshu>aklein: i am now
20:08:36  <aklein>cloudshu: I think we sort of figured out the answer...was trying to understand the intention of the committee WRT Atomics and BigInt64Array
20:08:56  <cloudshu>aklein: ah, cool
20:09:35  <aklein>cloudshu: was your takeaway from the discussion in September that for platforms without 64-bit atomic instructions, implementations are expected to do locking?
20:09:44  <aklein>and Atomics.isLockFree(8) should return false?
20:10:54  <cloudshu>i honestly don't remember, let me read over notes to jog memory
20:14:22  <cloudshu>aklein: i don't remember this being explicitly discussed, but that's the only sensible conclusion
20:14:43  <cloudshu>aklein: in the notes, there was some confusion about reads being torn and atomicity
20:15:08  <aklein>cloudshu: well clearly another possible conclusion would be "no 64-bit atomic ops"
20:15:12  <aklein>but I don't see anyone arguing for that
20:15:30  <cloudshu>aklein: to reiterate, 64bit *atomic* accesses must be atomic, and isLockFree(8) won't be able to be guaranteed for all chips like for 4-byte, so it must be variable like 1 and 2
20:15:37  * gskachkovjoined
20:15:51  <cloudshu>aklein: right, i think it'd be bad to decide on 64bit atomics, but only some places
20:15:58  <cloudshu>(and hope that's very uncontroversial)
20:16:11  <aklein>cloudshu: that does seem to be the agreement between Lars and littledan in https://github.com/tc39/proposal-bigint/issues/78
20:16:41  <cloudshu>yeah, that makes sense to me
20:16:56  <aklein>ok, thanks. the BigInt proposal needs some changes then
20:17:14  <aklein>but it's good to have confirmation that we're barking up the right tree
20:17:18  <cloudshu>the confusion in the September discussion was around whether we should legislate well-behavedness of non-atomic concurrent reads and writes of int64
20:17:23  <cloudshu>and the answer to that was no
20:17:48  <cloudshu>s/well-behavedness/non-torn-ness
20:19:23  <aklein>cloudshu: yeah. the main outstanding thing I see is that Waldemar wished for something like isLockFree() but for non-atomic reads/writes
20:19:46  <aklein>that currently seems unaddressed
20:20:10  <cloudshu>we can bring it up again, but my feeling is that the utility of that is limited
20:23:01  <aklein>I'm ok not bringing it up, just saying it might come up again :)
20:23:49  <cloudshu>Reflect.cpuid
20:54:35  <jschoi>According to https://tc39.github.io/ecma262/#sec-grammar-notation, Production[Parameter] defines two productions: Production and Production_Parameter. Syntax-directed operations (https://tc39.github.io/ecma262/#sec-algorithm-conventions-syntax-directed-operations) are associated to productions; their association notation does not use parameters. Is there a way to have a syntax-directed operation apply only to
20:54:35  <jschoi>Production[~Parameter] and not Production[+Parameter] (aka Production_Parameter)?
20:56:06  <jschoi>For instance, I want to have a static semantic rule apply to all instances of `FunctionBody : FunctionStatementList` *except* for when `FunctionBody` is ``ConciseBody : `{` FunctionBody `}` ``.
20:56:24  <jschoi>The formatting of the last grammar messed up but you hopefully get the point.
20:58:33  <jschoi>I could parameterize FunctionBody with another parameter, one that is true only for `ConciseBody : { FunctionBody }` and false for every other use of FunctionBody—but then there’s no way to make my static semantic rule match only `ConciseBody : { FunctionBody }`, because (as far as I can tell) we cannot use parameters in the association grammar for any syntax-directed operations, including static semantic rules.
20:59:53  <jschoi>My plan right now is to replace all uses of `FunctionBody` with a new `NonArrowFunctionBody : FunctionBody` production, except for `ConciseBody : { FunctionBody }` which is left alone. Then I would have my new static semantic rule apply to `NonArrowFunctionBody : FunctionBody` only.
20:59:59  <jschoi>I’m wondering if there’s a better way than this.
21:00:24  <jschoi>My goal is to use Contains to detect the presence of a symbol in all FunctionBody nodes except for those that are in ConciseBody.
21:01:56  <bterlson>you can have them be static semantics of FunctionBody and use a static semantics rule worded like "If FunctionStatementList was the sole FunctionBody of a ConciseBody" or some such
21:02:19  <bterlson>I would avoid refactoring the grammar if at all possible :)
21:02:22  <bterlson>jschoi: ^
21:02:41  <bterlson>probably s/was/is
21:02:44  <bterlson>but you get the idea
21:02:45  <bterlson>?
21:07:14  <jschoi>bterslon: Yes, thanks. That helps a lot.
21:07:35  <jschoi>I would much rather touch as little of the grammar as possible.
21:10:48  <jschoi>I see. So like https://tc39.github.io/ecma262/#sec-functiondeclarations-in-ifstatement-statement-clauses
21:12:41  <jschoi>> If |FunctionStatementList| is not the sole |FunctionBody| of a |ConciseBody|, it is a Syntax Error if |FunctionStatementList| Contains `#` is *true*.
21:12:57  <jschoi>Hopefully that works.
21:13:01  <bterlson>yeah something like that
21:13:11  <bterlson>unsure if sole is really necessary?
21:13:20  <jschoi>Yeah, I see what you mean.
21:13:53  <bterlson>but this is PLENTY fine for now
21:13:59  <bterlson>it is ok for a proposal to sketch
21:14:01  <bterlson>in the early stages
21:14:12  <jschoi>Good to know. Thank you so much for the guidance.
21:18:03  <littledan>aklein: What's the issue with BigInt that you're seeing?
21:18:11  <littledan>the discussion above reflects my understanding
21:36:42  * jwaldenjoined
21:42:46  * not-an-aardvarkjoined
21:51:04  <aklein>littledan: Jakob will file an issue, there are a variety of bits missing (to our understanding)
21:51:27  <littledan>aklein: OK, thanks
21:55:50  <TabAtkins>What's a good verb to use for the act of turning an abstract value into a concrete JS object?
21:55:58  <TabAtkins>I'm using "normalize" right now and I hate it.
21:56:21  <bterlson>TabAtkins: well you should be using normalise
21:56:21  <TabAtkins>I'd like to use "objectify", but the double entendre is unintended and not desired.
21:56:35  <TabAtkins>This is a W3C spec, we use American English.
21:56:48  <TabAtkins>Y'all just seemed relevant to ask. ^_^
21:57:06  <bterlson>normalize is wrong
21:57:13  <bterlson>realize?
21:58:09  <cloudshu>reify
21:58:13  <cloudshu>that's what i'm used to from papers
21:58:23  <bterlson>reify was where my brain was trying to go!
21:58:24  <bterlson>thank you
21:58:38  <cloudshu>it's the process of turning anything into an outdoor store
21:58:51  <bterlson>Cooperatively owned, no less
21:59:45  * gskachkovquit (Quit: gskachkov)
22:00:22  <ljharb>reifying things is more fun in seattle because there's a climbing wall
22:00:58  <bterlson>I've never seen a reified value that didn't have a climbing wall. Some are puny, but I thought all of them had it?
22:01:36  <ljharb>i didn't think the one in SF or san carlos had one
22:03:59  <TabAtkins>Yeah, was thinking about reify.
22:06:31  <cloudshu>i'd say definitely not normalize, that has a pretty different meaning to me
22:11:49  <littledan>aklein: About BigInt, it'd be great to get your (and anyone else's here) opinion on BigInt support for structured clone https://github.com/whatwg/html/pull/3480
22:12:11  <littledan>especially "should it exist?"
22:12:37  <aklein>littledan: I think it's a pretty clear "yes"
22:12:47  <aklein>I guess Domenic's comment suggests I should just say so there?
22:13:04  <littledan>I think so (though I'm new to W3C process)
22:13:10  <littledan>sorry WHATWG I mean
22:13:27  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:13:32  <littledan>you also might have a subtler opinion like "BigInt wrappers are too pointless to support in structured clone"
22:14:04  <littledan>or "we shouldn't permit this as IndexedDB values"
22:18:44  <littledan>aklein: Thanks
22:26:28  <bterlson>jmdyck: this may interest you https://github.com/tc39/ecma262/pull/1105
22:38:23  * keith_millerjoined
23:27:45  * caridyquit (Remote host closed the connection)
23:28:20  * caridyjoined
23:49:21  * Fishrock123quit (Quit: Leaving...)