Support QuickJS?

[mathiasbynens]

https://bellard.org/quickjs/

[devsnek]

I am working on an engine config for quickjs.

[devsnek]

I have finished up the config (it was basically a copy of engine262) but there is one small patch needed for quickjs itself. I emailed the author with a patch :crossed_fingers:

[rwaldron]

Yessir. I started writing the runtime and agent yesterday, but hit some obstacles. I emailed Fabrice this morning.

Fabrice,

First let me just say how excited we are about QuickJS! We at Bocoup spend a lot of time evaluating the existing JavaScript engines as well as emerging efforts, and your work is by far one of the most impressive implementations we've seen since taking the lead on Test262 in 2015.

As I mentioned above, we spend a lot of time evaluating JavaScript engines, both new and long standing projects, in terms of specification conformance. We're members of Ecma and participate in TC39 (TG1 & TG2) and TC53. We are also the primary maintainers of Test262 and associated Test262 test running tools. It is in that capacity that we're reaching out to request a "feature" for QuickJS. In order for us to verify QuickJS's conformance as an impartial third party, we need to have runtime access to either a) primitives that enable implementing the Test262 Host Defined Functions, or b) access to a host's implementation of those functions. A good comparison is ChakraCore, SpiderMonkey, V8, vs. JavaScriptCore: ChakraCore, SpiderMonkey and V8 provide the primitives and we implement the host defined functions in a "prelude" source file, while JavaScriptCore exposes a print() and $262 implementation of their own. Now for my big ask: I reviewed the source code for QuickJS and saw that you've done the work of implementing the Test262 Host Defined Functions, but that they are only available in your own run-test262 program. I'd like to request that you expose the Test262 Host Defined Functions in a way that allows us to either "enable" them, or assume their presence when executing a source file with qjs. If you don't want to burden qjs with an optional flag to turn on these APIs, an alternative would be to create a new "qjst", which is what our friends at Moddable chose to do for their Moddable XS engine (it wraps their base engine with necessary mechanisms to run a test file with the special Test262 Host Defined Functions exposed to the runtime. Enabling this will allow us to include QuickJS in our daily automated conformance test runner and publish the results to https://test262.report/—which we are very eager to do!!

[rwaldron]

@devsnek I didn't mean to duplicate or undermine your efforts, it appears we came to the same conclusion. I had sent that email this morning and @leobalter linked me to this issue but I forgot to post it until this afternoon.

[devsnek]

@rwaldron no prob, it seems we were focusing on different aspects anyway. I was just aiming to support eshost-cli.

[rwaldron]

eshost determines what is supported by eshost-cli ;)

[rwaldron]

I've been working with Fabrice this week to get changes made to "run-test262" that will allow it to run with their built-in runner machinery turned off.

[rwaldron]

QuickJS is now supported, but the run-test262 binary, with -N must be used.

[Alhadis]

FYI, I was able to configure eshost-cli to run QuickJS normally by pointing it to a shell-script:

{
    "hosts": {
        "quickjs": {
            "type": "qjs",
            "path": "/Users/john/.jsvu/qjs"
        }
    }
}

With ~/.jsvu/qjs being:

#!/bin/sh
shift 2
exec qjs --module "$@"

I've only just discovered eshost-cli, so I'm in the dark as to how important having Host Defined functions are to the average eshost user. But requiring users to run a specialised build of QuickJS feels rather excessive to me. Is there something I'm missing?