Maciej Piechotka | 1 Feb 09:51 2009
Picon

Re: [Vala] .vapi and GPL

vasaka@... writes:

> .vapi files are licensed under LGPL license, but some of them defines
> bindings to kernel api and hence make use of linux headers on stage of
> compiling generated C code which are GPL. does it mean that those
> files also should be licensed under GPL or that one can reduce GPL to
> LGPL since those vapi files are not derived from linux code?
>

IANAL but I'd guess that the vapi files are the description of linux
headers - which can be published on any license. But the code which use
them needs to be on GPL. But - as I pointed out - I'm not a specialist
in this area.

Regards
--

-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)
Matías De la Puente | 1 Feb 16:35 2009
Picon

Re: [Vala] Type of data in TreeView



2009/1/31 Thomas Chust <chust-S0/GAf8tV78@public.gmane.org>
Matías De la Puente wrote:
> [...]
> I want to add any type of data to a TreeView.
> What is the best option to do this ?
> [...]

Hello,

the GLib already provides a generic value container: GLib.Value.
It should be possible to use that.

I try to use that but i'm having some troubles...
 

cu,
Thomas


--
When C++ is your hammer, every problem looks like your thumb.

_______________________________________________
Vala-list mailing list
Vala-list@...
http://mail.gnome.org/mailman/listinfo/vala-list
Jürg Billeter | 1 Feb 17:53 2009
Picon

Re: [Vala] Abstract properties delared in VAPI files

On Sat, 2009-01-31 at 13:40 +0100, Jacob Kroon wrote:
> Ok, hope this test case is ok, I've attached a small library file which
> I compile with "valac foo-bar.vala --library=foo -C", in order to
> get .vapi file.
> 
> Then I run "valac foo.vapi", and I get the same kind of error messages. 

Thanks for the testcase, fixed in r2415.

Jürg

_______________________________________________
Vala-list mailing list
Vala-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Martin Olsson | 1 Feb 22:10 2009
Picon

[Vala] "checked vs unchecked exceptions" && API design guidelines for Vala

When Java was designed they went for checked exceptions. Later when the C#
language was designed they went for unchecked exceptions. I'd like to
understand better why one would go with either one. Also, does GObject
give a bias in any direction? Should I be using "return codes" instead of
"exceptions" like most of C programs tend to do? (after all Vala
exceptions just wraps GError's and they are pretty different from Java or
C# exceptions)

I'm curious, why does Vala have checked exceptions? What was the rationale
behind that design decision? I'm also curious about what API design
guidelines are useful when designing API's in languages with checked
exceptions.

Below I've describe a concrete question I was thinking about earlier
today. What is the best way to define a .peek() method on a stack class in
Vala? I've tried to outline four different ways to do it but the most
readable way is not possible in Vala because the lack of unchecked
exceptions (I really don't want to add throws StackError to the
process_stack method because it's valid to call this function with both
empty stacks and non-empty stacks and thus the caller should not need to
worry).

I think alternative #4 is the most readable, but Vala does not support
writing code like that (no unchecked exceptions). So for now I think I
will go with either #1 or #3. Even though #3 is shorter I think I like #1
the most because it makes it more clear that empty stacks are handled as a
special case. In #3 it's not obvious to an outside that trypeek() fails
_only_ when the stack is empty, thus while reading this code it's hard for
the outsider to know when which branch is taken. This is made easier in #1
because it's clear that the assert(false) branch is not meant to be taken
and if it is taken that would be obvious at runtime.

Most importantly, can anyone think of an API design that would yield even
more readable and simple code? Especially, can I get the code to become as
simple as alternative #4 despite checked exceptions?

public static void process_stack (Stack<string> stack)
{
        // Alternative #1 --- "check, try and assert on failure"
        if (stack.Count == 0) {
                ... handle empty stack here ...
        } else {
                string element1;
                if (!stack.trypeek (out element1))
                        assert (false);
                stdout.printf ("element1 == %s\n", element1);
        }

        // Alternative #2 --- "checked exception"
        if (stack.Count == 0) {
                ... handle empty stack here ...
        } else {
                string element2;
                try {
                        stdout.printf ("element2 == %s\n", stack.peek ());
                } catch (StackError.CANT_PEEK_AT_EMPTY_STACK e) {
                        assert (false);
                }
        }

        // Alternative #3 --- "dont check, just try and then handle failure"
        string element4;
        if (stack.trypeek(out element4) {
                stdout.printf ("element4 == %s\n", element4);
        } else {
                ... handle empty stack here ...
        }

        // Alternative #4 --- "unchecked exception" (works in C# but not
in Java/Vala)
        if (stack.Count == 0) {
                ... handle empty stack here ...
        } else {
                stdout.printf ("element3 == %s\n", stack.peek ());
        }

}

I'd be very interested to hear some opinions on this.

Martin
Attachment (main.vala): text/x-vala, 2353 bytes
_______________________________________________
Vala-list mailing list
Vala-list@...
http://mail.gnome.org/mailman/listinfo/vala-list
Ed Schouten | 1 Feb 19:26 2009
Picon

Re: [Vala] .vapi and GPL

* vasaka@...
<vasaka@...> wrote:
> .vapi files are licensed under LGPL license, but some of them defines
> bindings to kernel api and hence make use of linux headers on stage of
> compiling generated C code which are GPL. does it mean that those
> files also should be licensed under GPL or that one can reduce GPL to
> LGPL since those vapi files are not derived from linux code?

I can't really understand why vapi's of libraries of which we can't be
sure they are GPL are GPL licensed themselves. In my opinion it would
make more sense to use a MIT, X11 or BSD license on, say, the POSIX
vapi.

But I'm not sure this is required. I seem to recall that you are allowed
to use GPL licensed headers/libraries if the API that is implemented is
a default system interface... But IANAL. :-)

--

-- 
 Ed Schouten <ed@...>
 WWW: http://80386.nl/
_______________________________________________
Vala-list mailing list
Vala-list@...
http://mail.gnome.org/mailman/listinfo/vala-list
Thomas Chust | 2 Feb 00:04 2009
Picon

Re: [Vala] "checked vs unchecked exceptions" && API design guidelines for Vala

Martin Olsson wrote:
> When Java was designed they went for checked exceptions. Later when the C#
> language was designed they went for unchecked exceptions. I'd like to
> understand better why one would go with either one.
> [...]

Hello,

I think this is mainly a matter of taste, like it is the case for many
programming language design decisions.

If a language has only unchecked exceptions, it means that the language
designer thought they should normally be used only to signal error cases
detected at runtime that cannot always be handled. Checked exceptions on
the other hand can also be thought of as auxiliary return paths.

A more pragmatic reason why C# has unchecked exceptions is probably the
experience with Java where the combination of several APIs especially in
the presence of callback interfaces often leads to an absurd amount of
useless work to ensure correct exception handling -- checked exceptions
are boxed in unchecked ones or checked ones of a different type and
unwrapped at a different stack level. With unchecked exceptions this
kind of problem never occurs.

> [...]
> Should I be using "return codes" instead of "exceptions" like most of C
> programs tend to do? (after all Vala exceptions just wraps GError's and
> they are pretty different from Java or C# exceptions)
> [...]

Since GError handling is accessible from C without problems and is a far
more flexible error handling scheme than using plain integer return
codes or global variables, I would always recommend to use Vala's
exception mechanism and not to reinvent the wheel in a less comfortable
and more error prone way.

> [...]
> I'm curious, why does Vala have checked exceptions? What was the rationale
> behind that design decision?
> [...]

The simple answer to this question is that unchecked exceptions cannot
be modelled on top of GError handling well, since GErrors can only be
propagated by functions that know about them. Hence checked exceptions
are the most logical choice for Vala.

> [...]
> Below I've describe a concrete question I was thinking about earlier
> today. What is the best way to define a .peek() method on a stack class in
> Vala?
> [...]

My personal opinion is that no matter what type of exceptions is used,
your alternative #3 is the most readable and logical way of doing it,
since peeking at an empty stack is not really an error of any kind. A
peek operation is precisely intended to check whether something is empty
and to possibly also return an element if it is not. This should be
represented by an appropriate return type, for example with a boolean
return and an output parameter or with a polymorphic return type that
can either hold a value or represent the absence of one.

However, if you absolutely want to use exceptions for this kind of task,
my personal opinion is that an unchecked exception would be a totally
inappropriate choice here, since the absence of a value in a peek
operation is not a hard runtime error, rather it is one of the expected
outcomes of this operation and should therefore always be processed.

These consideration don't apply to a regular pop or get operation, of
course.

cu,
Thomas

--

-- 
When C++ is your hammer, every problem looks like your thumb.
Frederik | 2 Feb 01:09 2009
Picon
Picon

Re: [Vala] "checked vs unchecked exceptions" && API design guidelines for Vala

Martin Olsson wrote:
> When Java was designed they went for checked exceptions. Later when the C#
> language was designed they went for unchecked exceptions. I'd like to
> understand better why one would go with either one. Also, does GObject
> give a bias in any direction? Should I be using "return codes" instead of
> "exceptions" like most of C programs tend to do? (after all Vala
> exceptions just wraps GError's and they are pretty different from Java or
> C# exceptions)
> 
> I'm curious, why does Vala have checked exceptions? What was the rationale
> behind that design decision? I'm also curious about what API design
> guidelines are useful when designing API's in languages with checked
> exceptions.

To me it seems that the Vala design favours design-by-contract. Vala has
'requires' and 'ensures' keywords, parameters must be explicitly marked
as nullable and exceptions in Vala are part of the method contract, in
contrast to C#. Vala seems to emphasize correctness.

You might be interested in this interview with James Gosling on checked
exceptions in response to another interview with Anders Hejlsberg:
http://www.artima.com/intv/solid.html

> Below I've describe a concrete question I was thinking about earlier
> today. What is the best way to define a .peek() method on a stack class in
> Vala? I've tried to outline four different ways to do it but the most
> readable way is not possible in Vala because the lack of unchecked
> exceptions (I really don't want to add throws StackError to the
> process_stack method because it's valid to call this function with both
> empty stacks and non-empty stacks and thus the caller should not need to
> worry).

As far as I know exception handling is not intended for programming
errors such as division by zero, null dereference, index out-of-bounds,
etc. Exceptions should not be used for ordinary control flow, but for
unexpected failures / failures that the programmer can't predict (e.g.
I/O errors). If someone tries to peek an element from an empty stack
that's clearly a programming error. Your method should use assertions
for that and your stack API should provide means for the programmer to
query the state of his stack before if he's unsure about it, e.g. an
'is_empty ()' method.

> I think alternative #4 is the most readable, but Vala does not support
> writing code like that (no unchecked exceptions). So for now I think I
> will go with either #1 or #3. Even though #3 is shorter I think I like #1
> the most because it makes it more clear that empty stacks are handled as a
> special case. In #3 it's not obvious to an outside that trypeek() fails
> _only_ when the stack is empty, thus while reading this code it's hard for
> the outsider to know when which branch is taken. This is made easier in #1
> because it's clear that the assert(false) branch is not meant to be taken
> and if it is taken that would be obvious at runtime.

I'd go for Alternative #1.

Regards,

Frederik
Martin Olsson | 2 Feb 20:12 2009
Picon

Re: [Vala] "checked vs unchecked exceptions" && API design guidelines for Vala

Thomas Chust wrote:
> My personal opinion is that no matter what type of exceptions is used,
> your alternative #3 is the most readable and logical way of doing it,
> since peeking at an empty stack is not really an error of any kind. A
> peek operation is precisely intended to check whether something is empty
> and to possibly also return an element if it is not. This should be
> represented by an appropriate return type, for example with a boolean
> return and an output parameter or with a polymorphic return type that
> can either hold a value or represent the absence of one.

Thanks for the reply (and also thanks to Fredrik), both replies made
excellent points and I certainly understand this issue more in depth now.

In the end I opted for alternative #3 and besides your arguments
I also noted that this alternative makes it possible to implement the
API in a thread safe way should this be desired. There will always be
a potential race between checking .Length and doing .peek() so it
seems like a good habit to favor trypeek instead of peek by default.

		Martin
Michael 'Mickey' Lauer | 3 Feb 02:07 2009
Picon

[Vala] posix.vapi additions (signal)

Please add to posix.vapi:

    [CCode (cheader_filename = "signal.h")]
    public const int SIGHUP;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGINT;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGQUIT;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGILL;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGTRAP;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGABRT;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGIOT;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGBUS;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGFPE;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGKILL;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGUSR1;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGSEGV;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGUSR2;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGPIPE;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGALRM;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGTERM;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGSTKFLT;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGCLD;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGCHLD;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGCONT;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGSTOP;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGTSTP;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGTTIN;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGTTOU;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGURG;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGXCPU;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGXFSZ;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGVTALRM;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGPROF;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGWINCH;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGPOLL;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGIO;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGPWR;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGSYS;
    [CCode (cheader_filename = "signal.h")]
    public const int SIGUNUSED;

    public static delegate void sighandler_t (int signal);

    [CCode (cheader_filename = "signal.h")]
    public sighandler_t signal (int signum, sighandler_t handler);

--

-- 
:M:
Cliff Brake | 3 Feb 20:37 2009
Picon

[Vala] ProcessSignal compile error

The following code:

using GLib;

void main()
{
    message("KILL value = %i", (int)ProcessSignal.KILL);
}

Gives the following compile error:

test.c: In function '_main':
test.c:13: error: 'G_PROCESS_SIGNAL_KILL' undeclared (first use in
this function)
test.c:13: error: (Each undeclared identifier is reported only once
test.c:13: error: for each function it appears in.)
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)

I assume this should work?  If so let me know if I should add to bug
tracker, etc.

Thanks,
Cliff

--

-- 
=======================
Cliff Brake
http://bec-systems.com

Gmane