The declarative style of programming is not to everybody's taste. There are many who simply prefer the overtly operational nature of machine-oriented programs—for them, there is more psychological satisfaction to be had in exercising active control over the 'moving parts' of a computation than there is in the seemingly more passive business of declaring what the computation is to achieve. This preference may persist whatever claims are made or substantiated about the virtues of (present-day) logic programming.
I bet you thought that quote was going to be about functional programming until the last two words?
The quote is from Christopher Hogger's 1990 book Essentials of Logic Programming¹ [1This book was my university text on logic programming at Imperial College and Chris Hogger gave the lectures.]. Although the importance of logic programming has declined over the nearly twenty years since he wrote that passage the difference between declarative and imperative programming and the preference of some for one or the other is very much still with us.
He is right in talking about the fun aspects of programming—this is a big draw for many developers, but not all. I think many who prefer imperative programming simply have more trust in their solutions when they can see the moving parts and can fiddle with them. Getting to see and play with the ballistics of a program makes all sorts of things readily understandable that are hidden in declarative systems.
That doesn't mean that declarative programming isn't fun and it doesn't mean that we shouldn't trust our solutions even though we don't know how the answer is derived. Many of us are very happy to use compilers we barely comprehend, database engines which resolve problems for us that many don't even know exist and languages which abstract away not only the underlying machine but nearly all of the layers above that too.
Given the normal history of these things I think there'll be a resurgence in logic programming interest sometime in the next ten to fifteen years, as seems to be the repeated rise then decline and then rise again of programming paradigms—just look at object orientation and functional programming for two examples.
The decline of logic programming itself is certainly a shame. Logic programming has many useful things to teach us, for example, it allows us to reason about looping constructs and conditionals in a unified manner—something very important in Test Driven Development because it allows us to understand exactly what we get for our tests and how to test more of the program whilst writing fewer tests.
A day trip to have lunch at a restaurant featuring tables in one of the rivers.
I deliberately over exposed the photos of Freyja playing in the river as an experiment to see if it made them feel more summer-y.
I just upgraded my laptop to Saucy Salamander, and just about the only thing that broke was Skype, which had been pretty flaky already. I think that Skype isn't particularly happy with a 64 bit runtime, even the multi-architecture version is just the 32 bit code wrapped in some way.
What I wanted to do was to be try to run it inside the Lucid 32 bit runtime as I figured that's what they've been targetting and ideally I'd also have a very clean install with nothing else in there. I've been playing around with the tools
debootstrap for some other work, and have written mkschroot as a way to make the building of these environments totally reproducible. I hoped getting Skype to run was going to be easy, and it turned out to be trivial.
You'll need to install a few packages:
sudo apt-get install python-setuptools schroot debootstrap
python-setuptools is just so you can install
mkschroot and the other two packages are needed to get the
sudo easy_install mkschroot
You may want to substitute that with a
pip command and maybe a virtual environment too, but if you know about that sort of thing you don't need me to tell you the commands.
Below is the configuration file:
There are a couple of things you may need to change:
rootitem is where
mkschrootwill create the
schroot. On my system the total environment size (including Skype installation) is 438MB.
sourcepoints to a download mirror. A list of Ubuntu mirrors can be found here, or you can look in your
/etc/apt/sources.listfile to find what you're using already.
http-proxyshould point to your apt-cacher. If you don't have one then remove that line. For quickest results also make sure that your
/etc/apt/apt.confcontains the right apt-cacher configuration.
You need to create a local file with a copy of this configuration file with appropriate changes for your environment in order to use it.
schrootand installing Skype
Create the lucid runtime using this command (
skype.json is the file name you saved the configuration file to):
The first time you run this it will need to ask for
sudo rights in order to create the configuration file for you in
If you ever want to update to newer lucid packages in the
schroot (for example, when security patches are released) you can simply re-run this command.
schroot that is created will automatically mount your home directory and have a user with the same permissions as you, so if you already have a Skype configuration on your machine it will be picked up by the version inside the
Now to install Skype. Download the 10.04 32 bit version. At the time of writing I got
schroot -c skype -u root -- dpkg -i Downloads/skype-ubuntu-lucid_220.127.116.11-1_i386.deb
The required packages that Skype needs should already be installed.
To run Skype start it from a command line like this:
schroot -c skype -p /usr/bin/skype &
Doing this allowed Skype to run without segfaulting.
schroot also ensured that the mic and webcam were properly available for Skype to use and because
schroot also mounted my home directory for me inside the
chroot jail Skype had access to my existing configuration and history etc.
Now I just have to keep using it to see if it's more stable in its preferred environment than it was when running under raring…
Django Async is an asynchronous execution queue for Django with proper database transaction management
Building a database backed task queue is a fairly trivial thing, but getting the database transactions exactly right is no simple matter.
Get Django Async with pip from pypi:
pip install django-async
Installation is very simple, just add the
async application to your Django applications in
settings.py. You also really want to use the transaction middleware (see below) and a proper transactional database (like PostgreSQL).
To run a job asynchronously just use the
from async import schedule schedule('my.function', args=(1, 2, 3), kwargs=dict(key='value'))
Tasks can be run by executing the management command
python manage.py flush_queue
See below for more details.
schedule(function, args = None, kwargs = None, run_after= None, meta = None, priority = 5)
Returns a Job instance that is used to record the task in the database. The job has a method
execute which will attempt to run the job. Don't do this directly until you've fully understood how transactions are handled
deschedule(function, args = None, kwargs = None)
Marks all jobs in the queue that match the given function _and arguments_ as executed.
De-scheduling does not guarantee that the de-scheduled tasks will never run unless the de-scheduling is done within a task executed in the job queue. This is because the task might have already started executing within the queue whilst it is de-scheduled from outside the queue.
info = health()
dict containing basic information about the queue which can be used for monitoring.
Command line interaction with Django Async is through Django's management commands.
To run jobs in the queue you can use the command
python manage.py flush_queue
flush_queue will run once through the jobs that are scheduled to run at that time, but will exit early if any job throws an exception. Normally you would use it from an external script that simply keeps re-running the command.
while :; do ( python manage.py flush_queue && sleep 10 ) ; done
Jobs are executed in priority order first (higher numbers execute earlier), then by the scheduled time (unscheduled jobs will go last, but of course only jobs whose scheduled time has arrived will run) and finally by their ID order (which should be the order they were added). A failed task will be re-scheduled for later execution.
Queue health is done via the queue_health command:
python management.py queue_health
Database transactions are hard to get right, and unfortunately Django doesn't make them much easier. Firstly, you really want to be using a proper transactional database system.
Django has two major flaws when it comes to transaction handling:
The first problem is not going to get fixed in Django, but the second can be handled by putting the middleware in the right place — that is, as early as possible. The only middleware that should run before the transaction middleware is any whose functionality relies on it being first.
Within the async task execution each task is executed decorated by
django.db.transaction.commit_on_success. This means that you cannot execute a task directly from within a page request if you are using the transaction middleware (this is due to problem number one above).
The latest release was tagged some time ago now.
Just a couple of small API clean ups this time. The build changes are part of the
|Linux & Mac|
svn co http://svn.felspar.com/public/fost-hello/tags/4.13.09.44781 fost-hello cd fost-hello Boost/build hello/compile dist/bin/hello-world-d
On the Mac you will need to set DYLD_LIBRARY_PATH before running hello-world-d
export DYLD_LIBRARY_PATH=dist/lib dist/bin/hello-world-d
svn co http://svn.felspar.com/public/fost-hello/tags/4.13.09.44781 fost-hello cd fost-hello Boost\build hello\compile dist\bin\hello-world-gd
Everything is available through our Subversion repository. Below are the locations for the tagged releases for Fost 4.13.09.44781 components.