Re: [Ql-Users] DEBUG
Hi George There is an error in the Turbo parser at line 14490. Here is this line: 14490 IF var%0 AND (struct%(var%)directive_mask%)=directive_mask% Both sides of the AND get to be evaluated. Although var% is tested for being non negative on the left hand side, the right hand side will be evaluated in any event. Should var% happen to be negative, then struct%(var%) would be outside of the array bounds and will crash SuperBASIC. The above line needs to be re written so that the right hand side will only be evaluated if the left hand side evaluates to true. Here is my suggested work-around: 1 LOCal both : REMark (if needed) 14488 both = 0 14489 IF var%0:IF (struct%(var%)directive_mask%)=directive_mask% : both = 1 14490 IF both Michael ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
Hi Michael On 22 Feb 2012, at 13:31, Michael Bulford wrote: There is an error in the Turbo parser at line 14490. Here is this line: 14490 IF var%0 AND (struct%(var%)directive_mask%)=directive_mask% Both sides of the AND get to be evaluated. Although var% is tested for being non negative on the left hand side, the right hand side will be evaluated in any event. Should var% happen to be negative, then struct%(var%) would be outside of the array bounds and will crash SuperBASIC. You are quite right. But how did you get var%=-3? Does this imply another mistake in Parser? The above line needs to be re written so that the right hand side will only be evaluated if the left hand side evaluates to true. Here is my suggested work-around: 1 LOCal both : REMark (if needed) 14488 both = 0 14489 IF var%0:IF (struct%(var%)directive_mask%)=directive_mask% : both = 1 14490 IF both My solution is: 14490 IF var%0 14494 IF (struct%(var%)directive_mask%)=directive_mask%:Parse_Directive:ELSE Skip_Stmt Cheers George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
Hi George On Wednesday, 22 February 2012, 14:24 George Gwilt wrote: You are quite right. But how did you get var%=-3? Does this imply another mistake in Parser? No, I don't think so. -3 comes from for_flag% for an earlier occurence of p Your solution looks the best - it's neater. Michael ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
In message 1329917514.17351.yahoomail...@web171518.mail.ir2.yahoo.com, Michael Bulford michaelbulf...@yahoo.co.uk writes Hi George There is an error in the Turbo parser at line 14490. Here is this line: 14490 IF var%0 AND (struct%(var%)directive_mask%)=directive_mask% Both sides of the AND get to be evaluated. Although var% is tested for being non negative on the left hand side, the right hand side will be evaluated in any event. Should var% happen to be negative, then struct%(var%) would be outside of the array bounds and will crash SuperBASIC. The above line needs to be re written so that the right hand side will only be evaluated if the left hand side evaluates to true. Here is my suggested work-around: 1 LOCal both : REMark (if needed) 14488 both = 0 14489 IF var%0:IF (struct%(var%)directive_mask%)=directive_mask% : both = 1 14490 IF both Michael I use the logical method, of defining 'true' and 'false', as a global value in a program. 500 true=1 : false=NOT true Then you can use 1000 IF true 1010 REMark Take an action ... etc . This makes the program easier to follow. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
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
Re: [Ql-Users] DEBUG
Hi Michael On 21 Feb 2012, at 11:16, Michael Bulford wrote: 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 Yes. At this stage if the DEBUG level is high enough code is not compiled. 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. Although I have tried compiling large programs with DEBUG 1/DEBUG 0 insertions all over the place, no errors occur. The error you find is presumably, therefore, due to something in the code being compiled, though whether Parser_task is at fault or not I couldn't say unless I have the actual code producing the errore. I could then try to track down the reason for the fault. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
On 18 Feb 2012, at 13:38, Michael Bulford 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. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
Hi Michael On 17 Feb 2012, at 19:25, Michael Bulford wrote: There is some code in my program that I do not want compiled: this is only used when the SuperBASIC version is running. So, I use DEBUG 1 before the code and DEBUG 0 afterwards. When compiling the parser stops with the report of Task Turbo 5.06 halted, after line 0. Reason: out of range The display panel reads: Pass: 1Line 22300, which is a few lines after the DEBUG 1 statement. Can anyone please tell me what I am doing wrong? The program will compile successfully if the DEBUG command is not used. I have tried using DEBUG_LEVEL but this makes no difference. 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. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
Hi George On Saturday 18 February 2012, 9:56George 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: 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 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. Hi Malcolm On Friday 17 February 2012, 21:35 Malcolm Cadman wrote: Also useful to use and declare integer values, wherever you can, at the start of the BASIC program - which is value% rather than value. Yes, I agree. There is a particular reason for this. Suppose the compiled program stops somewhere with an out of range error. The SuperBASIC version could then be run using the same input data, duplicate the error and stop at exactly same place. The procedure how would then be run to discover the call hierarchies that got the program to that point. Variable values could then be examined with the view to pin-point the cause of the error. However, if using IMPLICIT% value, then the SuperBASIC version would be using floating point variables and the same error would not be produced and so would not stop at the same place. Michael Bulford ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
In message 1329572303.66299.yahoomail...@web171520.mail.ir2.yahoo.com, Michael Bulford michaelbulf...@yahoo.co.uk writes Hi George On Saturday 18 February 2012, 9:56George 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: 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 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. Hi Malcolm On Friday 17 February 2012, 21:35 Malcolm Cadman wrote: Also useful to use and declare integer values, wherever you can, at the start of the BASIC program - which is value% rather than value. Yes, I agree. There is a particular reason for this. Suppose the compiled program stops somewhere with an out of range error. The SuperBASIC version could then be run using the same input data, duplicate the error and stop at exactly same place. The procedure how would then be run to discover the call hierarchies that got the program to that point. Variable values could then be examined with the view to pin-point the cause of the error. However, if using IMPLICIT% value, then the SuperBASIC version would be using floating point variables and the same error would not be produced and so would not stop at the same place. Michael Bulford Hi Michael, It is always difficult to understand another persons code. Personally I would look to structure your program more. Your line was 22340 PRINT Call at ;BASIC_W%(p+18); in ; 22348 ELSE 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) Whereas 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) Is more understandable in its layout. The SELect ON structure is also available, as a clearer alternative to IF ... END IF and ELSE. Which is useful for a complicated series of conditions, and can also incorporate IF and END IF statements. Good luck with program ... :-) -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] DEBUG
There is some code in my program that I do not want compiled: this is only used when the SuperBASIC version is running. So, I use DEBUG 1 before the code and DEBUG 0 afterwards. When compiling the parser stops with the report of Task Turbo 5.06 halted, after line 0. Reason: out of range The display panel reads: Pass: 1 Line 22300, which is a few lines after the DEBUG 1 statement. Can anyone please tell me what I am doing wrong? The program will compile successfully if the DEBUG command is not used. I have tried using DEBUG_LEVEL but this makes no difference. Michael Bulford ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] DEBUG
In message 1329506713.90809.yahoomail...@web171507.mail.ir2.yahoo.com, Michael Bulford michaelbulf...@yahoo.co.uk writes There is some code in my program that I do not want compiled: this is only used when the SuperBASIC version is running. So, I use DEBUG 1 before the code and DEBUG 0 afterwards. When compiling the parser stops with the report of Task Turbo 5.06 halted, after line 0. Reason: out of range The display panel reads: Pass: 1 Line 22300, which is a few lines after the DEBUG 1 statement. Can anyone please tell me what I am doing wrong? The program will compile successfully if the DEBUG command is not used. I have tried using DEBUG_LEVEL but this makes no difference. Michael Bulford Hi Michael, Check that the SuperBASIC code is returning a sensible value at Line 22300. SuperBASIC, when it runs the code, tolerates values that the Turbo Compiler will not, as it is much less tolerant. Also useful to use and declare integer values, wherever you can, at the start of the BASIC program - which is value% rather than value. Doing this should rid your program of these out of range type errors. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
