00:00:36  <dilijev>for slow and tiny embedded systems, FP multiplication is relatively expensive even if you only do it once during setup, although in practice i think people will inline 2*PI and pay the cost if the compiler doesn't deal with it, and for floats, that loss of a bit is important
00:01:00  <dilijev>(compilers for embedded systems are often bad)
00:02:27  <dilijev>well adding TAU is one thing, maybe it's political, but I think there's a good case to having a constant equivalent to PI*2
00:02:49  <dilijev> even if its name is PI2
00:13:43  * Fishrock123quit (Remote host closed the connection)
00:17:14  <Bakkot>have a degree in math and was not taught about τ, but I agree it's probably worth adding.
00:17:24  <Bakkot>PI2 might be easier to get through committee? I dunno.
00:19:02  <dilijev>ljharb: how many slices of pizza are there and are they uniform?
00:19:56  <dilijev>how many pi radians are there in a slice of a pizza pi, er i mean, pie?
00:26:19  <ljharb>dilijev: if there are N equal slices of pizza, a slice is always τ/N radians :-p for π, it's 2π/N, and then you have to reduce 2/N in your head
00:26:40  <dilijev>yep yep, i was just being facetious
00:26:42  <ljharb>:-p
00:26:50  <ljharb>the benefit imo is the concept of "tau", not just "a constant for 2pi"
00:27:16  <dilijev>mathematically, yes
00:27:46  <dilijev>but practically, the issue is the inconsistency between (PI, nothing) and (SQRT2, SQRT1_2) and the loss of a bit in calcs
00:27:54  <dilijev>imho
00:28:36  <dilijev>but while we're at it, might as well increase awareness of TAU and people can trivially polyfill PI2 if they wish
00:33:00  <ljharb>^
00:48:53  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
01:06:29  * Fishrock123joined
01:06:32  * Fishrock123quit (Remote host closed the connection)
02:53:16  * not-an-aardvarkjoined
03:30:18  * jmdyckquit (Quit: Leaving.)
06:19:44  * gskachkov_joined
06:23:45  * brabjoined
06:45:57  * bttfquit (Ping timeout: 260 seconds)
06:53:01  * gskachkov_quit (Quit: gskachkov_)
06:55:34  * gskachkov_joined
07:00:53  * gskachkov_quit (Quit: gskachkov_)
07:02:18  * gskachkov_joined
07:04:33  * gskachkov_quit (Client Quit)
07:05:24  * gskachkov_joined
08:12:29  * gskachkov_quit (Quit: gskachkov_)
08:28:49  * gskachkov_joined
08:48:53  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:15:38  * gskachkov_quit (Quit: gskachkov_)
09:16:09  * gskachkov_joined
09:34:45  * gskachkov_quit (Quit: gskachkov_)
09:36:01  <littledan>dilijev: The proposal for Unicode properties in regular expressions adds the ability to check for ID_Start and ID_Continue
09:45:14  * gskachkov_joined
09:46:22  * gskachkov_quit (Client Quit)
10:21:17  * gskachkov_joined
10:22:08  * gskachkov_quit (Client Quit)
10:22:47  * gskachkov_joined
10:25:11  * mylesborinsquit (Quit: farewell for now)
10:25:41  * mylesborinsjoined
10:54:39  * gskachkov_quit (Quit: gskachkov_)
11:02:22  * gskachkov_joined
11:08:21  * gskachkov_quit (Quit: gskachkov_)
11:11:57  * gskachkov_joined
11:30:01  * gskachkov_quit (Quit: gskachkov_)
11:31:16  * gskachkov_joined
11:33:48  <littledan>dilijev: What we don't have proposed yet is an API to get the ranges which are included (e.g., as ICU exposes). What's the use case you're thinking of?
12:09:09  * gskachkov_quit (Quit: gskachkov_)
12:12:50  * jmdyckjoined
12:36:13  * gskachkov_joined
12:48:47  * brabquit (Quit: ERC (IRC client for Emacs 25.2.1))
12:55:54  * gskachkov_quit (Quit: gskachkov_)
12:58:43  * gskachkov_joined
13:00:47  * gskachkov_quit (Client Quit)
13:02:33  * gskachkov_joined
13:13:05  * gskachkov_quit (Quit: gskachkov_)
13:13:58  * gskachkov_joined
13:17:38  * gskachkov_quit (Client Quit)
13:19:22  * gskachkov_joined
13:29:35  * gskachkov_quit (Quit: gskachkov_)
13:37:49  * gskachkov_joined
13:44:01  * gskachkov_quit (Quit: gskachkov_)
13:53:04  * gskachkov_joined
13:58:43  * gskachkov_quit (Quit: gskachkov_)
14:06:50  * gskachkov_joined
14:09:30  * gskachkov_quit (Client Quit)
15:25:09  <leobalter>dilijev, mathiasbynens: I'm really excited with the tests for unicode properties. If it helps, we can have a audio (or video) call to discuss some more strategies for test262 formatting
15:25:30  <leobalter>If I can use my open source to contribute, that's even a +1 to help even more
15:39:28  * gskachkov_joined
17:02:34  * not-an-aardvarkjoined
17:05:10  * gskachkov_quit (Quit: gskachkov_)
17:19:31  <jeffmo>#lazyweb: If I have constants.js with `export const C = 42`, and then moreconstants.js with `export const C = 42; export * from "constants.js"`, is that a runtime error? Or does the second export win?
17:19:50  <jeffmo>(While I dig through the spec, wondering if anyone just remembers off-hand)
17:20:19  * gskachkov_joined
17:23:17  <jeffmo>wycats: ^ I feel like we discussed this 3-4 meetings ago, do you remember the answer off-hand?
17:25:50  <jeffmo>Ok -- seems to throw a SyntaxError in ModuleDeclarationInstantiation: https://tc39.github.io/ecma262/#sec-moduledeclarationinstantiation
17:27:00  <mathiasbynens>leobalter: what should the [features] flag be for these new tests?
17:27:03  <mathiasbynens>features: [UnicodePropertyEscapes]?
17:27:15  <mathiasbynens>the docs don’t say where those IDs are coming from
17:42:58  * gskachkov_quit (Quit: gskachkov_)
17:47:35  * gskachkov_joined
17:52:01  <wycats>jeffmo: people claimed it only errors when you import
17:52:10  <wycats>I think the current behavior is probably an accident
17:52:21  <wycats>and we should try to make it error to re-export multiple things with the same name
17:58:04  <jeffmo>wycats: I guess it's really a matter of when we *can* error -- which would be at link time
17:58:10  <wycats>right
17:58:12  <jeffmo>*a matter of how early we *can*
17:58:38  <wycats>I think it should be a link error *at the point when you compute the exports for a module*
17:58:49  <jeffmo>https://tc39.github.io/ecma262/#sec-moduledeclarationinstantiation
17:58:55  <jeffmo>it seems to be?
17:59:20  <jeffmo>12.d.2
18:03:48  * gskachkov_quit (Quit: gskachkov_)
18:06:52  <aklein>jeffmo: star exports are special
18:06:58  <leobalter>mathiasbynens: we don't have any specific documentation for the features flags so far
18:07:24  <leobalter>as long as we start with one flag, I'll also write some docs specifying some used flags for consistency
18:07:40  <jeffmo>aklein: special in that they are necessarily deferred, but not in that they can sneak through a dupe/name override right?
18:07:42  <leobalter>so far, it's only conventions: async-iteration, object-spread, etc
18:08:32  <aklein>jeffmo: well, to start with, the first part: they don't do anything in the exporting module at ModuleDeclarationInstantiation time
18:08:37  <mathiasbynens>leobalter: so is lowercase slug-case preferred?
18:09:07  <mathiasbynens>I’ll go with `features: [regexp-unicode-property-escapes]` then
18:09:16  <aklein>jeffmo: in your example, there's no error
18:09:25  <aklein>the second export C wins
18:09:33  <aklein>this is all in https://tc39.github.io/ecma262/#sec-resolveexport
18:11:55  <jeffmo>faceplam
18:12:11  <jeffmo>(which is like a facepalm, except sadder)
18:13:08  <aklein>jeffmo: context?
18:13:25  <jeffmo>aklein: syntactic exports error, but * exports don't
18:13:40  <jeffmo>(IIU what you're saying correctly?)
18:13:54  <jeffmo>I haven't read your linked spec text yet
18:14:04  <aklein>right, you can't do
18:14:10  <aklein>export const C = 42;
18:14:16  <aklein>export { C } from "constants.js";
18:14:29  <aklein>but you can with export * from "constants.js";
18:14:43  <aklein>jeffmo: but why the facepalm?
18:14:47  <jeffmo>and we *want* this behavior? that's not an accident?
18:15:30  <samth>jeffmo: it means that other people adding new exports doesn't break your code
18:15:56  <jeffmo>samth: unless your module has the `export *` after the `export {C} from ...`?
18:17:15  <jeffmo>Checking my premise: Is there a difference between `export const C = 42; export * from "constants.js";` and `export * from "constants.js"; export const C = 42;`?
18:17:25  <samth>jeffmo: the algorithm in the spec doesn't depend on order
18:17:46  * Fishrock123joined
18:18:06  <jeffmo>ok, so local exports always win over "*"-imported exports?
18:18:23  <aklein>jeffmo: yup
18:18:50  * gskachkov_joined
18:18:53  <samth>jeffmo: it's exports with a name that win over exports without them
18:29:56  <jeffmo>ok got it
18:30:00  <jeffmo>thanks for clarifying
18:30:40  <jeffmo>this was way quicker than trying to page in all the module spec text/context
18:40:13  <dilijev>leobalter, mathiasbynens: I was thinking along the lines of the test262 tests we had discussed on the test262 repo, wanting to do some in-Javascript logic rather than generating giant tests based on a priori knowledge specific to an engine or Unicode version number. Also possible applications to fuzzing. I think a call to discuss might be a good idea.
18:57:26  <leobalter>dilijev: +1. mathiasbynens has already made some generation tool using node but we still need to figure out how to upstream it to test262, so discussion is valid to find the best approach.
19:04:14  <jeffmo>aklein: samth: Ok, am I understanding the spec correctly that `export * from "ExportsC.js"; export * from "AlsoExportsC.js"`results in the `C` from "ExportsC.js" winning over AlsoExportsC because it comes first?
19:05:05  <jeffmo>oh sorry... I guess AlsoExportsC would win *because* it is last
19:05:22  <jeffmo>jk, first one wins by my reading
19:06:44  * gskachkov_quit (Quit: gskachkov_)
19:07:35  * gskachkov_joined
19:09:51  <jeffmo>*syntactically-first even
19:37:31  * gskachkov_quit (Quit: gskachkov_)
19:38:45  <mathiasbynens>leobalter, dilijev: WIP test generator is here https://github.com/mathiasbynens/unicode-property-escapes-tests these settings can be tweaked to make tests more precise/larger/slower: https://github.com/mathiasbynens/unicode-property-escapes-tests/blob/c784de53f008f2062a691f65d2de24b2f2900791/build.js#L1-L6
19:39:40  <mathiasbynens>using a priori knowledge for a given Unicode version number is the only way to ensure full interoperability, so imho it’s the best option in this case
19:41:07  <mathiasbynens>(although to *fully* ensure interoperability, the settings would have to be tweaked, but then each `*.case` file would be ~13 MB or more, and generating all tests would take ages)
19:42:06  * gskachkov_joined
20:00:55  <aklein>jeffmo: I believe that fails
20:01:05  <aklein>as "ambiguous"
20:06:27  <jeffmo>aklein: oh right, because of 8.d.ii.2
20:08:51  <aklein>you can manually disambiguate by adding `export { C } from "ExportsC.js"` in addition
20:10:27  <jeffmo>aklein: samth: doesn't this behavior fail the previous justification for having locals override remotes? (i.e. "don't want a change to another module to break yours")
20:10:54  <jeffmo>A works in isolation, B works in isolation, C pulls the two together -- A changes and only breaks C
20:11:23  <aklein>jeffmo: C doesn't break, though, only folks who import from C break
20:11:35  <aklein>not that that gets past your complaint
20:11:39  <aklein>I'll let samth comment on motivation
20:11:47  <aklein>I just happen to be an interpreter of the spec
20:11:47  <jeffmo>my complain is how messy this is to implement in Flow :p
20:11:52  <aklein>heheh
20:24:46  <samth>jeffmo: you could make it even lazier about producing errors, ie only error if you import C from that module that has the two conflicting * exports
20:24:55  <samth>I think that was my preference
20:25:11  <samth>but that also results in seeming spooky action at a distance and could be confusing
20:27:46  <jeffmo>samth: I wish it could be a link-time error
20:28:54  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
20:29:55  <aklein>samth: it does only cause an error if you import C
20:30:08  <aklein>jeffmo: it _is_ a link-time error
20:30:37  <samth>aklein: oh, I misunderstood your statment about "that fails"
20:30:59  <aklein>samth: ah, yes, I clarified further down
20:31:16  <samth>oh, sorry, I see that now
20:32:09  <samth>jeffmo: the justification is to only error when there was some actual use of a name that is ambigous, so as to avoid new exports being a breaking change as much as possible
20:32:37  <samth>obviously in any situation with `export *` eventually it could break something
20:58:15  * gskachkov_quit (Quit: gskachkov_)
21:04:17  * gskachkov_joined
21:23:03  <dilijev>maybe dumb question, but is the only resolution to a name overlap in imported modules (if you want all symbols) to rename one of them? Assuming you don't have control over either module, Is it possible to force a new name at import time?
21:26:02  * Havvyquit (Quit: Computer Restarted or Restarting IRC)
21:27:18  <ljharb>dilijev: you mean you want something like, `import { a as renamed }, * as all from 'path'; path.a = renamed;`? (not sure if that actually works)
21:31:34  * Havvyjoined
21:35:41  <dilijev>yeah I've only looked at modules in typescript personally so i don't know how much of the syntax overlaps with ES modules, but I think `import { a as renamed } from 'path'` is allowed there, as is `import * as all from 'path'`
21:36:43  <dilijev>In the latter, all gets all exports from 'path' as properties which basically sets up a namespace and sidesteps the problem that `import { a as renamed } from 'path'` solves directly
21:36:59  * gskachkov_quit (Quit: gskachkov_)
21:37:01  <dilijev>so i guess i'm asking is ES modules supports that syntax
21:40:31  <dilijev>s/is/if/
22:14:13  * Fishrock123quit (Remote host closed the connection)
22:14:59  * Fishrock123joined
22:15:49  * Fishrock123quit (Client Quit)
22:21:42  <aklein>dilijev: yes, that syntax is ES syntax
22:23:30  <aklein>dilijev: https://tc39.github.io/ecma262/#sec-imports and https://tc39.github.io/ecma262/#sec-exports for the full grammar
23:20:05  <aklein>random question: anyone remember what happened to comprehensions?
23:20:19  <aklein>I think dherman presented something that killed it at one of the first meetings I attended
23:21:40  <cloudshu>aklein: yes
23:22:20  <cloudshu>aklein: comprehensions got killed from what i remember
23:22:55  <aklein>cloudshu: I know they got killed, what I'm wondering is if there's somewhere on the web explaining why
23:24:05  <cloudshu>aklein: ah good question, let me dig through logs and see
23:24:12  <aklein>cloudshu: thanks
23:24:30  <aklein>I found some broken links to dherman's blog, and to the ecmascript harmony wiki (RIP)
23:24:33  <cloudshu>wingo would remember...
23:24:40  * cloudshupours one out for harmony wiki
23:24:41  <aklein>yeah wingo's blog scores highly
23:24:56  <aklein>except the thing I found says "hey it's implemented!"
23:24:56  <tcare>ah the harmony wiki.. good times..
23:25:00  <dherman>wingo might never forgive me
23:25:26  <dherman>there should be meeting minutes from that meeting
23:25:48  <dherman>I can picture the room but can't remember where/when it was
23:27:15  * cloudshustill digging
23:27:24  <aklein>if only github search worked
23:27:59  <dherman>last commit on my sudoku repo was 2/7/2015
23:28:04  <dherman>so I bet it was the meeting right around that time
23:28:06  <dherman>https://github.com/dherman/sudoku/
23:29:18  <cloudshu>MDN says removed in revision 27
23:29:20  <cloudshu>whenever that was
23:29:43  <aklein>notes from sep 2014 say they were removed in that spec draft
23:30:42  <aklein>https://github.com/tc39/tc39-notes/blob/master/es6/2014-06/comprehensions.pdf
23:30:49  <dherman>https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-06/comprehensions.pdf
23:30:51  <dherman>lol
23:31:07  <aklein>ha!
23:31:18  <dherman>that's not the death knell though
23:31:21  <dherman>just the death rattle
23:31:38  <dherman>https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md
23:31:48  <dherman>https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#47-revisit-comprehension-decision-from-last-meeting
23:32:14  <dherman>> MM: after seeing this code I will never use comprehensions
23:32:21  <dherman>I had the same reaction :)
23:32:47  <dherman>lol: > BE: who will own explaining to Andy Wingo and es-discuss?
23:33:08  <cloudshu>lol
23:33:09  <cloudshu>i just read that
23:36:38  <rbuckton>Adding onto bterlson's comment yesterday about cancellation, first draft of spec text is now up at https://tc39.github.io/proposal-cancellation
23:48:36  * not-an-aardvarkjoined