On Thu, Dec 30, 2010 at 06:46:40PM +0100, Abderrahim Kitouni wrote:
> Hi,
> What I tried to do to test this is to run vala's tests with the new
> vapi, I found some problems (the tests still don't compile, but that's
> probably the hard task: once they compile it would be trivial to fix any
> crashes):
Thanks a lot for testing :)
> 1) Gio-2.0.gir contains both gio-2.0 and gio-unix-2.0 (filedescriptor
> test uses both). So the assumption that there is a one-to-many
> replationship doesn't hold :-(
That is a big... big problem. The only solution I can think of is creating
two different metadata, one will hide gio-unix-2.0 symbols to create
gio-2.0.vapi and the other one will hide gio-2.0 symbols to generate
gio-unix-2.0. A total mess.
> 2) ByteArray isn't supported, so this
>
> <property name="path-as-array"
> writable="1"
> construct-only="1"
> transfer-ownership="none">
> <array name="GLib.ByteArray">
> <type name="gpointer" c:type="gpointer"/>
> </array>
> </property>
>
> is mapped to :
> public void*[] path_as_array { owned get; construct; }
> which valac can't even parse (this is with glib master as of December
> 25th, not the gir you suggested).
Fixed thanks.
> 3) InputStream.read takes void* buffer, size_t count instead of uint8[]
> buffer
Fixed, marked as upstream bug in the metadata.
> 4) when manually fixing the above (replacing gio-unix-2.0.vapi with an
> empty file, deleting the unparsable properties, and fixing read), there
> is still problems with the generated code (related to gio-unix), but the
> fact it got there (there seems to be only 2 tests after filedescriptor),
> I think it's in relatively good shape :-)
Yes it's in good shape but gio-unix will make us crazy for sure.
> Another thing that annoys me is ref/unref/free functions that aren't
> hidden (plus the ugly CCode annotations that use g_boxed_* and
> *_get_type). I know this is bug 572415, but maybe vapigen can second
> guess the g-i scanner?
On IRC we discussed the fact that it's safer to keep it as is. It may be a
little inconvenient to keep it Compact, but it might be less safe to promote
it to non-Compact. Anyway g_boxed_copy/g_boxed_free should be registered
with _ref/_unref so that it's compatible. The non-Gobject light ref counted
class is a problem but it's safer to threat it as a struct. Let's see in the future.
--
http://www.debian.org - The Universal Operating System
Attachment:
signature.asc
Description: Digital signature