1. 11 Feb, 2019 1 commit
  2. 01 Sep, 2018 2 commits
  3. 29 Jul, 2018 2 commits
    • Philip Chimento's avatar
      byteArray: Add backwards-compatible ByteArray class · 2b6d0fbf
      Philip Chimento authored
      This should make it easier to keep old code working. It adds a legacy
      ByteArray.ByteArray class that works just like the old ByteArray class
      but uses Uint8Array internally. It isn't zero-copy, so it will regress
      the performance of old code, but it should keep almost all code at least
      working. To recover the performance, clients can use Uint8Array instead.
      See: #5
    • Philip Chimento's avatar
      build: Fix distcheck · 526d7f22
      Philip Chimento authored
      The debugger test runner script was not included in the tarball, which
      made the tests fail during distcheck.
      Unreviewed, pushing to fix build.
  4. 23 Jul, 2018 1 commit
    • Philip Chimento's avatar
      debugger: GJS Debugger · ee89551e
      Philip Chimento authored
      This adds a simple debugger, adapted from the "jorendb" program in the
      SpiderMonkey source. It has basic stepping, breaking, and printing
      commands, that work like GDB. Activate it by running the GJS console
      interpreter with the -d or --debugger flag _before_ the name of the JS
      program on the command line.
      To integrate it into programs that embed the GJS interpreter, call
      gjs_context_setup_debugger_console() before executing the JS program.
      It will print when Promises are launched and resolved, although it's not
      yet possible to break at those points.
      Closes: #110
  5. 18 Jul, 2018 1 commit
  6. 16 Apr, 2018 1 commit
  7. 30 Mar, 2018 1 commit
    • Philip Chimento's avatar
      build: Specify code coverage flags correctly · eb041ee9
      Philip Chimento authored
      This uses CODE_COVERAGE_LIBS instead of CODE_COVERAGE_LDFLAGS; the two
      are equivalent but CODE_COVERAGE_LDFLAGS is from an older version of the
      code coverage macro and discouraged.
      Also uses CODE_COVERAGE_CXXFLAGS for C++ compilation.
      In some cases the flags weren't being passed to all compilations because
      AM_*FLAGS is not used by default if there are per-target flags.
  8. 27 Mar, 2018 1 commit
  9. 01 Dec, 2017 1 commit
  10. 05 Oct, 2017 2 commits
  11. 01 Sep, 2017 5 commits
  12. 07 Aug, 2017 3 commits
    • Philip Chimento's avatar
      GObject: Adapt GObject class framework to ES6 · 30170080
      Philip Chimento authored
      This moves our GObject class framework to use ES6 classes. GObject.Object
      and GObject.Interface gain static _classInit() methods which register
      GTypes and perform other such magic that used to be performed in the
      metaclasses. When defining the class you must call
      GObject.registerClass() on the class object, with an optional metadata
      object as the first argument. (The metadata object works exactly like the
      meta properties from Lang.Class, except that Name and Extends are not
          var MyClass = new Lang.Class({
              Name: 'MyClass',
              Extends: GObject.Object,
              Signals: { 'event': {} },
              _init(props={}) {
                  this._private = [];
          var MyClass = GObject.registerClass({
              Signals: { 'event': {} },
          }, class MyClass extends GObject.Object {
              _init(props={}) {
                  this._private = [];
      It is forward compatible with the following syntax requiring decorators
      and class fields, which are not in the JS standard yet:
          class MyClass extends GObject.Object {
              static [GObject.signals] = { 'event': {} }
              _init(props={}) {
                  this._private = [];
      We also now add a [Symbol.hasInstance]() method to interfaces so that
      instanceof will finally work for interfaces.
      One limitation is that GObject ES6 classes can't have constructor()
      methods, they must do any setup in an _init() method.
    • Philip Chimento's avatar
      GObject: Move all legacy GObject class code · bdb66678
      Philip Chimento authored
      This moves the GObject.Class and GObject.Interface code into the Legacy
      module along with Lang.Class and Lang.Interface.
      Also moves all tests for the legacy GObject code into a separate file.
      It is named testLegacyGObject in order to indicate that it tests legacy
    • Philip Chimento's avatar
      lang: Move all legacy Lang.Class code · 78a021e9
      Philip Chimento authored
      This moves Lang.Class into a separate Legacy module, which is not meant
      to be imported directly; instead, Lang imports it and exports the same
      members that it always did.
      Also moves all tests for the legacy Lang.Class into a separate file. It
      is named testLegacyClass in order to indicate that it tests legacy code.
  13. 11 May, 2017 2 commits
  14. 08 Feb, 2017 1 commit
    • Philip Chimento's avatar
      js: Refactor dual use of JS::Heap wrapper · cc71606f
      Philip Chimento authored
      The previous situation was that a JS::Heap wrapper was used to root a GC
      thing under some conditions using JS::AddFooRoot() or the keep-alive
      object, and trace or maintain a weak pointer otherwise.
      This will not be possible anymore in SpiderMonkey 38. JS::AddFooRoot()
      and JS::RemoveFooRoot() are going away, in favour of
      JS::PersistentRootedFoo. The keep-alive object has its own problems,
      because the SpiderMonkey 38 garbage collector will move GC things around,
      so anything referring to a GC thing on the keep-alive object will have to
      know when to update its JS::Heap wrapper when the GC thing moves.
      This previous situation existed in two places.
        (1) The JS::Value holding a trampoline's function. If the function was
        owned by the trampoline (the normal case), then it was rooted. If the
        function was a vfunc, in which case it was owned by the GObject class
        prototype and the trampoline was essentially leaked, then it remained a
        weak pointer.
        (2) The JSObject associated with a closure. In the normal case the
        object and the closure had the same lifetime and the object was rooted.
        Similar to above, if the closure was a signal it was owned by the
        GObject class, and traced.
      For both of these places we now use GjsMaybeOwned, a wrapper that sticks
      its GC thing in either a JS::PersistentRootedFoo, if the thing is
      intended to be rooted, or a JS::Heap<Foo>, if it is not. If rooted, the
      GjsMaybeOwned holds a weak reference to the GjsContext, and therefore
      can send out a notification when the context's dispose function is run,
      similar to existing functionality of the keep-alive object.
      This will still need to change further after the switch to SpiderMonkey
      38, since weak pointers must be updated when they are moved by the GC.
      (This is technically already the case in SpiderMonkey 31, but the API
      makes it difficult to do correctly, and in practice it isn't necessary.)
  15. 14 Jan, 2017 1 commit
  16. 13 Jan, 2017 1 commit
  17. 03 Jan, 2017 1 commit
  18. 28 Dec, 2016 5 commits
  19. 12 Dec, 2016 2 commits
    • Philip Chimento's avatar
      build: Use uninstalled library paths · 2649a2ec
      Philip Chimento authored
      Continuation of previous commit; needed in case there were any values
      already given in GI_TYPELIB_PATH. Also need to specify LD_LIBRARY_PATH to
      pick up uninstalled libgjs if applicable.
    • Philip Chimento's avatar
      build: Use uninstalled typelib path · 9aa231a7
      Philip Chimento authored
      This was causing "make distcheck" to fail because the GjsPrivate typelib
      would otherwise not be found if not installed.
  20. 10 Dec, 2016 1 commit
    • Philip Chimento's avatar
      js: Call JS_Init() and JS_ShutDown() · 6b25ce3b
      Philip Chimento authored
      Starting with mozjs31, JS_Init() is required. Calling JS_ShutDown() on
      exit is not required, but may become so in the future.
      This does so in the constructor and destructor of a static object.
      Normally this is discouraged because the order in which the constructors
      and destructors are called is not guaranteed, but I don't think that is a
      problem here since it's unlikely that anyone will try to use GJS API from
      a static constructor.
      However, API clients still must unref any GjsContext before the program
      shuts down. Usually this is not a problem, unless a JS script calls
      System.exit(), in which case the code would exit immediately without
      unreffing the GjsContext before JS_ShutDown was called. Instead, we make
      System.exit() throw an uncatchable exception, which is propagated all the
      way up to JS::Evaluate() and turned into a GError with code
      GJS_ERROR_SYSTEM_EXIT, thrown from gjs_context_eval().
      For this, we need to expose GjsError and its error codes in the public
      API. (They should have been exposed already, because gjs_context_eval()
      could already throw GJS_ERROR_FAILED.)
      Finally, the tests added as part of this patch made the testSystemExit
      script obsolete.
  21. 30 Nov, 2016 3 commits
    • Philip Chimento's avatar
      build: Reorganize testing makefiles · 838a7f34
      Philip Chimento authored
      These were a bit hard to navigate before, it was difficult to determine
      where to look if you wanted to write a test for new functionality. Now
      everything devoted to making "make check" work is in Makefile-test.am.
      The file is delineated into sections and comments are added.
      All the rules for converting some of the tests into installed tests, and
      installing them in the right place, are in Makefile-insttest.am now.
    • Philip Chimento's avatar
      build: Convert testCommandLine.sh to output TAP · 5be2bb7d
      Philip Chimento authored
      It's nice to be able to see in the test output what exactly is failing.
    • Philip Chimento's avatar
      build: Use Automake test driver with TAP output · 8feb2e49
      Philip Chimento authored
      For better integration with the build system and nicer output, use
      Automake's TAP driver and gtester's TAP output mode.
      There are a few things going on in this commit:
      - We don't put logs in test_user_data/logs anymore. That really assumed
        in the first place that all tests would be run serially, and we want
        them to be run in parallel. So we'll let Automake take care of the
        stderr and debug outputs and redirect them to a per-test log file.
      - We use the significant-to-Automake variable TESTS instead of
        TEST_PROGS. TESTS contains whatever is in check_PROGRAMS plus whatever
        else we put into it (our test script.)
      - TESTS_ENVIRONMENT is also significant to Automake, but should not be
        set within Automake, instead the AM_TESTS_ENVIRONMENT variable should
        be used so that the developer can override TESTS_ENVIRONMENT from the
        command line. This variable consists of a sequence of commands and
        needs to end with a semicolon. (So we can stuff XVFB_START in there
      - We need to put the test invocation in a separate script since gtester
        doesn't pass the --tap option on to its test binary.
  22. 22 Nov, 2016 1 commit
    • Philip Chimento's avatar
      build: Use dbus-run-session · 458100a9
      Philip Chimento authored
      DBus 1.8 gained a utility called dbus-run-session, that will run another
      program inside a new session bus and then shut down the session bus
      afterwards. This can replace the hand-rolled run-with-dbus script.
      Even though we started a fake system bus with run-with-dbus, I don't
      believe it was used. We also generated extra configuration files with
      which to start the buses, but I don't believe those were necessary
  23. 20 Oct, 2016 1 commit