lua.riscos.org.uk down?

Hi all,

I just thought of resurrecting my Lua RPG project and wanted begin by installing the newest verson of RiscLua, only to find a Windows Server frontpage at lua.riscos.org.uk. Does anyone know what happened?

Kind regards
Stephan

Try:
http://www.wra1th.plus.com/riscos.html

Sorry Stephan. Two separate things have happened. The xxx.riscos.org.uk service has vanished – some while ago, I think. And recently I decided to bring some order to my personal website www.wra1th.plus.com, cutting out a mass of ancient stuff. This was partly because most of the pages did not validate properly. I had just updated the Weave application with which I had made them and I was temporarily fired with reforming zeal.

Ah, thank you for putting my mind at ease! I have a dozen unfinished RiscLua projects (ok, four: a roguelike, a card game, a classic RPG engine and a library for working with the toolbox), and I’d like to finish at least one of them. Oh well, too many ideas, too little time…

On a related note: I wanted to check if everything still works with the newest version of RiscLua, but I can’t get !rlua6 to run, although I have merged the supplied !Boot. It’s always quitting on me with

SDFS::RISCOSpi.$.Programming.RiscLua.!rlua6.lua6: can’t load library ‘libm.so.1’

Any idea what I’m doing wrong?

SDFS::RISCOSpi.$.Programming.RiscLua.!rlua6.lua6: can’t load library ‘libm.so.1’

It is a !SharedLibs component that does appear to be missing from the Lua zip.

It does come with GCC, gccsdk-gcc-bin-4/7/4-Rel3/zip.!SharedLibs.lib.abi-2/0.libm/so/1

HTH

It is a !SharedLibs component that does appear to be missing from the Lua zip.

Apologies about that. I have now added it to the Lua zip. Unfortunately !SharedLibs just bungs everything together, and I was not too sure which bits in the !SharedLibs on my machine were relevant to Lua. More my slack habits than a moan about !SharedLibs. Many thanks for drawing this to my attention.
Taking a wider view, I think that GCC 4.7.4 is a big step for RISC OS, and !SharedLibs should be seen in the same light as the shared C library. But that being supplied in ROM is one thing less for the user to worry about – it is just taken for granted. I do not know how many people are using GCC to create software for RISC OS, but if the number is to increase then the deployment of !SharedLibs should be as simple as possible.

Unfortunately !SharedLibs just bungs everything together, and I was not too sure which bits in the !SharedLibs on my machine were relevant to Lua. More my slack habits than a moan about !SharedLibs.

I think there’s an erroneous assumption by the GCC team that everyone will just rush to add the latest SharedLibs so they haven’t greatly promoted the idea that, like the SharedC of old, the latest version required by the distributed application should be distributed with the application.

Taking a wider view, I think that GCC 4.7.4 is a big step for RISC OS, and !SharedLibs should be seen in the same light as the shared C library.

Hmm, distribution with/alongside the OS? Makes it easier for the developers, but are there any restrictions to the distribution and what are the pitfalls?

First, thanks for all your help :)

Then: From my point of view, I sure would welcome if running lua6 would be as easy was running lua570.

With lua570, I could (if needed) even bundle the lua interpreter with the appliaction and everything would just run.
Now, with lua6, care has to be taken that the user has installed !SharedLibs and the correct interpreter for his/her machine (Iyonix/RiscPC vs. RasPi).

Gavin, don’t get me wrong, from what it looks like, lua6 is a major step forward, and you have done terrific work bringing this language to RISC OS, but for building applications that are supposed to ‘just work’, these prerequisites are a bit of an inconvenience.

So, again, from my point of view, thumbs up for bundling !SharedLibs (and anything we might need to have the same lua interpreter binary for all systems) with the OS.

the latest version required by the distributed application should be distributed with the application.

Or have some sort of dependency resolver that can determine what a program needs, and go download and install it.

but are there any restrictions to the distribution and what are the pitfalls?

Wouldn’t we be opening the GPL can of worms again?

Wouldn’t we be opening the GPL can of worms again?

Hmmm. You ask, and the information in the SharedLibs package says:

/* Notice of general intent:
*

• The linux operating system generally contains large amounts of code
• that fall under the GNU General Public License, or GPL for short.
• This file contains source code that by it’s very nature would always
• be linked with an application program, and because of this a GPL
• type of copyright on this file would place restrictions upon the
• distribution of binary-only commercial software. Since the goal of
• the Linux project as a whole is not to discourage the development and
• distribution of commercial software for Linux, this file has been
• placed under a more relaxed BSD-style of copyright.
  *
• It is the general understanding of the above contributors that a
• program executable linked to a library containing code that falls
• under the GPL or GLPL style of license is not subject to the terms of
• the GPL or GLPL license if the program executable(s) that are supplied
• are linked to a shared library form of the GPL or GLPL library, and as
• long as the form of the shared library is such that it is possible for
• the end user to modify and rebuild the library and use it in
• conjunction with the program executable.
  */

and the same in the actual C library package.

But as you mentioned:

have some sort of dependency resolver that can determine what a program needs, and go download and install it.

For anything with a GPL reference (possibly actual libraries as opposed to the loader):
It ain’t distributed with the OS and it’s not a functional requirement of the OS so no problem.

If you look in the copyright file and read the dynamic loader copyright you will find that’s free of the dreaded GPL.

With lua570, I could (if needed) even bundle the lua interpreter with the appliaction and everything would just run. Now, with lua6, care has to be taken that the user has installed !SharedLibs and the correct interpreter for his/her machine (Iyonix/RiscPC vs. RasPi).

At the moment GCC and Acorn C are the only C compilers available for RISC OS. If you want arithmetic in hardware it has to be GCC and RiscLua 6. But then you cannot make standalone binaries out of your Lua programs. That is a shame; I was proud of Linker and Absolua. But if you do not need arithmetic in hardware, or dynamic linking, then go for RiscLua 5. In fact for version 3 of Weave I compiled myself a stripped down version of RiscLua 5 and gave the binary a different name, lw (lightweight Lua, Lua Weave ?).

By the way, the new Lua libraries for RiscLua 6 will work with RiscLua 5. They do not address the toolbox but deal with template files, menus and draggable objects quite nicely.

I think I need a conversation with you, Stephan, and with any other interested parties, on the topic of libraries. In the past I have been reluctant to develop and offer libraries, because I wanted to stick to Lua’s philosophy of minimalism; to offer the ingredients rather than the cake. But my reluctance has also come from my laziness, my increasing years, and the desire to get things right before blurting them out. There are so many factors to consider. For example, do you make one big library or lots of little ones. If you go midway how do you split things up. Once you have a policy on that then you have to address the choice of the right abstractions, and then of the right datatypes to represent them. For a wimp library how do you tackle the problem of debugging? Debugging toolbox programs tends to be a nightmare, with errors causing other wimptasks to crash. Maybe I am being too ambitious here and not accepting the limitations that are already built in. Uptil now I have not exploited sufficiently the very considerable powers that the Lua debug library has to offer. Dynamic loading makes a lot of sense in the debugging context.

Since we’re already (kind of) talking about RiscLua… after installing the current gcc, I was finally able to get RiscLua6 running. Yayyy.

But as I already had feared, none of my old projects worked any more.

One major difference seems to be that one can no longer concatenate strings and numbers. Ok, that could be easily fixed (tostring()), but another major problem for me is that the (immensely useful and oft-used) vdu library is gone. So I tried the vdu library from RiscLua5, but, alas, “number has no integer representation” in line 18, so that’s not working either.

Also something seems to have changed in passing parameters to the OS because in one project (the card game), where I do a lot of drawing, I have graphics glitches all over the screen… but at that point I gave up somewhat disenchanted and decided to look at the problem some other time.

But anyway, my first question to Gavin would be, are you planning to bring back the vdu lib? Or maybe you can help me figuring out what is going wrong with the existing routines? Or do you think I can safely require RiscLua570 in the forseeable future?

I swear, I’ll release all my stuff as open source, once it’s running again. No point in having it all gather dust on the hard drive and then one day nothing is working any more… ;)

p.s: To see what I’m talking about, here’s “Tahi”, an “Uno”-Clone written in RiscLua.
It uses a few support modules I have written over the years, namely “FontWriter” and “SpritePainter” (which are actually part of LuaToolboxLib, but I digress…)

It works fine with lua570 and is a big mess in lua6… and I have no idea what’s going wrong here.

https://www.dropbox.com/s/q36rxnrgg82xz6x/Tahi%2Cddc?dl=0

p.p.s: you need to put ‘riscos = require(“riscos”)’ in there to make it work in RiscLua6, also I’ve included the old ‘vdu’ routines for RiscLua6, rather than just requiring them without path.

p.p.p.s: yes, I know, it’s kinda ugly; it’s more like a proof of concept, the next step would have been to WIMPify it…

Oops, Gavin, saw your previous answer only after sending my last post… sorry!! Yes, we can use that as a starting point for the conversation ;)
Personally, I don’t really need more libraries in the standard package of RiscLua, but having those that have been part of RL570 would be nice…

are you planning to bring back the vdu lib?

Yes; just have not got round to it. There are two important things in the change from RiscLua 5 to RiscLua 6.

1) Libraries that were previously built in statically
riscos, lpeg must now be explicitly required.
E.g.

riscos = require "riscos"

2) Numbers in RiscLua 5 are 32-bit integers. So no problem for the wimp or vdu commands. Numbers in RiscLua 6 are 64-bit either floating point or integers.
In riscos.sys they are cut down to 32-bit integers. But beware that -1 may not be 0xffffffff, as it should be for RISC OS but 0xffffffffffffffff. Also, / gives floating point division and // gives integer division. For 64-bit bitwise operations you have & (and), | (or), ~ (unary not, binary xor), << (left shift), >> (right shift), % (modulo).

I have not checked but it should not be too hard to upgrade the vdu library so that it works in both contexts. Chapter 3 in edition 4 of Programming in Lua has some useful tips. Bitwise ORing a number with 0 forces it to an integer (x|0) if x has an exact representation as an integer and has no fractional part and is in range. Or use math.tointeger .

Coercion used to be presumed a good thing in Lua. I suspect that opinion may be changing. Personally I would remove all string<→number coercions and use explicit tostring and tonumber functions. It is good that Lua has for a long time distinguished between numbers and integers internally. I would go further and separate off an integer type, externally. Give it a few more years :).

I think I need a conversation with you, Stephan, and with any other interested parties, on the topic of libraries.

Perhaps a distinct thread in the Wishlist forum?
Should the SharedLibraries be included in part of the downloads that constitute a complete install or should there be a downloader added to RO that will add them?
(and check for updates)

See Libraries thread in Wish lists.

If you want arithmetic in hardware it has to be GCC and RiscLua 6.

Doesn’t Charm have an option to rebuild itself in a VFP capable form?

Plus BASICVFP. ;-)

Doesn’t Charm have an option to rebuild itself in a VFP capable form?

Yes. Not sure whether it works on RPi3s. Sadly Peter Nowosad died before that came out. I think it is tragic that he did everything his way, with no thought for compatibility.

I think it is tragic that he did everything his way,

Don’t we all?

with no thought for compatibility.

But the source is available

But the source is available

Yes. I found it very educational. Perhaps some hero of coding will be able to use Peter’s sources to forge new tools for RISC OS.