On Sat, 2007-09-08 at 06:42 +0200, pancake wrote:
Uh. Just to say 'Hi!' to the list and ask some questions :) - How is the gnet port? I need to - Is there any way to use a preprocessor with Vala? - How can I call inlined C code from Vala? - What is the threading stuff state? - How can I manage with execve's, popens and system()? And a final tip: - I think to avoid namespacing problems we can force filenames to be lowercase to avoid collisions with Namespaces and Classes. Having this rule as a 'standard' language rule we can avoid some newbye problems Finally I would like to say that I'm really happy to see this project going up. I was looking for something like that and I have finally found the right project :) Thanks! --pancake On Fri, 07 Sep 2007 19:23:16 +0200 Piotr Gaczkowski <doomhammerng gmail com> wrote:Dnia 06-09-2007, Cz o godzinie 07:01 +0200, Mathias Hasselmann napisał(a):GNet type_name_offset="1" GUnixSocket value_type="0"Is there any doc about what things are supported in .metadata files? I would like to know, how to tweak certain things, but I could only find possible settings in others' .metadata. Piotr Gaczkowski_______________________________________________ Vala mailing list Vala paldo org http://www.paldo.org/mailman/listinfo/vala
Hi all, I've done some work on the gnet-2.0 vapi file, but I haven't finished it (no testing yet). Thanks to Mathias we are closer to a functional vapi file, but not there yet. The main problem is that the struct and the function names follow a different convention. For example see GInetAddr struct and the gnet_inetaddr_* functions we have 2 namespaces but *also* we have two different struct names in the gidl file GInetAddr and GnetInetaddr different camel case in the Inetaddr part. So vapigen generate two classes InetAddr and netInetAddr To make a long story short I've made some modifications to the vapigen code but I don't know if is the best approach (Mathias :) ...) The first block of code introduces the support for the name "override" attribute and the second one tries to better infer the typename if the namespaces start with the same letters (G vs Gnet). there is some debugging output and the gnet-2.0.metadata misses the configurations for all types but GnetInetAddr, but if this is correct I will finish it. Bye, Andrea
Attachment:
gnet-2.0-bindings.patch
Description: Text Data