Normally when you write some code using launchpadlib you end up with Launchpad showing your users something like this:

This isn't great, how is the user supposed to know which option to click? What do you do if they don't choose the option you want?

Instead it's possible to limit the choices that the user has to make to only those that your application can use, plus the option to deny all access, by changing the way you create your Launchpad object.

from launchpadlib.launchpad import Launchpad

lp = Launchpad.get_token_and_login("testing", allow_access_levels=["WRITE_PUBLIC"])

This will present your users with something like this:

which is easier to understand. There could be further improvements, but they would happen on the Launchpad side.

This approach works for both Launchpad.get_token_and_login and Launchpad.login_with.

The values that you can pass here aren't documented, and should probably be constants in launchpadlib, rather than hardcoded in every application, but for now you can use:

• READ_PUBLIC
• READ_PRIVATE
• WRITE_PUBLIC
• WRITE_PRIVATE

Dear Mr Neary, thanks for your thought provoking post, I think it is a problem we need to be aware of as Free Software matures.

Firstly though I would like to say that the apparent ageism present in your argument isn't helpful to your point. Your comments appear to diminish the contributions of a whole generation of people. In addition, we shouldn't just be concerned with attracting young people to contribute, the same changes will have likely reduced the chances that people of all ages will get involved.

Aside from that though there is much to discuss. You talk about the changes in Free Software since you got involved, and it mirrors my observations. While these changes may have forced fewer people to learn all the details of how the system works, they have certainly allowed more people to use the software, bringing many different skills to the party with them.

I would contend that often the experience for those looking to do the compilation that you rate as important has parallels to the experience of just using the software you present from a few years ago. If we can change that experience as much as we have the installation and first use experience then we will empower more people to take part in those activities.

It is instructive then to look at how the changes came about to see if there are any pointers for us. I think there are two causes of the change that are of interest to this discussion.

Firstly, one change has been an increased focus on user experience. Designing and building software that serves the users needs has made it much more palatable for people, and reduced the investment that people have to make before using it. In the same way I think we should focus on developer experience, making it more pleasant to perform some of the tasks needed to be a hobbyist. Yes, this means hiding some of the complexity to start with, but that doesn't mean that it can't be delved in to later. Progressive exposure will help people to learn by not requiring them to master the art before being able to do anything.

Secondly, there has been a push to make informed decisions on behalf of the user when providing them with the initial experience. You no longer get a base system after installation, upon which you are expected to select from the thousands of packages to build your perfect environment. Neither are you led to download multiple CDs that contain the entire contents of a distribution, much of which is installed by default. Instead you are given an environment that is already equipped to do common tasks, where each task is covered by an application that has been selected by experts on your behalf.

We should do something similar with developer tools, making opinionated decisions for the new developer, and allowing them to change things as they learn, similar to the way in which you are still free to choose from the thousands of packages in the distribution repositories. Doing this makes documentation easier to write, allows for knowledge sharing, and reduces the chances of paralysis of choice.

There are obviously difficulties with this given that often the choice of tool that one person makes on a project dicatates or heavily influences the choice other people have to make. If you choose autotools for your projects then I can't build it with CMake. Our development tools are important to us as they shape the environment in which we work, so there are strong opinions, but perhaps consistency could become more of a priority. There are also things we can do with libraries, format specifications and wrappers to allow choice while still providing a good experience for the fledgling developer.

Obviously as we are talking about free software the code will always be available, but that isn't enough in my mind. It needs to be easier to go from code to something you can install and remove, allowing you to dig deeper once you have achieved that.

I believe that our effort around things like https://dev.launchpad.net/BuildBranchToArchive will go some way to helping with this.

If you don't want to read this article, then just steer clear of python-multiprocessing, threads and glib in the same application. Let me explain why.

There's a rather famous bug in Gwibber in Ubuntu Lucid, where a gwibber-service process will start taking 100% of the CPU time of one of your cores if it can. While looking in to why this bug happened I learnt a lot about how multiprocessing and GLib work, and wanted to record some of this so that others may avoid the bear traps.

Python's multiprocessing module is a nice module to allow you to easily run some code in a subprocess, to get around the restriction of the GIL for example. It makes it really easy to run a particular function in a subprocess, which is a step up from what you had to do before it existed. However, when using it you should be aware how the way it works can interact with the rest of your app, because there are some possible nasties lurking there.

GLib is a set of building blocks for apps, most notably used by GTK+. It provides an object system, a mainloop and lots more besides. What we are most interested here is the mainloop, signals, and thread integration that it provides.

Let's start the explanation by looking at how multiprocessing does its thing. When you start a subprocess using multiprocessing.Process, or something that uses it, it causes a fork(2), which starts a new process with a copy of the programs current memory, with some exceptions. This is really nice for multiprocessing, as you can just run any code from that program in the subprocess and pass the result back without too much difficulty.

The problems occur because there isn't an exec(3) to accompany the fork(2). This is what makes multiprocessing so easy to use, but doesn't insert a clean process boundary between the processes. Most notably for this example, it means the child inherits the file descriptors of the parent (critically even those marked FD_CLOEXEC).

The other piece to this puzzle is how the GLib mainloop communicates between threads. It requires some mechanism where one thread can alert another that something of interest happened. To do this when you tell GLib that you will be using threads in your app by calling g_thread_init (gobject.threads_init() in Python) then it will create a pipe for use by glib to alert other threads. It also creates a watcher thread that polls one end of this pipe so that it can act when a thread wishes to pass something on to the mainloop.

The final part of the puzzle is what your app does in a subprocess with mutliprocessing. If you purely do something such as number crunching then you won't have any issues. If however you use some glib functions that will cause the child to communicate with the mainloop then you will see problems.

As the child inherits the file descriptors of the parent it will use the same pipe for communication. Therefore if a function in the child writes to this pipe then it can put the parent in to a confused state. What happens in gwibber is that it uses some gnome-keyring functions and that puts the parent in to a state where the watcher thread created by g_thread_init busy-polls on the pipe, taking up as much CPU time as it can get from one core.

In summary, you will see issues if you use python-multiprocessing from a thread and use some glib functions in the children.

There are some ways to fix this, but no silver bullet:

• Don't use threads, just use multiprocessing. However, you can't communicate with glib signals between subprocesses, and there's no equivalent built in to multiprocessing.
• Don't use glib functions from the children.
• Don't use multiprocessing to run the children, use exec(3) a script that does what you want, but this isn't as flexible or as convenient.

It may be possible to use the support for different GMainContexts for different threads to work around this, but:

• You can't access this from Python, and
• I'm not sure that every library you use will correctly implement it, and so you may still get issues.

Note that none of the parties here are doing anything particularly wrong, it's a bad interaction caused by some decisions that are known to cause issues with concurrency. I also think there are issues when using DBus from multiprocessing children, but I haven't thoroughly investigated that. I'm not entirely sure why the multiprocessing child seems to have to be run from a non-main thread in the parent to trigger this, any insight would be welcome. You can find a small script to reproduce the problem here.

Or, to put it another way, global state bad for concurrency.

As my contribution to Ada Lovelace Day 2010 I would like to mention Emma Jane Hogbin.

Emma is an Ubuntu Member, published author, documentation evangelist, conference organiser, Drupal theming expert, tireless conference presenter, and many more things as well.

Her enthusiasm is infectious, and her passion for solving problems for people is admirable. She is a constant source of inspiration to me, and that continues even as she branches out in to new things.

(Hat tip for the title to the ever excellent Sharrow)

Many projects that I work on, or follow the development of, and granted there may be a large selection bias here, are showing some of the same tendencies. Combined these indicate to me that we need to change the way we look at becoming a trusted member of the project.

The obvious change here is the move to distributed version control. I'm obviously a fan of this change, and for many reasons. One of those is the democratisation of the tools. There is no longer a special set of people that gets to use the best tools, with everyone else having to make do. Now you get to use the same tools whether you were the founder of the project, or someone working on your first change. That's extremely beneficial as it means that we don't partition our efforts to improve the tools we use. It also means that new contributors have an easier time getting started, as they get to use better tools. These two influences combine as well: a long time contributor can describe how they achieve something, and the new contributor can directly apply it, as they use the same tools.

This change does mean that getting "commit access" isn't about getting the ability to commit anymore; everyone can commit anytime to their own branch. Some projects, e.g. Bazaar, don't even hand out "commit access" in the literal sense, the project blessed code is handled by a robot, you just get the ability to have the robot merge a branch.

While it is true that getting "commit access" was never really about the tools, it was and is about being trusted to shepherd the shared code, a lot of projects still don't treat it that way. Once a developer gets "commit access" they just start committing every half-cooked patch they have to trunk. The full use of distributed version control, with many branches, just emphasises the shared code aspect. Anyone is free to create a branch with their half-baked idea and see if anyone else likes it. The "blessed" branch is just that, one that the project as a whole decides they will collaborate on.

This leads to my second change, code review. This is something that I also deeply believe in; it is vital to quality, and a point at which open source software becomes a massive advantage, so something we should exploit to the full. I see it used increasingly in many projects, and many moving up jml's code review "ladder" towards pre-merge review of every change. There seems to be increasing acceptance that code review is valuable, or at least that it is something a good project does.

Depending on the project the relationship of code review and "commit access" can vary, but at the least, someone with "commit access" can make their code review count. Some projects will not allow even those with "commit access" to act unilaterally, requiring multiple reviews, and some may even relegate the concept, working off votes from whoever is interested in the change.

At the very least, most projects will have code review when a new contributor wishes to make a change. This typically means that when you are granted "commit access" you are able or expected to review other people's code, even though you may never have done so before. Some projects also require every contribution to be reviewed, meaning that "commit access" doesn't grant you the ability to do as you wish, it instead just puts the onus on you to review the code of others as well as write your own.

As code review becomes more prevalent we need to re-examine what we see as "commit access," and how people show that they are ready for it. It may be that the concept becomes "trusted reviewer" or similar, but at the least code review will be a large part of it. Therefore I feel that we shouldn't just be looking at a person's code contributions, but also their code review contributions. Code review is a skill, some people are very good at it, some people are very very bad at it. You can improve with practice and teaching, and you can set bad examples for others if you are not careful. We will have to make sure that review runs through the blood of a project, everyone reviews the code of everyone else, and the reviews are reviewed.

The final change that I see as related is that of empowering non-code contributors. More and more projects are valuing these contributors, and one important part of doing that is trusting them with responsibility. It may be that sometimes trusting them means giving them "commit access", if they are working on improving the inline help for instance. Yes, it may be that distributed version control and code review mean that they do not have to do this, but those arguments could be made for code contributors too.

This leads me to another, and perhaps the most important, aspect of the "commit access" idea: trust. The fundamental, though sometimes unspoken, measure we use to gauge if someone should get "commit access" is whether we believe them to be trustworthy. Do we trust them to introduce code without review? Do we trust them to review other people's changes? Do we trust them to change only those areas they are experts in, or to speak to someone else if they are not? This is the rule we should be applying when making this decision, and we should be sure to be aware that this is what we are doing. There will often be other considerations as well, but this decision will always factor.

These ideas are not new, and the influences described here did not create them. However the confluence of them, and the changes that will likely happen in our projects over the next few years, mean that we must be sure to confront them. We must discard the "commit access" idea as many projects have seen it, and come up with new responsibilities that better reflect the tasks people are doing, the new ways projects operate, and that reward the interactions that make our projects stronger.

I have a problem that I believe will be easy for someone with a bit of UNIX coding knowledge to solve, so I appeal to those that can to help.

I'm trying to write a DBus service that will spawn a command, and provide the output to the user. The service runs on the system bus as root, and so it is a form of privilege escalation. However, the command may be long running, and produce a lot of output as it works, so I want to allow the calling process to get this output before the command completes.

My current approach uses gobject.spawn_async and so gets file descriptors back, one for stdout and one for stderr. I currently have a thread that uses select to wait for output, and then uses DBus signals to allow the client to access it. This works great, except that stdout and stderr can become interleaved in the middle of lines.

I believe that I can't just wait for full lines before signalling, as a command might do something like print "Username: " and then wait for input. I could normally do full lines, and then if the child blocks on stdin send whatever it has written so far, but that doesn't seem ideal. (I haven't implemented anything about proving input on stdin so far, but I don't want a solution that makes it difficult to do so).

It seems to me that this is something that will be implemented somewhere, for instance my shell can run commands and then interleave the output in a desirable manner, but I haven't found how yet. Any suggestions are welcome, but this is from python, so system calls that I can't make directly from python would be a pain, though I'm not that bothered about portability.

As well as the new notification bubbles, jaunty now has something called the "indicator-applet", or various other names. If you are running Jaunty you may have seen it as an envelope in your panel. Not much is taking advantage of it yet, with only Evolution and Pidgin having the necessary support until recently.

The purpose of this applet is to give you access to messages that are waiting for you, regardless of the source. You can see some of Ted's early sketches on the idea, or the early draft of the spec for some information. Having this place gives you one place to look to respond to a message you received, and is part of the strategy to solve the issues caused by having notifications without actions. It also allows you to launch the main windows of the applications so you don't need to have an icon for each in the notification area.

As I don't use pidgin the only thing taking advantage of the menu was evolution, so I went to find which of the other apps I use had support. I first grabbed a more recent version of gwibber which had support, and sent a quick merge request to improve the support. There was little else I could do there though, as Ryan had done a great job already, and all I had to do was hook up a callback so that gwibber would open when you clicked on a message you received from someone.

I then moved on to Empathy, and found a bug requesting support be added. I decided to relax this weekend by working on something completely different and trying to add this support.

I found the libindicate API easy to work with, though it is un-documented currently there is not too much too it, and it has quite some similarity with libnotify. After finding my way around the empathy internals, learning more about gtk+ and encountering a bug in libindicate that I spent some time investigating I had something mostly working. It's not ready to merge yet, but it is most of the way there, and covers the most common cases.

You can see a quick video of the interaction, which shows the concept behind the menu as well. (Yes, I am talking to myself in that video, as Ted said, working on IM apps can be quite lonely as you continually send yourself messages).

This was supposed to be an Ada Lovelace Day post, but jet lag got the better of me last night before I could write it, so it's a Lady Day post instead, which is strangely apt. We don't have to restrict ourselves to a single day to highlight great people anyway.

The woman that I would like to write about is Sarah Bird. Sarah is an engineer by training, and spent much of her time working in the development, thanks in part to MIT's D-Lab. One of her University projects was a cheap land mine clearing device, which looked like a big drum on wheels, because that is essentially what it was. She always talks about it with great passion, as it meant that she got to test it by blowing things up.

In conjunction with Amy Smith (who is apparently also made of awesome) she has been working on "balls" which allow samples to be refrigerated so that they can be tested when there is no power. There work has the potential to save many lives, and they won a Deshpande grant to continue the research.

Last time I spoke to Sarah she was heading out to Pakistan with her new company SaafWater, trying to ensure that Pakistani families drank clean water, and using an innovative strategy to achieve that.

I know Sarah as I did a Summer internship at Aptivate, a UK NGO, at the same time as she was working there. She had a knack for analysis, and for explaining things, and she gave me the language to talk about many things, such as concerns about the OLPC project.

In particular though she taught me that simply considering yourself to be non-discriminatory is not enough. Trying to treat everyone in the same manner doesn't help to remove inequality, it will just perpetuate it. Without concerted effort the solution will just reflect the needs of the majority, and their needs are already well enough accounted for. If you want to have a solution that works for everyone, then everyone needs to be represented in those designing the solution. For that I am very grateful.

In addition to all that she's also great fun, and we spent many a great evening in the pub.

I'm also glad to say that there are also many inspiring women in the communities I am part of. It was great to see so many of the posts yesterday being about women that are currently active in Free Software, it's great to have so many peers that you can look up to, as well as the pioneers.

Please consider the following hypothetical situation. gnome-screensaver keeps crashing for people on Jaunty, which is pretty annoying, so it sends lots of people to Launchpad to report a bug.

It's pretty quickly established by the amazing desktop team triagers that it's actually a problem in Gtk+, so they duly reassign the bug there.

However, it's a little while before the fix is forthcoming, and it that time many users are still getting hit by the bug, so they are still heading to launchpad. As most of us aren't Gtk+ hackers we don't see that the issue is there, so we go to the obvious place to report the bug, the gnome-screensaver package, and not seeing any existing reports about the bug we file a new one.

This means that the desktop team has to spend time shovelling the bugs over to Gtk+ and duplicating them to the first one. While we have some tools to help with this sort of thing it would be great if we could try and avoid it all together.

One way this could be solved in Launchpad is to leave a task open on the gnome-screensaver package, but this isn't ideal, as the bug doesn't need to be fixed there. You could mark a gnome-screensaver bug on the package as Invalid, which would make the dupe search as you report a bug show it, but it wouldn't show up for those that just trawled the open gnome-screensaver bug reports looking for the crash.

My idea for something that would help in this case is Ghost bugs. These are bugs that are the ghosts of a bug somewhere else. In the above case a ghost bug could be created against gnome-screensaver pointing to the Gtk+ bug. It would then show up in the bug lists, but not have a status etc., and be somewhat "greyed out", hence the name ghost bug.

As the bug affects gnome-screensaver it makes sense for it to show up against that, but as it doesn't need to be fixed there it shouldn't have the rest of the information.

It doesn't just work for packages. See for example launchpad bug #174539. This is a bug that should be fixed in bzr, but it only manifests itself in bzr-builddeb. I am keeping a task against bzr-builddeb so that it shows up in my list to fix to have bzr-buiddeb work great, but I don't really need a status as nothing needs to change in bzr-builddeb for it to work.

With Launchpad having the concept of bug tasks this could be easily done by adding a new status Ghost, or perhaps Fix Elsewhere or something. This would be handled differently to the other statuses, giving behaviour such as that I described above.

Having a whole bug task may not be the right thing though. It could instead be a separate list, similar to the list of bug tasks, but just listing the things that should have ghost tasks.

Does anyone else think this would be useful? Is there prior art?

I have a small request to make. When writing a changelog entry please remember you are writing it for other people to read as well. Please document why you are doing something in enough detail that I can work it out later on.

A changelog is not just for describing what you changed, it should be for describing what you changed and why you changed it.

Just documenting what was changed is not that helpful, as I can simply look at the diff to see that. What I can't get from the diff is what was in your head at the time, the motivation, the reasons why you chose that solution, the stuff that I care about when I am looking at the change.

Oh, and one more thing, your immediate motivation may not be the one that I care about. "Because somebody told me to" isn't the reason that will help me understand the change.

Thanks in advance,

James

I was thrilled this morning to finally come up with what I hope is a fix for a bug in ConsoleKit that has been plauging a lot of users, judging by the number of subscribers and duplicates on the Ubuntu bug

I was happy to get upload fixes for various other bugs and sponsor some more from other members of the community.

I was pleased to see a group of people to come together to prepare uploads for the 2.24.1 release of GNOME.

I enjoyed going to my favourite curry restaurant for lunch and listen to the stories from my friend's trip to Malawi.

I was disappointed to read an article on the dailywtf.com today after I saw a pointer to it.

I was saddened to read this post in response.

Carolyn, if on the off chance you read this post, I'm sorry that you feel that way. I can only hope it doesn't end your involvement with our community, though I would understand if it did, it can't be easy to be involved with a community which makes you feel like that, no matter how infrequently. I can only promise that I will try and discourage things I see which I feel are likely to provoke similar reactions, and do my best to build communities that are welcoming. I also apologise in advance for those times when I fall short.

-- This post belongs to Lionel Richie

I recently attended Lugradio Live in Wolverhampton. During the live recording of the show they were discussing how things have changed since the started the show. Aq was saying that things are less interesting nowadays, as everything just works. I disagree that it's less interesting, not spending time compiling drivers for my video card means I can spend time on other things.

I bought another laptop this week, and so I can personally attest that the developers involved should be proud, all of the hardware was supported out of the box, with just a few minutes following instructions on a wiki page to get everything working properly. Also, all of those little tweaks won't be needed in a few months time, as the developers have fixed the problems.

However, I also disagree that everything just works. Even though it took me only a couple of hours to install and get all of the hardware working, I'm still setting up the laptop. Why do I have to spend ages configuring all of the applications, even though 90% of the settings will be the same as on my other laptop? I could copy across my dotfiles, but there could be more done to help me move just those that make sense to be on another machine. (I don't think I would want to copy the whole of .mozilla/)

There's more though. Though I have two laptops running linux next to each other, it's not that easy to move a file between them. Why do I have to enter details of my contacts more than once? Why isn't it trivial for me to send off an email to someone I am chatting to on IRC? I could go on.

The work on the kernel, drivers and installers that meant that it only took me a couple of hours to get up and running is a fantastic achievement; it's what allows us to ask questions like these. There is more that needs to be done in these areas, but we need to expand our ideas of what should just work.

I don't wish to discredit those that are working on this sort of problem, there should be more people helping them. We need other developers to appreciate the issues, and support those trying to tackle them.

If you agree with me then don't complain about it, fix it. Find a project working on a problem that you care about and support them however you can. I realise the irony inherent in telling everyone this at the end of a post like this, I hope you will forgive me.

-- This belongs to Lionel Richie

Hello Planet Ubuntu.

This feels like I've just made it on stage with my favourite band.

Today I was accepted as an Ubuntu member through the Universe Contributors group. Thanks to all those that helped me achieve this. There's been a load of other people join this group recently. Hopefully this is a sign of things to come, and we're going to have some great releases coming up.

It's an interesting time to be joining planet, with yesterday's CC meeting discussing what role the planet should play in our community. I think that Emma had a good post touching on how we should conduct ourselves. (Hey Emma, when are you going to become a member so that more people see your insightful posts? And the animal ones too, I like those)

Emma refers to a poem by Robert Frost in her post, I had heard of it before, but I had never read it, so I hunted it out. I recommend reading it.

Mending Wall
Robert Frost (1874-1963)

SOMETHING there is that doesn't love a wall,
That sends the frozen-ground-swell under it,
And spills the upper boulders in the sun;
And makes gaps even two can pass abreast.
The work of hunters is another thing:
I have come after them and made repair
Where they have left not one stone on a stone,
But they would have the rabbit out of hiding,
To please the yelping dogs. The gaps I mean,
No one has seen them made or heard them made,
But at spring mending-time we find them there.
I let my neighbour know beyond the hill;
And on a day we meet to walk the line
And set the wall between us once again.
We keep the wall between us as we go.
To each the boulders that have fallen to each.
And some are loaves and some so nearly balls
We have to use a spell to make them balance:
"Stay where you are until our backs are turned!"
We wear our fingers rough with handling them.
Oh, just another kind of out-door game,
One on a side. It comes to little more:
There where it is we do not need the wall:
He is all pine and I am apple orchard.
My apple trees will never get across
And eat the cones under his pines, I tell him.
He only says, "Good fences make good neighbours."
Spring is the mischief in me, and I wonder
If I could put a notion in his head:
"Why do they make good neighbours? Isn't it
Where there are cows? But here there are no cows.
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offence.
Something there is that doesn't love a wall,
That wants it down." I could say "Elves" to him,
But it's not elves exactly, and I'd rather
He said it for himself. I see him there
Bringing a stone grasped firmly by the top
In each hand, like an old-stone savage armed.
He moves in darkness as it seems to me,
Not of woods only and the shade of trees.
He will not go behind his father's saying
And he likes having thought of it so well
He says again, "Good fences make good neighbours."

From http://www.bartleby.com/118/2.html

I love Stephen Fry, everything he does is great, but also seems to come with a touch of quality as well. His documentaries are probably a lesser known part of his work, but they are equally fantastic; the two-part documentary on manic depression was particularly notable.

Last night a watched a new documentary presented by him, and while it was neither as moving or as personal as the others I have seen it was still interesting and enlightening. This particular documentary was about Johannes Gutenberg, the printing press that he invented, and the impact which this had upon the world.

He explained that the printing press, and the increased access to knowledge that it allowed, was a major factor in the Renaissance, which radically changed the world, and can be seen in the world in which we live today.

In Gutenberg's time the Church was the most powerful organisation. He worked with the church, and tried to show them the benefits of his idea to them. It was suggested that he would never have succeeded if he had not courted the Church. If the printing press was indeed the catalyst for the Renaissance, and the Renaissance was the start of the decline in the power of the Church that we see today, then the Church's embrace of the printing press could be said to have precipitated their loss of power and influence.

Are there any ideas at the current time that are as powerful as the idea of the printed word? During the programme their were a couple of references to the growth of the printing press being similar to that of the growth of the Internet in recent years.

The Internet, like the printing press before it, allows a new group of people to have direct access to information. Will that access cause a fundamental shift in our world and our lives?

Is there a dominant force in the world which will be diminished by the Internet? Are they currently embracing it as a tool which they can use to entrench their position? Are we thinking too small; is there something we haven't thought of yet that is going to have an even more radical impact?

The lecturer who taught me evolutionary computing was also a devout Christian, who believed that the world is the way that it is because God created it, rather than it evolving via natural selection.

This was quite surprising to us when he revealed this, but he did not see a problem with holding this view. He recognised that there was a fundamental conflict between Darwinism and Creationism, but not one between his work and his religious beliefs. He could see that the theory of natural selection could be an effective optimisation algorithm where the form that the solution would take was not entirely clear, but it was not his belief that this was the mechanism by which humans arrived on this earth.

It's an interesting feature of science that he was able to hold this position and still research in the field. At one point in the year he did give a lecture on creationism itself. This was not one of the lectures that made up our course, it was an optional lecture at luchtime, open to the whole engineering faculty and other members of the University. I did not attend, but many people got very excited beforehand, seeing it as a chance to go and argue with a holder of this belief and try to discredit the idea. Perhaps they were also spurred on by the fact that he was a man of science, and so potentially more likely to listen to an argument of logical reasoning.

I don't think anyone convinced him, and I doubt anyone ever will, he has obviously confronted this issue many times in the course of his work and still holds the two potentially conflicting ideas in his head.