[Vala] Asynchronous construction
Hi,
trying to make the gfreenect [1] library work with Vala and in
particular to deal with the missing asynchronous constructor support I
was running into some issues. The vapi [2] is generated from GIR.
The corresponding code in C is pretty straight forward and would
look like this:
static void on_new_kinect_device ( GObject *obj,
GAsyncResult *res,
gpointer user_data)
{
kinect = gfreenect_device_new_finish (res, error);
if (kinect == NULL)
{
g_debug (Failed to created kinect device: %s, error-message);
g_error_free (error);
clutter_main_quit ();
return;
}
g_debug (Kinect device created!);
int main (int argc, char *argv[])
{
gfreenect_device_new (0,
GFREENECT_SUBDEVICE_CAMERA,
NULL,
on_new_kinect_device,
NULL);
clutter_main ();
return 0;
}
Trying to implement that in Vala, I took the approach below.
It seems however, that the init_async does not work. Looking at the
generated C-Code it looks like the g_async_initable_init_finish method
is called right after init_async an not with in the callback as expected.
As a result the code is crashing in the underlying libusb due to
incorrect initialization.
What am I missing here? Any idea how to solve the issue.
thanks and sorry for the lengthy post,
--tomw
-
using GLib;
using GFreenect;
public class Main : Object
{
public GFreenect.Device device;
public Cancellable cancellable;
public Main () {
Cancellable cancellable = new Cancellable ();
}
public async void run (out Device dev) {
debug (Starting);
Device device = (Device) GLib.Object.@new (
typeof (Device),
index, 0,
subdevices, Subdevice.CAMERA
);
debug (Device created);
Idle.add (run.callback);
try {
debug (Trying to run init_async);
bool re = yield device.init_async (Priority.DEFAULT,
cancellable);
if (re) {
debug (Result = OK);
} else {
debug (Result = FAILED);
}
} catch (Error e) {
debug (Error initalizing device : %s, e.message);
}
}
public void callback (Main? source, GLib.AsyncResult? res, void* user_data) {
debug (Entering Callback);
Device dev;
if (res != null) {
source.run.end (res, out dev);
debug (Callback called - Device created);
try {
Device kinect = new dev.finish(res);
} catch (Error e) {
debug (Error finalizing device : %s, e.message);
}
} else {
debug (No result delivered);
}
}
static int main (string[] args) {
var loop = new MainLoop ();
var app = new Main ();
app.run.begin ((AsyncReadyCallback)callback);
loop.run ();
return 0;
}
}
[1] https://gitorious.org/gfreenect
[2] http://pastebin.com/xdXKCmWR
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Asynchronous construction
Hi,
[Freenect C init sample ]
Trying to implement that in Vala, I took the approach below.
It seems however, that the init_async does not work. Looking at the
generated C-Code it looks like the g_async_initable_init_finish method
is called right after init_async an not with in the callback as expected.
As a result the code is crashing in the underlying libusb due to
incorrect initialization.
What am I missing here? Any idea how to solve the issue.
thanks and sorry for the lengthy post,
--tomw
-
using GLib;
using GFreenect;
public class Main : Object
{
public GFreenect.Device device;
public Cancellable cancellable;
public Main () {
Cancellable cancellable = new Cancellable ();
}
public async void run (out Device dev) {
debug (Starting);
Device device = (Device) GLib.Object.@new (
typeof (Device),
index, 0,
subdevices, Subdevice.CAMERA
);
debug (Device created);
Idle.add (run.callback);
^^ No need for this since you're using yield in the function. Might
actually be harmful, causing a race between the init_async you call and
the one Vala calls implicitly.
try {
debug (Trying to run init_async);
bool re = yield device.init_async (Priority.DEFAULT,
cancellable);
^^ this yield returns to main loop and once init_async calls its
call-back will call init_finish for you. So after this line the device
is initialized.
if (re) {
debug (Result = OK);
} else {
debug (Result = FAILED);
}
} catch (Error e) {
debug (Error initalizing device : %s, e.message);
}
}
public void callback (Main? source, GLib.AsyncResult? res, void*
user_data) {
debug (Entering Callback);
Device dev;
if (res != null) {
source.run.end (res, out dev);
debug (Callback called - Device created);
try {
Device kinect = new dev.finish(res);
^^ And here you're basically trying to create another device.
} catch (Error e) {
debug (Error finalizing device : %s, e.message);
}
} else {
debug (No result delivered);
}
}
I would do it like this:
using GLib;
using GFreenect;
public class Main : Object
{
public GFreenect.Device device;
public Cancellable cancellable;
public Main () {
Cancellable cancellable = new Cancellable ();
}
public async void run () {
debug (Starting);
Device device = (Device) GLib.Object.@new (
typeof (Device),
index, 0,
subdevices, Subdevice.CAMERA
);
debug (Device created);
try {
debug (Trying to run init_async);
bool re = yield device.init_async (Priority.DEFAULT,
cancellable);
// start using the device
} catch (Error e) {
// re will always be true in the try block if you always get an
error
// when it's false, because you end up here anyway.
debug (Error initalizing device : %s, e.message);
}
}
static int main (string[] args) {
var loop = new MainLoop ();
var app = new Main ();
app.run.begin ();
loop.run ();
return 0;
}
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Asynchronous construction
On Di, 2012-03-27 at 11:59 +0200, Jens Georg wrote:
try {
debug (Trying to run init_async);
bool re = yield device.init_async (Priority.DEFAULT,
cancellable);
^^ this yield returns to main loop and once init_async calls its
call-back will call init_finish for you. So after this line the device
is initialized.
Thanks,
I'm afraid that the statement above is just initializing a new device
instance, which (according to gfreenect) can only be used after
gfreenect_device_new_finish () is called like in the C example. This is
why I was trying to create a finished instance in the callback. As the
code is still crashing in libusb - Is there a way to get the callback
called rather than the implicit init_finish being called from
init_async?
--tomw
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Asynchronous construction
On Di, 2012-03-27 at 12:24 +0200, tomw wrote:
On Di, 2012-03-27 at 11:59 +0200, Jens Georg wrote:
try {
debug (Trying to run init_async);
bool re = yield device.init_async (Priority.DEFAULT,
cancellable);
^^ this yield returns to main loop and once init_async calls its
call-back will call init_finish for you. So after this line the device
is initialized.
Thanks,
I'm afraid that the statement above is just initializing a new device
instance, which (according to gfreenect) can only be used after
gfreenect_device_new_finish () is called like in the C example. This is
why I was trying to create a finished instance in the callback. As the
code is still crashing in libusb - Is there a way to get the callback
called rather than the implicit init_finish being called from
init_async?
gfreenect_device_new_finished is just calling _async_initable_new_finish
which calls async_initable_finish, same for _device_new. Removing the
subdevices property stops the crashing here. looking at the gfreenect
code that isn't used at all:
https://github.com/elima/GFreenect/blob/master/gfreenect/gfreenect-device.c#L1150
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Asynchronous construction
gfreenect_device_new_finished is just calling _async_initable_new_finish which calls async_initable_finish, same for _device_new. Removing the subdevices property stops the crashing here. looking at the gfreenect code that isn't used at all: https://github.com/elima/GFreenect/blob/master/gfreenect/gfreenect-device.c#L1150 Thanks, indeed. It works. The reason is kind of strange though as this parameter is used in C and Python examples. I was suspecting bindings and a lot of other things but I would not think of a parameter like this... many thanks, --tomw ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] vapigen and Autotools problem
Hi, vala-list. Before anything else, I have to say I'm new to Vala and also to vapigen usage. I've been working on a library which uses GObject and GTK + and is written in C, now other developers are going to use this library to write an application, but they will do it using Vala, so I'm currently binding it using GObjectIntrospecton and vapigen, both integrated with the GNU Autotools. The directory structure of the library is composed by 4 directories, each of which contains an alredy generated .gir file. I've managed to integrate GObjectInstrospection in the project, and right now I'm dealing with vapigen (whose documentation about integration with Autotools doesn't exist, currently). The 4 directories have an horizontal dependency so the .gir of the first one is needed to generate the .gir (and .vapi) of the next one and so on with all of them, all being in the same level of the build tree. To generate the .girs I've used the --include-uninstalled option to include the previously generated .gir file of the project. Now, when the build system tries to run vapigen to generate a .vapi that depends on another part of the library, it fails. The call to vapigen is something like this: $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir The .vapi file of the gvn package is alredy generated (and put in the directory specified via the --vapidir option) at this point, as well as the .gir of the current package. And this is the error it produces: error: Package `Gvn-0.1' not found in specified Vala API directories or GObject-Introspection GIR directories I guess it has something to do with the package not being installed, but I couldn't find a way to tell it to vapigen. However that's just a guess, so I don't really know what i'm doing wrong and/or how to solve this. Can anyone help me with it? Thanks in advance! Regards, Alex PS: sorry if my english is a mess, if something is not clear tell me and I'll try to rewrite it. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
August, I just didn't know that. Reading the documentation and looking at an official gnome project (GDA, that does the same thing I was trying to do) I though it was the only way to bind C to Vala. And the other developers I mentioned are using Vala by the first time, too. If I can do this that way I'll save some time! Can you give me some reference to that method? Thanks! Alex El 27 de marzo de 2012 16:48, august aug...@alien.mur.at escribió: Alejandro, Is there a reason to create a .vapi file? Couldn't your vala developers just use the .gir file? AFAIK, that is the preferred method for binding to vala if you are already writing gobject libs. -august. Hi, vala-list. Before anything else, I have to say I'm new to Vala and also to vapigen usage. I've been working on a library which uses GObject and GTK + and is written in C, now other developers are going to use this library to write an application, but they will do it using Vala, so I'm currently binding it using GObjectIntrospecton and vapigen, both integrated with the GNU Autotools. The directory structure of the library is composed by 4 directories, each of which contains an alredy generated .gir file. I've managed to integrate GObjectInstrospection in the project, and right now I'm dealing with vapigen (whose documentation about integration with Autotools doesn't exist, currently). The 4 directories have an horizontal dependency so the .gir of the first one is needed to generate the .gir (and .vapi) of the next one and so on with all of them, all being in the same level of the build tree. To generate the .girs I've used the --include-uninstalled option to include the previously generated .gir file of the project. Now, when the build system tries to run vapigen to generate a .vapi that depends on another part of the library, it fails. The call to vapigen is something like this: $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir The .vapi file of the gvn package is alredy generated (and put in the directory specified via the --vapidir option) at this point, as well as the .gir of the current package. And this is the error it produces: error: Package `Gvn-0.1' not found in specified Vala API directories or GObject-Introspection GIR directories I guess it has something to do with the package not being installed, but I couldn't find a way to tell it to vapigen. However that's just a guess, so I don't really know what i'm doing wrong and/or how to solve this. Can anyone help me with it? Thanks in advance! Regards, Alex PS: sorry if my english is a mess, if something is not clear tell me and I'll try to rewrite it. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list -- http://aug.ment.org GPG: 0A8D 2BC7 243D 57D0 469D 9736 C557 458F 003E 6952 ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
Alejandro, Is there a reason to create a .vapi file? Couldn't your vala developers just use the .gir file? AFAIK, that is the preferred method for binding to vala if you are already writing gobject libs. -august. Hi, vala-list. Before anything else, I have to say I'm new to Vala and also to vapigen usage. I've been working on a library which uses GObject and GTK + and is written in C, now other developers are going to use this library to write an application, but they will do it using Vala, so I'm currently binding it using GObjectIntrospecton and vapigen, both integrated with the GNU Autotools. The directory structure of the library is composed by 4 directories, each of which contains an alredy generated .gir file. I've managed to integrate GObjectInstrospection in the project, and right now I'm dealing with vapigen (whose documentation about integration with Autotools doesn't exist, currently). The 4 directories have an horizontal dependency so the .gir of the first one is needed to generate the .gir (and .vapi) of the next one and so on with all of them, all being in the same level of the build tree. To generate the .girs I've used the --include-uninstalled option to include the previously generated .gir file of the project. Now, when the build system tries to run vapigen to generate a .vapi that depends on another part of the library, it fails. The call to vapigen is something like this: $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir The .vapi file of the gvn package is alredy generated (and put in the directory specified via the --vapidir option) at this point, as well as the .gir of the current package. And this is the error it produces: error: Package `Gvn-0.1' not found in specified Vala API directories or GObject-Introspection GIR directories I guess it has something to do with the package not being installed, but I couldn't find a way to tell it to vapigen. However that's just a guess, so I don't really know what i'm doing wrong and/or how to solve this. Can anyone help me with it? Thanks in advance! Regards, Alex PS: sorry if my english is a mess, if something is not clear tell me and I'll try to rewrite it. ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list -- http://aug.ment.org GPG: 0A8D 2BC7 243D 57D0 469D 9736 C557 458F 003E 6952 ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
Abderrahim, I did. In fact I needed to, in order to generate the Sql-0.1.gir and the subsequent .girs'. I noted that the name the error gives to the package is not the same I gave it when exporting it. I called it gvn-0.1 and the error talks about Gvn-0.1, which is not a correct package name. I thought vapigen parsed the name from the .gir and lower the case. May be the name the error gives to the package has no relevance, I don't know. As you can see, I'm kind of lost right now in all this .vapi generation thing (it's the first time I use a mailing list!), but I guess this is the funniest part of programming. Thanks for the link, I'll give it a look. Thanks! Regards, Alex. El 27 de marzo de 2012 18:07, Abderrahim Kitouni a.kito...@gmail.comescribió: في ث، 27-03-2012 عند 17:05 +0200 ، كتب Alejandro T Colombini Gómez: August, I just didn't know that. Reading the documentation and looking at an official gnome project (GDA, that does the same thing I was trying to do) I though it was the only way to bind C to Vala. And the other developers I mentioned are using Vala by the first time, too. If I can do this that way I'll save some time! Can you give me some reference to that method? Actually, the recommended way to use a gobject library from Vala is to generate the vapi from the GIR. It's actually possible to use the GIR directly, but I'm not sure whether it's a good idea. Anyway, in case you didn't already see it, look at this: http://live.gnome.org/Vala/UpstreamGuide As for your question: To generate the .girs I've used the --include-uninstalled option to include the previously generated .gir file of the project. Now, when the build system tries to run vapigen to generate a .vapi that depends on another part of the library, it fails. The call to vapigen is something like this: $(VAPIGEN) --pkg glib-2.0 --pkg gobject-2.0 --pkg gvn-0.1 -d $(vapidir) --vapidir=$(vapidir) --library foo-0.1 Foo-0.1.gir The .vapi file of the gvn package is alredy generated (and put in the directory specified via the --vapidir option) at this point, as well as the .gir of the current package. And this is the error it produces: error: Package `Gvn-0.1' not found in specified Vala API directories or GObject-Introspection GIR directories Just a guess, but I think the problem is that your gir file doesn't reference the package, and so valac doesn't know that gvn-0.1.vapi and Gvn-0.1.gir are the same. You have to add --pkg-export=gvn-0.1 to your g-ir-scanner flags. HTH, Abderrahim ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vapigen and Autotools problem
August, I just didn't know that. Reading the documentation and looking at an official gnome project (GDA, that does the same thing I was trying to do) I though it was the only way to bind C to Vala. And the other developers I mentioned are using Vala by the first time, too. If I can do this that way I'll save some time! Can you give me some reference to that method? If you have already created the .gir file and installed it in the proper location (with other gir files), then you should be able to use it directly in vala code. For example, if you are writing a gobject lib called Mylib, you create a Mylib-1.0.gir file and then a typelib file with something like: g-ir-compiler --includedir $(PREFIX)/share/gir-1.0/ Mylib-1.0.gir -o Mylib-1.0.typelib and put the .gir file under $(PREFIX)/share/gir-1.0/ and put the .typelib file under $(PREFIX)/lib/girepository-1.0/ then, vala users _should_ be able to call your api with: using Mylib-1.0; Since you are creating a GObject lib, I _thought_ the preferred method was through .gir and not .vapia. But, I could be wrong. I remember getting advised to do it this way on IRC. Of course, I am writing my gobject C lib in VALA, so that may have been why I was given that advice. If any of this is wrong, I would also love to know the proper methodwith or without autotools. thanks, best, suerte -august. -- http://aug.ment.org GPG: 0A8D 2BC7 243D 57D0 469D 9736 C557 458F 003E 6952 ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
