Re: [Vala] embedding c code snippet in vala source.



Dear Friend,

I've changed the title of the bug 548897 to
'Wrapping c code segment (snippet) around cfunc in .vapi files'

I hope this name is more GOB-victim friendly. 

I understand that as you pointed out, using external can glue c code in
a more pretty way. However we don't want any extra libraries to glue
vala code and an existed c library(I suppose this is one of vala's
announced advantage over other GLib bindings?); and under this
constraint creating a new .c file doesn't work.

Since 
(1) this feature is now intended for the vapi authors to write vala
library bindings, and 
(2) the binding authors are supposed to understand vala and c
programming to some extent, 
(3) If we don't document it, body knows they can also write raw function
in a .vala file, (or we can even deny this feature at all).
(4) we can always document that CCode snippets is intended for library
bindings and should be used as few as possible.
(5) I can anticipate that with some further work several GList hints in
valac can be moved to glib-2.0.vapi. 

I still believe pros > cons.

Which do you prefer if you want to split a string? mysplit or split?

    [CCode (cname = "g_strmysplit", snippet = "gchar ** rt = g_strsplit(this,
delimiter, max_tokens); *result_length1 = rt?g_strv_length(rt):0; return rt;")]
    public string[] mysplit (string delimiter, int max_tokens = 0);

    [CCode (cname = "g_strsplit")]
    [NoArrayLength]
    public string[] split (string delimiter, int max_tokens = 0);


Yu

On Fri, 2008-08-22 at 08:24 +0200, Ali Sabil wrote:


On Fri, Aug 22, 2008 at 7:32 AM, Yu Feng <rainwoodman gmail com>
wrote:
        
        On Thu, 2008-08-21 at 23:18 +0100, Emmanuele Bassi wrote:
        > On Thu, 2008-08-21 at 14:27 -0400, Yu Feng wrote:
        > > Dear all,
        > >
        > > I made a patch that allows embedding c code snippet in
        vala source.
        > >
        > > http://bugzilla.gnome.org/show_bug.cgi?id=548897
        > >
        > > This is quite primitive and more has to be done,
        especially to translate
        > > the vala variable names to cnames.
        >
        > no, please: let's not turn Vala into the new GOB. this makes
        the code an
        > unbearable mess - been there, done that.
        
        I don't agree with you.
        
        It is whom that messed up GOB messed up GOB.
        
        The code snippet is quite different from how embedding c code
        is done in
        GOB. Please have a look at the example given in the bug
        report.
        
        The embedded code is in unit of member methods. It is
        something similiar
        to Watcom's embedding asm in their C compiler. You define a
        function,
        and the function has an assembly body.
        
        People can always write messy code if they like. It doesn't
        depend on
        the language features.
        
        I personally consider the c code embedding more like an
        alternative way
        to glue C code with vala than the vast number of quirks
        in .vapi files.
        
        The following example may help you appreciate the snoippet
        patch:
        
        --------
        using GLib;
        /**********VVVVV**/
        [Compact]
        class mystring {
           [CCode (snippet = "gchar ** rt = g_strsplit(this,
        delimiter,
        max_tokens); *result_length1 = rt?g_strv_length(rt):0; return
        rt;")]
           public string[] mysplit (string delimiter, int max_tokens =
        0);
        }
        /***^^^^^^^^^^^^^*/
        class ClassA: Object {
           public static void main(string [] args) {
               ClassA obj = new ClassA();
               string test = "hello world\n line 2\n line3\n";
               string [] lines = ((mystring)test).mysplit("\n", -1);
               foreach(string s in lines) {
                   message("%s", s);
               }
           }
        }
        -------
        
        mystring.mysplit is an analogue with GLib.string.split, but it
        returns
        the string length as well.
        
        I am working on a further patch to compile the wrapped (with
        VVV ^^^)
        code even if it is in a .vapi file.
        
        At least this snippet thing can help us move some of knowledge
        of GLib
        away from valac to the .vapi bindings. (hopefully also the
        reference
        counting hell of GList, GSlist, and even vala array).
        
        There is also a hope to solve
        http://bugzilla.gnome.org/show_bug.cgi?id=548897 as mentioned
        by Alexey.
        
        Cheers,

Did you know that vala supports the "extern" modifier ?

extern void foo (int f);

and then create a .c file and define
void foo (int f) {g_debug ("Hello world %d", f);}

and then compile and link everything. 







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]