OK maybe the title is a bit of a reach, but she is pretty and my topic is dull.
It is the school holidays and between entertaining the kids I have been experimenting with the vala (see there is the link to the title) language. Overall I really like it, building a usable graphical GTK application is a snap and that side of it works well.
Unfortunately, and here comes a a whole pile of fail, the documentation is lacking, not just poor but mostly non-existent. You rapidly discover yourself using the Glib and GTK library documentation to try and infer how things work.
Underneath, the vala compiler is clever, it is really a c code generator. It takes your vala source file converts it to c and compiles it. When it works smoothly it works very well, when something is not quite right you can end up with a large pile of pieces complete with the C compiler spitting out cryptic nonsense.
This is all exasperated to new heights of madness when you want to access a simple c library. I say simple because if you want to access a Glib based library its easy and "there is an app for that". Because vala is object oriented c interfaces must be described as an object. This description is performed using vapi files. The file format is documented by the simple approach of "we already wrapped a load of libs go look at their vapi files"
For my small starter project I wanted to access a tiny c library I had written. The entire interface described in a single header header (excluding copyright) is:
typedef enum motor_dir
motor_off = 0,
motor_forward = 1,
motor_back = 2,
motor_brake = 3,
motor_dir;
int edgerbtarm_init(void);
int edgerbtarm_close(void);
void edgerbtarm_ctrl_motor(int motorn, motor_dir direction);
Yes that is it! one enum, an initialise a finalise and a single operation function. The vapi file I came up with after a great deal of trial, error and head scratching was.
[CCode(cheader_filename = "libedgerbtarm.h",
lower_case_cprefix = "edgerbtarm_",
cprefix = "")]
namespace edgerbtarm
[CCode(cprefix = "motor_")]
public enum motor_dir
off,
forward,
back,
brake
public int init();
public int close();
public void ctrl_motor(int motorn, motor_dir direction);
This seemed to work until I tried to use the motor_dir type within my vala code at which point the c compiler started throwing errors about undeclared macros
arm.vala.c:297: error: EDGERBTARM_TYPE_MOTOR_DIR undeclared (first use in this function)
I struggled for some time and finally ended up asking my friend
Enrico for help. He initially suggested I simply use an int instead of the motor_dir type and cast when I needed to. This approch worked and let me compile the program, it did however seem a bit grubby and removed the type safety of the enum.
Then Enrico came up with the "correct" solution. the enum description in the in the vapi file needed an extra parameter so vala would know the enum did not have a Glib type...yeah it was obvious to me too :-/
so by altering the vapi file enum declaration to
[CCode(cprefix = "motor_", has_type_id = false)]
public enum motor_dir
off,
forward,
back,
brake
Everything works as you might expect and the motor_dir enum can be used as a type within the vala program with no more fuss.
So the outcome of all this is that while vala is an interesting language which I may well use again in future, one should be aware that it is still very immature as a solution and has nowhere near enough documentation especially round the awkward stuff where it needs it most.
I'm pleased to announce that the new Garbee and Garbee
web store offering products designed by the
Altus Metrum community is now open for business!
Rocketry folks, please note that I refuse to sell anything that isn't in
stock, so if you want TeleMetrum
boards you'll have to wait a few more days. Keith and I just weren't happy
with the GPS receiver performance using the patch antennas we selected for
version 1.0, and I'm changing to a slightly better (and more expensive)
antenna that we expect will make everyone happier. Parts are due by Friday,
and so with any luck you should be able to buy TeleMetrum boards and starter
kits early next week.
In the meantime, we have TeleDongle
boards and other accessories in stock now and ready to ship. Last week,
Steve Conklin became our first customer by showing so much enthusiasm for
TeleDongle over snacks at a conference we all attended for work that we pointed
him to the web store under construction and he has already posted an
enthusiastic blog entry about his plans!
More as it happens!
When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it s ia32 on my MacBookPro; it was the very first time I could test the x64 build.
And the results weren t good: some images couldn t be loaded, and it all seemed to be random.
Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable.
Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It s annoying but it s also very helpful as I now had an error message to work with, and even if the error message wasn t reliable, it would still point me to some part of the code. The message was: Invalid argument.
On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn t match the calling convention of the ELF executables we re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it d be an obvious candidate for anyone looking at this issue.
Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That s the type the call wrapper uses when extracting the arguments from its va_list.
Introduce some more macros on top of the call wrapper, build, test: voila, it s fixed! That was tricky one.
Let s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64.
rEFIt 0.14-1, available in unstable in a couple hours.
Next, I ll see if I can reenable optimization in both GNU EFI and rEFIt.
I've now 
A few months ago, I wrote about 
A few People on IRC have ask me to elaborate on my email reading setup. ( As far as hosting I use Google Apps for your domain, but I wont be getting into the details of that. )
That was a pretty good weekend. I set up someone s new Samsung N150 netbook with 
Hello, 
This past week has had a couple of minor software releases:
I just published the following in debian-i18n. If you read this on
Planet Debian, please followup on debian-i18n.
The situation for D-I translations is currently the following. It is
not that brilliant, I have to say. And I limit details to "level 1".
In very short:
33 languages are in good shape.
*26 languages are in danger of being deactivated*
More details
The safe side
16 languages are complete:
PS 3 shameless plug! The
mythical 
Via 
Monday saw us at the 34 week mark. Yesterday was the point in Sarah's first
pregnancy that we lost Joshua. So we're in scary uncharted territory now.
Sarah's OB has said that he doesn't want her to go past 39 weeks, given prior
history, and he won't induce because of her heart (and they don't induce for
a VBAC anyway), so if we want a