1. 30 Sep, 2016 10 commits
  2. 10 Feb, 2016 1 commit
    • Philip Chimento's avatar
      build: Untangle (AM_) CFLAGS, CPPFLAGS, CXXFLAGS · 0f92f6be
      Philip Chimento authored
      In Automake, CPPFLAGS stands for C PreProcessor flags. C source files are
      compiled with CPPFLAGS and CFLAGS, while C++ source files are compiled
      with CPPFLAGS and CXXFLAGS. The exception to this naming convention is
      the PKG_CHECK_MODULES macro which substs a variable named <FOO>_CFLAGS
      which should properly be called <FOO>_CPPFLAGS.
      This untangles all the flags definitions so that -I and -D flags, which
      are preprocessor arguments, are put into CPPFLAGS variables, not into
      CFLAGS or CXXFLAGS. Otherwise they won't apply to both C and C++ source
      In addition, when using per-target flags, make sure to include the AM_
      prefixed variable as well, because otherwise per-target flags will
      override it. Conversely, if an assignment sets a per-target flags variable
      to only be the AM_ prefixed variable (e.g., "something_CFLAGS =
      $(AM_CFLAGS)") then it is redundant.
  3. 23 Jun, 2015 1 commit
  4. 17 Jun, 2015 1 commit
    • Sam Spilsbury's avatar
      coverage: Serialize statistics to cache-path on cache misses · 84c8eded
      Sam Spilsbury authored
      Running Reflect.parse can take a non-trivial amount of time to run
      and this can scale poorly when several files are passed to gjs
      as "coverage eligible." Autotools makes this problem worse, because
      each individual script containing tests invokes gjs again which
      means that potentially hundreds of files can be parsed per test.
      This problem makes tests with coverage mode enabled run very slowly.
      This change re-organizes the way that information is stored from
      Reflect so that we can easily serialize and de-serialize that
      information to a binary file between invocations.
      1) The process of fetching statistics out of coverage.js and into
         coverage.cpp was separated out from print_statistics_for_file
         into fetch_coverage_file_statistics_from_js
      2) All statistics are fetched for all coverage-eligible files,
         instead of just the actually-run files (although the actually
         run files are the only ones printed in the report).
      3) The importer is made available in the coverage compartment so
         that we can use JSUnit assertions with it.
      4) Function "keys" are immediately calculated whenever a function
         is detected in coverage.js, as opposed to being post-processed
         afterwards. This means that we can cache the keys themselves
         and restore them directly, as opposed to re-computing them.
      5) A "deactivate" method was added to CoverageStatistics, which
         disables the debugger completely in that compartment (allowing
         context re-use in tests).
      6) Finally, in coverage.js we determine the function key at the
         function detection site and tests were re-written to use
         function keys instead of function names. This will allow
         us to easily fetch from the cache object with the keys
         pre-filled instead of having to recompute them.
      The caching logic was also added. Some important features are:
      1) Regular files are stored with their modification time, and
         information obtained from individual files is not restored
         if the current modification time is greater than the stored
      2) GResource paths are stored along with a sha512sum of their
         contents. This is slighlty more expensive than using mtimes,
         but mtimes are not available for GResourceFile's.
      3) A method "staleCache" was added to CoverageStatistics which
         indicates whether information was read from Reflect. If so,
         coverage.cpp will write out a new cache.
      4) The cache file itself is stored in .internal-gjs-coverage-cache.
      5) The caching process happens in gjs_serialize_statistics, which
         calls the stringify method on CoverageStatistics in Coverage.
         This method converts the entire representation of the currently
         collected and relevant AST information into a JSON blob,
         which is then written out to disk.
      6) Restoration from the cache happens in
         gjs_deserialize_cache_to_object, which uses JSON.parse to
         deserialize the stored JSON blob back into an internal
         representation we can query straight away.
      7) Some helper functions like gjs_run_in_coverage_compartment
         and gjs_inject_value_into_coverage_compartment were added
         as "internal" functions for the coverage mode. They are
         essentially just helper functions to allow tests to inject
         objects and code into the coverage.js compartment.
  5. 25 Nov, 2014 1 commit
  6. 25 Aug, 2014 1 commit
  7. 04 Mar, 2014 2 commits
  8. 24 Feb, 2014 1 commit
  9. 10 Feb, 2014 1 commit
    • Colin Walters's avatar
      Fix assertions during context dispose · be5c12c4
      Colin Walters authored
      The current toggle ref code has and assertion that we don't have a
      DOWN notification pending while the object is supposed to be live -
      and during normal operation, this is true.
      Except at context shutdown, we force the JS object to be destroyed,
      which can cause recursion into a dispose handler of a gobject, which
      can then queue a toggle down.  Then we later force dispose that
      object, and find the DOWN pending.
      Now, we could simply avoid all of this insanity by default and allow
      the kernel to clean up our state much faster, in a more power
      efficient way by simply not doing any of this...
      However, there are valid use cases for wanting "clean" exits, such as
      valgrind.  So this patch fixes things up for the dispose by iterating
      over the entire live object list before we drop into the JS context
      destruction, breaking the JS <-> C association.  This safely clears
      the toggle refs, so the JS side is just JS cleanup, we don't reenter
      GObject land.
      This will make several of the OSTree tests written using gjs start
      passing in Continuous again.  \o/
  10. 29 Jan, 2014 1 commit
    • Sam Spilsbury's avatar
      coverage: Add GjsCoverage · 7ef7d25d
      Sam Spilsbury authored
      GjsCoverage is a wrapper around coverage.js, a new module
      which uses the JS Debugger API and JS Reflect API to collect
      hits counts for lines, branches and functions.
      Pass -C or --coverage-path to specify a file that should be
      added to the coverage report. --coverage-output must also
      be passed when using these options and specifies a directory
      to write coverage reports to. This will copy the directory
      structure of covered files into this directory and generate
      an lcov compatible coverage report at coverage.lcov. This file
      will be opened in append-mode and should be deleted when coverage
      reports need to be regenerated.
  11. 15 Jan, 2014 1 commit
  12. 14 Jan, 2014 1 commit
  13. 10 Jan, 2014 1 commit
  14. 02 Jan, 2014 1 commit
  15. 29 Oct, 2013 1 commit
  16. 07 Jun, 2013 1 commit
  17. 23 May, 2013 1 commit
  18. 09 May, 2013 1 commit
  19. 07 May, 2013 1 commit
  20. 23 Apr, 2013 1 commit
  21. 07 Mar, 2013 1 commit
  22. 18 Jan, 2013 1 commit
  23. 07 Jan, 2013 1 commit
  24. 02 Jan, 2013 1 commit
  25. 01 Dec, 2012 2 commits
  26. 20 Nov, 2012 1 commit
    • Giovanni Campagna's avatar
      Rework dynamic class system · 349ea62c
      Giovanni Campagna authored
      Stop creating multiple JS classes on demand, and instead use the
      same JS class and create multiple constructors with different
      prototypes, but hand-rolling our own version of JS_InitClass, that
      also avoids polluting the global object.
      This means that JS_ConstructObject is no longer usable with dynamic
      classes, use gjs_construct_object_dynamic or JS_New instead.
  27. 13 Nov, 2012 1 commit
  28. 05 Nov, 2012 1 commit
  29. 07 Aug, 2012 1 commit
    • Giovanni Campagna's avatar
      Use a GTypeModule for registering custom types · 235a3c05
      Giovanni Campagna authored
      This makes so that the types are installed as dynamic types, and
      thus loaded and unloaded on demand. In particular, resources such
      as signal class closures are now properly released when the use count
      of these types drops to zero.
      Additionally, to avoid unloading too early, each GObject prototype
      has a now a reference on the GObjectClass. This means that the above
      only applies at context destruction, and preserves previous semantics
      wrt property and signal installation.