Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Friday, 11 May 2012

#efdhack2012 26th May 2012

This one's a little different. Python West Midlands is hosting a hackday to kick off a new open source project for a very interesting little charity called Evidence for Development(EfD). EfD wants to help people make better decisions about aid projects – at local and national level – by putting real data about the real situation in the hands of the people making the decisions.

If you want to know if your aid programme is making a difference to the right people then you need to model the economy of your target village or district, before and after. Makes sense; simple science right? Problem is you can' afford a bunch of western econometricians crawling all over the place (cost too much, takes too long) and anyway their cash-based economic models don't work that well in a place where cash is only a small part of the economy (grow your own; harvest wild food; get paid in kind or cash or both for day labour; trade crops, labour or other goods; etc, etc). So EfD developed simple economic models that work in this environment, that can be learned and applied by locally trained people and that, are built to run on laptops. No reliance on big foundations' data centres.

Last year EfD, in partnership with Chancellor College of the University of Malawi and The University of  Wolverhampton developed a Python/MySQLapp to model local economies that is already in use in several countries in Southern Africa.

This year the challenge is bigger – to build software that can model national and international economies. The model exists and works (it has a great track record of predicting famine effects from annual summary surveys of rural economies). But the only current implementations are proprietary, ill-supported and not extensible. Smells like open source spirit.

So for this hackday we're going to have with us the two developers who led the IHM development last year (from Chancellor College in Zomba, Malawi) and the developers of the modeling methodologies from EfD (from Barnes and Surrey – exotic eh?). We'll have a pretty completeMySQL database schema to work on and we hope to finish the day with a simple demo scenario that downloads reference data about a geographical area (a livelihood zone) produces a spreadsheet template to capture information about that livelihood zone (what they grow there, what they eat, how they make a living) runs some local completeness reports and uploads the captured data for merging (with other livelihood zone surveys) to allow analysis of a national survey.

I'm not a software developer, can I still contribute?

Yes! Absolutely. There are a number of jobs that can be contributed without writing any code. We would really appreciate the support of contributors who can build a web presence for these projects, write user and developer documentation, help spread the word and any number of jobs! If you're keen to help out, there will definitely be a place for you.

When:

10:30 onwards, 26th May 2012. Please sign up here.

Where:

Thyme Software, Coventry University Technology Park, Puma Way, Coventry, CV1 2TT [map]

Posted via email from snim2's posterous

Wednesday, 5 May 2010

Introducing server processes

Much of the recent activity on the python-csp code base has to do with finding useful ways to debug networks of CSP processes. The dynamic analysis of CSP programs has a long history, dating back to Hoare's original work. I'll post more about that another time, but this post details a small change to the core library that enables debugging to run effectively. 

A common idiom in CSP-style code is to have many processes in a process network (connected via channels, or other guards) which all loop forever. If the program needs to be terminated, that is usually done via channel poisoning. I call these processes server processes, because they continually serve values to their output channels (if they have any).

In fact, all of the processes in the csp.builtins library are server processes, and python-csp has quite a few of these. It has most of the processes from the JCSP "plugNplay" package and a distinct process for every built-in unary or binary operator in Python. So, for example, the csp.builtins.Plus processes reads two pieces of data from its input channels, and sends their addition to an output channel. One possible implementation of csp.builtins.Plus would be this:

@process def Plus(inchan1, inchan2, outchan):     while True:         outchan.write(inchan1.read() + inchan2.read()

In reality, this isn't quite how csp.builtins.Plus is implemented, as there are quite a few unary and binary operators in Python, so we make use of metaprogramming to generate most of these builtin processes.

The problem with server processes is that if you want your debugger to deduce useful information about your program then at some point your code needs to terminate so that the debugger can compute a call graph, or some other structure, from which other useful information can be gathered. Ideally, it would also be nice if the debugger could deduce that your server processes are intending to run indefinitely, even though it actually terminates when the debugger executes them.

To achieve this effect, python-csp now has a special class for creating server processes called CSPServer, and a new decorator, called @forever. These work exactly like the usual CSPProcess and @process types that have been included in python-csp since its inception. Apart from using the new constructors, the only change you need to make in your code to use @forever or CSPServer is that a server process should be a generator and, usually, it should yield at the end of each iteration of its internal loop.

As an example, if we were to reimplement csp.builtins.Plus with the new constructors, we can do this in two ways, firstly with the decorator (which is the recommended method) and secondly using the CSPServer class directly. In the code below I am using two other processes from csp.builtinsGenerate which sends an infinite supply of integers down its output channel and Printer which prints anything it reads from its input channel to STDOUT (by default, you can customise this to use any other file type). So now, Plus could be implemented thus:

@forever def Plus(inchan1, inchan2, outchan):     while True:         outchan.write(inchan1.read() + inchan2.read())         yield ... # Silly way to print even numbers in1, in2, out = Channel(), Channel(), Channel() Generate(in1) & Generate(in2) & Plus(in1, in2, out) & Printer(out)

If we decide not to use decorators, then the code is essentially the same, we just need to remember to construct any Plus processes with the CSPServer class:

@forever def Plus(inchan1, inchan2, outchan):     while True:         outchan.write(inchan1.read() + inchan2.read())         yield ... # Silly way to print even numbers in1, in2, out = Channel(), Channel(), Channel() Generate(in1) & Generate(in2) & CSPServer(Plus, in1, in2, out) & Printer(out)

Posted via web from python-csp

Saturday, 13 September 2008

Leeds University at PyConUK 2008

Tony Jenkins and Nick Efford from Leeds University gave an excellent talk at PyConUK on their experiences of teaching Python as an introductory programming language which seems to be very similar to our efforts at Coventry. Tony and Nick managed to raise pass rates, inspire some fantastic coursework, have fun and generally kick ass. Great news for Python and even better news for a future generation of students. You can see some more of their work in ITALICS.