1. 11 Feb, 2019 1 commit
  2. 08 Oct, 2018 1 commit
  3. 01 Sep, 2018 2 commits
  4. 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.
  5. 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
  6. 18 Jul, 2018 1 commit
  7. 16 Apr, 2018 1 commit
  8. 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.
  9. 27 Mar, 2018 1 commit
  10. 05 Dec, 2017 1 commit
  11. 01 Dec, 2017 1 commit
  12. 31 Oct, 2017 1 commit
  13. 05 Oct, 2017 2 commits
  14. 02 Oct, 2017 1 commit
  15. 01 Sep, 2017 5 commits
  16. 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.
  17. 11 May, 2017 2 commits
  18. 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.)
  19. 14 Jan, 2017 1 commit
  20. 13 Jan, 2017 1 commit
  21. 03 Jan, 2017 1 commit
  22. 28 Dec, 2016 5 commits
  23. 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.
  24. 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.
  25. 30 Nov, 2016 1 commit
    • 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.