Dunno, I've never done that much low-level X handling. My guess is that free() is freeing the memory allocated to that object, but that destroy_...() will also clean up references in other data structures. So, if I had to guess, I'd say free() on its own will leak memory, yes.

Haven't tried the nightlies yet: how many packages make up one IDE?! Sheesh... [EDIT: these 1.9.1 backports look quite handy for Ubuntu]

Yes, but destroy_image() for instance takes two parameters and probably that is the reason why it doesn't do its destruction magic. Another thing i noticed - vapigen inserts only one header filename for the whole VAPI, even though i used a whole bunch of headers for vala-gen-introspect. Maybe I'm doing something wrong.

The IDE is only one package, but the framework is quite a number. That's one of the reasons why I don't like .NET.

The C functions in X11 are called not just to free the base memory but to also free anything linked under them.
This is similar to most other APIs as well.

Where a distinct cleanup function is provided for instance data you should use that and must not call free(...) on that memory unless explicitly told otherwise.


for instance, in liqbase i close up the x server:

int xv_canvas_close()
{
XShmDetach(dpy,&yuv_shminfo);
XFreeGC(dpy,gc);
XUnmapWindow(dpy,window);
XSPSetTSRawMode(dpy, False);
XDestroyWindow(dpy,window);
return 0;
}



(I hope i've not got the wrong end of the stick with this thread, you are automatically creating bindings to the x11 libraries for use in vala)

As it turns out it can't be done automatically At least not for not GObject based libs.

I wonder if it is possible at all, since as i see it, X destroy functions are using two parameters and Vala uses one, but that may be configurable.

EDIT: Then again, HildonDesktop needs only some functions and structs to generate, maybe i can add them by hand with specific header links (most are in Xlib.h i think). This can probably create a conflict when a real X VAPI arrives.

It would be great (at least for brace-challenged coders :-) to have a python-to-vala translator+compiler. Doesn't look totally impossible, either...

Python to C would be faster Since Vala is converted to C before compilation

Python->Vala would be easier though ;-)

What's a more interesting idea, though, is using existing OO bindings for libraries - say from Python - to generate VAPI files for Vala.

Update: after struggling to get MonoDevelop 2.0 alpha built & running; and then failing to get it doing anything with Vala, I decided to look more closely at Valable, an Eclipse plugin.

After a few nights of hacking it now does:

• Auto-determination of packages to include in build from "using ...;" lines (no need to futz around with pkg-config)
• Incremental builds (edit a file, press Save and only the necessary files get rebuilt, before whole project is relinked)
• Compile failures shown in editor on correct line
• Basic code-complete

This is in addition to the syntax highlighting and smart editing it already did. One possibly major limitation is that a project can only have a single main() method, otherwise gcc complains when it tries to link the object files.





My primary aims next are:

1. Improve code complete (context sensitive, include available packages etc.)
2. Test Maemo integration, e.g. with Scratchbox to build Hildon binaries.
3. Make it output a simple shell script which can be used to rebuild the project outside of Eclipse (e.g. a source package for the autobuilder)
4. Figure out how to use Launchpad better, so I can see about getting it committed as a branch.

Running MonoDevelop was no problem here, but so far I cannot really find a way to activate code completion or anything other than syntax highlighting, really.
That eclipse plugin seems to be abandoned, unfortunately. At least that's what the main branch says:
https://code.launchpad.net/~jprieur/.../valable.devel
So - vim for now here.

My changes to the plugin have been pushed into a branch:

https://code.launchpad.net/~aflegg/valable/jaffa

I've also made contact with the other developers to make sure we're not duplicating any work.

Current focus: trying to access libvala through Java (by converting the vala-1.0.vapi into something JNA can handle) so that code complete can be as intelligent, and context-sensitive, as we're used to in Eclipse.