Venue - Methodist Church Hall, Blackwell, Bromsgrove B60 1BL
Our guest speaker on Saturday was Dr Graham Shaw of RISC OS Toolkit, RISC OS Packaging, and open source Clib fame.
As well as listening to Graham's talk we discussed involving the club in a RISC OS Charity for for organising and funding RISC OS software.
Participants arrived over a period of half an hour or so, which is quite remarkable given the distances that several are prepared to travel. The tally (16) provided £31.10 by way of subscriptions to pay for the hall, etc. I guess the 10p was in mistake for a one pound coin by someone ;-). Robin provided refreshments - tea, coffee and biscuits - which seemed to be much appreciated as people arrived. The subscriptions more than paid for the Hall and other expenses, so we have a surplus of about £9 towards some future expenses. I do NOT propose to produce official accounts, by the way, unless someone insists!
The main subject of this meeting was a talk by GRAHAM SHAW on The RISC OS PACKAGING PROJECT, but before he began Doug Webb told us that he was trying to set up a talk by Jack Lillingston, of Castle. For this to happen we shall have to arrange an evening meeting. Most (possibly all) of us were prepared to turn up at such an event. A reminder of MUG events should be available on the web site.
John Rickman told us that there is a lack of traffic in the MUG site, and that it would be nice to see more.
John Cartmell (Qercus) delivered about a dozen copies of Qercus to Robin on Saturday morning, asking that meeting attendees accept them and perhaps pass them on to others who might be interested. We are duly grateful to John.
Graham's talk began at about 2.30, and we settled down to be enlightened on the very practical subject of the proposed optimum organisation of RISC OS software. Graham has undertaken the design and it seems implementation of a system that could make life for programmers and ordinary users much simpler than it sometimes is at present. The address of his site is www.riscpkg.org.
At this point I have to say that although I tried to take sufficient notes the pace of the presentation, though measured, was well in excess of my writing capabilities, so please do not expect the technical details to be reliable. They are not!
Although we are used to an excellent "drag and drop" OS, as software becomes larger and much more complex in its interaction with the OS (and possibly other software?) any changes, for example upgrades, can require considerable effort and even expertise to install them in such a way that all their interactions with "the system" are robust and secure. Graham's efforts are aimed towards producing a system into which software can be introduced as a "Package", that contains all that is required for the product to operate correctly, avoiding clashes with other material on the computer. The Package (operating under a Manager) is a Zip file which would contain the material to be installed, a control file and a "copyright" file. It could also contain a list of system variables to be set at boot time, and perhaps a list of sprite files. There could be yet more optional files.
The "Payload" of a package would consist of files that have logical file names. Graham gave the example Apps.Admin.!RiscPkg. The author specifies exactly where the files are to be stored. One could create links to "hidden" locations, though this is not recommended because they could be unwittingly overwritten.
The general Control file format is based on Debian's techniques. (I lost the thread a bit here - sorry). It might have Name, Section - to sort files into categories - Priorities - eg Essential, Normal, Widely used, "Everything". Also, Licence type.
A Package needs to be "maintained". The maintainer could be the author, a "maintainer", the "poster" or the "packager". The Maintainer would ensure that the package is licensed, conforms to standards (of non-interference), is appropriately upgraded and that bug reports are acted upon. Every package will have a version number, to ensure that upgrading can proceed correctly. The payload would have distribution gradings, such as "unstable", equivalent to a "latest version", "Well tested" - meaning what it says, and "Experimental", meaning that it is potentially worse than unstable!
Currently there are about 50 packages in the system, but a substantial further input is necessary to make the system sustainable. In particular, Applications are needed. Graham said that some needed modules and libraries may not yet be packaged. Applications having complex !Boot files cannot be automatically booted at present.
Graham then told us how we might be able to help:-
He said that the web site is now working quite well. He gave a demo which generated some questions about RiscPKG's relationship to existing, cherished storage structures and naming.
After this impressive display of diligence and dedication we were somewhat stunned, but Doug Webb brought up an important thing which Graham had not touched upon. This is about distinguishing between 26 and 32 bit software. Graham said that this could not be done at present.
He then talked about the RISC OS TOOL KIT. This product is intended to simplify greatly the complex work required to program desktop operations. He reminded us that the Acorn Toolbox, although language independent, cannot take advantage of any new language features of components, and must also be written as modules. Dr Wimp and App Basic are excellent but are useful only for BASIC programs.
The ROTK takes full advantage of ISO C++, and Graham gave a brief list of some of its features - too fast for my writing to take down!
The Toolkit is free, open source software, as is RiscPKG. It needs a C++ compiler to ISO standards, and the only one currently sufficiently capable is the GCC compiler, whic is essential for C++.
He then asked for opinions and/ help. There are high profile gaps in RISC OS software, which need filling for the sake of the platform. He is contemplating trying to set up a charity for accepting donations that would help collect and distribute software. The point of this is that a charity can collect "notional tax" on gifts to help further the cause. The project needs to be multi-participant, so that the load can be spread, but this in turn requires an organisation. The objective is to get software developers to cooperate.
A lively discussion followed. Are donations or programmers the prime requirement? How should things be started up - perhaps by advertising in Drobe? John Rickman suggested contacting other User Groups to gauge how many might be willing to participate. Graham agreed to send useful information to John, who will do the necessary.
We were I think all very impressed with the enthusiasm of Graham, and his astonishing degree of commitment at the practical level, and he was heartily applauded for his work and investment of time. He refused our offer of going some way to meet his expenses. He carried out his presentation using a laptop and Virtual Acorn (which sort I did not find out). The excellent projector was provided again by Simon, courtesy of Birmingham University, I believe!
I enjoyed this meeting a lot, and I'm sure we all did.
Robin Edwards