Toggle between if/endif in Vim with %

In vi/vim is it possible to match if/endif in a non-standard language so you can toggle between them using %? I know that this feature is usually reserved for parentheses and braces but this particular language doesn't use them.

I can see, from reading around, that you can set regions via ":syntax region" but I'm not sure if that applies to this case.

Installing Snow Leopard

I installed Snow Leopard and everything went okay. As usual the first thing that I do on an OS is to check the perl version:

$ perl -v

This is perl, v5.10.0 built for darwin-thread-multi-2level

Good start.

A few things that didn't work straight away were Apache (dav_svn_module was the culprit, probably the wrong version), make (I needed to install the developer tools separately) and Adblock in Safari (only works in the 32 version).

Spreadsheet::ParseExcel on github

It had previously been on Google Code but I didn't find it conducive to collaboration. Hopefully github will be better. I already like the clean look and feel.

One of the default options on github is to have a wiki page which I thought would be useful for the Pod documentation if it were converted to the Textile format. Then I thought "I have a module for that", Pod::Simple::Wiki.

So I imported Pod::Simple::Wiki to github, cloned it, followed my own instructions, and within a hour I had a pod2wiki Textile converter (with tests).

Data::Dumper + Perltidy

I use Data::Dumper a lot when debugging applications that return complex data structures. However I'm not always happy with the pretty printing that Data::Dumper provides and I often find myself copying he structure into Emacs and running perltidy against it.

As such I thought that it would be nice to have a Data::Dumper::Perltidy module that would do both steps in one go. I didn't find such a module on CPAN so I wrote one.

John.
--

Tuesday January 20, 2009

07:25 PM

Perl and the Art of Motorcycle Navigation

A lot of people use Spreadsheet::WriteExcel I think. At least I get a lot of emails related to it. At the same time I don't generally get an insight into what people use the module for. There are some obvious tasks that I can imagine such as invoices or inventories or balance sheets and the email addresses of the correspondents suggest a heavy usage among financial companies. The occasional example Excel file that I receive isn't usually very exciting, not least of all when viewed in a hex editor. As such Spreadsheet::WriteExcel is used for the mundane reporting we all have to do occasionally. (Apart from me that is. In the eight years with my current company I've only used Spreadsheet::WriteExcel once and that was in the last six months. So much for eating your own dogfood).

That's why I was blown away when Rick Lavigne contacted me to say he was using Spreadsheet::WriteExcel to produce Tulip Diagram roll charts for motorcycle navigation. If you don't know what that is, and I certainly didn't, have a look at Rick's website rollcharts.org where it is all explained in detail. In particular the quality of the finished worksheets really impressed me.

In fact it impressed me so much that I felt obliged to help Rick out. He had written to ask if a document properties feature was planned. It was on the TODO list but with a low priority so I moved it up the list and implemented it. There probably aren't many advantages to running your own Open Source project but at least you can set your own priorities.

Taking over maintenance of Spreadsheet::ParseExcel

I've taken over the maintenance of Spreadsheet::ParseExcel from Gábor Szabó.

I didn't want to because I barely get enough time to maintain/extend Spreadsheet::WriteExcel. However, Gábor is very busy with other projects and ParseExcel needs to be kept ticking over since it is so widely used and ultimately I'm probably the best person to deal with the Excel internals that are at the heart of the module.

Initially I plan to clean up the documentation, add more working examples and deal with the more egregious bugs. I may try to clean up and document the internals as well so that someone else can take over maintenance and so that patches are more consistent. It will also give me a chance to get ParseExcel and WriteExcel working better together.

Anyway, I've set up a Google Group for discussions relating to the module:

http://groups.google.com/group/spreadsheet-parseexcel

Feel free to join, post, chat if you are interested.

John.--

Monday August 18, 2008

01:29 PM

Somebody bet on the bay

It is about 1300m and I did it in about 45 minutes. It was the first time I'd swam it and I'd hoped to do it under 40 miunutes but I went a bit off course. Swimming in the open(ish) sea isn't quite like doing the same distance in a pool.:-)

The overall winner gets the The Richard Harris Memorial Trophy in memory of the actor who initiated the competition in his youth.

Microsoft Takes Additional Steps

In the case of the Excel file format, which I am interested in, the February specs offered little information over what was already in the public domain (for loose definitions of public).

Then less than a month ago, to much less or perhaps no fanfare, Microsoft released a second round of file format specifications, the June specs: "Microsoft Takes Additional Steps in Implementing Interoperability Principles". Surprisingly these were much more detailed.
The newer Excel specification, for example, is 1100 pages as compared to 350 pages in the previous one although the information is much more complete than a mere page count indicates. It is also cross-linked within itself and with supporting documents and all in all it feels more like a real specification than the February doc.

Which is great. As Joel Spolsky pointed out, in relation to the first round of docs, having a spec doesn't mean that it is easy to deal with these particular file formats. However, having such a detailed document certainly helps.

Which leads to the question, why didn't Microsoft release the detailed specs in the first place.

Anyway, since this is a Perl blog I should add by way of technical content that although Perl is often seen as a good text processing language it is also very flexible at processing binary data thanks to the pack()/unpack() functions. And binary data processing in Perl is much more portable than C solutions which suffer from more loosely defined data sizes and differently padded structs.