When g_irepository_find_by_gtype() doesn't succeed on a simple prefix
match (the current 'fastpass' mechanism), it ends up taking a
considerable amount of CPU time, traversing the contents of all typelibs.
I imagine that the reasons to have the exhaustive search fallback are
not as strong as they used to be. For example, the case mentioned
(Clutter including Cogl) no longer seems to be true.
Also, typelibs (as generated by g-ir-scanner) now provide
comma-separated C prefix info for cases when the typelib includes
introspection info for multiple prefixes. For example, the Sugar typelib
has a c_prefix string of Sugar,EggSM,Gsm,Acme. So I imagine there are
not many remaining justified cases where the exhaustive search is needed.
With that in mind, I found two ways to optimize this function:
1. Support comma-separated C prefixes
2. Don't bother with an exhaustive search if we did find a typelib
claiming support for the prefix. For example, if we're looking for
GdkDeviceManagerXI2 (currently non-introspectable) and we already found
typelib files providing the 'Gdk' prefix that didn't offer this, lets
not bother with the exhaustive search, we aren't going to find anything.
- add missing colons
- invalid annotations
- invalid parameters and tags
- correct parameter name
- preserve description indentation
- no description parts
- comment end marker
- invalid empty lines
- line numbers
AnnotationParser now emits warnings which are considered as
errors by "make check" so fix those warnings...
https://bugzilla.gnome.org/show_bug.cgi?id=672254
Otherwise, we fail to properly locate the typelibs, because on Windows
the value of GOBJECT_INTROSPECTION_LIBDIR depends on where Glib has been
installed. Due to the nature of how we handle software that depends on
Glib on Windows (it is recommended that each program bundles it's private
copy), we're working in a "multi-prefixed" environment. Hence the value
computed at build time will most likely not even exist at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
The previous ErrorDomain blob was never actually scanned or used, and
it was kind of a lame API conceptually.
To keep some compatibility, rather than removing the enumeration
values, rename them to _INVALID, and don't bump the typelib version.
This should in theory allow a new libgirepository to read an old
typelib.
Based on a patch from Colin Walters
https://bugzilla.gnome.org/show_bug.cgi?id=602516
Commit f97cc8687469f25752f79275 broke the lookup in
g_irepository_get_info; the passed offset is 0-based, then
we convert it to 1-based (and then back to 0 later...which needs
to be fixed).
This is a cleanup patch in preparation for future indexing
patches.
The lookup code was a mess trying to mash in the 3 different
cases of name, GType, and index into one mega-function.
Split it up properly, and move the core typelib internal-scanning
bits into gitypelib.c where it belongs.
Rather than have the scanner/parser handle both e.g. "glong" and
"long", simply use the GLib types everywhere.
This commit adds TYPE_LONG_LONG and TYPE_LONG_DOUBLE to the
scanner types; however, rather than add them to the typelib,
they're just marked as not-introspectable.
The reason for the warning was that g_irepository_get_version() expects
the typelib to be already loaded, but enumerate_version() can be called
on typelibs that are not.
Logically speaking, the already loaded version of a namespace is part of
the currently available versions, and can be forgotten if we only
consider the versions available in GI_TYPELIB_PATH, as it could have
been loaded using g_irepository_require_private().
As a side effect, it meant that bindings relying on enumerate_version()
(like pygobject) were not able to require private versions through their
classical requirement scheme.
This patch fixes it by adding the loaded version to the unsorted list of
available versions returned by g_irepository_enumerate_versions()
This patch also uses g_list_prepend() instead of g_list_append() in that
function.
https://bugzilla.gnome.org/show_bug.cgi?id=625983
We didn't show the right error message if we failed to find
the symbol; fix this by removing error printing from the
middle of the dumper, and add it correctly to the toplevel
dump entry point.
Entries in the GI_TYPELIB_PATH environment variable are added to the
global search path in reverse order - instead, add entries in the
same order in which they are specified.
Take a GError * for typelib loading code, validate the header. This
fixes bizarre errors from gjs where g_irepository_require would happily
load old typelibs.
Previously we had both e.g. GI_TYPE_TAG_LONG and GI_TYPE_TAG_INT64,
but in fact the typelib is already machine-specific, so it makes sense
to just encode this as a fixed type. The .gir remains abstract.
We also remove size_t from the typelib; one would never want to treat
it differently than an integer.
time_t is removed as well; while bindings like gjs had special handling
to turn it into e.g. a JS Date object, I don't think we should encourage
people to use these POSIX types in their API. Use GTimeVal or the like
instead.
Because the typelib is now really machine-specific, we need to remove
the -expected.tgirs from git. (We could potentially add a check
which wasn't just a literal diff later)
https://bugzilla.gnome.org/show_bug.cgi?id=623774
Use g_slice to allocate instead of g_new(x, 1); It uses a memory
pool internally and should be faster, especially for GBaseInfo/GRealInfo,
structs which are tiny.
It's was busted that g_typelib_new_* does the dlopen() since that caused
g-ir-compiler to load the modules even though it wasn't going to do
anything with them.
Instead, change things so that g_module_symbol does the dlopen on-demand.
Remove the extra dlopen(NULL) inside girepository.c, we had another
already in gtypelib.c.
Thanks to Owen Taylor for suggesting this approach.
Add type tags for short and ushort, plus all of the requisite code needed
to utilize them in libgirepository.
Add support in the scanner's AST files.
Add test functions to the everything library and the expected gir file.
gtypelib.c constant validation fixed by Colin Walters <walters@verbum.org>
Parse the c:prefix from the .gir, include it in the header. Armed with this
information, we can now optimize lookups of GTypes because we
have the requirement that GTypes must start with the c:prefix. We do
fall back though if a lookup fails.
We want the environment variable to override so that people can
easily write scripts that run their programs uninstalled.
svn path=/trunk/; revision=1024
The intended use of g_irepository_get_option_group is that your
application more transparently supports --introspection-dump; we
should exit so that your app doesn't continue trying to launch.
svn path=/trunk/; revision=1023
2008-12-10 Johan Bilien <jobi@via.ecp.fr>
Bug 563998 – Cache the GIBaseInfo for GTypes
* girepository/girepository.c (g_irepository_find_by_gtype):
add a cache of GType -> GIBaseInfo.
svn path=/trunk/; revision=991
