SpiderMonkey 68 / GJS 1.63.90 / GNOME 3.35.90

Hi list,

This is a notice that I just released GJS 1.63.90 depending on SpiderMonkey 68 (corresponding with Firefox's extended support release, ESR68) for the upcoming GNOME 3.35.90. Quoted below is the release announcement sent to ftp-release-list.

Mozilla has not worked out an automatic release process for SpiderMonkey tarballs yet. The official recommendation is to use the Firefox ESR68 source tarball. More information can be found here: https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr68/docs/Building%20SpiderMonkey.md

You will not need any extra patches to build SpiderMonkey for i386 or x86_64, but it does require at least version 68.4.0. For ARM you will need a patch, hosted here: https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/files/mozjs68/armv7_disable_WASM_EMULATE_ARM_UNALIGNED_FP_ACCESS.patch

This is the recommended set of configure options with which to build SpiderMonkey 68:
--disable-jemalloc: This one is strictly required, as the jemalloc allocator is incompatible with standalone SpiderMonkey.
--enable-unaligned-private-values: This one is also strictly required, to prevent data corruption issues with byte arrays.
--with-intl-api: This one is also strictly required, as core functionality of GJS will not work without it.
--enable-posix-nspr-emulation: This one is strongly recommended. Without it, you'll have an unnecessary dependency on NSPR.
--with-system-zlib: This one is also strongly recommended. Without it, you'll build SpiderMonkey's internal copy of zlib, which shouldn't be necessary as most if not all systems include a suitable shared library.
--with-system-icu: This one is recommended, but at least ICU 63.1 is required. If that's not possible on your platform, then you can use --without-system-icu to build SpiderMonkey's internal copy instead.
--host: In the org.gnome.Sdk flatpak manifest we set this to i686-unknown-linux-gnu for i386, and armv7-unknown-linux-gnueabihf for ARM. I'm not entirely sure if this is strictly necessary.
AUTOCONF: If you make downstream changes to SpiderMonkey's configure scripts, you will need to have a build-dependency on autoconf 2.13 (any more recent version will not work) to regenerate them. You may need to set the AUTOCONF variable on the configure command line, since different systems have different program-suffixes for autoconf 2.13. If you didn't make changes but the build is checking for autoconf 2.13 anyway, you can bypass this check by configuring with AUTOCONF=autoconf.

You may also want to consider:
--enable-ctypes: This is not considered core GJS functionality, so no GNOME software should use it, but it could be interesting for developers. However, I don't test builds with this option and it's been broken in the past.
--enable-debug: Never, ever ship a libmozjs with this option in production, as the performance is severely degraded. However, if your platform allows for such a thing, then you might
consider shipping a separate debug-enabled package that conflicts with the main package, since the debug option makes it significantly easier to develop with SpiderMonkey and diagnose crashes that might happen on user machines. (A complication is that SpiderMonkey's ABI is different between debug and non-debug, so a separate GJS package would also be required. GJS's ABI is the same in both cases.)

If you run into build problems with SpiderMonkey on your platform, please open a bug on bugzilla.mozilla.org and CC me. If you can provide a patch that would be great. Mozilla has a review and backport process that's a bit mystifying for outsiders, and I can help move your patches through it.

Philip C

On Sat, Feb 1, 2020 at 12:35 PM Philip Chimento <install-module master gnome org> wrote:
About gjs

GNOME _javascript_ bindings


- New JS API: The GObject module has gained new overrides:
  GObject.signal_handler_find(), GObject.signal_handlers_block_matched(),
  GObject.signal_handlers_unblock_matched(), and
  GObject.signal_handlers_disconnect_matched(). These overrides replace the
  corresponding C API, which was not idiomatic for _javascript_ and was not fully
  functional because it used bare C pointers for some of its functionality.
  See modules/overrides/GObject.js for API documentation.

- New _javascript_ features! This version of GJS is based on SpiderMonkey 68, an
  upgrade from the previous ESR (Extended Support Release) of SpiderMonkey 60.
  Here are the highlights of the new _javascript_ features.
  For more information, look them up on MDN or devdocs.io.

  * New language features
    + The BigInt type, currently a stage 3 proposal in the ES standard, is now

  * New syntax
    + `globalThis` is now the ES-standard supported way to get the global
      object, no matter what kind of JS environment. The old way, `window`, will
      still work, but is no longer preferred.
    + BigInt literals are expressed by a number with "n" appended to it: for
      example, `1n`, `9007199254740992n`.

  * New APIs
    + String.prototype.trimStart() and String.prototype.trimEnd() now exist and
      are preferred instead of trimLeft() and trimRight() which are nonstandard.
    + String.prototype.matchAll() allows easier access to regex capture groups.
    + Array.prototype.flat() flattens nested arrays, well-known from lodash and
      similar libraries.
    + Array.prototype.flatMap() acts like a reverse filter(), allowing adding
      elements to an array while iterating functional-style.
    + Object.fromEntries() creates an object from iterable key-value pairs.
    + Intl.RelativeTimeFormat is useful for formatting time differences into
      human-readable strings such as "1 day ago".
    + BigInt64Array and BigUint64Array are two new typed array types.

  * New behaviour
    + There are a lot of minor behaviour changes as SpiderMonkey's JS
      implementation conforms ever closer to existing ECMAScript standards and
      adopts new ones. For complete information, read the Firefox developer
      release notes:

  * Backwards-incompatible changes
    + The nonstandard String generics were removed. These had only ever been
      implemented by Mozilla and never made it into a standard. (An example of a
      String generic is calling a string method on something that might not be a
      string like this: `String.endsWith(foo, 5)`. The proper way is
      `String.prototype.endsWith.call(foo, 5)` or converting `foo` to a string.)
      This should not pose much of a problem for existing code, since in the
      previous version these would already print a deprecation warning whenever
      they were used.
      You can use `moz68tool` from mozjs-deprecation-tools
      (https://gitlab.gnome.org/ptomato/moz60tool) to scan your code for this
      nonstandard usage.

- Closed bugs and merge requests:
  * invalid import on signal.h [#295, !382, Philip Chimento]
  * SpiderMonkey 68 [#270, !386, Philip Chimento]
  * GObject: Add override for GObject.handler_block_by_func [#290, !371, Philip

https://download.gnome.org/sources/gjs/1.63/gjs-1.63.90.tar.xz (404K)
  sha256sum: 74f93da9024a8a915db4b97aa216f931ceefd01bc847e4400d585340750ecfeb

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]