Re: multiple vala versions in 3.4
On 01/22/2012 06:45 AM, Zeeshan Ali (Khattak) wrote: While it is true that ideal scenerio would be for Vala to simply use gir/typelib but gir is missing features supported by vala and its bindings for many years now. Nested namespace is one of them. Another example is default values for parameters. Nested namespaces would be nice for other bindings as well. There is a bug for it. https://bugzilla.gnome.org/show_bug.cgi?id=576327 Default values are asked for by pygobject guys as well. There is a bug for it as well: https://bugzilla.gnome.org/show_bug.cgi?id=558620 Both just need some more thought and a patch. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Sat, 2012-01-21 at 06:58 +0200, Zeeshan Ali (Khattak) wrote: On Fri, Jan 20, 2012 at 2:30 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On 01/19/2012 10:32 PM, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. This question might seem a little naive, but could someone highlight me why the vala compiler can't stay backward compatible from release to release? Indeed. Until vala grows up a little more, its increasing use in the desktop is a growing problem. Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. There are way I'm in charge of maintaining the bindings distributed with Vala, and I completely agree. Historically, most of the backwards incompatible breaks in bindings come from fixing things that kind of worked but were really sub-optimal (for instance, using string + size_t arguments for binary data instead of a single uint8[]). We have been working hard this cycle to switch to generating our bindings from GIR, which is fixing a *lot* of problems but some B.C. breaks are pretty much unavoidable. Future cycles should be much less tumultuous. too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. Wow, this post was very well timed. I've been working on that lately (since it was brought up on vala-list in the context of Clutter about a week ago) and I just pushed a patch to Vala which provides autotools integration similar to what GObject introspection offers. If anyone out there would like to distribute Vala bindings with their project instead of with Vala please let us know (preferably either through Vala mailing list or #vala on irc.gnome.org). I'm willing to help integrate Vala bindings into your build system and assist with maintenance. -Evan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi eba...@gmail.com wrote: hi Zeeshan; Hi Emmanuele, On 23 January 2012 02:14, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote: 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. I don't agree with this assessment. you're just deferring the issue to every library under the sun, and this is very much problematic in a variety of reasons: - as a maintainer, now I'd have to care not only about introspection, but also about a vapi file - which is another redundant format that expresses the library's API; so the first thing I'd look at would be generating the latter in terms of the former, which introduces a build dependency (albeit optional) on Vala. so it's my library that now has to deal with the compiler and generator bugs. yeah, right: not going to happen. What I was proposing wasn't so different from what you are saying here. Vala bindings should still be generated out of gir bindings but since gir doesn't support some of the essential features that vala apps have been depending on for some time now, we'll need to have *some* vala-specific metadata, at least until gir supports those features. If having any vala-specific metadata in a few libraries isn't acceptable to maintainers, yeah we should first separate out the bindings into another package and then push the bindings that are purely generated from gir to their respective libraries. BTW just for the record, It should be noted that gir is the cause of the problem here not vala. - I have used Vala, but I'm not an expert on figuring out its quirks, nor am I using it for my day to day work; this means that I'll have to rely on Vala developers to update the Vala bindings. this means that Vala developers and users will now need to go through various bugzilla products and git repositories to fix the Vala bindings in each and every project that ships one. They'll have to go through the same procedures as python and javascript users so I don't think this is an issue. Actually this will give good motivation to vala developers to fix/improve your gir annotations for you. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 10:12 AM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: BTW just for the record, It should be noted that gir is the cause of the problem here not vala. I think this argument doesn't hold any water, tbh. gir was invented to expose the bindable features of C apis to higher level languages, not to force (somewhat questionable) constructs like nested namespaces back into the descriptions of C apis which really don't have these concepts. Anyway, we don't need to assign blame here; I think we all agree that requiring two descriptions of each bindable api is problematic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
Any objections to this patch for the moduleset? From 93b05f15f3cd218dab7517e798ca3daf2e05bfc1 Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Mon, 23 Jan 2012 16:44:55 -0500 Subject: [PATCH] 3.4: Switch to building from git for vala, libgee, and folks jhbuild should always be building from actual source code (i.e. git) for modules we expect GNOMErs to possibly hack on. This set definitely includes vala and folks, but probably not e.g. SQLite. --- modulesets/gnome-suites-core-deps-3.4.modules | 23 +-- 1 files changed, 9 insertions(+), 14 deletions(-) diff --git a/modulesets/gnome-suites-core-deps-3.4.modules b/modulesets/gnome-suites-core-deps-3.4.modules index 25bb7bd..d655df3 100644 --- a/modulesets/gnome-suites-core-deps-3.4.modules +++ b/modulesets/gnome-suites-core-deps-3.4.modules @@ -379,9 +379,8 @@ /dependencies /tarball - tarball id=folks version=0.6.6 autogenargs=--enable-eds-backend -source href=http://ftp.gnome.org/pub/GNOME/sources/folks/0.6/folks-0.6.6.tar.xz; -hash=sha256:3dd6a2983969a6369c6b0e25f28ec92415b5570dd6c89b25385807ecc4aeb0a8/ + autotools id=folks autogenargs=--enable-eds-backend +branch revision=wip/vala-0-15/ dependencies dep package=dbus/ dep package=dbus-glib/ @@ -394,7 +393,7 @@ suggests dep package=telepathy-logger/ /suggests - /tarball + /autotools tarball id=fontconfig version=2.8.0 pkg-configfontconfig.pc/pkg-config @@ -758,18 +757,16 @@ /dependencies /autotools - tarball id=libgee version=0.6.2.1 + autotools id=libgee +branch revision=0.6/ pkg-configgee-1.0.pc/pkg-config -source href=http://download.gnome.org/sources/libgee/0.6/libgee-0.6.2.1.tar.bz2; -hash=sha256:e177be887727c9c214bd41f46063e386a7292ba207f586930148190580c829ad -md5sum=9c95ab9462179610d39df3c5a0911f3b size=477230/ dependencies dep package=glib/ /dependencies suggests dep package=gobject-introspection/ /suggests - /tarball + /autotools autotools id=libgnomekbd branch/ @@ -1234,15 +1231,13 @@ /suggests /autotools - tarball id=vala version=0.15.0 + autotools id=vala autogenargs=--enable-vapigen +branch/ pkg-configlibvala-0.16.pc/pkg-config -source href=http://download.gnome.org/sources/vala/0.15/vala-0.15.0.tar.xz; -hash=sha256:828f7341a3c4fc14b6d0f5a14ce3bdf4c40f5eae3e7ccf11c2b49061df9d2e23 -md5sum=2bffc49985cc790f0a9522b159ef935b size=2618360/ dependencies dep package=glib/ /dependencies - /tarball + /autotools autotools id=WebKit makefile=GNUmakefile autogenargs=--enable-introspection -- 1.7.6.5 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 10:48 PM, Colin Walters walt...@verbum.org wrote: Any objections to this patch for the moduleset? jhbuild should always be building from actual source code (i.e. git) for modules we expect GNOMErs to possibly hack on Great to read that jhbuild should preferably build over vcs and not tarballs. If people want to stick to a particular tag or branch, they can still specify it and keep using the vcs. The tarballs aren't developers friendly at all. regards -- Marc-André Lureau ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 4:48 PM, Colin Walters walt...@verbum.org wrote: Any objections to this patch for the moduleset? Looks right to me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, 2012-01-23 at 17:12 +0200, Zeeshan Ali (Khattak) wrote: On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi eba...@gmail.com wrote: hi Zeeshan; Hi Emmanuele, On 23 January 2012 02:14, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote: 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. I don't agree with this assessment. you're just deferring the issue to every library under the sun, and this is very much problematic in a variety of reasons: - as a maintainer, now I'd have to care not only about introspection, but also about a vapi file - which is another redundant format that expresses the library's API; so the first thing I'd look at would be generating the latter in terms of the former, which introduces a build dependency (albeit optional) on Vala. so it's my library that now has to deal with the compiler and generator bugs. yeah, right: not going to happen. What I was proposing wasn't so different from what you are saying here. Vala bindings should still be generated out of gir bindings but since gir doesn't support some of the essential features that vala apps have been depending on for some time now, we'll need to have *some* vala-specific metadata, at least until gir supports those features. I've been putting together a guide for people wanting to maintain bindings upstream, and it includes an incomplete list of discrepancies between GIR and Vala (and how to work around them): https://live.gnome.org/Vala/UpstreamGuide#Using_Metadata_Files If having any vala-specific metadata in a few libraries isn't acceptable to maintainers, yeah we should first separate out the bindings into another package and then push the bindings that are purely generated from gir to their respective libraries. I think it's worth pointing out here that most libraries aren't going to have a lot of metadata. Clutter's API is pretty large (the vapi is 7283 lines) and it only has 158 lines (including comments and whitespace, less once bug #667840 is resolved) of metadata, but most libraries will only have a few lines. BTW just for the record, It should be noted that gir is the cause of the problem here not vala. That's not really fair. It's true that there is some stuff that GIR doesn't support that we would like them to, but Vala's GIR parser has bugs too. Up until fairly recently Vala's GIR parser was definitely the bigger problem. - I have used Vala, but I'm not an expert on figuring out its quirks, nor am I using it for my day to day work; this means that I'll have to rely on Vala developers to update the Vala bindings. this means that Vala developers and users will now need to go through various bugzilla products and git repositories to fix the Vala bindings in each and every project that ships one. They'll have to go through the same procedures as python and javascript users so I don't think this is an issue. Actually this will give good motivation to vala developers to fix/improve your gir annotations for you. Yes! After the initial work to get bindings working properly, most of the stuff we do is actually fixing things in the metadata file that could/should really be fixed in annotations within the upstream project. This means that currently my workflow often looks something like this: 1. Tweak the metadata to fix the issue in the vala repository and regenerate the bindings. 2. Create a patch against the upstream library to resolve the issue with annotations. 3. File a bug report with the patch and wait for upstream to resolve the issue. Example: clutter bug #667840 4. Undo the changes to the metadata file in the vala repository and instead regenerate the bindings using the updated GIR. My offer to help with maintenance for libraries wanting to move bindings upstream wasn't entirely selfless; I could eliminate steps 1 and 4. It also means that you get those annotation fixes sooner rather than later (sometimes much later since I sometimes don't get around to #2 for a while, and sometimes someone else does #1 doesn't worry about the rest), which fixes the GIR-based bindings for other languages as well. The other obvious advantage is that users don't have to wait for a new Vala release to get updated bindings. Finally, we can stop worrying about a whole class of issues where the bindings are too new. Say a library has a virtual function and they decide they want to add a method which invokes it (a pretty common scenario). After you regenerate the Vala bindings valac will start using the invoker automatically instead of calling the vfunc directly, which works great for
Re: multiple vala versions in 3.4
2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. Yup, though it's still not unusual to hit vala compiler bugs unfortunately There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. Well, when people say vala, they mean what's in vala.git or the vala tarball. I agree there is a difference between vala-the-language and vala-the-bindings, but since they are shipped as a single entity, vala = vala-the-language + vala-the-bindings, it's not really useful to consider them separately. My feeling is that shipping the 2 separately might help (people may be able to keep using vala-the-language from their distro, but some module would require very new vala-the-bindings tarballs). Dunno how practical that would be. Christophe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote: 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. Yup, though it's still not unusual to hit vala compiler bugs unfortunately There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. Well, when people say vala, they mean what's in vala.git or the vala tarball. I agree there is a difference between vala-the-language and vala-the-bindings, but since they are shipped as a single entity, vala = vala-the-language + vala-the-bindings, it's not really useful to consider them separately. My feeling is that shipping the 2 separately might help (people may be able to keep using vala-the-language from their distro, but some module would require very new vala-the-bindings tarballs). Dunno how practical that would be. I see your point and agree with your solution but as a plan-B. In case we encounter heavy resistance against pushing individual bindings to respective libraries, lets look into this option. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
hi Zeeshan; On 23 January 2012 02:14, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote: 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. I don't agree with this assessment. you're just deferring the issue to every library under the sun, and this is very much problematic in a variety of reasons: - as a maintainer, now I'd have to care not only about introspection, but also about a vapi file - which is another redundant format that expresses the library's API; so the first thing I'd look at would be generating the latter in terms of the former, which introduces a build dependency (albeit optional) on Vala. so it's my library that now has to deal with the compiler and generator bugs. yeah, right: not going to happen. - I have used Vala, but I'm not an expert on figuring out its quirks, nor am I using it for my day to day work; this means that I'll have to rely on Vala developers to update the Vala bindings. this means that Vala developers and users will now need to go through various bugzilla products and git repositories to fix the Vala bindings in each and every project that ships one. - not every library is going to get their Vala binding in tree, and not every library is going to get a Vala binding in tree at the same time; in other words: some C libraries simply won't ship Vala bindings (libc anyone? all the crazy little C libraries that do not depend on GLib/GObject but that Vala users are so keen on accessing from something that looks likes a high level language?) and you'll have various cycles between now and the point when the current bindings set is spread into enough projects. there are also the two whole issues of the introspection format does not allow us to create the same vapi files as hand-writing them and the the introspection format does not cover all features of Vala so we cannot write libraries in Vala and have them introspected, which are kind of a red herring. yes, hand-writing is always going to be more expressive because you can fix the C API in your binding. well, tough: fix the C API instead. and yes, writing a library in Vala is moderately insane *anyway*, given the amount of build issues that are introduced, and the fact that now Vala has to always create the exact same ABI, even in the case of bugs. Well, when people say vala, they mean what's in vala.git or the vala tarball. I agree there is a difference between vala-the-language and vala-the-bindings, but since they are shipped as a single entity, vala = vala-the-language + vala-the-bindings, it's not really useful to consider them separately. My feeling is that shipping the 2 separately might help (people may be able to keep using vala-the-language from their distro, but some module would require very new vala-the-bindings tarballs). Dunno how practical that would be. I see your point and agree with your solution but as a plan-B. In case we encounter heavy resistance against pushing individual bindings to respective libraries, lets look into this option. no, I'd seriously look into splitting out the bindings repository from the Vala compiler repository *first*, if I were you. and then, if I still were you, I'd seriously look into making Vala and introspection play nice together, so that maintainers and users have to stop caring about this particular issue. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On 01/21/2012 05:58 AM, Zeeshan Ali (Khattak) wrote: Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. Libraries already maintain gobject introspection files, and valac is supposed to use those these days isn't it? All bindings are using those these days. libpeas provides samples using pygobject, seed, gjs and vala and the only sample which is broken for every releases is the vala one. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On 01/21/2012 11:44 AM, Steve Frécinaux wrote: Libraries already maintain gobject introspection files, and valac is supposed to use those these days isn't it? No. Unless gir format will be fixed to allow nested namespaces. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Sun, Jan 22, 2012 at 2:36 AM, Antono Vasiljev s...@antono.info wrote: On 01/21/2012 11:44 AM, Steve Frécinaux wrote: Libraries already maintain gobject introspection files, and valac is supposed to use those these days isn't it? No. Unless gir format will be fixed to allow nested namespaces. While it is true that ideal scenerio would be for Vala to simply use gir/typelib but gir is missing features supported by vala and its bindings for many years now. Nested namespace is one of them. Another example is default values for parameters. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
Il giorno gio, 19/01/2012 alle 16.32 -0500, Colin Walters ha scritto: However, modules will need to be patched to find the correct valac and vapigen with the -0.14 suffix. For example, folks just does: AC_PATH_PROG([VAPIGEN], [vapigen], []) if test x$VAPIGEN = x; then AC_MSG_ERROR([Vala must be built with --enable-vapigen]) fi We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to configure, but it's probably better to fix this inside the configure scripts. Wouldn't it be a good idea for Vala to install a valac.m4 file in /usr/share/aclocal, containing a pertaining macro? Something like AC_PROG_VALA([== 0.15]), so that everyone can use the same macro, avoiding this kind of duplication and differences among modulesets. This can set variables for both valac and vapigen in one go. Cheers, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L$ E+ W+++ N+ o? w--- O M- V- PS++ PE- Y+++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Thu, 2012-01-19 at 18:34 -0500, Colin Walters wrote: On Thu, 2012-01-19 at 22:53 +, Philip Withnall wrote: Also, I don't think there are any reasons for us to not port to Vala 0.15, as long as libgee 0.6 continues to compile with 0.15. Currently it seems to be broken for master (IIRC it worked for 0.15.0) and I'm working on fixing it. In fact, some of my recent folks branches require Vala 0.15 (due to .vapi file changes which haven't been backported to 0.14). Ah...okay so this raises another question I have - can someone fill me in on why the 3.4 moduleset is stuck on libgee 0.6.2.1? Are you guys using jhbuild for 3.4? In the big picture where I'd like to be is that git master of all of these modules are targeted for the 3.4 release. Or if for some reason you don't want to synchronize to the GNOME schedule, at least have a 3.4 branch. The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI (with expected breaks). I would advice to either follow 0.6 series or 0.6 branch (not master) until 0.7 will get stable API. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 11:49 +0100, Matteo Settenvini wrote: Il giorno gio, 19/01/2012 alle 16.32 -0500, Colin Walters ha scritto: However, modules will need to be patched to find the correct valac and vapigen with the -0.14 suffix. For example, folks just does: AC_PATH_PROG([VAPIGEN], [vapigen], []) if test x$VAPIGEN = x; then AC_MSG_ERROR([Vala must be built with --enable-vapigen]) fi We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to configure, but it's probably better to fix this inside the configure scripts. Wouldn't it be a good idea for Vala to install a valac.m4 file in /usr/share/aclocal, containing a pertaining macro? Something like AC_PROG_VALA([== 0.15]), so that everyone can use the same macro, avoiding this kind of duplication and differences among modulesets. This can set variables for both valac and vapigen in one go. Cheers, It's included by default in new automake: AM_PROG_VALAC([0.14.0]) (checks for valac = 0.14.0). Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On 01/19/2012 10:32 PM, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. This question might seem a little naive, but could someone highlight me why the vala compiler can't stay backward compatible from release to release? Indeed. Until vala grows up a little more, its increasing use in the desktop is a growing problem. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On 20 January 2012 12:25, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: It's included by default in new automake: AM_PROG_VALAC([0.14.0]) (checks for valac = 0.14.0). Does that also check for valac-0.14 when valac doesn't exist? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 07:30 -0500, Matthias Clasen wrote: On 01/19/2012 10:32 PM, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. This question might seem a little naive, but could someone highlight me why the vala compiler can't stay backward compatible from release to release? Indeed. Until vala grows up a little more, its increasing use in the desktop is a growing problem. I wouldn't say that - vala is widely used because people clearly find it useful. We clearly need some more communication here though (and more people using jhbuild to build their vala modules trackin 3.4). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote: The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI (with expected breaks). I would advice to either follow 0.6 series or 0.6 branch (not master) until 0.7 will get stable API. Ah, ok - that's what I need to know. So we should definitely be sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6 branch which is good - I want to track git, not a tarball snapshot. I'll fix up the moduleset and work with the folks people on 0.15 support. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 09:45 -0500, Colin Walters wrote: On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote: The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI (with expected breaks). I would advice to either follow 0.6 series or 0.6 branch (not master) until 0.7 will get stable API. Ah, ok - that's what I need to know. So we should definitely be sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6 branch which is good - I want to track git, not a tarball snapshot. Yes. 0.6 is still maintained. There should be a bugfix release during this weekend (I need just an advice from gir specialist about shared-library attribute of .typelib. Whom should I contact?) also allowing building against vala master. I'll fix up the moduleset and work with the folks people on 0.15 support. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 14:48 +, Maciej Marcin Piechotka wrote:
On Fri, 2012-01-20 at 09:45 -0500, Colin Walters wrote:
On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote:
The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI
(with expected breaks). I would advice to either follow 0.6 series or
0.6 branch (not master) until 0.7 will get stable API.
Ah, ok - that's what I need to know. So we should definitely be
sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6
branch which is good - I want to track git, not a tarball snapshot.
Yes. 0.6 is still maintained. There should be a bugfix release during
this weekend (I need just an advice from gir specialist about
shared-library attribute of .typelib. Whom should I contact?)
You're talking to him now =) What's the question?
also
allowing building against vala master.
How about this patch (I am a Vala noob, but I want to try to pitch in
here rather than talk endlessly)
There are a *ton* of compiler warnings but it builds, ship it etc...
From 5e35da9f6bbcb99790efb8934c9651e93f095d7c Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Fri, 20 Jan 2012 09:49:49 -0500
Subject: [PATCH] Fix compilation with Vala 0.15
---
gee/priorityqueue.vala |4 ++--
tests/testarraylist.vala |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gee/priorityqueue.vala b/gee/priorityqueue.vala
index 6c45238..e3e7a85 100644
--- a/gee/priorityqueue.vala
+++ b/gee/priorityqueue.vala
@@ -53,7 +53,7 @@ public class Gee.PriorityQueueG : Gee.AbstractQueueG {
private Type2NodeG? _lm_head = null;
private Type2NodeG? _lm_tail = null;
private Type1NodeG? _p = null;
- private Type1NodeG?[] _a = new Type1NodeG[0];
+ private Type1NodeG?[] _a = new Type1NodeG?[0];
private NodePairG? _lp_head = null;
private NodePairG? _lp_tail = null;
private bool[] _b = new bool[0];
@@ -316,7 +316,7 @@ public class Gee.PriorityQueueG : Gee.AbstractQueueG {
_lm_head = null;
_lm_tail = null;
_p = null;
- _a = new Type1NodeG[0];
+ _a = new Type1NodeG?[0];
_lp_head = null;
_lp_tail = null;
_b = new bool[0];
diff --git a/tests/testarraylist.vala b/tests/testarraylist.vala
index e5340c5..05bc328 100644
--- a/tests/testarraylist.vala
+++ b/tests/testarraylist.vala
@@ -148,9 +148,9 @@ public class ArrayListTests : ListTests {
assert (double_list.add (1.5d));
assert (double_list.add (2.0d));
- double[] double_array = double_list.to_array ();
+ double?[] double_array = double_list.to_array ();
index = 0;
- foreach (double element in double_list) {
+ foreach (double? element in double_list) {
assert (element == double_array[index++]);
}
}
--
1.7.6.5
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 09:51 -0500, Colin Walters wrote: On Fri, 2012-01-20 at 14:48 +, Maciej Marcin Piechotka wrote: On Fri, 2012-01-20 at 09:45 -0500, Colin Walters wrote: On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote: The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI (with expected breaks). I would advice to either follow 0.6 series or 0.6 branch (not master) until 0.7 will get stable API. Ah, ok - that's what I need to know. So we should definitely be sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6 branch which is good - I want to track git, not a tarball snapshot. Yes. 0.6 is still maintained. There should be a bugfix release during this weekend (I need just an advice from gir specialist about shared-library attribute of .typelib. Whom should I contact?) You're talking to him now =) What's the question? Could you comment what would be proper short-time fix on https://bugzilla.gnome.org/show_bug.cgi?id=667529 also allowing building against vala master. How about this patch (I am a Vala noob, but I want to try to pitch in here rather than talk endlessly) I'm currently working on making 0.7 branch work (it compiles but fails tests). If backporting existing patch will fail I will use yours + conditional compilation. PS. I'm not a vala wizard either. There are a *ton* of compiler warnings but it builds, ship it etc... I'm trying to slowly get rid of them. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, Jan 20, 2012 at 2:30 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On 01/19/2012 10:32 PM, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. This question might seem a little naive, but could someone highlight me why the vala compiler can't stay backward compatible from release to release? Indeed. Until vala grows up a little more, its increasing use in the desktop is a growing problem. Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
multiple vala versions in 3.4
Hi, Looks to me like some modules in the 3.4 moduleset want Vala 0.15 c.f. this commit: commit e6e59801cd13f5fa02ca7bbf6d269db886aca9f4 Author: Frédéric Péters fpet...@0d.be Date: Mon Jan 9 16:48:46 2012 +0100 3.4: bump vala to 0.15 (required by gnome-boxes and dconf, at least) But others (folks at least) fail to compile with 0.15. So far we've been relying on the fact that the .c files are cached in the tarball for folks, but this is pretty broken. Jhbuild is supposed to to be the developer tool where you can actually hack on stuff. I think we need to take both Vala 0.14 and 0.15 in the moduleset, using the --disable-unversioned flag. However, modules will need to be patched to find the correct valac and vapigen with the -0.14 suffix. For example, folks just does: AC_PATH_PROG([VAPIGEN], [vapigen], []) if test x$VAPIGEN = x; then AC_MSG_ERROR([Vala must be built with --enable-vapigen]) fi We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to configure, but it's probably better to fix this inside the configure scripts. Jürg, do you agree we should use --disable-unversioned for vala in jhbuild? This is what Ubuntu appears to do. As far as I can tell Fedora just accepts the generated .c files. (Or perhaps more ideally, modules using 0.14 would port, but if we're going to keep having Vala rebases, we should sort this out better) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
Hi, On Thu, 2012-01-19 at 16:32 -0500, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. So far we've been relying on the fact that the .c files are cached in the tarball for folks, but this is pretty broken. Jhbuild is supposed to to be the developer tool where you can actually hack on stuff. Thanks for pointing this out. I haven't had as much time for Folks lately, so it's gone a little undermaintained. Honestly, I'd like to remove generated .c/.h files from the Folks release tarballs (in part because it tangles up our makefiles even more) and just haven't gotten around to it. I solicited feedback and no one seemed opposed. The initial motivation was that most distros didn't have the bleeding-edge version of Vala we constantly required for the first year or so, but our requirements are modest at this point. I hope to make this change relatively soon and I'll try to keep everyone informed. Regards, -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
I maintain the GNOMEish app deja-dup. I also would like it if GNOME supported apps that want to stay on a stable compiler during the cycle. I use the following macro in acinclude.m4 to allow specifying a specific valac-X.XX version with a friendly fallback to valac. In configure.ac: DD_PROG_VALAC([0.14.0], [valac-0.14 valac]) In acinclude.m4: AC_DEFUN([DD_PROG_VALAC], [AC_PATH_PROGS([VALAC], [$2], []) AS_IF([test -z $VALAC], [AC_MSG_ERROR([No Vala compiler found.])], [AS_IF([test -n $1], [AC_MSG_CHECKING([$VALAC is at least version $1]) am__vala_version=`$VALAC --version | sed 's/Vala *//'` AS_VERSION_COMPARE([$1], [$am__vala_version], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]) AC_MSG_ERROR([Vala $1 not found.])])])]) ]) -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Thu, 2012-01-19 at 13:57 -0800, Travis Reitter wrote: Hi, On Thu, 2012-01-19 at 16:32 -0500, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. So far we've been relying on the fact that the .c files are cached in the tarball for folks, but this is pretty broken. Jhbuild is supposed to to be the developer tool where you can actually hack on stuff. Thanks for pointing this out. I haven't had as much time for Folks lately, so it's gone a little undermaintained. Honestly, I'd like to remove generated .c/.h files from the Folks release tarballs (in part because it tangles up our makefiles even more) and just haven't gotten around to it. I solicited feedback and no one seemed opposed. The initial motivation was that most distros didn't have the bleeding-edge version of Vala we constantly required for the first year or so, but our requirements are modest at this point. I hope to make this change relatively soon and I'll try to keep everyone informed. Also, I don't think there are any reasons for us to not port to Vala 0.15, as long as libgee 0.6 continues to compile with 0.15. In fact, some of my recent folks branches require Vala 0.15 (due to .vapi file changes which haven't been backported to 0.14). Philip Regards, -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, Jan 20, 2012 at 3:02 AM, Colin Walters walt...@verbum.org wrote: [snip] However, modules will need to be patched to find the correct valac and vapigen with the -0.14 suffix. For example, folks just does: AC_PATH_PROG([VAPIGEN], [vapigen], []) if test x$VAPIGEN = x; then AC_MSG_ERROR([Vala must be built with --enable-vapigen]) fi We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to configure, but it's probably better to fix this inside the configure scripts. Just a small clarification here in case people end up trying this. What needs to be passed is VALAC=$(which valac-0.14) VAPIGEN=$(which vapigen-0.14), i.e. the full path to the binaries; since AC_PATH_PROG doesn't read $PATH unless told to. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Thu, 2012-01-19 at 22:53 +, Philip Withnall wrote: Also, I don't think there are any reasons for us to not port to Vala 0.15, as long as libgee 0.6 continues to compile with 0.15. In fact, some of my recent folks branches require Vala 0.15 (due to .vapi file changes which haven't been backported to 0.14). Ah...okay so this raises another question I have - can someone fill me in on why the 3.4 moduleset is stuck on libgee 0.6.2.1? Are you guys using jhbuild for 3.4? In the big picture where I'd like to be is that git master of all of these modules are targeted for the 3.4 release. Or if for some reason you don't want to synchronize to the GNOME schedule, at least have a 3.4 branch. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Thu, 2012-01-19 at 22:53 +, Philip Withnall wrote: On Thu, 2012-01-19 at 13:57 -0800, Travis Reitter wrote: Hi, On Thu, 2012-01-19 at 16:32 -0500, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. So far we've been relying on the fact that the .c files are cached in the tarball for folks, but this is pretty broken. Jhbuild is supposed to to be the developer tool where you can actually hack on stuff. Thanks for pointing this out. I haven't had as much time for Folks lately, so it's gone a little undermaintained. Honestly, I'd like to remove generated .c/.h files from the Folks release tarballs (in part because it tangles up our makefiles even more) and just haven't gotten around to it. I solicited feedback and no one seemed opposed. The initial motivation was that most distros didn't have the bleeding-edge version of Vala we constantly required for the first year or so, but our requirements are modest at this point. I hope to make this change relatively soon and I'll try to keep everyone informed. Also, I don't think there are any reasons for us to not port to Vala 0.15, as long as libgee 0.6 continues to compile with 0.15. In fact, some of my recent folks branches require Vala 0.15 (due to .vapi file changes which haven't been backported to 0.14). Yes, I implied that but should have been more clear: part of the move to vala-dependent tarballs will include porting to 0.15 and explicitly requiring it. Regards, -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Thu, 2012-01-19 at 18:34 -0500, Colin Walters wrote: Are you guys using jhbuild for 3.4? In the big picture where I'd like to be is that git master of all of these modules are targeted for the 3.4 release. Or if for some reason you don't want to synchronize to the GNOME schedule, at least have a 3.4 branch. Sorry about the temporary breakage. In the case that we weren't going to match the Gnome schedule, we'd create a compatibility branch like that. But the only reason we aren't quite caught up is due to limited time, not a real difference of scheduling. I'll try to catch up soon. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
Hi, On 01/19/2012 10:32 PM, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. This question might seem a little naive, but could someone highlight me why the vala compiler can't stay backward compatible from release to release? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
