Jaffa | # 31 | 2008-07-14, 12:47 | Report

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]

---

Last edited by Jaffa; 2008-07-14 at 12:55. Reason: Found Ubuntu backports

Bundyo | # 32 | 2008-07-14, 13:17 | Report

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.

lcuk | # 33 | 2008-07-14, 13:25 | Report

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)

---

Last edited by lcuk; 2008-07-14 at 13:39. Reason: sp

Bundyo | # 34 | 2008-07-14, 13:30 | Report

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.

---

Last edited by Bundyo; 2008-07-14 at 13:33.

fpp | # 35 | 2008-07-14, 17:28 | Report

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

Bundyo | # 36 | 2008-07-14, 18:13 | Report

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

Jaffa | # 37 | 2008-07-15, 12:24 | Report

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.

Jaffa | # 38 | 2008-07-24, 22:48 | Report

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.

darklajid | # 39 | 2008-07-25, 19:02 | Report

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.

Jaffa | # 40 | 2008-07-25, 19:17 | Report

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.