[Vala] [ANNOUNCE] Vala 0.10.4 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.10.4 of Vala, a compiler for the
GObject type system.

Vala 0.10.4 is now available for download at:
   http://download.gnome.org/sources/vala/0.10/

Changes since 0.10.3
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala 0.11.6 How do I copy a file using GInputStream and GOutputStream?

[Jürg Billeter]

On Tue, 2011-03-01 at 18:21 +, Graham Whelan wrote:
> I'm trying to copy a file using GLib.InputStream and GLib.OutputStream
> but the copied file ends up corrupted.
> 
> Sample code:
> 
> uint8 buffer[4096];
> size_t read;
> while (true) {
>   read = input.read (buffer);
>   if (read > 0) {
>   output.write (buffer);

This should work with slicing:

output.write (buffer[0:read]);

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.11.6 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.6 of Vala, a compiler for the
GObject type system.

Vala 0.11.6 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.11.5
 * Add parse and try_parse methods to boolean and numeric types.
 * Add clutter-gtk-1.0 bindings.
 * Add pixmap-1 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] When is 0.12 coming?

[Jürg Billeter]

Hi Adam,

On Thu, 2011-02-03 at 10:12 -0800, Adam Dingle wrote:
> Is there a plan to release Vala 0.12 along with GNOME 3 in early April?  
> Or will 0.12 arrive later, or is the expected release timeframe simply 
> unknown?

Yes, Vala 0.12 will be released in time for GNOME 3.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] dova and glib

[Jürg Billeter]

On Tue, 2011-02-01 at 08:52 +, Rob Taylor wrote:
> How about, in dova mode, you automatically create dova objects wrapping
> the gobjects? Could be done explicitly (per vapi?) to make it obvious.

While this would theoretically work to some extent for Vala
applications, it would break for Vala libraries, at least when you use
GObject types in your API. It would also complicate things a lot as not
even the basic types such as strings have the same representation in the
two profiles - strings are ref-counted in Dova.

I think it makes more sense to keep the profiles separate from
language/compiler point of view and just make it easy to create Dova
bindings for GObject libraries based on gobject-introspection.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Libgee 0.6.1 - GObject collection library

[Jürg Billeter]

We are very pleased to announce version 0.6.1 of Libgee, the GObject 
collection library.

Libgee 0.6.1 is now available for download at:
http://download.gnome.org/sources/libgee/0.6/


Also please note that Libgee has its own mailing-list
http://mail.gnome.org/mailman/listinfo/libgee-list
and its own #gee IRC channel.


New in 0.6.1


 * Fix memory leaks in LinkedList.


For more information about the 0.5/0.6 release series, see:
http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
http://live.gnome.org/Libgee/Migration-0.5


Libgee is a collection library providing GObject-based interfaces and 
classes for commonly used data structures.

Libgee provides the following interfaces:

 * Iterable
   o Collection
 + List
 + Set
 + MultiSet
 + Queue
   # Deque
 * Iterator
 * Map
 * MultiMap

The ArrayList, HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList, 
PriorityQueue, TreeSet, TreeMap, TreeMultiSet, and TreeMultiMap classes 
provide a reasonable sample implementation of those interfaces. In 
addition, a set of abstract classes are provided to ease the 
implementation of new collections.

Around that, the API provide means to retrieve read-only views, 
efficient sort algorithms, simple, bi-directional or index-based mutable 
iterators depending on the collection type.

Libgee is written in Vala and can be used like any GObject-based C 
library. It's planned to provide bindings for further languages.


More information about Libgee is available at

 http://live.gnome.org/Libgee


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.10.3 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.10.3 of Vala, a compiler for the
GObject type system.

Vala 0.10.3 is now available for download at:
   http://download.gnome.org/sources/vala/0.10/

Changes since 0.10.2
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.11.5 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.5 of Vala, a compiler for the
GObject type system.

Vala 0.11.5 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.11.4
 * Add last_index_of and last_index_of_char to string class.
 * More refactoring in the code generator (Luca Bruno).
 * Improvements to the .gir writer (Michal Hruby).
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Unexpected behaviour when using interfaces.

[Jürg Billeter]

On Wed, 2011-01-19 at 21:52 +0100, Sergej Reich wrote:
> I know that calling interface methods is expensive and that it's a known issue
> in GLib but there is another problem. When a class implements an interface,
> calling methods is slow regardless whether you declare your objects as being
> instances of the class or the interface.
> 
> [...]
>
> So my question would be whether this is intentional, maybe I'm missing 
> something?
> If it is then interfaces have to be used even more carefully and you need to 
> use
> a dummy class in between the interface just to be able to use your class 
> without
> the extra overhead when the interface is not needed.

Vala follows common GLib practice where possible and in the case of
interface implementations, it's common practice to not export the method
implementations directly and always use the interface wrapper functions
instead.

I understand that this may be a performance issue, however, deviating
from common practice in that regard would work only with classes written
in Vala and require many annotations in bindings of GLib/C libraries as
they usually do not support direct calls. That's why I'd like to keep it
the way it is. The plan for the Dova profile is to allow direct access
to the method implementations for performance and other reasons.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.11.4 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.4 of Vala, a compiler for the
GObject type system.

Vala 0.11.4 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.11.3
 * Add index_of, index_of_char, and char_count to string class.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala code generation too constrained?

[Jürg Billeter]

On Tue, 2011-01-11 at 11:11 +0100, Xavier Bestel wrote:
> IMHO there should be 2 modes:
> - library mode, where conflicts are clearly and loudly shown by valac.
> - application mode, where conflicts are silently resolved via a suffix
>   or whatever clever magic some smart people invent.

The main reason that speaks against this, in my opinion, is that it
would be really confusing if your code stops working when you move it
from an application to a library, which is not that rare. Also, while C
identifier conflicts due to simple name mangling can lead to unexpected
error messages from the C compiler, they are usually really easy to work
around.

Maybe I could be convinced to optionally support this at some point,
however, there are many more important improvements we should be working
on before this, in my opinion.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.11.3 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.3 of Vala, a compiler for the
GObject type system.

Vala 0.11.3 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.11.2
 * Support BusName sender parameter in GDBus servers.
 * More refactoring in the code generator.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Potential memory leak?

[Jürg Billeter]

On Wed, 2010-12-29 at 20:45 +0100, Abderrahim Kitouni wrote:
> Hello,
 <  في ر، 29-12-2010 عند 18:34 +0100 ، كتب Alexander Krivács Schrøder:
> > Hi. I have a question.
> > 
> > If you look at the documentation for the
> > gtk_source_completion_proposal_get_text () C function:
> > http://library.gnome.org/devel/gtksourceview/2.9/GtkSourceCompletionProposal.html#gtk-source-completion-proposal-get-text
> > 
> > It says "The returned string must be freed with g_free()". 
> [...]
> > Isn't this a memory leak?
> It is. But this is not intentional : the bindings are auto generated and
> often return values are marked as unowned while they should be freed.
> 
> Feel free to file a bug.

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.10.2 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.10.2 of Vala, a compiler for the
GObject type system.

Vala 0.10.2 is now available for download at:
   http://download.gnome.org/sources/vala/0.10/

Changes since 0.10.1
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Array.length

[Jürg Billeter]

On Tue, 2010-12-07 at 00:34 +0100, Aleksander Wabik wrote:
> Seems like https://bugzilla.gnome.org/show_bug.cgi?id=585847 , but it
> is claimed to be fixed. Maybe some corner case?

It was fixed in master/0.11, not in 0.10. Unfortunately, the fix does
not apply to 0.10.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Interfaces - why do they must have prerequisites?

[Jürg Billeter]

On Mon, 2010-12-06 at 01:25 +0100, Aleksander Wabik wrote:
> As classes not inheriting from Object have different ref and unref
> functions (Foo will have foo_ref, and foo_unref, Bar will have bar_ref
> and bar_unref), if an object is referenced by the reference of interface
> type, there's no possibility to ref and unref this object unless
> knowing what ref and unref functions to use! This may be the cause why
> creating references of interface type fails, and passing interface type
> references to functions do not fail (there's no ref then).
> 
> This is a serious flaw to the object system IMO. It means, that there's
> *no way* of having two classes that do not have common ancestor but
> implement the same interface. Possible ways to solve this problem:

While I also do not like that aspect of the object system, it's not
really something that Vala can change. The object system is defined by
GType/GObject, not by Vala. We couldn't use anything like virtual
ref/unref functions as we can't expect non-Vala libraries to provide
them.

My recommendation is to not create too many fundamental classes. By
default you should always consider using GObject as base class. If
that's not an option for performance or other reasons, create a single
fundamental (Mini)Object class in your application or library and use
that as base for all other classes and interfaces in the same (part of
the) codebase.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Versioned vala, and vapi directory locations

[Jürg Billeter]

Hi Michel,

On Wed, 2010-11-17 at 12:01 +, Michel Alexandre Salim wrote:
> Since vala 0.9.5 Vala installs its VAPI binding files in $PREFIX/share/
> vala-$APIVER/vapi .
> 
> Is this the only directory scanned, or would Vala also pick up files in 
> the old-style $PREFIX/share/vala/vapi directory?
> 
> The reason I'm asking is that a lot of third-party packages still install 
> in the latter directory.

No, Vala also picks up files in the unversioned vala/vapi directory in
$XDG_DATA_DIRS (/usr/share and /usr/local/share by default).

Third-party packages should continue to install into unversioned
directories - unless the vapi is really Vala version-specific but that
should be rare.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Regression?

[Jürg Billeter]

On Mon, 2010-11-15 at 00:33 +0100, pancake wrote:
> This program compiles with no errors/warnings in vala-head and it should
> report an error because of missing 'return' in function:

Thanks for the report. 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.11.2 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.2 of Vala, a compiler for the
GObject type system.

Vala 0.11.2 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.11.1
 * Update libnotify bindings to 0.7.0.
 * Improvements to the .gir reader.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] development for 0.12

[Jürg Billeter]

On Wed, 2010-10-27 at 00:35 -0700, Evan Nemerson wrote:
> Perhaps I'm missing something, but I think there is a pretty big problem
> with this... When you roll a dist tarball, the Vala code will be
> compiled to C with *your* valac, and the resulting C code will not
> contain both versions.

This is true, however, this shouldn't be an issue in this case, where
you just want to support building your application with multiple Vala
versions. As long as both versions work the same, you don't care what
Vala version it was built with.

If you add features to #if VALA_0_12, the maintainers will need to make
sure to build the dist tarball with a recent Vala version. I don't
expect this to be a problem as I don't expect the maintainers to add
features to #if VALA_0_12 code if they don't use a recent Vala version
anyway.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] development for 0.12

[Jürg Billeter]

On Wed, 2010-10-27 at 08:10 +0200, pancake wrote:
> Is there any way to check at preprocessor stage for the version of  
> vala? Or I have to do this check outside (configure?) and then pass  
> the -D to valac?
> 
> #ifdef VALA10
> ... Old/stable stuff here
> #else
> .. New stuff here
> #endif

#if VALA_0_12
... Code for Vala >= 0.11
#else
... Code for older Vala
#endif

This is implicitly defined and doesn't need -D.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Vala 0.10.1 - Compiler for the GObject type system

[Jürg Billeter]

On Tue, 2010-10-26 at 20:50 +0200, Nicolas Joseph wrote:
> The code doesn't compile:
> 
> valaccodeconstant.vala:41.11-41.18: error: The expression `string' does
> not denote an array
>   assert (_name[0] == '\"');

Do not use valac 0.11.x to build valac 0.10.x from git. Either use
tarball releases or build with valac 0.10.x (or late 0.9.x) versions.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Vala 0.10.1 - Compiler for the GObject type system

[Jürg Billeter]

Hi,

On Tue, 2010-10-26 at 11:45 -0700, Anatol Pomozov wrote:
> One thing that confuses me is versioning policy for Vala. 0.11 version
> has been release recently, now you release 0.10. Also git repository
> as well as some developers mention 0.12 version. What is these
> versions for, what are the difference between them? Is there any doc
> that describes it? What is the recommended version?

Vala uses even minor versions for stable releases and odd minor versions
for development releases like many other software projects. 0.10.1 is
the latest release from the stable 0.10 branch. 0.11.1 is the latest
release from master, the main development branch.

The next stable release from master will be 0.12.0 (or 1.0.0), that's
why master is considered part of the 0.12 release series.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.10.1 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.10.1 of Vala, a compiler for the
GObject type system.

Vala 0.10.1 is now available for download at:
   http://download.gnome.org/sources/vala/0.10/

Changes since 0.10.0
 * Remove outdated GTK+ 3 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.11.1 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.1 of Vala, a compiler for the
GObject type system.

Vala 0.11.1 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.11.0
 * Require and target GLib >= 2.16.
 * Guard access to out parameters to allow null arguments.
 * Add support for local constants.
 * Support file descriptor passing with GDBus.
 * Support cached property values in GDBus clients.
 * Support Cancellable parameter in GDBus clients.
 * Support no-reply methods in GDBus clients and servers.
 * More refactoring in the code generator.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Thread unsafe GObject?

[Jürg Billeter]

Hi,

On Thu, 2010-10-21 at 18:33 +, gerhard.gru...@documatrix.com wrote:
> to solve the problem i have rewritten the gobject library so it
> increments the value of static_fundamental_next in function
> "g_type_fundamental_next" with a write-lock around it.
> but wouldn't it be better if vala locks the line
>   _type_id = g_type_register_fundamental
> (g_type_fundamental_next (), "", &g_define_type_info,
> &g_define_type_fundamental_info, 0);
> in order to guarantee that object orientation is thread safe in vala?

I don't see how Vala could safeguard this properly with unmodified GLib.
Do you have a more specific suggestion how this would work?

You should probably better file a GLib bug for this issue.

Possible workarounds are to not define fundamental types (e.g., always
derive from GLib.Object) or to make sure that all types are initialized
in the main thread before starting new threads.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Foreach with lambda: C error

[Jürg Billeter]

On Tue, 2010-10-19 at 19:32 +0200, Marco Trevisan (Treviño) wrote:
> I'm trying to use a lambda function as a foreach body for an HashTable:
> 
> public void print_hashmap(GLib.HashTable map) {
>   // 
>   map.foreach((k, v) => {
>   string key = (string)k;
>   Value val = (Value)v;

v is of type `Value?` and not just `Value`.

We should try to switch to generic delegate for HFunc to avoid the
necessity of such casts.

Jürg 

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Migrating to GLib.DBus caused problems

[Jürg Billeter]

On Tue, 2010-10-12 at 00:22 +0400, Gavrilov Maksim wrote:
> Hello, guys!
> 
> I became tired of warnings when using old dbus-glib method, so I went to 
> http://live.gnome.org/Vala/DBusClientSample and tried to compile first 
> BlueZ sample exactly as it is written there, but I get a GREAT amount of 
> c-mistakes :(
> 
> What should I do? Searched all over the Internet, but didn't find any 
> answer :(

What valac version are you using? It should work fine with both, the
current stable release 0.10.0 and the current development release
0.11.0.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [ANNOUNCE] Vala 0.11.0 - Compiler for the GObject type system

[Jürg Billeter]

On Tue, 2010-10-05 at 12:11 +0200, pancake wrote:
> > Changes since 0.10.0
> >   * Use byte indices for strings.
> by reading the patch I understand that this is not honoring UTF8 anymore?

No, strings in Vala are still UTF-8, nothing changed in that regard. The
difference is that indices/offsets/lengths are measured in code units
(bytes as we are talking about UTF-8) instead of code points.

This is in line with string APIs in many libraries (Java, .NET, Qt, Go)
and makes it possible to improve performance in string handling without
resorting to pointers all the time while still properly supporting
Unicode strings.

It may require changes in some code but most well-written code can
actually remain as it is.

> >   * Add support for parallel compilation.
> can't find any commit related to this. can you point to an example?

http://live.gnome.org/Vala/Documentation/ParallelBuilds

> >   * Improve compiler performance.
> any benchmarks?

From measurements some time ago, the valac CPU time for a rebuild of
libvala/valac itself was reduced from 16 seconds to 9 seconds. It really
depends on the application, though.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.11.0 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.11.0 of Vala, a compiler for the
GObject type system.

Vala 0.11.0 is now available for download at:
   http://download.gnome.org/sources/vala/0.11/

This is a development release leading toward 0.12.

Changes since 0.10.0
 * Use byte indices for strings.
 * Use uint8[] for binary data in bindings.
 * Add support for parallel compilation.
 * Improve compiler performance.
 * More refactoring in the code generator.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Libgee 0.6.0 - GObject collection library

[Jürg Billeter]

We are very pleased to announce version 0.6.0 of Libgee, the GObject 
collection library.

Libgee 0.6.0 is now available for download at:
http://download.gnome.org/sources/libgee/0.6/


Also please note that Libgee has its own mailing-list
http://mail.gnome.org/mailman/listinfo/libgee-list
and its own #gee IRC channel.


New in 0.6.0


 * Fix compiler warning.


For more information about the 0.5/0.6 release series, see:
http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
http://live.gnome.org/Libgee/Migration-0.5


Libgee is a collection library providing GObject-based interfaces and 
classes for commonly used data structures.

Libgee provides the following interfaces:

 * Iterable
   o Collection
 + List
 + Set
 + MultiSet
 + Queue
   # Deque
 * Iterator
 * Map
 * MultiMap

The ArrayList, HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList, 
PriorityQueue, TreeSet, TreeMap, TreeMultiSet, and TreeMultiMap classes 
provide a reasonable sample implementation of those interfaces. In 
addition, a set of abstract classes are provided to ease the 
implementation of new collections.

Around that, the API provide means to retrieve read-only views, 
efficient sort algorithms, simple, bi-directional or index-based mutable 
iterators depending on the collection type.

Libgee is written in Vala and can be used like any GObject-based C 
library. It's planned to provide bindings for further languages.


More information about Libgee is available at

 http://live.gnome.org/Libgee


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Two small new features

[Jürg Billeter]

Hi Frederik,

On Sat, 2010-09-25 at 17:20 +0200, Frederik Sdun wrote:
> i just pushed two little patches to [0] which allows to add an else
> statement to foreach and catch statements.
> For foreach, the else block is called if there is no iteration in the
> loop.
> For the catch clause, the else block is called if no exception was
> caught and before the finally statement.
> 
> Here are 2 little examples:
> foreach:
> void print_array (string[] args) {
> foreach (var arg in args) {
> debug(@"arg: $arg");
> } else {
> debug("no args"); //called if the array is empty
> }
> }
> void main (string[] args)
> {
> string[] test_1 = new string[0];
> string[] test_2 = new string[2]{"hello", "world"};
> print_array (test_1);
> print_array (test_2);
> }

The `else` seems to indicate that the code in the else block is reached
if the foreach is not successful. However, zero iterations are by no
means an unusual condition. In general, I'd like to keep (control flow)
statements relatively simple as, in my opinion, it's ok that the code
gets more complex when the control flow is more complex. You don't want
to hide complex control flow.

> catch:
> public errordomain TestError {
> FOO,
> }
> public void throw_error (bool t) throws TestError {
> if (t) {
>  throw new TestError.FOO("foo");
> }
> }
> void test(bool t) {
> try { 
> throw_error (t);
> } catch (TestError e) {
> debug("error :(");
> } else {
> debug("success :)");
> } finally {
> debug("finally");
> }
> }
> void main(){
> debug("false:");
> test(false);
> debug("true:");
> test(true);
> }

What is the difference to the following?

try {
throw_error (t);
debug ("success :)");
} catch (TestError e) {
debug("error :(");
} finally {
debug("finally");
}

> P.S.: There's a another branch, which supports async delegates/lambdas at [1]
> which requires some testing/reviewing.

I definitely like that one. I'll try to review it as soon as possible.

Thanks,
Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] New mailing list: vala-devel-list

[Jürg Billeter]

I've created a new mailing list:

vala-devel-l...@gnome.org

The new list will be used to discuss development of the Vala compiler
and language (and Dova).

Discussion about using Vala will remain on vala-list.

To subscribe to vala-devel-list, follow the instructions on the
following web page:

http://mail.gnome.org/mailman/listinfo/vala-devel-list

Regards,
Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala compilation fails

[Jürg Billeter]

Hi Anatol,

On Fri, 2010-09-17 at 18:01 -0700, Anatol Pomozov wrote:
> I just started learning Vala. I cloned vala repo from git://
> git.gnome.org/vala and run ./autogem.sh  (See log here
> http://pastie.org/1165976).
> 
> Everything looks fine, but when I run make - compilation fails

Building Vala from git requires an already installed version of Vala to
bootstrap the compiler. What version of Vala did you have installed on
your system before trying to build Vala from git? Building Vala from
release tarballs doesn't require an existing Vala installation, and you
should always be able to build Vala from git using the latest Vala
release.

Regards,
Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.10.0 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.10.0 of Vala, a compiler for the
GObject type system.

Vala 0.9.8 is now available for download at:
   http://download.gnome.org/sources/vala/0.10/

Changes since 0.9.8
 * Port GIR parser and writer to GIR version 1.2.
 * Update GLib bindings to 2.26 branch.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Libgee 0.5.3 - GObject collection library

[Jürg Billeter]

We are very pleased to announce version 0.5.3 of Libgee, the GObject 
collection library.

Libgee 0.5.3 is now available for download at:
http://download.gnome.org/sources/libgee/0.5/


Also please note that Libgee has its own mailing-list
http://mail.gnome.org/mailman/listinfo/libgee-list
and its own #gee IRC channel.


New in 0.5.3


 * Fix memory leaks in TimSort and LinkedList.
 * Bug fixes in TreeMap and TreeSet.


For more information about the 0.5 release series, see:
http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
http://live.gnome.org/Libgee/Migration-0.5


Libgee is a collection library providing GObject-based interfaces and 
classes for commonly used data structures.

Libgee provides the following interfaces:

 * Iterable
   o Collection
 + List
 + Set
 + MultiSet
 + Queue
   # Deque
 * Iterator
 * Map
 * MultiMap

The ArrayList, HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList, 
PriorityQueue, TreeSet, TreeMap, TreeMultiSet, and TreeMultiMap classes 
provide a reasonable sample implementation of those interfaces. In 
addition, a set of abstract classes are provided to ease the 
implementation of new collections.

Around that, the API provide means to retrieve read-only views, 
efficient sort algorithms, simple, bi-directional or index-based mutable 
iterators depending on the collection type.

Libgee is written in Vala and can be used like any GObject-based C 
library. It's planned to provide bindings for further languages.


More information about Libgee is available at

 http://live.gnome.org/Libgee


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Five bugs in Vala integration

[Jürg Billeter]

On Thu, 2010-09-09 at 08:03 +0800, Nor Jaidi Tuah wrote:
> That's a blow for me too. I was hoping that all those #ifs
> go straight to the c files so that there are ./configurable.
> 
> I suggest valac should have an option for the #ifs to be
> retained in the c files.

That's not as easy as it sounds. valac is not a simple preprocessor
where we could just retain parts from the sources. Processing multiple
branches at once influences semantic and flow analysis and the generated
code could change in more than just one place.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Five bugs in Vala integration

[Jürg Billeter]

On Wed, 2010-09-08 at 20:02 +0200, Ralf Wildenhues wrote:
> [ trying to add vala-list; this is
>    ]
> 
> * Valentin David wrote on Wed, Sep 08, 2010 at 03:08:00PM CEST:
> > On Wed, Sep 8, 2010 at 7:53 AM, Ralf Wildenhues wrote:
> > > Well, are the derived sources portable, i.e., not depending on the
> > > system on which they are created?
> > 
> > Unfortunately no. "Starting with version 0.7.0, Vala supports the
> > preprocessing directives #if, #elif, #else, and #endif."
> > 
> > http://live.gnome.org/Vala/FAQ#Does_Vala_have_a_preprocessor.3F
> 
> Well, that's a blow, but it's not necessarily the end of portable
> derived sources, iff developers are careful to never (ab)use this
> feature to create nonportable derived sources.

Yes, when using Vala with Automake, the idea is that the derived sources
are always portable, and #if shouldn't be used to handle configure
options or similar.

> I'm not qualified to judge that.  I'm fine with changing the semantics
> in Automake (so that vala derived sources are not distributed), but
> please do Cc: vala-list for such Vala-related changes in Automake, in
> case they have comments; in fact, this whole thread may be of interest
> to them so I've added the list in Cc: now.

While I certainly see some merit in allowing to drop vala derived
sources from distribution, there are also reasons for the current
semantics: Vala users may want to use features of recent Vala versions
without imposing such a recent Vala version as tarball build dependency.

While we are careful about not breaking backwards compatibility in the
language itself, at least some of the bindings are still a moving
target. Distributing derived sources helps to mitigate this.

Last but not least, Vala itself distributes .c files to avoid
bootstrapping issues.

If it is possible to support both semantics in Automake, I'm all for it,
however, please don't break what we currently have.

Thanks,
Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.8 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.8 of Vala, a compiler for the
GObject type system.

Vala 0.9.8 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.7
 * Add --fatal-warnings commandline option.
 * Deprecate string.len () in favor of string.length.
 * Deprecate use of D-Bus GLib in favor of GDBus.
 * 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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] valasemanticanalyzer error

[Jürg Billeter]

On Tue, 2010-08-17 at 18:09 +0530, Martin DeMello wrote:
> public interface Enumerable : Iterable {
> 
>   public delegate T DFunc(G elem);
> 
>   public void map(DFunc fn, Gee.List acc) {
>   foreach (G i in this) {
>   acc.add(fn(i));
>   }
>   }
> }

This is invalid code. Inner types don't have access to generic type
parameters of outer types. So you probably want something as follows:

public interface Enumerable : Iterable {

public delegate T DFunc(G elem);
[...]
}

It's still a bug in valac, though, as valac should report an error
instead of exiting due to an assertion failure.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.7 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.7 of Vala, a compiler for the
GObject type system.

Vala 0.9.7 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.6
 * Fix regression introduced by codegen refactoring.

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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.6 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.6 of Vala, a compiler for the
GObject type system.

Vala 0.9.6 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.5
 * Drop deprecated support for assigning to construct properties.
 * Some refactoring in the code generator.
 * Bug fixes in bindings and vapigen.

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://www.vala-project.org/


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.5 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.5 of Vala, a compiler for the
GObject type system.

Vala 0.9.5 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.4
 * Add version suffix to support parallel installation.
 * Define VALA_X_Y according to compiler version.
 * Enable version header by default.
 * Add vala.m4 with VALA_CHECK_PACKAGES macro.
 * Add gedit-2.20 bindings (Andrea Del Signore).
 * Add tokyocabinet bindings (Evan Nemerson).
 * Various improvements to the Dova profile.
 * 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] Vala - Unreviewed patches.

[Jürg Billeter]

On Wed, 2010-08-04 at 11:15 +0200, geert.jorda...@telenet.be wrote:
> Currently a lot of unreviewed patches exist. Could somebody review
> them? (IMHO) Feedback on the patches is important to get more people
> involved or familiar with the development process. 

I'll try to review pending patches as soon as possible. I've been busy
with other things, however, I'll try to spend more time in patch review
from now on as I agree that it's really bad to let contributors wait
long for feedback.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.4 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.4 of Vala, a compiler for the
GObject type system.

Vala 0.9.4 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.3
 * Append documentation comments to generated C files.
 * Skip  tags in .gir files.
 * Various improvements to the Dova profile.
 * 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] [ANNOUNCE] Vala 0.9.3 - Compiler for the GObject type system

[Jürg Billeter]

On Thu, 2010-07-15 at 10:01 +0200, JM wrote:
> Congratulations for this release! 
> Can you explain the new GBoxed-based memory management in vala? 
> I know GBoxed is a generic wrapper for C structures, that only needs
> copy and free functions. And I know that in vala a type get's boxed when
> you use the '?' operator, like in 'string? s = null;'. 
> So what is new for the user? Or is this just for bindings?

This is just for bindings, especially bindings generated from .gir files
as they do not contain information about copy/free functions.

Regards,
Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.3 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.3 of Vala, a compiler for the
GObject type system.

Vala 0.9.3 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.2
 * Support newlines in double quoted string literals.
 * Add experimental support for main blocks.
 * Add experimental vala tool to compile and run code.
 * Initial support for generic delegates.
 * Support using GClosure for delegate parameters.
 * Support GBoxed-based memory management.
 * Improvements to the .gir reader and writer.
 * Various improvements to the Dova profile.
 * 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] [vala] for loop

[Jürg Billeter]

Hi,

On Fri, 2010-06-25 at 10:27 +, gerhard.gru...@documatrix.com wrote:
> Why do you write a for loop in this way? I think there are some
> reasons, but I did not find them.
> But when it is necessary to write a while loop instead a for loop
> would it not be better, if the generated code looks like this?

The compiler converts internally all loop variations into a generic
infinite loops with appropriate if and break statements. This helps
keeping flow analysis and code generation simpler (especially regarding
error handling).

> In this way you do not need the _tmp0_ variable, which could improve
> the performance of the for loop, couldn't it?

This should not make any difference when building with optimizing C
compilers. If you have a test case where you notice a measurable
performance difference, we can check whether there might be worthwhile
optimization possibilities.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] GBinding support?

[Jürg Billeter]

Hi,

On Sun, 2010-06-20 at 17:57 +0200, Frederik wrote:
> GLib/GObject 2.26 will add property binding [1]. The straightforward way to
> support this in Vala would be:
> 
>   Object.bind_property (foo, "x", bar, "y");
>   Object.bind_property (foo, "x", bar, "y", BindingFlags.BIDIRECTIONAL);
> 
> However, this is not very type-safe. Would direct language support be
> reasonable? E.g. something like
> 
>   foo.x +> bar.y; // default
>   foo.x <+> bar.y;// bidirectional
> 
> Or is it too cryptic?

We don't need special syntax for every available GObject method. Let's
first have a plain binding and see how it will be used. If we see a very
common pattern where syntactic sugar would help a lot, we can reconsider
adding syntactic sugar.

> And how to deal with 'g_object_bind_property_full'? It takes two 
> TransformFuncs
> but only one user_data/GDestroyNotify pair.

This will be fixed, I talked to ebassi on IRC.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.2 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.2 of Vala, a compiler for the
GObject type system.

Vala 0.9.2 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.9.1
 * Initial support for GDBus-based clients and servers.
 * Support implicit and explicit GVariant casts.
 * Add support for [Deprecated] attribute.
 * Add GenericArray as alternative binding to GPtrArray.
 * Add gdk-pixbuf-3.0, gdk-3.0, gdk-x11-3.0, and gtk+-3.0 bindings.
 * Updates to the GLib 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


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Libgee 0.5.1 - GObject collection library

[Jürg Billeter]

We are very pleased to announce version 0.5.1 of Libgee, the GObject 
collection library.

Libgee 0.5.1 is now available for download at:
http://download.gnome.org/sources/libgee/0.5/


Also please note that now Libgee has its own mailing-list
http://mail.gnome.org/mailman/listinfo/libgee-list
and its own #gee IRC channel.


New in 0.5.1


 * Bug fixes in HashMultiSet, TimSort, TreeMap, TreeMultiSet, and TreeSet.
 * Fix build with Vala 0.8.0 and later.
 * Fix build on Windows.
 * Fix subprocess handling in test infrastructure.


For more information about the 0.5 release series, see:
http://live.gnome.org/Libgee/NewAndNoteworthy-0.5
http://live.gnome.org/Libgee/Migration-0.5


Libgee is a collection library providing GObject-based interfaces and 
classes for commonly used data structures.

Libgee provides the following interfaces:

 * Iterable
   o Collection
 + List
 + Set
 + MultiSet
 + Queue
   # Deque
 * Iterator
 * Map
 * MultiMap

The ArrayList, HashSet, HashMap, HashMultiSet, HashMultiMap, LinkedList, 
PriorityQueue, TreeSet, TreeMap, TreeMultiSet, and TreeMultiMap classes 
provide a reasonable sample implementation of those interfaces. In 
addition, a set of abstract classes are provided to ease the 
implementation of new collections.

Around that, the API provide means to retrieve read-only views, 
efficient sort algorithms, simple, bi-directional or index-based mutable 
iterators depending on the collection type.

Libgee is written in Vala and can be used like any GObject-based C 
library. It's planned to provide bindings for further languages.


More information about Vala is available at

 http://live.gnome.org/Libgee


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Abstract properties in Concrete Class

[Jürg Billeter]

Hi,

On Wed, 2010-06-09 at 22:25 -0400, tecywiz121 wrote:
> This is the second snippet I was curious about.
> 
> Basically, valac should not allow the following code to compile since
> IMHO, its completely wrong.
> 
> Just checking whether I should file a bug report or not.

Yes, this is a bug. valac already reports an error when declaring
abstract methods in concrete classes. It should do the same with
abstract properties.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Rules for updating generated C files

[Jürg Billeter]

Hi Rob,

On Tue, 2010-06-08 at 13:36 -0700, Robert Powell wrote:
> On Tue, Jun 8, 2010 at 1:23 PM, Jan Hudec  wrote:
> 
> > On Thu, Jun 03, 2010 at 14:13:01 -0700, Robert Powell wrote:
> > > If a member variable is added to BaseClass, BaseClass.vapi will change.
> >  The
> > > C file that is generated from Derived.vala will be identical, but it
> > needs
> > > to be recompiled because the base class has changed.  valac will not
> > > regenerate Derived.c because it hasn't changed.
> >
> > The Makefile in your example is hopelessly broken. Derived.c has not
> > changed,
> > but it certainly includes BaseClass.h which must have had. The makefile
> > fails
> > to see that Derived.o depends on BaseClass.h and the fix should be to make
> > the makefile directly aware of the fact.
> >
> >
> You snipped the important bit "For this simple system, it would be easy
> enough to update the makefile to watch for this dependency."  It was meant
> to illuminate the fact that when systems get larger, trying to maintain
> dependencies becomes terribly complicated.  I suggested a solution for the
> problem.  Does anyone have any better suggestions (other than use
> automake--automake is not an option for our projects here) for dealing with
> larger systems?

You could use a similar approach and use gcc -M or makedepend to
generate Makefile rules describing header file dependencies. The
Makefiles would certainly get a bit more complicated but it should be
possible and not require manual dependency maintenance. If that's
possible, I'd prefer to keep the simple update logic we currently have
in valac.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.9.1 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.9.1 of Vala, a compiler for the
GObject type system.

Vala 0.9.1 is now available for download at:
   http://download.gnome.org/sources/vala/0.9/

Changes since 0.8.0
 * Support constants in enums.
 * Deprecate +=/-= syntax to connect/disconnect signal handlers.
 * Add experimental support for Dova profile.
 * Update Genie parser (Jamie McCracken).
 * Add clutter-gst-1.0 bindings (Ali Sabil).
 * Add gdu and gdu-gtk bindings.
 * Add libesmtp bindings (Adrien Bustany).
 * Add mx-1.0 bindings (Evan Nemerson).
 * Add orc-0.4 bindings (Fabian Deutsch).
 * Add rest-extras-0.6 bindings (Adrien Bustany).
 * Updates to the GLib, GStreamer, Linux, SQLite, and other 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


Jürg Billeter

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] casting out parameters

[Jürg Billeter]

On Wed, 2010-05-26 at 15:41 +0200, pancake wrote:
> Would love to see this dynamic casting supported by the language..
> Should I open a bug?

As Nor Jaidi Tuah wrote, the declaration of the method `test` does not
guarantee that `foo` is set to an instance of `Bar`. The method could
also be implemented as follows:

void test(out Foo foo) {
foo = new Foo ();
}

If the compiler accepted your `main` method, you'd have a variable of
type Bar pointing to an object of type Foo, and this should never
happen. The compile error you get is intentional and not a bug.

Jürg

___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.8.1 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.8.1 of Vala, a compiler for the
GObject type system.

Vala 0.8.1 is now available for download at:
   http://download.gnome.org/sources/vala/0.8/

Changes since 0.8.0
 * Support constants in enums.
 * Add clutter-gst-1.0 bindings (Ali Sabil).
 * Add gdu and gdu-gtk 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] Vala on CentOS?

[Jürg Billeter]

On Thu, 2010-04-01 at 22:16 -0700, Joseph Montanez wrote:
> I am trying to deploy a vala application on a web server running
> CentOS 5. I've been fighting to get it compile let alone run. Here is
> the current command I am running to get it to compile:
> valac --Xcc=-I/usr/local/include/gee-1.0 --pkg=gee-1.0
> --pkg=json-glib-1.0 main.vala taxonomy.vala
> 
> That seems to compile, but when I run ./main I get a bunch of missing
> share libraries. I've tried to link them to /lib64 but because the
> CentOS is built on an older glib I get a bunch of undefined symbols.

What exact symbols are missing? You could try building with
--target-glib=2.12. This tells the compiler to not use symbols from more
recent GLib versions. However, this might not be sufficient, if you use
functionality from GLib 2.14 or later in the .vala files yourself.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [vala 0.8.0] construct properties in interface

[Jürg Billeter]

On Thu, 2010-04-01 at 11:01 +0200, Nicolas Joseph wrote:
> Hello,
> 
> I have a compilation error with vala 0.8.0:
> 
> public interface Valide.Plugin : Object
> > {
> >   public abstract string path { get; construct set; }
> >   public abstract Window window { get; construct set; }
> > }
> >
> 
> libvalide/plugin.vala:30.38-30.51: error: construct properties not supported
> > for specified property type
> > libvalide/plugin.vala:35.40-35.53: error: construct properties not
> > supported for specified property type
> >
> 
> What is the good way to fix this error?

It's already fixed in master and will be in the next release.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.8.0 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.8.0 of Vala, a compiler for the
GObject type system.

Vala 0.8.0 is now available for download at:
   http://download.gnome.org/sources/vala/0.8/

Changes since 0.7.10
 * Infer type arguments when calling generic methods.
 * Support `in' operator for arrays.
 * Add experimental support for regular expression literals.
 * Add experimental support for chained relational expressions.
 * Add va_list support.
 * Add clutter-gtk-0.10 bindings (Gordon Allott).
 * Add gdl-1.0 bindings (Nicolas Joseph).
 * Add gstreamer-app-0.10 bindings (Sebastian Dröge).
 * Add gstreamer-cdda-0.10 bindings (Sebastian Dröge).
 * Add gudev-1.0 bindings (Jim Nelson).
 * Add libgda-report-4.0 bindings (Shawn Ferris).
 * Add libgvc (graphviz) bindings (Martin Olsson).
 * Add purple 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] Locking null references

[Jürg Billeter]

On Tue, 2010-03-30 at 12:33 +0200, "Andrés G. Aragoneses" wrote:
> El 30/03/10 11:58, Jürg Billeter escribió:
> > Hi Andrés,
> > 
> > On Tue, 2010-03-30 at 11:47 +0200, "Andrés G. Aragoneses" wrote:
> >> El 30/03/10 11:35, Jürg Billeter escribió:
> >>> On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote:
> >>>> In Vala, I can lock a null reference.  Is this by design or a 
> >>>> side-effect?
> >>>
> >>> It's by design (constrained by GObject). Unlike in C#/.NET, we don't
> >>> have a monitor available in every object. Due to this constraint, we've
> >>
> >> AFAIK, it's not that there's a Monitor available in every object. The
> >> lock statement is translated into a Monitor.Enter() call, but note that
> >> this is a static function call.
> > 
> > The runtime uses a per instance field to implement Monitor.Enter, as far
> > as I know.
> 
> Ok, a private field only available at run-time by the runtime.
> But couldn't vala do something similar with the recently added
> g_type_class_add_private API? This way there would be a solution for the
> lock(this) case. Beware: glib/gobject noob here.

We need a field per instance, not a field per class.

> >>> decided to use different lock statement semantics compared to C#. The
> >>> only other option would have been to not support lock statements at
> >>> all .
> >>
> >> Well, I'm wondering about a 3rd option which would be a compromise: that
> >> vala translate every lock statement with a minimal null-check first, so
> >> if the condition is not met, an exception is raised? What do you think
> >> about this approach?
> > 
> > I fail to see what we would gain by doing that. The semantics would
> > still differ significantly from C#. I don't see a reason why the field
> > value should ever be relevant with Vala's lock statement semantics. For
> > example, you can also lock integer fields where the null check wouldn't
> > make any sense.
> 
> How about requiring at compile time that the lock statement uses a
> reference-type too, like in C#?

Again, I don't see what we would gain by doing that. The semantics would
still differ significantly from C#.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Locking null references

[Jürg Billeter]

Hi Andrés,

On Tue, 2010-03-30 at 11:47 +0200, "Andrés G. Aragoneses" wrote:
> El 30/03/10 11:35, Jürg Billeter escribió:
> > On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote:
> >> In Vala, I can lock a null reference.  Is this by design or a side-effect?
> > 
> > It's by design (constrained by GObject). Unlike in C#/.NET, we don't
> > have a monitor available in every object. Due to this constraint, we've
> 
> AFAIK, it's not that there's a Monitor available in every object. The
> lock statement is translated into a Monitor.Enter() call, but note that
> this is a static function call.

The runtime uses a per instance field to implement Monitor.Enter, as far
as I know.

> > decided to use different lock statement semantics compared to C#. The
> > only other option would have been to not support lock statements at
> > all .
> 
> Well, I'm wondering about a 3rd option which would be a compromise: that
> vala translate every lock statement with a minimal null-check first, so
> if the condition is not met, an exception is raised? What do you think
> about this approach?

I fail to see what we would gain by doing that. The semantics would
still differ significantly from C#. I don't see a reason why the field
value should ever be relevant with Vala's lock statement semantics. For
example, you can also lock integer fields where the null check wouldn't
make any sense.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Locking null references

[Jürg Billeter]

Hi Jim,

On Mon, 2010-03-29 at 18:30 -0700, Jim Nelson wrote:
> In Vala, I can lock a null reference.  Is this by design or a side-effect?

It's by design (constrained by GObject). Unlike in C#/.NET, we don't
have a monitor available in every object. Due to this constraint, we've
decided to use different lock statement semantics compared to C#. The
only other option would have been to not support lock statements at
all .

In Vala lock(foo) locks the field `foo' and not the instance where `foo`
points to. This means that the current value of the field is completely
irrelevant, and locking a field whose value happens to be null is
perfectly fine.

> I think this is fine and should be the documented behavior.  Because Vala
> only allows locking member variables (and not "this"), being unable to lock
> a nulled reference would require allocating a dummy object to lock against
> or explicitly using a Mutex and forgoing lock().  I find both unappealing.

Yes, it's unfortunate that we can't properly support lock(this) as
GObject doesn't support it and we can't just add a mutex field to
instance structs as this would result in issues when using lock(this) in
subclasses. Otherwise, I'd probably recommend using lock(this) in most
cases.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] DBus Client Timeout Woes

[Jürg Billeter]

On Mon, 2010-03-22 at 15:46 +0100, Michael 'Mickey' Lauer wrote:
> How can we make this argument customizable in Vala? Would it --
> at least for static clients -- be feasible to introduce a new attribute, i.e.
> [DBus (name = "foo", timeout = "12")] ?

This is now supported in master (except that the timeout argument has to
be an integer). When GDBus is added to GLib, I expect the default
timeout to be configurable using a method call.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] 'GUnixSocketAddress' undeclared

[Jürg Billeter]

Hi Jeff,

On Wed, 2010-03-24 at 21:51 -0600, Jeff Cave wrote:
> I'm having trouble creating a "UnixSocketAddress". Of all the stupid problems 
> I've figured out, this one is annoying because it seems so obvious (include 
> the 
> required package). Anyone able to tell me what I'm missing here?

This was a bug in the binding. It's now fixed in Vala master and will be
fixed in the next release.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Vala 0.7.10.262 pre-release

[Jürg Billeter]

A new Vala version will be released shortly. To make sure that we have
not introduced serious regressions, we'd like to invite everyone to test
the following pre-release and report any regressions or other
release-critical issues.

http://www.vala-project.org/downloads/vala-0.7.10.262-39688.tar.bz2

There have been many fixes and also quite a few enhancements since
0.7.10. The complete list of changes is available in the ChangeLog and a
summary will follow with the announcement of the final release.

Thanks,
Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Binding a C library w/ a message inheritance structure

[Jürg Billeter]

Hi,

On Thu, 2010-03-04 at 20:26 +0100, Michael 'Mickey' Lauer wrote:
> 1.) Where does Vala take that MSMCOMM_REPLY_GET_FIRMWARE_INFO and how
> can I fix the problem? Since all the concrete messages inherit from the
> base class I would expect this to be a no-op in C, as we're just
> ensuring Vala that we know which message type it is.

These are GObject-style casts with runtime type checking. As you appear
to be binding a non-GObject-based library, you're missing a [Compact]
attribute for the Message class.

> 2.) Is there a better way to handle C-APIs like that?

I've only taken a quick look but I haven't seen any fundamental issues
in the binding.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Feature request: Syntactic sugar to map foo[index] to foo.get(index)

[Jürg Billeter]

On Mon, 2010-03-01 at 13:07 +0100, Dr. Michael Lauer wrote:
> Am 01.03.2010 um 11:21 schrieb Frederik:
> > T get (int index)   -> indexer access ('[index]')
> 
> What about the string lookup, i.e. gee's foo["bar"] ?

It's not limited to a single int parameter. The parameter can be of any
type, and you can even have multiple parameters (of mixed types).

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Feature request: Syntactic sugar to map foo[index] to foo.get(index)

[Jürg Billeter]

On Mon, 2010-03-01 at 11:21 +0100, Frederik wrote:
> Can you give us a list of the compile-time "duck typing" protocols?
> 
>  Iterator iterator ()  -> 'foreach'
>  T? next_value () -> alternative 'foreach' iterator protocol
> 
>  T get (int index)-> indexer access ('[index]')
>  void set (int index, T item)
> 
>  bool contains (T needle) -> 'in' operator
> 
>  T slice (long start, long end)   -> slicing ('[start:end]')
> 
>  string to_string ()  -> string templates
> 
> Am I missing something?

I don't think so, this list appears to be complete.

Regards,
Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Feature request: Syntactic sugar to map foo[index] to foo.get(index)

[Jürg Billeter]

Hi,

On Mon, 2010-03-01 at 03:31 -0600, Sandino Flores Moreno wrote:
> I noticed that Vala allows with Gee sequences the next mapping:
> array_list[index]---> array_list.get(index)
> 
> However, shouldn't it be possible in non-gee objects?

This is already the case, there is nothing Gee-specific in the compiler
(with the exception of the Genie parser).

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Memory leak in async dbus calls

[Jürg Billeter]

Hi,

On Wed, 2010-02-03 at 16:15 +0100, Dierberg, Sascha wrote:
> compiling this min vala test file I got code that calls 
> 
> _data_ = g_slice_new0 (testDBusProxySetLedData);  
> 
> in test_dbus_proxy_set_led_async which is never freeed nor has the 
> 
> dbus_pending_call_set_notify (_pending, test_dbus_proxy_set_led_ready,
> _data_, NULL);
> 
> a valid DBusFreeFunction (param 4: NULL). 
> 
> What I am missing is a line like:
> 
> g_slice_free(testDBusProxySetLedData, _data_); 

This and a few related memory leaks have been fixed now.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.7.10 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.7.10 of Vala, a compiler for the
GObject type system.

Vala 0.7.10 is now available for download at:
   http://download.gnome.org/sources/vala/0.7/

Changes since 0.7.9
 * Support coalescing operator ??.
 * Support to_string and bitwise complement with enums.
 * Return handler id when connecting signal handlers.
 * Support struct comparison.
 * Support constructor chaining in structs.
 * Enforce protected member restrictions.
 * Improve performance of flow analysis.
 * Support automatic line continuations in Genie.
 * Improvements to the .gir reader and writer.
 * Add --enable-mem-profiler commandline option.
 * 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] Vala Clutter example segfaults

[Jürg Billeter]

On Mon, 2010-02-01 at 12:33 -0800, Adam B wrote:
> Hello all,
> 
> I compiled the clutter example linked from the Vala website and it segfaults
> near the end of the animation.
> http://live.gnome.org/Vala/ClutterSamples
> 
> If I comment out this code it works:
> 
> animations[i] = rectangles[i].animate (
> AnimationMode.EASE_OUT_BOUNCE, 3000,
> "x", Random.next_double () * stage.width,
> "y", Random.next_double () * stage.height / 2
>+ stage.height / 2,
> "rotation-angle-z", rectangles[i].rotation_angle_z,
> "opacity", 0.0);
> 
> Other wise it segfaults on the first iteration (i == 0).
> 
> I'm using Vala 0.7.9 and Clutter 1.0.6-0ubuntu1 on Ubuntu Karmic AMD64.  I'd
> try it on the latest Clutter but I can't find packages for that.
> 
> Can anybody reproduce this?  Is it Vala's fault or Clutter's?

It's a bug in the above code snippet, "opacity" is expecting a guchar,
not a double. Replacing 0.0 by 0 fixes the issue. I've updated the wiki.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] async D-Bus methods that return arrays fail to compile

[Jürg Billeter]

Hi,

On Fri, 2010-01-29 at 14:13 +0100, pHilipp Zabel wrote:
> the following example program fails to compile because Vala adds the
> length of the int[] output array (output_length1) to the async begin
> function call instead of to the async finish function call. The async
> function itself is fine, only the D-Bus wrappers put this parameter in
> the wrong place. Is there any way to work around this for now?

This 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] preconditions for constructors

[Jürg Billeter]

On Tue, 2010-01-19 at 14:46 +0800, Nor Jaidi Tuah wrote:
> It seems that constructors do not accept preconditions
> using requires (though assert can still be used).
> Is this an oversight or intentional?

This was bug 607110 and now fixed in master.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Array Property Length Not Matching What I Expect

[Jürg Billeter]

On Tue, 2010-01-19 at 21:25 -0500, Sam Wilson wrote:
> Okay, here is try number two at asking my question.  If you couldn't
> tell I am new to the mailing list world.
> In the code snippet below, I am attempting to read the length of an array
> through a property.  For some reason the returned result is completely
> random, but when I set a temporary variable to the value of the
> property and read its length, it is correct.
> 
> Is there a problem in what I am doing, or is something else going on?

This is bug 585847[1].

Jürg

[1] http://bugzilla.gnome.org/show_bug.cgi?id=585847


___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] for loop and closure (bug or big gotcha?)

[Jürg Billeter]

On Wed, 2010-01-20 at 14:00 +0800, Nor Jaidi Tuah wrote:
> Given this:
> 
> for (int i=0; i < 10; i++) {
> button[i].clicked.connect ((s) => {stdout.printf ("%d\n", i);});
> }
> 
> all the buttons, when clicked, outputs 10.
> i.e., the variable i is treated as non-local and shared
> by all those closures.
> 
> Is this the correct semantic?

Yes.

> If this is up for debate I would say that this is
> a wrong semantic. Different iteration of the for loop
> should use "different" i.

The scope of the variable `i` covers the whole `for` statement, not just
a single loop iteration (otherwise i++ at the end of each iteration
wouldn't make any sense). While it's true that this may cause mistakes,
we can't change this without breaking consistency. foreach loops should
be more convenient in that regard.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Is the C code generated by valac compliant with C89, or C99?

[Jürg Billeter]

On Thu, 2010-01-14 at 15:57 +0800, Jerry Tan wrote:
> Hi, all,
> 
> I know that I can use gcc or sunstudio to compile C code which is 
> generated by valac,
> 
> I just want to know that is there any compiler dependency,
> for example, gcc extension,  c99 support,
> any requirement for gcc version or sunstudio version?

The generated C code should be C89 compliant.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [PATCH] Enable glib's memory statistics by option

[Jürg Billeter]

Hi,

On Sat, 2010-01-09 at 16:27 +0100, JM wrote:
> I wrote a small patch to enable glib's memory statistics support for
> vala programs.
> It is trivial, but gives the programmer the possibility to use the
> mem_profile() call. This function needs an initialization done by the
> commandline option from this patch first.

Thanks, I've pushed it to master after renaming the command-line option
to --enable-mem-profiler.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala safe to use for development?

[Jürg Billeter]

On Fri, 2010-01-08 at 17:51 +0100, Dr. Michael Lauer wrote:
> As far as I know (Jürg, please speak up if I'm wrong) the core Vala syntax
> is to stay like it is until 1.0 except some possible additions, such as the 
> new
> array slice syntax or the string templates. We will hopefully see
> tuples as well.
> 
> We will see more changes in the bindings though, which can lead to code that
> does no longer compile (e.g. because of ownership changes such as recently
> seen in gio).

This is correct. Syntax is expected to stay or at least remain backward
compatible to the current syntax while we still need some more
flexibility for bindings, so we cannot guarantee full compatibility
there.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] case/when with enum

[Jürg Billeter]

On Thu, 2010-01-07 at 07:08 -0500, Arc Riley wrote:
> error: Integer or string expression expected
> 
> on a case statement where:
>   enum _message
> create
> resize
> title
> close
>   _queue = new AsyncQueue of _message
>   case _queue.pop()
> 
> Using case/when with enum values would seem extremely logical, was this
> overlooked or is there a reason not to support it?

switch/case should be working with enum values. Can you post a full test
case?

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.7.9 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.7.9 of Vala, a compiler for the
GObject type system.

Vala 0.7.9 is now available for download at:
   http://download.gnome.org/sources/vala/0.7/

Changes since 0.7.8
 * Support array and string slicing.
 * Add --symbols commandline option.
 * Add avahi-gobject bindings (Sebastian Noack).
 * Add ccss-1 bindings (Ali Sabil).
 * Add libarchive bindings (Julian Andres Klode).
 * Add libmagic bindings (Jens Georg).
 * Add readline bindings (Jukka-Pekka Iivonen).
 * Add twitter-glib-1.0 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] DBus horror

[Jürg Billeter]

On Tue, 2009-12-15 at 12:45 +0100, Kos wrote:
> You can find the test-source here: http://pastebin.org/65108
> I compile it with valac --pkg dbus-glib-1 vlc_test3.vala -g

Use the static variant but with an out parameter instead of a return
value as in the following lines:

public abstract void GetStatus (out State state) throws DBus.Error;

// Get info
org_freedesktop_MediaPlayer.State state;
dbus.GetStatus (out state);

It should also work with return values, however, there was a change in
how struct return values are processed a couple months back, and it's
possible that the D-Bus code still needs a few fixes there.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with Closure in Coroutine

[Jürg Billeter]

On Sun, 2009-12-13 at 13:00 +0100, Michael 'Mickey' Lauer wrote:
> Am Sonntag, den 13.12.2009, 11:01 +0100 schrieb Jürg Billeter:
> > On Sat, 2009-12-12 at 19:18 +0100, Michael 'Mickey' Lauer wrote:
> > > The problem seems to be that the data for the closure
> > > (_data_->_data2_)
> > > gets unref'ed when the function ends; however Gst is calling the
> > > callback later on and then the instance is 0x0. The C code for this
> > > function is:
> > 
> > Can you check whether it works if you use add_watch_full() instead of
> > add_watch()?
> 
> Awesome, that does it! Should we then change add_watch like
> 
> -public uint add_watch (Gst.BusFunc func);
> +public uint add_watch (owned Gst.BusFunc func);
> ?

No, this is not possible as the C function gst_bus_add_watch does not
have a GDestroyNotify parameter which is necessary to support owned
delegates. However, I've now fixed the binding to always use
gst_bus_add_watch_full to avoid such issues.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with Closure in Coroutine

[Jürg Billeter]

On Sat, 2009-12-12 at 19:18 +0100, Michael 'Mickey' Lauer wrote:
> The problem seems to be that the data for the closure
> (_data_->_data2_)
> gets unref'ed when the function ends; however Gst is calling the
> callback later on and then the instance is 0x0. The C code for this
> function is:

Can you check whether it works if you use add_watch_full() instead of
add_watch()?

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] vala-list.gnome.org

[Jürg Billeter]

On Wed, 2009-11-18 at 12:34 +0100, Julian Andres Klode wrote:
> On Wed, Nov 18, 2009 at 10:04:20AM +0100, pancake wrote:
> > Something like this will be good to have in the language:
> > 
> > using Gee (ArrayList);
> > 
> > So if you useArrayList in the code. The compiler will get it from
> > Gee. Likethe from import syntax in python or the static import in
> > java.

> or doing it the C# way of:
>   using ArrayList = Gee.ArrayList;
> Which explains itself very well.

This is planned to be added to Vala as well.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Some trouble with --use-header in valac

[Jürg Billeter]

On Thu, 2009-11-26 at 00:52 +0100, Frederik wrote:
> Maybe Vala should warn when '--use-header' is used without '--header'.
> Without '--use-header' Vala will use forward declarations in the
> generated C files.

Fixed.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] "precompiled" vapis

[Jürg Billeter]

On Fri, 2009-11-27 at 12:20 +0100, Marc-André Lureau wrote:
> On Fri, Nov 27, 2009 at 12:15 PM, pancake  wrote:
> > I was playing around gtk and curses and noticed a huge different in compile 
> > times
> > which I think it is caused because of the size of gtk+-2.0.vapi compared to
> > curses.vapi.
> >
> > It will be nice to be able to precompile those .vapis in a binary form, so 
> > Vala can
> > directly load the AST instead of having to parse it.
> >
> > What do you think about it?
> >
> 
> Switching to gir might speed up things, especially if vala supports
> the typelib format.
> 
> I would go into that direction instead, if it's possible.

As far as I can tell, parsing itself does not appear to be the limiting
factor, creating and resolving the AST is. I have some ideas how to
improve the situation by lazily creating the AST, however, bug fixing
appears to be more important right now.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Methods/ctors overloading

[Jürg Billeter]

On Mon, 2009-11-30 at 14:01 -0500, "Andrés G. Aragoneses" wrote:
> Abderrahim Kitouni escribió:
> > 2009/11/30 "Andrés G. Aragoneses" :
> >> Replying to myself:
> >>
> >> Andrés G. Aragoneses escribió:
> >>> Hello. I'm wondering if the difference between Vala and C# wrt
> >>> method/ctor overloading is intentional or is its real support
> planned in
> > It's intentional, one of the main goals of vala is to have libraries
> > that can be used from C. So methods must have sensible names (i.e.
> > name mangling is not an option)
> > 
> > btw, Vala has named creation methods (a.k.a. named constructors) so
> > there is no need for overloading (Yes, it would be useful but not
> > necessary)
> 
> Useful but not necessary, I agree. So this is why, if I were to help
> providing a patch for this, I would make ctor overloading an option, not
> dropping support for named constructors. Would that be acceptable?

Thanks for offering to work on this, however, I'd like to avoid
method/constructor overloading at the moment. In addition to various
potential issues with overloading¹ Vala is currently in a stabilization
period. No fundamental semantic change as in your proposal will enter
master in the near future.

Jürg

¹ e.g., confusing effects on differing implementations of overloaded
methods and complex method resolution as the combination of default
arguments and method overloading can lead to conflicts, the mentioned
issue of mapping to C identifiers

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala Bugfix Hackathon (was: when will vala 0.8 be released?)

[Jürg Billeter]

On Mon, 2009-11-30 at 20:25 +0100, Michael 'Mickey' Lauer wrote:
> Am Freitag, den 20.11.2009, 17:36 +0100 schrieb Michael 'Mickey'
> Lauer:
> > How can we move on with the hackathon?
> > 
> > I guess the central question is who apart from Jürg (who seems to be
> > very busy these days) has the knowledge to educate us how to fix certain
> > things in an upstream-acceptable way? These people are critical to such
> > a hackathon, hence we need them to dictate a date that would work.
> 
> Okay, if noone of the elders are volunteering to help us moving Vala
> forward, then this pretty much kills the idea of the hackathon.

I was/am quite busy (and one week abroad) in November and December due
to customer projects, however, it should be better in January and
beyond. I really like the idea of a hackathon and we should try to find
a date/time in January for this. If it is supposed to happen during the
day European time, I will only be able to actively participate if it's
at a weekend. If it is just an evening, during the week should be ok for
me as well.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] MarkupParser binding

[Jürg Billeter]

On Sat, 2009-12-05 at 21:10 +0100, Michael 'Mickey' Lauer wrote:
> How can we fix the MarkupParser binding?
> 
> Apart from the anonymous callbacks, which needs fixing upstream, it
> still doesn't quite work, as the delegates complain about their missing
> target. How can we fix that?

The MarkupParser binding should be usable, IIRC, although possibly not
in the most convenient way and it's easy to get it wrong in a way that
valac can't detect. If you have an issue that goes beyond convenience
and error detection, please paste a test case and I'll take a look.

> Btw., how does delegate_target_pos relate
> to instance_pos and when are we supposed to use has_target = false?

delegate_target_pos applies to return values and parameters that return
or accept delegates, resp.

instance_pos applies to method and delegate declarations to specify the
position of self and user_data, resp.

has_target = false should only be used if the delegate does not have
anything like gpointer user_data in the C declaration.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] [ANNOUNCE] Vala 0.7.8 - Compiler for the GObject type system

[Jürg Billeter]

We are pleased to announce version 0.7.8 of Vala, a compiler for the
GObject type system.

Vala 0.7.8 is now available for download at:
   http://download.gnome.org/sources/vala/0.7/

Changes since 0.7.7
 * Support constructor chain up to GObject using Object (...).
 * Add syntax for string templates.
 * Support (!) non-null casts.
 * 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] Maintaining bindings

[Jürg Billeter]

I'd like to thank everyone who has offered to help maintaining the
bindings. I'm happy to announce that Evan Nemerson will be the new
general bindings maintainer. This means that he will review new bindings
and patches for existing bindings.

For some bindings there will be an additional maintainer so that the
work is distributed more evenly.

Thanks again,
Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Maintaining bindings

[Jürg Billeter]

On Tue, 2009-10-27 at 19:00 +0100, Jürg Billeter wrote:
> as my time available for Vala does not grow the same as the number of
> bindings we ship, I'm looking for a volunteer to take over maintenance
> of Vala bindings. While there are already many contributors and a few
> have permission to directly push changes to master, we so far don't have
> an official bindings maintainer - besides me as maintainer of Vala as a
> whole.
> 
> Being bindings maintainer does not mean that you have to fix all issues
> that come up yourself, of course. The idea is that there is someone that
> is familiar enough with Vala bindings to triage bug reports and review
> and commit patches. This would allow me to focus on the rest of Vala as
> there is still enough left to work on in the code generator.
> 
> Is there anyone out there who feels up to task?

Just to be clear, while I'd like to have a single person responsible for
bindings in general, this doesn't mean that there can't be separate
maintainers who are responsible for some of the bindings. For example,
it would make a lot of sense to have separate maintainers for the GTK+
stack, for GStreamer, for POSIX, and for SDL. For the latter two there
are already volunteers.

That way the general bindings maintainer needs a lot less time and will
only need to handle requests for new bindings and bindings that don't
have separate maintainers.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

[Vala] Maintaining bindings

[Jürg Billeter]

Hi,

as my time available for Vala does not grow the same as the number of
bindings we ship, I'm looking for a volunteer to take over maintenance
of Vala bindings. While there are already many contributors and a few
have permission to directly push changes to master, we so far don't have
an official bindings maintainer - besides me as maintainer of Vala as a
whole.

Being bindings maintainer does not mean that you have to fix all issues
that come up yourself, of course. The idea is that there is someone that
is familiar enough with Vala bindings to triage bug reports and review
and commit patches. This would allow me to focus on the rest of Vala as
there is still enough left to work on in the code generator.

Is there anyone out there who feels up to task?

Thanks,
Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Vala dealing with const paramaters

[Jürg Billeter]

On Tue, 2009-10-27 at 16:24 +, Gordon Allott wrote:
> Hi,
> 
> I'm trying to subclass a Clutter.Actor, which happens to have methods
> such as 
>   void (* allocate) (ClutterActor   *actor,
>  const ClutterActorBox  *box,
>  ClutterAllocationFlags  flags);
> 
> Which is okay, apart from that it uses a const parameter, which as far
> as I can tell I have no way of defining in vala.
> 
> Would it not be worth allowing const parameters in method declarations
> even if all they do is indicate to the c translator that the parameter
> should be declared as const? or at the very least a CCode attribute
> would be handy. at the moment you will get a bunch of "assignment from
> incompatible pointer type" warnings from gcc, which if you are trying to
> develop clean code and have -Wall on, it makes it impossible to use
> valac in this situation.

valac will use const for this parameter if the struct is annotated as
[Immutable] in the bindings. If `const ClutterActorBox *` is used for
all (or most) input parameters in the C API, we should add the
[Immutable] attribute to the clutter bindings to get rid of the
warnings. Can you check/verify whether `const` is used consistently in
the case of ClutterActorBox input parameters?

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [PATCH] Clean up unused GError in case of catch statement without arguments

[Jürg Billeter]

On Sun, 2009-10-25 at 11:21 +0200, Alexander Bokovoy wrote:
> When catch statement has no arguments, no access to a GError is possible
> from Vala source code. Therefore, do not create temporary variable which
> is not used. Also, clear error object as it is not passed upwards then.

Thanks, applied - without the CCodeComment, we don't comment generated
code in general.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] [Genie] Convert string to uchar[]

[Jürg Billeter]

On Mon, 2009-10-12 at 16:29 +0200, Nicolas wrote:
> I need to convert string to array of uchar in genie.
> I know under vala it's "(uchar[]) testing" where testing is the string, 
> so how can i do this under genie ?

There is a string.to_utf8 method that returns a copy of the string as
char[].

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] How to debug vala program?

[Jürg Billeter]

On Wed, 2009-09-30 at 08:25 +, John - wrote:
> I try to debug Vala program with Nemiver :
> http://projects.gnome.org/nemiver , that It recomends in Debugging
> chapter from http://live.gnome.org/Vala/Tutorial
> 
> But It give me this message : "Could not find file test.vala.c" when I
> try to see what happens in clicked button signal.

Build your application with valac -g, that way you get debug information
for the .vala source files instead of the generated C files.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Problem with switch statment

[Jürg Billeter]

Hi,

On Mon, 2009-09-28 at 13:41 +0200, Nicolas wrote:
> I found a simple solution to avoid this warnings.
> Rather than using a "return", I use a bool and at the end of the 
> procedure, I return the bool.
> 
> Do you think this is a good solution?

You can do this to avoid the warning, however, this should certainly be
fixed in the compiler at some point. Feel free to file a bug.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Final / Sealed classes in Vala

[Jürg Billeter]

On Tue, 2009-09-22 at 06:40 +0200, Marco Trevisan (Treviño) wrote:
> Is it possible to define both in VAPIs and in a vala code a class which
> can not be extended?
> 
> I mean something like "final" does for Java and "sealed" for C#...

It's planned to introduce `sealed' in a future version on both, the
class and the method level.

> I think they could be useful for grouping static methods in "virtual
> classes" (I mean in a class which name has not a reference in a C
> type/structure, but that has just been written for organizing similar
> methods) without the risk of methods overriding or of extending a
> "virtual" class that has been defined in a VAPI but that is not
> available in the relative C code.

However, `sealed' is not meant for "static classes", that concept is not
encouraged in Vala as we support namespace methods.

Jürg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list