On 19 Feb 2012, at 15:07, George Gwilt wrote:
>
>> I use DEBUG 0 and 1 for the same reasons as you and have never had the fault
>> you mention.
>
>> If you could send me, privately, a copy of your program I'll try to locate
>> the problem.
>
> Thanks for your offer of help, this is really appreciated. However, I
> believe I have solved the problem. I tried moving the piece of code to near
> the beginning of the program, and this solved the puzzle. My guess is that
> because my program is over 64k, the DEBUG mechanism could not cope, so that
> the fault is actually with Turbo. DEBUG must be using unsigned integers,
> when it should be using floating point variables. That is my guess. The
> piece of code under question is:
>
DEBUG is trapped by PARSER_TASK to see whether code is to be ignored or
compiled. If fact in PARSER_TASK the values 0 to 9 (which is the allowed range
of DEBUG) are held in an fp variable.
> 22268 REMark DEBUG 1
> 22276 DEFine PROCedure how
> 22284 LOCal p, scan_rt
> 22292 CLS 2 : PRINT
> 22300 p = BASIC_L(56)
> 22308 REPeat scan_rt
> 22316 p = p + 24
> 22324 IF p > BASIC_L(60)-24 : EXIT scan_rt
> 22332 IF BASIC_W%(p+18)<>0
> 22340 PRINT "Call at ";BASIC_W%(p+18);" in ";
> 22348 ELSE
> 22356 PRINT "Stop at ";BASIC_W%(146);" in ";
> 22364 END IF
> 22372 IF BASIC_W%(p-12) > 0 : IF NOT COMPILED : LIST #1; BASIC_W%(p-12)
> 22380 END REPeat scan_rt
> 22388 END DEFine how
> 22396 REMark DEBUG 0
>
With the DEBUG commands REMarked out TURBO will ignore them.
With the DEBUG commands not REMarked out the "IF NOT COMPILED" is, of course,
not needed.
>
> This piece was copied from the Turbo Toolkit Demos file, the original
> procedure name being How_COME. My idea of using DEBUG was to try and save a
> little bit of code, because my program is so large.
>
>
I have a copy of parser506_bas and have managed to compile this
with line numbers included. Trying this
on my program the parser stops at line 14490, which is in the middle of ignoring
code. I then inserted the following line
14488 PRINT #log%, BASIC_NAME$(value%) ! var%
After recompiling and running, this produced the following
output
CLS 216
PRINT 144
p -3
At line 14490, where the parser stops, struct% is an array
and so the -3 has caused this to go out of range.
Michael
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm