RiscLua 6.0

Lua has been available on RISC OS, in the form of RiscLua, since 2002. Only now, though, with the arrival of GCC 4.7.4, has it become possible to implement Lua on RISC OS in anything like its standard form as found on other platforms. So here is an announcement for RiscLua 6.0 which attempts to be such an implementation and also to be as compatible as possible with the RiscLua 5.xx versions.

Get it at the usual place.

There are two versions: one for ARMv3 which I hope runs on RiscPCs – only tested on an Iyonix so far, and the other for ARMv5, i.e Raspberry Pi (only tested on version 2) and other platforms. The former use the floating point emulator, the latter use VFP.

The big new feature is that it can use dynamic loading. You need !SharedLibs (get it from http://www.riscos.info/packages/LibraryDetails.html#SharedLibs ) in !Boot.Resources to run RiscLua 6.0. Whereas programs running under previous versions of RiscLua could only extend themselves by loading in Lua libraries, now programs can extend the Lua interpreter itself, as they are being interpreted, with C libraries. This makes RiscLua far more extensible than it was before, when everything had to be linked statically. The difference between Lua modules and C modules is invisible to the user. To write C modules you need some experience with C and the Lua-C API; probably a bit harder than writing modules in Lua.

My thanks to all those who helped me with GCC, especially Lee Noar.

The download site says “ARM v 7” not “ARM v5” — a critical issue since the Pi 1 is ARM v 6 rather than ARM v 7. Could you clarify please?

Whoops – lapsus muris! I meant to say ARMv7. But I would be very surprised if the Pi 1 could not swallow the ARMv7 version. I no longer have one, but I would be grateful if somebody who did could give the ARMv7 version a try and let me know.

Of course it will. I will give it a try.

Is it possible to clairfy how it differs from RiscLua 5.x? I’m assuming the major change is f.p. rather than integers, and that the other “non-standard” bits are unchanged (including the libraries).

I’m assuming the major change is f.p. rather than integers,

That and the dynamic loading of libraries written in C. The only change there as far as the user is concerned is that the riscos, lpeg and bc libraries are no longer statically linked. So you need an extra line of code

 riscos = require "riscos"

Now to Lua libraries … I had hoped to use this opportunity to make a thorough revision of these.
They were a mess. I wanted to have libraries for tasks and the toolbox that would make writing wimptasks easier with RiscLua than any other language. So much for my ambitions. In fact I have simplified them a bit.
What used to be wimp.task and wimp.tbox are now plain task and tbox. The latter is unchanged. task is only slightly different – it offers a multitasking replacement alert instead of report which brought the wimp to a standstill. alert uses the excellent MultiError (thank you Snowstone). Compare the new !Eph example with the old. It is much shorter. It works by firing off a new wimptask (using alert) to display a message in a window, and then sending that wimptask a Quit message to kill it a certain interval afterwards.

I guess I need to document the examples and libraries. But I do not want to fix them in stone too early. They could do with much improvement and extension. I will be happy to fill in the gaping absences any time, of course. Thanks for your interest.

I notice that there’s only one version of RiscLua 6 for download. I’ve tried putting it on VRPC/RO 4.39, but when I type ‘lua’ in a task window I get the following error message:

HostFS::HardDisc4.$.!boot.Resources.!rlua6.lua6: can't load library 'libgcc_s.so'

As with Risc Lua, !SharedLibs is in !Boot.Resources but there’s no libgcc_s.so in there…

!SharedLibs is in !Boot.Resources but there’s no libgcc_s.so

Also needed is SharedLibs-C2

I notice that there’s only one version of RiscLua 6 for download.

I fell for that as well. The version required for VRPC OS4.39 is in the v3 directory. It’s in the Readme, which I didn’t.

Hope that helps.

Also needed is SharedLibs-C2

What! All 3.6 Mb of it? I note that libgcc, and its vfp version, are each about 1.5 Mb. I do not think it would be wise to include these in the RiscLua distribution. Bundling resources with applications is bad policy because users end up with lots of redundant stuff, often out of date. This is where packaging wins out, of course. Maybe it was unwise of me to have bundled the SharedULib module and the skeleton !SharedLibs. Perhaps as things settle down and these resources become more widely used they will be distributed as part of RISC OS, like the shared C library.

Anyway, all advice about what resources should best be bundled will be gratefully received.

That brings up another point about resources for software. If you have a single receptacle, like !SharedLIbs, to chuck shared libraries in, you end up with a whole load of stuff and no information about which bits are actually needed by which applications. Somehow one needs a database that keeps track of dependencies automatically. This is complicated by the fact that resources may come in different flavours – witness the libgcc compiled for vfp and the libgcc compiled for softfp. It would be useful not to have to download the bits you do not need.

I’m probably missing the point, but have you considered using the RISC OS Packaging project to distribute this. The users will need to load PackMan of course so it’s an extra step. But once loaded you only need to make your RiscLua dependent on the SharedLibs you need and they will be downloaded automatically when they install RiscLua if they weren’t downloaded before. From the PackMan user interface you can check what dependencies any package needs.

Thanks – this is a good point. I have got so used to downloading stuff in zip file format that I have not really got into the packaging mindset. But the more that applications depend on resources, and the more varied the target platforms, the more that packaging makes sense.

Thanks – this is a good point. I have got so used to downloading stuff in zip file format that I have not really got into the packaging mindset. But the more that applications depend on resources, and the more varied the target platforms, the more that packaging makes sense.

Whoops! What happened there? Why cannot we delete our accidental duplications?

The usual method is to edit one to just say ‘duplicate deleted’ or somesuch.

Perhaps as things settle down and these resources become more widely used they will be distributed as part of RISC OS, like the shared C library.

Only if the libraries are non-GPL – otherwise they have to a separate distribution to avoid the nasty GPL restrictions.

Yep, but what about a “GPL additions” package in Miscellaneous downloads ?
(I really like Bonus binaries :) )

Yep, but what about a “GPL additions” package in Miscellaneous downloads ?

Wouldn’t this imply GPL in the source repository?

Better to firewall GPL code and hold it on a separate server…like…say… http://riscos.info/

Wouldn’t this imply GPL in the source repository?

Surely only if statically linked? That is direct jumps from code to code.

I guess I am pretty sloppy. Licenses and copyright notices make my eyes glaze over. The only software I ever sold was a sideways ROM for the BBC B, and Joe Taylor took charge of the marketing aspect. So I probably need advice about what documents to include in the RiscLua distribution (which is free, of course). The file !rlua6.doc.readme/html finishes with a license section, explaining that Lua is free software distributed under the terms of the MIT license, which it reproduces, and with whose terms I am compliant. However I feel that I ought to be giving due credit to GCCSDK whose implementation of GCC 4.7.4 was crucial. What is the right way to do that, without stirring up GPL angst?

@Gavin

On the matter of the gcc Shared Libraries the GCC for RISC OS site “strongly recommends” a course of action on distribution.

Hope that helps.

You need to make sure you specify the licence terms for any parts you distribute. You don’t need to include the full wording of the licence if it is well known (‘this file is under the GNU GPL version 2’ is sufficient, ideally with a pointer to where to find more detail). Typically source code will include this on the top so you need not do anything. If Lua is under the MIT licence then that’s fine. If you have components under other licences they should include details of what they are under, or you should include details otherwise (eg for an image which can’t include a copyright statement). If you have modified a source file you should also add your name to the list of copyright holders on the file (assuming the licence allows modification) since you have now produced a derivative work of the original file.

You don’t need to thank people, that’s entirely optional and with no legal standing. However you should ensure that you have the rights to distribute what you do. All too often RISC OS software doesn’t mention distribution rights (saying only things like ‘this software is Freeware’), which technically makes it impossible to distribute.

Thanks. The only bit of the distribution that is not covered by the MIT license is a (very) slight modification of Adam Snowstone’s MultiError, of which he declares

MultiError is in the public domain, so you may use, distribute and modify it however you like.

Precision of wording is obviously important in licenses, however against the grain and custom such precision may be. I have often wondered at the contrast between the precision necessary for writing programs and the traditional informality and laxness of speech to be found in many of the persons writing them. But I have wondered naively, because different contexts obviously require different modes of speech.

One thing I notice is that the backspace key doesn’t work either at the Lua command prompt or in a Lua input statement. Instead I get ^H^H^H —can’t remember the old version doing that.

Yup. This is actually not an artefact of Lua but of your Taskwindow server,
and you would get the same with any compiled C program that uses gets from stdio .

If you are using StrongED as TaskWindow Server you need to edit your TaskWindow modefile so that the line
⁰⁹⁰⁹Backspace⁰⁹⁰⁹ToTask
is replaced by
⁰⁹⁰⁹Backspace⁰⁹⁰⁹CharstoBuffer(“<127>”)
; copy TaskWindow’s modefile to !StrED_cfg.UserPrefs.Modes.TaskWindow and do the edit. The ⁰⁹ stands for a tab character. I am not a Zap user, so I do not know whether the problem occurs there, or what the equivalent solution is.

I’ve tried this but I get “abort on data transfer” the moment I hit the backspace key. StrongEd 4.69f8, 25th April 2015 version.