Packaging Confessions

posted in: Software | 0

Since June 2002 I have been offering software from my website,, to the RISC OS community, namely RiscLua, a port of Lua. New versions have come and gone,, to keep up with developments in Lua, and because I have often changed my mind about the best way to present the software for the user’s convenience.

This article is not about Lua but about packaging; it just happens that RiscLua is the only template that I have for discussing the subject. There are many possibilities; I am by no means sure that any of the ones that I have chosen in the past are optimal. In the end it is the user who must be the arbiter of that. So I certainly welcome feedback, and not just from users of RiscLua.

So what does the package contain? There are five main ingredients:

  • Executables – in this case lua, the interpreter, and luac, a bytecode compiler and disassembler.
  • System variables – defining a filetype run-action, so that programs can be run by doubleclicking the icon of a file – LUA_INIT for prelude code, run before any program – LUA_PATH to tell the require function where to find libraries of Lua code, and LUA_CPATH to do the same job for dynamic linking libraries (a feature not available before 2015, and probably of little relevance in the RISC OS context).
  • Utilities – for running in a Taskwindow, for displaying intermediate bytecode, and for linking in libraries and interpreter to produce standalone executables.
  • An HTML/CSS manual for the current version of Lua, with an extension for the non-standard, and in particular the RISC OS, parts of RiscLua.
  • Example programs and tutorial material.

At one point, in 2003, I implemented the interpreter as a relocatable module and used the Resource Filing System for the Obey files setting up the system variables. However I gave up this option when I realized that it was easier to keep other tasks insulated from errors if I implemented it as an application, even in the case of interpreting wimp-tasks. Besides, RISC OS has the convenient system of !Boot files for setting up system variables, defining filetypes and their run-actions and RMEnsuring the existence of resources. It would be daft not to take advantage of this.

To begin with I called the application !Lua. Later, as the versions multiplied and the chances grew that different versions would interfere with each other, I started to use the version number as part of the name, at least for the binary files. So the latest version is named  !rlua7. Then there is the question of where you put the other stuff: the documentation, the utilities and the examples? Inside the application, or outside? These choices are important for ease of updating, both for me and the user.

You might not want to download the whole package just for some trivial correction to the manual. It has been my habit to upload zip files to my website with FTP, so do I have one big zip file or lots of smaller ones? Writing tutorial material is, for me anyhow, a gradual process of many small steps. I suddenly get interested in this or that topic and fire off an addition to the tutorial material or to the examples.

A particularly thorny aspect for me has been the question of software libraries. Luckily Lua has by tradition taken the road of minimalism – provide as little extra possible and leave it to the user to write their own libraries. Provide possibilities not solutions. Lua is often compared unfavorably with Python on this score. But libraries bring into play the question of authority. In a small user-base each user may prefer to knit their own jersey rather than get one off the peg.

So I have been in two minds about providing libraries, not wishing to set them in concrete. This is particularly true of libraries for writing wimp-tasks or for the toolbox  where I have had second thoughts about the best approach quite frequently. Fortunately it is very easy for the user to set up their own libraries, because the require function discovers where to find them by using the strings package.path and package.cpath which the user can modify at the start of her program. The system variables LUA_PATH and LUA_CPATH are only used to initialise these strings.

The way that RiscLua is packaged is actually irrelevant for most uses, which only need to know where the Lua interpreter is and what its commandline arguments should be. A vital consideration, however, is whether the platform on which you use RISC OS has VFP or not. Until 2015 RISC OS only handled floating point calculations in software. In consequence it was never a good choice for intensive number-crunching. But things are different now and so RiscLua has to come in two packages, one for use with VFP and the other for use with the older ARM chips without it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.