Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
The check for _MSC_VER here is not necessary here because:
-One cannot compile GLib out-of-the-box with VS 2003 (let alone VS6
or earlier) since GLib 2.22.4 or so.
-This code compiles fine with the currently-supported VS versions
(2008/2010) without the error mentioned in the comments.
This will close Bug 652002.
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
From discussion, GVariantIter is not useful for bindings, but
GVariantBuilder may be.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
The grouping in files/headers is not used anymore, and
the function attributes neither. Adapt abicheck scripts
and .def file generation rules accordingly.
The hash table used exclusively for looking up types by name used to map
quarks => types. But we can easily make it map strings => types, which
avoids the quark lookup. And that in trun avoids taking a lock and
consulting another hash table. So this change should make
g_type_from_name() roughly twice as fast.
In some cases, signal arguments have to be collected, even if there are i
no signal handlers connected (e.g. for GVariant parameters, where collection
consumes a floating variant).
Based on a patch by Christian Persch.
Bug #643624.
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
I couldn't tell from reading the documentation whether I had to pass in
an uninitialized value, or a value initialized to the exact type, or
something else. It turns out (from reading the source) that you have to
pass in an initialized value, but you can use any type to which the
property's actual type can be transformed.
So, let's document this.
The code section guarded with toggle_refs_mutex includes a call to
g_object_unref(), which may call toggle_refs_notify(). As the latter
tries to acquire the same mutex, glib locks up.
https://bugzilla.gnome.org/show_bug.cgi?id=632884
Previously, dumping a GValue holding a GStrv just yielded "((GStrv *)
0xDEADBEEF)". I think it'd be more useful to dump a Python list-style
representation of the GStrv's contents, if it's not NULL.
Fixes: <https://bugzilla.gnome.org/show_bug.cgi?id=629192>
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
The gdatasetprivate.h header includes gatomic.h directly. It all works
well in GLib, but inside GObject it will trigger the single inclusion
guard.
Since this is a private header, and it's kind of a special case, one way
to fix it is to declare GLIB_COMPILATION around it and fool the single
inclusion guard in gatomic.h into thinking we're compiling GLib and not
GObject.
g_object_class_list_properties tries to sort the returned list of
paramspecs by 'type depth' and param_id. But all the overridden
interface properties have a param_id of 0, so they come out in
a random order.
Bug 628253.
The previous code dedup'd when thawing and threw nasty warnings your way
if you notified too often. This can now easily be avoided.
Performance should be roughly identical, as both are O(n²).
The g_object_bind_property_with_closures() function should set a
marshaller if the two GClosures don't have one already. This simplifies
the caller code and avoids duplication.
We need to add a new marshaller to the gmarshal.list matching the
signature of the GBindingTransformFunc function.
Since GSettings got the same functionality and flag in commit ca3b7b75b
GBinding should also have the ability to automatically invert a boolean
value without requiring a custom transformation function.
Since using the function pointer version muddles the memory management
requirements of language bindings, we should implement a GClosure-based
variant on top of g_object_bind_property_full().
https://bugzilla.gnome.org/show_bug.cgi?id=622278
This reverts commit 0201a81f04 and adds
locks in the right place.
As this file is a public header (see last commit), we cannot just remove
functions from it.
gobjectnotifyqueue.c is a public header, so we cannot remove files from
it. (Yes you read that right, this .c file is a public header. See your
installation directory.)
Adds locking around object property change notification handling. The
notifications are only emitted after all threads have called
g_object_thaw_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=166020
You can pass a NULL GValue * to any of g_value_array_insert, _prepend or
_append to add a new, uninitialized value. This is a very useful
shortcut, and it should be documented rather than left languishing in a
comment in the implementation.
Fixes Gnome bug #552363.
When creating a binding between two object properties we might want to
automatically synchronize the two values at the moment of the binding
creation, instead of waiting for the next change.
The G_BINDING_SYNC_CREATE flag does exactly what it says on the tin.
https://bugzilla.gnome.org/show_bug.cgi?id=622281
This is a minimal patch-out of the galias functionality. We will do a
release like this so that we can easily back it out if there are
reported problems.
A more substantial cleanup (mostly removing #includes from every file)
will follow if there are no issues.
Since an object instance might have a lot of bindings, using a list
might become a performance issue when removing them. Using a simple
hash table guarantees constant time lookup, which is the most common
operation.
GBinding is a simple, opaque object that represents a binding between a
property on a GObject instance (source) and property on another GObject
instance (target).
https://bugzilla.gnome.org/show_bug.cgi?id=348080
g_object_notify_by_pspec() will emit the "notify" signal on the given
pspec, short-circuiting the hash table lookup needed by
g_object_notify(). The suggested and documented way of using
g_object_notify_by_pspec() is similar to the way of emitting signals
with their ID.
Emission tests (with no handler attached to the notify signal) show a
10-15% speedup over using g_object_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=615425
This adds static markers and systemtap tapsets for:
* type creation
* object lifetimes (creation, ref, unref, dispose, finalize)
* signal creation and emission
Signal emissions and finalization marker have a corresponding
*_end (or *-end in dtrace) version that is when the corresponding
operation is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=606044
Add a @valuenum@ substitution that outputs the integer value of a
particular enum value. The value is determined by using (sandboxed)
perl to evaluate C expression. If evaluation fails then glib-mkenums
dies loudly. Evaluation is only enabled if '@valuenum@' appears in the
template file, so existing users will not be affected.
Currently, specifying a comment template in the template file results in
the given template being appended to the default (C-style) one rather
than replacing it.
This causes it to be replaced outright.
Bug 617940.
Don't keep the lists of source files for libglib, libgobject and
libgio in the VS project files in addition to the canonical location,
the corresponding Makefile.am files.
Instead, generate the corresponding .vcproj files at make dist time
using the C preprocessor, from template files called .vcprojin. We
still list explicitly in the .vcprojin files some of the
Windows-specific source files, and the sources files of gnulib and
pcre.
This adds the two new functions g_type_add_class_private()
and g_type_class_get_private() and a convenience macro
for the getter G_TYPE_CLASS_GET_PRIVATE().
Appease the MS C++ compiler by using _val instead of __value as a variable
name in G_VALUE_COLLECT_INIT.
Problem found by Haakon Sporsheim <haakon.sporsheim@gmail.com>.
Re-closes: bgo#608602
This way we don't need to keep a custom array that we bsearch on (and
that isn't threadsafe) but can use the gtype.c machinery that is
threadsafe. And fast, too!
https://bugzilla.gnome.org/show_bug.cgi?id=554887
This eases cleaning up these functions.
One optimization in value_set_internal() was lost in the process. It
shouldn't cause too many issues when all is said and done.
https://bugzilla.gnome.org/show_bug.cgi?id=554887
It makes the IBM XL C Compiler (the 'native' non-free compiler
on the AIX 5.3 and 6.1 platform) stop compiling with syntax error.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=581300
Signed-off-by: Javier Jardón <jjardon@gnome.org>
The reason we need to enforce this is that the GTypeValueTable
documentation explicitly states that memory is memset to 0 when the
value_init function is called.
https://bugzilla.gnome.org/show_bug.cgi?id=603590
