1. 13 Nov, 2018 4 commits
  2. 12 Nov, 2018 9 commits
    • Philip Chimento's avatar
      release: Prepare for 1.54.3 · 7d5e567b
      Philip Chimento authored
    • Philip Chimento's avatar
      build: Stable branch version bump · a011deca
      Philip Chimento authored
    • Philip Chimento's avatar
      object: Fix build with --enable-dtrace · c5698eab
      Philip Chimento authored
      We don't build with this option very often, so this has been broken for a
      Closes: #196
    • Marco Trevisan's avatar
    • Marco Trevisan's avatar
      object: add reference to the property pspec we cache · 0f77ebd6
      Marco Trevisan authored
      When caching the properties param specs we get them from the class object, which
      is currently owning them, however since we're caching them we should add a
      reference to them in order to keep the ownership and clean them up properly
      when the cache is destroyed
      Fixes GNOME/gjs#213
    • Marco Trevisan's avatar
      jsapi-util: add ability to ref added GjsAutoParam · ecd7e786
      Marco Trevisan authored
      Add an overloaded method to initialize a GjsAutoParam with with a reffed pspec.
      This helps to ref param specs we're consuming.
      Fixes GNOME/gjs#213
    • Philip Chimento's avatar
      arg: Handle case with null array and garbage length · 2190ed7d
      Philip Chimento authored
      It happens sometimes in the case of an array out argument with a
      separate length argument, that C code passess a NULL array pointer with
      garbage as the length.
      In the particular case that caused the crash in the associated bug
      report, gtk_selection_data_get_targets() passed NULL as the array
      pointer and -1 as the length, which later got interpreted as an unsigned
      int and so caused a failure to allocate memory.
      I doubt that the C code should be doing this, but in any case we should
      not crash in this case. This adds a check for this situation to
      gjs_array_from_carray_internal() as well as to all the shortcuts and
      special cases called from there.
      Closes: #201
    • Andrea Azzarone's avatar
      engine: mozjs60 changes for GC sweeping tracking · d4fe34a2
      Andrea Azzarone authored
      With the switch to mozjs60, the sweeping happens in three phases insted of two:
      Update the code to keep track of whether the runtime is currently doing GC
      sweeping, and prevent calling JS code at that time.
      Fixes: GNOME/gjs#212
    • Philip Chimento's avatar
      object: Fix write-only properties · 9f53812a
      Philip Chimento authored
      Since the property refactor, write-only properties have not been working.
      The problem was that a getter and setter function were not defined for
      them, because is_gobject_property_name() did not consider them to be
      properties. Now, the setter function works as normal while the getter
      function just pretends a write-only property has the value of undefined.
      The test is marked pending until a test is added to the
      gobject-introspection test suite.
  3. 02 Nov, 2018 8 commits
  4. 22 Oct, 2018 3 commits
  5. 10 Oct, 2018 1 commit
  6. 08 Oct, 2018 6 commits
    • Marco Trevisan's avatar
      context: use timeout with seconds to schedule a gc trigger · e3f6208a
      Marco Trevisan authored
      We can use lower granularity as we care about seconds anyway
    • Daniel van Vugt's avatar
      context: Defer and therefore batch forced GC runs · c281d9c2
      Daniel van Vugt authored
      Since commit e9e96955, forced GC runs get queued very often in some
      cases. For example, during the gnome-shell icon spring animation around
      60% of gnome-shell's CPU time was spent in `trigger_gc_if_needed`.
      That's too much.
      We now defer the forced GC runs by 10 seconds, which provides two
      significant performance benefits:
        1. Animations triggering garbage collection are unlikely to have their
           performance adversely affected by the run because the animation
           will be finished before it starts.
        2. The total number of garbage collection runs is much lower because
           they're more likely to have been batched into the same run.
      This has the observed benefit, for example, of reducing the CPU usage
      of the gnome-shell icon spring animation from 78% to 47% on an i7-7700
      (a 40% relative reduction).
      Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/582
    • Philip Chimento's avatar
      tests: Don't time-limit the unit tests · 358a9797
      Philip Chimento authored
      Previously there was code that would intentionally crash if more than 7
      minutes elapsed, in case the tests got stuck on autobuilders. This code
      is more harmful than helpful, see the following table:
        Times it has killed a stuck test on GitLab: . . . . . . . . 0
        Times it has killed a JS_GC_ZEAL test:  . . . . . . . . .  34
        Times it has killed my GDB session because I forgot
          to add the stupid environment variable: . . . . . . . . 478
    • Philip Chimento's avatar
      build: Remove useless pkgconfig check · 7e9e35ee
      Philip Chimento authored
      This was necessary because some test code used to use GUnixOutputStream,
      but it no longer does.
    • Philip Chimento's avatar
      tools: Update clang-format scripts · a3e11762
      Philip Chimento authored
      A few bugs have been fixed upstream.
    • Philip Chimento's avatar
      build: Remove apostrophe from conftest program · cf56080b
      Philip Chimento authored
      I noticed that this apostrophe causes a warning while compiling the
      conftest program. The text of this error message really doesn't matter,
      so just remove the apostrophe.
  7. 05 Oct, 2018 5 commits
    • Simon McVittie's avatar
      1.54.1-1 · a8b29f9d
      Simon McVittie authored
    • Simon McVittie's avatar
      New upstream release · 4a5b44cd
      Simon McVittie authored
    • Simon McVittie's avatar
      Update upstream source from tag 'upstream/1.54.1' · af11d0c4
      Simon McVittie authored
      Update to upstream version '1.54.1'
      with Debian dir 1c19ecf34678411381e77be91e9a251f980b6011
    • Simon McVittie's avatar
      New upstream version 1.54.1 · 69c874a7
      Simon McVittie authored
    • Simon McVittie's avatar
      Revert "Update library provides to libgjs0-libmozjs-60-0" · 69391987
      Simon McVittie authored
      The Provides on libgjs0-libmozjs-52-0 is counterintuitive but
      intentional. It's there to avoid needing a transition in which every
      dependent package is rebuilt, which is not actually necessary any more.
      In historical versions of gjs, the gjs-internals module exposed mozjs
      ABI as gjs ABI, and was used by at least GNOME Shell. As a result, the
      upstream developers should ideally have bumped the SONAME every time they
      upgraded to a new, incompatible version of mozjs; but because it wasn't,
      we worked around this with package names like libgjs0a, libgjs0b, ...,
      libgjs0g, and per-ABI virtual package names like libgjs0-libmozjs-38-0,
      with gjs' shlibs generating a dependency on both.
      The gjs-internals module was removed by upstream commit d3e2f861 between
      versions 1.46.x and 1.47.0, in 2016. From that point on, libgjs can
      more or less be treated like an ordinary library: there are no longer
      any public symbols that expose mozjs ABI, and an application compiled
      against one version can run with any later version (as long as it does
      not make use of Mozilla-specific JavaScript syntaxes that has been
      removed from mozjs, but a rebuild wouldn't fix or even detect that,
      so versioned Breaks seem like a better tool to deal with it).
      When we updated to gjs (>= 1.47) and libgjs0f/libgjs0g in 2017, nobody
      noticed that libgjs no longer has any public symbols that expose mozjs
      ABI, so we assumed that the virtual packages were still necessary.  As a
      result, the shlibs continued to generate a dependency on the virtual
      package libgjs0-libmozjs-52-0, and packages like gnome-shell and polari
      now depend on that virtual package. To avoid needing to rebuild dependent
      packages immediately and do a full transition, we continue to provide
      it from this version: the justification is that this new libgjs has the
      same ABI as the one that was built using mozjs52, even though it now
      uses mozjs60.
      The new shlibs file does not generate a dependency on the virtual package,
      so we do not need a libgjs0-libmozjs-60-0 virtual package, and packages
      that have been rebuilt against gjs 1.54.x will simply have "Depends:
      libgjs0g (>= 1.54.0)" like any other shared library; the only relic of
      the package's unfortunate history is that the shared library package
      name is libgjs0g, not the expected libgjs0.
      If distros' release teams want to rebuild dependent packages anyway, the
      rule that could be used for that transition would be something along the
      lines of this ben file:
          Affected: .depends ~ "libgjs0g"
          Good: !.depends ~ /\blibgjs0-libmozjs-/
          Bad: .depends ~ "libgjs0-libmozjs-52-0"
      After that transition has completed, the libgjs0-libmozjs-52-0 Provides
      could be removed from libgjs0g. However, this is not critical-path and
      does not block the migration of gjs.
      See debian/changelog for earlier attempts to document this situation.
      This reverts commit 78055b78.
  8. 04 Oct, 2018 1 commit
  9. 24 Sep, 2018 3 commits