On Thu, 2009-10-29 at 00:45 +0100, Marc-André Lureau wrote:
> On Thu, Oct 29, 2009 at 12:15 AM, Hans Vercammen wrote:
> > Another (not uncommon) option would be to distribute syntax files with
> > the vala tarball, so it always matches the installed release. But I
> > don&#x
Hi Sergi,
On Wed, 2009-10-28 at 11:45 +0100, Sergi Alvarez wrote:
> I have updated the vala.vim to colorize the following keywords:
Thanks. Could you try to keep them somewhat alphabetically sorted, that
way it's easier to match them up with the vala lexer.
> async owned unowned assert
Not sure
On Fri, 2009-09-25 at 23:36 +1000, Magentus wrote:
> On Wed, 23 Sep 2009 18:40:04 +0200, Didier 'Ptitjes' wrote:
>
> > For instance you may have an abstract class A that defines some
> > methods as virtual, a child class B that re-implements some of the
> > virtual methods of A and that wish the s
On Wed, 2009-09-23 at 19:01 +0200, Frederik wrote:
> Didier 'Ptitjes' wrote:
> > I think the problem to not have it in Vala is more a technical problem
> > where nothing will avoid C users (in the current GObject) to subclass
> > the classes that would be marked as sealed in Vala.
>
> Vala already
On Thu, 2009-08-06 at 16:37 +0200, David Keijser wrote:
> > Vim is the best... I do everything non-Vala in it. Once you get used
> > to command mode, and make regular expressions a part of everyday life,
> > nothing else I've used comes close. Of only Valide could embed Vim as
> > its editor
On Sun, 2009-08-02 at 16:20 +0200, Jiří Zárevúcky wrote:
> On 08/01/2009 08:14 PM, Hans Vercammen wrote:
> > Using weak/unowned is mainly intended for the bindings and in case you
> > need to break cycles to prevent memory leaks. Furthermore weak/unowned
> > variables cou
On Sat, 2009-08-01 at 17:42 +0200, Łukasz Pankowski wrote:
> Another performance related usage of the weak variables (apart from one
> you mentioned in the bug comment #3) is that properties return weak
> variables so the values are copied unless assigned to the weak variable
> (as in the code belo
Hi,
On Sat, 2009-08-01 at 16:53 +0200, Jiří Zárevúcky wrote:
> On 08/01/2009 04:36 PM, Łukasz Pankowski wrote:
> > "Finally Vala has a mechanism called Type Inference, whereby a local
> > variable may be defined using var instead of giving a type, so long as
> > it is unambiguous what type is mean
On Tue, 2009-01-27 at 12:12 +0100, pancake wrote:
> Actually Vala forces you to pass the correct type for assignations ,
> argument passing in functions, etc..
>
> I think this should be a warning instead of an error. And Vala should
> know about which basic
> types can be automatically casted (
On Tue, 2009-01-20 at 16:02 +0100, Frederik wrote:
> Hans Vercammen wrote:
> > /usr/include/libgda-3.0/libsql/sql_parser.h:122: syntax error, unexpected
> > typedef-name, expecting identifier or '('
> > /usr/include/libgda-3.0/libsql/sql_parser.h:297: syntax erro
On Tue, 2009-01-20 at 14:39 +0100, Frederik wrote:
> How did you bind 'libsql/sql_parser.h'? It has unions and stuff. :(
The internals in v4 have changed significantly. I didn't check into the
unions generation, but these do not seem to exist anymore. It's a bit
odd. I get an error for v3:
/usr/i
On Tue, 2009-01-20 at 13:55 +0100, Frederik wrote:
> I am trying to bind libgda-3.0 (generation base attached to this mail).
> I have already worked around some naming conflicts via metadata. But for
> one thing I have no solution:
Cool!
> In 'libgda/gda-data-model.h' there is this enum:
>
> typ
On Tue, 2009-01-20 at 12:21 +0100, Luca Dionisi wrote:
> On Tue, Jan 20, 2009 at 11:57 AM, Frederik wrote:
> > Alberto Ruiz wrote:
> >> I actually think, that it would be really nice to do a good GNOME (as
> >> in the platform) Tutorial based in Vala. Teaching how to create a
> >> GNOME app from t
On Tue, 2009-01-13 at 23:27 +0100, Jürg Billeter wrote:
> On Tue, 2009-01-13 at 23:01 +0100, Hans Vercammen wrote:
> > On Mon, 2009-01-12 at 14:43 +0100, Jürg Billeter wrote:
> > > On Mon, 2009-01-12 at 08:40 +0100, Hans Vercammen wrote:
> > > > On Sun, 2009-01-11
On Mon, 2009-01-12 at 14:43 +0100, Jürg Billeter wrote:
> On Mon, 2009-01-12 at 08:40 +0100, Hans Vercammen wrote:
> > On Sun, 2009-01-11 at 14:14 +0100, Jürg Billeter wrote:
> > > * Internal API
> > >The whole point of an internal API is that it is internal, and w
On Sun, 2009-01-11 at 14:14 +0100, Jürg Billeter wrote:
> * Internal API
>The whole point of an internal API is that it is internal, and we
>should therefore aim to separate public from internal header files.
Yes, that sounds like a very good idea. Could we extend this with
G_GNUC_INTERNA
On Sat, 2009-01-10 at 21:12 -0500, Yu Feng wrote:
> On Sat, 2009-01-10 at 23:48 +0100, Hans Vercammen wrote:
> > On Sat, 2009-01-10 at 13:07 -0500, Yu Feng wrote:
> > > On Sat, 2009-01-10 at 18:35 +0100, Jürg Billeter wrote:
> > > > On Sat, 2009-01-10 at 12:19 -050
On Sun, 2009-01-11 at 01:23 +0100, Thomas Chust wrote:
> Hans Vercammen wrote:
> > On Sat, 2009-01-10 at 13:16 -0800, Noah Gibbs wrote:
> > [...]
> >> Remember that an object can be part of more than one cycle, and you
> >> have to know how many of those ref
On Sat, 2009-01-10 at 13:16 -0800, Noah Gibbs wrote:
> In addition to keeping a list of pointers to the object, you'll need
> to traverse them in some way to find cycles and free storage with
> cycles, but not pointed to by any non-cycles. That pass should not be
> done every time you break a poin
On Sat, 2009-01-10 at 13:07 -0500, Yu Feng wrote:
> On Sat, 2009-01-10 at 18:35 +0100, Jürg Billeter wrote:
> > On Sat, 2009-01-10 at 12:19 -0500, Yu Feng wrote:
> > > On Sat, 2009-01-10 at 09:24 +0100, Jürg Billeter wrote:
> > > > On Sat, 2009-01-10 at 01:04 -0500, Yu Feng wrote:
> > > > > On Fri,
On Sun, 2008-12-21 at 13:25 -0500, Yu Feng wrote:
> On Sun, 2008-12-21 at 00:16 +0100, Jürg Billeter wrote:
> > On Sat, 2008-12-20 at 23:57 +0100, Hans Vercammen wrote:
> > > On Sat, 2008-12-20 at 08:24 +0100, Jürg Billeter wrote:
> > > > On Sat, 2008-12-20 at 02:
On Sun, 2008-12-21 at 00:16 +0100, Jürg Billeter wrote:
> On Sat, 2008-12-20 at 23:57 +0100, Hans Vercammen wrote:
> > On Sat, 2008-12-20 at 08:24 +0100, Jürg Billeter wrote:
> > > On Sat, 2008-12-20 at 02:19 +0100, Hans Vercammen wrote:
> > > > On Fri, 2008-12-19
On Sat, 2008-12-20 at 08:24 +0100, Jürg Billeter wrote:
> On Sat, 2008-12-20 at 02:19 +0100, Hans Vercammen wrote:
> > On Fri, 2008-12-19 at 12:10 +0100, Jürg Billeter wrote:
> > >
> > > * `(owned)' cast replaces `#' reference transfer expression
On Fri, 2008-12-19 at 20:49 -0500, Jamie McCracken wrote:
> On Sat, 2008-12-20 at 02:19 +0100, Hans Vercammen wrote:
> > On Fri, 2008-12-19 at 12:10 +0100, Jürg Billeter wrote:
> > >
> > > * `(owned)' cast replaces `#' reference transfer expression
On Fri, 2008-12-19 at 12:10 +0100, Jürg Billeter wrote:
>
> * `(owned)' cast replaces `#' reference transfer expression
>
> Even less used, equally unintuitive. Example of new syntax:
>
> string foo = (owned) bar;
I don't have a strong opinion on this since I don't really need it, but
usi
On Sun, 2008-12-14 at 05:23 +0100, Hans Vercammen wrote:
> On Sat, 2008-12-13 at 22:05 -0500, Yu Feng wrote:
> > Machines can be happy if the ccode are written carefully, but a
> > bilingual text is usually difficult for human beings to understand; to
> > me this is more convi
On Sat, 2008-12-13 at 22:05 -0500, Yu Feng wrote:
> On Sun, 2008-12-14 at 00:55 +0100, Hans Vercammen wrote:
> > > > > On Sat, 2008-12-13 at 23:44 +0600, Ildar Mulyukov wrote:
> > >[...]
> > > 1. inlining asm is most unportable. But this did not prevent from
On Sun, 2008-12-14 at 00:51 +0600, Ildar Mulyukov wrote:
> On 14.12.2008 00:00:31, Jamie McCracken wrote:
> > On Sat, 2008-12-13 at 17:46 +, Karl Lattimer wrote:
> > > On Sat, 2008-12-13 at 23:44 +0600, Ildar Mulyukov wrote:
> >>> What do you think about having C inline in Vala? This looks quit
On Sun, 2008-11-23 at 10:03 +0100, Jürg Billeter wrote:
> On Sun, 2008-11-23 at 00:13 -0500, Yu Feng wrote:
> > Both vala 0.5.1 and trunk fails to smoothly switching the parent
> > classes. if I have extra stuff in the creation methods.
>
> Do you have an example or bugzilla link?
Perhaps unrelat
gt; [...]
> On Sun, 2008-11-23 at 02:47 +0100, Hans Vercammen wrote:
> > (1) You either use the classical GObject construction scheme with a
> > registered constructor function (the construct block) and GObject
> > (construct) properties as parameters. You need [CCode
> >
Hello Yu,
On Fri, 2008-11-21 at 21:27 -0500, Yu Feng wrote:
> Dear Jurg and others,
>
> I have an idea about chaining up constructors to share with you.
>
> Situation
>
> We have 2 different constructors, the construction block(CB), and the
> construct function(CF).
>
> for GType based
On Sun, 2008-10-19 at 20:51 +0200, Jiqing Qiang wrote:
>Thanks for your input. Concerning the problem you mentioned, I'm
> aware of it, but I don't really know how to write it in a better way,
> suggestions are welcome.
Vala is pretty flexible when it comes to boxing existing C code into a
val
On Fri, 2008-10-17 at 04:53 -0700, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I just made a still incomplete binding for gcrypt, and added it to the
> External Bindings page[1].
>
> Hope to be useful.
>
> Cheers,
>
> [1] http://live.gnome.org/Vala/ExternalBindings
>
Very cool, thanks! Small questi
On Wed, 2008-10-15 at 23:05 +0400, Кутейников Дмитрий wrote:
> I have defined function with name register and Vala translated it to C
> as is.
> So gcc shows errors because "register" is reserved keyword in C.
Vala currently doesn't check possible conflicts in the C namespace but
it's definitely
Hi,
On Wed, 2008-10-15 at 22:05 +0400, Кутейников Дмитрий wrote:
> I wrote this:
>
> class Item
> {
> public uint8 x, y, zlevel;
> public string location;
> }
>
>
> and got an error:
>
> objects.vala:18.19-18.19: error: syntax error, expected de
On Mon, 2008-10-13 at 07:25 +0100, Sam Liddicott wrote:
> I suggest that these attributes should be able to be declared in the C header
> file using vala key words which in C are #defined to nothing.
A more general stand-alone gobject-introspection module[1] is currently
under heavy development,
On Sat, 2008-10-11 at 14:50 -0700, Geert Jan wrote:
> When I don't use a weak TreePath, like this:
>
> TreePath path;
> weak TreeViewColumn focus_column;
> treeview.get_cursor (out path, out focus_column);
>
> I get this error:
>
> error: duplicating TreePath instance, use weak variable or
Hi,
On Fri, 2008-10-10 at 17:32 +, Tonatiuh Morales wrote:
[...]
> [Compact]
> [CCode (cheader_filename = "shapefil.h")]
> public class DBFHandle {
> }
> [Compact]
> [CCode (cheader_filename = "shapefil.h")]
> public class DBFInfo {
I'm not familiar w
On Wed, 2008-10-08 at 20:33 +0200, Hans Vercammen wrote:
> Hi Jürg,
>
> On Wed, 2008-10-08 at 09:57 +0200, Jürg Billeter wrote:
> > The plan for gobject-introspection is to have two names per gir file,
> > one is a unique module name, which can be used e.g. in Python, a
Hi Jürg,
On Wed, 2008-10-08 at 09:57 +0200, Jürg Billeter wrote:
> The plan for gobject-introspection is to have two names per gir file,
> one is a unique module name, which can be used e.g. in Python, and the
> other is a namespace that doesn't have to be unique.
Cool, so for good understanding
Hi,
I have been toying a bit with the new gobject-introspection module at
gnome-svn and some things caught my attention. It seems that the glib
library is divided into different namespaces according to the glib
modules, which follows more or less the python bindings. Assuming that
at some point in
Hi,
On Fri, 2008-08-22 at 05:49 -0400, Yu Feng wrote:
> Just a scratch of idea:
>
> class array {
>[CCode (snippet = "int i; while(((T)this)[i]) i++; return i;")]
>public int get_length();
>[CCode (snippet = "gpointer * rt; while((T)(this)[i]) i++; result.length =
> i; rt = g_new0(T,
Hi Nicolas,
On Wed, 2008-06-04 at 16:51 +0200, gege2061 wrote:
> I create a vala parser for ctags from the C/C#/Java/Vera parser.
I assume you need this in the context for the valide project. You
should definitely take a look at the tagmanager part of the anjuta
project. It's also some sort of s
On Fri, 2008-05-30 at 10:40 +0200, Juerg Billeter wrote:
> > Assigning private or protected values during construction is a rather
> > common practice, but I don't know what the preferred solution would be.
> > Personally I like the {get; set;} thing, even for just marking private
> > fields read/w
Hi Jürg,
Thanks again for clearing things up.
> For cases where this is a performance issue, we're improving the support
> for non-GObject (but still GType-registered) classes, which follow more
> closely the C# and Java construction scheme.
Will the non-gobject approach in the future provide oo
Hi Yu,
> MyObject * my_object_new(int my_value){
> MyObject * myobject = g_object_new(TYPE_MY_OBJECT, NULL);
> MyObjectPrivate * priv = MY_OBJECT_GET_PRIVATE(myobject);
> priv->my_value = my_value;
> }
Yes, this was exactly what started me thinking. But indeed this doesn't
add up in the end
Hi Jaap,
> The reason for this is that the objects are gobjects and these are
> created by a g_object_new call [1]. That function can only set
> properties. So you need to have a property if you want to pass data to
> your constructor
Thanks, yes you are absolutely right, I was not thinking outsi
Now the construct keyword for properties in the class constructor
arguments is being deprecated, I started to adjust some things and
stumbled upon some implementation questions.
While "private int foo { get; set; }" does not make much sense and
should better be optimized to "private int foo;", ass
Thanks for your clarification.
I have made the sample able to compile, but I was wondering if there
were any plans on pre-catching wrong casts and so eliminating following
warnings at runtime:
(process:6903): GLib-GObject-WARNING **: invalid cast from `FalseFoo' to
`Foo'
(process:6903): GLib-GOb
> My first test (http://live.gnome.org/Vala/BasicSample) declare private
> structure in public classe structure :
>
> [in header file]
> struct _Sample {
> GObject parent_instance;
> SamplePrivate * priv;
> };
>
> But I don't found SamplePrivate definition... I re-check tomorow.
>
Y
Just realized you probably ment the o->free () in relation to pointers
Object* o = new Object();
o->free ();
I don't know why keyword delete isn't used, maybe this can be supported
in future?
Hans
___
Vala-list mailing list
Vala-list@gnome.org
http:
Hi,
> - Why Glib.Object inheritace is not implicit ?
Quoted Jürg:
While most classes (should) derive from GObject, it's not always the
case. For one there are many libraries that don't use GObject at all or
don't use GObject for all class types and we want to be able to use such
libraries from Va
Hi all,
First of all, many thanks for a great initiative which has in my opinion
a very bright future!
I am not quit sure on which level invalid type casts should be
monitored, whether it be the vala compiler or the underlaying gobject.
Please view the attached test-case for details.
As I unders
53 matches
Mail list logo
