info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Program execution problem
16 views
Skip to first unread message
Wendelin Uez
Aug 29, 2020, 6:21:19 AM8/29/20
to
Hi,
first, your program stops executing the END statement so it's no question
why it stops but why it does reach this line.Executing an END statement
always closes all open files.
Second, the error might be caused due to some code outtside the loop making
your code difficult to check. Using GOTO <linenumber> is possible but you
have to take care that your code will later on jump back into the loop. PDS
supports GOSUB with labels, so to get better readable and checkable code you
should use GOSUB <label> in conjunction with <label>: and RETURN to get a
better readable and checkable code structure. A still better way is to use
subroutines with SUB <subname>...RETURN.
Generally, PDS does not need line numbers at all. Forget all line numbers
and use labels, this will make your code significantly clearer and more
readable, and insert blank lines for separation to enhance readability. The
more readable your code the better checking for errors it is. Empty lines
are ignored by the compiler and therefore do not enlarge file size.
Third, it's not a good practice to add graphical files as attachment. You
can add code simply as plain text into your mail, or if you insist to add a
code file use txt format at least, this will enable us to copy out your code
for better reading, more tests, and so on, if nescessary. The included GIF
file is of poor quality and therefore harder to read than nescessary.
Your trial to understand code execution by reporting line numbers is not
very effective as you see, because it's hard to maintain variable values to
find out which conditions will branche.
For easier debugging use something like this:
MSG$ = "<code location>: <variable name> = <variable's content>
CALL DBGOUTPUT (MSG$)
:::
SUB DBGOUTPUT (M$)
PRINT M$
END SUB
Fourth, never, never change FOR...NEXT loop variables inside or outside the
loop as you do here.
If you need to change such a value use a WHILE...WEND construction with a
separate loop counter variable which can be incremented as you want and used
to exit loop.
HTH, wuez
BTW: do you still use PDS and MS DOS, or do you PDS run in a command line
window (I never tried this but it might work)?
Basic PDS 7.1
"Robert Baer" <rober...@localnet.com> schrieb im Newsbeitrag
news:FEc1H.81519$lZ.3...@fx12.iad...
> I am having a devil of a time tying to figure out why a BASIC program
> does not work properly.
> Had been using the BASIC Professional Development System Ver 7.1
> (equivalent to Quick BASIC from DOS 6.22 daze).
>
> Inserting a bunch of debug print lines did not help much; in a
> section of the program, 6 statement lines got executed in 1,3,5,2,4,6
> order instead of the expected, listed 1,2,3,4,5,6 order.
>
> I got tired of fighting it so converted the program into a
> line-numbered version and made the obvious reference changes for GWBASIC
> DOS 3.3).
>
> Attached is a screen shot montage showing one still messy section of
> code, along with a TRON.
>
> Notice the program stops at line 530 for no good reason, and all
> files are closed.
>
> One would think that a more regimented, line-numbered program would
> behave.
>
> Help?
>
> Thanks.
>
first, your program stops executing the END statement so it's no question
why it stops but why it does reach this line.Executing an END statement
always closes all open files.
Second, the error might be caused due to some code outtside the loop making
your code difficult to check. Using GOTO <linenumber> is possible but you
have to take care that your code will later on jump back into the loop. PDS
supports GOSUB with labels, so to get better readable and checkable code you
should use GOSUB <label> in conjunction with <label>: and RETURN to get a
better readable and checkable code structure. A still better way is to use
subroutines with SUB <subname>...RETURN.
Generally, PDS does not need line numbers at all. Forget all line numbers
and use labels, this will make your code significantly clearer and more
readable, and insert blank lines for separation to enhance readability. The
more readable your code the better checking for errors it is. Empty lines
are ignored by the compiler and therefore do not enlarge file size.
Third, it's not a good practice to add graphical files as attachment. You
can add code simply as plain text into your mail, or if you insist to add a
code file use txt format at least, this will enable us to copy out your code
for better reading, more tests, and so on, if nescessary. The included GIF
file is of poor quality and therefore harder to read than nescessary.
Your trial to understand code execution by reporting line numbers is not
very effective as you see, because it's hard to maintain variable values to
find out which conditions will branche.
For easier debugging use something like this:
MSG$ = "<code location>: <variable name> = <variable's content>
CALL DBGOUTPUT (MSG$)
:::
SUB DBGOUTPUT (M$)
PRINT M$
END SUB
Fourth, never, never change FOR...NEXT loop variables inside or outside the
loop as you do here.
If you need to change such a value use a WHILE...WEND construction with a
separate loop counter variable which can be incremented as you want and used
to exit loop.
HTH, wuez
BTW: do you still use PDS and MS DOS, or do you PDS run in a command line
window (I never tried this but it might work)?
Basic PDS 7.1
"Robert Baer" <rober...@localnet.com> schrieb im Newsbeitrag
news:FEc1H.81519$lZ.3...@fx12.iad...
> I am having a devil of a time tying to figure out why a BASIC program
> does not work properly.
> Had been using the BASIC Professional Development System Ver 7.1
> (equivalent to Quick BASIC from DOS 6.22 daze).
>
> Inserting a bunch of debug print lines did not help much; in a
> section of the program, 6 statement lines got executed in 1,3,5,2,4,6
> order instead of the expected, listed 1,2,3,4,5,6 order.
>
> I got tired of fighting it so converted the program into a
> line-numbered version and made the obvious reference changes for GWBASIC
> DOS 3.3).
>
> Attached is a screen shot montage showing one still messy section of
> code, along with a TRON.
>
> Notice the program stops at line 530 for no good reason, and all
> files are closed.
>
> One would think that a more regimented, line-numbered program would
> behave.
>
> Help?
>
> Thanks.
>
R.Wieser
Aug 29, 2020, 7:47:15 AM8/29/20
to
Robert,
> Notice the program stops at line 530 for no good reason,
> and all files are closed.
Under QBasic 'end' terminates the program. Are you sure you didn't mean
'end if' there ?
(That all the files are closed could easily be part of PDS'es clean-up
activities before actually terminating)
> in a section of the program, 6 statement lines got executed
> in 1,3,5,2,4,6
As you have not posted the involved code and I (we) do not have any kind of
mind-reading capabilities there is nothing I (we) can say about that.
> One would think that a more regimented, line-numbered
> program would behave.
It certainly enables you to write goto-enabled spagetti code (as in:
unreadable/trackable code). Why do you think most languages dropped the
'goto' and/or strongly advice you NOT to use it ? :-)
Basic bug-hunting most often boils down to isolating the problem by removing
everything that does /not/ make the problem disappear (and sometimes
replacing variable and/or human input by fixed stuff). If you're lucky
you're left with a single line. :-)
Regards,
Rudy Wieser
> Notice the program stops at line 530 for no good reason,
> and all files are closed.
'end if' there ?
(That all the files are closed could easily be part of PDS'es clean-up
activities before actually terminating)
> in a section of the program, 6 statement lines got executed
> in 1,3,5,2,4,6
mind-reading capabilities there is nothing I (we) can say about that.
> One would think that a more regimented, line-numbered
> program would behave.
unreadable/trackable code). Why do you think most languages dropped the
'goto' and/or strongly advice you NOT to use it ? :-)
Basic bug-hunting most often boils down to isolating the problem by removing
everything that does /not/ make the problem disappear (and sometimes
replacing variable and/or human input by fixed stuff). If you're lucky
you're left with a single line. :-)
Regards,
Rudy Wieser
Robert Baer
Aug 31, 2020, 6:40:28 PM8/31/20
to
Wendelin Uez wrote:
> Hi,
>
> first, your program stops executing the END statement so it's no
> question why it stops but why it does reach this line.Executing an END
> statement always closes all open files.
* Thanks; it as been over 40 years since i have used GWBASIC and 15
> Hi,
>
> first, your program stops executing the END statement so it's no
> question why it stops but why it does reach this line.Executing an END
> statement always closes all open files.
years since using PDS Basic.
I finally figured out that "END" meant end-of-program.
It got into the program from previous ierations,one having an IF..ENDIF.
>
> Second, the error might be caused due to some code outtside the loop
> making your code difficult to check. Using GOTO <linenumber> is
> possible but you have to take care that your code will later on jump
> back into the loop. PDS supports GOSUB with labels, so to get better
> readable and checkable code you should use GOSUB <label> in conjunction
> with <label>: and RETURN to get a better readable and checkable code
> structure. A still better way is to use subroutines with SUB
> <subname>...RETURN.
numbers gone (see below).
>
> Generally, PDS does not need line numbers at all. Forget all line
> numbers and use labels, this will make your code significantly clearer
> and more readable, and insert blank lines for separation to enhance
> readability. The more readable your code the better checking for errors
> it is. Empty lines are ignored by the compiler and therefore do not
> enlarge file size.
number..comment (120 ').
>
> Third, it's not a good practice to add graphical files as attachment.
> You can add code simply as plain text into your mail, or if you insist
> to add a code file use txt format at least, this will enable us to copy
> out your code for better reading, more tests, and so on, if nescessary.
> The included GIF file is of poor quality and therefore harder to read
> than nescessary.
original visual, in fact the TRON is more readable because i inverted
black and white.
>
> Your trial to understand code execution by reporting line numbers is not
> very effective as you see, because it's hard to maintain variable values
> to find out which conditions will branche.
>
> For easier debugging use something like this:
> MSG$ = "<code location>: <variable name> = <variable's content>
> CALL DBGOUTPUT (MSG$)
> :::
>
> SUB DBGOUTPUT (M$)
> PRINT M$
> END SUB
>
> Fourth, never, never change FOR...NEXT loop variables inside or outside
> the loop as you do here.
> If you need to change such a value use a WHILE...WEND construction with
> a separate loop counter variable which can be incremented as you want
> and used to exit loop.
>
> HTH, wuez
>
> BTW: do you still use PDS and MS DOS, or do you PDS run in a command
> line window (I never tried this but it might work)?
nicely.
House-some ever, in Win7.1, even tho you can have visual screen full
in CMD prompt, it is impossible to get those larger characters for same
ADM-3 effect.
An 1024x768 screen or 1152x864 screen becomes max of 144w x 66h, 8x12
(raster font) fills monitor nicely with small but readable text.
However, QBX only fills about 2/3 of it with "large" font 80 wide.
GWBASIC does the same. No nice "fill it up" like in XP.
Thanks.
Robert Baer
Aug 31, 2020, 6:45:07 PM8/31/20
to
R.Wieser wrote:
> Robert,
>
>> Notice the program stops at line 530 for no good reason,
>> and all files are closed.
>
> Under QBasic 'end' terminates the program. Are you sure you didn't mean
> 'end if' there ?
* In one iteration of the program, that is what was intended..
> Robert,
>
>> Notice the program stops at line 530 for no good reason,
>> and all files are closed.
>
> Under QBasic 'end' terminates the program. Are you sure you didn't mean
> 'end if' there ?
>
> (That all the files are closed could easily be part of PDS'es clean-up
> activities before actually terminating)
>
>> in a section of the program, 6 statement lines got executed
>> in 1,3,5,2,4,6
>
> As you have not posted the involved code and I (we) do not have any kind of
> mind-reading capabilities there is nothing I (we) can say about that.
>
>> One would think that a more regimented, line-numbered
>> program would behave.
>
> It certainly enables you to write goto-enabled spagetti code (as in:
> unreadable/trackable code). Why do you think most languages dropped the
> 'goto' and/or strongly advice you NOT to use it ? :-)
>
>
> Basic bug-hunting most often boils down to isolating the problem by removing
> everything that does /not/ make the problem disappear (and sometimes
> replacing variable and/or human input by fixed stuff). If you're lucky
> you're left with a single line. :-)
>
> Regards,
> Rudy Wieser
>
>
Robert Baer
Sep 1, 2020, 12:33:00 AM9/1/20
to
Partial copy of output:
<h2 id="A:"><B>A:</B></h2>
<h3>
READSJ
COPYSJ
able
<a
href="downhole-measurements.html?find=able">Downhole Measurements</a>
<br>
READSJ 'above' record GONE
READSJ
COPYSJ
absorbers
<a href="vendor-profile.html?find=absorbers">Vendor
Profile</a>
<br>
READSJ 'absorbing' record GONE
READSJ
COPYSJ
absorption
<a
href="downhole-measurements.html?find=absorption">Downhole Measurements</a>
<a
href="https://www.hamamatsu.com/resources/pdf/etd/PMT_handbook_v3aE.pdf?find=absorption">Photomultiplier
Tubes Basics</a>
<br>
READSJ 'accelerate' record GONE
READSJ
COPYSJ
accelerator
<a
href="downhole-measurements.html?find=accelerator">Downhole Measurements</a>
<br>
**END COPY**
So there are two problems:
1) NO "debug" output from the git-go
FOR LWD = 1 TO 164 'LWD keyword file size
GOSUB READIKW '**NO "READIKW" PRINTOUT
2) Skips every other SJ keyword.
Comments?
Thanks.
R.Wieser
Sep 1, 2020, 4:02:53 AM9/1/20
to
Robert,
>> Under QBasic 'end' terminates the program. Are you sure you didn't mean
>> 'end if' there ?
>
> * In one iteration of the program, that is what was intended..
You do not make much sense there. You complain that it stops there, and now
you're telling me that was intended ? <huh?>
Besides, the indentation tells me that that 'end' was /ment/ as the
terminator of the 'if' above it ...
Regards,
Rudy Wieser
>> Under QBasic 'end' terminates the program. Are you sure you didn't mean
>> 'end if' there ?
>
> * In one iteration of the program, that is what was intended..
you're telling me that was intended ? <huh?>
Besides, the indentation tells me that that 'end' was /ment/ as the
terminator of the 'if' above it ...
Regards,
Rudy Wieser
R.Wieser
Sep 1, 2020, 4:02:54 AM9/1/20
to
Robert,
> GOSUB READIKW '**NO "READIKW" PRINTOUT
Well duh! You commented that line out. :-)
> 2) Skips every other SJ keyword
Your main loop (for lwd = 1 to 164) contains *three* 'gosub readjs' calls.
My guess is that it goes wrong there. You might try to move the first one
/above/ the 'for' loop.
> Comments?
A few.
No indication of the used basic variant. That makes it hard to even do a
syntax check on the code.
No (samples of) the datafiles, meaning that I (we) cannot run that code and
spot where it goes wrong.
No attempt to simplify the code (using dummy datafiles or even static data)
(making it easier to spot where it goes wrong)
"Writing programs is easy. Just let your cat walk over the keyboard a few
times and you're done.
The hard part is to figure out what/where it goes wrong when it does
something else than you expected."
Regards,
Rudy Wieser
> GOSUB READIKW '**NO "READIKW" PRINTOUT
> 2) Skips every other SJ keyword
My guess is that it goes wrong there. You might try to move the first one
/above/ the 'for' loop.
> Comments?
A few.
No indication of the used basic variant. That makes it hard to even do a
syntax check on the code.
No (samples of) the datafiles, meaning that I (we) cannot run that code and
spot where it goes wrong.
No attempt to simplify the code (using dummy datafiles or even static data)
(making it easier to spot where it goes wrong)
"Writing programs is easy. Just let your cat walk over the keyboard a few
times and you're done.
The hard part is to figure out what/where it goes wrong when it does
something else than you expected."
Regards,
Rudy Wieser
Robert Baer
Sep 1, 2020, 4:30:51 PM9/1/20
to
R.Wieser wrote:
> Robert,
>
>>> Under QBasic 'end' terminates the program. Are you sure you didn't mean
>>> 'end if' there ?
>>
>> * In one iteration of the program, that is what was intended..
>
> You do not make much sense there. You complain that it stops there, and now
> you're telling me that was intended ? <huh?>
* The "END" stop was not intended, it was the left-over from an intended
> Robert,
>
>>> Under QBasic 'end' terminates the program. Are you sure you didn't mean
>>> 'end if' there ?
>>
>> * In one iteration of the program, that is what was intended..
>
> You do not make much sense there. You complain that it stops there, and now
> you're telling me that was intended ? <huh?>
IF..ENDIF.
>
> Besides, the indentation tells me that that 'end' was /ment/ as the
> terminator of the 'if' above it ...
>
> Regards,
> Rudy Wieser
>
>
R.Wieser
Sep 2, 2020, 2:44:06 AM9/2/20
to
Robert,
>> You do not make much sense there. You complain that it stops there, and
>> now you're telling me that was intended ? <huh?>
>
> * The "END" stop was not intended, it was the left-over from an intended
> IF..ENDIF.
Thats what I said the in my initial response to you/it, which you only /now/
acknowledge.
Odd though, I would have expected that code (the unterminated "if") to have
thrown an error (QBasic certainly does), but I have not seen you mention
anything like it....
>> Besides, the indentation tells me that that 'end' was /ment/ as the
>> terminator of the 'if' above it ...
>
> * Ain't that what i sed?
You did ? You mean when you said "In one iteration of the program, that
is what was intended" ? I can read that in at at least four different ways
(two possibilities left of the comma, two right of it), so I pretty-much
ignored it.
Kiddo, as I have zero wish to second-guess what you might have ment when you
say or write something I can only wish you good luck with your further
bug-hunting.
Regards,
Rudy Wieser
P.s.
As you mentioned that you do not see all posts : I also wrote a reply to
your "Rev1" message. It might be usefull to you.
>> You do not make much sense there. You complain that it stops there, and
>> now you're telling me that was intended ? <huh?>
>
> * The "END" stop was not intended, it was the left-over from an intended
> IF..ENDIF.
acknowledge.
Odd though, I would have expected that code (the unterminated "if") to have
thrown an error (QBasic certainly does), but I have not seen you mention
anything like it....
>> Besides, the indentation tells me that that 'end' was /ment/ as the
>> terminator of the 'if' above it ...
>
> * Ain't that what i sed?
is what was intended" ? I can read that in at at least four different ways
(two possibilities left of the comma, two right of it), so I pretty-much
ignored it.
Kiddo, as I have zero wish to second-guess what you might have ment when you
say or write something I can only wish you good luck with your further
bug-hunting.
Regards,
Rudy Wieser
P.s.
As you mentioned that you do not see all posts : I also wrote a reply to
your "Rev1" message. It might be usefull to you.
0 new messages