I like developing using Python. I like its program structure, its performance and the way it supports coroutines. What I don’t like is distributing Python programs. Python installations from one computer to the next are notoriously different from one another. I may have two seemingly similar Linux computers running the same version of Python and a program may run well on one and may not find a dependency on another.
While the language and run-time system is well-defined, they way in which search-paths are set up and resolved does not seem to be. (See http://stackoverflow.com/questions/25715039/python-interplay-between-lib-site-packages-site-py-and-lib-site-py). Virtualenv aims to help, but the contract between Python and “the system” seems not well-defined. The result for me has that it has been difficult to produce shrink-wrapped programs for distribution from Python source.
The types of programs I’ve developed usually have dependencies on locally-developed SWIG-generated shared-libraries (.so), so my case may not be typical. (However, it is interesting :-) I’ve looked at using Cython to compile Python modules, and it works well for building an extension module in C, or for extending a C program with Python.
However, if your aim is software construction using Python for the distribution of a complete application, then Cython seems lacking.
Nuitka (http://nuitka.net) is a “Python Compiler.” Nuitka can compile just one or a few modules, or it can compile an entire Python program. It takes a higher-level view of the job of compiling an entire project.
I’ve shared a little “HOW-TO” article over at Github regarding implementing User-Authentication for a Twisted web-site. The target for this audience is someone who needs Form-based (login page) User-Authentication for a Twisted web-site. It uses Jinja2 for templating. The example shows a recipe for guarding pages, rather than defining an entire authentication framework.
The most relevant “prior art” I had found on this topic was from 2004, and referenced long defunct software components. I thought it was time for someone to do an update.
Apple’s Yosemite has received a lot of attention for the addition of Bluetooth MIDI over Bluetooth LE. What has gotten less attention are the updates to Network Midi. Here are a few things I have learned.
Network Midi has been included in Mac OSX since about 2004. It allows computers to find one another over the LAN via Bonjour and to join each others’ MIDI sessions. The protocol spoken by Network MIDI is defined in a IETF doc: RFC 6295, which was ratified in 2011. An earlier version of this document (RFC 4695) was ratified in 2006. It seems that this protocol standard has had a long and very slow evolution.
Apple’s implementation of Network MIDI has been sometimes criticized as “buggy.” I myself had been able to isolate a bug in the implementation of the protocol. I was delighted to find that Yosemite not only fixes that one specific bug, but seems to include a Network MIDI stack with entirely different characteristics from the previous versions.
- Receive latency is much lower overall.
- An erroneous delta timestamp format has been fixed (comex algorithm).
- Realtime commands are sent (active sense, MTC).
I’ll keep this post updated as I learn more.
On November 21 I was pleased to participate in a meetup entitled Real-Time Streaming Data. The organizer of this meetup assembles a wide variety of presenters and topics under the umbrella topic of “Large-Scale Production Engineering.” Chris (the organizer) does a remarkable job of keeping a pipeline of interesting talks coming. I’m particularly interested in the January talk humorously entitled “Whatever happened to IPV6?”