Re: [Vala] Problem with switch statment
On Sun, 2009-09-27 at 20:23 +0200, Nicolas wrote: > My function work but i have this message when building: > > treeview.gs:143.9-158.13: warning: unreachable code detected I assume the reason for this is that the Genie parser just always appends a break statement even if you have, for example, a return statement right at the end of the block. So, from the control flow analyzer, that inserted break statement may be unreachable. This will need an exception in the flow analyzer for generated statements or something like that. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.7 - Compiler for the GObject type system
We are pleased to announce version 0.7.7 of Vala, a compiler for the GObject type system. Vala 0.7.7 is now available for download at: http://download.gnome.org/sources/vala/0.7/ Changes since 0.7.6 * Support `using' directives inside namespaces. * Use const only for immutable structs. * Support string marshalling for enums in D-Bus (Didier Ptitjes). * Update Genie parser (Jamie McCracken). * Add libgda-4.0 bindings (Shawn Ferris). * Many bug fixes for closures and async methods. Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following: * Interfaces * Properties * Signals * Foreach * Lambda expressions * Type inference for local variables * Generics * Non-null types * Assisted memory management * Exception handling Vala is designed to allow access to existing C libraries, especially GObject-based libraries, without the need for runtime bindings. All that is needed to use a library with Vala is an API file, containing the class and method declarations in Vala syntax. Vala currently comes with bindings for GLib and GTK+. It's planned to provide generated bindings for the full GNOME Platform at a later stage. Using classes and methods written in Vala from an application written in C is not difficult. The Vala library only has to install the generated header files and C applications may then access the GObject-based API of the Vala library as usual. It should also be easily possible to write a bindings generator for access to Vala libraries from applications written in e.g. C# as the Vala parser is written as a library, so that all compile-time information is available when generating a binding. More information about Vala is available at http://live.gnome.org/Vala Jürg Billeter ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] add move_window method to X11 bindings
On Thu, 2009-09-17 at 13:57 +0100, Gordon Allott wrote: > small patch, adds the method "move_window" to the Display class in the X11 > bindings, uses XMoveWindow. Thanks, applied. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Strange error from glib-2.0.vapi
On Fri, 2009-09-18 at 21:20 +0200, Enrique Ocaña González wrote: > Following the GLib headers, I saw that *in Linux* a GPid is in the end a > pid_t, that in the end is a 32 bit integer. > > What I did was to copy part of the GLib vapi into a seperate vapi file and > there I copied the vapi directives of gint. It worked. > > I'd propose the attached patch to correct GLib vapi, but I'm not sure if it > should be added to Vala because I've read in other mails that in Windows GPid > is a pointer and not an integer. Yes, GPid is not an integer on Windows, unfortunately. That's why I won't apply this patch upstream. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [RFC, PATCH] add async keyword to vapigen
On Thu, 2009-09-24 at 22:21 +0200, Philipp Zabel wrote: > Hi, the following patch adds support for an "async" attribute to > vapigen. This can be used in metadata to fix up the binding of > asynchronous methods that don't end in _async like this: Thanks, applied to master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [RFC, PATCH] add async keyword to vapigen
On Fri, 2009-09-25 at 09:23 +0200, Jan Hudec wrote: > On Thu, Sep 24, 2009 at 22:21:36 +0200, Philipp Zabel wrote: > > Or would it be better to make the parser recognize asynchronous > > functions that don't end in _async? > > An async function can be recognized by having a GAsyncReadyCallback argument > next to last and void * last (that's what vala expects from an async > function). So it could probably be detected only by that (and not look at > "_async" suffix at all except to strip it). Unfortunately, there are a few exceptions to that. An attribute sounds safer for now. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Storing strings inside structs fails.
On Sun, 2009-09-20 at 13:57 +0200, Julian Andres Klode wrote:
> storing a string inside a struct does not work.
>
> If you compile the following Vala code:
> struct Item {
> public string uri;
> }
>
> public static void main() {
> var uri = "http://google.de";;
> Item item = {uri};
>
> stdout.printf("item.uri: %s\n", item.uri);
> stdout.printf(" uri: %s\n", uri);
> }
>
This was bug 583603 and is now fixed in master.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Why not use g_strcmp0 instead of a custom _vala_strcmp0?
On Sat, 2009-09-26 at 20:47 +0200, Julian Andres Klode wrote: > Vala currently writes a _vala_strcmp0 into almost every > C file. This function is exactly the same as glib's > g_strcmp0. Wouldn't it be better to use g_strcmp0 > instead? g_strcmp0 is available since GLib 2.16, however, Vala currently only requires GLib 2.12. I'll consider bumping this requirement in the near future. If we do, we should be able to drop the generated function. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Cleaning up GCC warnings; dereferencing a void pointer.
On Sun, 2009-09-20 at 21:29 -0400, Michael B. Trausch wrote: > Some time back I had some trouble getting the GDK and X11 bindings > playing well together. Jürg helped out and I got the code to compile > and work properly, but being the pedant that I am, I'd like to get rid > of the warning from gcc altogether. > > The code that Vala generates is: > > real_xev = (XEvent*) (&(*xev)); > > The code that silences the GCC warning is: > > real_xev = (XEvent *)xev; > > So, what I am wondering is, should I report a bug against Vala? It > would seem that the expression "(&(*xev))" could be simplified to the > latter, and that simplification makes GCC happy, since the void* pointer > is no longer dereferenced and the pointer is properly cast to the > appropriate pointer type. I haven't tested with your exact code, however, I've committed the expression simplification to Vala master. Let me know if you still have issues with that. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [BUG] Cannot store delegate in a class.
On Fri, 2009-09-18 at 21:54 +0200, Jan Hudec wrote: > Until recently, I could store a delegate in a class. It was incorrect in many > cases because a destroy notify was not stored in the delegates. > > Now the destroy notify is stored, but for some reason fails to be stored in > a class. What is worse, vala does not report any error and silently generates > invalid code: Fixed in master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Async] why use .begin ?
On Sat, 2009-09-19 at 01:41 +0200, Michael 'Mickey' Lauer wrote: > > No, the call without .begin() is being deprecated. > > > > >From yestarday's discussion on IRC I understood it's not generally possible > > to collapse to synchronous call automagically. Doing it involves running > > a (recursive) main loop until the callback is called, but this brings a lot > > of problems like something quitting the outer loop, the nested loops being > > quit out of order and such. Therefore it should not be done without user's > > explicit request. > > I see, am I correct then in assuming that at the end of the day this means, > calling an asynchronous function with out/return arguments is forbidden/will > not work from synchronous code? You can certainly call an asynchronous method with out/return values, however, you obviously have to wait for the method to return until you can use them. You could, for example, handle them in a closure used as callback to .begin. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.6 - Compiler for the GObject type system
On Fri, 2009-09-18 at 10:11 +0200, Frederik wrote:
> Great release!
Thanks.
> One question about closures: is it intentional that captured variables
> change after the closure? For example:
>
> --
> delegate void Func ();
>
> void main () {
> int a = 42;
> Func f = () => stdout.printf ("%d\n", a);
> a = 43;
> f ();
> }
> --
> Output: 43
This is correct, there is only one instance of the variable `a' and that
instance is captured by the closure. You can also change the value of
`a' inside the closure and this will affect the outer method as well as
there is only one instance of this variable.
> This seems to affect currying as well:
>
> --
> delegate int IntFuncInt (int i);
>
> IntFuncInt curried_add (int a) {
> return b => a + b;
> }
>
> void main () {
> int a = 3;
> int b = 4;
> stdout.printf ("%d + %d = %d\n", a, b, curried_add (a)(b));
> }
> --
> Output: 3 + 4 = 4
This was a bug in how delegates were returned from methods. This is now
fixed in master.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.6 - Compiler for the GObject type system
We are pleased to announce version 0.7.6 of Vala, a compiler for the GObject type system. Vala 0.7.6 is now available for download at: http://download.gnome.org/sources/vala/0.7/ Changes since 0.7.5 * Add support for closures. * Improve support for asynchronous methods. * Support async methods in D-Bus servers. * Add clutter-1.0 bindings (Rob Taylor). * Add GVariant, GSettings, and dconf bindings (Ryan Lortie). * Add linux, libnl-1, and libasound bindings (Michael 'Mickey' Lauer). * Add gnutls bindings (Jiří Zárevúcky). * Add librest bindings (Adrien Bustany). * Many bug fixes and binding updates. Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following: * Interfaces * Properties * Signals * Foreach * Lambda expressions * Type inference for local variables * Generics * Non-null types * Assisted memory management * Exception handling Vala is designed to allow access to existing C libraries, especially GObject-based libraries, without the need for runtime bindings. All that is needed to use a library with Vala is an API file, containing the class and method declarations in Vala syntax. Vala currently comes with bindings for GLib and GTK+. It's planned to provide generated bindings for the full GNOME Platform at a later stage. Using classes and methods written in Vala from an application written in C is not difficult. The Vala library only has to install the generated header files and C applications may then access the GObject-based API of the Vala library as usual. It should also be easily possible to write a bindings generator for access to Vala libraries from applications written in e.g. C# as the Vala parser is written as a library, so that all compile-time information is available when generating a binding. More information about Vala is available at http://live.gnome.org/Vala Jürg Billeter ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Add is_out for Gst.ChildProxy.get_property value parameter
On Wed, 2009-09-16 at 20:50 +0200, Frederik Sdun wrote: > +gst_child_proxy-get_property.value is_out="1" As far as I know, this should be a `ref' parameter, as the get_property method requires an already initialized GValue. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Some thoughts about multidimensional arrays
Hi, On Wed, 2009-09-16 at 20:03 +0200, Frederik Sdun wrote: > I wrote some code using multidimensional arrays yesterday and realized > it is not perfect, especially if you use strings. > > Every array uses an additional _length and and _size gint. size is the > allocated size, length the actual use fields. Because every array uses > such data, why not pack them into a struct? Let's call it > ArrayDim[ension]: While I agree that it intuitively makes a lot more sense to store the length/size in a struct, it's, unfortunately, not realizable. The main reason is that it would be incompatible to everything else out there. This means that Vala applications coult not access/pass arrays from/to C libraries unless you support two array types, one that is compatible and one that uses these structs. An other issue is that there is no good place to define these structs as there is no Vala-specific runtime library. This could probably be worked around but the main issue is compatibility as mentioned above. BTW: I am experimenting with a new runtime library that could be used for Vala applications as an alternative to GLib, and there I sacrifice compatibility for features and sane definitions, this includes moving everything that belongs to the array into a single struct. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] using a non-glib C library in vala
On Wed, 2009-09-16 at 15:41 -0400, Michael B. Trausch wrote: > The bug is "memset code generation is incorrect", so I'm not sure how > you can say "Vala should not generate invalid code, but this bug is > indeed invalid". The bug is that the code generation is incorrect. > > Whether or not the binding that triggers the incorrect code generation > is itself incorrect is another, distinct issue. If it is indeed > incorrect, then there should be a Vala compiler diagnostic to catch it. > So, if what you're saying is correct, that bug report really contains > *two* valid bugs, one that isn't actually described, and the one that is > (invalid code generation). As bindings describe the mapping of a high-level API to the low-level C API, there are unlimited possibilities how you can break code generation with incorrect bindings. It's impossible for the compiler to detect all of these cases. That said, if this was a valid binding, the corresponding memset compiler bug would be bug 578968¹. Jürg ¹ https://bugzilla.gnome.org/show_bug.cgi?id=578968 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] using a non-glib C library in vala
On Wed, 2009-09-16 at 15:46 -0400, Michael B. Trausch wrote: > On Wed, 2009-09-16 at 15:41 -0400, Michael B. Trausch wrote: > > Did the meaning of [SimpleType] change somewhere? I thought it meant > > "pass by value". > > And pardon me, I'm not thinking very clearly. That sounds wrong. > > My thought was that a SimpleType could be allocated statically, and > passing it would do something like (in C, continuing the example from > earlier in the thread): > > ip_address_t foo; > memset(&foo, 0, sizeof(ip_address_t)); > > I can see writing things like this being frowned upon, but my thought > was that a SimpleType was just that. It seems instead that all > allocations are supposed to come from the heap via (one way or another) > malloc/free? Or am I still misunderstanding something? Vala structs are always stack/inline-allocated, it doesn't matter whether they are annotated with [SimpleType] or not. The only meaning of [SimpleType] is that values of these structs are passed by value in method calls. Normal structs are passed by reference. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] vapi/linux.vapi: Add mremap(2) call.
On Wed, 2009-09-16 at 19:13 +0200, Julian Andres Klode wrote:
> This is a Linux-specific enhancement to the mmap() function
> set implemented in posix.vapi.
> +public enum MremapFlags {
> [...]
> +public void *mremap(void *old_address, size_t old_size, size_t new_size,
> +MRemapFlags flags);
Thanks, I've fixed the case typo and applied it to master.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH 2/2] vapi/posix.vapi: Introduce ftruncate() and truncate().
On Wed, 2009-09-16 at 16:44 +0200, Julian Andres Klode wrote: > There has been no answer to my 2 patches yet, so I ask again. Having > mmap() and file truncation support is kind of needed for maintaining > a binary cache on the disk. And writing a package manager[1] without > such a cache would be silly. Sorry about that, I tend to lose track of patches in the mailing list as there are also patches in Bugzilla pending for review. Feel free to ping me about patches I might have missed at anytime. On Sun, Aug 30, 2009 at 01:42:33PM +0200, Julian Andres Klode wrote: > > + [CCode (cheader_filename = "unistd.h")] > > + public int truncate(const char *path, off_t length); I've changed this to `string path' and applied both patches, thanks. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Thoughts on asynchronous methods
On Wed, 2009-09-16 at 13:34 +1000, Magentus wrote: > On Sun, 13 Sep 2009 17:40:33 +0200, > Jürg Billeter wrote: > > > This should be `yield return i;'. We do not use/need `yield return' > > for async methods, and I'm planning to add support for `yield return' > > for generators in Vala the same way as it's used in C#. I don't see a > > conflict here. > > Can I ask what probably should be an obvious answer... Why is it > 'yield return'. What else can 'yield' be followed by? `yield return' statements are used to return values from a generator/iterator to the caller (of Iterator.next). This is not implemented yet in Vala but it's planned for a future version. `yield' expressions, on the other hand, are used to call async methods from within an other async method without blocking the original caller. They do not return a value to the original caller. This is implemented in Vala master. If these definitions sound too complicated, I'll try to come up with some good async examples and will blog them. > > I can't see a reference to documentation on the syntax and usage of > 'yield' anywhere... But I'm guessing everyone else has? `yield' expressions only have been implemented (correctly) for a few days, we'll have to update the documentation. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] gobject-2.0: Bind g_object_newv
On Tue, 2009-09-15 at 19:49 +0200, Jan Hudec wrote: > Can you please add the binding for g_object_newv (GLib.Object.newv), as that > was the main reason to have GParameter working (it is the only public user in > gobject). Applied, thanks. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Fix generation of implemented interfaces in .gir.
On Mon, 2009-08-31 at 15:07 +0200, Jan Hudec wrote: > The list of implemented interfaces is expected as > > > > ... > > by gobject-introspection library (as of 0.6.3), but was written as > > > > > ... > > > by Vala.GIRWriter. Note, that vapigen expects the same format as > gobject-introspection, so it was not able to read vala-written .girs > before the change and is able to read them properly now. > > Fixes 584576. Thanks, applied. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] gtk-clutter-0.10 bindings
Hi Gord, On Thu, 2009-09-10 at 16:33 +0100, Gordon Allott wrote: > there are clutter-1.0 bindings in vala now (great!) but no clutter-gtk-0.10 > bindings, they are very often paired together so I thought it best to generate > some up-to-date ones and would love for them to included in the trunk. they > were > built using vapigen and used metadata to correct them. > Also have a vested interest in maintaining them against newer versions > clutter-gtk > patch is attached to this email but can also post in the bugzilla if anyone > feels that's more appropriate Thanks for the patch. As you've generated them using vapigen, would you mind also adding the .gi and .metadata files? Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] add_inet_port's(GSocketListener) source_object is optional
On Sun, 2009-09-13 at 06:29 +0800, Darren Hoo wrote: > Hi, > I am trying the GIONetworkingSample [1]. > compiling the gio-server sample has the following warning: > > warning: Argument 2: Cannot pass null to non-null parameter type > service.add_inet_port (8080, null); > > according the signature of g_socket_listener_add_inet_port [2] > the source_object is optional.so I assume the value source_object > passed to add_inet_port can be nullable. > > Am I right? Yes, thanks for the report. Please note that gio-2.0.vapi is a generated file, which means that the change needs to be applied to gio-2.0.metadata instead. I've committed a fix. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to define copy and destroy functions in vapi
On Sun, 2009-09-13 at 16:35 +0200, Jan Hudec wrote: > I want to use the GParameter structure (GLib.Parameter in gobject-2.0.vapi). > However, vala requires a copy and destroy functions for it and none are > defined in the gobject header. I can define them (they are simple but not > empty), but how do I tell vala to actually generate them when it needs them? I've just added two new boolean CCode attributes for structs, has_copy_function and has_destroy_function, and fixed the GParameter binding. This should fix the problem. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Thoughts on asynchronous methods
On Sun, 2009-09-13 at 16:16 +0200, Jan Hudec wrote:
> On Sat, Sep 12, 2009 at 13:34:27 +0200, Jürg Billeter wrote:
> > Hi Jiří,
> >
> > On Sat, 2009-09-12 at 00:27 +0200, Jiří Zárevúcky wrote:
> > > --
> > > 1. "yields" keyword is far from intuitive
> > > --
> > >
> > > [...]
> > >
> > > Personally, I would find following much more appropriate:
> > >
> > > public virtual async void method (int arg) throws IOError;
> >
> > I agree with you here. The reason I've chosen `yields' is that I've
> > initially thought that the same syntax could be used for more generic
> > coroutine support. However, the focus was always on asynchronous methods
> > and there is no plan to integrate generic coroutine with the same syntax
> > anymore.
>
> Please, don't use 'yield' keyword in a way incompatible with C#, where (since
> version 2.0) it is used for generators just like in Python. E.g.
>
> public IEnumerable range(int start, int end) {
> for(int i = start; i <= end; ++i)
> yield i;
> }
This should be `yield return i;'. We do not use/need `yield return' for
async methods, and I'm planning to add support for `yield return' for
generators in Vala the same way as it's used in C#. I don't see a
conflict here.
> This has nothing to do with asynchronous at all.
>
> I understand this is would be complicated to implement, but please at least
> don't use any of that syntax in an incompatible way.
>
> Virtual machines actually have it pretty easy to implement. They just stash
> away the running function state and than resume it. Vala can't easily do
> that, but I see two options for it:
>
> - Generate the function in a special way so it is restartable. This would
>mean to generate an anonymous class. All arguments and variables would be
>converted to members of that class. Plus one extra member would remember
>which point the function last returned at. Than if the function contained
>no block-local variables, it should be possible to wrap it in a big case
>(similar to what Duff's device uses) to jump to the correct point to
>continue.
That's roughly what we already do for async methods, and the
implementation will be very similar for generators.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Thoughts on asynchronous methods
On Sat, 2009-09-12 at 16:41 +0200, Jiří Zárevúcky wrote: > On 09/12/2009 01:34 PM, Jürg Billeter wrote: > >> > >> 2. purely asynchronous methods > >> > >> > >> There are actions that can't be represented synchronously and methods > >> where synchronous variant needs to be written separately. 'nuff said. > >> This could perhaps be handled using specialized [Async] attribute with > >> appropriate parameters. > >> > > For this exact reason - and the fact that sometimes parameter lists > > differ slightly between sync and async variants -, I'm actually tending > > to drop the combined sync/async method support, and only support purely > > asynchronous methods. While combined methods sound interesting, they are > > not essential, and I prefer a solid slightly simpler async support to > > advanced async support with issues. > > > > I don't know about removing altogether. AFAIK it just feeds the normal > codegen with the same data, no big deal. Maybe it would be more > reasonable to disable by default with some attribute for enabling? We can always readd proper support for this later if we think it makes sense. For now async methods are purely async. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Thoughts on asynchronous methods
On Sat, 2009-09-12 at 14:16 +0200, Michael 'Mickey' Lauer wrote: > On Saturday 12 September 2009 13:34:27 Jürg Billeter wrote: > > I agree with you here. The reason I've chosen `yields' is that I've > > initially thought that the same syntax could be used for more generic > > coroutine support. However, the focus was always on asynchronous methods > > and there is no plan to integrate generic coroutine with the same syntax > > anymore. > > That's kind of sad. What is the plan towards generic coroutines then, if any? It's planned to support generators using yield statements. Generator methods will not need any special method modifiers at all, though, so this shouldn't influence the modifier used for async methods. > Missing async dbus on server side is a showstopper for us here, is there a > away I could fake/wrap that in the meantime until it's there? I've just added initial support for async D-Bus server methods. Let me know if you find any issues. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Thoughts on asynchronous methods
Hi Jiří,
On Sat, 2009-09-12 at 00:27 +0200, Jiří Zárevúcky wrote:
> I did some thinking on the subject of asynchronous (aka "yielding")
> methods. I'd like to share and discuss some of my ideas here.
>
> --
> 1. "yields" keyword is far from intuitive
> --
>
> [...]
>
> Personally, I would find following much more appropriate:
>
> public virtual async void method (int arg) throws IOError;
I agree with you here. The reason I've chosen `yields' is that I've
initially thought that the same syntax could be used for more generic
coroutine support. However, the focus was always on asynchronous methods
and there is no plan to integrate generic coroutine with the same syntax
anymore.
As async support is still considered experimental, I think it makes
sense to change the keyword now. I don't know whether we should use
`async' or rather the unabbreviated `asynchronous' to be clear, although
it's quite long. Any opinions?
>
> 2. purely asynchronous methods
>
>
> There are actions that can't be represented synchronously and methods
> where synchronous variant needs to be written separately. 'nuff said.
> This could perhaps be handled using specialized [Async] attribute with
> appropriate parameters.
For this exact reason - and the fact that sometimes parameter lists
differ slightly between sync and async variants -, I'm actually tending
to drop the combined sync/async method support, and only support purely
asynchronous methods. While combined methods sound interesting, they are
not essential, and I prefer a solid slightly simpler async support to
advanced async support with issues.
> ---
> 3. stopping execution until a callback yields
> ---
>
> There are actions that can be described as "waiting for callback". For
> that to work correctly, programmer needs to make sure all the connected
> callbacks are disconnected as the method returns. If there is mechanism
> to "pause execution" (from the programmers POV) until some connected
> callback yields, it would allow doing this cleanup in a finally block.
> I have a faint feeling that bare "yield" keyword already has some
> semantics, but for the sake of demonstration:
>
> public int method () yields throws Error{
> try {
> signal1.connect ((x) => yield return x;);
> signal2.connect ((x) => yield throw new Error ("Error
> occured: %s", x);); // the first one to be executed decides the return
> condition
>
> yield; // wait and treat yields as if they were called here
> }
> finally {
> signal1.disconnect ();
> signal2.disconnect ();
> }
> }
>
> This is also a prime example of method that can't be translated into a
> synchronous version.
>
> ---
> 4. co-execution operator
> ---
>
> [...]
This is an interesting idea. However, I hope you understand that it
doesn't make sense to me to closely look into things like that until
basic async support is working well - and Vala 1.0 has been released.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Why do regular reference types leak null?
On Fri, 2009-08-14 at 13:57 -0700, Sam Danielson wrote:
> By cast I mean that there must be some way to get a Foo out of a Foo?.
> When I encounter a Foo? I should (ideally) not be allowed to
> dereference it unless I have first ensured it is not null by
> transforming it into a Foo. Vala is not dependently typed so the
> preceding operation isn't generally supported but I believe that nulls
> are important enough to warrant special handling. The Foo/Foo?
> dichotomy is precisely that special case. The only thing we're missing
> are the static checks to make it usable, IMHO.
>
> Here's what I mean by dependently typed.
>
> // f is Foo?
> if (f != null) {
> // f is Foo
> }
>
> Of course the conditional would have to be statically verifiable. If
> it is not then f would remain Foo? inside the consequent branch. But
> disallowing dereference for Foo? is perhaps too draconian for Vala
> since the constraint could be enforced elsewhere and making the
> programmer put every use of Foo? in a dependently typed block is
> insane.
This is the eventual goal of Vala's support for non-nullable reference
types. However, this will not happen for Vala 1.x, at least not as
default. The reason is that if strict null checking is enabled without
good static analysis, it does more harm than it helps - compiler errors
in places where the expression can never be null.
Getting static analysis to a point where it's nice to work with strict
null checking is far from trivial. Just supporting `if (f != null)' is
not good enough in my experience. You'd end up with a lot of nullable =>
non-null casts, and this cannot be the goal.
I welcome experiments with the --enable-non-null-experimental mode, and
if and when we can get it to a usable state, we can consider enabling it
by default for the next major version.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] wish for Type Inference working for weak local variables
On Sun, 2009-08-02 at 16:20 +0200, Jiří Zárevúcky wrote: > Yet, I'm kinda wondering about one thing. It seems to me some people > were, are and will be wanting inference for weak variables, regardless > the real benefits may be negligible. Even if it were just to have nice C > code where the reffing is not needed. Still, every time the question > comes up, people will spend much more time arguing the insignificance > then it would take to actually implement it... Quite I hope you do understand that language design is not about how to add as many features as possible as quickly as possible. Every syntax addition has its merits and its drawbacks for both, users and implementors of the language. Adding syntactic sugar just because you can is not the right decision. If you make something more prominent in the language by adding syntactic sugar, you imply that you're encouraging its use and therefore also require that more users of the language should be able to understand it. If you do this for functionality that should only be used rarely, people will use it in situations where they shouldn't, which will lead to more bugs and confusion as, for example, dangling pointers and crashes. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.5 - Compiler for the GObject type system
We are pleased to announce version 0.7.5 of Vala, a compiler for the GObject type system. Vala 0.7.5 is now available for download at: http://download.gnome.org/sources/vala/0.7/ Changes since 0.7.4 * Add support for static properties. * Add support for delegate properties. * Support virtual default handler for signals. * Add limited support for derived compact classes. * Add libgdata bindings (Víctor Manuel Jáquez Leal). * Add libusb-1.0 bindings (Evan Nemerson). * Many bug fixes and binding updates. Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following: * Interfaces * Properties * Signals * Foreach * Lambda expressions * Type inference for local variables * Generics * Non-null types * Assisted memory management * Exception handling Vala is designed to allow access to existing C libraries, especially GObject-based libraries, without the need for runtime bindings. All that is needed to use a library with Vala is an API file, containing the class and method declarations in Vala syntax. Vala currently comes with bindings for GLib and GTK+. It's planned to provide generated bindings for the full GNOME Platform at a later stage. Using classes and methods written in Vala from an application written in C is not difficult. The Vala library only has to install the generated header files and C applications may then access the GObject-based API of the Vala library as usual. It should also be easily possible to write a bindings generator for access to Vala libraries from applications written in e.g. C# as the Vala parser is written as a library, so that all compile-time information is available when generating a binding. More information about Vala is available at http://live.gnome.org/Vala Jürg Billeter ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] glib-object.h?
On Fri, 2009-07-31 at 15:59 +0800, Yu Feng wrote: > Dear list, > > gobject-2.0.vapi pulls in . but the GNOME guidelines says > the header should not be included. > > http://live.gnome.org/GnomeGoals/CleanupGTKIncludes The list of toplevel headers on the wiki page appears to be incomplete. may be included directly, building with -DG_DISABLE_SINGLE_INCLUDES should not complain. Maybe you should add a comment to the wiki page. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Class and interface names can be "too short"?
Hi Boris, On Wed, 2009-07-22 at 10:16 +0200, boris kolar wrote: > I just noted an error stating that class name was too short (less than > 3 characters). After taking a look at the source, it seems that > interfaces have the same restriction. This goes strongly against my > "libertarian" sense that all needless restrictions should be > removed ;) Is there a good reason for this restriction? If not (or not > always), I propose modification of valagtypemodule.vala and allowing > arbitrary length identifiers (hint: search for "too short"). I'm not familiar with the reasoning behind the restriction, however, it's a limit of GObject, not a limit of Vala. We just report the error in Vala to avoid a runtime error from GObject later on. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Errors handling in vala compiler
Hi Yu, On Wed, 2009-07-15 at 10:30 +0800, Yu Feng wrote: > I can see there is a 'check' method for each node which recursively > checks the children of the node. It returns a false on error, and writes > the error message to stderr. > > But how and why does the compiler exit when the method returns false? > Why isn't this part using the throw/catch handling? The aborting is only done by the compiler driver, that is, compiler/valacompiler.vala. The reason we do not use throw/catch for that is that we want to be able to report more than one error at once and not just abort at the first error we encounter. > I am looking into this because I am evaluating the possibility of > parsing and constructing the ast in valide with libvala. The IDE won't > be happy if libvala reports to stderr and aborts for errors. You can subclass Vala.Report, override the err and warn methods, and then set the `report' property of the default context to an instance of your report subclass. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] vala 0.7.4 and plugins bug?
Hi Andrea, On Wed, 2009-07-01 at 00:01 +0200, Andrea Del Signore wrote: > while trying to compile vtg with the new 0.7.4 version I think that I > spot a bug with plugin modules C code generation. > > Attached there are: > > 1) plugin.vala - a minimal test case > 2) plugin.c - the generated wrong C code > 3) type-modules.patch - a one line patch. > > In a few words the problem is that the _type_id > variable isn't declared if the class is inside a type-module plugin. > > I don't know if it's desiderable to declare the type_id variable in the > declaration block or not, so check the patch ok? Thanks. The type_id variable should never be in the header file, so I had to change a few more things. It's pushed to master now. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] gnet-2.0 vapi, v2
On Tue, 2009-07-07 at 01:53 -0400, Michael B. Trausch wrote: > Found a few issues, so here's a second version. Seems vapis can't bind a > function twice with the same name statically and non-statically, so I removed > the instance convenience methods for equality/hashing. > > Also, it's worth noting that the vapi requires that you add gio-2.0 to the > compilation process, since it depends on certain things from there for > IOChannel and IOError. Thanks, I've committed it to master with gio-2.0 as dependency. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.4 - Compiler for the GObject type system
On Mon, 2009-06-29 at 19:44 +0200, Michael 'Mickey' Lauer wrote: > Congrats on the release! > > > * Add initial support for generic methods. > > Is this just infrastructure preparations or can we use them already? You can use them already. They are just not heavily tested yet, so there might still be severe bugs. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Trouble with array length in vala 0.7.4
On Mon, 2009-06-29 at 19:49 -0400, Sam Danielson wrote: > I am having trouble with arrays in expressions. AFAICT foo.x.length > doesn't work if x is a function or property returning an array. I > explain more in the comments of the following snippet. I couldn't find > a bug matching this exact behavior but I would like to know if anyone > else has come across this before I file it. Using 0.7.4. This is http://bugzilla.gnome.org/show_bug.cgi?id=585847 Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.4 - Compiler for the GObject type system
We are pleased to announce version 0.7.4 of Vala, a compiler for the GObject type system. Vala 0.7.4 is now available for download at: http://download.gnome.org/sources/vala/0.7/ Changes since 0.7.3 * Add support for array properties. * Support implicit and explicit GValue casts. * Add initial support for generic methods. * Add postgres bindings. * Many bug fixes and binding updates. Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following: * Interfaces * Properties * Signals * Foreach * Lambda expressions * Type inference for local variables * Generics * Non-null types * Assisted memory management * Exception handling Vala is designed to allow access to existing C libraries, especially GObject-based libraries, without the need for runtime bindings. All that is needed to use a library with Vala is an API file, containing the class and method declarations in Vala syntax. Vala currently comes with bindings for GLib and GTK+. It's planned to provide generated bindings for the full GNOME Platform at a later stage. Using classes and methods written in Vala from an application written in C is not difficult. The Vala library only has to install the generated header files and C applications may then access the GObject-based API of the Vala library as usual. It should also be easily possible to write a bindings generator for access to Vala libraries from applications written in e.g. C# as the Vala parser is written as a library, so that all compile-time information is available when generating a binding. More information about Vala is available at http://live.gnome.org/Vala Jürg Billeter ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [RESEND] [PATCH] Fix Posix.getpgid() binding
On Sat, 2009-06-20 at 14:37 -0400, Michael B. Trausch wrote: > It's been a while since I sent this, and looking at the archives, I somehow > must have mangled the email. Here it is again. This fixes the binding for > getpgid() to take a single parameter, a pid_t, which complies both with POSIX > and Linux, specifically: Thanks, pushed to master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Add parenthesis to macro substitutions
On Thu, 2009-06-25 at 18:51 +0200, Frederik Sdun wrote: > thats a common problem with C makros. Here a better example: > > public const double = 1.0 + 3.0; > public const double = 2.0 / ; > > will be replaced to 2.0 / 1.0 + 3.0 = 5.0 instead of 0.5. > The Patch add () around and the statement will be correct: > > = 2.0 / ( 1.0 + 3.0 ) = 0.5 Thanks, it certainly helps to look at all attachments before responding... I've pushed a slightly different patch to avoid unnecessary parenthesis. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Add parenthesis to macro substitutions
On Thu, 2009-06-25 at 17:24 +0800, Yu Feng wrote: > Only for expressions. No parenthesis is added to string macros. > A test is attached. Without the patch compiles to a wrong expression. What do you mean with ? Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [Patch] Small improvements on gsl bindings
Hi Yu, On Thu, 2009-06-25 at 21:53 +0800, Yu Feng wrote: > Here are a few small improvements on gsl bindings. > > Several places the pointers are properly replaced by arrays, and several > delegates are handled the native vala way. Thanks for the patch. It does not apply on master, though. patching file vapi/gsl.vapi Reversed (or previously applied) patch detected! Skipping patch. 6 out of 6 hunks ignored -- saving rejects to file vapi/gsl.vapi.rej Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] GType is a IntegerType + SimpleType
On Thu, 2009-06-25 at 16:09 +0800, Yu Feng wrote: > Refer to Sam's email on Jun 24th Switch statement on GType. The reason why GType is not supported in switch statements is because typeof expressions are not considered constant expressions. While there are a few basic GTypes that are constants in C, this is not true for types defined outside GLib. If we apply your patch, valac will generate invalid C code if you use typeof expressions that are not constant in C. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Loop not found?
On Thu, 2009-06-25 at 07:17 +0800, Yu Feng wrote:
> I was trying to catch up with recent vala master branch, but I get this
> error:
>
> valacodevisitor.vala:308.34-308.37: error: The type name `Loop' could not be
> found
> public virtual void visit_loop (Loop stmt) {
> [...]
> Nevertheless git reports the working copy is uptodate and clean.
> valaloop.vala is in the source file list.
Looks like you've run ./configure without --enable-maintainer-mode.
Always use ./autogen.sh instead of ./configure when building from git
and everything should build fine.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] autotool support for genie
Hi Jamie, On Tue, 2009-06-16 at 19:02 -0400, Jamie McCracken wrote: > hi juerg, > > i note that vala now has automake support for .vala files but it > lacks .gs genie source file support > > i have a patch for autotools to support genie but my perl is not very > good so please see attached patch and let me know if its right and i > will forward to autotools list You've missed at least necessary changes in 'output_extensions' (in Vala's register_language) and in lang_vala_rewrite. Best would probably be to port the Vala test cases to Genie (should be easy) and make sure all Vala and Genie test cases pass. Thanks, Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] setting this.window from Gtk.Widget subclass is not allowed?
On Fri, 2009-06-12 at 10:02 +0100, Ali Afshar wrote: > Hi everyone, nice work with Vala, I am quite excited. > > I am not sure whether this is a bug or not, but when I follow the custom > widget examples on http://live.gnome.org/Vala/CustomWidgetSamples, in > the final example, which set's this.window (which seems right for gtk+ > and is needed later by other parts of gtk+) I get an error complaining > that "window" is read-only. > > I am not sure what I am doing wrong, but this pretty much stuffs me from > writing a custom widget implementation. Granted, I can subclass > DrawingArea (except I need a container implementation) or EventBox > (which already has 2 Gdk.Window), but it's not exactly ideal. Fixed in git master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with generating headers. Forward declaration?
On Thu, 2009-06-11 at 22:27 -0400, Sam Danielson wrote:
> I have a convenience library written in Vala so I need to generate
> headers. There are a few circular dependencies and adding the -H
> switch to valac causes something like this.
>
> libsqlpilot/flight.vala:8.10-8.17: error: The type name `Aircraft'
> could not be found
> public Aircraft? aircraft {
>
> The convenience library compiles without -H but then it isn't of much
> use for the rest of the project.
If I understand you correctly, you only get the above error message if
you use -H. In that case, this is certainly a bug. Can you provide
instructions how to reproduce the issue?
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Owned method parameters
On Wed, 2009-06-10 at 19:32 +0200, Jiří Zárevúcky wrote: > Hello, I've noticed a strange thing about the "owned" keyword. > > It works differently (and completely uselessly) on method parameters, > then it does when assigning. I'm curious whether that's intentional. > > It references the object in the call, and unreferences on the end of > the method. I really don't see why anyone would want to do that, as > weak parameter works exactly the same without the ref/unref overhead. > Even if it was intentional, to ensure lifetime of the passed object, > it would be IMHO better to reference it on the beginning of the > method, not in the call (it could confuse C programmer using the > class). > > Anyway, I don't think it's wise to make the behavior different in > those two cases. The behavior is quite consistent. Passing a value as a method argument corresponds to assigning the value to a local variable (=> ref), and the end of the method body corresponds to the end of the scope of a local variable (=> unref). Anyway, owned parameters are not intended to be used in Vala code. The main use case is to make it possible to bind C libraries with unusual memory management requirements. And in those cases we really need the current owned parameter semantics, everything else will either leak or crash. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] DBus.ObjectPath as DBus output parameter
On Tue, 2009-06-09 at 16:27 +0200, Jens Kristian Jensen wrote: > MediaPlayerManager.getDefaultMediaPlayer(MediaPlayerProxy); Try the following: MediaPlayerManager.getDefaultMediaPlayer(out MediaPlayerProxy); Alternatively, you can also use it as return value: MediaPlayerProxy = MediaPlayerManager.getDefaultMediaPlayer(); Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] fix a typo in the gsl.vapi
On Mon, 2009-05-25 at 14:12 +0200, Picca Frédéric-Emmanuel wrote: > Hello > > A trivial fix. Thanks, applied. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Problems with virtual extern methods.
On Mon, 2009-06-01 at 05:23 -0400, Yu Feng wrote: > Think about implementing the GtkBuildable interface(the interface > itself) with VALA. > > If the interface definition is written in VALA to take the advantages of > Vala, several of the accessor functions have to be supplied in C because > they selectively chain down to derived implementations based on whether > the instance is a GtkBuildable or not. Manually looking up the vtable is > too much for VALA. Can you point me to the code where GtkBuildable functions accept instances not implementing GtkBuildable? From a quick glance at the code, all the virtual method wrappers appear to contain g_return_if_fail (GTK_IS_BUILDABLE (buildable)); Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Tiny patch regarding gdk-x11 vapi.
On Sat, 2009-05-30 at 18:30 -0300, Alexandre Moreira wrote: > I am dealing with the new x11 binding and a few things (trying to port > a System Tray manager to Vala) and I found that there is (what I > believe to be) a tiny mistake in gdk-x11 vapi files. > > Gdk.x11_screen_get_xscreen is returning a Gdk.Screen, where it should > return a X.Screen, so I'm sending you the simplest patch possible: > changing Gdk to X Thanks for the patch. gdk-x11-2.0.vapi is - like most .vapi files - generated from files in vapi/packages/ as indicated on the first line of the .vapi file. This means that we should update the input files and regenerate the .vapi, instead of directly modifying the .vapi file. I've pushed updated bindings to git master, let me know if there are more issues. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Enhance X11 bindings and fix some cnames
On Sun, 2009-05-31 at 14:48 -0400, Michael B. Trausch wrote: > (Resending a modified patch, per juergbi.) > > This patch fixes cnames for the X11 bindings and provides bindings for > new methods which came from my original bindings that I wrote for > AllTray earlier this year. Thanks, pushed. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Writing to existing file
On Sun, 2009-05-31 at 11:36 +0200, Joss 4 wrote: > What I want is to change this line > var file_stream = file.create (FileCreateFlags.NONE, null); to > something like > > var file_stream = file.open (); > var data_stream = new DataOutputStream (file_stream); > > How can I accomplish this ? Take a look at GLib.File.append_to[1][2]. Jürg [1] http://valadoc.org/?pkg=gio-2.0&element=GLib.File.append_to [2] http://library.gnome.org/devel/gio/stable/GFile.html#g-file-append-to ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala 0.7.3 & glib <2.14
On Wed, 2009-05-27 at 22:02 +0100, Andrew Flegg wrote: > Unfortunately, 0.7.3 depends on g_regexp_split_simple - which was > introduced in glib 2.14. Unfortunately, Maemo 4 only has glib 2.12 > (Maemo 5, which is currently in the form of a beta SDK has glib 2.14 > but isn't going to be released for current devices). > > This issue cropped up a year ago: > > http://mail.gnome.org/archives/vala-list/2008-March/msg00061.html > > Then, the code in valac to rely on the regexp functions was backed > out. Is that feasible here, or do I need to start maintaining a patch > set for glib 2.12 compatibility (a lot more work than simply packaging > it :-/)? I've applied a patch by Mark Lee to fix this, GLib 2.12 compatibility should now be restored in master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.3 - Compiler for the GObject type system
We are pleased to announce version 0.7.3 of Vala, a compiler for the GObject type system. Vala 0.7.3 is now available for download at: http://download.gnome.org/sources/vala/0.7/ Changes since 0.7.2 * Add initial support for POSIX profile. * Add --vapi and --gir commandline options. * Add initial x11, xcb, and cairo-xcb bindings. * Many bug fixes and binding updates. Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following: * Interfaces * Properties * Signals * Foreach * Lambda expressions * Type inference for local variables * Generics * Non-null types * Assisted memory management * Exception handling Vala is designed to allow access to existing C libraries, especially GObject-based libraries, without the need for runtime bindings. All that is needed to use a library with Vala is an API file, containing the class and method declarations in Vala syntax. Vala currently comes with bindings for GLib and GTK+. It's planned to provide generated bindings for the full GNOME Platform at a later stage. Using classes and methods written in Vala from an application written in C is not difficult. The Vala library only has to install the generated header files and C applications may then access the GObject-based API of the Vala library as usual. It should also be easily possible to write a bindings generator for access to Vala libraries from applications written in e.g. C# as the Vala parser is written as a library, so that all compile-time information is available when generating a binding. More information about Vala is available at http://live.gnome.org/Vala Jürg Billeter ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] more posix for 0.7.3 release
Hi Mickey, On Sat, 2009-05-16 at 01:06 +0200, Michael 'Mickey' Lauer wrote: > thanks for applying all the posix enhancements, I could reduce my diff a lot > :) > > Here's some more which you might want to review, on top of master: > > http://git.freesmartphone.org/?p=vala- > lang.git;a=shortlog;h=refs/heads/mickey/0.7/posix Thanks for the patches. I've applied two of the four new commits. TIOCM_* and ptsname_r appear to be Linux and GNU-specific, respectively. Maybe it makes more sense to add them to the linux vapi. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How to get the local variables of a method?
Hi, On Sat, 2009-05-09 at 23:32 +0200, gege2061 wrote: > I continu my learning of the vala parser. > > I seek to get the local variables of a method. I tested > Method.body.get_local_variables() but the list is empty. > > What is the good way? Local variables have block scope, which means that you might need to call get_local_variables() on a child block of the method body. If you want to list all local variables in a method, you need to iterate over all block children and call get_local_variables() on each. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vapigen errors?
On Sun, 2009-05-10 at 00:05 +0200, Robert Palmqvist wrote: > On Sat, May 9, 2009 at 3:45 PM, Jürg Billeter wrote: > This looks as if you're mixing vapigen and libvala of > different > versions. Make sure you have only one version installed, > fix /etc/ld.so.conf, and/or set LD_LIBRARY_PATH. > > > Thanks Jũrg, that was my initial thought based on the following posts; > [1] & [2]. It looks like I'm running into a similar situation but I > can't figure out why. I could "buy" the warning about > GeeCollectionObject if I only could verify that I got different > versions indeed (but I can't, see dump below). Any other thoughts? Can you run `ldd $(which vapigen)' to check whether it actually uses the libvala.so from the package? Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vapigen errors?
Hi, On Sat, 2009-05-09 at 15:06 +0200, Robert Palmqvist wrote: > someu...@somehost:~$ vapigen --library libexif libexif/libexif.gi > > (vapigen:23894): GLib-GObject-WARNING **: cannot register existing > type `GeeCollectionObject' This looks as if you're mixing vapigen and libvala of different versions. Make sure you have only one version installed, fix /etc/ld.so.conf, and/or set LD_LIBRARY_PATH. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Creating executables without glib/gobject
On Thu, 2009-03-12 at 10:37 +0100, Jürg Billeter wrote: > On Wed, 2009-03-11 at 17:46 +0800, Barry Kauler wrote: > > I am very interested in what you have done, with your "Multiboot" > > code. I'm wondering how far this can be pushed. Is it feasible to code > > in a subset of Vala/Genie such that Glib/Gobject is not required, only > > the C library, so the executable could be compiled statically with > > dietlibc? > > > > [...] > > > > I'm wondering though, would I quickly run into trouble if I started to > > write anything more than the most elementary Vala/Genie program? > > You'll hit limits quite soon if you want to use more Vala features. > Various users seem to be interested in using Vala also for non-GLib > based applications. I wouldn't be opposed to supporting, for example, a > POSIX backend where GLib would not be mandatory. However, this is not > something I will focus on for the next few months. Requiring GLib is not > an issue for most users, and there is still some work left to do before > we can consider a stable Vala release. Vala git master has a new command-line option --profile. Code compiled with valac --profile posix will not depend on GLib or GObject. However, many language features are currently not supported with the POSIX profile. I'm still not planning to really work on this, however, now that the basic infrastructure is there, I'd certainly accept patches to make it more useful. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] error domain constant names
On Fri, 2009-05-08 at 13:05 +0200, Michael 'Mickey' Lauer wrote: > With the recent introduction of proper dbus error marshalling courtesy Didier > Ptitjes, he and me ran into an argument about error domain constant names and > we'd like your input. > > Since the dbus error names are getting CamelCased, I think it's cleaner to > use > CamelCased names for error constants locally as well -- his position is that > it's Vala convention to use CONSTANT_NAMED error constants. > > What's your take on that? In general, I prefer consistent naming in Vala, independent of backend specifics such as C or D-Bus conventions. Following that, I'd agree with Didier that CONSTANT_NAMED should be used. We should certainly support overriding the default name mangling with an attribute, though. However, I understand that such name mangling should be avoided wherever possible as there are various issues with it like name conflicts and D-Bus services that don't follow the D-Bus conventions. I don't think there is a perfect solution for this. Unless we change the D-Bus method name mangling we already do in Vala, we should follow the same path with D-Bus errors, though. It doesn't make sense to do something different for methods and errors here. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.2 - Compiler for the GObject type system
We are pleased to announce version 0.7.2 of Vala, a compiler for the GObject type system. Vala 0.7.2 is now available for download at: http://download.gnome.org/sources/vala/0.7/ Changes since 0.7.1 * Improvements to the .gir reader and writer (Didier Ptitjes). * Many bug fixes and binding updates. Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C. valac, the Vala compiler, is a self-hosting compiler that translates Vala source code into C source and header files. It uses the GObject type system to create classes and interfaces declared in the Vala source code. The syntax of Vala is similar to C#, modified to better fit the GObject type system. Vala supports modern language features as the following: * Interfaces * Properties * Signals * Foreach * Lambda expressions * Type inference for local variables * Generics * Non-null types * Assisted memory management * Exception handling Vala is designed to allow access to existing C libraries, especially GObject-based libraries, without the need for runtime bindings. All that is needed to use a library with Vala is an API file, containing the class and method declarations in Vala syntax. Vala currently comes with bindings for GLib and GTK+. It's planned to provide generated bindings for the full GNOME Platform at a later stage. Using classes and methods written in Vala from an application written in C is not difficult. The Vala library only has to install the generated header files and C applications may then access the GObject-based API of the Vala library as usual. It should also be easily possible to write a bindings generator for access to Vala libraries from applications written in e.g. C# as the Vala parser is written as a library, so that all compile-time information is available when generating a binding. More information about Vala is available at http://live.gnome.org/Vala Jürg Billeter ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] preprocessor rules
On Thu, 2009-04-23 at 12:47 +0200, pancake wrote: > In vala 0.7 we have some preprocessor rules '#if','#else','#endif'...But > looks that it can only work with > variables, so if i do: > > [...] > Are there plans to support numeric values in preprocessing conditionals? There are no plans for numeric values atm, however, boolean values already work: #if false #if true HTH, Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.1 - Compiler for the GObject type system
We are pleased to announce version 0.7.1 of Vala, a compiler for the
GObject type system.
Vala 0.7.1 is now available for download at:
http://download.gnome.org/sources/vala/0.7/
Changes since 0.7.0
* Introduce new syntax to connect/disconnect signal handlers.
* Add experimental support for fixed-length arrays.
* Update Genie parser (Jamie McCracken).
* Updates to the GLib, Cairo, GTK+, GStreamer, and POSIX bindings.
* Many bug fixes.
Vala is a new programming language that aims to bring modern programming
language features to GNOME developers without imposing any additional
runtime requirements and without using a different ABI compared to
applications and libraries written in C.
valac, the Vala compiler, is a self-hosting compiler that translates
Vala source code into C source and header files. It uses the GObject
type system to create classes and interfaces declared in the Vala source
code.
The syntax of Vala is similar to C#, modified to better fit the GObject
type system. Vala supports modern language features as the following:
* Interfaces
* Properties
* Signals
* Foreach
* Lambda expressions
* Type inference for local variables
* Generics
* Non-null types
* Assisted memory management
* Exception handling
Vala is designed to allow access to existing C libraries, especially
GObject-based libraries, without the need for runtime bindings. All that
is needed to use a library with Vala is an API file, containing the class
and method declarations in Vala syntax. Vala currently comes with
bindings for GLib and GTK+. It's planned to provide generated bindings for
the full GNOME Platform at a later stage.
Using classes and methods written in Vala from an application written in
C is not difficult. The Vala library only has to install the generated
header files and C applications may then access the GObject-based API of
the Vala library as usual. It should also be easily possible to write a
bindings generator for access to Vala libraries from applications
written in e.g. C# as the Vala parser is written as a library, so that
all compile-time information is available when generating a binding.
More information about Vala is available at
http://live.gnome.org/Vala
The Vala Team
Jürg Billeter and Raffaele Sandrini
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
On Thu, 2009-04-16 at 21:09 +0200, Ralf Wildenhues wrote: > * Jürg Billeter wrote on Thu, Apr 16, 2009 at 09:02:30PM CEST: > > On Thu, 2009-04-16 at 20:49 +0200, Ralf Wildenhues wrote: > > > bin_PROGRAMS = foo > > > foo_SOURCES = foo1.vala foo2.vala > > > foo_LDADD = libbar.a > > > noinst_LIBRARIES = libbar.a > > > libbar_a_SOURCES = bar1.vala bar2.vala > > > > > > How would valac cope with the necessarily separate invocations for > > > foo*.vala and bar*.vala? And what happens if you try to put vala > > > code into shared libraries, and use them from other vala code? > > > > In this case you instruct valac to generate a bar.vapi and a bar.h file > > and use those files in the program by specifying > > > > libbar_a_VALAFLAGS = --library bar -H bar.h > > foo_VALAFLAGS = bar.vapi > > > > A .vapi file contains declarations for Vala libraries, similar to a .h > > file for C libraries. > > How is the semantic relationship between the .vapi name and its library? > s/^lib//; s/\.a$//; s/$/.vapi/? > > What about shared libraries, do they have .vapi's, too? Yes, shared libraries have .vapi files, too. They are installed into /usr/share/vala/vapi/ by default. The .so name and the .vapi name do not need to match in any way, the convention for shared libraries is to use the pkg-config name, if applicable. When writing the .vapi file, the compiler just uses the argument of the --library option and appends .vapi. > What if I want to build one big shared (or static) library from a set of > convenience archives (uninstalled .a libraries with PIC code)? Do you > have means to generate a .vapi for the big library from the .vapi's of > the several small ones (plus maybe a couple of loose objects, too)? That's where it starts getting a bit tricky. While generating the big .vapi file is as simple as concatenating the .vapi files of the convenience libraries, I don't know how we can avoid a manual `cat' rule without making it a lot more complex. Thanks, Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
Hi Ralf, On Thu, 2009-04-16 at 20:49 +0200, Ralf Wildenhues wrote: > * Jürg Billeter wrote on Wed, Apr 15, 2009 at 08:56:44PM CEST: > > On Wed, 2009-04-15 at 20:42 +0200, Ralf Wildenhues wrote: > > > or even > > > valac -C b.vala > > > valac -C e.vala > > > > This would not work, valac requires all Vala source files of the same > > program / library on the same commandline. The reason is that the source > > files can depend on each other, but there is no header/include > > mechanism. > > Hmm. What if I do something like this: > > bin_PROGRAMS = foo > foo_SOURCES = foo1.vala foo2.vala > foo_LDADD = libbar.a > noinst_LIBRARIES = libbar.a > libbar_a_SOURCES = bar1.vala bar2.vala > > How would valac cope with the necessarily separate invocations for > foo*.vala and bar*.vala? And what happens if you try to put vala > code into shared libraries, and use them from other vala code? In this case you instruct valac to generate a bar.vapi and a bar.h file and use those files in the program by specifying libbar_a_VALAFLAGS = --library bar -H bar.h foo_VALAFLAGS = bar.vapi A .vapi file contains declarations for Vala libraries, similar to a .h file for C libraries. Thanks, Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
Hi Ralf, On Wed, 2009-04-15 at 20:42 +0200, Ralf Wildenhues wrote: > I'm looking at adding per-target flag support for vala sources. > > Say I have baz.vala and want to create from that > foo-baz.c foo-baz.h > > in one valac invocation, as well as > bar-baz.c bar-baz.h > > in another 'valac -D BAR' invocation. Is there some flag I can pass to > valac that will use these output names for me? If yes, does it do so > without generating intermediate baz.c baz.h files or any other temporary > files that have a name which would conflict with parallel make -jN > execution? valac does not currently support any transformation on the output names of the .c files. It's not as easy as a simple -o option because you have multiple input and output files per invocation in general (see below). If you think it would make sense to add a --suffix option or similar to valac, I could certainly take a look at it. > Also, I see that your vala compile passes all sources to valac. Is that > intentional (or just because that was good enough)? I.e., if you have > bin_PROGRAMS = foo > foo_SOURCES = a.c b.vala c.l d.java e.vala > > do you really want to invoke > valac -C a.c b.vala c.l d.java e.vala That was not intentional. valac won't mind unnecessary .c files but will reject files with other extensions. > rather than > valac -C b.vala e.vala This would be the correct commandline. > or even > valac -C b.vala > valac -C e.vala This would not work, valac requires all Vala source files of the same program / library on the same commandline. The reason is that the source files can depend on each other, but there is no header/include mechanism. > ? And if per-target flags are used with multiple input files, how would > I specify the renamed output files? We'd probably need to add a new commandline option to valac as suggested in the first paragraph. Thanks, Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Signal connect syntax
The syntax for connecting and disconnecting signal handlers using += and -= has been inherited from the C# syntax. As described in bug 566847 [1], using these operators does not seem appropriate for signals. Therefore, the syntax has now been deprecated by foo.clicked.connect (handler); foo.clicked.disconnect (handler); The old syntax still works and will continue to be supported for the foreseeable future to not break existing code. A future compiler version might print a warning when not using --enable-deprecated. Jürg [1] http://bugzilla.gnome.org/show_bug.cgi?id=566847 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Delegates without target
Callbacks in C libraries usually have a user_data parameter, which is used by Vala to pass the object of an instance method. However, some callbacks do not have a user_data parameter. Vala required bindings to use the `static' modifier for the delegate to let the compiler know about this limitation. The `static' modifier for delegates has been deprecated now by [CCode (has_target = false)] The rationale for the change can be found in bug 526549 [1]. The `static' modifier still works, but the compiler will print a warning in future versions when not using --enable-deprecated. Jürg [1] http://bugzilla.gnome.org/show_bug.cgi?id=526549 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Regression in git master: array dup wants 1.8 TB of RAM
Hi Mike, On Mon, 2009-04-13 at 15:35 -0400, Michael B. Trausch wrote: > Today I updated my local working tree of Vala, built and installed it, > and was unable to build the application I am working on; it wanted 1.8 > TB of RAM to copy an array (that was the best I could isolate out of > the issue looking at gdb output). > > I did a "git bisect" on the Vala repository and have identified this > commit (74cb5c7d) as the cause: > > > http://git.gnome.org/cgit/vala/commit/?id=74cb5c7d6d1df95f7779f84b58f31ceeab5417ad I've just fixed a regression introduced by this commit, which is likely the reason for the crash you're experiencing. Let me know if it works fine again with vala master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.6.1 - Compiler for the GObject type system
On Mon, 2009-04-13 at 02:38 +1000, devros wrote: > Are we going backwards in releases? I though this should be 7.1? Did I > miss something? 0.6.1 is just a minor bugfix release from the stable 0.6 branch. As Vala projects require small changes in the build system to support Vala 0.7 and 0.7.0 still has a few regressions, some projects may still depend on Vala 0.6. A Vala 0.7.1 release will follow soon as well. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.6.1 - Compiler for the GObject type system
We are pleased to announce version 0.6.1 of Vala, a compiler for the
GObject type system.
Vala 0.6.1 is now available for download at:
http://download.gnome.org/sources/vala/0.6/
Changes since 0.6.0
* Updates to the GLib, Cairo, GTK+, GStreamer, and POSIX bindings.
* Minor bug fixes.
Vala is a new programming language that aims to bring modern programming
language features to GNOME developers without imposing any additional
runtime requirements and without using a different ABI compared to
applications and libraries written in C.
valac, the Vala compiler, is a self-hosting compiler that translates
Vala source code into C source and header files. It uses the GObject
type system to create classes and interfaces declared in the Vala source
code.
The syntax of Vala is similar to C#, modified to better fit the GObject
type system. Vala supports modern language features as the following:
* Interfaces
* Properties
* Signals
* Foreach
* Lambda expressions
* Type inference for local variables
* Generics
* Non-null types
* Assisted memory management
* Exception handling
Vala is designed to allow access to existing C libraries, especially
GObject-based libraries, without the need for runtime bindings. All that
is needed to use a library with Vala is an API file, containing the class
and method declarations in Vala syntax. Vala currently comes with
bindings for GLib and GTK+. It's planned to provide generated bindings for
the full GNOME Platform at a later stage.
Using classes and methods written in Vala from an application written in
C is not difficult. The Vala library only has to install the generated
header files and C applications may then access the GObject-based API of
the Vala library as usual. It should also be easily possible to write a
bindings generator for access to Vala libraries from applications
written in e.g. C# as the Vala parser is written as a library, so that
all compile-time information is available when generating a binding.
More information about Vala is available at
http://live.gnome.org/Vala
The Vala Team
Jürg Billeter and Raffaele Sandrini
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
Hi Ralf, On Tue, 2009-04-07 at 23:08 +0200, Ralf Wildenhues wrote: > Other than that, I haven't yet gotten around to get my system up to date > in order to support Vala 0.7 yet. Would you be so nice as to post > verbose log output for all the vala tests? That is, just > cd tests > for t in path/to/source/tree/tests/*vala*.test; do > $t > done 2>&1 | tee log > > and post "log", preferably gzip'ed. That will allow me to finish review > before finishing my system. I've attached the verbose test log. Thanks, Jürg log.gz Description: GNU Zip compressed data ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.0 - Compiler for the GObject type system
On Mon, 2009-04-06 at 01:52 -0400, Yu Feng wrote: > On Sun, 2009-04-05 at 17:54 +0200, Jürg Billeter wrote: > > * Support conditional compilation. > > > and the usage of the conditional compilation? The FAQ[1] has been updated with an example. Jürg [1] http://live.gnome.org/Vala/FAQ#head-842bf5904d24f6af1317fdd61dd96a0d0cd58a17 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [ANNOUNCE] Vala 0.7.0 - Compiler for the GObject type system
On Tue, 2009-04-07 at 01:50 -0400, Yu Feng wrote: > Vala 0.7.0 is affected by Bug 578191 which may interfere with many > programs written in VALA. > Would you please take a look at the patch before the next major/minor > release? The master branch is self-compilable with the patch applied. This should already be fixed in master for two days as commented on the bug. Let me know if there are still issues. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] more posix patches
On Sun, 2009-04-05 at 10:27 +0200, Michael 'Mickey' Lauer wrote: > http://git.freesmartphone.org/?p=vala- > lang.git;a=shortlog;h=refs/heads/mickey/0.6/posix > > Please pick the top three, if you find suitable. They're on top of the 0.6 > branch. Thanks, pushed to master. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] Add standard C/POSIX methods exit() and abort().
On Sun, 2009-04-05 at 03:44 -0400, Michael B. Trausch wrote: > Hello, here is a patch that adds exit() and abort() to posix.vapi: Thanks, pushed. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] How do I call functions which have a "ref" variable as one of their argument
On Tue, 2009-04-07 at 15:19 +0200, Jaap A. Haitsma wrote:
> I've wanted to restart working on my vala branch of cheese. In the
> meantime vala has received quite some changes. Therefore it does not
> compile anymore. The main problem I have are "ref" variables. For
> example with the text_extents method of Cairo
>
> TextExtents extents;
> text_extents ("hello", ref extents);
>
> This does not compile because the compiler says.
> "use of possibly unassigned local variable `extents' text_extents
> ("hello", ref extents);"
>
> What should I do here or is it a bug in text_extents?
This is a bug in text_extents, it should be an `out' parameter (should
have been from the beginning). Fixed in master.
> RawError dbus_error;
>
> dbus_error.init ();
> complains about the fact that dbus_error is unassigned.
That is a bad binding, improved now in master:
// calls dbus_error_init in the generated code
var dbus_error = RawError ();
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.7.0 - Compiler for the GObject type system
We are pleased to announce version 0.7.0 of Vala, a compiler for the
GObject type system.
Vala 0.7.0 is now available for download at:
http://download.gnome.org/sources/vala/0.7/
Changes since 0.6.0
* Do not generate header files unless requested by the -H commandline
option. This requires changes in the build system of Vala projects.
* Support conditional compilation.
Vala is a new programming language that aims to bring modern programming
language features to GNOME developers without imposing any additional
runtime requirements and without using a different ABI compared to
applications and libraries written in C.
valac, the Vala compiler, is a self-hosting compiler that translates
Vala source code into C source and header files. It uses the GObject
type system to create classes and interfaces declared in the Vala source
code.
The syntax of Vala is similar to C#, modified to better fit the GObject
type system. Vala supports modern language features as the following:
* Interfaces
* Properties
* Signals
* Foreach
* Lambda expressions
* Type inference for local variables
* Generics
* Non-null types
* Assisted memory management
* Exception handling
Vala is designed to allow access to existing C libraries, especially
GObject-based libraries, without the need for runtime bindings. All that
is needed to use a library with Vala is an API file, containing the class
and method declarations in Vala syntax. Vala currently comes with
bindings for GLib and GTK+. It's planned to provide generated bindings for
the full GNOME Platform at a later stage.
Using classes and methods written in Vala from an application written in
C is not difficult. The Vala library only has to install the generated
header files and C applications may then access the GObject-based API of
the Vala library as usual. It should also be easily possible to write a
bindings generator for access to Vala libraries from applications
written in e.g. C# as the Vala parser is written as a library, so that
all compile-time information is available when generating a binding.
More information about Vala is available at
http://live.gnome.org/Vala
The Vala Team
Jürg Billeter and Raffaele Sandrini
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] trunk broken?
On Wed, 2009-04-01 at 18:14 +0200, Leonti Bielski wrote: > So I'm not the only one :) > I have similar errors with structs too: > > http://pastebin.com/m4693867a > > I'm using Enlightenment Elementary bindings for Vala. This is an unrelated issue. You have to use the new [CCode (delegate_target = false)] attribute for the delegate fields in the binding to prevent the compile errors. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] trunk broken?
On Wed, 2009-04-01 at 11:07 -0400, Feng Yu wrote: > I am working on a fix for struct member method as a delegate. But the > test code entirely fails to compile with lots of gcc errors. I notice > that the types are now declared in both of .h and .c files. and those > in .c files are incomplete. You derive from GLib.Boxed, which is not supported as it is not a real class. If you want to declare a type that is registered as GBoxed in the GObject type system, use a struct in Vala. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala support for automake
On Wed, 2009-04-01 at 01:02 -0400, Yu Feng wrote: > If a VALA package depends on the features provided in the patch, will > the distributed tarball(make dist) be compilable on a system with a > unpatched automake? Source tarballs do not require automake at all (nor autoconf or libtool) just to build and install the package. Automake is only required for development and building from VCS. > Is VALA itself going to make use of the features once the they are > accepted in the automake upstream? If so, when? > There might be problems, since some distributions doesn't updated their > automakes timely. (eg RHEL5 didn't even update automake to 1.10.x) I'd like to switch the vala package itself some time after a stable automake version with Vala support has been released. I won't switch as long as it's not widespread, but I don't think we should wait until enterprise distros have upgraded as it's only needed for development. I estimate that we can switch in about half a year with the release of Fedora 12 and Ubuntu 9.10. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Vala support for automake
I've updated the Vala support patches initially written by Mathias
Hasselmann to fix a few issues and to conform to the reworked header
file generation in Vala 0.7. It appears to work well with a simple test
project including correct distcheck and maintainer-clean functionality.
I didn't get around yet to test it with larger projects, but I'm not
aware of outstanding issues in the patch.
The Vala support is intended to be used with the upcoming Vala 0.7
release series (git master) and all later versions. Earlier versions may
work with some limitations (e.g., only recursive make). Vala 0.7.0 is
expected to be released this week.
Regards,
Jürg
>From e98d9faf34fbb9ab2e719c22beb968e386d06425 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?J=C3=BCrg=20Billeter?=
Date: Tue, 31 Mar 2009 10:08:24 +0200
Subject: [PATCH] Initial support for the Vala programming language.
* automake.in: Add %known_libraries, lang_vala_rewrite,
lang_vala_finish and lang_vala_target_hook to support the Vala
programming language. Register Vala language hooks.
* doc/automake.texi, NEWS: Document Vala support.
* lib/am/vala.am: Empty rules file to prevent creation of depend2
based rules for Vala code.
* lib/am/Makefile.am (dist_am_DATA): Add vala.am.
* m4/vala.m4: Provide AM_PROG_VALAC for detecting the Vala compiler.
* m4/Makefile.am (dist_m4data_DATA): Add vala.m4.
* tests/vala.test: Test Vala support.
* tests/vala1.test: Test .c file generation.
* tests/vala2.test: Test recursive make.
* tests/vala3.test: Test non-recursive make.
* tests/vala4.test: Test AM_PROG_VALAC.
* tests/Makefile.am: Update.
Based on patch by Mathias Hasselmann.
---
ChangeLog | 20 ++
NEWS |2 +
automake.in| 99 +++-
doc/automake.texi | 52 +++
lib/am/Makefile.am |1 +
lib/am/Makefile.in |1 +
lib/am/vala.am | 17 +
m4/Makefile.am |3 +-
m4/Makefile.in |3 +-
m4/vala.m4 | 29 +++
tests/Makefile.am |5 +++
tests/Makefile.in |5 +++
tests/vala.test| 59 +++
tests/vala1.test | 58 ++
tests/vala2.test | 70
tests/vala3.test | 64 +
tests/vala4.test | 61
17 files changed, 546 insertions(+), 3 deletions(-)
create mode 100644 lib/am/vala.am
create mode 100644 m4/vala.m4
create mode 100755 tests/vala.test
create mode 100755 tests/vala1.test
create mode 100755 tests/vala2.test
create mode 100755 tests/vala3.test
create mode 100755 tests/vala4.test
diff --git a/ChangeLog b/ChangeLog
index 3e08fe6..cadf637 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,23 @@
+2009-03-31 Jürg Billeter
+
+ Initial support for the Vala programming language.
+ * automake.in: Add %known_libraries, lang_vala_rewrite,
+ lang_vala_finish and lang_vala_target_hook to support the Vala
+ programming language. Register Vala language hooks.
+ * doc/automake.texi, NEWS: Document Vala support.
+ * lib/am/vala.am: Empty rules file to prevent creation of depend2
+ based rules for Vala code.
+ * lib/am/Makefile.am (dist_am_DATA): Add vala.am.
+ * m4/vala.m4: Provide AM_PROG_VALAC for detecting the Vala compiler.
+ * m4/Makefile.am (dist_m4data_DATA): Add vala.m4.
+ * tests/vala.test: Test Vala support.
+ * tests/vala1.test: Test .c file generation.
+ * tests/vala2.test: Test recursive make.
+ * tests/vala3.test: Test non-recursive make.
+ * tests/vala4.test: Test AM_PROG_VALAC.
+ * tests/Makefile.am: Update.
+ Based on patch by Mathias Hasselmann.
+
2009-03-29 Ralf Wildenhues
Rewrite maintainer-check in separate tests, parallelizable.
diff --git a/NEWS b/NEWS
index 6b94a7c..0126a14 100644
--- a/NEWS
+++ b/NEWS
@@ -42,6 +42,8 @@ New in 1.10a:
- The default source file extension (.c) can be overridden with
AM_DEFAULT_SOURCE_EXT now.
+ - Vala source files are recognized now.
+
* Miscellaneous changes:
- Automake development is done in a git repository on Savannah now, see
diff --git a/automake.in b/automake.in
index c1321f0..f5d0dac 100755
--- a/automake.in
+++ b/automake.in
@@ -112,7 +112,7 @@ sub finish ($)
my ($self) = @_;
if (defined $self->_finish)
{
- &{$self->_finish} ();
+ &{$self->_finish} (@_);
}
}
@@ -569,6 +569,7 @@ my @dist_targets;
# Keep track of all programs declared in this Makefile, without
# $(EXEEXT). @substitutions@ are not listed.
my %known_programs;
+my %known_libraries;
# Keys in this hash are the basenames of files which must depend on
# ansi2knr. Values are either the empty string, or the directory in
@@ -699,6 +700,7 @@ sub initialize_per_input ()
@dist_targets = ();
%known_programs = ();
+%known_libraries= ();
%de_ansi_files = ();
@@ -802,6 +804,21 @@ register_language ('
Re: [Vala] Declare an 'in-place' array?
On Mon, 2009-03-30 at 17:09 -0400, Feng Yu wrote:
> Is there a way to declare an 'in-place' array?
> By 'in-place' I mean an array allocated on the stack or within the struct.
>
> struct A {
> int c[10];
> }
> int main() {
>int a[10];
> }
>
> c and a are 'in-place'.
This is not supported yet but planned[1] for a future version.
Jürg
[1] http://bugzilla.gnome.org/show_bug.cgi?id=492481
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] [ANNOUNCE] Vala 0.6.0 - Compiler for the GObject type system
We are pleased to announce version 0.6.0 of Vala, a compiler for the
GObject type system.
Vala 0.6.0 is now available for download at:
http://download.gnome.org/sources/vala/0.6/
Changes since 0.5.7
* Improvements to the .gir reader and writer (Didier Ptitjes).
* Add librsvg-2.0 bindings (Evan Nemerson).
* Add Maemo libosso bindings (Jukka-Pekka Iivonen).
* Add V4L2 bindings (Matías De la Puente).
* Many bug fixes.
Vala is a new programming language that aims to bring modern programming
language features to GNOME developers without imposing any additional
runtime requirements and without using a different ABI compared to
applications and libraries written in C.
valac, the Vala compiler, is a self-hosting compiler that translates
Vala source code into C source and header files. It uses the GObject
type system to create classes and interfaces declared in the Vala source
code.
The syntax of Vala is similar to C#, modified to better fit the GObject
type system. Vala supports modern language features as the following:
* Interfaces
* Properties
* Signals
* Foreach
* Lambda expressions
* Type inference for local variables
* Generics
* Non-null types
* Assisted memory management
* Exception handling
Vala is designed to allow access to existing C libraries, especially
GObject-based libraries, without the need for runtime bindings. All that
is needed to use a library with Vala is an API file, containing the class
and method declarations in Vala syntax. Vala currently comes with
bindings for GLib and GTK+. It's planned to provide generated bindings for
the full GNOME Platform at a later stage.
Using classes and methods written in Vala from an application written in
C is not difficult. The Vala library only has to install the generated
header files and C applications may then access the GObject-based API of
the Vala library as usual. It should also be easily possible to write a
bindings generator for access to Vala libraries from applications
written in e.g. C# as the Vala parser is written as a library, so that
all compile-time information is available when generating a binding.
More information about Vala is available at
http://live.gnome.org/Vala
The Vala Team
Jürg Billeter and Raffaele Sandrini
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Conditional compilation: Passing #ifdefs through to generated C code
On Thu, 2009-03-26 at 18:13 +, Maciej Piechotka wrote:
> Jürg Billeter bitron.ch> writes:
>
> > I understand the issue. Unfortunately, it's not easy to solve. One issue
> > is that you might need multiple #if in the generated code for a single
> > #if in the Vala code - e.g. for #include directives. It would also
> > require the Vala compiler to support dealing with multiple declarations
> > of the same method for different conditions, which would make semantic
> > and flow analysis a lot more difficult.
> >
> > I'd be happy to hear proposals how we could solve this in a
> > non-intrusive way.
> >
>
> May be static if or something like that?
>
> void my_method () {
> [StaticIf]
> if (vala.pkg.gtk+-2.0.version > 2.4.0") {
> // Use new gtk+
> } else {
> // Use legacy gtk+
> }
> }
The exact syntax is not the main issue. The question is how to support
conditional compilation in such a way that we can keep the conditions in
the generated C code. Otherwise, we cannot support conditionals with
projects that distribute the generated C code in the source tarballs.
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Conditional compilation: Passing #ifdefs through to generated C code
On Mon, 2009-03-23 at 20:35 -0400, Michael Terry wrote: > I'd like to know more about how to use C preprocessor commands in > Vala. I know that Vala allows some sort of conditional compilation > via [Conditional], but I'm interested in a particular use case that it > doesn't seem to really help with. > > Specifically, I have a GTK+ app, and I want to use a bit of code only > if the compile-time GTK+ version is high enough. So something like: > > #if GTK_CHECK_VERSION(2, 4, 0) > GtkFileChooserAction action; > ... > #endif > > I can have vala conditionally use a bit of code, but the conditional > is resolved at Vala-compile-time, not C-compile-time. I need > 'passthrough' conditionals that show up in the generated C code, since > my software distributes the C code in the release tarball. The > typical user just compiles the C. I understand the issue. Unfortunately, it's not easy to solve. One issue is that you might need multiple #if in the generated code for a single #if in the Vala code - e.g. for #include directives. It would also require the Vala compiler to support dealing with multiple declarations of the same method for different conditions, which would make semantic and flow analysis a lot more difficult. I'd be happy to hear proposals how we could solve this in a non-intrusive way. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] misc. patches
On Fri, 2009-03-13 at 21:21 +0100, Michael 'Mickey' Lauer wrote: > Please see attachements. Thanks, I've applied patch 2 and 3. Patch 4: I think we should use the same approach for GLib.Dir and GLib.FileStream. I tend to only support construction using the static methods, though, any objections? Patch 5: I didn't find any note about __sighandler_t in the POSIX documentation, are you sure that's not something implementation-specific as well? I only see `void (*func)(int)' as parameter type. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Creating executables without glib/gobject
On Wed, 2009-03-11 at 17:46 +0800, Barry Kauler wrote: > I am very interested in what you have done, with your "Multiboot" > code. I'm wondering how far this can be pushed. Is it feasible to code > in a subset of Vala/Genie such that Glib/Gobject is not required, only > the C library, so the executable could be compiled statically with > dietlibc? > > [...] > > I'm wondering though, would I quickly run into trouble if I started to > write anything more than the most elementary Vala/Genie program? You'll hit limits quite soon if you want to use more Vala features. Various users seem to be interested in using Vala also for non-GLib based applications. I wouldn't be opposed to supporting, for example, a POSIX backend where GLib would not be mandatory. However, this is not something I will focus on for the next few months. Requiring GLib is not an issue for most users, and there is still some work left to do before we can consider a stable Vala release. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Friend class?
On Tue, 2009-03-10 at 23:10 -0400, Yu Feng wrote: > On Tue, 2009-03-10 at 08:07 +0100, Jürg Billeter wrote: > > On Mon, 2009-03-09 at 20:36 -0400, Yu Feng wrote: > > > Dear list, > > > > > > Are friend classes available in VALA? If not, are there any particular > > > reason against it, and are there any alternatives for friend classes? > > > > There is no plan to support friend classes in Vala. The `internal' > > modifier is as close as it gets, it restricts access to the class/member > > to the current library/application. If this is not fine-grained enough, > > maybe you should consider moving some code into a separate library (can > > also be a libtool convenience library in case you're using autotools). > > > > Can a property setting be internal? I tried to added to a setter and > apparently nothing happened. Yes, this should be supported. However, internal header declarations will only vanish from the public header files once the header rework[1] has been completed. Jürg [1] http://mail.gnome.org/archives/vala-list/2009-January/msg00058.html ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Friend class?
On Mon, 2009-03-09 at 20:36 -0400, Yu Feng wrote: > Dear list, > > Are friend classes available in VALA? If not, are there any particular > reason against it, and are there any alternatives for friend classes? There is no plan to support friend classes in Vala. The `internal' modifier is as close as it gets, it restricts access to the class/member to the current library/application. If this is not fine-grained enough, maybe you should consider moving some code into a separate library (can also be a libtool convenience library in case you're using autotools). Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Vala/DBus with dict object
On Thu, 2009-02-19 at 10:49 -0300, Marcelo Boveto Shima wrote:
> But no luck yet. Now it is segfaulting at OpenSessionWithParameters
> call.
> I am using vala 0.5.6.
> am I missing something else?
The dynamic D-Bus client support still uses dbus-glib based marshalling,
which doesn't support arrays of structs. Static D-Bus client supports
this with vala master. The marshalling code for dynamic D-Bus clients
will be ported to the same code static D-Bus clients are already using.
Code snippet explaining how to use static D-Bus client support here:
[DBus (name = "org.freedesktop.ConsoleKit.Manager")]
public interface ConsoleKit.Manager : DBus.Object {
public abstract string open_session_with_parameters (Test[] parameters);
}
[...]
this.ckmanager = (ConsoleKit.Manager) conn.get_object
("org.freedesktop.ConsoleKit", "/org/freedesktop/ConsoleKit/Manager");
Jürg
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Added kill and pid_t to posix.vapi
On Fri, 2009-03-06 at 10:06 +0700, Hans Baier wrote: > 2009/3/6 Michael 'Mickey' Lauer : > > Added the IntegerType descriptor. Can we apply the attached patch then? > > > > Maybe you could consider altering glib.vapi too, > because there, Pid is defined as: GPid is a pointer, not an integer, on Windows according to GLib documentation, so we should not bind it as an integer type. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Added kill and pid_t to posix.vapi
On Thu, 2009-03-05 at 17:17 -0500, Yu Feng wrote: > Curious: > > What does rank mean? The compiler uses the rank of integer types to determine what implicit casts should be allowed. The larger the range on common platforms, the higher the rank in the bindings. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Added kill and pid_t to posix.vapi
On Fri, 2009-03-06 at 01:41 +0100, Michael 'Mickey' Lauer wrote: > Added the IntegerType descriptor. Can we apply the attached patch then? Thanks, pushed. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Added kill and pid_t to posix.vapi
On Wed, 2009-03-04 at 13:50 +0100, pancake wrote: > mmh, pid_t is not a struct, is an 'int', in which whay do you get > the (int) value of this empty struct? I would rather prefer to do > it in another way to allow vala use the 'int' nature of the pid_t type > for conversions between numbers, strings and process-id's. The IntegerType attribute should help us here: [IntegerType (rank = 6)] Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] [PATCH] posix.vapi: add remaining syslog constants
Thanks, all 4 patches applied and pushed. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
