1. 27 Feb, 2015 2 commits
  2. 26 Feb, 2015 1 commit
  3. 20 Feb, 2015 1 commit
  4. 11 Feb, 2015 1 commit
  5. 08 Feb, 2015 1 commit
  6. 06 Feb, 2015 1 commit
  7. 05 Feb, 2015 1 commit
  8. 04 Feb, 2015 1 commit
  9. 03 Feb, 2015 2 commits
  10. 02 Feb, 2015 1 commit
  11. 30 Jan, 2015 4 commits
  12. 28 Jan, 2015 1 commit
  13. 27 Jan, 2015 1 commit
  14. 25 Jan, 2015 1 commit
  15. 18 Dec, 2014 2 commits
    • Thomas Haller's avatar
      gobject: don't use G_STRLOC in G_OBJECT_WARN_INVALID_PSPEC() macro · c447bc7f
      Thomas Haller authored
      Using G_STRLOC ends up embedding unique strings of the form
      __FILE__:__LINE__ in the compiled binary. We can avoid these
      by passing __FILE__ and __LINE__ separately when constructing
      the warning text.
      This probably reduces the size of the binary as __FILE__ is
      likely already contained as string otherwise.
      
      Note that for GCC 2.x this changes behavior because G_STRLOC
      also contained __PRETTY_FUNCTION__.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741654
      c447bc7f
    • Philip Withnall's avatar
      gobject: Add g_set_object() convenience function to set GObject pointers · d951db42
      Philip Withnall authored
      Along the same lines as g_clear_object(), g_set_object() is a
      convenience function to update a GObject pointer, handling reference
      counting transparently and correctly.
      
      Specifically, it handles the case where a pointer is set to its current
      value. If handled naïvely, that could result in the object instance
      being finalised. In the following code, that happens when
      (my_obj == new_value) and the object has a single reference:
          g_clear_object (&my_obj);
          my_obj = g_object_ref (new_value);
      
      It also simplifies boilerplate code such as set_property()
      implementations, which are otherwise long and boring.
      
      Test cases included.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741589
      d951db42
  16. 28 Nov, 2014 1 commit
  17. 23 Nov, 2014 1 commit
  18. 10 Nov, 2014 1 commit
  19. 11 Oct, 2014 3 commits
  20. 08 Aug, 2014 2 commits
  21. 30 Jul, 2014 1 commit
    • Alexander Larsson's avatar
      Remove atomics from g_clear_object/g_clear_pointer · b1dd594a
      Alexander Larsson authored
      Practically no caller of these functions require atomic behaviour,
      but the atomics are much slower than normal operations, which makes
      it desirable to get rid of them. We have not done this before because
      that would be a break of the ABI.
      
      However, I recently looked into this and it seems that even if the
      atomics *are* used for g_clear_* it is not ever safe to use this.  The
      atomics protects two threads that are racing to free a global/shared
      object from freeing the object twice. However, any *user* of the global
      object have no protection from the object being freed while in use,
      because there is no paired operation the reads and refs the object
      as an atomic unit (nor can such an operation be implemented using
      purely atomic ops).
      
      So, since nothing could safely have used the atomic aspects of these
      functions I consider it acceptable to just remove it.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=733969
      b1dd594a
  22. 10 Jul, 2014 1 commit
  23. 06 Jul, 2014 1 commit
  24. 28 Jun, 2014 2 commits
  25. 27 Jun, 2014 1 commit
  26. 25 Jun, 2014 1 commit
  27. 24 Jun, 2014 2 commits
  28. 23 Jun, 2014 1 commit
  29. 22 Jun, 2014 1 commit