Moving code to BitBucket

As the number of packages I’ve written has grown keeping a track of everything has got more complex for me. Not having a background in programming, I’ve very much had to learn things ‘on the job’. One thing I’ve been doing for a while now is using a version control system for the new version of siunitx and working as part of the LaTeX3 Project. The LaTeX3 Project uses the Subversion system (also known as ‘SVN’), and so I’ve been using the same system for siunitx version 2 (hosted by BerliOS). I’ve now decided to get a bit more systematic, using the service provided by BitBucket.


There are a few different things that I wanted to get sorted out with all of my packages. First, I think it is useful to make the code (and code changes) publicly available in one place. That is what version control systems provide: you get a list of changes, with hopefully some notes on what was going on. That also makes it possible for other people to easily suggest patches (if they want to, of course!). Second, tracking bugs and feature requests really requires some kind of structure. I currently have a long list of e-mails that list things to think about: making these both publicly available and organised is a good idea. That helps me, and also lets user see what has already been logged. Third, it is useful if there is a way of having on-line documentation, for example using a wiki.

Moving to BitBucket

I had a look at various approaches to doing all of that. I’ve had a few issues with BerliOS, and as I’ve used it I’ve realised that the interface is rather awkward. Two services which look rather more helpful are BitBucket and GitHub. Both of these are based around distributed version control systems: Mercurial and Git, respectively. I’m not going to go into the details of either of these (or the differences between them), but Mercurial seemed a bit easier to use to me so I decided to go that way. BitBucket includes all of the bug tracking and wiki features on my list of ideas, and so far I’ve found the interface clear and powerful.

Over the last couple of days I’ve uploaded basically all of the current versions of my packages to BitBucket. As most of these were written without formal version control, I’ve had to ‘reconstruct’ the historical changes from my archive. I’ve aimed for a balance between providing information and my time: the history goes back to the first version of the current releases (for example, from v3.0 for achemso, which is currently on v3.4f). Of course, any new versions will appear on BitBucket. I’m now working on moving all of the issues into the bug databases. I’ll also look at the wiki side of things: I’ll try to put some basic installation and use information, and perhaps some frequently asked questions. BitBucket includes RSS feeds, so anyone interested can follow what is going on.

The beamer connection

I should add that one of the reasons for looking at all of this was the recent news that the beamer package has a new maintainer. I’ve taken a bit of interest in this, and as the code has been moved to BitBucket, took a look at the facilities on offer there. As a result, I’ve been given access to the new repository. I have a few vague ideas about areas to look at, but at the moment nothing definite!

Get involved

Anyone interested is of course free to contribute. Adding any bugs, enhancements or ideas to the databases is one of the easiest way to do that. If anyone wants access to edit the wikis or add code, drop me a line.

siunitx version 2: beta release

Over the past few months I’ve been working a new version of siunitx with completely re-written internals. This is now at the point where I hope that it is usable for most people, but before replaced version 1 some testing is needed. This is what this beta (testing) release is for. There are some important notes for people testing, which I’ll run through below. For the impatient, you can get:

Release notes

The code used in siunitx relies on the LaTeX3 Project packages expl3 and xpackages. You will need the latest versions of both of these to test siunitx 2: they can both be downloaded from CTAN or installed using the update facilities in TeX Live or MiKTeX.

Version 2 of siunitx renames most of the package options to make them more informative. The old names are available by using:

\usepackage[load-configurations = version-1]{siunitx}

The new option names are intended to make it easier to continue to expand siunitx without having completely opaque option names. At the same time, the nature of some of the options has been changed. This means that there are no longer any ‘magic’ keywords, which have caused confusion in the past.

There will be no significant features added to siunitx version 2 between the beta version and the production release (probably in June). The aim is to get the inevitable bugs in the current code found and fixed, which is best done while not making other changes.

A small number of features from version 1 of siunitx are not present in version 2. The features removed have never worked as well as I would like, and so I felt it was better to remove them and rework them later if needed. If this causes severe problems for users then some of these decisions may of course be reversed.

I have had a large number of feature requests for siunitx, and only some of these have been added to version 2 at present. This is partly as I have a limited amount of time, and need to get siunitx 2 to release within a reasonable time. At the same time, some of the feature requests are very specialist and I need to consider which of these fall within the scope of the package. That said, I intend to work on adding more features to siunitx after the full release of version 2.0. More details on this will be posted here in the future.

Feedback on any aspect of siunitx version 2 is very welcome:

TeX and security

Security in computer programs is always an issue, with the balance between ease of use and security never being a simple black and white line. There’s a very interesting paper, being presented at an upcoming conference, about TeX security issues. This is particularly significant to MiKTeX users, as it’s led to a change in how MiKTeX implements certain features.

One of the well-known security questions with TeX is whether to enable \write18, and as a result this is off by default in TeX Live and MiKTeX. Another area that is of obvious concern is the \openout primitive, which allows writing a new file and could therefore be used for undesirable purposes. Of course, this functionality is also important: writing to files is how LaTeX manages a whole range of automated cross-referencing. So there is a balance to be struck: we need \openout, but not at any cost.

The TeX Live team have taken the attitude that \openout should be able to write within the current directory structure but not outside of it. This can be seen with a couple of very similar plain TeX test files. If you try

\immediate\openout\mywrite test/

then everything will be fine and the test file will be created. On the other hand

\immediate\openout\mywrite ../

will raise an error. The behaviour with MiKTeX was to allow both (and also absolute paths, etc.). That has now been altered, so that MiKTeX behaves in the same way as TeX Live (at least, that’s what it looks like in my tests).

Reading the MiKTeX lists, the new behaviour is causing issues because LaTeX’s \include relies on \openout. Quite a lot of MiKTeX users have been doing things like:

\include{C:/Users/<user>/My Documents/Chapters/chapter1.tex}



which used to work and now does not. There is a setting which enables the old behaviour, but it’s not really to be recommended, I think. So users will have to rearrange their input a bit to reflect the new more secure approach.

There are some other interesting points in the paper on TeX security. One is that making a truly secure LaTeX implementation (to use as a web service) is basically impossible. The MathTran site gets mentioned as the most secure TeX web service: it uses a specially hardened version of plain TeX, with no access to things like \csname, \catcode and so on to make it secure. For LaTeX, that is probably not possible (at least with LaTeX2e). Worth reading, but for those of us who just use TeX on our own computers not quite so immediately relevant.

siunitx 2: release timetable

As many readers will know I’ve been working on version 2 of siunitx for some time. There are always more feature requests, but at some stage I have to actually release something. I’ve now got some code that fixes a lot of bugs and annoyances in the current release and provides a better platform for new features, and so I want to move to releasing it.

The plan is to fix the known bugs in the development code and add as many new features as possible by the 25th of the month, and then to freeze development for a beta (testing) release. Depending on feedback, I’ll then aim to fix the bugs in the beta and go for a first production edition of version 2 in June. I’m not going to add any new features between the beta and production releases, but will start on them again once the production version is out. There is a feature tracker on the BerliOS site, which is a good place to put things so I don’t forget about them.

Talking about TeX

I’ve been able to meet up with a few ‘TeX people’ over the past few months, as we’ve ended up in the same places and I’ve been able to put a face to an e-mail address. It’s always interesting to meet other TeX users, and to talk not only about TeX but also about other things! I’m sure I’m not the only person who find this, so if anyone fancies talking about typesetting over a cup of coffee, do drop me a line. It might be nice to arrange some kind of informal get together (I know these are popular in some countries), if there is any interest.

Building biblatex-biber on Windows

I’ve just reinstalled my Strawberry Perl system on Windows, and so had the opportunity to try a clean build of biblatex-biber. I’ve posted before about building this on various platforms, and it now is almost asstraight-forward on Windows as on Linux.

As before, I’ll assume you’ve grabbed the source code, unzipped it and have a Command Prompt running as the Administrator, in the directory where biblatex-biber is unzipped. First, you need to install one support Perl module using

cpan Config::AutoConf

You can then do

perl Build.PL
build installdeps
build test
build install

That’s it! I’m not quite sure why you have to install Config::AutoConf ‘by hand’, but if you don’t then Text::BibTeX still fails to work. However, that is almost as easy as on Linux or MacOS 10.6, so everyone should be able to use biblatex-biber now.