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
hmm. I thought if I declare something as volatile they will be stored in
memory instead of registers.
On i386 FPU the double numbers in the register has a higher precision
than the double numbers in memory and the compilier optimization is
apparently causing me troubles: by adding a stdout.print o
Is that even be possible on 32bit? sizeof(gdouble) is 8.
-- Christian
On Sun, 2009-01-11 at 17:54 -0500, Yu Feng wrote:
> Hi all,
>
> How do I declare a volatile double variable?
>
> Yu
>
> ___
> Vala-list mailing list
> Vala-list@gnome.org
> http:/
Hi all,
How do I declare a volatile double variable?
Yu
___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Dear Jurg,
HashTable is broken in trunk with an error:
error: `GLib.Quark' is not a supported generic type argument, use `?' to
box value types
But Quark is actually a SimpleType. Is SimpleType no longer propagated?
Yu
___
Vala-list mailing list
Va
If you implemented the last solution, my current use case would always
require the -H option. But I may not be typical that way.
Would that interact well with precompiled headers? I'd worry a bit about
that. It seems like writing the necessary header subsections into every .C
file would
My point on this.
I took a look at gtkwidget.c and gtkcontainer.c.
GtkWidget has a parent reference to GtkContainer so it should have
circular header files.
It turns out they avoid the cycle by defining the parent member of
GtkWidget as a GtkWidget instead of what it should be (GtkContaienr).
The win32 installer:
http://code.google.com/p/valide/downloads/detail?name=vala-0.5.5.exe
2009/1/10 Jürg Billeter
> We are pleased to announce version 0.5.5 of Vala, a compiler for the
> GObject type system.
>
> Vala 0.5.5 is now available for download at:
> http://download.gnome.org/sources/v
On Sun, 2009-01-11 at 15:07 +0100, Jürg Billeter wrote:
> Hi Yu,
>
> On Sat, 2009-01-10 at 13:11 -0500, Yu Feng wrote:
> > Is it possible to expose ref and unref member of gtypeinstance classes?
> >
> > They will be useful with GHashTable.new_full
> >
> > I am currently using a dirty workaround
On Sun, 2009-01-11 at 14:50 +0100, Jürg Billeter wrote:
> On Sat, 2009-01-10 at 19:32 -0500, Yu Feng wrote:
> > I made a patch to accept the following syntax:
> >
> > class Container {
> > ...
> > }
> > class Stuff: Container {
> >Stuff() {
> >base();
> >}
> > }
> >
> > Bug #56731
On Sun, 2009-01-11 at 16:41 +0200, Arto Karppinen wrote:
> Jürg Billeter wrote:
> > * Header file interdependencies
> >Header files often depend on other header files and sometimes these
> >dependencies form cycles. These cycles are currently detected by the
> >compiler and resolved as
Jürg Billeter wrote:
I want to finally solve issues we're having related to generation of C
header files. The current situation is that valac generates a .h file in
addition to a .c file for each .vala source file. The .h files describe
both, the public and the internal, C API.
There are various
On Sun, Jan 11, 2009 at 3:14 PM, Jürg Billeter wrote:
> * Generate two sets of header files
> For each source file foo.vala, we could generate foo-priv.h in
> addition to foo.c and foo.h and move the internal C API there. One
> issue with this approach is that it clutters the source directo
Hi Yu,
On Sat, 2009-01-10 at 13:11 -0500, Yu Feng wrote:
> Is it possible to expose ref and unref member of gtypeinstance classes?
>
> They will be useful with GHashTable.new_full
>
> I am currently using a dirty workaround like this:
>
> class A {
>public static extern void unref(void*);
>
On Sat, 2009-01-10 at 23:48 +0100, Hans Vercammen wrote:
> Why do this manually? Don't you need to chain the dispose handlers
> throughout the hierarchy to make it usable somehow?
> As far as I understand the GObject dispose mechanism, it doesn't prevent
> the cyclic references from not being clean
On Sat, 2009-01-10 at 19:32 -0500, Yu Feng wrote:
> I made a patch to accept the following syntax:
>
> class Container {
> ...
> }
> class Stuff: Container {
>Stuff() {
>base();
>}
> }
>
> Bug #567319
Thanks for the patch. I don't think it's a good idea to require the
developer
I want to finally solve issues we're having related to generation of C
header files. The current situation is that valac generates a .h file in
addition to a .c file for each .vala source file. The .h files describe
both, the public and the internal, C API.
There are various issues with the curren
17 matches
Mail list logo
