More about Bob

ArmBob, based on Bob 1.5, was written in 1994. David Betz went on to clean up Bob in a later version, whose sources are available at github , in 2001. You can download these, modified for the Norcroft C compiler, from my website together with the binaries bob, bobc, bobi and bobmerge in the bin directory. Bob works by compiling textual source (.bob files) to bytecode and then interpreting the bytecode. bobc or bob -c compile source text to bytecode files (.bbo), which can be run with either bob or bobi . bobmerge list output merges a list of .bbo files into a single output file. The file list contains the pathnames of the .bbo file inputs, each on a separate line.

It is interesting to compare Bob with Lua. Bob is definitely object-oriented, whereas Lua is not, which is maybe why I find Lua easier. But others may have different tastes, which is why I have put these sources up without adding any extra RISC OS sauce of the kind that comes served with ArmBob. So the newer Bob comes with no way to call SWIs or interact with RISC OS. The obvious way to do this is to add a new built-in object with attributes a vector r of integers to represent registers and a method sys(swi) for calling SWIs and some assembly glue using OS_CallASWIR12.

Unfortunately the documentation is rather sparse. The indications are that Bob should run a bit faster than BASIC. Bob’s similarity to C++ suggests that concocting a compiler for Bob might be more straightforward than for Lua – or is that wishful thinking?

By coincidence I took some Archive mags up to bed with me last night for late night reading and fell asleep part way through Vol. 25 No 5 :-)

I am not surprised. Poor Gavin Smith had not discovered yet that an opening brace ({) causes Impression-X to skip the next word, so the code sections throughout Archive Vol. 25 No 5 are mostly gibberish – and not just in my article. Seeing how important braces are in so many programming languages that is a problem. I have never used Impression and was unaware of this effect. I do not know what version number David Betz assigned to the newer tidier Bob. It is so rare to find C source code that can be tweaked to compile on RISC OS that I thought it worth announcing, in the hope that somebody would give it a go.

I have never used Impression and was unaware of this effect defect.

FTFY.

I’m not an Impression user, so can only go by what’s been written here… however if this is correct then the software is horrendously broken.
When importing text files, there should be absolutely no unexpected side effects unless a very clear “enable” sequence begins the file. It should strip out (or fault) control codes, obey tabs and newlines, and then – as faithfully as possible – introduce the text content into the document.

The idea of using { to skip a word is incomprehensible. It sounds to me like a broken parser that can handle {embedded codes}, but which fails to backtrack upon encountering an invalid code. Another reason why there should be an explicit {enable} code. The software shouldn’t be making assumptions about what the user is importing – there’s already enough brokenness in the world regarding character sets and newlines alone!

The idea of using { to skip a word is incomprehensible. It sounds to me like a broken parser that can handle {embedded codes}, but which fails to backtrack upon encountering an invalid code.

It’s almost certainly trying to interpret DDF codes in the text, which isn’t unexpected given that by default Impression exports text with DDF codes embedded¹ – a massive pain, as one has to remember to untick the option every time, unless there’s an option that I’ve missed somewhere.

In fact, on experimentation, yes – that’s exactly what it’s doing. So if you import

This is some {bold on}bold text{bold} in a sentence

then you’ll get “This is some bold text in a sentence” imported. To actually get “This is some {bold on}bold text{bold} in a sentence” imported, you’ll need a file containing

This is some {\123}bold on}bold text{\123}bold} in a sentence

so that the opening braces are escaped with their character codes.

I can’t help but note that Ovation Pro uses separate filetypes for both DDF and its own DDL, reserving “Text” for, er, plain text… Or that the Impression Publisher manual doesn’t seem to mention this potentially unhelpful feature in either section where file import is discussed.

ETA: Or even the really odd side effect that if one exports the second example above whilst “With styles” is unticked, and then re-imports it, it gets converted into the first example. DDF import is a nice idea, but it really should be optional and not the default behaviour…

¹ “With styles” in the Save text story dialogue.

ARMalyser outputs in both Impression DDF and Ovation DDL, and I had lots of fun trying find out what worked in the absence of much documentation.

When you drag a merge command to Impression from Impact, it is sent as a text file. An example:
{merge “:Impact.Addresses Fetch Name”}

Ovation Pro can interpret text files as DDF, if you modify the !TransDDF boot or run file, but I chose to enhance Impact so that it sends properly-filetyped DDL to Ovation Pro instead.