Peter Brett's Blog

GTK+ no longer supports Windows, apparently

2010-02-20T00:20:00.001Z

When writing computer programs, I try to ensure that they are portable enough to run on as many different platforms as possible without modifying the source code. This becomes tricky when I'm writing in C and I want to provide a vaguely-modern-feeling user interface. Since about 2006, I've relied on GTK+, the basis of the GNOME desktop environment, as my GUI library of choice. A good example of a piece of GTK+-based software for which I'm a member of the development team is the gEDA project, a collection of tools for electronics design.

One of the attractions of GTK+ for me has always been its ability to be used on both X Window System-based operating systems (e.g. Linux and BSD) and on Microsoft Windows. Unfortunately, it seems that Windows support has now been discontinued.

Back in September, GTK+ 2.18 was released. Unfortunately, it contained a large regression which has caused some headaches for people working with GTK+ on the Windows platform (essentially, GTK+ applications would be completely unusable in some cases). Furthermore, a rewrite of some core GTK+ code inbetween 2.16 and 2.18 left the GTK+ on Windows infested with a host of other minor but annoying bugs.

Now, what normally happens when an Open Source program upon which literally thousands of applications and millions of users depend has a major stable release containing a large regression on one of the major supported platforms? Well, in most such cases, the software's developers figure out a workaround as quickly as possible and make sure that those affected know about it, and then make haste to track down the source of the bug, fix it, test the fix, and issue a point release or set of patches with which their users can obtain a working version.

Apparently not so in the case of GTK+. Four months later, GTK+ 2.18.x is still pretty much unusable on Windows, and the general consensus is to use 2.16.x. Dominic Lachowicz, a GTK+ developer, has is still warning people not to use 2.18.x on Windows:

Look before you leap. GTK 2.18 on Windows is very buggy.

The attitude of the maintainer of the Windows port, Tor Lillqvist, has been quite alarming. In comments on the GNOME bugtracker, he gave no impression of any intention of resolving the issues himself, saying:

You want ot use some new API present only in 2.18? Please then consider helping in actually debugging and fixing the problems in GTK+ 2.18 on Windows.

... perhaps you should just use the version of software as it was before the "introduction" of the bug? I mean, nobody promised you there would be any updates of Windows-specific functionality, or otherwise, in GTK+, right? So just use GTK+ as it was before "somebody broke it".

It's becoming distressingly clear that there is no-one in the current GTK+ development team with any particular commitment to keeping the Windows support in working order. Furthermore, it seems clear to me that the hostile and confrontational attitude of people like Tor will tend to drive away any new developers interested in taking the work on. It's already hard enough to get patches into GTK+ as it is -- even complete and tested patches tend to hang around in the GNOME bugtracker for weeks or months before being dealt with.

Going forward, I think that I'll need to find an alternative set of libraries that I can use for cross-platform GUI programming and get a well-integrated 'look and feel' with. The Qt toolkit has a good reputation for documentation and support, but doesn't seem to support applications written in C. Are there any other alternatives I've missed?

Project Postcard

2010-02-01T08:49:00.005Z

I recently wrote a blog posting for the Pirate Party UK website about my latest publicity initiative: Project Postcard!

The election is fast approaching, and the time has come to really press on with raising our profile. All our members need to be doing their part if we're going to make an impact on the UK political landscape. I personally have been aiming to do something meaningful & constructive for the party every day -- and I recommend to you all to make a similar commitment. Even little things can make a real difference.

One way you might be able to help is to get involved with my 'Project Postcard' initiative. I'm shortly going to be ordering a few thousand professionally-produced postcard-like flyers, printed with information on who we are and what we stand for, as well as details of how to find out more.

Read the full article on the PPUK blog.

From the ridiculous to the... even more ridiculous?

2009-11-10T07:41:00.003Z

I've been following the progress of In Re Bilski before the US Supreme Court, because it's got the potential to set the rules for business method (and thus software) patents for the next few years.

Unfortunately, it seems that lawyers' view of what constitutes a "good" patent has hit a new and hilarious low. Take this extract from the oral arguments (thanks to Groklaw for pointing it out):

JUSTICE KENNEDY: But it would be different, it seems to me, than what you are -- let's assume you can't patent an alphabet. I assume that is true. And you can take an alphabet to make beautiful words, and -- and so forth. You -- you want to say that these -- these electronic signals can be used in a way just like the alphabet can be used. And many of the scientific briefs say that their process is different, that they are taking electronic signals and turning them into some other sort of signal. But that's not what you are doing.

MR. JAKES: That may be, but those signals could also be transmitted. On -- on your question about the alphabet you said look at the Morse claim 5, which was an alphabet to Morse Code. That's exactly what it was.

CHIEF JUSTICE ROBERTS: So you reject -- you reject the substitute. You think you can patent an alphabet because it is a process of forming words.

MR. JAKES: It could be, yes.

In what world does this seem like a sane and reasonable way for patentability rules to evolve?

ACTA: write to them!

2009-11-05T12:23:00.002Z

I've now written to both the Green MEP in my region, Caroline Lucas, and my MP, Humfrey Malins.

My e-mail to Caroline Lucas was fairly straightforward to write. Firstly, she's an MEP, and thus European-level matters are more directly relevant to her interests. Additionally, the Commission have been ignoring direct calls, by MEPs, lead by the Green Party, for more transparency in ACTA, so I know that she already agrees that there's a problem.

Dear Dr. Lucas,

In December 2008, lead by the Green Party, the European Parliament adopted a resolution regarding ACTA which:

"... Calls on the Commission and the Member States to negotiate ACTA under conditions of the utmost transparency towards EU citizens, especially with regard to the definitions of the terms "counterfeiting" and "piracy" and the criminal sanction measures foreseen; takes the view that the social impact of the agreement as well as the impact on civil liberties must be assessed; supports the establishment of a task force to examine the implementation of the agreement, by promoting this subject in dialogue between the European Union and third countries and as part of cooperation measures with those countries..." [P6_TA(2008)0634]

Furthermore, in March 2009, the Parliament and Council adopted a Regulation that required that:

"In accordance with Article 255(1) of the EC Treaty, the Commission should immediately make all documents related to the ongoing international negotiations on the Anti-Counterfeiting Trade Agreement (ACTA) publicly available. [Am 109]" [P6_TA-PROV(2009)0114]

Nevertheless, many months later, the ACTA text under discussion is still being discussed behind closed doors, without the opportunity for review or discussion by those whom it will affect if adopted. I would greatly appreciate an explanation as to why this is, and what the Parliament, the Green Party and you yourself are currently doing to address this.

Yours sincerely,
Peter Brett

Writing to Humfrey Malins was more challenging. Firstly, European Commission-level negotiations aren't something that the Commons has any real direct influence on. However, the fact that the Baroness of Uphallow is the European Commissioner for Trade provided a way to demonstrate the ACTA negotiations' direct relevance.

Dear Humfrey Malins,

The UK, as part of the European Commission, is currently in the process of negotiating the plurilateral Anti-Counterfeiting Trade Agreement.

This process has been concealed behind a veil of utmost secrecy, despite repeated demands by the European Parliament and Council for greater transparency (see: P6_TA(2008)0634 and P6_TA-PROV(2009)0114). Only a rough outline of the structure of the proposed treaty is available to the billions of people who will be affected by its provisions. I do not believe that, in the case of a trade treaty, such secrecy serves the public interest. The quality and fairness of the results of the process can only be improved by allowing the people in whose name the treaty is being negotiated to see and discuss the actual provisions being suggested.

I have already written to my MEPs, but the Commission has made it quite clear that they intend to continue to ignore the European Parliament's position on this issue. Catherine Ashton is the UK Commissioner and holder of the Commission's Trade portfolio, and as such is responsible for the Commission's role in the ACTA negotiations. (It is interesting to note that the Baroness of Upholland has no background in trade issues and has never been elected to public office.)

Would you be willing to ask the Prime Minister to direct Baroness Ashton to encourage the EU ACTA delegation to open the process to public scrutiny, please? It seems to me this would greatly serve the public interest.

Yours sincerely,

Peter Brett

Hopefully I'll get some useful and timely replies. We'll see!

ACTA: what lurks in the shadows?

2009-11-05T07:06:00.004Z

Over the last two years, a number of countries and multi-national blocs have been negotiating a new treaty called the Anti-Counterfeiting Trade Agreement (ACTA). The UK Intellectual Property Office, for example, claim that:

The Anti-Counterfeiting Trade Agreement (ACTA) seeks to coordinate international cooperation on IPR enforcement practices, to tackle effectively counterfeit and pirated goods.

Whether or not you feel that the premises on which the proposed treaty is founded are benign (the Pirate Party UK, of which I am a member, opposes it in principle), the most disturbing thing about this treaty is the veil of total secrecy behind which all of the negotiations and details of the proposed treaty provisions have been concealed. (Recall that, in most countries, international treaties which have been ratified by the government have the force of law).

Indeed, the public was not even aware of what, exactly, the proposed agreement would cover until a discussion paper was leaked in May 2008.

On the EU side, the negotiations are being carried out by the European Commission, which has routinely denied or stalled all attempts to give transparency to the process. They have even ignored repeated demands from the European Parliament for drafts and documentation of the process. In December 2008, for example, the European Parliament adopted a resolution which:

Calls on the Commission and the Member States to negotiate ACTA under conditions of the utmost transparency towards EU citizens, especially with regard to the definitions of the terms "counterfeiting" and "piracy" and the criminal sanction measures foreseen; takes the view that the social impact of the agreement as well as the impact on civil liberties must be assessed; supports the establishment of a task force to examine the implementation of the agreement, by promoting this subject in dialogue between the European Union and third countries and as part of cooperation measures with those countries.

The Commission failed to comply. Several months later, in March 2009, the European Parliament and Council adopted new regulations on transparency in government, and as part of this they specifically singled out the ACTA negotiations as an area in which transparency was sorely needed.

In accordance with Article 255(1) of the EC Treaty, the Commission should immediately make all documents related to the ongoing international negotiations on the Anti-Counterfeiting Trade Agreement (ACTA) publicly available.

Nevertheless, these documents are still not available. Although there are judicial procedures by which the Parliament can compel the Commission to act, these take a long time, long enough that the details of ACTA might not be made available until the negotiations are concluded and the treaty's provisions presented as a fait accompli.

It's therefore been recommended that citizens of EU countries pressure our individual governments to make the process more transparent. For example, I have recently filed a request under the Freedom of Information Act for details of the UK's part in the ACTA negotiations and, specifically, for draft documents, and I'll be writing to my MP later today to ask him whether he feels that such secrecy in negotiations of a trade treaty is really in the public interest.

Watch this space.

Update: I've made additional FOI requests of the Department for Business, Innovation and Skills, and the Foreign and Commonwealth Office.

Update 2: BIS say that I should contact UKIPO. How fortunate that I already have done so!

Perception of reality

2009-08-20T00:38:00.003+01:00

In late 2005, shortly after arriving at Girton College to begin my undergraduate course in Engineering, I met a young lady who would change my life forever. She was tall; she was slender; she was a stunning brunette; she was intelligent; she was witty. She was the most wonderful woman I had ever met.

She was also quite shy, which meant it took a long time -- months -- for me to win her trust. We chatted online most days of the Christmas vacation, and in the Lent term we drank late night cocoa together while commiserating about the length and difficulty of our examples papers. Just after Easter in our first year at Cambridge, we began going out. It was the 17th April 2006, and it was the happiest day of my life.

We had a wonderful time together. I remember one evening in June 2006, after finishing our exams, we packed a dinner of boiled eggs, rocket, cheshire cheese and crusty brown bread, cycled into the fens to the north of Cambridge and enjoyed a relaxing picnic on the verge outside the Queensholme Bloodstock Stables near Willingham. I remember her laughing as she snapped a photograph of a big green caterpillar crawling around in the grass near her lap.

I remember my 21st birthday, at her house in the Alps, with a delicious carrot cake and beautiful, hot continental weather to travel up a funicular railway and enjoy a meal overlooking the mountain lakes.

I remember a second year in Cambridge, living next door to each other on a corridor of our friends at Girton's Wolfson Court. I remember fondue evenings followed by games of Mario Kart 64 in my room, with people sitting on the bed and huddled on the floor to gather round and watch. She always won, no matter how hard we tried! I remember visiting her home again -- this time at the New Year -- and travelling far into the highest mountains to find a resort with ski-able snow. I remember carrying her new kayak to the river on her 20th birthday in the pouring rain, and watching the fireworks with her at the First and Third Trinity May Ball.

I asked her to marry me, and she said, "Yes." We went to a jeweller together, and together we decided to have a beautiful ring made to order: a sapphire flanked by two smaller diamonds. It was the second happiest day of my life.

At College again in our third year, we lived next door to each other again. I remember my happiness and her joy as I watched her win all of her kayaking varsity events, and I remember her endless months of struggling with mountains of horrendous maths problems. I remember punting on the Cam, our finals behind us, and not a care in the world. I remember her graduation, and looked forward to her being there at mine.

But then things changed. In September 2008 she went to York, to do a PGCE in secondary mathematics, while I remained in Cambridge, plugging away at the final year of my MEng. And suddenly it was not "we" who told the story any more, it was "she" and "I." I dutifully dragged her bicycle and her clothes and her books up to York on the train, longing to spend as much time as I could with the one I love. She seemed unwilling to make the time to come down from York to visit me, and when she came seemed to wish she hadn't. When I was there, it was as if she resented my presence, as if I was intruding into her privacy. Something had changed, and I was bewildered and confused.

She spoke to me less and less on the telephone, and never seemed to want to chat with me online. I was distraught. "What is going wrong?" I wondered. "Was it something I have done? Was it something I didn't do?" Yet I loved her still, with all my heart, and arranged a surprise visit to her in York. It was a cold night in March, but she was icy. It seemed like the relationship I cherished as much as life itself was hanging by a tenterhook.

The final examinations of my MEng began on the 17th April 2009, and it was on the 19th April I received the letter that I had expected but which I hoped would never come. Just over three years after our relationship had begun, it was over. It was the worst day of my life.

That was four months ago, and now she is with a new man, or at least, that is what her Facebook status says. Four devastating months, in which my life has crumbled to pieces around my ears as if struck by a tsunami; not only my future, but my past as well.

I looked forward to marrying her, starting a household together and eventually starting a family together, and now that will never happen. All my hopes, all my dreams are the wreckage of jagged splinters left after the box of Christmas baubles is hurled down the stairs. My heart is a broken mess of mingled sorrow, love, jealousy and anger.

But worse, I find myself doubting whether the way I saw things was in fact the way they really were. Towards the end of the relationship, I was fooling myself when I told myself that she loved me and that this was just a hiccough that could be put right by showing her that I loved her. But for how long? How long did she hide the way she felt about me? Did she do it out of some misplaced wish to avoid "hurting my feelings," or because she was afraid of how I might react? What did I do, or not do, or what about me was it that drove her away from me? Is the truth of the matter that I was too devoted, too trusting?

I fear -- I so dreadfully fear -- that even when our friends were sending us cards to congratulate us on our engagement, even then she was doubting whether I was the man for her, and she didn't tell me. And that would mean that, for more than a year and half of my life, the reality I perceived did not exist. I was living in a dream world.

How I wish, how I so terribly desire for that dream world to be real. Because, at the same time as I continue to love her wholly, I know now that we will never -- can never -- be together again. She has changed my life forever; but I hadn't expected it to be like this.

My days are swifter than a weaver's shuttle, and are spent without hope.

--Job 7:6

US NEO detection programme not on schedule

2009-08-14T08:37:00.003+01:00

In space-related news:

According to a new interim report from the US National Research Council, NASA's current near-Earth object surveys will not meet the congressionally mandated goal of discovering 90 percent of all objects over 140 meters in diameter by 2020. Funding for near-Earth object activities at NASA has been constrained, with most costs being met by funds from other programs.

What a surprise! Underfunded science programmes have difficulty meeting targets! In addition to complaining about funding, the full report (which is free to download) has some interesting information on the current technology and facilities used for detecting near-Earth objects.

Another of the report's findings was that:

The Arecibo Observatory telescope continues to play a unique role in characterization of NEOs, providing unmatched precision and accuracy in orbit determination and insight into size, shape, surface structure, multiplicity, and other physical properties for objects within its declination coverage and detection range.

I find this particularly interesting in the light of concerted efforts in recent years to shut the Arecibo facility down "to save money."

Congress should make up their minds: they can mandate and fund public research, or do neither.

Response to illicit filesharing legislation consultation

2009-08-13T19:03:00.001+01:00

In the wake of the recently-release Digital Britain report, the Department for Business, Innovation and Skills recently opened a consultation on proposed legislation to combat illicit peer-to-peer filesharing. I have published my rather lengthy response on my website.

I hereby disclaim all responsibility for permanent brain damage caused by extreme boredom induced by reading the document linked above.

gEDA build system redesign

2009-08-09T00:05:00.001+01:00

One of the items on the gEDA "Todos" list as a prerequisite for the 1.6.0 release has been a refactor of the gEDA build system. Instead of using several distributed source archives (one for each major component), it was decided to distribute the gaf suite as a single archive, with one unified build system.

Why?

The advantages of this strategy were seen as follows:

The system would be less confusing for new testers or "power" users who want to try out the latest changes in git.
The whole suite could be built and tested before installing any files. In the past, it's been necessary to install the libgeda and symbols packages before any of the other packages could be built.
It would reduce the labour involved in keeping the version numbers, ChangeLogs, and required dependency checks up-to-date. Maintaining multiple configure scripts in parallel is labour intensive, and there is the ever-present risk of missing one.
It would simplify the job of distribution packagers. In the RPM case, it would only be necessary for a packager (like the maintainer of the Fedora Electronic Lab distribution, Chitlesh Goorah) to maintain a single SPEC file, rather than nine.
It would simplify building using parallel make (see the -j option to make), which can significantly speed up compiling gEDA on machines with multiple or multi-core processors.
It would improve detection of targets requiring rebuilding. This is particularly important for working on libgeda; only changes which affect the public interface require a rebuild of the applications, but it's often hard to keep track of what's changed. What often happens with the 1.4.x build system is that people end recompiling the applications completely just to make sure, at a cost of time and energy.

Approach

The rework had been on the "Todos" list for several months when I started looking into it at the beginning of June 2009 (just after handing in my MEng project), and some ideas came to mind about how the current structure of the build system could be improved.

One idea that crossed my mind extremely briefly was not to use GNU Autoconf and Automake, but to adopt another build infrastructure. Autotools was retained, because not only is it well known by current gEDA developers, but it has worked well enough for us in the past, and it doesn't require developers or users to install yet another tool in order to be able to compile and install gEDA.
I had recently been looking at the configure.ac file for DTN2 (the reference implementation for the Delay Tolerant Networking Bundling Protocol), and I noticed that they used a very minimalist, clearly-laid-out configure script will almost all of the configure checks being described in separate m4 files, as self-contained Autoconf macros. This appealed to me, because configure.ac files are often very confusing to a newcomer, and this method offered the potential to make it much, much clearer.

Problems encountered

There were two major problems encountered while carrying out the work.

Firstly, internationalisation of desktop integration files (.desktop files to appear in menus etc., and MIME-type info files to make file browsers show the right icon. In previous releases, intltool has been used to do this, but intltool suffers from a major flaw: it doesn't support more than one gettext domain in a single package, and we would need to use at least three (one each for libgeda, gschem and gattrib).

I was very surprised to find that there wasn't an existing solution to this problem in widespread use. In the end, I had to actually write my own tool from scratch to carry out this task, a 550-line shell script called desktop-i18n. Although enormously hacky, it works remarkably effectively!

The second major problem was in getting the testsuite to pass without gEDA being installed. The number of issues encountered was innumerable (one of my "favourite" examples was the way that libgeda used to call exit(-1) if it couldn't find the gEDA font, even in gnetlist which doesn't need to display any text objects anyway). By a combination of actually fixing bugs (few) and horrible nasty hacks (many), I eventually surmounted this issue too. With this, there were more than a few occasions where I felt like I was banging my head against a brick wall.

Results

On Friday 7th August I merged the "build-system" branch into the main git repository, and the new build system seems to be a genuine and successful enhancement (despite a few minor issues). However, I can hardly believe how much work it took to do!

Double-chocolate brownies

2009-07-26T20:16:00.002+01:00

While CURA were at Bisley for the Imperial Meeting this year, I made the team some of these brownies. They were very much enjoyed by all!

This recipe is designed to make quite firm brownies that travel easily (e.g. on the back of my bike). If you like your brownies nice and squidgy, put less flour in (175 g instead of 225 g).

275 g plain chocolate (50% cocoa solids)
220 g unsalted butter
85 g walnut pieces
170 g milk chocolate (cut into chunks)
225 g plain flour
1 tsp baking powder
4 large eggs, lightly beaten
1 tsp vanilla essence
325 g caster sugar

Pre-heat oven to 170�C (155�C if you've got a fan oven). Line a 30x20x3.5 cm cake tin with lightly buttered greaseproof paper. I find that it makes the brownie easier to extract from the tin if you butter the base of the tin as well.

Melt the chocolate and butter in a large (preferably metal) mixing bowl over a pan of simmering water. Remove the pan from the heat and stir in the sugar, followed by the eggs and vanilla essence.

Sieve the flour and baking powder into the mixture, and fold in. Fold in the nuts and chocolate.

Pour the mixture into the cake tin, place in the oven and cook for 20-25 mins. The corners will cook fastest; do not allow them to burn! When cooked, a skewer inserted into the centre of the brownie should come out mostly clean, but it's no big deal if you get a squidgy middle.

Allow to cool in the tin. When cool, remove the brownie from the tin and cut into squares (you should be able to get 24 good-sized pieces from this recipe).

Update: Avoid oil-based chocolate and/or HFCS-based chocolate for this recipe. It won't work.

Simple unit tests in Scheme

2009-07-26T00:58:00.001+01:00

One nice feature of the Scheme programming is the ridiculous, over-the-top power of its "hygienic" macro system, which allows a programmer to effectively redefine the language to suit the task at hand.

A few days ago, I needed to write some simple unit tests for some Scheme code I was in the process of developing. The Guile Scheme implementation doesn't come with a library for unit testing by default, so it was necessary to create one of my own. This is it:

(define *failed-tests* '())
(define *passed-tests* '())

(define (assert-true result)
  (if (not result)
      (throw 'test-failed-exception
             (with-output-to-string
              (lambda ()
                (display "  assert-true: ")
                (display "got: ")
                (write result))))))

(define (%begin-test name test-thunk)
  (let ((test-success #t)
        (test-fail-msg #f))
    (display name) (display "... ")

    (catch #t test-thunk
           (lambda (key . args)
             (set! test-success #f)
             (set! test-fail-msg
             (if (eqv? key 'test-failed-exception)
                 (car args)
                 (with-output-to-string
                  (lambda ()
                    (display "  unexpected exception: ")
                    (write (cons key args))))))))

    (if test-success
        (begin
          (display "passed")
          (set! *passed-tests* (cons name *passed-tests*)))
        (begin
          (display "failed")
          (if test-fail-msg
              (begin
                (newline)
                (display test-fail-msg)))
          (set! *failed-tests* (cons name *failed-tests*))))
    (newline)))

(define-syntax begin-test
    (syntax-rules ()
      ((_ name . test-forms)
       (%begin-test name (lambda () . test-forms)))))

(define (report-tests)
  (display "Test summary")(newline)
  (display "Passed: ") (display (length *passed-tests*)) (newline)
  (display "Failed: ") (display (length *failed-tests*)) (newline))

Note that this effectively adds a keyword (begin-test) to the Scheme language, and this very simple macro has a massive effect on the readability of the resulting testcase code. For example, a trivial unit test using this minimalistic framework might look like:

(begin-test 'SuccessfulTest
  (assert-true #t)
  (assert-true (equal? 1 1)))
(begin-test 'FailTest
  (assert-true (equal? #t "string")))
(report-tests)

The framework is completed with the addition a few more assert- functions (left as an exercise to the reader). This code will form part of a future release of gEDA.

(In case you want to use this code in your own project, it is licensed under the GNU LGPL v3 or later). But there are probably better unit test systems for Scheme out there!

Enchiladas

2009-07-18T12:24:00.002+01:00

While I'm on a roll with the recipes, here's my recipe for chicken enchiladas. It's probably not particularly authentic, but I enjoy them! This recipe serves 2 moderately hungry people.

Enchilada sauce

400 g can of chopped tomatoes
1 clove garlic, chopped
Fresh chilis, chopped
1 tbsp olive oil

I usually use 2-3 of the normal chilis sold in Tesco or Sainsbury's (with the seeds left in), but I like my echiladas nice and spicy! With those chilis, I find them a bit impotent with the seeds left out.

Fry the chilis and garlic in the olive oil for 2-3 minutes over a medium heat. Add the chopped tomatoes and simmer for 20-30 minutes until most of the excess liquid has evaporated leaving a thick, spicy tomato sauce.

This can easily be made in advance, and freezes well.

Fried chicken filling

This is a very simple filling -- use your imagination and come up with your own! Try other meats, fried peppers or mushrooms, seafood, cheese... Also consider marinating the chicken with spices before frying.

300 g chicken breast, cut into strips
10 g fresh ginger, grated
Dried paprika
Salt & pepper
Half a medium cooking onion, coarsely chopped.
1 tbsp olive oil

Heat the oil over a high heat in a wide-based frying pan. Add the onion, chicken, ginger, and paprika, and season the chicken to taste. Fry until the chicken is cooked through, then set aside.

Like the sauce, this can easily be made in advance.

Putting it all together

4 corn tortilla wraps
150 g grated cheese (cheddar works okay)

Pre-heat the oven to 150�C. Microwave the tortilla wraps for 15-20 seconds until they are warm and flexible. Divide the filling between them, roll them up, and place them together in a small roasting tin. Spread the enchilada sauce generously over the tortillas (making sure to coat them all over). Top with the cheese and salt and pepper to taste.

Bake in the oven for 15-20 minutes, and serve with green salad and spring onions.

This will seem like bragging...

2009-07-17T17:09:00.002+01:00

This will seem like bragging, but in retrospect I really did rather well at Cambridge. These are the prizes and scholarships I was awarded over my four years:

Emily Davies Scholarship (twice)
Henry Tompkinson Scholarship
Beatrice Mills Prize
Rosalind, Lady Carlisle Prize
Raemakers Prize
Accenture Second Year Computing Prize
i2 Ltd. Third Year Computer-Based Project Prize

Of course, those successes paled into insignificance alongside the accomplishments of some of my peers at certain prestigious inner-city colleges, but I think I did okay for a hick from the sticks (i.e. a Girtonian)!

Edit: I forgot to mention that I also blagged a (large) award from the academic funds for a plane ticket to a conference at MIT. But that was more of a success in terms of "social engineering" than actual engineering!

Starting my PhD!

2009-07-01T21:20:00.002+01:00

As I mentioned in January, I was awarded a PhD studentship at Surrey Space Centre. I graduated from Cambridge last Friday, with I Class honours in my BA and a Distinction in my MEng, moved down to south-west Woking at the weekend, and started at SSC today!

I'm having to fight a bit to get a Linux workstation -- other groups in the same building (and serviced by the same IT staff!) use Fedora on their desktops, but SSC has historically been an all-Windows environment. In a corporate setting, I might put up with Windows -- there, at least, there is often a reasonably well-staffed IT services department to take care of the innumerable things that go wrong -- but in my experience, PhD students don't get quite that level of support. If I'm going to be solving my own problems, I want to do it with more powerful tools. (Also, Emacs on Windows isn't nearly as much fun. How can I possibly survive without a properly-functioning compilation-mode?)

Nevertheless, I think I'm eventually going to win the battle. In the meantime, it looks like I'll have to make do with Cygwin.

As far as the research is concerned, I've barely start to dip my big toe into the scalding bathtub of things I don't know, and it feels like I've got a long, long way to go before I get to the things no-one else knows either!

Update: I managed to persuade the computing folks to give me second PC running Linux and a USB KVM switch. So that's alright, then.

Chorizo and tomato pasta

2009-07-01T20:04:00.001+01:00

Another chorizo recipe that I made to use up what was left over from the previous one. Note that I use Spanish chorizo, not Mexican (as most commonly found in the USA).

Ingredients (serves 3-4):

150 g dried chorizo sausage, diced finely
1 medium cooking onion, coarsely chopped
1 clove garlic, chopped
100 g mushrooms, sliced
400 g can chopped tomatoes
Olive oil
Balsamic vinegar
Dried tarragon
2 small bay leaves
Black pepper

In a wide-based saucepan, heat a tablespoon of olive oil, and fry the onion and chorizo for 2-3 minutes (or until the onion is translucent). Add the mushrooms and garlic, and continue to fry until the mushrooms begin to darken and shrink. Add the tomatoes, and stir in the dried tarragon, bay leaves, black pepper, and about a tablespoon of balsamic vinegar. Cover and simmer gently for 20-30 minutes.

Serve with pasta and fresh green salad.

Baked pork chops with chorizo

2009-06-29T18:42:00.001+01:00

Here's a simple but delicious recipe I adapted from a dish served at Girton's cafeteria sometime in early 2009.

Ingredients (serves 2):

2 pork chops
60�g dried chorizo sausage, diced finely
1 medium cooking onion, coarsely chopped
1 clove garlic, chopped
Salt and pepper

Pre-heat the oven to 180�C (fanless oven 200�C). Sprinkle both sides of the chops with salt, and place in a small roasting tin. Pile garlic, onion and chorizo on and around the meat. Add pepper on top. Cover the roasting tin with tin foil and bake in the oven until the meat is cooked (usually between 45 mins and one hour).

Serve with boiled potatoes and fresh cabbage.

PhD studentship at SSC

2009-01-24T22:44:00.001Z

I've been accepted for a PhD studentship at Surrey Space Centre, working on applications of satellite-based Synthetic Aperture Radar (SAR). Even better, I've been awarded a Doctoral Training Grant by the EPSRC, so as long as I pass my MEng I'm going to be going exactly where I've wanted to go for the last couple of years, doing (more or less) exactly what I want to do!

gschem, log files and X selections

2009-01-24T22:39:00.001Z

Just over a week ago, I posted a series of [RFC] posts to the gEDA-user mailing list suggesting six reasonably non-trivial changes to libgeda and gschem. Although the discussions they started off weren't quite as productive as I was hoping, they did attract quite a bit of interest.

I haven't been afraid to put my money where my mouth is. Since then, I've implemented two of the changes I suggested: a modification of the way gEDA apps create logfiles, and support for copying and pasting bits of schematics between gschem windows. I thought I'd post here to explain the amount of careful design work that goes into even relatively minor changes to the gEDA suite.

Logging

Historically, gschem (and the other gEDA apps) have created logfiles in the current working directory when they were launched. This behaviour quickly resulted in a user's home directory becoming littered with the files, gschem.log files especially.

My initial suggestion was to just not create log files by default, and require users to specifically enable them. However, it was quickly pointed out that since one of the most common reasons for gschem failing to start was that a new user had made a mistake in their configuration file, and that it would be best to carry on with generating logfiles as the default behaviour.

Instead, it was suggested that the logfiles should be put in a centralised, out-of-the-way location, and ~/.gEDA/logs/ was suggested, with the caveat that it would be necessary to make sure that multiple copies of gschem accessing the directory would have to be supported safely, even on different machines, but also that a user could quickly easily find the most recent log file -- so just adding a random suffix with mktemp wouldn't work either!

Having worked out a way of doing this (a secure algorithm for generating sequentially numbered, dated log files), I then realised that on some operating systems, such as Microsoft Windows, $HOME might not even be defined, and that there might be platform-specific differences in the standardised place to keep configuration data. Since the gEDA applications had no existing way of handling these variations, I ended up abstracting out the methods for locating the system and user data and configuration files, and updating all of the gEDA apps to use them.

All in all, changing the location where log files are stored used up at least eight hours of development time.

Clipboard copy, cut and paste

For a long time, gschem has supported copying and pasting schematic data between pages and windows in the same gschem process, but it was never made clear to users that this mechanism didn't use the X clipboard, and thus sometimes copying and pasting didn't work when it would have made sense for it to.

X Window System selections are complicated. There are two selections normally used by X applications: the PRIMARY selection and the CLIPBOARD selection. Traditionally, the PRIMARY selection is contains the most recent piece of text selected by the user with the mouse, and can be pasted by clicking the middle mouse butten, while the CLIPBOARD selection is accessed via "copy" and "paste" actions explicitly invoked by the user. In order to match up with other applications (and because nothing like the PRIMARY selection is available on Microsoft Windows or OS X), we decided to use the CLIPBOARD.

For the same portability reasons (and also because the raw X API is horrendously complicated), we decided to use the GTK Clipboard API to manage the clipboard.

A neat feature of clipboards (and X selections in particular) is that it's possible for the source application to provide the data in different forms, depending on what the "pasting" application wants. We needed a format for transferring between gschem instances, so we decided to use the gEDA schematic format (application/x-geda-schematic). Fortunately, as part of my rewrite of the symbol library back in mid 2007, I'd made libgeda able to "load" and "save" schematics from memory buffers, so I simply hooked the clipboard code into that and things started working!

I then, of course, had to work through the boilerplate required to update the GUI to support it. This took as long as implementing the actual feature.

I've also been working on some other features, using some code that I've had floating around for a long time. But more of that another time!

More cooking escapades

2008-09-21T18:17:00.002+01:00

I tried out two recipes yesterday, with lots of success (well, I thought so, anyway).

First was nice and simple recipe for lemon drizzle cake from the BBC Good Food website -- I used it as a fallback plan when I failed to obtain a copy of my mother's legendary and delicious recipe.

I made it in a 20 cm spring-form tin instead of a loaf tin as the recipe suggests (I don't have a loaf tin at the moment). This meant it only took around 40 minutes rather than the 45 to 50 suggested, due to the cake being somewhat wider and flatter.

The cake was delicious, but a little dense; next time I will try adding an extra teaspoon of baking powder to try and lighten it slightly.

The second was a Thai-style dish called khao pad gai from a WikiBooks Cookbook recipe. Due to the limited contents of my food cupboard and my unwillingness to buy lots of unusual and seldom-to-be-used foodstuffs, my version of the ingredients (to feed two) looked more like:

Olive oil
225 g chicken breast, in strips
2 medium eggs
'Some' cooked, cold Basmati rice
1 medium cooking onion, half-ringed
2 small tomatoes, seeds removed and julienned
2 spring onions, thinly sliced
3/4 cup coriander, coarsely chopped
Dark soy sauce
'Normal' granulated sugar
Salt
2 cloves fried garlic

We didn't bother with the garnish, the nam pla or the Thai chili sauce, but nevertheless the taste came out okay (we were quite pleasantly surprised by how good it was after how awful it looked just after the egg was added). Note that although the recipe specifies a wok, we cooked it quite successfully in a large, flat-bottomed non-stick saucepan.

Emacs word counting and tab completion

2008-06-25T19:05:00.001+01:00

I've been doing a lot of work that's required me to keep an eye on word counts recently, so I've needed a decent word count function in Emacs. The easiest way to implement this was to use the wc command from CNU coreutils.

(defun word-count nil "Count words in buffer" (interactive)
  (let ((start (if mark-active (point) (point-min)))
        (end (if mark-active (mark) (point-max))))
    (shell-command-on-region start end "wc -w")))

If the the mark is active, it counts the number of words marked, otherwise counts the entire buffer. I have this bound to C-c C-w.

I also extended tab completion with dabbrev-expand to all file buffers, so I can use it in MATLAB, Bash, Python, etc. This was inspired by doing lots of MATLAB programming recently at my newly started summer job at Cambridge Silicon Radio.

(defun indent-or-complete ()
  "Complete if point is at end of a word, otherwise indent line."
  (interactive)
  (if (looking-at "\\>")
      (dabbrev-expand nil)
    (indent-for-tab-command)))
(add-hook 'find-file-hook
          (function (lambda ()
                      (local-set-key (kbd "<tab>") 'indent-or-complete))))

Christmas

2007-12-25T18:26:00.000Z

Having been horribly ill for what feels like most of December, Christmas is now here! I'm spending Christmas with my parents and all of my siblings, and it seems like I've been running around like a mad things for the last few days getting everything clean, tidy and ready for Christmas. On Christmas Eve my mother and I were at the butchers' shop at half past six in the morning to get the turkey and other bits we needed! This was most certainly a better option than waiting in the hour-long queue that had formed by the time I returned to the town centre later in the morning to do some other shopping.

Although being miserably ill put a big damper on my plans to do vast amounts of gEDA development during December, I've nevertheless managed to get some useful stuff done, further based on the libgeda error reporting issues discussed in my last couple of posts.

Firstly, I improved the way in which errors in Scheme files were reported. Messages reporting errors in gEDA rc files often reported the error as occurring in the wrong file, and claimed every error was a parenthesis mismatch (often when they were nothing of the sort). The error messages were also sent directly to the console rather than to the gEDA logging mechanism. Using deep dark Guile debugging magic, any errors encountered while reading in rc files now logs a backtrace, and tries to report the actual file and line on which the error occurred.

Secondly, and more importantly, I added internationalisation support to libgeda using gettext. As there are many international users of gEDA, and many important messages generated by libgeda, I feel that this is a very important development.

I'm hoping that we can use the web translation tools offered by Launchpad to make translating gEDA easier for users, and thus increase the quality and number of translations.

Peter Clifton and I have also been working hard on getting gEDA ready for a new release, squishing as many serious bugs as possible. Peter Clifton has particularly excelled himself, creating stunning icons for all the main file types used by gEDA.

In the next development cycle, I hope to substantially increase the flexibility of the component library. In particular, I hope to make it possible to have truly independent library setups, so that it is possible to have schematics from different projects with different libraries open in the same gschem session without any conflicts. I also hope to generalise the library infrastructure so that the same basic code can be used for the component library, hierarchy source library and any other library of reusable resources which might need to be added in the future.

As a first step along the route to the Ultimate Resource Library, however, the way that the Scheme extension API works needs to be rationalised, and once Christmas starts to wind down, I hope to deal with this. It will involve fluids.

Update: My blood test results have arrived, and it turns out that I have glandular fever. Absolutely fantastic.

Error-reporting progress

2007-12-07T23:06:00.001Z

Further to my previous blog post on error-reporting in libgeda, I've made some pretty good progress on implementing the ideas that I described. In particular:

The file opening functions (f_open() and f_open_flags) now use GError to return error messages rather than just spewing them to the console.
gschem now shows an informative dialog box when it fails to load a file.
All programs now actually tell you the real reason for failing to load a file (e.g. "Permission denied" or "File does not exist") rather than just giving a generic "Could not open file" message.
The libgeda logging mechanism now handles most levels of GLib log message rather than just the "message" level (seeing as the log is most useful when some sort of error has occurred, this seems sensible).
gschem now highlights warnings and errors in the log window.
Lots of ways in which libgeda could randomly kill your program have been eradicated.

These changes are not yet in the unstable branch, but barring someone objecting to my changes I'll push them upstream tomorrow sometime.

The next (probably thankless) task is to work through libgeda converting all calls to directly output debugging/error-reporting information to the console to use the GLib logging functions instead, and to make log messages be sent at appropriate levels rather than all at the "message" level (this will allow filtering of log messages in the gschem log window, for instance).

I'm still of two minds about the best way to do this. Currently, libgeda defines a macro s_log_message() which is equivalent to GLib's g_message(). For adding logging at multiple levels, the two options are:

Get rid of s_log_message entirely, and just use the GLib logging macros directly.
Define s_log_debug, s_log_warning etc so that the exact implementation could be easily modified at a later date (e.g. for the purpose of making libgeda always log in the "libgeda" log domain).

I'm currently leaning towards the latter, but haven't as yet made up my mind about exactly which will be the best way to go.

Error reporting & handling in libgeda

2007-11-27T23:22:00.001Z

Apparently some people do read my blog: Peter Clifton and I met up for a drink at Borders in town this evening, and he recommended that I write more often. So here's this evening's contribution, on a slight refactor of libgeda error reporting.

It's been a while since I last blogged about gEDA development, and since then I've had the good fortune to be able to travel to Cambridge, MA and meet several of the other developers based around there. In the last couple of days I've started ramping up my involvement in preparation for having some time for serious development over the Christmas vacation.

So, to begin: in general, libgeda kills the process without warning far too often. This is a bad thing for a library to do; in particular, it's very bad to do it just because someone passed some bad data in. The libgeda doesn't make any attempt to hide how the data structures are organised, and thus we have to assume that user code will make use of this knowledge to try and hack them directly.

My pondering of this problem over the last couple of days has lead me to think up four basic rules to consider when working out how to handle errors occuring in libgeda code:

If possible, succeed.
If failure is inevitable, fail gracefully.
If normal operation may result in failure, use GError.
Assume that libgeda works.

Of course, some of these need a little explanation as to their interpretation and why they make sense.

Firstly, "If possible, succeed." This seems obvious, but actually has some subtlety. What I mean here is that if there's a sensible, clean way of carrying on despite a problem, you should do so. This only really applies to user-facing code, as code which can't be called from outside libgeda really should have had its inputs checked by the calling function already. However, since all of libgeda's code is user-facing -- we don't have any private headers or the like -- this point is rather moot. In addition, "succeeding" doesn't preclude printing messages to the effect of, "Someone's playing silly buggers but I'm going to try my best anyway." g_critical() should be used for this. One example would be when an unknown object type is encountered; at the moment, libgeda often kills the program by calling g_assert_not_reached(), when often it would be valid to continue by logging a critical message and then skipping over the offending object.

Secondly, "If failure is inevitable, fail gracefully." Failing gracefully requires no dangerous side-effects from the failure. If possible, the system should be returned to its prior state. This often requires that user data needs to be checked before doing anything destructive, possibly at the expense of some CPU time.

GError is a nice mechanism in that it allows errors to be ignored if necessary. A good example of when it should be used would be in code which reads and writes files; because GLib's file access code already uses GError extensively, this would not be hard to implement.

Finally, "Assume that libgeda works." Similarly to rule #1, what is meant here is that libgeda functions should check their own behaviour. If they do so, there is no need for libgeda functions which call them to check again -- it's a waste of CPU time and developer effort.

So, given the above points, when is it appropriate to use g_assert()? It would not be appropriate to use it to check the arguments passed to a function, but it would be valid to use it to check that the function has successfully done what it is supposed to before returning a result. For instance, when a complex algorithm is in use, putting some assertions in to make sure that the algorithm actually does what you think it does might be a very good idea.

Of course, this has lead to a number of action items in terms of libgeda refactoring:

Cleaning up uses of g_assert() in libgeda, and replacing them with g_critical() logging and graceful failure where possible. I've already made a start on this.
Moving all of the file handling code to use GError. This will allow gschem to show a message dialog when a file operation fails, rather than forcing the user to look at the log window or at the console.
In the medium term, moving all of libgeda to use the GLib logging API (of which g_critical() is part) will allow the development of a shiny new gschem log window which allows logging at different levels with colour coding of criticality. This would be nice.
Ideally, the error messages used for GErrors emitted from libgeda should be translated. This means libgeda will need to use gettext.

As usual, I'd be interested to hear peoples' thoughts on this. Please let me know on the -dev list or by e-mail.

Taking time out

2007-07-23T18:12:00.001+01:00

Much of my work on gEDA recently has met with rather mixed responses, many not particularly positive. Most of the things that bug me are fixed, so between the lukewarm reception that seems to meet my changes and the absence of any particular itch to scratch, I'm taking a little time out from gEDA hacking. This will also (hopefully) help with my RSI, which is slightly more aggravating than usual at the moment. No doubt I'll still troll the mailing lists telling users to RTFM (or possibly write it).

My current contract is both interesting and hard; I'm doing an electronic systems redesign for a laboratory automation robot to be used by the Sanger Institute, at the Wellcome Trust site near Cambridge. This is rather involved, with a very broad scope for the work. I've had to learn a lot different types of electric motor (in particular stepper motors and brushless DC motors), as well as needing to keep a very careful eye on issues such as inductive load dump and EMI filtering. Sometimes digging around to find out the design rationale for parts of the current design can get a little tedious; I hope that my attempts to put everything in one place will be useful for future engineers working on the same system!

One thing that has recently struck me while working on this project is the lack of a consistent lightweight symbol library for gEDA suitable for drawing circuit diagrams to be used in documents such as datasheets or academic papers. I've made a rough start on creating one, but have got a little stuck on exactly what symbols are within the scope; and more stuck on finding a sensible way to name all of the different types of diode available.

Making embedding more useful

2007-06-30T14:59:00.001+01:00

One of the trickiest problems electronic engineers have is with keeping their symbol libraries up-to-date while not breaking old schematics (e.g. with changing pin positions).

Currently, most people use one of two approaches to managing the problem:

gEDA has the ability to embed symbol data in the schematic file, making the schematic independent of changing symbol libraries, and some people choose to embed all their symbols. However, a full copy of the symbol is embedded for each time it's instantiated in the schematic, making the file size bloat enormously. In addition, not only is neither possible to check whether any of the symbols have updated versions available in the library nor to update all symbols of a given type together, it is also impossible to make sure that all symbols of the same type are embedded from the same version of that symbol.
gEDA also has the ability to use a project-specific configuration file which lives in the same directory as the schematics. This can be used to implement a project-specific component library where all symbols used by the project live. Although this solves the problem of keeping all symbols in the project in sync with each other, it is quite high maintenance to keep the project library in sync with a "master" library. It is also still impossible to automatically check for newer versions and update them.

My solution to this would be to add the missing features to the embedding functionality (presupposing that these embedding bugs [1692626] are also fixed).

By default, each symbol used would automatically have a single copy embedded in the schematic, which instances of that symbol would reference. This would mean that all instances of a given symbol would be upgraded in lockstep, eliminating inconsistencies.

A hash algorithm would be used to compare the embedded version of a symbol with the latest library version. If they differ, an icon would be shown in a new component manager (derived from the current component selector) and users would be able to update symbols from there, either all symbols at once or one symbol at a time.

I have yet to work out whether it should be possible to edit symbols which do not exist in the local library, but it should certainly be possible to open them for read-only viewing or export them to discrete symbol files.

I believe this solution would eliminate most of the current deficiencies of gEDA and gschem for keeping archived schematics safe and keeping current schematics in sync with libraries.