00:06:44  * jmdyckquit (Remote host closed the connection)
00:07:21  * jmdyckjoined
00:17:37  * Fishrock123quit (Remote host closed the connection)
00:24:49  * chicoxyzzyjoined
00:25:39  * chicoxyz_joined
00:25:43  * chicoxyzzyquit (Client Quit)
00:26:14  * chicoxyz_quit (Client Quit)
01:15:05  * caridyjoined
01:15:14  * caridyquit (Remote host closed the connection)
01:15:40  * AtumTquit (Remote host closed the connection)
01:18:31  * Fishrock123joined
01:22:51  * Fishrock123quit (Ping timeout: 240 seconds)
01:47:31  * Fishrock123joined
01:47:47  <ljharb>mathiasbynens: yes, everything's 0 by default, but there's an unofficial kind of thing where it's not *really* stage 0 until it's been presented to the committee. anyone "asking for stage 0" is either misunderstanding the doc, or they have a contentious proposal that's at risk of being rejected outright, which would make it useless to mark it as stage 0 (even tho technically it'd be stage 0 automatically)
02:52:30  * jwaldenquit (Quit: back later hopefully)
02:56:27  * dilijevjoined
02:56:54  <dilijev>The language in the spec around Dates seems inconsistent with web reality in a few cases.
02:57:14  <dilijev>Is there a special process for making normative spec changes that update the spec to match web reality or is a PR enough?
02:58:48  * Fishrock123quit (Remote host closed the connection)
03:01:42  * Fishrock123joined
03:03:27  * caridyjoined
03:06:11  * Fishrock123quit (Ping timeout: 240 seconds)
03:23:39  * caridyquit (Remote host closed the connection)
03:42:08  <ljharb>dilijev: i think typically a PR is enough, if it includes results from all 4 engines
03:42:46  <ljharb>dilijev: also feel free to PR tests into compat-table if there's something that 2+ engines do
03:43:14  <dilijev>is compat-table a folder in test262?
03:59:06  * caridy_joined
03:59:15  * caridy_quit (Remote host closed the connection)
03:59:16  <ljharb>dilijev: no i mean http://kangax.github.io/compat-table/es6/
04:04:35  * caridyjoined
04:04:41  * caridyquit (Remote host closed the connection)
04:05:27  <dilijev>oh okay. is that considered official or standard or anything?
04:06:00  <dilijev>IOW is it worth maintaining with minor/edge case test cases?
04:06:10  * caridyjoined
04:06:17  * caridyquit (Remote host closed the connection)
04:06:46  * caridyjoined
04:06:48  <ljharb>dilijev: it's not official or standard, but all the browsers seem to be motivated to fix anything that's marked failing on it :-p
04:07:10  <ljharb>dilijev: imo it's worth maintaining until such time as it employs test262 directly, which has been on peoples wishlist for years but is probably still years out
04:07:12  <dilijev>In this case it's 4/4
04:07:16  <dilijev>```
04:07:16  <dilijev>## Source
04:07:16  <dilijev>print(new Date('2008-10-13T05:16:33Z').toUTCString());
04:07:16  <dilijev>print(new Date('2008-10-13T05:16:33Z').toString());
04:07:16  <dilijev>print(new Date('2008-10-13T05:16:33Z').toDateString());
04:07:16  <dilijev>print(new Date('2008-10-13T05:16:33Z').toTimeString());
04:07:16  <dilijev>#### ch, d8, jsc, sm
04:07:17  <dilijev>Mon, 13 Oct 2008 05:16:33 GMT
04:07:17  <dilijev>Sun Oct 12 2008 22:16:33 GMT-0700 (Pacific Daylight Time)
04:07:18  <dilijev>Sun Oct 12 2008
04:07:18  <dilijev>22:16:33 GMT-0700 (Pacific Daylight Time)
04:07:19  <dilijev>```
04:07:31  <ljharb>then yes, i'd say it would be awesome if you could PR it into both test262 and compat-table
04:08:03  <ljharb>is it something that's just web reality, or is it something that's subjectively/vaguely specified by a specific edition of the spec?
04:08:17  <dilijev>it's web reality and incorrect in spec
04:08:20  <ljharb>gotcha
04:08:30  <ljharb>then yeah that'd be great to send those 2 PRs, plus a PR to the spec itself <3
04:08:37  <dilijev>toUTCString goes day, month, year
04:08:38  <ljharb>we can talk about it in a week and a half
04:08:41  <dilijev>the others go month, day year
04:09:03  <dilijev>Difference in whether there's a comma after the Day of Week, which I think is correct in the spec
04:11:01  * caridyquit (Ping timeout: 240 seconds)
04:21:56  * Fishrock123joined
04:45:06  * Fishrock123quit (Remote host closed the connection)
04:57:27  * jwaldenjoined
05:08:56  * caridyjoined
05:17:21  * caridyquit (Ping timeout: 248 seconds)
05:21:12  * gibson042quit (Ping timeout: 240 seconds)
05:33:16  * Fishrock123joined
05:40:21  * jmdyckquit (Remote host closed the connection)
05:43:23  * Fishrock123quit (Remote host closed the connection)
05:44:40  * Fishrock123joined
06:06:18  * Fishrock123quit (Quit: Leaving...)
07:32:09  * howdoiquit (Quit: Connection closed for inactivity)
08:08:45  * caridyjoined
08:13:21  * caridyquit (Ping timeout: 248 seconds)
08:14:49  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
09:09:09  * annevkquit (Ping timeout: 252 seconds)
09:09:36  * annevkjoined
10:54:01  * gskachkovjoined
11:00:47  * gskachkov_joined
11:02:25  * gskachkov_quit (Client Quit)
11:02:35  * gskachkovquit (Ping timeout: 240 seconds)
11:08:50  * gskachkovjoined
11:12:32  * caridyjoined
11:16:42  * caridyquit (Ping timeout: 240 seconds)
11:25:06  * mylesborinsquit (Quit: farewell for now)
11:25:36  * mylesborinsjoined
11:29:33  * gskachkovquit (Quit: gskachkov)
11:31:08  * gskachkovjoined
11:48:33  * gskachkovquit (Quit: gskachkov)
11:51:59  * gskachkovjoined
11:59:08  * dpkjoined
11:59:53  <dpk>hi there. i wondered if anyone's considered adding finalizers or destructor methods to ECMAScript?
12:00:32  <dpk>in theory they shouldn't be needed, but since we now have emscripten it's sometimes necessary to connect garbage collection of JS objects to management of the emscripten memory buffer
12:01:19  * gskachkovquit (Ping timeout: 258 seconds)
12:02:57  <dpk>(essentially i just want to be able to call Module._free on some of the stuff i've allocated in the emscripten memory space, whenever an instance of the JS class i've created to wrap that stuff in a nice API gets collected)
12:38:30  <annevk>dpk: it comes up sometimes iirc, Mark Miller has thoughts
12:39:09  <annevk>Also formalizing OOM
13:13:56  * caridyjoined
13:18:07  * jmdyckjoined
13:18:25  * caridyquit (Ping timeout: 248 seconds)
14:11:07  * AtumTjoined
14:51:31  <ljharb>destructors would tell you when GC occurs tho
14:54:09  <annevk>ljharb: yup
14:58:20  <annevk>dpk: https://esdiscuss.org/topic/weak-references-and-destructors and https://esdiscuss.org/topic/observable-gc go into it a bit
15:15:28  * caridyjoined
15:20:01  * caridyquit (Ping timeout: 248 seconds)
15:30:43  * caridyjoined
15:42:59  * gskachkovjoined
15:48:55  * caridyquit (Remote host closed the connection)
15:49:37  * caridyjoined
16:02:54  <dpk>annevk: so we don't have observable GC (according to http://w3ctag.github.io/design-principles/#js-gc) because it would be non-portable?
16:03:13  <dpk>i mean, i can already watch the GC at work with WeakMap and WeakSet, just in a very roundabout way
16:03:33  <dpk>so this is already a 'problem'
16:04:30  <annevk>dpk: that argument is also made further down the thread, though it might be worth filing an issue against that document with concrete examples of workarounds
16:04:32  <samth>dpk: no, you can't watch the GC with those, which is an intentional part of their design
16:04:41  <dpk>samth: i can't?
16:04:56  <samth>you can't tell if something has been collected with a WeakSet
16:05:16  <samth>because either you have it (in which case it can't have been collected) or you can't see if it's in the set at all
16:06:00  <samth>weak sets are not enumerable, for example, and the .length is always 0
16:06:04  <annevk>I think there's a couple places in the web platform where folks haven't taken care to ensure GC is not exposed, but generally those are considered bugs
16:06:30  <annevk>But I'm still rather suspect of service workers, I don't think it's been properly reviewed with this in mind
16:06:53  <dpk>oh, i didn't know WeakSet wasn't enumerable. hmm, okay then
16:11:40  <dpk>well, the problem here then is that i'm faced with a JS class which can potentially leak memory if you're not very careful to manually destroy it. that seems objectively worse than code which might behave slightly differently timing-wise depending on the JS implementation in use
16:13:04  <ljharb>dpk: the solution is then to rearchitect it so it doesn't have that problem
16:15:54  <dpk>ljharb: as far as i can tell, this is a problem for almost any code that uses an emscriptened C library which needs to malloc, and the emscripten people don't have any better answer than 'well, then you need to be careful to free everything'
16:15:56  <dpk>https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#call-compiled-c-c-code-directly-from-javascript
16:17:00  <ljharb>dpk: my gut response is then that that's a pretty big flaw in emscripten :-/ but i'm not familiar with it so i can't know for sure
16:18:48  <samth>ljharb: I think they can't do better without weak references, but maybe not even then
16:18:58  <ljharb>possibly true
16:18:59  <samth>manual memory management is manual
16:35:32  <leobalter>ljharb dilijev we have a compat table project in progress, it's basically me using my available open source time, when I'm not working directly on Test262. We had to create some better tools to fetch the results and did some nice work to get CI tooling (to generate results), this will be hopefully done before December
16:35:47  <leobalter>by compat table I mean something fetching results from Test262
16:37:40  <ljharb>that'd be great
16:37:53  <ljharb>nobody's yet audited the compat table tests tho; i'm quite sure there's things in there that aren't in test262
16:39:17  <leobalter>ljharb this is not in Test262, not anything oficial. This project is just a collection of test results
16:40:06  <leobalter>using the tests from Test262. The idea is to collect the results using CI tooling, this helps me a lot to identify areas of improvements in Test262 itself.
16:40:51  <leobalter>is more a results dashboard rather than a "compat table", but you can read that just to check things for feature compatibility.
16:43:06  <ljharb>ah ok
16:52:14  <dpk>if a generator which contains a try..finally begins, but is never exhausted then gets garbage collected, …?
16:52:34  <dpk>Python, according to my quick test, does the right thing and calls the finally block
16:53:50  <dpk>(upon garbage collection)
16:56:02  <ljharb>i don't think it can ever be GCd if it's never exhausted
16:56:16  <ljharb>or hm
16:56:19  <ljharb>that's a good question
16:56:24  <ljharb>but no, i don't think the finally block will be executed
17:04:28  * gskachkovquit (Ping timeout: 268 seconds)
17:33:32  * jwaldenjoined
19:27:16  * gskachkovjoined
20:10:37  * gskachkovquit (Quit: gskachkov)
20:14:48  * gskachkovjoined
21:08:29  * gskachkovquit (Quit: gskachkov)
21:12:01  * gskachkovjoined
21:24:26  * gskachkovquit (Quit: gskachkov)
21:37:09  * gskachkovjoined
21:48:49  <dilijev>bterlson: is leobalter's compat dashboard project the test262 dashboard you mentioned to me some time back?
21:57:37  * gskachkovquit (Quit: gskachkov)
22:02:24  * gskachkovjoined
22:10:07  * gskachkovquit (Quit: gskachkov)
22:13:24  <dilijev>littledan: I'm wondering why some of the date functions in the spec are runtime semantics and some are not -- they all seem to have algorithm setps
22:13:49  <dilijev>For example https://tc39.github.io/ecma262/#sec-todatestring versus https://tc39.github.io/ecma262/#sec-datestring
22:14:38  <dilijev>I understand the naming is just that one is an abstract operation and the other is not but why is ToDateString a runtime semantics thing (called from https://tc39.github.io/ecma262/#sec-date.prototype.tostring)
22:48:07  <bterlson>dilijev: link?
22:48:37  <dilijev>^ bterlson: he mentioned above, don't know about the link
22:49:29  <jmdyck>dilijev: The algorithms labelled 'Runtime Semantics' are abstract operations. The others are built-in functions (accessible to users). Or are you asking something else?
22:50:28  <jmdyck>(At least, I *think* that should be true.)
23:01:18  <dilijev>jmdyck: Hmm that would make sense. Thanks for clarifying. In some cases that may not be how they are used. I'll double check
23:17:55  <bterlson>dilijev: ahh yep same thing
23:27:56  <dilijev>jmdyck: from the ones I'm looking at now, runtime semantics for internal operations look consistent. I'll stay on the lookout for inconsistencies in the future.
23:28:09  <dilijev>* abstract operations
23:28:22  <jmdyck>sounds good
23:32:00  <dilijev>Alright here's the possible semantics inconsistency I'm puzzling over right now. I'll try to make it concise.
23:32:15  <dilijev>We have four Date.prototype.to*String operations
23:32:24  <dilijev>```
23:32:24  <dilijev> ## Source
23:32:24  <dilijev> print(new Date('2008-10-13T05:16:33Z').toUTCString());
23:32:24  <dilijev> print(new Date('2008-10-13T05:16:33Z').toString());
23:32:24  <dilijev> print(new Date('2008-10-13T05:16:33Z').toDateString());
23:32:24  <dilijev> print(new Date('2008-10-13T05:16:33Z').toTimeString());
23:32:24  <dilijev> #### ch, d8, jsc, sm
23:32:25  <dilijev> Mon, 13 Oct 2008 05:16:33 GMT
23:32:25  <dilijev> Sun Oct 12 2008 22:16:33 GMT-0700 (Pacific Daylight Time)
23:32:26  <dilijev> Sun Oct 12 2008
23:32:26  <dilijev> 22:16:33 GMT-0700 (Pacific Daylight Time)
23:32:27  <dilijev>```
23:32:54  <dpk>even Scheme lets you observe the garbage collector now … https://srfi.schemers.org/srfi-124/srfi-124.html (will very probably be in R7RS Large)
23:34:24  <dilijev>toUTCString is fine -- just there as a comparison (it's strange that we all agreed on a different (month day) vs (day month) ordering there and the comma after day of week versus no comma
23:34:33  <dilijev>but that's something we all agree on and not a problem
23:34:43  <bterlson>dpk: have you seen https://github.com/tc39/proposal-weakrefs/blob/master/specs/weakrefs.md?
23:34:45  <dilijev>ignoring toGMTString which is identical and the toLocale* variants
23:35:03  <dilijev>we are left with toString toDateString and toTimeString
23:35:24  <dilijev>the web reality is that toString is (cat toDateString toTimeString)
23:37:49  <dilijev>reading the spec i'm having a hard time piecing that together and i keep thinking it's saying toDateString should be identical to toString
23:37:58  <dilijev>I'll find references to explain what i'm seeing, h/o
23:38:26  <dpk>bterlson: the 'executor' there is the finalizer for when the 'target' is collected? from the example code and the name that seems to be the case, but the prose suggests otherwise
23:38:40  <dpk>("Because condemned objects can never become reachable again, it is not visible to the program whether they were actually reclaimed or not at any particular time.")
23:38:47  <dpk>oh, sorry, i misunderstood that sentence
23:39:14  <dpk>well, if that gets accepted it'll be super
23:39:23  <bterlson>nice, glad to hear
23:54:06  <dilijev>ah i see my confusion
23:54:11  <dilijev>My confusion comes from the fact that ToDateString calls DateString(t) and concats the result with TimeString(t), and TimeZoneString(tv).
23:54:12  <dilijev>> Date.prototype.toString (https://tc39.github.io/ecma262/#sec-date.prototype.tostring)
23:54:12  <dilijev>>> Return ToDateString(tv).
23:54:12  <dilijev>>>> ToDateString(tv) (https://tc39.github.io/ecma262/#sec-todatestring)
23:54:12  <dilijev>>>>> Return the string-concatenation of DateString(t), the code unit 0x0020 (SPACE), TimeString(t), and TimeZoneString(tv).
23:54:12  <dilijev>>>>>> DateString(t) e.g. `Sun Oct 12 2008`
23:54:12  <dilijev>>>>>> "string-concatenation of ... TimeString(t), and TimeZoneString(tv)." e.g. `22:16:33 GMT-0700 (Pacific Daylight Time)`
23:54:13  <dilijev>>>>> e.g. `Sun Oct 12 2008 22:16:33 GMT-0700 (Pacific Daylight Time)`
23:54:13  <dilijev>Perhaps ToDateString should be called ToDateTimeString?
23:59:28  <dilijev>From its other uses e.g. in the Date constructor I can see why ToDateString is probably less confusing but still
23:59:40  <dilijev>ToDateString and DateString having totally different meanings is a bit jarring