Re: [Vala] Generated vapi file for a library not compilable.
OK, I use a workaround and run a sed command to fix the incorrect generated vapi file. I use sed to prepend global:: to all wrong namespaced classes then it works. Before the bug of vala gets handled, I have to use the workaround for now. The problem is, how to integrate this fix with automake? I need to run the command everytime after the vapi file is generated. However, I cannot find a proper "automake" mechanism to do it automatically. Any suggestions? On Thu, Nov 29, 2012 at 1:40 PM, Axel FILMORE wrote: > On Thu, 29 Nov 2012 13:09:53 +0800 > PCMan wrote: > > > Thanks for sharing. > > Manually editing the vapi file works for me too, but this is only a > > workaround. > > After regeneration of vapi files, the changes are gone and need to be > > done again. > > There must be something wrong in valac or my compiler settings. > > We need a way to generate correct vapi files from vala code directly. > > So, it seems that it's a bug in valac? > > I done like this in the library : > > http://bazaar.launchpad.net/~axel-filmore/valadesktop/spanel-lib/view/head:/src/PanelApplet.vala > > http://bazaar.launchpad.net/~axel-filmore/valadesktop/spanel-lib/view/head:/vapi/libspanel.vapi > > And like this in the application : > > http://bazaar.launchpad.net/~axel-filmore/valadesktop/spanel/view/head:/src/Applets/Weather/WeatherApplet.vala > > I don't use any namespace for Applets :) > > I don't have the technical explanation however. > > :P > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generated vapi file for a library not compilable.
On Thu, 2012-11-29 at 10:13 +0800, PCMan wrote: > All of the errors I got are like these: > VALAC lxpanel2_vala.stamp > lxpanel-applet.vapi:10.27-10.49: error: The type name `Lxpanel.AppletInfo' > could not be found In lxpanel2.vala you have a class `Lxpanel' in the namespace `Lxpanel'. This means that the symbol `Lxpanel' will be resolved to the class `Lxpanel.Lxpanel' instead of the global namespace `Lxpanel' - when referenced from within the namespace `Lxpanel'. valac typically detects such conflicts and prefixes the name with `global::' in the generated .vapi file. However, as the conflict is not in the lxpanel-applet library, it's impossible for valac to detect that conflict when generating the .vapi file. I recommend you to rename the class `Lxpanel.Lxpanel' to something else such as `Lxpanel.Panel'. Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Is creating dbus interfaces in type modules (plugins) broken?
Hello Unfortunately you didn't point to the exact code lines but I had the same issue. I experienced the same thing with an interface for "org.gnome.SettingsDaemon.MediaKeys". I got crashes if the interface declaration was in the module. Moving the interface to the application itself fixed the issue. But the implementation of the interface may remain in the module and it is working. Regards Am Donnerstag, den 29.11.2012, 10:06 +0800 schrieb PCMan: > Hello, > I tried to develop some type modules for my program. > Everything works fine initially and [ModuleInit] registered GObject dynamic > classes automagically as expected. > However, after I move a previously working dbus interface to that type > module, I got crashes. > > My source code is here: > http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/lxpanel2;a=summary > > A google search lead me to a similar report from others: > https://mail.gnome.org/archives/vala-list/2012-September/msg00125.html > > Is this a known bug? Or is there anyway to overcome this? > I like vala a lot and I don't want to rewrite the whole program in C again > just because some little problems. > > Thanks in advance. > ___ > vala-list mailing list > vala-list@gnome.org > https://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generated vapi file for a library not compilable.
Thank you for the prompt reply. I just fixed it with using a sed command to add the "global::" prefix in a "all-local" target of Makefile.am, which is very dirty! I'll try what you said. I did not noticed that it can be the cause of the problem. Thank you very much!!! On Thu, Nov 29, 2012 at 5:11 PM, Jürg Billeter wrote: > On Thu, 2012-11-29 at 10:13 +0800, PCMan wrote: > > All of the errors I got are like these: > > VALAC lxpanel2_vala.stamp > > lxpanel-applet.vapi:10.27-10.49: error: The type name > `Lxpanel.AppletInfo' > > could not be found > > In lxpanel2.vala you have a class `Lxpanel' in the namespace `Lxpanel'. > This means that the symbol `Lxpanel' will be resolved to the class > `Lxpanel.Lxpanel' instead of the global namespace `Lxpanel' - when > referenced from within the namespace `Lxpanel'. > > valac typically detects such conflicts and prefixes the name with > `global::' in the generated .vapi file. However, as the conflict is not > in the lxpanel-applet library, it's impossible for valac to detect that > conflict when generating the .vapi file. > > I recommend you to rename the class `Lxpanel.Lxpanel' to something else > such as `Lxpanel.Panel'. > > Regards, > Jürg > > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Is creating dbus interfaces in type modules (plugins) broken?
On Thu, 2012-11-29 at 10:06 +0800, PCMan wrote: > I tried to develop some type modules for my program. > Everything works fine initially and [ModuleInit] registered GObject dynamic > classes automagically as expected. > However, after I move a previously working dbus interface to that type > module, I got crashes. Support for dynamic types will likely be removed from a future GLib version¹, i.e., you will no longer be able to unload modules. Can you try whether you can fix the crashes by simply removing the [ModuleInit] attribute? Module loading should still work the same way, you just won't be able to unload it without restarting the process. If you want to keep using dynamic types and help finding the solution for this bug, can you please try the following? * Replace G_DEFINE_TYPE_EXTENDED in the generated .c file by G_DEFINE_DYNAMIC_TYPE_EXTENDED (for the UPower proxy) * Add upower_upower_proxy_register_type(type_module) to your plugin_init function right after the call to upower_upower_register_type Regards, Jürg ¹ http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/ ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Generated vapi file for a library not compilable.
Really thank you , Jürg Billeter. My problem is solved by renaming that class to avoid conflicts. Mailing list is good. I spent hours and hours trying to workaround this and did not find any clue. I should have came here earlier. Thanks! On Thu, Nov 29, 2012 at 5:26 PM, PCMan wrote: > > Thank you for the prompt reply. > I just fixed it with using a sed command to add the "global::" prefix in a > "all-local" target of Makefile.am, which is very dirty! > I'll try what you said. I did not noticed that it can be the cause of the > problem. > Thank you very much!!! > > > On Thu, Nov 29, 2012 at 5:11 PM, Jürg Billeter wrote: >> >> On Thu, 2012-11-29 at 10:13 +0800, PCMan wrote: >> > All of the errors I got are like these: >> > VALAC lxpanel2_vala.stamp >> > lxpanel-applet.vapi:10.27-10.49: error: The type name `Lxpanel.AppletInfo' >> > could not be found >> >> In lxpanel2.vala you have a class `Lxpanel' in the namespace `Lxpanel'. >> This means that the symbol `Lxpanel' will be resolved to the class >> `Lxpanel.Lxpanel' instead of the global namespace `Lxpanel' - when >> referenced from within the namespace `Lxpanel'. >> >> valac typically detects such conflicts and prefixes the name with >> `global::' in the generated .vapi file. However, as the conflict is not >> in the lxpanel-applet library, it's impossible for valac to detect that >> conflict when generating the .vapi file. >> >> I recommend you to rename the class `Lxpanel.Lxpanel' to something else >> such as `Lxpanel.Panel'. >> >> Regards, >> Jürg >> > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Is creating dbus interfaces in type modules (plugins) broken?
Thank you for the info. I'll remove dynamic type modules from my program. It's a pity that the feature is going to be removed. I think it's a wrong decision. Without this features, we cannot unload large and unused modules and its dependencies to save resources once it's no longer needed. In C++, it's perfectly legal to unload a lib at runtime. In C/GObject, it's no longer possible. This is the price we pay for fake OOP support in C. Really disappointed to hear that news. Thanks anyway. On Thu, Nov 29, 2012 at 5:39 PM, Jürg Billeter wrote: > On Thu, 2012-11-29 at 10:06 +0800, PCMan wrote: >> I tried to develop some type modules for my program. >> Everything works fine initially and [ModuleInit] registered GObject dynamic >> classes automagically as expected. >> However, after I move a previously working dbus interface to that type >> module, I got crashes. > > Support for dynamic types will likely be removed from a future GLib > version¹, i.e., you will no longer be able to unload modules. Can you > try whether you can fix the crashes by simply removing the [ModuleInit] > attribute? Module loading should still work the same way, you just won't > be able to unload it without restarting the process. > > If you want to keep using dynamic types and help finding the solution > for this bug, can you please try the following? > * Replace G_DEFINE_TYPE_EXTENDED in the generated .c file by > G_DEFINE_DYNAMIC_TYPE_EXTENDED (for the UPower proxy) > * Add upower_upower_proxy_register_type(type_module) to your > plugin_init function right after the call to > upower_upower_register_type > > Regards, > Jürg > > ¹ http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/ > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
