Vector graphics, DTP and BASIC libraries

Hi all,

I know there’s lots to be done to get RISC OS onto 64bit, improve various bits and bobs of the innards and a load of stuff I don’t even understand, so I ask the following knowing that that has to take priority.

I was basically wondering if any work was going on, or being considered, to achieve the following:

• A capable, actively-developed vector graphics package, perhaps a port of Inkscape. ArtWorks development seems to have stopped beyond making it work on new hardware, and Vantage seems to have gone altogether. I asked this a year or two ago I believe, but that’s enough time for things to have changed.
• Update of the now-open-source Ovation Pro with some modern features like transparency and direct PDF input and output
• Development of BASIC libraries so people like me who are looking at dipping their toe into programming can actually build working software fairly quickly. I’ve messed around with Python on Mac OS a little bit and it’s simple to connect to an API, or to read and write to Excel files, for example, simply by importing and using the libraries that do that. The thought, as a complete novice, of being faced with those tasks is slightly off-putting.

Anyway, just trying to get a picture of what’s happening or not with those things.

@ Mciahel

I can’t answer for your first 2 bullet-points, sorry, while for the 3rd:

Development of BASIC libraries so people like me who are looking at dipping their toe into programming can actually build working software fairly quickly. I’ve messed around with Python on Mac OS a little bit and it’s simple to connect to an API, or to read and write to Excel files, for example, simply by importing and using the libraries that do that. The thought, as a complete novice, of being faced with those tasks is slightly off-putting.

RISC OS has a recent releases of Python, 3.8, 3.10 and Python is actively being maintained. It also comes with a lot of libraries and more are being ported. It supports also pip.

Have you checked it out?

I started making a collection of BBC BASIC libraries, but those are mostly old libraries, and BBC BASIC won’t be a nice candidate to query RESTFul APIs and modern things like this. There are other Library collections here and there, so it’s mostly a matter of googling tbh.

Hope this helps,

Thanks for the reply, Paolo.

The focus on BBC BASIC was because it’s well-established on RISC OS and there are more resources and support for it. I believe it can also be compiled. For that reason I have not tried RISC OS Python yet, although I’m quite happy to. Can’t seem to find a Web site detailing what works and what doesn’t, though.

In non-programmer’s terms, why would BASIC be a bad idea for modern stuff like RESTful APIs?

I believe it can also be compiled.

It can… but compiled BASIC isn’t really the same thing as normal BASIC: ABC has a few ‘quirks’.

In non-programmer’s terms, why would BASIC be a bad idea for modern stuff like RESTful APIs?

One thought, as someone who has used RESTful APIs in languages like C#, is that BBC BASIC has limited support for data structures. One of the common tricks with the JSON libraries that I’ve used is serialisation to/from classes where the properties match the JSON fields, and the types are used for working out what the data is.

255 character strings could be a bit limiting for handling even moderately bulky data, too.

All of that can be done in BBC BASIC, of course, but it won’t be as clear or simple as it is in other languages. BBC BASIC often has a knack of quickly descending into a soup of indirection operators in a way that other languages… don’t.

Thanks, Steve.

Is it basically the case that once you want to develop seriously for RISC OS, you’re looking at C?

Steve’s web site is very good for that, good tutorial for creating C applications with DDE.

;) GOTO → https://stevefryatt.org.uk/risc-os.

There is also, Lua and GNU C++, and a C++ toolbox library (available from !PackMan- package management system).

Then there’s AppBasic- Basic + Toolbox.

What BASIC is really good at – is trying out ideas.

Is it basically the case that once you want to develop seriously for RISC OS, you’re looking at C?

No: it’s a bit more complicated than that… :-)

BASIC is still good for many tasks, at least with a good Wimp library¹ to hide the mess that is the low-level API. It works well for small applications which need to handle single, identifiable amounts of data. For example, amongst my own software you’ll find Clipper for managing the contents of the clipboard, the Float interactive help client, and a collection of simple games (the source for all of them is on GitHub for the curious – follow the links above and look at the download boxes²).

The common thing here is that all of them handle a single piece of data or a pre-known data set. Clipper and Float both need to track a single block of data (text or otherwise). The games have a single, fixed game world which we know about – and can allocate storage for – when the application starts up. There will be no surprises.

What it doesn’t do well are multi-file editors, or other things which also need complex, variable sized data structures – which is more or less what RESTful APIs are about. For those, C is a much better option on RISC OS – but again, probably not the language that you’d recommend for beginners on another platform.

What BASIC is really good at – is trying out ideas.

Not really, because it still requires too much thinking and groundwork. Something like Python is far better for experimenting, because so much is there “out of the box”.

That said, I did use it recently to cobble together a test suite for PrintPDF, but in that case there was the significant benefit of code re-use.

¹ AppBasic is a good place to start for BASIC Wimp development these days – and it’s available again: http://www.stronged.iconbar.com/fjg/

² Note that I don’t use AppBasic or the Toolbox – they weren’t around when I started out, and I have too much time invested in my own library code.

or a pre-known data set

Basically there are two reasons why BASIC is inadequate here: 1. It does not handle complex datastructures smoothly and 2. it does not do automated memory management. Python and Lua do. C is actually not so hot either on these points because memory allocation has to be done explicitly, but at least it can hide the messy implementation details in libraries.

In non-programmer’s terms, why would BASIC be a bad idea for modern stuff like RESTful APIs?

As others have pointed out well, BASIC is a programming language that was:

a) designed in 1963 (at Dartmouth College), so way before the “revolution” of contract¹ based programming would explode
b) BBC BASIC it’s indeed an improvement over the original BASIC. But it’s an improvement designed mostly to teach (relatively) “good programming” rules in schools and to allow a BBC Micro’s (and later a RISC OS) user to be able to improve the “usefulness” of such systems for their specific need within the boundaries of the resources available to such systems in the 80s.

As a matter of fact, BBC BASIC never really evolved toward a fully event based programming model like other BASICs actually did (read Visual BASIC).

With that said, you can do everything in BBC BASIC, especially thanks to the assembler available, you can also extend it. But, as Steve pointed well, this would result in a lot of work. While, in Python (or Lua) all you’d need is use CURL (either as external command or as a library) to do your API request after you have created a nice dynamic data structure to represent your request and store the response in another dynamic data structure. Then, with more convenience, analyse the response for the fields and data that you want to process in your code.

So, why would one want to go through a lot of work, especially if without all the required skills to design such an infrastructure, when you can do the same in much less work using Python or Lua?

Also, remember that compiling BBC BASIC, doesn’t necessarily means completely convert it into well optimised ARM Assembly, so the results may not be what you’d expect. Moreover, when using Assembly, compiling BBC BASIC with ABC is a bit more complicated, in other words more complexity to add to all of the above.

A solution based on Python or Lua would be way more elegant and less demanding. As well as being faster to get from your idea into a working model. Lua’s performance on RISC OS are totally comparable to BBC BASIC (and in certain cases Lua can exceed by a long shot BBC BASIC performance, and yes, this one will be probably taken here as “heresy”! lol but the truth can be harsh).

Also, don’t forget that modern RiscLua handles really well modules written in GNU ASM, GNU GCC (both C and C++) and with dynamic load, which is waaaaayyyyyyy better than dealing with the old ARM assembler in BBC BASIC. Not to mention that you can get advantages from NEON and VFP and with compiled logic that is truly compiled. I mean, IMHO there is NO comparision. Python should be able to do the same, it should support dynamic binary libraries loading, I just never tried it with Python on RISC OS. (I just prefer Lua syntax to Python, so not a big Python user in general).

Lua also has GC (has mentioned well by Gavin Wraith), which is another modern tool that makes coding easier.

For the C portion of the discussion, I personally do not recommend to non-developer to learn C as first language, i think it’s better to start from Lua (or Python) that have replaced BASIC basically in modern days and then face more complex environments like C or ASM (or C++). The reason for this is simple: number of concepts to learn and master to get to a level where people can “materialise” their ideas into code. BASIC was exceptional for this, but in a world that was more contained in resources than the modern world, this is why new interpreted languages have arisen btw.

Hope this helps and that I did not use to much programmers jargon! :)

¹ Contract programming, more info: https://en.wikipedia.org/wiki/Design_by_contract

C is actually not so hot either on these points because memory allocation has to be done explicitly, but at least it can hide the messy implementation details in libraries.

And it has structures, which can be accessed through pointers to memory via the -> operator.

I can hide the messy implementation details of how I dynamically allocate memory in BASIC through libraries, too, but I’m still left to make accessing its contents readable and maintainable.

While, in Python (or Lua) all you’d need is use CURL (either as external command or as a library) to do your API request after you have created a nice dynamic data structure to represent your request and store the response in another dynamic data structure.

A very quick Google leads me to dataclasses-json on PyPI, which looks very muck like the kind of thing I was thinking of. That said, I’ve used JSON (with C# and Json.NET) and Python, but never JSON and Python together, so I’m probably not the best person to advise on this… :-)

A very quick Google leads me to dataclasses-json on PyPI, which looks very muck like the kind of thing I was thinking of.

That would work well yes (AFAIR). :)

For Lua there are many libraries, here are few examples:

https://github.com/rxi/json.lua

https://github.com/harningt/luajson

RISC OS Developments stated a while back that, among the things to come out of the Iris project as well as the browser, would be a GTK implementation and GCC 10. I don’t know whether anything has come out of these or not, but Inkscape is a GTK-based program. However, many modern programs are written in the expectation of a multi-ccre processor being available, so there’s no guarantee as to how well they would run on RISC OS. I haven’t got Artworks (as yet) and haven’t used Inkscape much, but I get the impression that it is probably Artworks that has the most features.

As for Python, there’s a need for (e.g.) the toolbox library to be properly documented—IMHO this is more important than chasing the latest Python subversion — until the next version comes out, Debian Linux is still on Python 3.8.

RISC OS Developments stated a while back that, among the things to come out of the Iris project as well as the browser, would be a GTK implementation and GCC 10.

If you are using the GCCSDK project, then you can already build GCC 10 (and GCC 12) for it to then use GCC 10/12 to build for RISC OS JFYI.

For more info on GCCSDK please refer to riscos.info

As for Python, there’s a need for (e.g.) the toolbox library to be properly documented—IMHO this is more important than chasing the latest Python subversion

Can I ask you what is preventing you (or anyone else) from starting to document it? I think Chris is doing already a lot.
I started to document Python SWI API myself and just looking at Chris’s source code, so what is the issue blocking people from documenting the ToolBox?

until the next version comes out, Debian Linux is still on Python 3.8.

And just like that :-

djp@debian12:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

djp@debian12:~$ python3 --version
Python 3.11.2

Explained here

Thanks for all the programming posts, guys! Very informative, although I think I’ll go over all your answers again so it all sinks in. Python and BASIC appeal for learning and writing stuff, although I note BASIC’s shortcomings that have been pointed out. The ‘but’ comes in here because we need more coders working to make RISC OS viable as a main OS for people and that’s either going to involve writing software from scratch, or porting it over, and that seems to be more C or its derivatives. To be fair, I might never get that good anyway.

David: ArtWorks is good, and MW Software did bring it up-to-date when he took over it. Vantage was a tad unstable on some machines, but had a modern and sublime rendering engine (probably the wrong term) which produced awesome output. It’s a shame one is not being developed at speed any more and the other has disappeared entirely, because people saw them as good reason to use RISC OS.