01:19:02  * AtumT_quit (Remote host closed the connection)
02:13:07  * jwaldenquit (Ping timeout: 245 seconds)
02:19:19  * jwaldenjoined
02:42:19  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
03:15:50  * howdoiquit (Quit: Connection closed for inactivity)
03:39:02  * howdoijoined
03:43:44  * jmdyckquit (Remote host closed the connection)
04:06:09  * jwaldenquit (Quit: back shortly)
05:35:50  * jwaldenjoined
06:15:44  * caridyquit (Remote host closed the connection)
06:16:54  * caridyjoined
06:19:29  * caridyquit (Remote host closed the connection)
06:21:00  * caridyjoined
06:42:11  * caridyquit (Remote host closed the connection)
06:43:39  * caridyjoined
08:11:15  * araijoined
08:28:26  * araiquit (Remote host closed the connection)
08:34:55  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
09:05:50  * howdoiquit (Quit: Connection closed for inactivity)
09:39:27  * shachafquit (Ping timeout: 240 seconds)
09:41:51  * shachafjoined
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:57:24  * howdoijoined
12:03:45  * jmdyckjoined
12:14:10  * bradleymeckjoined
12:29:13  * vikash-afkquit (Remote host closed the connection)
12:49:03  * araijoined
13:29:24  * AtumTjoined
13:53:39  * vikash-afkjoined
15:41:26  * srl295joined
15:58:02  * caridyquit (Read error: Connection timed out)
15:59:11  * caridyjoined
16:05:57  * caridyquit (Remote host closed the connection)
16:06:46  * caridyjoined
17:28:49  * bradleymeckquit (Quit: bradleymeck)
17:51:13  * bradleymeckjoined
18:04:52  * jackhortonjoined
18:11:02  <jackhorton>Intl question: Steps 13 and 14 of InitializePluralRules are super vague, but id imagine everyone in ICU land is using uplrules_getKeywords. Unfortunately, theres no version of that that takes into account the number formatting options, so right now chakra vnext, spidermonkey, and V8 can report the wrong pluralCategories when the number formatting options are being used. Also, chakra can use some older versions of ICU that
18:11:02  <jackhorton>don't have uloc_getKeywords, so we fall back to just saying [ "other" ] there. In general, what is the point of reporting these categories? How are they expected to be used? Is it an issue if what engines report doesn't exactly line up with what they use?
18:13:51  <jackhorton>For example, `new Intl.PluralRules("en-US", { type: "cardinal", minimumFractionDigits: 3 }).resolvedOptions()` reports ["one", "other"] but as far as I can tell, select(1) will always report "other" because its actually 1.000 and thus "one" is never used
18:30:08  <littledan>jackhorton: That's a great question. When implementing this in V8, I took a look at what SpiderMonkey did and just sort of cargo-culted it. Let me pull it up to remember...
18:30:33  <littledan>I think it was something like, actually format the number, then do PluralRules on it
18:31:07  <littledan>anyway we knew at the time that this was something of a mismatch with ICU. I think there's a bug open on the ICU trac to add this feature (but it's getting ignored like all of the other Intl-related issues)
18:32:12  <littledan>jackhorton: Yeah, what we do in V8 is actually format the number, then parse the number, then pass this into the C++ equivalent of uplrules_getKeywords
18:32:18  <littledan>jackhorton: Would that work for you>?
18:33:21  <littledan>hmm, the V8 code points to http://bugs.icu-project.org/trac/ticket/12763 but I think there's more beyond that that would be nice
18:33:28  <littledan>maybe we should discuss this at the next Intl meeting
18:40:25  <jackhorton>yeah, so selectWithFormat exists (its internal, so Chakra can't use it -- I already brought this up with our ICU people to bring up to ICU TC), but there isn't a getKeywordsWithFormat, so the two will be at odds
18:41:32  <jackhorton>also we cant use any C++ APIs so if C++ has an expanded capability here, that's not super useful. With that being said, the code above in Chrome shows ["one", "other"], even though one is never used
19:00:52  * bradleymeckquit (Quit: bradleymeck)
19:27:52  * jwaldenjoined
19:50:19  * bradleymeckjoined
20:14:27  * pandemquit (Ping timeout: 240 seconds)
20:15:43  * pandemjoined
20:41:45  * rkirslingjoined
21:41:18  <srl295>jackhorton: uplrules_selectWithFormat is 'tech preview'
21:43:02  <jackhorton>sure. However, Windows can't include anything that isn't stable in public windows headers, so its not exposed by the system ICU on Windows and thus we cant (well.... really really shouldn't) use it in Chakra. We self-impose the same things on other platforms by hiding all draft/internal/deprecated APIs at compile time
21:43:27  <srl295>jackhorton: but I don't see a proposal to make it a public API. So it will just stay internal at that point
21:44:16  <srl295>it's kind of a chicken and egg issue then. If you don't use it, it won't get feedback. Could you start with using it anyway (even if internal ) to see if it does what you need? then file a proposal to make it public?
21:45:35  <srl295>littledan: > it's getting ignored like all of the other Intl-related issues…  So we need people to push on your org representatives (Chrome in this case ) and/or contribute patches. Otherwise something will just show up as a nice to have.
21:45:50  <jackhorton>yeah, I only brought it to jeff genovy's attention yesterday, as I didn't realize it would be necessary to implement Intl.PluralRules. And, technically, it isn't, we can just use select() and be wrong when someone asks for different number options. But, if this API could be stabilized or re-thought into a version that can be stabilized, that would probably be best for everyone (the fact that all JS engines depend on an API
21:45:50  <jackhorton>marked "internal: do not use" in the ICU docs seems less than ideal)
21:46:13  <srl295>jackhorton: it's marked " * @internal ICU 59 technology preview, may be removed in the future"
21:47:34  <littledan>Sorry for my wording there, but I still haven't heard back about even the design proposal for RelativeTimeFormat.formatToParts
21:47:38  <srl295>jackhorton: OK, i see what you mean: "Internal do not use"
21:47:53  <srl295>littledan: can you join an 8am Pacific call?
21:48:00  <littledan>Which day?
21:48:06  <srl295>not 8am, sorry
21:48:07  <jackhorton>I think "do not use" is probably auto-added to all internal API docs?
21:48:08  <littledan>In general that time works for me
21:48:16  <srl295>jackhorton: yes, it's in the Doxygen config. I'll file a bug on this..
21:49:07  <srl295>http://bugs.icu-project.org/trac/ticket/13685
21:49:42  <littledan>I wasn't aware that these issues were blocked on code. I thought they were blocked more on a decision from maintainers. Maybe I am misunderstanding
21:50:37  <littledan>Or is the decision-making blocked on Chrome pushing harder?
21:51:01  <littledan>It's just unclear to me what the process is here
21:51:02  <srl295>I don't think anyone is pushing at all, that's the problem
21:51:12  <littledan>How am I supposed to push?
21:51:33  <littledan>We talked with you about the issues, in several Intl meetings. What is the next step?
21:52:26  <littledan>We also filed bugs and sent emails to icu-design
21:52:31  <srl295>roght
21:52:34  <srl295>right
21:53:17  <srl295>for icu-design - would be good to get you on the call to discuss the api proposal
21:53:33  <littledan>Sure, what is the call?
21:53:37  <littledan>Happy to join
21:54:49  <littledan>There are lots of smaller bugs open as well--would those be good topics for the call?
21:55:45  <srl295>yes. I wonder if you can send me a list of agenda items and i can send it around and get feedback so that it is on the agenda ? next ICU call would be https://time.is/compare/0945_11_Apr_2018_in_PT
21:57:19  <littledan>I will be traveling then. When is the one after that?
21:57:29  <srl295>every week
21:57:35  <littledan>Oh perfect
21:58:36  <littledan>Yeah the same time the following week works for me, and that gives plenty of time to compile agenda items in advance
21:58:44  <srl295>Great
21:58:58  <littledan>How do I call in?
21:59:15  <srl295>i'll get you the info- sending a note to icu-tc now
22:00:31  <littledan>Thanks!
22:00:36  <srl295>np
22:01:30  <littledan>I probably won't want to come to all of these, but it will be good to be able to attend as things come up for Ecma 402
22:01:40  <srl295>littledan: http://bugs.icu-project.org/trac/ticket/12763#comment:18 please file a seprate ticket about this if you didn't already
22:02:12  <srl295>icu 62 has a shorter release cycle
22:02:42  <srl295>> ICU 62 feature freeze: 2018-05-09 (no more API changes)
22:02:48  <littledan>The release cycles don't really matter to me personally--if we can get the changes in some time in the next year, I am happy
22:03:03  <littledan>Maybe others will be more eager
22:03:30  <littledan>I can understand if new features will be low priority towards the end of the cycle; if so I am fine calling in later
22:03:39  <srl295>littledan: agenda is at http://site.icu-project.org/projectinfo/meetings
22:03:57  <srl295>earlier is better for features
22:04:49  <srl295>unfortunately i personally am not able to do much feature work. My ICU time this year is around infrastructure transition
22:05:30  <littledan>That is fine; I think if we figure out what sorts of changes might be accepted, we can find development resources somewhere or other
22:05:33  <srl295>but trying to advocate here wherever i can
22:06:15  <srl295>here's a custom query that will find things with the ecma keyword http://bugs.icu-project.org/trac/query?status=!closed&keywords=~ecma
22:06:20  <littledan>Do you discuss features that will land in the following release in these meetings, or is the agenda typically focused on the release under current development?
22:07:02  <srl295>we discuss whatever people bring up. we definitely approve apis for a future release. (so approving 62 apis when 61 is about to ship, say).
22:07:23  <littledan>Great
22:08:07  <littledan>Ok I will review these notes, the open issues, and get back to you late next week with something to put on a future meeting agenda
22:08:58  <srl295>sounds good. a shared (typically) google doc could work also, i can link it into the agenda
22:09:53  <littledan>OK works for me
22:10:11  <littledan>Sorry for my snark, and thanks for opening this invitation
22:10:28  <srl295>oh np. cool. could post it around here, etc.
22:11:24  <littledan>Right, of course, but it will take me some time to prepare everything
22:43:19  * bradleymeckquit (Quit: bradleymeck)
22:59:59  * AtumT_joined
23:00:17  * AtumTquit (Ping timeout: 265 seconds)