02:31:19  * gibson042joined
03:16:37  * gibson042quit (Ping timeout: 265 seconds)
04:05:42  * stpeterjoined
04:06:17  * stpeterquit (Client Quit)
04:25:34  * jmdyckquit (Remote host closed the connection)
05:01:48  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
05:03:25  * AtumTquit (Ping timeout: 256 seconds)
05:11:26  * shachaf_joined
05:16:32  * shachafquit (*.net *.split)
05:16:33  * bradleymeckquit (*.net *.split)
05:16:33  * gajusquit (*.net *.split)
05:16:33  * Wizekquit (*.net *.split)
05:16:34  * d_runquit (*.net *.split)
05:16:34  * mathiasbynensquit (*.net *.split)
05:16:34  * JaseWquit (*.net *.split)
05:16:34  * mmunquit (*.net *.split)
05:16:34  * kosamariquit (*.net *.split)
05:16:35  * maggie_quit (*.net *.split)
05:16:35  * littledanquit (*.net *.split)
05:16:35  * Domenicquit (*.net *.split)
05:18:59  * vikash-afkquit (Ping timeout: 260 seconds)
05:19:58  * shachaf_changed nick to shachaf
05:23:29  * vikash-afkjoined
05:35:17  * gajusjoined
05:35:17  * bradleymeckjoined
05:35:17  * Wizekjoined
05:35:17  * d_runjoined
05:35:17  * mathiasbynensjoined
05:35:17  * JaseWjoined
05:35:17  * mmunjoined
05:35:17  * kosamarijoined
05:35:17  * maggie_joined
05:35:17  * Domenicjoined
05:35:17  * littledanjoined
05:36:22  * Wizekquit (Max SendQ exceeded)
05:38:38  * Wizekjoined
06:22:22  * howdoijoined
08:09:02  * akoserwa|lunchjoined
09:51:53  <littledan>eval is a sandwich: filled with savory code execution, with parsing, compilation and deoptimization as the bread
10:25:40  * mylesborinsquit (Quit: farewell for now)
10:25:49  * mylesborinsjoined
10:33:07  * akoserwa_joined
10:36:14  * akoserwa|lunchquit (Ping timeout: 276 seconds)
10:53:03  * akoserwa__joined
10:55:21  * akoserwa_quit (Ping timeout: 240 seconds)
11:03:03  * ebrynquit (Quit: Connection closed for inactivity)
11:39:51  * jmdyckjoined
13:42:41  <IgnoredAmbience>In this case, I'm amazed we'd never noticed that it wasn't working in some circumstances.
13:43:33  <IgnoredAmbience>Might be a test262 coverage hole, I should look into that
13:50:05  <IgnoredAmbience>A quick grep leaves me unable to find any instances of eval.call(), bind() or apply()
13:50:48  <IgnoredAmbience>For some odd reason we'd not actually populated the [[Call]] slot of our eval, but had special-cased it through the call syntax
13:51:56  * gsnedders|ooojoined
13:53:03  <IgnoredAmbience>*only special-cased it
13:56:49  <gsnedders|ooo>[[OwnPropertyKeys]]() on the built-in objects has a defined enumeration order, but EnumerableOwnPropertyNames just matches the order of EnumerateObjectProperties which has it undefined. I thought Object.keys() for example had a defined order, but this would imply it doesn't?
13:59:21  <IgnoredAmbience>It follows the ES5-era for-in enumeration order. Implementations were different enough that the spec had to be loose.
14:00:50  <gsnedders|ooo>Right; I thought that it had converged at this point, and been spec'd?
14:01:09  <IgnoredAmbience>It is still specced loosely in EnumerateObjectProperties
14:01:50  <gsnedders|ooo>Does the order defined for built-ins in the various [[OwnPropertyKeys]]() definitions get exposed anywhere?
14:04:03  <IgnoredAmbience>Likely in any newer standard library additions, Object.getOwnPropertyDescriptors is one that I've just found
14:04:05  <gsnedders|ooo>I guess Object.assign can expose it if a getter throws
14:04:22  <IgnoredAmbience>And Reflect.ownKeys
14:07:18  <IgnoredAmbience>It also seems that Object.getOwnPropertyNames had its iteration order defined between ES5 and now
14:07:57  <gsnedders|ooo>Object.defineProperties() too
14:08:05  * gsnedders|ooohas scarcely looked at the spec since ES5 days
14:08:20  <IgnoredAmbience>I'm still playing catch-up to be honest
14:08:29  <gsnedders|ooo>Turns out not working on a JS VM any more meant I stopped looking :)
14:08:51  <IgnoredAmbience>I'm now at a point where I'm familiar with how Proxies have been integrated to the language
14:09:17  <IgnoredAmbience>And the various changes that were made to allow for it
14:09:30  <gsnedders|ooo>Yeah, I've not got used to that yet :)
14:11:30  * gsnedders|ooowonders if test262 has tests for order for these
14:22:03  * stpeterjoined
14:27:38  * stpeterquit (Quit: stpeter)
14:46:38  * stpeterjoined
14:51:19  * howdoiquit (Quit: Connection closed for inactivity)
14:59:54  <devsnek>what if we wrote a es2018 engine in JavaScript
15:01:56  <bradleymeck>it would... be difficult
15:02:32  <devsnek>that's where the fun is
15:43:13  <jmdyck>There's Narcissus: https://github.com/mozilla/narcissus/
15:44:24  <jmdyck>i.e., might be easier to upgrade that to es2018 than start from scratch
15:44:39  <gsnedders|ooo>AFAIK, it doesn't implement all of ES5
15:47:58  <jmdyck>yup, looks like it's es3 + some harmony stuff: https://github.com/mozilla/narcissus/wiki/Narcissus-internals
15:50:34  <gsnedders|ooo>so what's the status specing enumeration order for for…in? how much non-interop stuff is left? is it just array properties in SM differing from everything else? is there anything else left?
15:58:34  <devsnek>oooooo thats cool
15:58:51  <devsnek>doesn't look like it got "rapidly revived"
16:00:39  <devsnek>this actually relies on the underlying engine though so thats no fun
16:04:58  * akoserwa__quit (Quit: Leaving)
16:06:11  <gsnedders|ooo>to what degree does it?
16:09:27  <devsnek>`Array: function (dummy) { return Array.apply(this, arguments) }`
16:10:14  <IgnoredAmbience>Ah, that's quite a big one
16:11:20  <IgnoredAmbience>Ours relies on the underlying floating point engine, because I don't really want to do that all in native JS.
16:12:08  <devsnek>i'm having trouble figuring out like how to go from an ast to running code
16:12:24  <devsnek>it looks like narcissus just steps through the ast recursively to perform evaluation
16:12:44  <jmdyck>(There's also https://github.com/codecombat/esper.js/ , though it's not clear to me which version it implements)
16:13:26  <devsnek>oh still in development
16:14:01  <devsnek>this looks fun
16:16:53  <gsnedders|ooo>IgnoredAmbience: I mean every mainstream JS VM just relies on the underlying hardware to do floating point. And hopefully sets the rounding mode and percision correctly.
16:17:42  <IgnoredAmbience>At one point we were going to use a formally verified floating point implementation compiled from Coq
16:17:54  <IgnoredAmbience>But then realised that it probably doesn't matter _that_ much
16:20:37  <gsnedders|ooo>I mean plenty of browsers used x87 in its default 80-bit mode on x86, which totally breaks the ES spec.
16:20:51  <gsnedders|ooo>(But not x86_64, which includes SSE2 by definition.)
16:21:18  <jmdyck>https://github.com/NeilFraser/JS-Interpreter
16:22:48  <gsnedders|ooo>IgnoredAmbience: what are you working on, btw?
16:24:18  <IgnoredAmbience>https://github.com/jscert/jsexplain, JS implementation in subset of OCaml that compiles to JS, based off the interpreter portion of https://github.com/jscert/jscert
16:24:32  <IgnoredAmbience>Primary aim being closeness to spectext
16:25:16  <IgnoredAmbience>And yes, we ran into the x87 80-bit mode problem, as the OCaml compiler passes through to it
16:25:44  <IgnoredAmbience>Got very confused when our nightlies started to fail that particular test262 case
16:26:03  <IgnoredAmbience>(Change of build system)
16:26:15  <gsnedders|ooo>(I presume there's some way to get it to use SSE2 fp instead of x87?)
16:26:47  <IgnoredAmbience>(At the time this was an undocumented 'feature' of the OCaml compiler x86 backend... I don't think it's been fixed since)
16:27:24  * gsnedders|ooohad entirely forgotten about JSCert
16:27:39  <IgnoredAmbience>It's kicking on slowly
16:27:52  <IgnoredAmbience>Core team have moved onto other things since
16:35:11  <IgnoredAmbience>As a result of the esper.js link above, I've just discovered that js.org allocates subdomains for project usage
16:51:52  <devsnek>oh yeah they've been doing that for a while
18:08:31  <devsnek>npm install in the ecma262 repo now yields `No valid versions available for ecmarkdown`
18:09:27  <devsnek>i guess 3.0.9 doesn't satisfy ^3.0.9?
18:13:56  <IgnoredAmbience>Weird, ecmarkup/ecmarkdown aren't appearing in the npmjs.com package search
18:14:37  * jwaldenjoined
18:15:24  <devsnek>https://www.npmjs.com/package/ecmarkup https://www.npmjs.com/package/ecmarkdown
18:15:26  <devsnek>they exist
18:18:12  <IgnoredAmbience>Indeed, quite why they're missing from the search index, however
18:28:35  <ljharb>email support@npmjs.com, they can gfix it
18:38:13  <devsnek>:(
19:55:17  <IgnoredAmbience>Question to the test262 maintainers, would a PR that changes a { name() {} } object style into { name: function() } style be accepted, when this syntax is not the what's being directly tested?
19:55:49  <IgnoredAmbience>Urgh, the second code snip should be { name: function() {} }
19:56:13  <rkirsling>what would be the motivation?
19:56:29  <ljharb>yes, i think it would
19:56:41  <ljharb>i believe the current preference is that tests should be written in ES3 or ES5 except when necessary
19:56:42  <IgnoredAmbience>I don't support the former syntax, and the rest of the testcases in the Proxy don't use it
19:56:47  <IgnoredAmbience>*Proxy directory
19:58:19  <IgnoredAmbience>A chunk of the ownKeys trap tests do, I guess because they were writen later
19:59:32  <ljharb>i think they could all be changed to use older syntax
19:59:51  * IgnoredAmbiencenods, will prepare a PR
20:00:20  <IgnoredAmbience>Temporary fix in my local copy until then
21:09:09  * howdoijoined
22:05:56  * shachaf_joined
22:07:05  * shachafquit (Disconnected by services)
22:08:44  * shachaf_changed nick to shachaf
22:45:26  * jwaldenquit (Ping timeout: 255 seconds)
22:58:10  * rwaldronquit (Ping timeout: 245 seconds)
22:59:46  * gcommerquit (Ping timeout: 264 seconds)
23:03:17  * jwaldenjoined
23:31:54  * rwaldronjoined
23:32:17  * gcommerjoined