Plumbing Life's Depths

In one of those cases where you ask a question, don't get an answer, then spend far longer than you intended playing with the problem, I've just added a Pipe mechanism to Fussy (why to fussy, you ask? Well because that's where I wanted to use it).  Basically it provides a small wrapper around subprocess that lets you easily setup chains of subprocesses, files, generators, etc and have them iterate reading/writing until they are all closed.

You can read samples in the documentation.  It's still pretty rough, and there's lots of things still to be worked out, but oh well, it seems like a fun interface sketch for now.

I just upgraded our last machine to Kubuntu 12.04 (the laptop has been running it since a beta).  In place update with about 2 minutes offline... Debian/Ubuntu/Kubuntu really is amazing that way.

The new Kubuntu is pretty much just like the old Kubuntu.  It works, is very pretty, but just gets out of the way and lets me work.  There still appear to be some issues with disk i/o on encrypted disks (an slocate database update can max out your CPU inside the kernel so that it effectively hangs the machine until it finishes).  Haven't come up with a solution for that yet.  The KDE Telepathy mechanisms still seem a bit broken (e.g. try setting up an IRC connection on Freenode), but Pidgin works fine.

Not much else to say about Kubuntu 12.04.  A solid, practical desktop that looks great, comes configured fairly sensibly, has every feature you'd want (and more really), works on all the hardware I have, and has access to all the software I need.

http://readthedocs.org/docs/2daypython/

and you can branch and alter/adapt the source (in restructured text) as you wish using:

bzr branch lp:2daypython

One thing that seemed like a good idea from the presentation tonight is the idea of using a real-life example of how to break down a task into steps as a motivational introduction.  I may add that.  I'd also like to break the lesson plan page into multiple pages and let a presentation layer tweak handle making smooth transitions.

Oh, and I apparently lost my "interactively worked examples" from the presentation when I lost my laptop hard-drive, so I suppose we should re-do those and add them to the respository.

The revised title (2DayPython instead of Software Carpentry Python Session) is both to avoid conflicts with Software Carpentry's official "branding", and because I'd likely structure the sessions differently if I were to teach it again, i.e. it would actually be 2 days of just Python, so we could have far more time and get farther through the core material.

Since this was a bit of a pain to track down, here's the process, on an Ubuntu Server 12.04 machine, to create many ALSA dummy devices:

$ cat /etc/modprobe.d/alsa-dummy.conf 
options snd-dummy enable=1,1,1,1,1,1,1,1,1,1,1,1 pcm_devs=4,4,4,4,4,4,4,4,4,4,4,4 fake_buffer=0,0,0,0,0,0,0,0,0,0,0,0
$ modprobe snd-dummy

That sample creates 48 dummy devices (on 12 cards), though that's likely more than you'll ever need.  The fake_buffer array means they should all have a real internal buffer.  The "enable" array is specifying how many cards to create.  The pcm_devs array specifies how many pcm devices to have on each card.

Note that dummy devices do not seem to work as the target of dmix.  You can use a file plugin to send the audio sent to the dummy device into a file or pipe.

[Update] The values are all arrays...

As mentioned a while ago, I was looking for a firmware packager that would allow for "user uploads a signed bundle" style upgrades for hardware devices.  Esky is similar (even a similar on-disk layout), but focused on cross-platform and distutils-based "application" setup.  Fussy is intended for "core of a system" setups, where the entire user interface and functionality of a custom piece of hardware is delivered through the "firmware" package.

The package is up on PyPI, LaunchPad and ReadTheDocs now (though the docs are still being built on RTD). There's still lots to be done, but the basic outline is there.

Query came up on PyOpenGL-dev this morning about how to handle GLchar pointer arguments.  These are binary-specified arguments, they are human-readable text most of the time, ascii source-code and identifiers, that kind of thing, but nothing about GLchar pointer requires that they be ascii.  They are 8-bit character strings (that's what GLchar pointer means).

But it looks awkward for Python 3 users to specify b'identifier' and b'#shader-code...' so they are likely going to expect to be able to pass unicode values in.  That, I think, we can support without any real problems, but then users are going to be using Unicode to store and process their ASCII 8-bit shaders...

The question is what to produce when we return something which is a GLchar pointer.  Most of the time, these are ASCII human-readable strings, some of the time they are 8-bit character pointers with binary data.  It seems whichever way we go, some corner cases will pop up where a user tries to compare, search or otherwise interact with a byte-string and a unicode object and blows up because they can't be auto-converted.

So, is best practice to raise errors on ingest (refuse to guess, require explicit conversion to 8-bit)? Return unicode even if the data might be binary (make it convenient for the user in the common case of not caring)?  Allow unicode ingest, but produce 8-bit output (introduce some corner cases that are likely to blow up "elsewhere" in the code)? Or do we have to explicitly code every single GLchar pointer entry point looking at whether that entry point is dealing with text or arbitrary data (and hoping that it always does the same)?

My sinking feeling is that the only way to provide both a "natural" interface and a safe/sane one will be the last of those.  I'd rather go for the first or third option, just to make it simple and easy to explain.  Python 3 experts care to weigh in?