A colleague of mine at Facultad de Ingenier a pointed me to a note published in the Faculty's gazette about a short cycle of talks we had on April 4th, trying to get life and interest back in the once-active LIDSOL (Laboratorio de Investigaci n y Desarrollo en Software Libre, Free Software Research and Development Laboratory), which nowadays lies mostly dormant. Good thing the official communication channels got notice of this! Only I am not sure if they can properly produce Spanish (as this feels more like an English redaction). Quoting only the first lines of the paragraph that referes to me:

La ltima conferencia fue presentada por Gunnar Wolf, que aunque su nombre nos hiciera pensar en una nacionalidad europea, l es nacido en tierras mexicanas pero con descendencias h ngaras, austriacas y polacas.

Which translates to:

The last talk was presented by Gunnar Wolf, that although he has a name that makes us think about an European nationality, he was born in Mexican soil, but with Hungarian, Austriac and Polish descent.

As far as I can tell (and I am almost sure I know all of the story At least on that regard), I have no descent yet. Not Hungarian, Austriac, Polish, nor of any nationality. (nitpickers: Yes, similar words are often used. In Spanish, it would be correct to say de ascendencia h ngara, austriaca y polaca, and in my attempt towards English translation, it would be of Hungarian, Austriac and Polish descent).

Weblate 1.5 has been released today. It comes with lot of improvements, especially in performance, reporting and support for machine translations. Full list of changes for 1.5:

• Please check manual for upgrade instructions.
• Added public user pages.
• Better naming of plural forms.
• Added support for TBX export of glossary.
• Added support for Bitbucket notifications.
• Activity charts are now available for each translation, language or user.
• Extended options of import_project admin command.
• Compatible with Django 1.5.
• Avatars are now shown using libravatar.
• Added possibility to pretty print JSON export.
• Various performance improvements.
• Indicate failing checks or fuzzy strings in progress bars for projects or languages as well.
• Added support for custom pre-commit hooks and commiting additional files.
• Rewritten search for better performance and user experience.
• New interface for machine translations.
• Added support for monolingual po files.
• Extend amount of cached metadata to improve speed of various searches.
• Now shows word counts as well.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you.

Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!

You might of looked at Ralph Bean s tutorial on graphs and thought, that s nice but I d like something different. The great thing about ToscaWidgets using the jqPlot library is that pretty much anything you can do in jqPlot, you can do in ToscaWidgets and by extension in TurboGears. You want different graph types? jqPlot has heaps! My little application needed a Pie Chart to display the overall status of attributes. There are 6 states an attribute can be in: Up, Alert, Down, Testing, Admin Down and Unknown. The Pie Chart would show them all with some sort of colour representing the status. For this example I ve used hard-coded data but you would normally extract it from the database using a TurboGears model and possibly some bucket sorting code. I ve divided my code into widget specific, which is found in myapp/widgets/attribute.py and the controller code found unsurprisingly at myapp/controllers/attribute.py Also note that some versions of ToscaWidgets have a bug which means any jqPlot widget won t work, version 2.0.4 has the fix for issue 80 that explains briefly the bug. The widget code looks like this: Some important things to note are:

• resources are the way of pulling in the javascript includes that actually do the work, generally if you have something like a renderer using js_symbol further on, it needs to be listed in the resources too.
• seriesColors is how you make a specific data item a specific colour, or perhaps change the range of colours. It s not required if you use the default set, which is defined in the jqPlot options.
• The renderer tells jqPlot what sort of graph we want, the line above says we want pie

Next the controller needs to be defined: And that is about it, we now have a controller path attributes/statuspie which shows us the pie chart.
My template is basically a bare template with a $ w.display n in it to just show the widget for testing.

Keith and I have discovered a change in the behavior of the protection circuits integrated in the LiPo batteries we sell for use with Altus Metrum products that poses a risk for our customers. This post is meant to document what we now know, communicate changes we're planning as a result, and explain what we think flyers of our existing electronics and batteries may want to do to maximize their chances of successful flights. Background Choosing batteries and designing pyro circuits for high power rocketry avionics involves a variety of trade-offs. Reliability is the highest concern, both because nobody wants to lose an airframe due to a failed pyro event, and also because airframes recovering anomalously have safety implications. But we also care about other factors including cost and weight, and usually want to minimize the complexity of both the electronics and the overall installation. The objective of a pyro circuit is to dump enough energy rapidly into an electric match to cause it to catch fire. We need batteries both to power the electronics that decide when to fire the charge, and to provide the energy that actually ignites the match. The two most common battery types seen in the rocketry hobby are alkaline cells, often the nominal 9V rectangular variety, and rechargeable batteries based on Lithium Polymer (LiPo) chemistry. LiPo cells are 3.7 volts per cell nominal voltage, are very light, and have a high energy density. LiPo capacity is measured in units of current times time, so an 850mAh cell should be able to deliver 850 milliamps for an hour. The battery industry also uses something called a "C rate" to describe how fast the battery can be usefully discharged, wich is a multiplier relative to the battery capacity. So a battery with 850mAh capacity and a "2C" rating can deliver current at a sustained rate of 1700mA until discharged, while the same capacity at a "5C" rating can deliver 4250mA. By comparison, most 9V alkaline batteries are actually composed of 6 individual 1.5V cells enclosed in a wrapper. It's hard to get hard numbers for capacity and discharge rate, since in an alkaline cell the two are not independent, and the discharge rate is related to the volume of each individual cell. The data sheet for an Energizer 522 shows just over 600mAh at a 25mA discharge rate, dropping to about 300mAh at a 500mA discharge rate. Importantly for use in pyro circuits, LiPo cells have a very low source impedance, which means they can source immense amounts of current. It's not unusual for cells in the 1000mAh range to have ratings in excess of 30C! Because this rapid discharge ability can pose a risk of fire, it's common for LiPo cells to come with a "protection board" integrated into the battery assembly that is designed to limit the current to some rate such as 2C continuous duty. In large airframes, or projects that involve staging, air-starts, or other complex pyro event sequences, the most reliable approach will always be to use separate batteries for the control electronics and the source of pyro firing power. In the limit, having separate pyro batteries for each pyro charge with the control electronics only providing the switching to connect the batteries to the charges could even make sense. But for most airframes, this is overkill, and the increases in mass, volume, and wiring complexity just don't make sense. The challenge, then, is how to design electronics that will robustly initiate pyro events without negatively affecting the rest of the electronics when operating from a single shared battery. Altus Metrum Pyro Circuits The very first prototypes of TeleMetrum were designed to use a single-cell LiPo battery, and had an on-board 100mA charging circuit. Because we needed 5 volts to power the accelerometer, we had a small switching regulator that up-converted the LiPo voltage, and we used some of that regulator's output to charge a 1000uF capacitor. The pyro circuit used Fairchild FDN335N N-channel MOSFET switches in a low-side switching configuration to dump the energy stored in the capacitor through an attached ematch. Those FETs had an on resistance of under a tenth of an ohm in our operating conditions. The circuit worked very reliably, but the 1000uF electrolytic cap was huge and we struggled with the mechanics of such a large part hanging off the board... It turns out that 3.7 volts is way more than enough to fire a typical low-current e-match or equivalents like the Quest Q2G2 igniters. In fact, bench testing with a good digital oscilloscope showed that a typical e-match with resistance of 1.3-1.8 ohms will fire in approximately 13 microseconds when hit with the nominal 3.7 volts from a LiPo. So, starting with our v0.2 boards, we switched to using the LiPo battery voltage directly to fire the pyro charges, eliminating the clunky electrolytic capacitor entirely. We also switched to the Fairchild FDS9926A dual N-channel MOSFET whose specs are better in all regards for our application. The on resistance is down around 40 milli-ohms in our circuit, such that the current ratings are much higher (FET current limits are primarily driven by how much heat is generated due to current flowing through the channel's on resistance). Because using the LiPo voltage directly means we're effectively temporarily putting a very low resistance across the battery during the pyro events, the input voltage to the voltage regulator gets pulled down. To ensure the processor could "ride through" these events, we added a 100uF surface mount bulk capacitor on the 3.3 volt regulated voltage rail, which bench testing demonstrated was more than sufficient to maintain processor operation through pyro events. And that is essentially the same pyro circuit on all the boards, both TeleMetrum and TeleMini, that we have shipped to date. What's Changed The LiPo batteries we source and sell with our electronics come with a protection board and cable terminated in a 2-pin, 2mm "JST" connector. The specs on the protection board have always been "2C continuous", but we observed the ability to source much higher currents for short periods such as the 13 micro-seconds or so required to fire an e-match. Thus these protection circuits seemed just fine .. we could fire e-matches with a burst of current but were protected against short circuits in the wiring or our boards by the 2C continuous limit. Unfortunately, the most recent batch of batteries we sourced seem to have a much "twitchier" protection circuit. We can draw more than 2C for short bursts, but not as much as with prior boards, and not for as long an interval. With a 1 ohm power resistor on the pyro terminals of one of our boards, we get about 9 milliseconds of power before the protection circuit cuts in and shuts the battery down. The power stays down until all load is removed, which at least means the board is turned off and back on again, and in some cases could even mean the battery is unplugged and re-plugged since we draw trace current to keep the GPS memory alive even when the power is turned off, and at least some of the new batteries see that as enough to keep the power turned off after an over-current event. For many e-matches, this isn't an issue, since 9 milliseconds is way longer than the 13 microseconds needed to fire the charge. Unfortunately, we've discovered that many of the e-matches bought and used in the rocketry hobby are actually made for use in the fireworks industry, where it is desireable to retain continuity after firing so that series connections of e-matches all can fire even if some fire faster than others! This means that while the resistance goes up some after firing, sometimes the drain on the battery remains sufficient to cause the protection circuit to kick in even after the pyro charge has fired. What We're Doing About It If we remove the protection circuit from the LiPo (or jumper around it), all existing Altus Metrum products will operate successfully with pyro charges thave have an effective resistance of as low as 1 ohm. That's lower than any e-match or Q2G2 we've ever seen, so in effect what this means is that if you have an existing Altus Metrum flight computer, and you remove the LiPo protection circuit, you're good to go. This does not really make things any more "dangerous", since our battery chargers are all current limited and our discharge patterns will never cause heating of the battery. Frankly, in a rocket, the most likely way to cause a problem with a LiPo is by smashing or puncturing the actual battery during bench work or during a crash... and those cause the same problems with or without a protection board present. In the future, we will ship batteries that have either a much higher C rating on the protection circuit, or have no protection circuit at all. The number of problems reported by actual customers that we think should be attributed to LiPo protection circuit boards is very low, and we suspect most of our customers who are happily flying their boards can continue to do so. Ground testing where you fire pyro charges (or at least e-matches) using RF to issue the commands (not USB, since the LiPo charger is running any time USB is connected!) will confirm whether there's a problem. If the board resets (does startup beeps) after a pyro event, or shuts down completely (no LED activity), then you have a problem. If the matches light and the board keeps running, you're good to go. However, any Altus Metrum customer with LiPo batteries sourced from us or our distributors who is worried about this problem (even if you haven't seen problems in ground testing or previous flights), and who doesn't want to try soldering on the battery circuit board yourself, is welcome to contact us about removing the protection circuit for you. We won't charge anything other than shipping. To take advantage of this offer, just send email to fixmybattery@altusmetrum.org telling us how many of which capacity batteries you have that you'd like updated, and we'll respond with an RMA number and shipping details. Going Even Further As previously indicated, with the LiPo protection circuits removed, all of our current products will work reliably with at least 1 ohm across the pyro terminals. That should cover all real-world flying conditions just fine, but we're not satisfied yet. We've designed a new pyro control circuit that transfers the maximum possible energy to the load regardless of battery voltage without ever allowing the voltage to the processor to droop at all. We're testing this new circuit in various prototypes now, and if it pans out it will probably show up first in MegaMetrum and then trickle down to TeleMetrum and TeleMini as those products are updated later this year. The new pyro circuit tolerates 0 ohms (dead shorts) on the pyro terminals for as long as the battery can provide current, which is as good as it gets. We think the circuit is clever enough that we'll probably write more about it once we're finished validating it.

Regular expressions are a wonderful tool, but as many other powerful tools they tend to be misused. If I had a penny for everytime I recommended against using regular expressions for parsing HTML fragments . yeah you know what I mean. This time made me think a bit about my own use of regular expressions. Do I ever fall in the trap of misusing regular expressions myself? Looking at my current code base I couldn t find any glaring misuses, if I could only get a list of all the regular expressions in my current project. Regular expressions to the rescue? No, that would probably be quite an horrible adventure. Luckily I have tools to parse Perl: PPI to the rescue: <script src="https://gist.github.com/pmakholm/5354001.js"></script> A few hundred regular expressions. Most of them just matching simple substrings (in some cases case insensitive) or just short hand for testing a handful of equalities in one go. The only zero-width assertions we are using are the word boundary and quantifiers are mostly used on simple character classes like \d, \s, [0-9a-f] and a few anything but this one or two characters ([^>]). Lessons learned: 1) PPI is cool. 2) I really do use regular expressions as I preach.

Today Thursday April 4th I give a talk at Distro-recipes in Paris about Debian Pure Blends. Slides and sources for them.

For one of my classes, the final project is to work on a personal project for four weeks. Since I have never done mobile programming before, I decided I would use this project as a chance to teach myself the basics of Android development. Paul Tagliamonte recently blogged about a Google Summer of Code project idea for a Debian Android application. It was this post that motivated me to create a Debian Android application for my final project. We are only in the middle of week one, but my plan is to have at least a basic BTS and PTS interface done by the end of the project. Then, depending on a few things, I hope to turn it into a Google Summer of Code project or simply continue developing it on my own. As I mentioned, I am only a few days into the project. One of the first hurdles I encountered was interacting with the SOAP interfaces available for the PTS and BTS. There are a few examples available on the wiki, but there are not any for Java. A Google search also failed to return any clear and simple results. As a result, I decided I would create a Python script that would accept requests from the Java Android application via a REST API and pass them on to the SOAP API before returning the result as JSON. Before I could finish writing the script, Paul mentioned that he had already written a similar program a few months ago. I immediately stopped working on my script and began preparing a patch for Paul's program to add support for some missing PTS SOAP functions as well as the entire BTS. After a few hours, I had the ability to query the PTS and BTS via a REST API from Java. While I normally prefer to use VIM for my programming, I decided to follow Google's recommendation and use Eclipse. I was able to follow their guide to get the SDK setup and a simple demo application running. One of the few hurdles I encountered was when I wanted to make web requests. Due to the ability for such requests to stall, you are required to perform them in a separate thread. This only becomes aparant when you try to test your application on an actual device; the emulator will happily run the process in the main thread. Regardless, I was eventually able to modify the demo application to allow me to make requests to my Python REST server and then parse and display the result. Here are some screenshots of the application running. If you have any feature suggestions, questions, or comments, feel free to send me an email (nhandler@debian.org). The source code for the Android application is currently not available, but I plan to put it up in a git repository sometime in the near future. The source code for the Python script that provides a REST API to access the PTS and BTS SOAP interface is available on GitHub.

I'll be traveling to Amsterdam next week for a free software conference. Does anyone have recommendations for restaurants that are vegan-friendly? Natural food stores? I'll be staying very near the Central Station.

On wednesday 7. of November I gave a talk at EPFSUG in Brussels about FreedomBox. EPFSUG is an interest group of Free Software users working inside the European Parliament. The FreedomBox is a project to help non-geeks care about their personal privacy when online, same ways as geeks have practiced for a decade or more. The goal is a small, cheap physical box looking like and operating like an internet gateway or wifi router many are accustomed to nowadays - but with three additions:

• Easy and intuitive to setup and personalize for non-geeks
• Offers routines to help you protect your privacy
• Offers routines to let you help others in need of privacy

"Privacy" is commonly mistaken as "secrecy": Privacy is to keep you in control of your information - you can then use that control to keep secrets from others or to share with others as you like. Talking about personal privacy in the European Parliament can seem a bit of a stretch. It is not a home but a (huge) office space, where it is perhaps less obvious that you should treat some information as personal, or that you are even allowed to do so. Try watch the videos, and if you have questions then please don't hesitate to get in touch with me about them. At the EPFSUG meeting was also a presentation by an emplyee who had succesfully installed and used Free Software at the internal network of the Parliament, but then later told that it wasn't allowed - because the IT staff need to be in control of your computer activities at the place! The head of IT services at the Parliament attended the meeting and gave a short improvised talk at the end, expressing positive interest in behalf of the established IT services at the place towards our grassroots activities - and even praising explicitly EPFSUG as being the ideal place for all EU citizens to ask questions about Free Software in relation to the European Parliament. See for yourself in the video of Giancarlo! Thanks a lot especially to Erik Josefsson for making this event reality! Slides, sources and videos from the event.

Today Sunday November 11th I give a talk at FSCONS in Gothenburg about FreedomBox. FSCONS is an annual scandinavian hacker conference, with a very friendly attitude and atmosphere. The FreedomBox is a project to help non-geeks care about their personal privacy when online, same ways as geeks have practiced for more than a decade. The project is exciting in that is frames a common dream among lots of hackers and therefore sparks new innovation and renewed commitment. The goal is frustrating to tackle, because us hackers most often solve problems close to ourselves (a.k.a. is driven by "an itch to scratch"), and only very few of us are interface designers, which are crucially needed to make things usable for non-geeks. Slides and sources for them.

Some time ago, the QR Code Generator WiFi Access made quite some noise on the mighty Internet. Sure, it is cool to be able to share your WiFi-access with someone by just showing him a QR code he can scan on his phone and the phone will auto-connect to the WiFi. But I get a strange feeling telling someone I do not know my WiFi credentials. No, I do not mean my guests, I know them. I mean that shiny web-service that will generate a QR code for me. The geek in you will now say: So? Open up a terminal, install qrencode, pipe it the string WIFI:S:<SSID>;T:<WPA WEP >;P:<password>;; and you got our QR code . Yeah, that works. But was it one or two semicolons at the end? And was it really just WPA even if my WiFi uses WPA2? Oh and how do I encode that umlaut again? I do not want to remember this. Thus, without too much rumble, may I present you: QiFi the pure JS WiFi QR Code Generator. QiFi is a QR code generator for WiFi access in pure JavaScript. It will generate the QR code on your machine, in your browser, not leaking your precious credentials to anyone (but your guests). Don t trust me? Read the code. Fork the code. Host the code yourself. I hope you will find QiFi at least slightly useful ;-)

2 comment(s) this blog is flattr enabled

Finally.. My bee box has arrived. Initially I had planned to build it myself, but with current time constraints and in light of the fact that the commercial variant is built in a sheltered workshop, I decided to go for a pre-built one. The bee box is designed to give bees a natural habitat and allow them to get through the winter without the need for artificial sugar. Harvest is limited to about 15 kg in a good year as opposed to up to 50 kg in commercial beehives, but this method of beekeeping is less stressful for the bees. The trick is that there are two sections in every bee box; starting in the second year, you open the second section as soon as the bees have started to run out of space. As that's done relatively late in May, the bees will mainly build honey-only non-larvae honeycombs. During harvest, you remove only those secondary honeycombs; as a result, the bees will not need to defend their larvae and thus be a lot more relaxed. As those bees are under supervision of a human with access to oxalic acid, it's trivial to protect those bees against infestations by varroa destructor and to keep them safe form mice during winter. Bees are incredibly important for nature's cycle, so this is a hobby with a lot of positive impact on your local flora, and subsequently fauna. And hey.. free honey!

If you re a Google Reader user, you probably read in one of your subscriptions that Google is pulling the plug on Google Reader. It is yet another demonstration of why putting data in the cloud isn t so much of a nice idea: the service you rely on may well disappear some day, with all the data it contains. Sure Google, in its extreme goodness, allows you to take out the Google Reader data. Or does it?
These are what you ll get from Google Takeout for Reader:

• followers.json, following.json: both files contain similar data, that I suspect correspond to Buzz subscriptions (yet another dead service). Each friends item contains some information about your friend , and a stream identifier for their activity (I guess), as well as a few websites urls. For instance Tim Bray s stream is user/05198174665841271019/state/com.google/broadcast . What the hell do I do with that? Fortunately, he has websites, but not all my friends have. Thankfully, I haven t really been using this feature, so there s almost nothing in these files.
• liked.json, starred.json, shared.json, shared-by-followers.json: all have the same structure, and contain items you liked, starred, shared, or that the people you follow shared (yeah, that file is badly named). Each item contains an url (or so I hope), and the corresponding content (yay). shared-by-followers.json however doesn t contain more than the items the people you follow actively shared: it doesn t contain their feeds (and I m pretty sure I read more from Tim Bray than the two links he shared)
• subscriptions.xml: Essentially, a list of RSS feed urls, with no content ; nothing from Tim Bray here, but now that I think about it, I think I was only following his Buzz feed, so that went away with Buzz without me noticing.

Interestingly, while looking into shared-by-followers.json, I found urls that would correspond to friend streams. For instance, Tim Bray s is http://www.google.com/reader/public/atom/user/05198174665841271019/state/com.google/broadcast. But it s useless: all it displays is permission denied . As for subscriptions, one of the strengths of Google Reader is that it allowed to search though past items, which means a big part of the interesting data is the archived items. But that s not part of the take out . Sure, you have the feed urls, but most RSS feeds contain a limited amount of items, not the entire history of items for the given feed. So, history is more or less lost. Except if I star, like or share all items in all my subscriptions and take out again. So much goodness. It could have been worse, though.

Last week I had another birthday, which was nice. I'm now all mature, and everything. Honest. I received a few surprise gifts from friends and strangers alike, which was pretty good. Other than that I didn't do too much. This weekend I'm going to be using "airbnb" to spend the weekend in Dundee with my partner who is regularly commuting between Edinburgh and Perth/Dundee, to work in various hospitals. With all the commuting time she's not had too much time to explore the actual city, and I've only been there once before so I'm sure it will be a fun weekend. The templer static site generator got a little bit of pimping on LWN.net the other day, thanks to Martin Michlmayr, although embarassingly I seem to have read the article and repeated the content in the conclusion, and duplicated that in my own comment. Ooops. Beyond that I've done little coding recently, although I suspect now that nodejs has had a stable release I might do something interesting soon. I don't want to dwell on the failure of Sim City - because I don't run windows and couldn't have tried it even if I wanted to - but I'm pondering the idea of a persistant grid-space where different items can be placed. I've not tried anything browser-based before, but the popularity of things like minecraft make me wonder if you had an "infinite grid" where folk could store "stuff", and scroll around in a browser you might be able to do interesting things. Starting small, with a 100x100 grid, and some kind of updated play-by-mail turfwars/drug-war like experience should be simple. But then again enthusiasm is easy to generate until you start working out how you'd interface with the server and what kind of client you'd need. Now to enjoy some 21 year old whisky and call it a night..

Partially because of Markdown being Github s markup format of choice, I enjoy writing documents in simple markup formats more and more. There s though one common annoyance with these formats compared to writing plain HTML The Annoyance They need to be rendered (i.e. more or less compiled) before you can view your outpourings rendered, e.g. in the web browser. So the workflow usually is:

1. Saving the current file in your favourite editor
2. Switch to terminal with commandline
3. Cursor up, Enter
4. Switch to your favourite web browser
5. Hit the reload button

Using a Specialized Editor with Live Preview One choice would be to use a specific editor with live rendering. The one I know in Debian (from Wheezy on) is ReText (Debian package retext). It supports Markdown and reStructuredText. But as with most simple GUI editors, I miss there many of the advanced editing commands possible with Emacs. Using Emacs Markdown Mode Then there is the Markdown Mode for Emacs (part of Debian s emacs-goodies-el package), where you can get a preview by pressing C-c C-c p. But for some reason this takes several seconds, opens a new buffer and window with the rendered HTML code and then starts (hardcoded) Firefox (which is not my preferred web browser). And if you do that a second time without closing Firefox first, it won t just reload the file but will open a new tab. You might think that just hitting reload should suffice. But no, the new tab has a different file name, so reload doesn t help. Additionally it may not use my preferred Markdown implementation. Meh. Well, I probably could fix all those issues with Markdown Mode, it s only Emacs Lisp. Heck, the called command is even configurable. But fixing at least four issues to fix one workflow annoyance? Maybe some other time, but not as long there are other nice choices Using inotifywait to Render on Write So everytime you save the currently edited file, you immediately want to rerender the same HTML file from it. This can be easily automated by using Linux inotify kernel subsystem which notices changes to the filesystem, and reports those to applications which ask for it. One such tool is inotifywait which can either output all or just specific events, or just exit if the first requested event occurs. With the latter it s easy to write a while loop on the commandline which regenerates a file after every write access. I use either Pandoc or Asciidoc for that since both generate full HTML pages including header and footer, but you can use that also with Markdown to render just the HTML body. Most browsers render it correctly anyway:

while inotifywait -q -e modify index.md; do pandoc -s -f markdown -t html -o index.html index.md; done
while inotifywait -q -e modify index.txt; do asciidoc index.txt; done
while inotifywait -q -e modify index.md; do markdown index.md > index.html; done

This solution is even editor- and build-system-agnostic (But not operating-system-agnostic.) inotifywait is part of inotify-tools, a useful set of commandline tools to interface with inotify. They re packaged in Debian as inotify-tools, too. Using mdpress for Markdown plus Impress.js based Slides The ruby-written mdpress is a special case of the previous case. It s a commandline tool to convert Markdown into Impress.js based slide shows and it has an option named --automatic which causes it to keep running and automatically update the presentation as soon as changes are made to the Markdown file. mdpress is not yet in Debian, but there s an ITP for it and Impress.js itself recently entered Debian as libjs-impress. Nevertheless, two dependencies (highlight.js, ITP ed, ruby-launchy, ITP ed) are still missing in Debian.

Two papers got published recently. The first one is Bates and Eddelbuettel (2013). It is titled Fast and Elegant Numerical Linear Algebra Using the RcppEigen Package, and provides a pretty thorough introduction to our RcppEigen package which uses Rcpp to provide access to the Eigen C++ template library from GNU R. The paper is out as Volume 50, Issue 5 at the (all electronic, open, and generally awesome) Journal of Statistical Software. A bibtex entry is available. The second paper is Eddelbuettel and Sanderson (2013). This one is titled RcppArmadillo: Accelerating R with high-performance C++ linear algebra and introduces the RcppArmadillo package which brings Conrad Sanderson's Armadillo C++ template library to GNU R by deploying Rcpp. The paper is currently "in press" at Computational Statistics & Data Analysis but the DOI 10.1016/j.csda.2013.02.005 will remain once a volume and issue is assigned by CSDA. Preprints of both papers are available via my papers page, and as vignettes in the corresponding packages. The upcoming Rcpp class in New York will feature Rcpp, RcppArmadillo and RcppEigen. Space is still available.

Following up on using Debian on the WeTab with GNOME Shell I had a look at automatically adjusting the screen orientation when rotating the device. The accelerometer is handled in the asus_laptop module since kernel 3.2, so this shows up in /proc/bus/input/devices:

I: Bus=0019 Vendor=0000 Product=0000 Version=0000
N: Name="Pegatron Lucid Tablet Accelerometer"
P: Phys=pega_accel/input0
S: Sysfs=/devices/platform/asus_laptop/input/input4
U: Uniq=
H: Handlers=event4 js0 
B: PROP=0
B: EV=9
B: ABS=7

Whenever the screen orientation changes the driver emits a udev event. The helper in /lib/udev/accelerometer processes it thanks to /lib/udev/rules.d/61-accelerometer.rules, determines the orientation and adds the ID_INPUT_ACCELEROMETER_ORIENTATION property to the event which can be checked with udevadm monitor --property:

UDEV  [5778.534171] change   /devices/platform/asus_laptop/input/input4 (input)
ABS=7
ACTION=change
DEVPATH=/devices/platform/asus_laptop/input/input4
EV=9
ID_FOR_SEAT=input-platform-asus_laptop
ID_INPUT=1
ID_INPUT_ACCELEROMETER=1
ID_INPUT_ACCELEROMETER_ORIENTATION=right-up
ID_PATH=platform-asus_laptop
ID_PATH_TAG=platform-asus_laptop
MODALIAS=input:b0019v0000p0000e0000-e0,3,kra0,1,2,mlsfw
NAME="Pegatron Lucid Tablet Accelerometer"
PHYS="pega_accel/input0"
PRODUCT=19/0/0/0
PROP=0
SEQNUM=1550
SUBSYSTEM=input
TAGS=:seat:
UDEV_LOG=3
USEC_INITIALIZED=6154288

This is captured by gnome-settings-daemon (>=3.2) that adjusts the screen rotation using xrandr2 accordingly. This can be checked by running gnome-settings-daemon with --debug. The old way of using xinput events is no longer supported. Unfortunately Debian's udev has a minor bug that misdetects the input device so this patch is needed to have the screen orientation changed automatically on the WeTab. This blog is flattr enabled.

StreamResult, covered in my last few blog posts, has panned out pretty well. Until that is, that I sat down to do a serialised version of it. It became fairly clear that the wire protocol can be very simple just one event type that has a bunch of optional fields test ids, routing code, file data, mime-type etc. It is up to the recipient at the far end of a stream to derive semantic meaning, which means that encoding a lot of rules (such as a data packet can have either a test status or file data) into the wire protocol isn t called for. If the wire protocol doesn t have those rules, Python parsers that convert a bytestream into StreamResult API calls will have to manually split packets that have both status() and file() data in them this means it would be impossible to create many legitimate bytestreams via the normal StreamResult API. That seems to be an unnecessary restriction, and thinking about it, having a very simple here is an event about a test run API that carries any information we have and maps down a very simple wire protocol should be about as easy to work with as the current file or status API. Most combinations of file+status parameters is trivially interpretable, but there is one that had no prior definition a test_status with no test id specified. Files with no testid are easily considered as global scope for their source, so perhaps test_status should be treated the same way? [Feedback in comments or email please]. For now I m going to leave the meaning undefined and unconstrained. So I m preparing a change to my patchset for StreamResult to:

• Drop the file() method altogether.
• Add file_bytes, mime_type and eof parameters to status().
• Make the test_id and test_status parameters to status() optional.

This will make the API trivially serialisable (both to JSON or protobufs or whatever, or to the custom binary format I m considering for subunit), and equally trivially parsable, which I think is a good thing.