Home
Nick [entries|archive|friends|userinfo]
Nick

[ website | gagravarr.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Playing BBC HD and ITV HD on a DVBWorld DW2104 [Jun. 12th, 2010|06:07 pm]
Having got fed up with the ropey reception on Freeview, due to ongoing problems with my local transmitter (engineering works, fires, too windy for helicopters, the list of excuses is impressive...), I decided to pick up a DVB-S adapter for my mythtv box.

The snag with having a very small, low power mythtv machine is that all the adapters need to be USB, which does limit the choices of linux compatible DVB-S adapters. However, a bit of browsing of the Linux TV wiki and some patience with ebay searches paid off, and I was able to pick up a DVBWorld HD 2104.

With the help of this site, I was able to get the firmware for it, and it was quickly up and running. I followed this guide to get things running, which largely worked for the SD channels.

However, despite the scan of the Astra 28.2E and Eurobird 1 satellites showing me both BBC HD and ITV HD, I was unable to get either working with MythTV or mplayer. Trying in mplayer I saw:
nick@minimyth:/dev/dvb/adapter1$ mplayer dvb://2@"BBC HD"
MPlayer UNKNOWN-4.4.3 (C) 2000-2010 MPlayer Team
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing dvb://2@BBC HD.
dvb_tune Freq: 10847000
Cache fill: 18.85% (1581056 bytes)   
TS file format detected.
VIDEO MPEG2(pid=5500) AUDIO MPA(pid=5502) NO SUBS (yet)!  PROGRAM N. 0

But nothing played. Using szap myself to capture a bit of the stream myself, and trying with that, I got sound but no picture:
mplayer /tmp/HD
MPlayer UNKNOWN-4.4.3 (C) 2000-2010 MPlayer Team
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /tmp/HD.
Cache fill:  0.00% (0 bytes)   
TS file format detected.
VIDEO MPEG2(pid=5500) AUDIO MPA(pid=5502) NO SUBS (yet)!  PROGRAM N. 0
MPEG: FATAL: EOF while searching for sequence header.
Video: Cannot read properties.
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...


The key thing to spot here is that mplayer thinks it has MPEG2 video. However, both BBC HD and ITV HD are H264 when broadcast over Freesat! After some googling, it turns out that there's something up with how the dvb-s scan program outputs the channel lines. The easy option is to tell mplayer to use a workaround for this, by passing in an extra option to mplayer - -demuxer lavf

Thus, the easy way to play BBC HD on the DVBWorld card (my 2nd DVB adapter), the command is:
mplayer -demuxer lavf dvb://2@"BBC HD"

This largely seems to work fine, though the sound sometimes drifts which needs a quit and restart to work.

However, it is possible to also hack channels.conf to contain the correct details to "just work(TM)". This seems a bit black magic, but you need to run mplayer with "-identify", pick the PMT_PID (via trial and error...), and add this into the channels.conf video entry with a plus. Thus, my channels.conf entries for the HD freesat channels are:
BBC HD:10847:v:0:22000:5500+259:5502:6940
ITV1 HD:10832:h:0:22000:2362+288:2369:10000
ITV1 HD:10935:v:0:22000:513+289:641:3851

By adding in the correct PMT PIDs, I can then just do mplayer dvb://2@"BBC HD" and it picks the correct video and starts playing! Still has sound drifts though, which I think might be slightly worse than with lavf but I've yet to double-blind test...

Next up, time to make MythTV believe the stream is H264 too!
linkpost comment

Mentoring and Incubation at the Apache Software Foundation [May. 25th, 2010|03:54 pm]
I'd like to give my personal view on the Apache Incubator, and how I see my role as a mentor of an incubating project with that. This post explains my views, and while it ought to chime nicely with official policy, there might be the odd error, and so this isn't official foundation policy. But first, a bit of history on how I ended up mentoring a project.


I've been using Apache software for a very long time now, and I'd guess I first played with the webserver back in something like 1996 or 1997, which seems a very long time ago.... I'd say I first properly got involved in Apache with POI when I started with Torchbox. A check of the archives shows I first started contributing patches back in 2003. I stayed around on the POI list after that, contributing more patches and helping out with user questions, and then in 2005 everyone had got fed up of committing my patches without changes, and I was granted committership.

In 2006, I attended my first ApacheCon, and had a great time whilst learning lots. In late 2006, I was elected to the Jakarta PMC, and discovered a whole new world as I learnt about PMCs, the board, how the ASF works and so on. This didn't put me off, and in May 2007 I helped POI leave the Jakarta umbrella, becoming PMC chair. At the 2007 ApacheCon, I'd gone to lots of foundation related talks, and began to learn in detail about "The Apache Way", which is partly how I ended up as the new POI chair. Roll forward to 2009 and I found myself giving talks on "The Apache Way", having in the mean time made member. Late last year I also joined the new Apache Community Development project, helping out with mentoring, outreach and so on.


It's been quite a long journey, from my first involements in apache, through my first commits and on to today. It has taken me a long time to learn about "The Apache Way", to really understand what it means, and get to a position where I'm able to try to help others to learn about it. It's really great to be able to stand up in front of an audience, and talk to them about open source, open development, and apache-style open development, and see that moment when someone gets it, understands part of why it's so powerful. Well, I say stand in front, but quite often it could just be sat in a pub, or even on the grass in a circle, enjoying the Irish sunshine!

Since starting at Alfresco, I've also become involved in the Apache Incubator, and I'm currently a mentor of the Apache Chemistry incubating project. Having explained how I got here, I'd like to look at what I think this role of mentor involves, and using Chemistry as an example.


Firstly, what isn't it? Well, I'd say a mentor isn't a committer. Sure, a mentor can also be a committer, and it's great when that's the case. However, I'd see those as two distinct roles, and you may sometimes need to switch hats. It's great if mentors can commit code, since it helps ensure that if there is any pain from the incubation process, one of the mentors quickly feels it too, but I don't think it's in any way required.

What is in the role of mentor then? I'd say the most important, and over-arching role is to teach the podling (incubating project) about The Apache Way. You can't do this in one go though (see above - it took me at least 4 years to get to the point that I was happy enough with my understanding that I could pass it on!), but you need to be trying to pass it on as and when you can. Partly this means watching the mailing lists, and offering insight and advice when things happen. Or don't happen. Possibly especially when the don't happen...

Within the incubator, various things need to happen whilst the project is there, and others before graduation can occur. As a mentor, you need to help everyone understand why they need to do something, as well as helping them do it. For example, the requirement that as much as possible of the project's communications should be on-list, and off-list things should be relayed back. It's no good just saying "no", you need to explain why, explain what gets missed if you don't, explain the benefits of doing it The Apache Way. With Chemistry, the big test for this was with in-person meetup in Munich back in March. Many of the committers were there, but certainly not all. I explained on-list beforehand why it was important to keep the list updated, then spoke again about it at the meeting. During and after the meeting, everyone who couldn't make it seemed very happy with how it had worked out, and how their views had been included. We also now have a record of those discussions to check back on if an architecture question surfaces again in future. Overall, it seemed to work well!

Three things that often cause issues within the incubator are IP clearance, releases and new committers. With all of these, the podling needs to do some work, and then the incubator PMC needs to sign off on this. Firstly in this then, the role of the mentor is to help the podling do the thing right, pointing that at documentation as needed, advising them on their process, and reviewing what they've done. When everything is fine, you then need to put on your IPMC hat, and approve it. Next, you need to prod your friends within the IPMC to ensure that a quorum approves the action, so the podling isn't stuck waiting. Finally, you need to ensure that the podling understands why and how to do it, because after graduation they'll need to do the same thing again, but without the oversight, so they need to be able to get it right themselves :)

Where does that leave us for defining the role of the mentor? Overall, you're there to help the project learn the apache way, both in what to do and why they should be doing that. You should be helping them when problems come up, and trying to spot problems and head them off before they develop. You should be helping the project to do the steps needed to run and graduate (clearance, releases etc), giving them guidance, advice and voting. You should be there to answer questions. If it all works, then the closer graduation gets, the less you'll need to do, as the closer the project will be to running itself happily in The Apache Way!


One thing I should probably point out at this juncture is about in-person vs remote mentoring. You sign up to mentor the whole podling project (while ComDev do have a formal 1:1 mentoring program, the incubator is about mentoring the project), so much of that mentoring needs to be remote, using mailing lists. However, with Chemistry, I found it very helpful to also have a chance to meet and advice many of the project committers in person. Much as the ASF is a global organisation with proceedures and a way of working that handles everyone being disparate and remote, some parts of teaching the Apache Way work best in person. That's partly why I've helped set up the Local Mentors Program (aka take a new contributor out for a drink to help explain the whole thing to them). With that in mind, I'm tempted to recommend that where possible, at least one of the mentors meets at least some of the committers at least once, probably ideally at an Apache BarCamp or conference.


There are many different ways to run a project, be that an open source project or a closed one. I'm a big believer that open development is the right way for many projects, but I'm also fairly well aware of the cases where it may not be the best. This isn't a post about project management and methodologies, though buy me a beer and I'll happily talk at length on the subject! Instead, I want to finish off with my view on why the Apache Incubator exists.

Within the ASF, all projects should be running to The Apache Way. Now, the Apache Way doesn't cover everything, just certain key areas, so each project is free to make their own decisions on how to do many things. It's part of the beauty of the ASF that different projects do try out different things, and share what works well, even if sometimes this leads to a week of discussion on members@.... However, most projects outside of the ASF don't run to the Apache Way. So, for a project to join the ASF, we need to ensure that the licensing is correct, the IP is properly cleared, and that the project runs itself The Apache Way. That's where the Apache Incubator steps in.

So, my view of the incubator is that it's somewhere to do the IP clearance, it's somewhere to sort out licensing and dependencies, but mostly it's a place to learn the Apache Way. Projects come in, they learn, and then the choose to either tweak themselves to fit the Apache Way, or they say "no thanks, that's not for us" and leave to go on their own way. Seems simple enough, doesn't it? :)
linkpost comment

Who drives, directs and supports projects within the Apache Software Foundation [May. 25th, 2010|02:30 pm]
Following on from my previous post on CLAs and Release Votes, I thought I'd do another one on the Apache Software Foundation. This time, it's looking at different roles in directing and supporting a project, and how the ASF deals with corporate contributions.

Note - this is a personal view. While I am a member of and PMC chair within the ASF, it's my view, not an official foundation statement. It's based on lots of discussions, talks and mailing list posts, but please do shout if you think I've got something wrong...


When looking at an Apache project, people will often make distinctions between four kinds of people:

  • Users - anyone who just uses the software, without really interacting with the project beyond that

  • Contributors - anyone who helps out with answering questions, contributing simple patches or tests cases, often but not always on the project mailing lists

  • Committers - people able to commit changes to SVN, both their own changes, and those coming in from the community from Contributors

  • PMC Members - those people tasked with keeping the project on-track, and directed by the ASF board to look after the project on behalf of everyone


It's often said that there is a pyramid of people within an Apache project. At the bottom are very large numbers of users, above them a smaller number of contributors powering the project, then a smaller number of committers making changes to the code, then a smaller number of PMC members overseeing it. If you can get yourself to a The Apache Way talk somewhere (ApacheCon, Apache BarCamp etc), you'll hear a lot more on this, but the important thing is that a project's success is driven by this large base.


Two common questions about an Apache project are: who drives and directs the project, and who keeps it going?

The answer to the 2nd is easy, but perhaps not the one you may think. It's the contributors! Without all the contributors out there, answering the questions of others, helping write examples, providing test cases and the odd patch, evangelising, your project won't grow and maintain itself. This is why you see some projects (eg httpd) rewarding those people who contribute documentation and examples, and not just those who contribute code. Almost all new committers come from the pool of contributors. Most users will hit a problem at some point, and it's through the work of the contributors in blog posts, mailing list answers, documentation or examples that help them solve their issue and carry on. Of course, on every project there are committers doing the same thing, but in most cases they started doing all that before as contributors, and it's the work done as contributors that keeps the project going!


Now, what about who drives the project? On most projects, at least some of the people, and possibly almost all of them will be there in their role as employees of a company. How should committers (and pmc members) handle the need to wear two hats, those of an employee and as a committer to the project?

Within the project, new features are added by whoever does the work. This might seem obvious, but it's worth remembering that there's no magic coding fairy secretly committing while we all sleep - all new features and bug fixes come from someone spending time at a keyboard working on them. In some cases, that's someone working on it in their own time. More often though, it's someone working on company time, usually on a project that is important to their employer.

So, we can see that on many projects, the new features in the project will be those which matter to the companies providing the employees to work on them. But, does that mean that those companies get to set the direction of the project? In some foundations, the answer would be yes, but at Apache, the answer is a little more complex. It's maybe, but only if the community agrees!

How does this work then? Generally, people should announce in advance what they're working on, and seek feedback on it. That could mean opening a JIRA for the new feature, describing it, then later attaching the patch to it. It could be a quick post to the mailing list, followed by a later commit. For a very uncontentious change, it could even be committing the patch and describing it in the commit message, assuming that your project allows commit-then-review for that sort of change. Generally though, for a company-driven change, a committer will announce what the new feature they're planning to work on.

Once the new feature has been described, what then? It could be that everyone feels this is a useful addition, and +1's it. That's the ideal case - your company's needs closely match those of everyone else, and everyone's happy! Much more commonly, people will say things like "that isn't what I'd choose to work on first, but it's useful, so go for it" or "I wouldn't use that, and wouldn't code it, but I can see the value for others, so go for it". These would be more of a +0, hinting that while the change is good for the project, it isn't something that others care deeply about (which is perhaps why no-one has done it before...) In all these cases though, the community have agreed that the change that your employeer needs fits with their needs too.

In a few cases, you'll get someone saying "that's a stupid idea, you should be working on the thing that I need instead!". That's usually the point that you need someone else to step in (so as not to start a flame war), and explain that Apache is a participatory meritocracy. If there's a feature you want, you have three choices - code it yourself, pay someone to code it for you, or inspire someone to code it for you. No-one's under any obligation to write something for you, everything's done by people who want to do so!

Now, what about the case when you describe a new feature that you want to work on (either because your employer wants you to, or even just you want to in your own time), and the community isn't keen? That might be because it will have wide ranging changes, or introduce new dependencies, or will work using a new methodology, or half a dozen other things. Well, firstly, the thing to do is to hold fire on your changes. Instead, you need to make your case, probably on the mailing list, and explain why you feel your change is the right one to do. With any luck, people will suggest alternate ways of doing things without the problems, and you can get the new feature you need whilst also having the community support you.

What happens though if after that discussion, you haven't convinced the community? Generally, that's the time to try it anyway, but not on the main codebase! Let everyone know you're trying it out, and do so on a branch, or in an external SCM, depending on the scope of the change. Try to let the community see what you're up to. Then, when you're done, come back and make your case again. Hopefully now things will be easier, because you can point to real code, and say things like "there had been concern that the new configuration system would slow down the core, but if you try it with this benchmark, you'll see it's actually 5% faster". It could be that when people see the new code, they'll agree, you have a quick vote, commit the change, and everyone's happy :)

And if even having seen the code, the community doesn't agree? Well, sorry, but you'll need to maintain a vendor fork at this point. After all, your company needs it, and the community doesn't want it, so it'll be up to you to maintain. Next time, try to make the case to the community better...

In general though, the project moves in the direction of those with the time to code. When those people are working on company time, the project will tend to move in the direction that that company wants it to. However, that's only the case while the community agrees with the direction, and if the company tries to push something the community doesn't want, that all changes.

Apache - powered by the people who do the work, but directed for and by the community!
linkpost comment

CLAs and Release Votes within the Apache Software Foundation [May. 23rd, 2010|04:21 pm]
There has been a fair bit of discussion of late, both within the Apache Software Foundation and outside of it, about whether some of the processes and proceedures are a help or a hindrance. With this in mind, I thought I'd write something about how I see things.

Note - this is a personal view. While I am a member of and PMC chair within the ASF, it's my view, not an official foundation statement. It's based on lots of discussions, talks and mailing list posts, but please do shout if you think I've got something wrong...


There are three main things that people seem to moan about around the ASF. The first I won't really dwell on, that of "why can't I use ${latest_tool_of_the_moment}. As the hard-worked ASF infrastructure crew will happily tell you, you can use anything that can be supported, maintained, bug fixed and generally looked after 24/7 by volunteers scattered around the globe. If you want something new, be prepared to help look after it!

The other two main things seem to be around CLAs, and release voting. These two offer some very important protections for everyone - users, developers, committers and the ASF. The need for these are documented at http://www.apache.org/dev/, but as there's a lot to read there, I'll try to give my view on why they matter.

Firstly, a question. What are two of the easiest ways to close down an open source project?

The answers, I feel, are to either sue the release manager, or to sue whoever holds the source code.


For the first, think how long your project would last if the release manager was sued for a very large sum of money, and anyone else who might consider signing up was threatened with a similar lawsuit too? With no releases, one key community member out of action through a lawsuit, and everyone else worried, the answer is alas not all that long. Personally, I think it's great that I'm both allowed (and encouraged!) to work on open source at work, whilst also well enough paid that I can afford to spend part of my free time coding, mentoring etc within open source. However, it does also mean I have enough to loose... And having been an Apache release manager in the past (for Apache POI), I'm very glad that the ASF protected me. But how?

If you do a release of some open source code on your own, and someone has it in for your project, then you could be at risk. One of the key reasons for founding the ASF was to provide protection for this. What you want, should something bad like this to ever happen, is for some ASF lawyers to turn up in court and say "stop suing this poor contributor, sue us if you're going to sue anyone", and have the judge agree. For that to work, the release needs to have been done by the ASF. That's where the release votes and rules come in.

What you're after, therefore, is for the ASF to stand up and say "that's our release". The ASF wants lots of good open source software to be out there and being used, so wants to support your release, but tat the same time, doesn't want to take needless risks. The release requirements are therefore basically that enough people who provide oversight have OK'd the release, and that as far as is possible, all the code in the release is allowed to be. Therefore, we see the requirement that 3 PMC members have +1'd the vote, the source has appropriate headers, notice files and licenses are clear, the build is open and repeatable, and dependencies are all ok. (The PMC, or project management committee, is the ASF board's eyes and ears on the project). Largely above and beyond that, what each project wants to do in terms of releases is up to them. Things like betas, release candidates and numbering all lies within the project, based on how the community wishes things to work.


Now, on to the CLAs, or Contributor License Agreements. There are two of these, the iCLA (for individuals), and the CCLA (for companies). These are actually fairly simple documents, and all relate to the core Apache License v2.0. For an individual, it is basically "I understand what it is to release software under the apache license, and what rights I wave to do so, and I'm happy and able to do so". For a company, it's basically "I understand what it is to release software under the apache license, and what rights I wave to do so, and I'm happy for my employees to do so". These provide the foundation, and the software users (the community) with the protection that someone can't turn around a year later and say "I know I said I was contributing under the apache licenese, but I've changed my mind, and now I'm going to sue you".

Many other foundations are happy to accept contributions under their licenses (be that the ASL, GPL or whatever) without requiring that those making significant contributions formally state (via a CLA) that they understand the license, and are OK with their contributions being under it. However, within the ASF, we like to be very sure on these things (which is part of what allows our software to be used so widely without lots of legal checks being required first). As such, we ask people to file a CLA before they contribute, just to confirm they're happy with how their contributions will be used.


So, we see two key parts of Apache policy, the release process (checks and votes), and the CLAs, are both there to protect the project and the community. They happen to protect the ASF too, but they're mostly about protecting everyone!

As an aside, if much of this is new to you, I can't recommend enough attending a "The Apache Way" talk somewhere. You'll find them at all Apache Cons, at all Apache Bar Camps, and many other things, and are a great way to learn about things like this, both what the proceedures are, and why they exist. It's much of how I learnt these things!
linkpost comment

Compiling for your N900 on debian [Jan. 12th, 2010|07:34 pm]
I've just got my Nokia N900, and while the phone-phone synchronisation pulled my calendar entries and contacts over from my N95 just fine, it didn't do the sms's.

Since it runs linux, the fact that the official software doesn't support it isn't the end of the world. Handily, someone's written a small sms importer program that reads in the sms's from the S60 pc-suite csv export, and loads them onto the phone.

Only snag is the pre-built version didn't support long sms's, so I needed to patch and re-compile. That means needing an arm cross-compiler, the build environment etc.


Handily, that's fairly easy to setup. The best guide I found was http://maemo-sdk.garage.maemo.org/install-debian.html, which got me almost all the way there.

One thing to note is that you need to install the "Nokia Binaries" if you want to do much development, which includes various key system components and dev libraries that aren't open source. http://wiki.forum.nokia.com/index.php/Maemo_5_SDK_installation_for_beginners has what I found to be a slightly easier guide to follow on that.


Now I'm about ready to try my newly compiled smsimporter. A couple of commands that I've found to be helpful are:
  • sb2 -eR apt-get install [pkg] - installs the given arm native package in the build root

  • maemo-sdk enter devel - enter a shell suitable for compiling for native arm


Hopefully I'll be knocking up a few more little bits of code on the weekend :)
linkpost comment

Nearly everything runs linux [Jan. 12th, 2010|07:23 pm]
My new phone runs Linux, which is great. So, I thought I'd do a quick roundup of all my computing devices, and see how close I am to all Linux:

  • Desktop - Debian Stable

  • New work laptop - Ubuntu Karmic

  • Dell Mini laptop - Ubuntu Karmic (netbook edition)

  • Media PC - Ubuntu Karmic (mythbuntu edition)

  • Nokia N900 - Maemo Linux

  • 2nd wireless access point - tomato (linux)

  • Apple TV - stripped down OSX, so Unix but not Linux

  • ADSL + wireless router - not sure, but not apparently linux

  • Nintendo Wii - not linux


I think that's about it for computing devices, so not bad all in all. When 802.11n adsl routers that run Linux come down in price a bit more, I'll ditch the current cheap'n'chearful (but with a few annoying bugs) no-name router I have for one of them, and I'll almost be there!
linkpost comment

New phone! [Jan. 12th, 2010|07:19 pm]
At long last, vodafone finally had a N900 in stock, so I have a new phone!

In general, it's proving really good. It runs linux, which is making everything so much easier (no need to hack it like you do with S60 - just apt-get install whatever you want!)

So far, I've enabled SSH, installed several extra bits and pieces, and imported almost everything over from my N95. Will shortly attempt to import the SMS's too....
linkpost comment

Now I remember why I try to avoid coding in c.... [Sep. 5th, 2009|07:12 pm]
At work, in common with most IT firms, we have a need to securely store a lot of passwords. Quite a while ago we settled on PWMan as the tool to do this with. It has a nice ncurses front end, and uses gpg encrypted xml files under the hood, so there's no worries about getting your data out if you ever want to go to anything else. After posting a few patches, several of us were given commit access, and all was good.

Roll forward to last week, and I'm now the only active maintainer of the project. We haven't had any problems with pwman for a while, but there are one or two features that people have asked for, and I figured it might be good to try to implement a few of them. The biggest thing was search (filtering results on the screen has been in there for an age, but not finding all entries anywhere in the tree). As pwman is written in c (using ncurses and libxml2 directly), there isn't anyone else at work who was comfortable making the changes, so it was either I do them or no-one would. I had a couple of hours spare, and I figured that might be enough. My hunch was 20-30 minutes were it in python, double it as I hadn't worked on the codebase lately, apply my usual "it's java not python, double it" multiplier, and hope that c and java coding times are similar. That gave me 2 hours, which seemed fine.

How wrong was I...

We're now at about 6 hours of coding, and search is almost but not quite fully implemented. Firstly I wrote the search algorithm and structures as I would in python, perl or java, only to remember at the last moment that auto-extending arrays and vanilla c don't mix, and I didn't want to have to pull in something like APR as a dependency at this stage. So, back to the drawing board, and I had to re-write the whole thing (algorithm, data structures etc) using linked lists.

Then, when I compiled and ran the program normally, and did a search it segfaulted. Compiled it without the optimisations, and with the -g flag, and ran it under gdb. No segfault, seemed to be fine. I was very bemused. Then I ran it a bit longer under gdb, and eventually managed to trigger the segfault.

At this point, I was once again reminded of why I don't like c. The bug was a simple, schoolboy error - I'd added a couple of new fields to a structure, but I'd forgotten to null one of them. Not something you need to worry about with java, python or perl, but as any C hacker will tell you, very very important there. I'd remembered for almost all of my new fields, forgotten one, and thus as soon as the memory was re-used for another similar structure (more common at the higher optimisation levels), it all went to pot :(

So, I did a full review of all the structure creating code, spotted a few other places that might need it too and added it explicitly, then all seemed fine. I do now know a lot more about using gdb than I used to, but it's all taken longer than I'd hoped for, and so I still haven't managed to find the time to write the rest of the UI. Hopefully I'll get a chance soon, and then pwman will have nice and shiny search. In the mean time, I'm reminded why lots of people end up deciding that porting non-performance critical code from c to python is worth doing when they want to add moderately complicated features....
linkpost comment

Fringe 2009 [Sep. 3rd, 2009|11:23 pm]
It's that time of year again, and so I find myself up in Edinburgh, binging on culture! As we're up for the last weekend, my reviews won't be all that helpful for other fringe goers (what with being posted just as the festival ends...), but they're rather handy for us in future years, and also when chatting to people later in the year about what we saw. So, reviews follow!

Thursday



My first show of the year was Austen's Women at Assembly George Street. This delighful mid morning show was a one woman series of monologues. The script took various parts of Jane Austen's work, as both character and narrater, exploring different ideas of what it is to be a women, and what she should do. Each character was presented very differently, and I think really enhanced the work. The result was an enthralling mix of different scenes, from scatty to serious, dry to passionate, and all engaging. A pleasant 4*

Next up was another Assembly George Street show, Party. This followed an evening as 5 passionate but clueless students endevoured to found their own political party. It was filled with great comedic moments as the students displayed their ineptitude, ignorance and misguided passion, whilst also holding up a mirror to all political parties, both new and old. Funny, cringeworthy, cutting, and certainly a 4*.

Finally for Thursday was Words with A.L. Kennedy. This started rather slowly, and made me initially wonder about the good reviews I'd seen, and whether I should leave.... However, after 10 minutes she'd got into her stride, and all was good! Her show was part autobiography, part explanation for her passion for words, and part exposition in how we think and talk. It did loose its way once or twice, but when working was excellent, both fun and insightful. Overall, 4*.

Friday



Shakespear for Breakfast is now a regular for us, since it's always good fun, is early when not that much else is on, and comes with free croissants! This year didn't dissapoint, with a slicker story than last year, based around Midsummer Nights Dream, and the usual mix of real shakespeare and fun new stuff woven together. What's more, we got to witness Alex being propositioned by a fairy, which is always good for a laugh! Solid 4*

Our only free show was Carl Sagan is my god, and Richard Feyman too. This lunchtime comedy was hosted by Robin Ince, and was in the basement of a pub on the Royal Mile (most of the cheap/free venues seem to be pubs/clubs). Robin himself gave us about 30 minutes of material, and was generally both funny and interesting. His choice of guests wasn't quite so good, but that does vary between days, and it looks like we caught a less good set. Still, it was fun, and proved that free needn't be rubbish. 3*

Next up was some dance / physical theatre in the form of Crime of the Century. This was dealing with the issue of knife crime in London, how teenages are drawn into it, and how it affects them. It was powerful and moving, but I couldn't help feeling it would've been even better if they'd concentrated a little more on either the dance, or the story. As it was, I felt the two parts were both a little underdeveloped, which was a shame. Overall, well worth seeing, a really good insight into youth knife crime, and a 4*.

Carrying on with the dance theme was Still Breathing. This reminded me a lot of the excellent dance show we saw last year, who's name escapes me... It was an all male cast, something like 12 dancers, very energetic and impressive. The music and lighting leant towards electronic and dystopian, and the dancing itself was technically very impressive, almost mesmorising. Most styles got at least a mention, but it was mostly towards energetic modern, a mix of solo through formation. Very good, a 5*

Moving on from dance, we then had some comedy in the form of Sammy J (1999). We all really enjoyed Sammy J and the Forrest of Dreams last year, so were keen to experience his new show. This year we were treated to a slightly surreal journey through his penultimate year of school, following the ups and downs of a musical nerd. We're not sure quite how much of it was autobiographical, but it could be quite a bit...! His one man delivery style worked really well, and we all had a great time listening to the surreal but heartwarming story. Once again well worth a 5*.

Finally we had Dan Antopoloski, doing his standup routine. We normally don't go in for late night comedy, but Alex had seen him before, so we made an exception. Half of his material was really good, but the rest drifted between meh and unfunny. When it worked, it worked well though, so certainly someone to keep an eye out for in future years. Overall, 3*

Saturday



We began our day at Assembly George Street with Sylvia Plath - Three Women. This was three partly interwoven stories about motherhood, being a women, life and sanity. It sometimes seemed to lack a structure, though possibly those bits were the actual life and words of Sylvia Plath... When it worked, it was very powerful and though provoking, and well acted. 4*

A big change in style for our 2nd show of the day, The Early Edition. As ever, Marcus Brigstock and friends disected and satirised the days papers, in a part News Quiz, part Mock The Week, part rant way. The guests were largely great, and it was good fun (if slightly worrying, as ever, when you hear just what is in all the papers....). Wouldn't have minded seeing it another day if we'd been up for long enough! 4*

A British Subject charts the fairly recently ended story of a British/Pakistani dual national stuck on death row for half his life. It follows a Daily Mirror journalist and his wife as he starts to cover the story, and they are so moved by his plight that they take up his cause. It's a harrowing story, and pretty much only Prince Charles comes out looking good from it, which is an unusual situation! The acting is brilliant, with a cutting script that really has you feeling like you're stood there too in the jail, even with the understated minimal props. An excellent story, excellently performed. Well worth its 5*.

Carrying on the high scoring day came Circa. This dance show covered most styles, and really pushed the boundaries of what the human body can do. The balances and acrobatics were breathtaking, as they flung themselves joined across the floor, perched one atop another at improbable angles, walked over each other in stileto heals, or performed amazing feats with hula rings. An amazing show of what can be done, beautifully performed. I'd happy have watched it a second time in awe. 5*

Finally was Year of the horse, a very surreal show of the work of the Herald's editorial cartoonist. As his haunting cartoons were shown, the increasingly bizare stories that went with them were read out, to a jarring musical soundtrack. It was a compelling, and quite different show, and you could largely forgive some of his more ranty lefty conspiracy pieces because of what he could do when he really hit the mark. 4*

Sunday



I missed our first planned show, so I kicked off the day with the Rap Guide to Evolution. This was by Baba Brinkman, who did the Rap Canterbury Tales a few years ago, and was a biologist approved rap show on evolution, in hommage to Charles Darwin. Most of the songs really hit their mark, and I even learnt a few interesting things too! Not sure it'd be enough to convince a creationist of their error, though dragging one along could potentially be good fun to watch... The songs cover the topic well, and the rap related parts worked too, giving a solid 4* performance.

Beachy Head deals with the aftermath of one man's suicide at Beachy Head. His wife struggles to understand and come to terms with it, whilst a pathologist tries to explain, and two film makers try to document it despite their secret. There's heavy use of video and lighting, which produces a very powerful show. If they'd fixed a couple of plot wholes, and tweaked a few bits of characterisation, it could've been one of the best shows on the fringe. As it is, it seems they spent a tiny bit too long on the lighting and video, which while they give a stunning show, aren't everything. So, ends up a good 4*.

Stefan Golaszewski is a Widower is Stefan Golaszewski's second show (we caught his first last year and really enjoyed it). Again, it's a one man passionate account of part of a life, with a lot of wit and humour. This time he plays an old man, looking back over his time with the love his life. It's a funny, heart-warming, moving performance, largely just him with the odd prop. However, the story doesn't quite hold your attention quite as well as last year, and the lighter elements didn't always fit quite as well. Good, but not quite as good as last time, a 4*.

We finished with a £5; fringe show, Robin Ince - Bleeding Heart Liberal. We'd been impressed enough with Robin Ince from his free luncthime show, so decided to get an hour of just him. Being his last show of the fringe, it did often wander a long way off path, but on the whole the deviations were very funny and interesting. He's not quite got the anger or drive of someone like Mark Steel or Marcus Brigstock, but his geekier side makes him a little more like a non-musical Mitch Ben. It was funny and interesting though, certainly a 4*.

Monday



We started the day with some music in the form of Brel at Breakfast. This was roughly 50% Jacque Brel songs, in a mixture of English and French, along with a number of other pieces. The singer was good, though from the between-song discussions clearly has a lot of issues... His two pianists were great fun, and good players too. Some of the song juxtapositions were a little surreal, but overall the hour passed pleasingly with good music well done, with the odd funny moment. The pastries before were very nice too! Solid 4*.

Then for a quick trip over the mound for Shappi Khorsandi (A Beginners Guide to Acting English). This was supposed to be just a book reading, but was actually part book reading, part interesting reminiscance, and part standup material. It made for an excellent fun lunchtime session, even if sometimes random or meandering. Shame we couldn't get tickets for her main show, but this was a great show in its own right too. 4*

The Other Side was a powerful set of intertwined tales in Israel and Palestine, using a minimal but well used set. It followed families on both sides through tragedy and loss, and finally a sort of understanding through phone calls and meetings across the side. The staging used the few props (mostly the metal door frames) well to create simple but powerful effects, and only once or twice overused them. However, the occasional welsh sounding liltings in many of the accents kept distracting you and pulling you out, which was a shame. Powerful, and almost worked brilliantly, 4*.

Odyssey was a one man attempted to the whole of Homer's great story in an hour, complete with some actions and sound effects. The slightly silly premise actually worked very well, and the story was well covered and engaging. Probably also not too far off how much of it would've been performed/told in ancient greece! Good fun and engaging, 4*.

News Review were back for their 30th year, and continued with their musical look into the news, both this year's and the last 30 years. Some things were great, some flopped totally, but on the whole good, and better than last year. 4*

Last year we saw one Red Room show from Belt Up, and wished we'd known in time to see more. This year, they were back again, with a partly burnt out room in C Soco, and on top form as ever. Our first show was The Tartuffe, which was supposed to be their best of last year and back even better. The audience begins sat on sofas, matresses etc in the squat in C Soco, as the company mingles and chats in character. Then the play begins, as an aragent and deranged company attempts and fails to tell the story of Tartuffe, through squabbling, mutterings, incompetance and mime. All throughout, the cast have completely smashed the 4th wall, sitting with the audience muttering about the other actors, getting audience members to play bit parts, cast-audience water fights and the rest! It's an absolutely brilliant show, in a very immersive and engaging experience. Crazy, veering wildly and filled with random references and in parts only barely recognisable, but utterlly brilliant none the less! Certainly my pick of the fringe by far,
a stunning 5*.

Our final show was another Belt Up show in the Soco squat, this time The Trial. It begins with the audience blindfolded and lead into the space one at a time, whilst the disorientating soundtrack plays, and the cast runs about. From then you join with the cast in a dark, smoke filled, random and confusing tale through Kafka's terrifying play. You're constantly moving thoughout the space to follow the action, struggling to understand as the lead character struggles with the boombing voices, smoke, light, dark confusion. However, I kind of feel they over did the immersive disorientating experience a tiny bit, and toning it down a little bit would've still kept the excellent atmosphere and effect, but allowed the story a little bit more room. Almost there, but in the end not quite as good as Tartuffe, so 4*.
linkpost comment

PostGreSQL xml extensions (pgxml / xml2) now much easier on windows [Jul. 30th, 2009|03:23 pm]
At work, we make quite heavy use of the contrib xml2 xml parsing functions in PostGreSQL (just a shame they're not in 8.4 as standard....). On linux, getting the module compiled in is fairly easy, and has been since 8.0. On windows, it used to be a bit of a faff.

I upgraded the first of our windows machines to postgresql 8.3 the other day, and start out with the usual process of part building under mingw / msys, then building just the module with mingw (see this for more details). The good news is that this method seems to work fine still. What's more, installing MinGW and MSYS has got quite a lot easier in the last couple of years :)

The even better news is that the binary windows downloads of postgresql 8.3 seem to come with the pgxml / xml2 contrib functions pre-built :)

For anyone still on PostGreSQL 8.0 or 8.1 on windows, you can download pre-built pgxml modules from http://encore.torchbox.com/pgxml/.
linkpost comment

navigation
[ viewing | most recent entries ]
[ go | earlier ]