From:  Benjamin Bouvier <ben@mozilla.com>
Date:  28 Sep 2017 17:13:21 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine
Subject:  

Re: Success with embedding ESR52 spidermonkey

NNTP-Posting-Host:  63.245.214.181

Thank you Kent, that is great to read!

Note that in general, the Spidermonkey team won't update the documentation
on MDN whenever an API change breaks the code, because (this is going to be
deceptive but) there is nobody who is working on embedding (including
documentation) per se, and Spidermonkey priorities have not been moving
towards this direction, so far (this may or may not change in the future).

That being said, people are usually very happy to help and explain anything
about embedding on IRC (#jsapi on irc.mozilla.org), or to answer
questions/issues in bugs on Bugzilla.

Spidermonkey (Mozilla in general) is also a community project, so help like
the one you provide in this email is much helpful. Our documentation is
hosted on our wiki [1] and can be updated by *anyone*, as long as you sign
in (with Github 🤷).

So Kent, and anybody who stumbled upon SM embedding and found solutions to
their problems, I encourage you to update the wiki pages with your
solutions / fixes, so that other people don't run into them as well. That
would be greatly appreciated and I am pretty sure people from the JS team
would review and tweak the text, if needed. Thanks again!

Cheers,
Benjamin

[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_User_Guide

2017-09-28 0:17 GMT+02:00 Kent Williams :

> In case anyone else follows my particular path (going from ESR45 to
> ESR52)  Thanks to Steve Fink and #JSAPI personage ptomato-M
>
> The biggest problem with doing this is the source code is the only
> up-to-date documentation.  That's an ongoing Spidermonkey issue.
>
> But the changes from JS45->JS52 are smaller than the last upgrade from
> JS38->JS45 which had some drastic and mystifying API changes that took a
> lot more support on the IRC to resolve.
>
> Necessary changes. These might be a subset of what you'll need to do:
>
> 1. JSRuntime is no more.
>
> 2. JSClass has changed. The initialization is roughly like this below.
> Basically the array of class functions is moved out of the JSClass into a
> separate JSClassOps structure.
>
> JSClass ScriptData::global_class = {
> -    "global", JSCLASS_GLOBAL_FLAGS,
> -    0,                                      // JSPropertyOp
> addProperty;
> -    0,                                      // JSDeletePropertyOp
> delProperty;
> -    0,                                      // JSPropertyOp
> getProperty;
> -    0,                                      // JSStrictPropertyOp
> setProperty;
> -    0,                                      // JSEnumerateOp
> enumerate;
> -    0,                                      // JSResolveOp
> resolve;
> -    0,                                      // JSConvertOp
> convert;
> -    0,                                      // FinalizeOpType
> finalize;
> -    0,                                      // JSNative            call;
> -    0,                                      // JSHasInstanceOp
> hasInstance;
> -    0,                                      // JSNative
> construct;
> -    JS_GlobalObjectTraceHook,      // JSTraceOp           trace
> -};
> -
> +static const JSClassOps global_ops = {
> +    /* Function pointer members (may be null). */
> +    nullptr,                              // JSAddPropertyOp addProperty;
> +    nullptr,                              // JSDeletePropertyOp
> delProperty;
> +    nullptr,                              // JSGetterOp getProperty;
> +    nullptr,                              // JSSetterOp setProperty;
> +    nullptr,                              // JSEnumerateOp enumerate;
> +    nullptr,                              // JSResolveOp resolve;
> +    nullptr,                              // JSMayResolveOp mayResolve;
> +    nullptr,                              // FinalizeOp finalize;
> +    nullptr,                              // JSNative call;
> +    nullptr,                              // JSHasInstanceOp hasInstance;
> +    nullptr,                              // JSNative construct;
> +    JS_GlobalObjectTraceHook,      // JSTraceOp           trace;
> +};
> +/* The class of the global object. */
> +JSClass ScriptData::global_class = {
> +    "global",
> +    JSCLASS_GLOBAL_FLAGS,
> +    &global_ops
> +};
> +
>
> 3. JS_NewContext no longer takes the runtime argument, and the size
> argument is what the old JSRuntime init takes, e.g.
> -        context = JS_NewContext(runtime, 8192);
> +        context = JS_NewContext(8L * 1024L * 1024L);
>
> 4. Add JS::InitSelfHostedCode(context) after context initialization.
>
> 5. JS_SetErrorReporter is replaced by JS::SetWarningReporter.
>
> 6. JS::RootedString no longer allows JSRuntime as first argument, the
> signature with a JSContext as first argument is used instead.
>
> 7. JSWarningReporter function signature is changed:
>
> -void ScriptData::spidercode_error(JSContext *cx, const char *message,
> -            JSErrorReport* what) {
> +void ScriptData::spidercode_error(JSContext *cx,JSErrorReport* what) {
>
> And insted of the 'message' parameter, use what->message()
>
> 8. Classes with FinalizeOp member need to specify either
> JSCLASS_FOREGROUND_FINALIZE or JS_BACKGROUND_FINALIZE in the JSClass flags
> field.
>
>
> 9. Linking: There's an ongoing problem related to static linking, the
> ever-popular MOZ_GLUE_IN_PROGRAM bug.  There are various fixes proposed for
> that if you look in Bugzilla@Mozilla which AFAIK don't end up in any
> release yet.
>
> I fixed it by force-loading all of the mozglue library on link:
> -  -lmozglue
> +  -Wl,--whole-archive -lmozglue -Wl,--no-whole-archive
>
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-js-engine@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>