StrongED 4.69f9 released
Pages: 1 2
Fred Graute (114) 645 posts |
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)
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 Graute (114) 645 posts |
The StrongED 4.69f9 download has been updated to fix issues found: If you already have StrongED 4.69f9, an update can be found here: 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 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! |
Chris Hall (132) 3554 posts |
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. |
Fred Graute (114) 645 posts |
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. |
Chris Hall (132) 3554 posts |
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. |
Steve Drain (222) 1620 posts |
Ouch! Nothing compels you to use such a long program and I think it it is inadvisable. Split the program into libraries.
That is a reason to use throwback. The simplest way to do that is to employ Reporter and put If you insist on very long programs you cannot use such helpful facilities. 1 Or, if you are using Basalt, you can use the |
Chris Hall (132) 3554 posts |
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. |
Rick Murray (539) 13806 posts |
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? |
William Harden (2174) 244 posts |
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. |
Steve Drain (222) 1620 posts |
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.
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. ;-) |
Fred Graute (114) 645 posts |
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.
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. |
Steve Fryatt (216) 2103 posts |
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… |
Chris Hall (132) 3554 posts |
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. |
GavinWraith (26) 1563 posts |
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? |
Rick Murray (539) 13806 posts |
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. |
GavinWraith (26) 1563 posts |
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. |
Rick Murray (539) 13806 posts |
Certainly, to deal with file corruption, empty files, etc.
[Citation Needed] ;-)
Whoa. Petrobras really overspecified their data format then! :-) |
Fred Graute (114) 645 posts |
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.
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). |
Rick Murray (539) 13806 posts |
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 “0”? 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. |
Rick Murray (539) 13806 posts |
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. |
GavinWraith (26) 1563 posts |
If you make a file, say mylist, returning a list like this where items are either values (such as numbers or strings or lists) or labelled values in the form then Lua can read this in directly, with no separate parsing, using . Then the i-th item will be x[i] , and for labelled items the value will be x[label] . In effect, the data format is executable code.
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. |
Steve Drain (222) 1620 posts |
@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 1 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? 1 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. |
edwardx (1628) 37 posts |
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: Of course you won’t see any error messages this way either. |
Fred Graute (114) 645 posts |
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.
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. |
Fred Graute (114) 645 posts |
That was one of the first things I tried. You can avoid the command window by doing this instead: Thanks, that works! |
Pages: 1 2