The one I just made I considered it a *weakness* that I didn't bother
trying to skip over comments and quoted strings.
I'm also not even checking if the new output lines exceed the 255 (or
whatever it is) length limit.
It doesn't care what ranges of numbers you want to use, meaning it will
happily generate invalid large line numbers that the interpreter
wouldn't accept, but also doesn't care if you want to move the output to
start at line 8000 regardless what the original line number were. It's
strange to me that any renumberer would have had that limitation.
One thing someone on the facebook group convinced me to deal with is
when a statement references a line which doesn't exist. There is no
definitely correct way to handle that, but at least you can make sure
the output runs.
I just have it generate a new additional line number after the
previously highest generated number, and writes both a warning to
stderr, and if the specified stepping value leaves room it also writes a
comment into the generated basic on the next line.
So, say the orginal input:
ends at line 200,
line 200 is 1340 after renumbering,
includes a line like
20 GOSUB 500
I output
50 GOSUB 1350
51'50: 1350 was 500
If there were multiple such numbers on one line, they are all also
documented on the same following line.
20 ON X GOSUB 500,600,700
50 ON X GOSUB 1350,1360,1370
51'50: 1350 was 500, 1360 was 600, 1370 was 700
It ensures the generated output runs, and at least documents what
happened right in the file, but it totally borks the original intent of
lines like that, which is to merge in modular blocks of code like
printer drivers. Not only are the new lines different, they aren't
pointing to different spaced out blocks like the originals were.
The only real fix for that I see would be to renumber only after you
merged whatever you were going to merge.
It could be a non-default option though, where if you want you could
tell it to preserve non-existing numbers. Up to the user to take
responsibility for going out of their way to invoke that option.
Maybe the way to deal with that is provide a way for the user to provide
directions what to do for ranges of numbers.
So maybe a commandline option where you indicate "For any number
encountered in the range 500-800, shift them to start at 2000"
Maybe by only applying an offset without changing the stepping, or maybe
by applying the same new stepping. Either way is probably ok so long as
you can then do the same thing to the file that has the 500-800 bock in it.
I think that's doable and not too crazy.
--
bkw
On 6/17/21 7:47 PM, Peter Noeth wrote:
I have found bugs / limitations in all the renumbering programs on the
Club100 site, including the Compuserve Archive. Biggest problem with
these programs is they will only act on a ASCII BASIC source file (.DO),
so you can easily run into RAM space limitations depending on the size
of your source file. And some won't renumber comment lines starting with
the "single quote" shortcut and others won't renumber comment lines at all.
The best renumbering function (that works the closest to the full
Microsoft BASIC's) is the one contained in the ROM2 Option ROM. But it
too has the limitation that it cannot renumber a source range to a
destination range that is greater than the last line number of the
source file. i.e.:
100 xxxxxxxx
110 xxxxxxxx
120 xxxxxxxx
.
.
200 xxxxxxxx
210 xxxxxxxx
220 xxxxxxxx
.
.
.
999 END
The range 200-220 cannot be renumbered to 1000-1020, but CAN be
renumbered to 800-820 if line numbers 800-820 do not currently exist.
This is sometimes frustrating for me, as I block my routines in ranges
and sometimes need to move something past the current last line number.
The workaround for this is to add a line "65534 END" to the program
when developing, and then remove it when done.
The best thing about it is that it will act upon the .BA file
directly (in-line) from within BASIC. If using the TEXT Editor to write
your program, just exit back to BASIC, "CALL 911", then type the "RN"
command to set your ranges.
Regards,
Peter
------------------------------
Message: 7
Date: Thu, 17 Jun 2021 12:21:02 -0400
From: Stephen Adolph <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Subject: Re: [M100] feature to add to REX#/REXCPM - renumbering BASIC
Message-ID:
<camcmnv4+ng94c3nfyqxjphhwjdbs9-h-sjqdsu+s6ghy2vf...@mail.gmail.com
<mailto:camcmnv4%2bng94c3nfyqxjphhwjdbs9-h-sjqdsu%[email protected]>>
Content-Type: text/plain; charset="utf-8"
that is true, yes. ROM2 does include that plus some other nice things.
<snip>
--
bkw
