October 25, 2007
General
6 Comments
I don’t really remember how we got there, but a couple of days ago at the office we ended up talking about the complexity of the codebase we have to deal with. Tommi mentioned the McCabe cyclomatic complexity, “which may be considered a broad measure of soundness and confidence for a program“. According to the Wikipedia article it “directly measures the number of linearly independent paths through a program’s source code“. And there’s this little table, with some pre-defined thresholds:
Cyclomatic
Complexity |
Risk
Evaluation |
| 1-10 |
a simple program, without much
risk |
| 11-20 |
more complex, moderate risk |
| 21-50 |
complex, high risk program |
| greater than 50 |
untestable program (very high
risk) |
Well, fair enough. You always have to be a little skeptic about this kind of data, but it might give you some insights about a codebase. So “apt-get install pmccabe”, a tool to “calculate McCabe cyclomatic complexity or non-commented line counts for C and C++ programs“. The man page says:
The obvious application of pmccabe is illustrated by the following which gives a list of the “top ten” most complex functions:
pmccabe *.c | sort -nr | head -10
Sounds like fun! Let’s run it on the gtk/ directory in gtk+… (drum rolls):
| Cyclomatic complexity |
Lines of code |
Function name |
| 119 |
337 |
gtk_notebook_calculate_tabs_allocation |
| 119 |
744 |
gtk_tree_view_bin_expose |
| 89 |
467 |
gtk_tree_view_column_cell_process_action |
| 88 |
545 |
update_node (in gtkuimanager.c) |
| 68 |
404 |
gtk_tree_view_button_press |
| 68 |
381 |
gtk_toolbar_size_allocate |
| 64 |
218 |
gtk_im_context_simple_filter_keypress |
| 64 |
230 |
gtk_tree_view_key_press |
| 59 |
243 |
gtk_menu_handle_scrolling |
| 58 |
175 |
gtk_clist_motion |
Some of the functions are way past the threshold for intractability (and all of them surpass it), and GtkTreeView has 4 of the 10 most complex functions in gtk according to McCabe. I suppose you can extract many lessons from here, but I’ll only give one humble suggestion: we need regression testing for gtk, and we need it yesterday, as it seems that no human being can hack on some parts of gtk without breaking something 
October 17, 2007
General
3 Comments
As others have alread commented, the new tablet is now out. But I’m a software guy, so I’ll talk about the software it runs and let others dissect the hardware.
As Michael says we had to break the API to unfuck cleanup the mess that was our stack until now. This sucks, but I think the benefits are worth it: we now use a slightly modified (but ABI compatible, unlike before) GTK+ 2.10.12, the most egregious crack is gone from Hildon, you have cairo, which is used to render almost all the text you see on the device (but use it with moderation please, it’s not a speed demon yet :)), the theming infrastructure is greatly improved, etc.
The differences in our GTK+ are documented for a change, and there’s an on-going effort to provide a coherent start page for the platform at live.gnome.org/Hildon. Now we need the validation of the community, so please port your apps and write new and excellent free software for Hildon.
October 8, 2007
General
3 Comments
I always like to read others people hacking tips, mostly because I suck a lot at using any tool correctly and I am almost always enlightened by them. Today I’ll try to contribute one small trick to the pool.
I remember the last time I posted something about gtk-look.el, someone asked me: “Why would you want to use that? You know about devhelp right?”. My answer at that point was “It’s faster and I like to get the help inside emacs if it’s possible”. Those are quite valid points on their own, but today I can add more benefits: meet Icicles.
The short description of Icicles is that it adds super-powers to any emacs mini-buffer interaction, among other things. But as always, an example is more instructive than a thousand words.
Say we are merrily hacking on our GTK+ application with GtkTreeView (a classical mistake), and we have, as always, forgotten how to set a treeview in multiple selection mode. No problem, let’s look it up. First, we press C-h C-j , bind in our box to ‘gtk-look’. After that we type ’selection’, as we’re pretty sure the function will contain that name.
Now we press S-TAB, which is Apropos-Complete in Icicles (ie, show me any string that contains my input).
Well, there’s quite a few huh? No problem, let’s narrow the search with M-*, aka Match-Also-Regexp. This will filter our result with everthing than does not match our input, akin to adding an extra grep to end of a pipe in a shell. So, as we are interested in GtkTreeView, we do M-* tree S-TAB:
That’s better! In fact I think I see what I want now, gtk_tree_selection_set_mode. So once more… M-* set_mode S-TAB… There’s only one hit now, so Icicles will select it automatically for us in the mini-buffer:
Enter, and we open it in our browser of choice (w3m for emacs here):
Yep, that was it.
Of course the beauty of this is that we did all that pretty fast and without moving our hands from the keyboard.
There are other cool things here, like the ability to save any completion to a cache to speed up things massively. Say, if you hack on GTK+ you are bound to cycle through its docs many times, so save only the gtk API reference search to a cache file and start your completions from there. See this for more details.
This of course barely scratches the surface, so if you use emacs I recommend you to spend some time in the Icicles wiki, install it and play with it. You won’t be disappointed.
