Europython 2009 was my first Python conference, this being the first year that I’ve been able to use Python professionally for application development. We’d made a decision that if we were to be using Python commercially, we should be active within the Python community, so two of our team travelled from Norway to Birmingham, UK. Prior to Europython 2009 my use of Python had been confined hobby projects, occasional scripts and substantial commercial use with a several industrial-scale SCons builds.

I’ll start out by stating that I came away from the conference a little dissappointed, although I must emphasise in no way cheated, by the experience. I’ve attended a great many professionally and community organized conferences over the years, and I felt in many regards Europython was somewhat further down the quality scale than it should be, given the rising importance of Python. I’m concious that this posting may come across as a litany of complaint, but I feel that some changes could significantly improve the experience for everybody involved. Organisers of such events are forever soliciting feedback, so here goes!

Europython 2009 was a multi-tracked conference with up to six parallel sessions, so its not possible for me to report on even a representative sample of the sessions. Nonetheless, the overview of the not-so-random sample presented below may give you a flavour of the experience. I’m not involved in web development currently so I tended to shy away from the plethora of sessions covering web frameworks. What does interest me are the alternative Python implementatons, IronPython and Jython and uses of Python for scientific computation. Unfortunately, I couldn’t make it to the SCons talk, another interest of mine.

Size, venue and organization

Europython had around 500 delegates in attendance, which is I believe a record. The chosen venue was something of a disappointment. Although the main lecture theatre (The Adrian Bolt Hall) was effective, the other rooms in use were without exception compromised in significant ways. One was quite small with insufficient capacity and little or no air conditioning – although it should be noted that Birmingham was experiencing something of a heatwave at the time. Another featured a concrete pillar between the speaker and his audience – although much better air conditioning in here – and a third had the audience seated on a raked seating arrangement that creaked and groaned with the slightest movement. I wonder how the musicians who usually inhabit the placed manage?

The lunch arrangements were wholly inadequate. Lunch involved collecting a polystyrene plate, bowl and a drink from a refectory upstairs, loading these with food canteen style and then precariously balancing these items (no trays here!) and trooping down a fire escape stairwell back into the corridors between the lecture halls where there was insufficient seating. At one point our Vice President of Product Development, had expressed an interest in attending Europython, having shown a genuine curiosity in the langauge – we’ve been working hard on internal advocacy. At the point at which I found myself having to stand up to eat my lunch standing up in a corridor, having requisitioned a corner of the coffee serving table with my colleague, I was glad he wasn’t here to witness this somewhat unprofessional scenario (Yes, I know its a community event, and not ‘professionally’ organised, but a touch of professionalism can go a long way in the Python advocacy stakes with the right people). I appreciate there were a mitigating circumstances (a broken lift) but the nature of the facilities alone will make me think twice about who I encourage to attend this event in future.

Preparation and planning

Shortly before Europython I’d returned from a conference called EAGE 2009 which had 7000 student and professional delegates in a major European convention centre (RAI in Amsterdam). I’ll confess that this may have done much to anchor my expection levels vis-à-vis conferences immediately prior to Europython. Venue differences and registration cost aside (Europython was 5× cheaper than EAGE) one clear difference was the poor level of preparedness of speakers at Europython compared to EAGE, even though at both conferences speakers were drawn from professional, student and amateur circles. Time and again at Europython speakers hurriedly arrived in the room with little or no time for setup of equipment such as projectors. At this point I must give a note — no, make that a plea — to conference organizers: Please place a printed notice in 144 point text stating the preferred projector resolution on the table or lectern at the front so we can be spared a linear search through the possible resolutions at the beginning of each talk.

Now, I don’t know about you, but on occasions that I’ve been presenting and a private meeting or a conference, especially if it involves a live demo requiring network connectivity, I’m in the room setting up, connecting, authenticating, testing, and re-testing for up to 30 minutes before hand ensuring that everything will run smoothly. Although this doesn’t ensure a professional delivery, it can usually eliminate the tiresome, and stressful for the speaker, configuration during the talk. Its also a common courtesy to your audience to be ready before they are and not keep them waiting. Doing this means you means you’ll get longer to talk, and time for questions. I’m sure most people would agree that time for questions beats staring Display Settings for the umpteenth time.

Some talks dependend on a ‘live’ Internet connection – always a bad idea but in this case it was fatal. Wireless connectivity was intermittent throughout the conference.

Talk quality

I found the quality of the material presented at Europython to be highly variable; it covered the gamut from borderline incompetent to very good indeed. Many of the talks simply did not have sufficient material behind them to justify the length of the time slot they were given. I wonder if fewer parallel tracks with shorter talks would give a better result; audiences would be larger, the pace quicker and delegates would be a able to see a larger proportion of talks, which would help in technology transfer between the different subgroups within the wider Python community.

Keynotes

The keynotes were engaging as one expects. Cory Doctorow gave the predictable but entertaining DRM is evil and copyright unenforceable polemic, in the moral vacuum we have come to expect. Bruce Eckel delivered an entertaining historical overview of language features across C++, Java, C# and Python. Susan Blackmore and Simon Greenish made an impassioned plea for funds for Saving Bletchley Park, although the talk lacked any technical content about the operations or machines there, which given the technical audience was a little disappointing. Sir Tony Hoare rounded off the keynotes with a comparative study of the disciplines of software engineering and computing science, finishing with the not unreasonable prediction that one day “software will be the most reliable component of every product which contains it”, although he didn’t venture to suggest a time-scale on which this might come to pass.

Conclusion

I’m glad I attended. The conference was good value and on the whole informative. The organisers should seriously consider a better venue for next year and raising the standard of talks would make a return visit a more compelling prospect. The easiest way to do this may be to simply reduce the number of talks, or shift more of the content into a more appropriate format such as lightning talks.

I’ve been using an iPhone 3G for about six months now. It’s been an excellent mobile computer and a fair to poor telephone — the main difficultly has been the very low earpiece volume which has made it nigh on impossible to hold a conversation in anything but the quietest environment. The earpiece volume problem has been widely reported. Full volume has just not been enough for me, until now!

It turns out that the culprit is a small piece of transparent plastic which covers the earpiece. I have an after market screen protector and had already removed the earpiece cut-out from that when I applied it. I thought the remaining plastic cover was part of the phone itself, but I assume it must have been left behind when I removed the protective film that Apple ships with the phone, when I first got it.

Carefully peel off this plastic cover — there should be nothing but fresh air between your ear and the gauze in the earpiece recess. I’m now comfortably using the phone on a volume setting of 4 of of 15.

Once I’d discovered the problem and knew what to search for, I discovered that others had already covered the same ground. I wonder how many reported earpiece volume problems and returned phones were affected by this simple problem?

In combination with the iPhone 3.0 software update, I couldn’t be happier.

For a useful re-implementation of BBC BASIC, especially in compiled form, a run-time system is needed to provide services to the running program which cannot be directly provided by the operating system. In the case of our OWL BASIC implementation, we are targeting .NET so we already have a very sophisticated run-time in the shape of the CLR (Common Language Runtime). Nevertheless, additional services specific to the BBC BASIC language are required, many of them based closely on old Acorn hardware from the BBC Micro and RISC OS eras. Fortunately, many of the services required to produce a functioning BBC BASIC system are fairly well abstracted from hardware details, as the many different implementations on quite different underlying hardware, such as BBC BASIC for Windows, have shown.

Many of the services, such as the VDU drivers, used extensively by BBC BASIC are not strictly part of the language; however, a fairly complete implementation is required in order that existing programs can be run successfully with little or no modification.

Its difficult to know where to draw the line when deciding on the degree of backwards compatibility. Our aim is to get the most widely used features to work well. Some of the obscure features may never be implemented. We must also strike a balance between .NET compatibility and good interoperability with other .NET languages and tools, and what I will call Acorn compatibility, for want of a better term.

Implementation details

Our OWL Runtime Library (ORL) is coding in C# and leans heavily on the existing .NET framework. We plan to support common RISCOS SWI calls and a fairly complete VDU system. Much of the work by my brother Ian and myself has to date has focussed on the VDU system, which uses GDI+ through the System.Drawing2D namespace of .NET to do most of the heavy lifting.

Compatibility Testing

The testing approach has been as follows:

1. Find write a simple but interesting BBC BASIC program using graphics commands, such as GCOL, MOVE, PLOT and VDU. Execute this program on Acorn hardware or an emulator to get the graphics output.
2. Convert all graphics commands to their equivalent VDU sequences. For example GCOL 0, 3 becomes VDU 18, 0, 3, and verify that program output is the same
3. Write a test in C# against our OWL Runtime Library using the VDU codes, and very that output is sufficienly similar.
4. Compile and run the original BBC BASIC test program using the OWL BASIC compiler and verify the output

Currently we are pursuing steps 1-3 above as the compiler is not yet ready for step 4. This enables us to work on the run-time library and compiler concurrently.

Example program

The following is a fragment from a larger example program.

REM BBC BASIC using graphics commands
size% = 220
radius% = 250
FOR t% = 1 TO 4
radius -= 30
c% = 3
cntr% = 0
cd% = 0
FOR x2% = 100 TO 450 STEP 20
cntr% += 1
GCOL 0, (c% AND 63)
TINT 2, (t% – 1) * 64
MOVE size, size
MOVE size + (COS(RAD(x2% – 20)) * radius%), size% + (SIN(RAD(x2% – 20)) * radius%)
PLOT 85, size + (COS(RAD(x2%)) * radius%), size% + (SIN(RAD(x2%)) * radius%)
CASE cntr% OF
WHEN 1: cd% = 4
WHEN 4: cd% = -1
WHEN 7: cd% = 16
WHEN 10: cd% = -4
WHEN 13: cd% = 1
WHEN 16: cd% = -16
ENDCASE
c% += cd%
NEXT
NEXT

which can be converted to the equivalent program which uses only VDU commands:

size% = 220
radius% = 250
FOR t% = 1 TO 4
radius -= 30
c% = 3
cntr% = 0
cd% = 0
FOR x2% = 100 TO 450 STEP 20
cntr% += 1
VDU 18,0,(C AND 63)
VDU 23, 17, 2, (T – 1) * 64, 0,0,0,0,0,0
VDU 25, 4, size%; size%;
VDU 25, 4, size% + (COS(RAD(x2% – 20)) * radius%); size% + (SIN(RAD(x2% – 20)) * radius%);
VDU 25, 85, size + (COS(RAD(x2%)) * radius%); size% + (SIN(RAD(x2%)) * radius%);
CASE cntr% OF
WHEN 1: cd% = 4
WHEN 4: cd% = -1
WHEN 7: cd% = 16
WHEN 10: cd% = -4
WHEN 13: cd% = 1
WHEN 16: cd% = -16
ENDCASE
c% += cd%
NEXT
NEXT

These programs both give the following output in Arculator :

Translating the second version above into C# against our run time library, we get the following:

const short size = 220;
int radius = 250;

for (int t = 1; t < 5; ++t)
{
    radius -= 30;
    int c = 3;
    int cntr = 0;
    int cd = 0;

    for (int circle = 100; circle < 450; circle+=20)
    {
        cntr++;
        // TINT action (2) color (t * 64)
        vdu.Enqueue((byte)23, (byte)17, (byte)2, (byte)((t-1) *64));
        vdu.Enqueue((byte)0, (byte)0, (byte)0, (byte)0, (byte)0, (byte)0);

        // GCOL action (0) color (c & 63)
        vdu.Enqueue((byte)18, (byte)0, (byte)(c & 63));

        short mov1x = (short)(size + (Math.Cos((circle - 20) * (Math.PI / 180)) * radius));
        short mov1y = (short)(size + (Math.Sin((circle - 20) * (Math.PI / 180)) * radius));
        short mov2x = (short)(size + (Math.Cos((circle) * (Math.PI / 180)) * radius));
        short mov2y = (short)(size + (Math.Sin((circle) * (Math.PI / 180)) * radius));

        // MOVE
        vdu.Enqueue((byte)25, (byte)4);
        vdu.Enqueue(size, size);

        // MOVE
        vdu.Enqueue((byte)25, (byte)4);
        vdu.Enqueue(mov1x, mov1y);

        // PLOT triangle fill
        vdu.Enqueue((byte)25, (byte)85);
        vdu.Enqueue(mov2x, mov2y);

        switch (cntr)
        {
            case 1:
                            cd = 4;
                            break;
            case 4:
                            cd = -1;
                            break;
            case 7:
                            cd = 16;
                            break;
            case 10:
                            cd = -4;
                            break;
            case 13:
                            cd = 1;
                            break;
            case 16:
                            cd = -16;
                            break;
        }
        c += cd;
    }
}

which renders the following display on Windows Vista,

The Windows version is of higher quality because we have double the vertical resolution since Windows is used square pixels each half the size of the original rectangular pixels used in this screen mode on RISCOS. This is an example of a difference between historical implementations and our new implementation which we do not intend to address.

However, its possible to improve quality even further using the facilities of GDI+. We have implemented a new code (in the reserved for future expansion block) VDU 23, 28, n the purpose of which is to control rendering quality. In the current version we have implemented three quality levels. With the highest quality level, we get the following output:

which was simply never possible with the original Acorn BBC BASIC.