Apparently I’ve had a github account for ages, and never used it. Recently I’ve been using github a for some work I’ve been doing with Intel at Collabora.
I picked up my saxophone for the first time in a while last night and went along to a big band rehearsal. Very quickly discovered that I’ve forgotten most of my scales and that I need to do some practice.
Realised I didn’t feel like writing eight scales out in nine keys, and there had to be a better way, so I played around for a bit with lilypond and then hacked together a bit of Python to help generate my scales.
Anyway, I thought this was pretty neat, and possibly useful to others, so I’ve shoved it on github.
I rebooted the other day, which got me a new kernel (3.2.91), and now it seems my wireless (rtl8192ce) has become really flaky and unstable. At first I thought it was the router playing up, but everything else in the house works fine (everything else in the house is made by Apple it seems).
Typically it fails to associate until you reboot the router (which is why I thought it might be the router) or occasionally the laptop. When it is connected performance is occasionally crappy. I’m totally out of my depth debugging this. I poked around a bit but found nothing meaningful.
- I think I was running 3.2.1 before, which got uninstalled. Fedora helpfully left 3.2.6 and 3.2.7, neither of which I think I ever booted into. [↩]
Since it’s annoyingly hard to work out what muxer to use for m4a files, and I don’t have a profile for encodebin, here’s the gst-launch command to make m4a or m4r (ringtone) files.
gst-launch filesrc location=input.file ! decodebin2 ! audioconvert ! faac ! ffmux_mp4 ! filesink location=output.m4a
This is a neat trick, and so I thought worth reblogging. I was handed a corrupt SD memory card yesterday and asked if I could try and get some Christmas photos off it.
Typically, the first thing I did was image the card with ddrescue (package gddrescue in Debian/Ubuntu), confirming that the partition table was intact, it looks like the problem was a corrupted FAT, so I wanted to run fsck on the partition.
Back in the day this would have involved either dd-ing the partition out of the image, or re-imaging the card, both slow, or screwing around with loopback offsets. Instead I discovered a tool called kpartx which maps the partitions from the image into the device mapper, giving a device like /dev/mapper/loop0p1, which can be used like a regular block device.
Unfortunately while different, both FATs were damaged, and has been incorrectly repaired by something, and I ended up recovering the files with photorec instead.
Happy new year, everyone!
Once again my former employer, Fugro Seismic Imaging, is looking for two new R&D staff for their office in Perth, Western Australia (one to replace someone who’s moving on, and another to grow the team).
The team there is approximately half a dozen people, generally open-source experienced, who are primarily developing graphical front ends to geophysics applications (there’s also some other stuff, in general it’s pretty cool). You’ll almost certainly have to know C. Knowing any of C++, Python, Perl, GTK+, Qt or Fortran also a benefit. You don’t have to know any geophysics, but knowing a bit of maths and physics helps. You’ll easily pick up what you don’t know as you go along.
Pay and conditions are very good. FSI have previously provided sponsored work visas for skilled applicants looking to work in Australia.
If you’re interested, send your CV to the regional manager, Kelly Beauglehole.
I find it so amusing yet depressing how afraid your average engineer now is now afraid of a computer.
My brother started his first real engineering job and rapidly found himself with a problem he needed to solve. He can’t afford Matlab or Mathematica, so I suggested he teach himself Python and use that. After all, Python has excellent scientific credentials. He looked at Python and agreed it looked easy to learn and met his needs.
His boss however, vetoed the idea on the basis that if a tool were written in Python, no one would be able to come back later and edit it. The implicit assumption here seems to be that programming is hard. That no one else could learn enough of the language to later edit the program.
Once upon a time, computers didn’t do very much. They could read and write data and execute programs. Engineers and scientists had to teach themselves to write their own programs to solve their problems.
Over time programs got bigger and more complex. Then people started collecting them together into packages of tools and turning them into a product to sell to other people. They hired engineer-programmers to work on them. Eventually they glued user interfaces on top and so we get the engineering and scientific packages you see today. [My first programming job was working on one of these packages.]
New engineers start in the field and they are simply taught the package at the user interface level. Sometimes they hit the limits of the interface, and learn how to drive the individual programs underneath.
Rarely though do they still see the computer as the blank canvas which they can use to solve their problem. It does so much now that the idea of learning to make it do more seems foreign. Engineers are now afraid of the tool.
It is my belief that engineering students should be compulsorily exposed to some computer science; The core stuff with useful tools. They should have to implement algorithms that have meaning to engineers: solving equations, not a booking system for tennis matches. Perhaps then they’ll stop being afraid of using computers to do computation.
The GOPW application period is coming to a close soon, and so potential interns are currently getting their initial contribution in to qualify.
Obviously the nicest way to submit your patch is as a commit, or series of commits using git, either via git bz or git format-patch (a branch is nice too, but submitting the patch in Bugzilla allows for inline review).
Of course, after your patch is correct, the maintainer is going to want to merge it into the tree, in which case you need to have a useful commit message. GNOME has some guidelines on commit messages, but here are the important dot points:
- the first line should be a short description, no more than 72 characters and does not end with a full stop;
- the next line should be empty space;
- following this is an optional longer description, this should be written in regular paragraphs with full sentence structure;
- finally if this patch fixes an open bug, there should be a link to the bug report, in a paragraph by itself.
Here are some good examples taken from Empathy:
Don't destroy MainWindow on delete-event, just hide it
This stops MainWindow being unreferenced, and prevents crashes caused by things which then try to use it.
This one has a tag:
e-account-widget-jabber: Use GtkGrid instead of GtkTable
This works around bug #657621.
Here’s another way of doing a tag (preferred by some projects):
[contact-chooser] emit 'activate' on 'row-activated' as well
This means the selection can be activated when the treeview is focused.
Or a one-liner commit:
[contact-chooser] Move the selection up/down without defocusing the entry
Remember that your commit message is important. They tell other developers what’s changed. What a commit fixes, or does, or is meant to do, and occasionally, what it doesn’t do. Commit messages are often used by the maintainer to write the release notes. When things break, people come back looking through the code for what broke it (e.g. via a git bisect) so clear and useful commit messages are essential.
October 7th is Ada Lovelace Day. A day that showcases women in science and technology by profiling a woman technologist or scientist on your blog.
This year I wanted to write about two women who I’ve met and worked with in the last year as a mentor of the GNOME Outreach Programme for Women and the Google Summer of Code.
I met Chandni when she applied to be an Empathy intern for the GNOME Outreach Programme for Women. Chandni had never worked in open source before, but she approached it with an amazingly keen enthusiasm. Before too long Chandni began to grasp the ropes, learning GTK+ and Telepathy. She then went on to fix bugs in Empathy as well as the Telepathy connection managers.
Chandni studied computer science at the Dr M.C. Saxena College Of Engineering & Technology and has a passion for algorithms and would regularly participate in algorithm competitions. She learned about open source from a friend and in her final year of college and ordered Ubuntu CDs to check it out. Chandni says “I liked the idea of open source particularly since it allowed one to learn and evolve without any restrictions even if you are a student.”
Chandni applied for GOPW after completing her final year and has remained working on Empathy since the end of her internship. Chandni gave her first conference presentation, detailing her experience with the programme, at GNOME.Asia. She had hoped to give it again at the Desktop Summit, but unfortunately bureaucracy got in the way. She looks forward obtaining a position with a company working on GNOME.
Tiffany was in the same intake of the GOPW as Chandni, working on the documentation for GNOME with Paul Cutler. I then met Tiffany when she applied for the Google Summer of Code to work on integrating Empathy and Evince.
Tiffany is studying software engineering at McMaster University and also taught first year programming to students of the same course, having helped to design the curriculum. Before studying software engineering, Tiffany was a veterinary technician, and used to work in an emergency vet clinic. She also works part time in a neuroscience research lab.
Tiffany got involved in GNOME through the GNOME Documentation Project after being an Ubuntu user for around two years prior. In 2011 Tiffany attended the GNOME docs hackfest, the Open Documentation Conference and the Desktop Summit, where she worked on improving the documentation for GNOME. She successfully applied for Google Summer of Code with a project to work on integrating Telepathy into Evince. Recently Tiffany began working on the Esperanto translation for GNOME.
My Thinkpad X200s is playing up, in that it will no longer suspend and sometimes the wireless stops working until I reboot. The suspend issue looks like an issue with the Thinkpad TPM, but that’s meant to be resolved, and I could have sworn it was previously working while I was still running this kernel.
I checked the workaround was enabled (it is). Blacklisting the modules or disabling the Security Chip in the BIOS causes it to sleep, but not wake up. Someone suggested upgrading the BIOS firmware, but I’ve always been wary of doing this, I’ve bricked machines before.
Anyway so that I can put some computation that suspends in my bag, I installed Fedora 15 on the Dell Inspiron Mini 1012 I have. The machine itself is a little slow, but GNOME Shell runs pretty well. The trackpad drivers have improved too. Less weird jumping around and two finger scrolling.
Managed to crash the Fedora installer twice, it crashes when it tries to delete extended DOS partitions (automatically or manually). Had to delete my old Meego-created partition tables by hand for it to work.