00:12:07  * caridyjoined
00:38:32  * caridyquit (Read error: Connection reset by peer)
00:38:39  * caridyjoined
01:35:12  * caridyquit (Remote host closed the connection)
01:43:23  * AtumT_quit (Remote host closed the connection)
01:54:45  * gibson042joined
02:35:59  * caridyjoined
02:36:33  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
02:40:38  * caridyquit (Ping timeout: 268 seconds)
03:10:07  * caridyjoined
03:10:17  * caridyquit (Remote host closed the connection)
03:10:47  * caridyjoined
03:11:50  * caridyquit (Remote host closed the connection)
03:11:56  * caridyjoined
03:12:25  * caridyquit (Remote host closed the connection)
03:13:00  * caridyjoined
04:02:27  * caridyquit (Ping timeout: 240 seconds)
05:18:16  * jmdyckquit (Remote host closed the connection)
11:25:10  * mylesborinsquit (Quit: farewell for now)
11:25:40  * mylesborinsjoined
11:53:32  * brianloveswordsquit (Ping timeout: 240 seconds)
11:53:47  * bstorozquit (Read error: Connection reset by peer)
11:53:53  * littledanquit (Ping timeout: 250 seconds)
11:54:36  * bstorozjoined
11:54:45  * dilijevquit (Ping timeout: 250 seconds)
11:55:38  * dilijevjoined
11:55:39  * littledanjoined
13:49:12  * jmdyckjoined
13:49:45  * brianloveswordsjoined
13:51:00  * jmdyckquit (Remote host closed the connection)
13:51:41  * jmdyckjoined
14:26:23  * AtumTjoined
16:27:12  * jmdyckquit (Ping timeout: 240 seconds)
16:29:31  * jmdyckjoined
16:53:53  * jwaldenjoined
18:12:33  * cloudshujoined
19:11:29  <dilijev>cloudshu: I'm guessing what bterlson is getting at is that eshost-cli should be helpful for you, but we'd like to know how we could improve it to better suit your purposes.
19:11:43  <dilijev>eshost abstracts over some differences in the engines so that the same test case can work in all of them
19:12:24  <dilijev>we could certainly have eshost display exit codes.
19:12:41  <dilijev>whatever utility you would use to run an arbitrary engine would have to know to propagate the return code anyway
19:13:07  <dilijev>as for progress -- what would that look like to you?
19:13:30  <cloudshu>dilijev: ah, i must've missed some messages because i've been too cheap to subscribe to irccloud after i lost my enterprise sub...
19:14:00  <dilijev>IOW what I'm imagining is that the engine itself would have to report progress, but progress is really something that should be defined by the app or test case, in which case you would have your test case print something out to show progress
19:14:55  <cloudshu>dilijev: the engine-agnosticness isn't important for the tests, which will be tied to the specific engine. i just wanted to save my own time in adopting something that wasn't already hardcoded to a particular engine
19:15:20  <dilijev>cloudshu: not sure you missed anything. The last message between you and brian was "bterlson: return code checking and progress would be nice"
19:15:23  <cloudshu>dilijev: by progress i don't mean sub-test, i just mean stuff like "succs/fails/total so far" or something
19:15:46  <cloudshu>dilijev: like per-file progress, assuming the unit of testing is just per-file
19:15:51  <dilijev>yeah, unless you have a runner with inherent knowledge of a test harness technology, you'd have to code that up yourself or use a library
19:15:52  <cloudshu>dilijev: instead of anything more sophisticated
19:15:57  <dilijev>are you asking if anyone knows of such a library?
19:16:20  <cloudshu>dilijev: yes. doesn't have to be perfect fit, just what's the easiest to use as a starting point
19:16:51  <dilijev>not sure about per-file... i think if you had a script which would be running multiple tests it would be easy to have the script print out which file you're on
19:16:57  <dilijev>but if you're looking at per-test-case within a single file
19:17:03  <cloudshu>dilijev: i am not
19:17:04  <dilijev>ChakraCore has a library we use in some of our unit tests
19:17:54  <cloudshu>is it complicated? :)
19:17:56  <dilijev>https://github.com/Microsoft/ChakraCore/blob/master/test/UnitTestFramework/UnitTestFramework.js
19:18:35  <dilijev>I was hoping it wouldn't have any WScript dependencies but it looks like it does
19:18:36  <cloudshu>ah that's not too bad
19:18:42  <cloudshu>except those parts, yes
19:18:49  <dilijev>otherwise it should be plat agnostic
19:18:59  <dilijev>maybe we could refactor those bits out to have them under a feature check
19:19:01  <dilijev>anyway
19:19:10  <dilijev>boilerplate to use this is pretty simple
19:19:10  <dilijev>https://github.com/Microsoft/ChakraCore/blob/master/test/Intl/Basics.js
19:19:26  <dilijev>you would need a module or script file loader for your test case
19:19:38  <dilijev>or you could copy the framework into your test directly
19:19:57  <cloudshu>unfortunately that is much too modern for me to use
19:20:52  <dilijev>if you mean module loading -- that's not even how this was intended to be used ... e.g. WScript.LoadScriptFile has been around for a long time and is nothing like loading a module
19:20:57  <dilijev>it's more like c++ #include
19:21:02  <dilijev>except dynamic
19:21:20  <cloudshu>ah
19:22:01  <dilijev>anyway if you copy the runner into your test case directly, then all you need to do is `let tests = []; testRunner.runTests(tests)`
19:22:33  <dilijev>it should print as it goes (but it only prints on test failures) and give you a count of tests passed / failed at the end
19:23:22  <cloudshu>dilijev: this is what ChakraCore uses for its internal engine tests?
19:23:25  <dilijev>it takes an option bag with verbose `{ verbose: false }` to print information IFF there is a failure, otherwise just prints pass
19:23:43  <dilijev>yeah a lot of our unit tests are written with it
19:24:01  <dilijev>probably not the majority unfortunately
19:24:08  <dilijev>a lot of tests predate this frameowkr
19:24:12  <dilijev>and some tests are not well suited to it
19:24:20  <dilijev>(things like checking error stacks etc)
19:24:30  <cloudshu>dilijev: most of SM's tests would want to have a fresh shell per test (file)
19:24:37  <cloudshu>dilijev: how is that managed here?
19:24:45  <dilijev>our test runner runs one test at a time
19:24:51  <dilijev>in a fresh shell
19:24:54  <dilijev>that's runtests.py
19:25:00  <cloudshu>dilijev: right, ok
19:25:02  <dilijev>https://github.com/Microsoft/ChakraCore/blob/master/test/runtests.py
20:16:12  <dilijev>Does anyone know if this appears anywhere in the spec, or is just a case of undocumented cases being agreed upon by engines as a matter of web reality?
20:16:12  <dilijev>https://github.com/Microsoft/ChakraCore/pull/4062
20:17:23  <dilijev>Closest I can find to a special case on years <100
20:17:24  <dilijev>https://tc39.github.io/ecma262/#sec-date-year-month-date-hours-minutes-seconds-ms
20:17:29  <dilijev>If y is not NaN and 0 ≤ ToInteger(y) ≤ 99, let yr be 1900+ToInteger(y); otherwise, let yr be y.
20:17:35  <dilijev>but that doesn't cover the case of
20:18:13  <dilijev>[0..50] => year+=2000; [50..99] => year+=1900
20:18:50  <dilijev>which seems to be specific to mm/dd/yy or possibly dd/mm/yy if you can make the date parsing algorithm interpret it that way
21:19:45  * not-an-aardvarkjoined
21:57:56  * caridyjoined
23:09:00  * caridyquit (Remote host closed the connection)
23:09:36  * caridyjoined
23:29:12  * not-an-aardvarkquit (Quit: Connection closed for inactivity)