Commit Graph

16 Commits

Author SHA1 Message Date
Christian Persch
5ef34e5f11 resources: compiler: Fix resources on big endian architectures
Resources are always little endian, so the gvdb is byteswapped. When looking
up the value, it would return a new byteswapped variant, making the data
returned from do_lookup() invalid once that variant is unref'd. Since
byteswapping doesn't matter for the "ay" data anyway, just use
gvdb_table_get_raw_value() instead and only byteswap the length and flag
values.

https://bugzilla.gnome.org/show_bug.cgi?id=673409
2012-04-16 22:39:34 +02:00
Kalev Lember
e13fc58535 GResource docs: fix typo 2012-04-13 13:22:46 +03:00
Matthias Clasen
5ce66bed3d Formatting cleanup 2012-04-06 21:22:17 -04:00
Bastien Nocera
9b0734a09c all: s/availible/available/ 2012-03-27 11:01:00 +02:00
Christian Persch
30e0a1beac resources: Consolidate creation of GResource into one place 2012-02-05 19:57:10 +01:00
Christian Persch
877fe6fb52 resources: Init refcount to 1
This bug was exposed by fixing the following leak in the resources test:

==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204==    by 0x4084724: standard_malloc (gmem.c:85)
==29204==    by 0x40847C7: g_malloc (gmem.c:159)
==29204==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204==    by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204==    by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204==    by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204==    by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204==    by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204==    by 0x417C1DB: g_object_new (gobject.c:1535)
==29204==    by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204==    by 0x4228D38: g_resource_open_stream (gresource.c:363)
2012-02-05 19:57:10 +01:00
Christian Persch
30e9cccb85 resources: Plug a mem leak
==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 of 861
==29204==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204==    by 0x4084724: standard_malloc (gmem.c:85)
==29204==    by 0x40847C7: g_malloc (gmem.c:159)
==29204==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204==    by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204==    by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204==    by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204==    by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204==    by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204==    by 0x417C1DB: g_object_new (gobject.c:1535)
==29204==    by 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204==    by 0x4228DD8: g_resource_lookup_data (gresource.c:422)
2012-02-05 19:57:10 +01:00
Christian Persch
ffe7a3293f resources: Plug a mem leak
==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020==    by 0x4084724: standard_malloc (gmem.c:85)
==27020==    by 0x40847C7: g_malloc (gmem.c:159)
==27020==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020==    by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020==    by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020==    by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020==    by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020==    by 0x4228B36: do_lookup (gresource.c:280)
==27020==    by 0x4228F56: g_resource_get_info (gresource.c:492)
2012-02-05 19:57:09 +01:00
Christian Persch
fa37057169 resources: Plug a mem leak
==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427==    at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427==    by 0x4084724: standard_malloc (gmem.c:85)
==26427==    by 0x40847C7: g_malloc (gmem.c:159)
==26427==    by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427==    by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427==    by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427==    by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427==    by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427==    by 0x4228BA5: do_lookup (gresource.c:293)
==26427==    by 0x4228F51: g_resource_get_info (gresource.c:493)
2012-02-05 19:57:09 +01:00
Christian Persch
296a2a72c6 resources: compiler: Make to-pixbuf failure fatal
Bug #669123.
2012-02-02 23:44:38 +01:00
Alexander Larsson
47aa8c43e8 resources: Add to-pixdata preprocessing option 2012-01-31 16:07:09 +01:00
Alexander Larsson
b79cfda49c Make constructor-based resource registration malloc free
We need to do this because constructors run before main() and
thus before any call to g_mem_set_vtable, making it impossible to
use that function if constructors call g_malloc.

We do this by making the constructors just register the static data
for lazy registration, doing the lazy registration when using
the global resource set.
2012-01-31 10:51:44 +01:00
Alexander Larsson
2496c8b53e resources: Minor fixes to the docs 2012-01-31 10:51:23 +01:00
Christian Persch
45783c5927 resources: compiler: Allow stripping blanks from xml data
It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.

Bug #667929.
2012-01-25 14:47:37 +01:00
Alexander Larsson
feb120eb40 Fix typo
registred_resources -> registered_resources
2012-01-16 10:38:35 +01:00
Alexander Larsson
b87cf49163 Initial version of GResource
GResource is a bundle of files combined into a single binary blog.
The API lets you access the files the resource contains by
using resource paths. You can also register resources with a
global list and access these globally in a merged resource namespace.

The normal way this is used is to link in the resources into your
application/library and have it be automatically registred.

Resources are compiled from an xml description using
glib-compile-resources.
2012-01-13 17:12:45 +01:00