1. 18 Nov, 2020 3 commits
  2. 27 Oct, 2020 6 commits
  3. 26 Oct, 2020 2 commits
  4. 23 Oct, 2020 1 commit
  5. 22 Oct, 2020 8 commits
    • Michael Catanzaro's avatar
      Fix 32-bit build · f19e67b3
      Michael Catanzaro authored
      Problem is that each separate 'if constexpr' block needs to evaluate to
      the same return type. The first block returns GType (long unsigned int).
      On x86_64, the second block returns uint64_t (long unsigned int), and
      everything is fine. But on i686, the second block instead returns
      uint32_t (unsigned int). The types are different, and the build fails.
      It doesn't matter that long unsigned int and unsigned int are the same
      size on i686: they are different types, so it fails anyway.
      I learned a few things about types when working on this. Vanilla int and
      unsigned int are always 32 bits on Linux (not surprising), and long long
      int and unsigned long long int are always 64 bits (also not surprising).
      But I had never previously learned the rule for long int and unsigned
      long int. Turns out it matches word size, so long is 64 bits on x86_64
      but 32 bits on i686. That's interesting.
      I also learned that GType is always long unsigned int in C++. In C, it
      is long unsigned int on 64-bit architectures, but it is gsize (size_t)
      on 32-bit architectures. That's right, on 32-bit systems, the size of
      GType differs based on what programming language you use! I guess if
      there are no explosions in practice, and nobody registers more than
      four billion types per process, it must be OK?
      Thanks to Abderrahim for preparing an earlier version of this fix, and
      to both Abderrahim and Jordan for helping me with BuildStream to do an
      i686 build.
      Fixes #357
    • Marco Trevisan's avatar
    • Marco Trevisan's avatar
      arg-cache: Save unsigned state as argument flag, sharing the bit with FILENAME · 8d42570e
      Marco Trevisan authored
      There won't be any case in which a string can be unsigned, or when a
      number is a filename, so we can reuse the same bit safely.
    • Marco Trevisan's avatar
    • Marco Trevisan's avatar
      gi: Support caller-allocates GValue arguments · 3500148f
      Marco Trevisan authored
      When we were handling a GValue caller-allocates argument we actually
      were changing a new temporary GArgument copy that we actually didn't end
      up passing to the function that was changing it.
      To ensure that this doesn't happen:
       - When a caller-allocates argument is passed to a function, use the
         actual GIArgument pointer and not deference it.
       - Include an argument flag that can be used at conversion time to make
         clear that we're working on the actual caller allocated argument and
         not in a gjs copy of it.
       - When converting a JSValue to GValue, act on the caller allocated
         (possibly by arg-cache) memory, instead of setting a new GValue.
      As per this we can enable the `vfunc_caller_allocated_out_parameter`
      test now.
      This doesn't seem enough to fix GNOME/gjs#74 testcase though as the gtk
      introspection doesn't give us enough information about being
    • Marco Trevisan's avatar
      arg: Use argument flags for the gjs conversion functions · 95f83e59
      Marco Trevisan authored
      Make arguments more readable and easier to extend when it comes to pass
      flags to such functions, instead of rely on hard-to-maintain booleans.
      Using an enum class that needs some more redefinitions but gives more
      type safety, as per this adding a enum-utils.h header with some smarter
      templated definitions for operators that match all the enum class types.
      We automatically define operators for Enum class (only if strongly typed)
      types, just include this header and the magic will happen now.
      Internally using a wrapper struct to wrap the return values so that we
      can define the bool() operator and so no need to use the !! operator
      anymore for simple true checks.
    • verdre's avatar
      gi/wrapperutils: Move gjs_get_string_id() into resolve() implementations · 6aec0972
      verdre authored
      Calling gjs_get_string_id() allocates a string, which can be quite
      expensive and should be avoided in hot-paths. There are some resolve()
      implementations which don't need the prop_name string and can return
      without it, most notably the implementation of ObjectPrototype, which
      has an unresolvable cache. If we hit that cache, there's no need to
      create the string.
      So move the call to gjs_get_string_id() into the implementations of
      resolve() and make sure ObjectPrototype::resolve() avoids calling it in
      case we hit the unresolvable cache.
    • verdre's avatar
      Revert "arg-cache: Save space by not caching GType" · d526bf89
      verdre authored
      As found in GNOME/gjs#361, getting the
      GType using g_registered_type_info_get_g_type() is very expensive and
      can make up for a significant part of the overhead when calling into a C
      Since the argument cache seems to be fairly small in a typical
      gnome-shell session (about 1300 entries), the total increased memory
      usage of about 10kB seems very reasonable given the benefits of the
      This reverts commit adfb7dc3.
  6. 20 Oct, 2020 2 commits
    • Marco Trevisan's avatar
      Use standard allocator for JS private data · 3aa7c428
      Marco Trevisan authored
      It will allows to get memory counters working
      Also requires initializing all the private data structs in their
    • Marco Trevisan's avatar
      wrapperutils: Use native C++ allocation and deletion for wrappers · 6d90b3fc
      Marco Trevisan authored
      When allocating a wrapped object we've some unnecessarily complicated
      initializiation logic, where we initially allocate the memory (zero-ing
      it) and then calling the constructor for the allocated memory.
      The same process is repeatead (in inverted order) when deallocating it.
      While this may have the benefit of zero-ing the memory for us, it's just
      unncessary as C++ constructors and destructors can handle this for us,
      and we can avoid duplicate writes on the same memory space, leaving the
      initialization fully to the constructors.
      So, using simple new/delete and adjusting the few places where we didn't
      initialize the private flags at construction.
  7. 15 Oct, 2020 2 commits
  8. 14 Oct, 2020 5 commits
  9. 13 Oct, 2020 11 commits