Would you be interested in a monthly Zoom Meeting on everything coding on RISC OS?

There are two sorts of library for programming in Lua: those written in Lua, and those written in C. The latter can be thought of as extensions to the Lua interpreter itself. Conventionally for RiscLua, the former are kept as text files in !rlua.lib and the latter as ELF files in !rlua.solib (N.B. their filenames must end in /so). The RiscLua interpreter (!rlua.bin.lua) is compiled from C sources in this zip archive. Libraries of either kind can be loaded using the require function. For example

x = require "mylib"

Section IV, the C API, in Programming in Lua, is about writing libraries for Lua in C. The examples, in !rlua.solib, are perhaps rather meagre fare and too obscure. So can anybody suggest some possibilities that are neither too complex nor too trivial, for further examples? In some sense the riscos library caters for any interaction with RISC OS that you might need, but not necessarily in the most efficient way.

@ Gavin

So can anybody suggest some possibilities that are neither too complex nor too trivial, for further examples? In some sense the riscos library caters for any interaction with RISC OS that you might need, but not necessarily in the most efficient way.

Sure, let me work some simple examples.

In general what is truly important is learning how to write a C wrapper for Lua for an existsing ELF32 library. That is what makes the whole game work.

In some experiments (althought if we do not want to use ASM), I have managed to access from Lua ObjASM written functions that were written for the C compiler and so I just needed to write the C wrapper for Lua, which means RiascLua can also access Assembly written code.

That is an important point. The sources do not have to be written in C. So long as they can be compiled to ELF files that can be linked to the C library that is enough.

The classic RISC OS applications, Draw, Paint and Edit were written in C using the riscoslib library, described in RISC OS library reference section in the Manual ACORN ANSI C RELEASE 4. The memory management for these applications, and most of riscoslib, are based on the heap and flex libraries. A question that has been at the back of my mind for over two decades is: can they be based on the Lua library, and its memory management, instead? If this is a feasible exercise one would get profound advantages. Edit, for example, would acquire all the pattern matching provided by Lua and Lpeg, and powerful scripting facilities. Most of the heavy lifting in Edit is done by the txt library and its extensions, txtedit , txtwin , etc. It would be a question of going through the sources of txt and replacing its dependences on heap and flex by calls to the Lua library.

Does ROOL have those sources?

@ Gavin

Does ROOL have those sources?

Do you mean these?

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Draw

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/EditApp

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Paint

Flex sources should be included in those repos.

I don’t know what ROOL wants to do with those apps, however, I believe !Edit should probably be left in ROM as an “emergency editor” in case of issues, so maybe you’d like to work on an enacted version outside the one in ROM?

Draw should probably stay a Module, for instance in the future we may use it instead of sprites to have a more scalable desktop?

Paint, IMHO has no need to live in ROM and should become (if it hasn’t already) an on disc app, so people can extend also its functionalities, given that at this point it’s way too basic even to create sprites for apps, so it would benefit a lot from becoming an on disc app.

Just my 0.5c

Do you mean these?

No. I meant the sources to riscoslib. In particular there is probably a file txt.c somewhere.

https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib

https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/blob/master/rlib/c/txt

I would also ask if someone is interested in showing how to use: – Ada

The list of people still active on RISC OS who ever did soomething serious in Ada has probably 1 1/2 entries…so choose wisely :-)

More seriously, I cannot commit myself to such a venture in the coming months. Perhaps in a year or so. And the largest section of any talk about Ada on RISC OS would be “ah, there are those cool features, but you cannot use it on RISC OS because the compiler is buggy/does not support this, and you’d obviously like to use Ada 2012, but we only have Ada 95”. It would be a depressing talk.

would be “ah, there are those cool features, but you cannot use it on RISC OS because the compiler is buggy/does not support this, and you’d obviously like to use Ada 2012, but we only have Ada 95”. It would be a depressing talk.

Sure, but we should still document how to code in Ada on RISC OS (as well as Perl, TCL etc.), let’s put the “world domination” mode off for a while please, let’s just have fun with RO for what it is, again just my 0.5c

Sure, but we should still document how to code in Ada on RISC OS (as well as Perl, TCL etc.)

Ah, I already documented (small parts of) it in 2001:

• http://legacy.huber-net.de/adagag.htm
• http://legacy.huber-net.de/ada_e.htm

And some failed plans of World (and RISC OS development languages) Domination:

• http://legacy.huber-net.de/adalio_e.htm
• http://legacy.huber-net.de/adalin_e.htm

But I basically agree that I should put something together on my webpages for the current state of things. Things are scattered around a lot, like the ARMv8 pacthed runtime AND the 32bit compatibility package AND who knows if the original GCC/GNAT tandem is still downloadable somewhere…and the StrongEd Ada mode…and the Zap Ada mode never made it to 32bit…

Let’s see if I can collect it all together somewhere.

let’s just have fun with RO for what it is

A platform with development tools in a very depressing state? There is a lot of fun using RISC OS for certain things, but Ada development is probably the furthest away from “fun”. Let’s stick to the reasonable things.

http://legacy.huber-net.de/adagag.htm

I decided to see what Google translate made of the German text.
It’s definitely improving, although it does need teaching that sometimes a word doesn’t need translating (begin ==> start was what it did)

Edit: I wonder if there’s a need for translations of the RO resources to a number of the main languages (English, French, German, Spanish…)

I can participate and give some talk about dual running os stuff. It will be difficult to share code , but I can explain how it works.

Hopefully you could also help with introducing coding in C?

I don’t see why not… :-)

There’s also what I’ve learned while getting all of my BBC BASIC applications under source control – first in Subversion, then later on Git and published on GitHub – if that would be of interest to anyone?

@ Steve Pampling

I wonder if there’s a need for translations of the RO resources to a number of the main languages (English, French, German, Spanish…)

Yes there is, at least the small community in Italy would like that, but I think it’s not a priority anymore given that Google translator can help when resources are on-line.

@ Michael

I can participate and give some talk about dual running os stuff. It will be difficult to share code , but I can explain how it works.

Great! Thanks a lot :)

@ Steve Fryatt

I don’t see why not… :-)

Nice! thank you very much :)

There’s also what I’ve learned while getting all of my BBC BASIC applications under source control – first in Subversion, then later on Git and published on GitHub – if that would be of interest to anyone?

Of course! SHowing how to use tools and your approach and workflow as well! It’s a meeting about everything coding on RISC OS, so definitely all the tools people use to help coding, versioning, testing, debugging, organise sources, measure performance, all absolutely welcome stuff!

Also don’t forget we all have workflows and a lot of people may benefits from seeing multiple of them and then organise their own based on bits taken from everything they have liked.

Also I may prepare a mini “course” in micro-benchmarking languages in order to squeeze performances, or how to use the NULL event to simulate a more preemptive behaviour of our Apps. Using DDT for C, C++ and ABC compiled code etc. there is so much we can talk about.

Also will introduce (as they become ready) new compilers for RO 5 like my Forth and the Forth VM Jitter, Prolog compiler (it started to work recently on RO 5), Maybe in the future some new BASIC with OOP support.

Also I wish to have space to talk about all the details of AIF Object Format and all the others. Again, everything coding on RISC OS.

So thanks everyone for all the great feedback and ideas so far! :)

As an action items:

- I am collecting all the feedback and preparing a list to share and edit on GitHub
- From there we can put to votes what people would like to start with
- Collect some commitment from who wants to present and/or just share their work.
- When we have material for at least few meetings (to start and measure attendance and reception) we can start some scheduling and share it.

I’ll share links on here so everyone can provide feedback and let me know who is going to present what :)

P.S. given that quite a few people I know are coding also on (and for) older releases of RISC OS, I would like to extend the invitation to whoever is coding on (or for) older versions and older RISC OS platforms.

I would be interested. On the advanced section I would like to see someone show how we can build Risc OS from source code.

What software do we need? How to download from github, how to compile and run everything. I want to make a change to the OS, how do we do this and test it. What happens when it goes wrong and doesn’t boot up? How do we revert? When we have finished, how do we send updates back to github/Risc OS for them to evaluate?

I would definitely watch a series which includes this. It maybe needs someone to prepare some video first so the long boring bits can be fast forwarded.

I think this is a good idea… there’s so much that’s in the heads of relatively few people. I think some good ‘high level overview’ material would be especially useful: ‘there is X, there is Y (but nobody worked on that since 1992), we don’t currently have a Z. Here’s how to get started’. Doesn’t have to be comprehensive, even simply ‘this is my workflow and I use these tools’. It would be useful to keep as a repository of information.

It is a shame for me that I am not so good at real-time communication. My brain usually goes blank when I pick up the telephone. Other people’s mobile phones always go apeshit when put into my hands, which is why I have an obscure Swedish variety that uses buttons, but which cannot load more apps (it has Whatsapp built in but I have never succeded in mastering it). But without feedback I go rattling on over the horizon – the legacy of a lifetime of teaching. My usual way of expounding things is to make web pages and put them up on my website, though I guess using this forum, or Rick’s Aldershot, are just as easy. So if anybody needs anything specific from me, they will have to prod me first; aliter multa tacebo

I think this is not uncommon, especially for people who aren’t used to this kind of format. What I’d suggest is:

• Write a plan. I’d start with bullet points, as that helps you get your thoughts into some kind of logical progression. You’re telling a story, so it helps to think about how to make it unfold in a coherent way – you don’t want to tell us who did the murder before introducing the victim. Find out your time limit as this will shape how much content you can fit in (don’t try to over-fill it).

• If you’re doing the Powerpoint thing, pictures and diagrams are good, too many words are overwhelming. Often a good talk has mostly pictures on the screen, and the words explain the pictures. (If your audience is not native English-speaking, sometimes more words can be helpful though). You don’t need to do the Powerpoint thing if you don’t want to, though – just audio or maybe some pictures like a classic slideshow are ok.

• If it helps, write it out longhand. Often it comes across better if you can do it without a full text (reading out a script can tend to the monotone), but the longhand version may help in terms of organising the thoughts, and gives you something to fall back on if your mind goes blank halfway through. It can also help if English isn’t your first language. You may find, after writing it out, you can do it second time around without the script.

• Practice. Give a runthrough so you get the hang of explaining the tricky parts and don’t dry up halfway. Practice is also good for ensuring you run to time, and have a chance to edit the material in case you are too far over (if you overrun by too much it’s impolite to anyone who comes after, and the audience will get bored).

• Record it. These days, you often don’t have to give it live. So record yourself, and if it all goes wrong, just delete the recording and start again. Or edit together different parts if you prefer.

(something useful when writing this kind of material is that Powerpoint, and maybe other packages, can attach audio to a slide. So you have a series of slides, each with their own audio commentary. Then you can ‘compile’ the slides into a movie file, that displays each slide while the audio plays. This makes it much easier to change something, because you can just re-record the audio for a particular slide and recompile, rather than have to do the whole talk again)

I’m pleased that Paolo has run with the idea and that it’s gained some traction. So I’m all in and happy to talk about my experiences.

Forgive me at the moment, but I’m a bit busy with some private family matters, so I can’t currently catch up with all the information here and elsewhere.

I’ll offer to help coordinate as soon as I’m free, and I’m up for hosting a few sessions.

A suggestion, let’s also keep ROOL and ROD in the loop.

Bye for now.

@ Graeme

I would be interested. On the advanced section I would like to see someone show how we can build Risc OS from source code.

Great idea and noted, thanks a lot! :)

@ Andrew

A suggestion, let’s also keep ROOL and ROD in the loop.

They have been invited from my very first message (look at the topic one). No answers so far, which is ok, I don’t want to apply pressure on any of them also considering this might be slightly in conflict with the “business” side orientation they both present, although if, in another side, it would be beneficial to both of them to have more people capable of getting into RISC OS coding and faster. So, I am expecting both of them to take some time to eventually provide an answer (if it will ever happen they would).

@ Theo

Record it. These days, you often don’t have to give it live. So record yourself, and if it all goes wrong, just delete the recording and start again. Or edit together different parts if you prefer.

Very true, it would be totally fine to prepare a pre-recorded presentation if that helps some of us, no worries at all. Again the goal is to preserve knowledge and share it so everyone have an easier life coding on RO.

And, beside, for things like Graeme idea we’ll need rep-recorded material anyway or the presentation may take a very long time! :)

A pre-recorded talk with the speaker there to do the Q&A/discussion live often works quite well. One neat trick if you’re on-camera for the talk is to wear the same shirt and have the same background during the Q&A as you did for the recording – that way they can’t tell it wasn’t live :)

Very true, it would be totally fine to prepare a pre-recorded presentation if that helps some of us, no worries at all.

I couldn’t see a convenient quote to grab from Theo’s post, so I’ve quoted Paolo’s response for context. I suspect that people may be overestimating the number of “off the cuff” presentations that take place in the RISC OS world (or any field). I may be wrong, but I strongly suspect that most of the apparently ad-libbed performances that we get at RISC OS shows and user group meetings are very much scripted and rehearsed.

The ones that work well are very likely to have been written and then “performed” a couple of times – even if that’s only quietly in the head of the presenter. Unless you’re very good, just turning up to do a talk on something without preparation is a recipe for complete disaster – especially if there’s facts or processes involved.

In fact, I’d venture to guess that the ones which look most “casual” and “laid back” are almost certainly the most tightly rehearsed ones of the lot.

If it helps, write it out longhand. Often it comes across better if you can do it without a full text (reading out a script can tend to the monotone), but the longhand version may help in terms of organising the thoughts, and gives you something to fall back on if your mind goes blank halfway through. It can also help if English isn’t your first language. You may find, after writing it out, you can do it second time around without the script.

I tend to write out the key points in paragraphs of short sentences, along with the steps that need to be taken in any demo that’s ongoing, whilst running through the full text in my head as I do it. This process is then repeated a couple of times, refining the written notes as required. After a couple of passes, this also gives a fair approximation of the timing for the talk.

For the talk, the notes are printed out in “large print” and referred to at suitable pauses in order to make sure that I’m still on track.

One other observation: it’s very different doing a talk on Zoom compared to doing one in person. In person, there’s feedback from the audience (even if it’s just eye contact and the fact that people aren’t visibly nodding off), which is useful when deciding whether to emphasise sections or skip through them quickly. On Zoom, there’s no feedback at all – it’s just a case of ploughing on to the end and hoping for the best… This is one reason why breaking the subject up into short chunks and doing questions after each one can be a valuable approach in an online presentation.

On the advanced section I would like to see someone show how we can build Risc OS from source code.

It’s a bit outdated, but the basic principles are there… https://heyrick.eu/blog/index.php?diary=20131105

It’s much faster on a more recent Pi, and if you’re a bit psycho you could try dumping the extracted files into a RAMdisc!

@ Rick

It’s a bit outdated, but the basic principles are there…

Are you proposing to give us a presentation for it? :)