Entries Tagged 'General' ↓

After coming back from the wild goose chase figuring out leaks reported in gdk_window_invalidate_maybe_recurse(), _gdk_windowing_window_queue_antiexpose() and g_closure_invoke() (due to some interesting test setup) I sat down and optimized the sapwood theme engine data structures a bit saving maybe 30k per process.

Our gtkrc files are huge, 6000+ lines and 500+ file references so only saving the absolute image filenames takes quite a bit of memory. For comparison the largest gtkrc I could find on my desktop was Grand Canyon which is 817 lines and has 80 file references.

The optimization was rather simple and straightforward, splitting the path to directory and basename components; the directory is always the same until you switch themes so it can be efficiently shared. Turning struct members into bitfields saved some more memory and didn’t even need changes to the code.

Note to self: when committing patches to GtkTreeView make sure the design has been approved by the board, the developer has four years experience in hacking GtkTreeView, at least two of which with our modifications, the patch has been reviewed by at least three people with twice the experience, and that unit, acceptance, system, stress and IQ tests still pass. Then test it again. Otherwise the chances are you just broke something.

Now at three duplicates and counting…

I am yet to decide which one is easier to break or is broken in more obscure and subtle ways, GtkMenu or GtkTreeView.

I’ve been playing aroung with Jabber and loudmouth a bit, and more specifically trying to implement JEP-0055, a simple JUD search. Now, for an unambiguously defined protocol there seems to be quite a bit of ambiguity. It didn’t take me long to notice that:

1. Servers don’t necessarily reply to your <iq/> requests (spec says they MUST – granted I didn’t bother checking the timeout period, if any, so who knows…)
2. JIDs might have trailing whitespace, so you can get different results for user@jabber.org and user@jabber.org . Just try to present that in a sane fashion for the user.
3. The contents of <nick/> and <email/> seem to have been swapped (but not always.)
4. The contents of <first/>, <last/>, <nick/> and <email/> sometimes contain trailing newlines (seems to be server dependent.)

Maybe the above explains why JEP-0055 is not standards-track but Historical.

At first I used to bake my pizzas completely from scratch, making the crust to fill the whole baking tray. Making the crust is pretty much the single most time consuming task, and rather boring, so I’ve since switched using pre-baked round crust you get from stores. Saves you a lot of time and the taste isn’t too bad (and the toppings are spicy enough to hide it anyway.)

Latest development was to realize I was making warm sandwiches that really weren’t that different from a pizza. A little bit thicker maybe, but that’s about it.

So I’m a sucker for pizzas, what else is new?

Once upon a time there was an obscure bug in theme switching. Sometimes when you changed the theme only the desktop (task navigator, statusbar and home) kept using the old theme – every other (running) application did change the theme properly. Now, the fun starts from realizing the same mechanism was used (update gtkrc file and send a “reread rc files” message to all applications) so it should’ve failed consistently or not at all.

First hints of the bug were seen many months ago, but no one could figure out how to reproduce it. It seemed to come and go at random. After fixing other bugs in theme switching people stopped seeing (or at least complaining about) this particular bug also so we thought it was killed in the process. Turns out it was just on a break.

Recently the bug came back. A manager was able to reproduce it consistently. And still developers were unable to reproduce it with other devices outside the manager’s office.

More time passes and finally the bug was reproduced on another device in a bathroom (don’t ask, I don’t know, I don’t think I want to know) – but once back at the desk where one is equipped to actually debug the issue, the bug can no longer be reproduced.

Eventually it was figured out the bug is triggered when booting up the device for the very first time. Why first boot wizards and whatnot would have any effect on themes made no sense whatsoever, but at least we were narrowing down the problem. While discussing the problem once more, we noted that one of the things first boot wizard does is set the date and time. Right that moment I could already see the problem. And right there it was, so clear in intention, so wrong in implementation. Once tracked down fixing the bug was trivial:

- (statbuf.st_mtime > rc_file->mtime))
+ (statbuf.st_mtime != rc_file->mtime))

It was fun, in a slightly twisted sense. Now I just need to figure out what the step 2) is…

1. Fix bugs
2. ???
3. Profit!

Holy Penguin Pee — is that served chilled, or body temperature?

My internet connection developed worse than usual case of existence failure and having your internet connection break down does wonders to your free time. So I had enough time to finish reading Starship Titanic and Dirk Gently’s Holistic Detective Agency. I found the characters in the latter bear striking resemblance to Arthur et. al. The main character is just an ordinary fellow who gets in the middle of extraordinary events and who has a rather eccentric friend.

Detecting and triangulating the vectors of interconnectedness of all things, one hundred and fifty pounds.

Struggling on in the face of draining scepticism from client, drinks – three hundred and twenty-seven pounds fifty.

To saving human race from total extinction – no charge.

However I think Starship Titanic was funnier. Little things make all the difference.

The problem with checking integer overflows is to remember to do that in the first place, the actual check itself is easy, right? Then it should be an easy task to explain what the following prints, or doesn’t print, and why.

#include <stdio.h>
#include <limits.h>

int main (void)
{
	int a = INT_MAX;
	int b = a + 42;

	if  (a < 0)                  printf ("a1\n");
	if             (a + 42 < 0)  printf ("a2\n");
	if ((a < 0) || (a + 42 < 0)) printf ("a3\n");
	if  (b < 0)                  printf ("b\n");

	return 0;
}

Finally finished catching up with packages and pending patches. Now the latest and greatest of maemo gtk+2.0, hildon-lgpl, hildon-fm and hildon-libs are in the subversion repository.

Unfortunately at the moment there’s a slight glitch regarding localisation. While the en_GB catalog is included in the sources it will not be included in the Debian packages. Message catalogs are packaged separately for easy configuration and they come from different source, installing the included catalog would conflict. Now, the binary packages are depending on the localisation packages which are not currently available in maemo. They will be in the release once it’s ready, but until then, if you’re brave enough to try out unreleased stuff, the packages won’t be installable without modifications.

Of course while trying to get something actually done I had to ignore practically all bugmail so now I’m drowning in it. There was an evolution plugin somewhere to help with that, I think…

We chose subversion for maemo code repository for a couple of reasons. One was that we’re already using it internally so we can continue using the same tools, but more importantly it’s sufficiently similar to all CVS users so there’s no huge learning curve for anyone interested in having their hands on bleeding edge code.

However, having used tla for Galeon development I’m already missing the simple way of doing merges. And bzr is on its way to make things even better. With subversion branching may be cheap, but repeated merges will conflict. To that end I thought to give svk a try. Well I didn’t even get as far as actually running it before getting the feeling it’s just not going to get far off compared to bzr.

Two reasons why I think bzr is much more likely to gain significant momentum outside its core development team:

First, bzr (or any other coming from arch heritage) doesn’t come even close to having the insane amount of dependencies svk does:

Sure, on up-to-date Debian unstable or other decent distribution the dependencies are not really an issue since someone else has already gone through the trouble and kindly made them easily available. But just try to install svk on redhat9 or similar. (And for those advocating CPAN: tests are failing or hanging; can’t install as non-root, even after following the instructions something still insists on installing stuff in /usr/bin…)

So much for taking svk for a quick spin.

Second, bzr is written in python, svk in line noiseperl.

I did, eventually, manage to get svk installed so maybe one day I’ll manage to try to do something practical with it.