2011-12-17

Vala bindings

No man who didn't tried to implement .vapi interface to C-library could fully understand me. I've gone a pretty short path through this hell and already hit so many issues...

Static field construction doesn't even happen for [Compact] classes (bye-bye RAII for library init/cleanup).

[CCode (lower_case_csuffix = "xxx")] - just makes nothing (btw, you can specify any properties and they just would be ignored).

struct don't allow other types declaration inside of it (have no idea what is the reason for that).

string get_driver(); and string dirver { get; } - is totally different things even that C-names for generated code are the same (be careful when uses them in .vapi). First one causes returned string to be freed, but second does nothing (you can try with any type). Nothing special mentioned in documentation.

After narrowing sample and putting it into .vala file you notice that get_dirver() { return "XXX"; } returns g_strdup() of returned value, but dirver { get { /* ... */ } } returns value directly.

To sort that out - you have to use all your charm to squize out of Google several letters in mail-list. 3 years and Google can't find documentation, small wiki page or blog post...

So now we are aware of the fact that default meaning owned/unowned might change depending on context. That makes sense when you want spend minimum effort (not only lines of code, but thinking) to bring another external library to Vala. But that small thing might make harm to your mind. We know that we should write string driver { owned get; } if you want caller to be responsible for removing object.

    [Compact]
    [CCode (cname = "char", free_function = "cpufreq_put_driver")]
    public class Driver : string {
    }

    [SimpleType]
    [Immutable]
    [CCode (cname = "unsigned int", cprefix = "cpufreq_")]
    public struct Cpu : uint {
        public Driver driver { owned get; }
    }
 

But if that would be all problems, I have had, I wouldn't write this post at all...

2011-12-15

Unboxed arrays in Haskell

There is a great idea of Data.Ix implemented for nice and fast Data.Array.Unboxed and others. That allows to form arrays, matrices and other schemas (even triangles) of data access. To gain that flexibility we separate storage implementation (i.e. continous sequence of bytes) from indexing schema implementation.
But sometimes we need a way to access more complex objects and still have that magic Unboxed storage. I.e. instead of accessing single object we need two of them. Once again mighty of Haskell type system comes to save us. Just add another index axis and hide it in the same way how Ix do.