Colin's Journal: A place for thoughts about politics, software, and daily life.
I’ve updated my XSLT templates to now include <pre> tags around code samples. This should make the code examples mentioned throughout the SimpleTAL pages render correctly in IE 5.5, and possibly other browsers that don’t implement style sheets fully.
Every few months the issue of harmonising taxation across the EU crops up, and when ever it does it usually gets denounced pretty quickly from most sides. It’s one of those subjects that no-one seems to be in favour of, and yet it still keeps coming back.
I’ve finally found someone putting forward a good reason as to why tax harmonisation may be a good thing, and it has nothing to do with the usual reason given, that of unfair tax competition. Written by the Edward Troup, the head of tax strategy at Simmons & Simmons, this article in the FT explains the problems with the current situation.
Although there is freedom of movement across the EU most people end up a resident of one country, and if they move to another country they become residents there, and so pay income tax there. Most people don’t change residency from one country to another very often, and there are rules in place in each country that determine when you class as a resident for tax purposes. If you are a company however it’s very common to have different parts of you in different EU countries on a permanent basis. It’s also not clear, especially if your customers are also in multiple EU states, where you earn the profit that countries wish to tax. The EU has a common market, so in theory it shouldn’t matter where you are in the EU, you can conduct business everywhere. The European Court has the task of ensuring that this fundamental right of access to the free market is upheld, and so (borrowing from the article) when Germany says that you can not pay interest owed on loans in an another country out of earnings from Germany, it acts and limits this ruling to only countries outside the EU.
I’m a strong supporter of the common market. It is an important part of securing the peaceful future of Europe. It gives us more choices, in things to purchase, places to work and live, and brings a greater variety to life. So when the issue of tax harmonisation comes up again I’m going try and find out exactly what kind of tax harmonisation is being proposed, because it might turn out that I don’t appose it after all.
It’s been at the back of my mind to change how local variables are implemented in SimpleTAL/ES for a while now. The implementation used in 2.0 goes back to my first ever version of SimpleTAL, and was a bit of a hack. I’ve changed it to work the way it should have done from the beginning, and I’m now seeing a 5% improvement on the basic performance test and 10% on the deeply nested test.
I’ll included this in the next release, whenever that turns out to be.
I’ve just upload the new version of SimpleTAL. This is the version that brings with it significant performance improvements thanks to the refactoring. It also brings some changes to the API, so if you are using an earlier version please take a look at the notes on migrating from an older version. Feedback, as always, is much appreciated.
For anyone reading this and wondering just what SimpleTAL is, here’s a quick description. SimpleTAL is a Python library that provides an easy to use template language for HTML (and XML) documents. By using SimpleTAL it becomes easy to separate the look and feel of a page from it’s content, which makes it very useful for powering interactive web pages. SimpleTAL is a standalone piece of software, so you can use it to produce HTML or XML content from any Python program.
This weblog is produced using SimpleTAL, and is also the reason that I wrote it in first place.
There’s a wonderful little restaurant near us called Citron, which for those living in Toronto who haven’t found it yet, is at 813 Queen Street West. We were there last night (Pear Salad, Coconut Pumpkin Stew, and Melted Chocolate Truffle Cake now that you ask) and discovered that it is going to be temporarily closing for renovation.
The good news is that they will only be closed for a couple of weeks starting shortly after Valentines day, and of course we’ll have to go back to see what the new decor is like…
There’s a small debate on the use of English on the continent going on thanks to Bjørn Stærk, with Tobias Schwarz providing some dialogue. It’s hard as a native English speaker, who knows no other languages, to comment on this issue with any level of authority. One aspect I feel I can comment on is mentioned by Tobias, and that’s the use of English as the language between people who speak two different languages (in this case Germans and the French using English as a common language).
The important aspect to this is not it’s evident benefit to the likes of me, but that it pushes forward the ideal of a Europe that can identify with it’s self. A Europe that can speak a common language, along with it’s common currency, is a Europe full of people more likely to get along with one another. In this sense any common choice of language would be fine, that it’s English just brings the bonus of being able to communicate with large chunks of the rest of the world.
I can definitely agree with Bjørn in welcoming the opportunity to read the views of Continentals in English. I’ve tried to track down European weblogs that are written in English, and I’ve not had much luck. The most promising list I found does not break up the weblogs by language, and seems to feature many broken links. Maybe I should start a list myself…
I’m nearly done with the refactoring of SimpleTAL for version 2.0. All of the unit test cases that I have now pass, both for HTML and XML templates, and I’ve even added a few more to cover some commands that were not tested before. As part of final testing I updated my weblog software to use the new version, and found some interesting relics.
This weblog has archives going back to my first ever post, back long before my current weblog software was written. I started out with a few python scripts that would grab HTML files and merge them together looking for special tags in a template file; it was very crude but it mostly worked. The current system stores all my posts as XML, has TAL templates, and some cunning logic in between. When I moved to this new system I had to port over all the old posts to the new format if I wanted to keep a consistent history. The cut-over didn’t happen cleanly however, and there were a small number of posts which had strange XML source files.
The files had the content body of the posting encapsulated in a CDATA section, and were also escaped using entity references. In SimpleTAL 1.x the posting body would be sent through an SGML parser prior to inclusion in the template, and that parser would expand the entity references back into normal characters. In SimpleTAL 2.0 content structure is not sent through a parser (if you need to use TAL in the structure then you can create a compiled template before placing it into the context), and so the entity references would be included as literal text. A few search-and-replace commands have sorted those postings out, and it looks like the new version of SimpleTAL works reasonably well with my weblog system.
I have some documentation and clean-up work to do prior to releasing SimpleTAL 2.0, but it shouldn’t take me long to do. The performance of the new engine is pretty good, anywhere between 1.5X and 7X faster than the current version (depending on the type of template). The top performance is a little lower (~70 templates/sec) than I achieved with my prototype version, but I had expected that there would be some sort of drop once the character encoding conversion and other must have features were added.
Yesterday I thought I would take a look at the performance of SimpleTAL, and look to see if there were any easy ways of improving it. I took a small (one screen full) template consisting of lots of ordinary text, a repeat command, and a couple of content commands, and timed SimpleTAL expanding it 200 times. The result was around 5 templates/sec.
I had an idea of pre-parsing the template and turning it into a series of events (start tag, data, and end tag). I implemented this fairly quickly, and found that performance improved up to the 11 templates/sec mark. I know, however, that Zope’s TAL engine can go significantly faster than this, so I started looking at it again and trying to work out how I could improve things significantly.
The current SimpleTAL implementation uses OO methodology fairly heavily. This means that for each tag in the template an object is created, and at least one handler object (often more). The tag is then passed to each handler which does various things to it based on the evaluated expressions coming back from the simpleTALES module. The result is that for a given run of the template, even with the HTML/XML parsing done before hand, there is a significant amount of object creation (expensive), a large number of method calls rather than variable access (expensive) and text manipulation/parsing.
The Zope way of getting around this is to parse the template into an inter-mediate byte code. This byte code is then used by an interpreter to generate the template, with very little in the way of object creation. I’m now re-factoring SimpleTAL in a similar way to see how much improvement I can get, and so far it’s looking promising. I’m still along way from finishing, but I have content and repeat working well enough to run my performance template, and the result is now around 90 templates/sec – a near 95% improvement! The unfortunate side effect though is that the code is harder to understand because it’s data structure driven instead of object driven, which will make maintaining the code a lot harder.
We were on our way to the airport, on a long and indirect series of flights back home for Christmas, when I first saw our neighbourhood wind turbine. The fact that up to then we had failed to notice a 94 meter tall wind turbine protruding out of the city scape indicates how far away from it we live. Upon return to Toronto I have spent the odd moment looking out over our deck to see whether or not we can see it from our flat, and thought several times that I maybe could see it, hiding behind a tree in the distance.
When I awoke this morning and glanced out over the deck I noticed, in the near distance, the turbine happily rotating away. It is indeed behind a tree some distance away, but quite visible when it’s turning. Apparently it cost approximately C$1.2M to build (it’s not clear if any maintenance is included in that figure) and will generate 1,800 MWh of electricity a year, which at market rates (now fixed by the government at 4.3c/kWh for most consumers) could bring in $77K per year.
As such it’s only a symbolic and public awareness development, but it seems that when a large site is developed the cost of wind generated electricity is pretty comparable to a new coal station and close to that or a modern gas fired station (see the excellent British wind energy site and this rather more independent FT article). Wind energy is only part of the answer (apparently only 10% of the UK electricities needs can be met this way before reliability becomes an issue), but it is still nice to have our own neighbourhood turbine, and even nicer to see how quickly wind power generation is being built.
Email: colin at owlfish.com