hello,
the attached .vala file causes valac to segfault during compilation (it
used to compile fine with 0.5.4).
Make check passes all 27 tests, and valac can compile itself, so it
shouldn't be a problem with my installation, but if someone could check
to make sure...
Thanks
alberto
PS:
On Sun, 2009-01-11 at 10:52 -0500, Yu Feng wrote:
Therefore my opinion on the cycles is that there should not be
unsolvable typedef cycles ( with .h, -priv.h and .c) in a properly
designed program, because these cycles represents solid cycles in your
Class atlas; which (as I can remember)
On Sun, 2009-01-11 at 08:49 -0800, Noah Gibbs wrote:
If you implemented the last solution, my current use case would always
require the -H option. But I may not be typical that way.
You will need -H for each library or application with plugin system.
However, not much we can do about that as
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 we
should therefore aim to separate public from internal header files.
Yes, that sounds
Hi,
I am curious but are there any reasons to avoid static abstract member
functions? They seem to be pretty doable because the class structure is
instance-independent.
Regards,
Yu
___
Vala-list mailing list
Vala-list@gnome.org
On Mon, 2009-01-12 at 14:32 +0100, Jürg Billeter wrote:
On Sun, 2009-01-11 at 10:52 -0500, Yu Feng wrote:
Therefore my opinion on the cycles is that there should not be
unsolvable typedef cycles ( with .h, -priv.h and .c) in a properly
designed program, because these cycles represents solid
