StrongED 4.69f9 released

Hi All,

The ninth full release of StrongED 4.69 can found on the website

This release fixes a number of bugs that have been found in 4.69f8. This is intended to be the last release of StrongED 4.69 and comes with all modes installed. This to ensure that they are compatible with 4.69f9.

The modes available from the website will be updated, where appropriate, with versions that take advantage of new features that are offered by StrongED 4.70a10 once that’s been released. Updated modes will not work with 4.69f9.

Changes in StrongED 4.69f9 (from 4.69f8)

• Fixed bug in redraw of throwback windows. If the line number was more than 6 digits wide, StrongED would freeze.

• When opening an LoF using Ctrl-F and the pointer was over the LoF the cursor line (menu line) didn’t appear.

• LoF and Throwback windows didn’t auto-scroll when keeping scroll arrows depressed. Fixed by setting scroll events to Auto-repeat.

• Fixed some Throwback related problems such as registers not being properly unstacked and using the wrong register after a rewrite.

• Clicking a throwback window for a file that had been deleted/renamed would cause an abort after a couple of clicks.

• The name under an iconised view could contain spurious characters.

• Fix for double-click selections. Code didn’t check if both clicks were on the same line, only if they were within the double-click limits.

• If text was inserted into a TaskWindow it could result in a flex block being leaked.

• Texts exported from StrongED could have different colours to those on the screen due to some flags being ignored.

• Fixed KeywordFix utility to prevent it from converting function names that match BASIC keywords to uppercase.

A full list of changes starting from the initial release 4.69f1 through to 4.69f9 is included in the download.

As always, all feedback is welcome and appreciated!

Cheers,
Fred.

The StrongED 4.69f9 download has been updated to fix issues found:
http://www.stronged.iconbar.com/archives/releases/se469f9.zip

If you already have StrongED 4.69f9, an update can be found here:
http://www.stronged.iconbar.com/archives/releases/up469f9.zip

Apart from fixing a couple of bugs that have been found, some of the resources have also been updated.

A bug fix to the TaskWindow code accidentally introduced a new bug which prevented the insertion of strings longer than 32 characters (eg Shift dragging a file to insert its pathname).

The cursor position on the Infobar wasn’t updated when (Ctrl-) Shift dragging a file to a TaskWindow.

Work on 4.70a10 showed that some of the interactive help messages were missing or out-of-date. Some of this also applied to 4.69f9 and so the help messages have been updated.

While testing the updated help messages it was found that menus in
dialogue boxes aborted when Help was active. This too has been fixed.

Saving the contents of an LoF resulted in 2 zero pains on versions of RISC OS 5 with a relocated zero page.

The Choices item in the iconbar menu had only 2 trailing dots instead of the usual 3.

The StrongHelp manual still contained a reference to the GPL even though 4.69f9 is released under the BSD licence.

As always, all feedback is welcome and appreciated!

Loading a BASIC programme into StrongEd, editing it then saving it produces a BASIC programme with all the line numbers set to zero. Although this runs fine, errors become difficult to trace. Is this intended behaviour please?

It does correctly load a BASIC programme which has all lines set to line number zero and allow it to be edited. I have tried this on programmes that are of normal length and those with more than 65000 lines.

The default is to start line numbering at 1 with an increment of 1. Just checked the release zip and that’s how it’s configured.

What values do you have in the BASIC section of the global choices? If it’s 0,0 then change them and save the options, that should fix the issue.

I have 0,0 Strip line nos Convert to text but I don’t want it to renumber unless it needs to (like Zap – for example adding a line between 1000 and 1001) as it helps to keep the line numbers the same where it can. For a programme longer than 65000 lines the renumber is no use unless set to 0,0. Hence I have it set to 0,0. Setting neither convert to text nor strip line nos and it does not seem to be able to handle BASIC progs.

After all the most likely use of an editor for a BASIC programme is after receiving ‘Error at line 17456’ or something – you need to load it into an editor and look for line 17456. Not sure how to do that in StrongEd – obviously you can’t strip line nos and converting to text leaves it with no intelligence about numbering the lines you add.

For a programme longer than 65000 lines

Ouch! Nothing compels you to use such a long program and I think it it is inadvisable. Split the program into libraries.

use of an editor for a BASIC programme is after receiving ‘Error at line 17456’

That is a reason to use throwback. The simplest way to do that is to employ Reporter and put *Report Error T in your error routine.¹ When an error occurs, StrongED opens its throwback window and you just need to click on the error for StrongED to jump to the line in the file where it happened. This does mean setting StrongED’s numbering to 1,1, because, as you say, there are no line numbers until you save.

If you insist on very long programs you cannot use such helpful facilities.

¹ Or, if you are using Basalt, you can use the THROW ERROR statement, or even invoke Reporter’s throwback with REPORT ERROR EXT.

Nothing compels you to use such a long ..

It’s not quite so simple as that – breaking down a complex Draw file into a list of BASIC commands can generate a 300000 line programme. So very occasionally I need to do this – a few quick and simple edits and a revised Draw file is produced (a few line colours changed for example).

Using throwback because the editor can’t show the line numbers is a horrible hack. I think, fundamentally, StrongEd cannot handle BASIC programmes as an editor.

can generate a 300000 line programme

While I understand the reason for the extremely long program, isn’t it you who is relying upon “undefined” behaviour, by exceeding the line number limitations of the language?
As such, while it works in BASIC, I’m not sure it is justified to fault StrongEd for not coping?

I’m struggling to understand the use case for the really long program. Why would you break a Draw file into a sequential list of BASIC commands? Why wouldn’t you write something which took the Draw file (or indeed an intermediary file or array of drawing objects) in a block of memory, and interpreted them line by line into drawing instructions (probably plotting with SYS “OS_Plot” or suchlike).

Or indeed use draw file’s own render routines, and then call again to re-render it when finished? This at least allows the option of hardware acceleration.

breaking down a complex Draw file into a list of BASIC commands can generate a 300000 line programme.

That is a list of statements (sic), but it is not a program that BASIC can deal with natively. You can use a “horrible hack” to make it run by setting all the line numbers to 0, but you should not expect the debugging support that BASIC normally provides if you do that.

the editor can’t show the line numbers

StrongED can show line numbers, but you have chosen not to, because programs exceeding the BASIC limit will not load.

My suggestion would be to swap to 0,0 when you are dealing with your special Drawgen (?) files, and back to 1,1 with normal programs. Fred might even suggest making a button to do that. ;-)

Using throwback because the editor can’t show the line numbers is a horrible hack.

StrongED can show the line numbers if you want but line numbers are not really necessary with BBC BASIC. Just look at Edit, that doesn’t show line numbers by default either.

As for throwback – it’s incredibly useful. For example, StrongED’s source is split into 33 (BASIC assembler) files. Errors during assembly are reported using throwback which is much more convenient than finding the error file+line manually.

I think, fundamentally, StrongEd cannot handle BASIC programmes as an editor.

Of course it can. Lots of people, myself included, have written BASIC programs using StrongED. The fact that it doesn’t handle your particular need well, doesn’t discount it as an editor for BASIC programs.

At the moment you’d need to have line numbering set to 1,1 and temporarily change it to 0,0 for overly long files. It could be made somewhat easier by making the warning window for ‘Line number too big’ into a proper error window.

Then an additional button could be added to allow you to save the file with 0,0 numbering. This would require at least RO 3.5 but I don’t think StrongED runs on 3.1 anymore so probably not a big deal.

Why would you break a Draw file into a sequential list of BASIC commands? Why wouldn’t you write something which took the Draw file (or indeed an intermediary file or array of drawing objects) in a block of memory, and interpreted them line by line into drawing instructions (probably plotting with SYS “OS_Plot” or suchlike).

Because the aim is to create new drawfiles programmatically, not to render existing ones. AIUI, Chris’s program generates a new drawfile from the long BASIC code, perhaps after he’s tweaked a couple of lines.

However, I would suggest that this could be an indication that the concept is fundamentally flawed. A better approach would have been to have written a simple parser in BASIC that could process a series of instructions in a text file, and then dump drawfiles out to that text-based format – a bit like CCRes does for Templates. You could then use it for putting drawfiles into source control…

A better approach would have been to have written a simple parser in BASIC

Yes – that makes a lot of sense. Generate a data file, large as I like, and parse it. I’ll think about it. It makes it slightly more awkward to do a rectangle with calculated coordinates and to have constants – e.g. Rectangle(A+10,b+20*c,w,h) – but not impossible.

The thing I find difficult is that if you edit a BASIC programme [with Strip Line Nos unticked] with line numbers showing, add some lines (which appear with no line numbers) and then save the programme, you end up with a programme that has several lines with the same line number. BASIC seems to be content with this so perhaps I should be content too.

The format of Drawfiles, using chunkfiles, is very much of its time. It has some drawbacks: not readable, difficult to edit, does not support recursive interpretation, no abstraction. That is maybe why there have been so many tools to translate Drawfiles to other, preferably textual, formats; e.g. DrawGen (Basic, C, Fortran), AppBasic, Lua and doubtless others. At least with a textual format you can make up for lack of abstraction by using macros. Drawfiles are often far larger than they need to be, as a consequence of these limitations. It is a shame that Acorn was so focussed on the GUI that they did not think more about production of graphics programmatically rather than by hand. The same remarks go for Paint and most of the early desktop publishing software. I guess chunkfiles are easy to merge; what other virtues spring to mind?

I guess chunkfiles are easy to merge; what other virtues spring to mind?

A fair few of my files use binary chunks. They are basically a memory dump to file. Easy to save and reload, and without any of the headaches of parsing a textual file which will always need to be continually sanitised.

For the ability to generate files by software, my VeroDes software uses a textual file format, and there’s a huge amount of code reading the board description files and ensuring the data that is present makes sense.
…
Which could be replaced with three lines of code if it was a binary chunk.

headaches of parsing a textual file

A good point. Still, some mugtrapping is still needed for binary chunks, and textual formats can be chosen that minimize, or even do away with, parsing. The data format for Petrobras’s geological surveys eventually became Lua.

Still, some mugtrapping is still needed for binary chunks,

Certainly, to deal with file corruption, empty files, etc.

and textual formats can be chosen that minimize, or even do away with, parsing.

[Citation Needed]

;-)
Wherever a human is involved, a parser will need to attempt to make guesses as to the intentions of said human. It can either be inflexible as most computer language parsers are, or extremely flexible as most HTML parsers are.
[case in point #1: OvHTML has a fair bit of special case code in its parser to deal with some of the insane stuff that has turned up “in the wild”; including bodging the text colour if it is specified to be exactly the same shade of grey as the background (yup, a site really did that)
case in point #2: omit one single closing brace from anywhere in a C program, then watch the compiler have a nervous breakdown as it knows something is wrong but carries on regardless just so your screen fill fill up with hundreds of scary messages]

The data format for Petrobras’s geological surveys eventually became Lua.

Whoa. Petrobras really overspecified their data format then! :-)

The thing I find difficult is that if you edit a BASIC programme [with Strip Line Nos unticked] with line numbers showing, add some lines (which appear with no line numbers) and then save the programme, you end up with a programme that has several lines with the same line number.

In StrongED 4.69f9 and above you can renumber a file using c-E,c-R. This saves the text to a temporary file, executes a small Exec file and reads the result back in. The only drawback is that there seems to be no way to get rid of the command window that opens.

At the moment you’d need to have line numbering set to 1,1 and temporarily change it to 0,0 for overly long files. It could be made somewhat easier by making the warning window for ‘Line number too big’ into a proper error window.

The error window is now implemented so you can save overly large files with 0,0 for the numbering while leaving the default at 1,1 (or whatever is preferred).

StrongED can show the line numbers if you want but line numbers are not really necessary with BBC BASIC. Just look at Edit, that doesn’t show line numbers by default either.

Looking (very briefly – OMG!) at the BASIC source, it looks like you would be relying upon the undefined behaviour of not giving any line numbers. BASIC deals with lines of code sequentially (searching for PROC/FN entry points), so the line numbers are not strictly necessary for a functioning program, however… GOTO/GOSUB can’t logically work. TRACE outputs what, never-ending “⁰”? Plus error reporting will fail (there’s an error … at line 0!).

Edit removing line numbers is not doing so because they are unnecessary, it is doing so because Edit isn’t smart enough to be able to intelligently renumber if you had lines 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20… and you needed to insert another line after line 16. It could be…difficult. So BASIC just strips off all the line numbers and recreates them when the file is saved – note that bit in italics.

This saves the text to a temporary file, executes a small Exec file and reads the result back in.

If StrongEd understands BASIC programs, why do you have to do all that? Can’t you just whip through each line and twiddle the line number bytes? The line gives its length, just step through each until you get the end of program marker.

[Citation Needed]

If you make a file, say mylist, returning a list like this

return { item1, item2, ... }

label = value

x = dofile (mylist)

Whoa

It should be added that the evolution from Petrobras’s data format to Lua took place over some years.

I forgot to say that chunkfiles are also good for re-ordering items and grouping them. Am I right in thinking that the Draw module simply renders each draw-object in turn, so that later objects in the list occlude earlier ones? If so moving an object to the front means bringing it to the end of the list of draw-objects.

@Rick You have so missed the point.

StrongED and Edit are text editors. BASIC line numbers and tokens etc are part of what some people might call a bytecode version of that text. You cannot edit that bytecode directly, even with Zap or the BASIC line editor. What you write has to be tokenised ¹ somewhere, and doing so on saving is a sensible choice. So is tokenising a line on entry. Either method can have problems with inserted lines, but the option to sequentially number on saving removes that. Probably thousands of programmers have been doing that for decades, so there should be no reason to panic now.

You are right that actual line numbers are only there for the things that you mention, with the addition of RESTORE, but the only essential is error reporting. If programs are renumbered 1,1 there is a one-to-one (!) correspondence between the BASIC tokenised line number and the physical line of the text file. This makes identifying the error line in the text easy, for throwback or otherwise.

The singular problem raised in this topic is that you cannot have line numbers greater than &FEFF without a fundamental change to BASIC. This is not a progamming problem, because code can be included from libraries, each with independent line numbering. As Fred had now provided a very reasonable work-around for this singularity, is there any point in going on?

¹ Tokenising and Detokenising is done using the routines in the BASIC module. Edit finds these and stores the addresses in the system variables Edit$Tokenise and Edit$Detokenise, so they are available to any program, but I expect StrongED does its own thing to find them.

This saves the text to a temporary file, executes a small Exec file and reads the result back in. The only drawback is that there seems to be no way to get rid of the command window that opens.

My first thought was to do this:

Run <StrongED$Tmp_ModePath>.Tools.Renumber { > null: }

But that doesn’t work, so I guess *Exec must be setting output back to the screen. You can avoid the command window by doing this instead:
BASIC { < <StrongED$Tmp_ModePath>.Tools.Renumber > null: }

Of course you won’t see any error messages this way either.

What you write has to be tokenised 1 somewhere, and doing so on saving is a sensible choice. So is tokenising a line on entry.

In StrongED (and Edit) programs are detokenised on loading and tokenised on saving. This has the advantage that it’s plain text during editing meaning that no special case needs to be created.

The drawbacks are that line numbers are not handled automatically (even if they aren’t stripped you still need to number new line manually) and that editing crunched programs often ends up corrupting them.

Zap detokenises a line when you start to edit it and tokenises it when finished. This mostly avoids the problems with line numbers and crunched programs but at the cost of more code.

One of the reasons why they handle BASIC the way they do, is the difference in program architecture. Zap uses a central core module with additional modules for various languages. Each module can do pretty much what it wants as long as the interface with the core module (and ZapRedraw) is correct.

StrongED uses a single engine, for all languages, that is configured using the various mode files. Because of this single engine it’s more convenient to have as few exceptions as possible which is why BASIC is handled the way it is. The only exception right now is Dump mode as binary files need to be handled differently.

if StrongEd understands BASIC programs, why do you have to do all that? Can’t you just whip through each line and twiddle the line number bytes? The line gives its length, just step through each until you get the end of program marker.

Line numbers are only present when not stripped, and in that case they are part of the actual text. Whilst it would be possible to write a parser to go over the text and update any line numbers (and even line number references) it’s a lot easier to throw it at the BASIC interpreter. If it wasn’t for the command window popping up it’d be completely transparent.

Run <StrongED$Tmp_ModePath>.Tools.Renumber { > null: }

That was one of the first things I tried.

You can avoid the command window by doing this instead:
BASIC { < <StrongED$Tmp_ModePath>.Tools.Renumber > null: }

Thanks, that works!
Now for a sure-fire way to avoid any errors. :-)