Hi list, We all know that Vala is not perfect, and every now and again, I hit a bug in the compiler. I'm not talking about snags where something isn't as I expect it, but about Vala generating C code that doesn't compile or does improper memory management. As I know some of you also spend time working on complex Vala projects, and I'm sure that you, too, will stumble across some issue, I was wondering how you dealt with this kind of problem, and whether we agreed on best practices.
Of course, I never immediately jump to the conclusion that the compiler is doing something wrong. For me, once I have a good enough understanding of where an error I don't understand occurs, the first step is to try to write a simple, self contained, correct example that reproduces the problem. This usually helps me understand the precise nature of the issue I'm facing. If, at this point, I have a short piece of code that causes problems I don't understand, I go this very mailing list with it. There'll be somebody here who understands Vala better than me and able to clarify. If I do understand what's going wrong, I have to convince myself that it's actually a bug in Vala before reporting it. Broadly speaking, this could fall in one of four categories: * Explicitly documented behaviour being broken / missing (I don't think I've ever seen this myself) * Incorrect VAPI bindings * Valac generating incorrect C code that doesn't compile and link * Reference counting issues in code that does not explicitly call Object.ref() or Object.unref() If it is a bug in Vala, after checking that it hasn't been reported before, I file a bug against the compiler, attaching my reproducible code sample. If I have different Vala versions available, I will test it with multiple versions on the off-chance that it's a regression from a previous version - this information could help the maintainers. Those were the obvious steps - Everybody should be following them anyway. Now, the interesting part - how to deal with a broken compiler in your project. I do this: I add a workaround to my code (there's always a way), and add comments to the workaround code explaining that it is necessary due to a bug in Vala, the nature of the bug, and a link to the bug report at bugzilla.gnome.org. This way, it's possible to periodically check if code that shouldn't exist in the first place is still necessary, or if Vala has been fixed and the workaround can be removed. What do you do? Do you take the effort to explain workaround in your code? Or do you go straight to fixing Vala yourself? (good job, man!) How broad a range of Valac versions do you try to support? I think I'm currently "on top of things" enough to know when the most recent relevant bug-fix in Valac was, so that's the number I specify as minimum. At this point, I must say: the situation has vastly improved since I got started with Vala in spring last year. Good job, my friends! The number of ugly workaround constructions in my code that I'd like to kick out is not zero, but it's a lot lower than it was a year ago. Regards Thomas PS: I'm not sure what to make of the fact that several bugs I've reported are still "UNCONFIRMED", with no comments, despite including a simple, reproducible test case. They're mostly obscure, so I'm not expecting a quick fix, but a "confirmed" or "cannot reproduce" would still be reassuring. But no worries, guys, I'm not letting lack of feedback stop me. _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list