[BBC Basic] INSTALL question

Hello

I am learning BBC basic on both RiscOS and Windows.
Under BBC Basic for Windows, if I want to load external functions and procedures from a file located in the same directory as the current bbc basic file, I use:
INSTALL @dir$ + “file_name”

This does not work under RiscOS.

So, my question is simple: how do I do this under RiscOS BBC Basic?

Thank you for your help

LIBRARY "filename"

You can’t do the in-the-same-directory thing from within BASIC, though. Either enter the full pathname or use the ‘Set directory’ option from the Filer’s menu.

Oh, and: BBC BASIC for Windows is a very different language, incompatible in multiple exciting ways (like this one). Learning both at once is probably an exercise best left unattempted. I’d recommend dropping it and sticking to RISC OS, since BASIC is actually useful in many situations on RISC OS, and there are very few real alternatives, whereas it’s just another scripting language on Windows (and with highly icky syntax at that). I’ve never understood what people see in BASIC for other systems (other than nostalgia) when the likes of Python and Ruby are available, and come with all the whizz-bang stuff built into their syntax rather than bolted onto an unstructured, barely procedural language from fifty years ago.

Somewhere around there was module that set <BASIC$Dir> when a BASIC file was run, so you could do

LIBRARY "<BASIC$Dir>.file_name"

and it would generally work. However, I think it was probably ©Acorn User (most likely *Info), and so the 32-bit version I use is probably completely undistributable.

Wow, Martin, troll bait much? ;-)

There is an application called ‘!MultiTask’ (available from !Store) that automatically sets the csd (currently selected directory or ‘@’) to the last opened directory window or last opened BASIC programme and thus allows ‘LIBRARY “file_in_same_csd”’ to work. ALso ‘SAVE “name”’ for those too lazy to use a full pathname (like me). Thus:

If you load a RISC OS BASIC programme file into BBC BASIC for Windows then the token for ‘LIBRARY’ under RISC OS is shown as ‘INSTALL’ under BBC BASIC for Windows as the functionality is similar.

Sigh.

The system does know where your program was loaded from, but doesn’t automatically present it to you. Instead you must call OS_GetEnv to the command line that launched your program and extract your pathname, most easily with OS_ReadArgs, before stripping the program’s leafname.

The lines necessary are slightly difficult to remember, so most people rely on their BASIC program being launched by a !Run file, as in the above screenshot. Obey files set the system variable <Obey$Dir> to the directory, so often the BASIC program will just read that.

However, to do it ‘properly’ do something like:

DIMQ%255:SYS16TOA%:SYS&20049,"BASIC,quit/K",A%,Q%,256TO;A%
IFA%AND1:ERROR1,"Where am I?"
SYS&2002B,Q%!4TOA$:J%=0:REPEATI%=J%:J%=INSTR(A$,".",I%+1):UNTILJ%<1
A$=LEFT$(A$,I%-1)

PRINT"I'm in "A$

Yes, I do write BASIC like that. No, I wouldn’t recommend it.

Edit: You can read <Obey$Dir> like this:

DIMQ%255:SYS&23,"Obey$Dir",Q%,256TO,,Z%:Q%?Z%=13:A$=$Q%

as in the above screenshot

In the above screenshot, the BASIC file ‘DiscCat’ is loaded into BASIC by dragging it with the mouse from a filer window onto the MultiTask icon on the icon bar, not by being run via a !Run file.

MultiTask neatly avoids all the complication of reading the environment (to see where the programme came from) by sitting on the icon bar and making sure that the csd is always set to the last directory you used and so BASIC, in single tasking mode (i.e. while you are editing and developing a programme), can assume a ‘SAVE’ will put things where you want.

Once you have developed your programme into an application, you need to ensure that LIBRARY statements etc. explicitly refer to the full pathname.

If you just double-click the BASIC programme to run it however, MultiTask will make sure the csd is set to where you double-clicked it from and it will stay that way until you QUIT the programme becuase it will be single tasking until then.

If you run a BASIC programme from a task window or as an application (with a !Run file etc.) then the csd could change while it was running and all the normal rules would apply.

I think there are couple of things I can add here.

The first is the use of *Prefix, which is provided by the DDEUtils module and is supplied with RO5. This sets a local path for a program separate from anything else. Until quite recently Basalt set this path automatically to the path of the program file. Unfortunately, I had a bug reported with Font_FindFont that was traceable to this, so it no longer does it. If it were to continue to do so then a programmer would have to explicitly unset the path with a naked *Prefix.

Basalt does have something else to offer: INFO$(1) returns the path to the file (without ‘.’). So the OP could do:

 OSCLI("Prefix "+INFO$(1))
 LIBRARY "filename"
 <or>
 path$=INFO$(1)
 LIBRARY path$+".filename"

I am learning BBC basic on both RiscOS and Windows.
Under BBC Basic for Windows, if I want to load external functions and procedures from a file located in the same directory as the current bbc basic file, I use:
INSTALL @dir$ + “file_name”
This does not work under RiscOS.
So, my question is simple: how do I do this under RiscOS BBC Basic?

There is an alternative. ;-)

If you are writing a proper application (doesn’t need to multitask) then it will be in a directory prefixed with an !, you can set a pointer to your current directory in the !Run file and then use that.

In other words:

1. create a directory called !MyApp (where “MyApp” is a name suitable for your program).
   
   
2. within this directory, place your BASIC program and its library. By convention the main program is called !RunImage, but it doesn’t have to be.
   
   
3. create another file called !Run which must be set as an “Obey” file (from the command line, *SetType blahblahetc.!Run Obey will do it).

This Obey file should read:

Set MyApp$Dir <Obey$Dir>
WimpSlot -min 128K
Run <MyApp$Dir>.!RunImage

Alter “MyApp”, “!RunImage”, and the minimum amount of memory to start with according to your application.

Then, in your program, you can use:

LIBRARY "<MyApp$Dir>.mylib"

Every folder under RISC OS that begins with a ‘!’ is in fact a directory full of stuff, all kicked off by the !Run file when you double-click on the directory itself.
Hold Shift while double-clicking to look inside some, get an idea of how this works.

You should also have a cute icon for your directory. Copy one from something you already have and modify it in !Paint. Note that the sprite name should be changed to be the same as your application directory.

Terse details here: http://www.riscos.info/index.php/Programming_Conventions#Application_Structure

More complete details here: http://www.apdl.co.uk/riscworld/volume9/issue5/wimpprog/chap02.htm
And here: http://www.steve-potts.me.uk/rot/apps.html
And here: http://www.tofla.iconbar.com/tofla/gen/008/index.htm

Dear all

Thank to all of you for your answers.
It has been an opportunity to learn more about application structure.
The solution of Rick is just what I needed.

Cheers

François

BBC BASIC for Windows is a very different language, incompatible in multiple exciting ways (like this one). Learning both at once is probably an exercise best left unattempted… it’s just another scripting language on Windows (and with highly icky syntax at that).

Must we get this kind of comment every time BBC BASIC for Windows is mentioned? It is not a “very different” language; yes there are a few minor differences which can usually be worked around without difficulty, but generally the degree of compatibility is very good. And as for being a “scripting language”, what nonsense!

In the specific respect of INSTALL and LIBRARY the history is interesting. Originally, in ARM BBC BASIC both INSTALL and LIBRARY were statements (i.e. both could be used from within a program), the difference being that INSTALL installed the library ‘permanently’ (for that session) and LIBRARY installed it temporarily (on the heap). BBC BASIC for Windows implements INSTALL in a compatible way, but not LIBRARY.

At some point in the development of ARM BBC BASIC a problem was discovered with the use of INSTALL from a running program and it was changed from being a statement to a command, meaning that it can be issued from the immediate-mode prompt but not from within a program. If anybody knows, I’d be interested to learn what the problem was that resulted in this change. I can only guess that it was something to do with loading the library above HIMEM (in BBC BASIC for Windows if you raise HIMEM any libraries that were previously installed are discarded).

Richard.

Must we get this kind of comment every time BBC BASIC for Windows is mentioned?

Oooh, you fell for the troll bait. ;-)

If anybody knows, I’d be interested to know what the problem was that resulted in this change.

It’s right there in the source archive… a file that’s 16 years old and since I’ve seen it before was probably doing the rounds on the BBS scene way-back-when. Surprised you’ve not seen it before.

(2) INSTALL was treated as a statement permitting a variety of lethal, innocent
looking BASIC programs along the lines of:

10 INSTALL"foo"

which wipes out a substantial portion of the interpreter’s stack: an error,
local array or any structure causes mayhem. 1.05 series interpreters treat
programs like this as bad: an error is issued if the INSTALL is encountered.
INSTALL is now implemented as a command (and it is therefore impossible to edit
the line containing an INSTALL to the state that a 1.04 interpreter left it).

INSTALL … wipes out a substantial portion of the interpreter’s stack

As I understand it, INSTALL lowers HIMEM by an appropriate amount and then loads the library between the new value of HIMEM and the old one. To that extent it’s no different from what MODE does in the 6502 version of BBC BASIC, i.e. it lowers HIMEM to make room for the display memory. And surely lowering HIMEM and *LOADing a file above it (which I presume ARM BBC BASIC allows you to do) is just as destructive of the stack?

The implication, in all those cases, is that it’s only safe to execute the code when the stack is empty, i.e. in the ‘main program’ rather than in a function or procedure, and not inside a loop. But generally that isn’t an inconvenience: you almost certainly want to execute INSTALL near the beginning of the program anyway.

Changing INSTALL from a statement to a command seems to be a case of throwing the baby out with the bathwater. If the risk of destroying the stack is considered too serious, then surely the solution is to issue an error if it’s executed when the stack isn’t empty?

Richard.

And as for being a “scripting language”, what nonsense!

I am curious. What would you personally classify BBC BASIC as, if not a scripting language? FWIW, I consider it to be very much a scripting language on RISC OS too. The big differences between BASIC’s situation on RISC OS and that on Windows are:

1. The BASIC interpreter is in the RISC OS ROM, meaning it can be used anywhere without installing any software (or even without a hard drive at all).
2. Absolutely anyone with a RISC OS computer can be guaranteed to have it.
   1. Although this is as much a curse as it is a blessing. BASIC has become very difficult to add new features to, simply because this very universality is so highly prized that programmers are loath to use them for fear of losing it.
3. Most alternatives, such as the likes of Python, are unavailable or impractical.

It is, in short, actually important.

That said, I’ll admit that part of the reason I wrote that paragraph was just to see if you’d pop up to get all defensive again. You’re treading a very fine line between contributing to this forum and being to the detriment of it.

You’re treading a very fine

At least he isn’t being impolite

What would you personally classify BBC BASIC as, if not a scripting language?

By my understanding, a ‘scripting language’ is a language which lets you automate a sequence of commands that you could have entered one-by-one at a command prompt, typically shell commands. Scripting languages are not intended for, nor well suited to, programming tasks such as carrying out calculations, drawing graphics or real-time applications. I would classify BBC BASIC as a ‘general purpose programming language’ because it is well-suited to such tasks. Of course BBC BASIC, like virtually all languages, can be used to automate shell or other Operating System commands, but that is not its principal purpose.

If you want evidence of the ‘general purpose’ nature of BBC BASIC you need look no further than Rosetta Code, at which more than 500 of the 660 programming tasks have implementations in BBC BASIC, ranking it 14 out of the 490 languages listed:

Richard.

.. if not a scripting language?

See http://www.riscos.info/index.php/Scripting .

Just to throw my old €0,02 coin into the mix.. I personally see a scripting language as one where the source and “executable” are the same thing; as some sort of interpreter acts directly on the scripted source.

Thus, BASIC fails the scripting language test because source is tokenised. It can be held as text, but that isn’t the native format, just a convenience. When you TEXTLOAD a program, the first thing BASIC does is tokenise it. [note for pedants: I am specifically talking about ARM BBC BASIC; could care less how Brandy does it…]

Examples of scripts – Lua, perl, php, javascript… There is some muddling here where PHP can be processed and turned into a sort of p-code, but that is a speed trick, you don’t get the source PHP from the processed version. You edit the text file containing the source, and the interpreter reloads (and processes if necessary) that.

Very far from a script language – C and Pascal, etc. There is no direct relationship between the source and the execution. The source is read and a variety of intermediate files created. These are mashed together to make the final executable. While the source determines what the executable is, once the executable has been produced, the source is no longer relevant for the functioning of the software. Thus, it isn’t a scripted language (but it might in turn be a scripting language!).

(^_^)

BTW, from the Scripting link:

The term scripting language is vague, but the languages described by it tend to have the following features:

• Memory management is automatic.

Isn’t it this under Java?
Ditto a lot (not all) of VisualBasic (which can create native code EXEs).

• They have powerful string-processing and pattern-matching facilities.

Depends on what libraries you have. RegEx is everywhere. One day I might even manage to read and understand a regular expression.

• They can read system variables and execute commands.

_kernel_getenv() [RISC OS], getenv(), system() …

• The words on the command line are available as an array of strings.

int main(int argc, char *argv[])

• They support arrays or lists in various forms without the need for specifying a maximum number of components.

It is usually implied by what you are setting the array to, for example:

$rgb = array('red', 'green', 'blue');

Adding an extra element will auto-expand the array; but what should happen if you want to read element 11 of that array? Should the array be resized to allow you to read element 11 just as it would be resized if you wanted to write element 11; or should it be faulted because the programmer probably meant ‘1’ but made a typo?
This is where stricter control of arrays is useful. Things that happen behind your back can trick you by not doing what you want when you want it; plus can make you a lazy programmer. You don’t always need to pay attention to array bounds in Java when you use the clever “for” loop, nor PHP when you look at something as a collection and use “foreach” on it. Then if you are handed a lower level programming language and you continue being lackadaisical with array bounds…well, we know how that story ends don’t we?

[note: “you” is third-party you, not YOU specifically; I’m not going to write “one is” and “one does” as that sounds horribly pretentious!]

I’m a registered user of BBC Basic for Windows, and also a user of ARM Basic. Many years ago, I also used Z88 Basic – remember that ! With a little care, BBC Basic programmes can be written so that they run on both of the major branches of BBC Basic (Z80/8086 and ARM). I’ve tended to use BB4W recently at work for various text manipulation programmes, since I retired my work old Risc PCs from regular use.

Just to say well done to Richard for keeping BB4W going for all these years.

And also well done to the ROOL developers – thanks to you I now have an RPi on my desk at work, that I use for many tasks – including running a whole load BBC Basic programmes at the speed of light.

My message is that if everybody works together then RISC OS has a good future as a niche and fast ARM operating system on the RPi and other emerging ARM based devices. United we stand…

Ralph

I’m a registered user of BBC Basic for Windows, and also a user of ARM Basic. Many years ago, I also used Z88 Basic – remember that ! With a little care, BBC Basic programmes can be written so that they run on both of the major branches of BBC Basic (Z80/8086 and ARM).

Indeed. While BB4W wouldn’t be my language of choice for a lot of Windows-based stuff, it’s more than capable of cross-platform code if you’re not interested in operating within a windowed environment. I can’t remember if I’ve posted this link before, but here’s an article that was written at the request of Archive’s editor but then never published about one such cross platform, full screen use of BBC BASIC in a theatre a few years ago. Sorry, Richard — full-screen is sometimes a necessity…

And also well done to the ROOL developers – thanks to you I now have an RPi on my desk at work, that I use for many tasks – including running a whole load BBC Basic programmes at the speed of light.

I have s suspicion that, were I to have needed to come up with the system described above today, it might well have remained on ARM BASIC and used a couple of Raspberry Pis to provide the hardware backup…

I can’t remember if I’ve posted this link before, but here’s an article that was written at the request of Archive’s editor but then never published about one such cross platform, full screen use of BBC BASIC in a theatre a few years ago

Most interesting; I don’t remember seeing it before. Quoting from the article:

As this article was written in a week where the BBC was promoting the recovery of colour versions of Dad’s Army from black and white film, which was done using software written in BB4W, it’s interesting for us RISC OS users to ponder where else our favourite programming language may also still be performing a public – if invisible – role.

Another ‘public’ application which many people may be unware of is the ‘Free-D’ camera tracking technology used daily for the ITV1 television news (everything in the studio, apart from the presenters and the desk they sit at, is virtual). The installation and calibration software is written in BBC BASIC.

Richard.

Another ‘public’ application which many people may be unware of is the ‘Free-D’ camera tracking technology used daily for the ITV1 television news

That still done by Radamec? Or were they auto-cam-droids for the Beeb?

That still done by Radamec?

They licensed the design from the BBC, yes. Subsequently they were taken over by Vinten.

Richard.