Preventing mercurial from eating itself

Mercurial doesn’t seem to handle being interrupted particularly well. That, coupled with my tendency to hit ^C when I do something stupid leads to Mercurial ending up in an inconsistent state about once a week, causing me to manually restore my patch queue state with judicious use of `strip` (or otherwise).

I’ve just about had enough of this. A simple hack (that hopefully others will find useful) is to alias `hg` to a script containing:

hg “$@”&
wait

exit $!

Sort of evil hack, but does the job (provided you don’t kill the terminal you’re typing in: but I’m yet to meet someone who is suffering from reflexively executing `exit`. Now you can ^C Mercurial all you want and it will blithely ignore you. This seems preferable to it half-doing something, throwing a tantrum, and eating itself…

Advertisements
Standard

A novel (well, not really) way of optimising nine-patches

While tinkering with shrinking Fennec’s apk size, I came across a potential optimisation for nine-patches that’s oddly missing from Android’s resource preprocessing steps.

 

There’s a pretty decent explanation of what nine-patches are over here.

 

When a nine-patch contains multiple scalable regions along an axis, the system guarantees to maintain their relative size (though no promises are made about aspect ratio of the entire image).

In the simpler (and more common) case where only a single scalable region exists along an axis, if all the columns (or rows) are identical, they may safely be collapsed to a single column (or row). The renderer will happily later upscale this single-pixel region as much as necessary with identical results.

Apparently this isn’t something that’s done automagically during the packaging step, so I’ve written a neat (and slightly badly-structured) utility for performing this optimisation, available here:

https://bitbucket.org/ckitching/shrinkninepatch

It takes a list of .9.png files as input and overwrites them with optimised versions (if the optimisation is found to be safe. It does not currently perform any optimisation where multiple scalable regions exist, even though it should be safe to do so under some circumstances (if the regions each consist of homogenous rows/columns and you reduce their size in a way that preserve their relative size)).

Note that this program doesn’t preserve PNG indexes, so if you feed it an indexed png you’ll get an unindexed ARGB image as the result (causing the file to grow in size). Simply repeat your png quantisation step to obtain your optimised image.

Standard