Re: [Ql-Users] SBASIC interpreter bug?
Op 23/11/2022 om 16:40 schreef pjwitte via Ql-Users:
On 23/11/2022 14:51, François Van Emelen via Ql-Users wrote:
Op 22/11/2022 om 13:26 schreef pjwitte via Ql-Users:
Does anyone know whats going on here?
<>
Could this solve your problem?
100 ch = FOPEN("con"): CLS#ch
110 test ch, 25
120 print#ch,"hit a key to stop" :PAUSE#ch,-1
130 CLOSE#ch
140 :
150 DEFine PROCedure test(coucou, a)
160 PRINT#ch; coucou,a
180 END DEFine test
Only replaced 'ch' as first parameter with 'coucou'
tested in QD sbas/qd and ex the file
François Van Emelen
Thanks for playing, François,
But its not MY problem. It is A problem. I normally manage to work
around it these days, as I do numerous other little quirks and
"features".
It only became a problem for me 'tother day after I merged some some
well-tested library routines with a larger project, not realising that
some of my global variables happened to have the same name as the
parameters of some function (Duh!) Then I wasted a stressful hour and
a half trying to figure out why the program would just hang without
there being anything "wrong" with it. (It compiled with Qlib and the
Turbo parser did not report any relevant errors, etc.) I made some
changes and then I kept getting nonsense structural errors instead. In
other words a huge time waster; just the sort of thing to put people
off writing decent, modern programs in SBASIC for SMSQ/E!
That being said, I dont expect anyone to try to fix it! It takes some
skill and, more importantly, "being in the picture". Ie it takes time
to get into the thing, especially if it has been a while. And bug
hunting can be a dreadful, time consuming business even for the best.
At least by bringing it up here, where there still appears to be some
interest in SMSQ/E and QL software, people may be made aware and save
themselves some head/heartache.
Per
___
QL-Users Mailing List
Hi Per,
I know that is not Your problem but when I saw that Wolgang seemed
somewhat puzzled too, I decided to reply to your question.
The error ‘DEFines may not be within other clauses’ has already been a
topic but I can’t remember where it was. Here or private mail ?
Many thanks to you and Martin Hill for Qlib 3.45.
I am not a member of ql forum (only have a look now and then)
François Van Emelen
___
QL-Users Mailing List
Re: [Ql-Users] SBASIC interpreter bug?
On 23/11/2022 14:51, François Van Emelen via Ql-Users wrote:
Op 22/11/2022 om 13:26 schreef pjwitte via Ql-Users:
Does anyone know whats going on here?
<>
Could this solve your problem?
100 ch = FOPEN("con"): CLS#ch
110 test ch, 25
120 print#ch,"hit a key to stop" :PAUSE#ch,-1
130 CLOSE#ch
140 :
150 DEFine PROCedure test(coucou, a)
160 PRINT#ch; coucou,a
180 END DEFine test
Only replaced 'ch' as first parameter with 'coucou'
tested in QD sbas/qd and ex the file
François Van Emelen
Thanks for playing, François,
But its not MY problem. It is A problem. I normally manage to work
around it these days, as I do numerous other little quirks and
"features".
It only became a problem for me 'tother day after I merged some some
well-tested library routines with a larger project, not realising that
some of my global variables happened to have the same name as the
parameters of some function (Duh!) Then I wasted a stressful hour and
a half trying to figure out why the program would just hang without
there being anything "wrong" with it. (It compiled with Qlib and the
Turbo parser did not report any relevant errors, etc.) I made some
changes and then I kept getting nonsense structural errors instead. In
other words a huge time waster; just the sort of thing to put people
off writing decent, modern programs in SBASIC for SMSQ/E!
That being said, I dont expect anyone to try to fix it! It takes some
skill and, more importantly, "being in the picture". Ie it takes time
to get into the thing, especially if it has been a while. And bug
hunting can be a dreadful, time consuming business even for the best.
At least by bringing it up here, where there still appears to be some
interest in SMSQ/E and QL software, people may be made aware and save
themselves some head/heartache.
Per
___
QL-Users Mailing List
Re: [Ql-Users] SBASIC interpreter bug?
Hi, Per wrote: > Perhaps you didnt EX it? If you RUN it it may work, although a > differently constructed (more complex) version would also fail. I didn't ex it, just ran it - the problem was already seen under an SBasic daughter job. Derek wrote: It looks like the variable for the FOPEN parameter is getting mixed up with the parameter on the Procedure parameter. Indeed, but I believe that the point Per was making is that it shouldn't. Wolfgang ___ QL-Users Mailing List
Re: [Ql-Users] SBASIC interpreter bug?
Hi I changed the ch in the FOPEN variable to chan and it worked with EX, SBAS. It looks like the variable for the FOPEN parameter is getting mixed up with the parameter on the Procedure parameter. I also tried the original program on Minerva with MultiBasic executing the program with: EX pipep;"test_bas>" Seemed work without any problem, clearlt SMSQ/E is a little stricter than Minerva on variable. --- Regards, Derek ___ QL-Users Mailing List
Re: [Ql-Users] SBASIC interpreter bug?
Op 22/11/2022 om 13:26 schreef pjwitte via Ql-Users:
Does anyone know whats going on here?
SBASIC only: EXecute the following program:
100 ch = FOPEN("con"): CLS#ch
110 test ch, 1
120 PAUSE#ch
130 CLOSE#ch
140 :
150 DEFine PROCedure test(ch, a)
160 PRINT#ch; a
180 END DEFine test
Result in this case:
At line 150:4 DEFines may not be within other clauses
However there are various error conditions depending on how the program
is constructed. In the worst case it just hangs and must be RJOBed.
What seems to get the interpreter's knickers in a twist is a parameter
being referenced using the same name as the parameter, 'ch' in this case.
This is supposed to be perfectly "legal". I dont know when this behaviour
started but Ive noticed it for a while.
It would be nice if this could be fixed as, for example, in larger
projects, when using library code you dont necessarily notice that
variable
names are the same a parameter names, and so you may end up getting
unexplained hangs or obscure error messages that dont actually relate to
the problem.
Per
___
QL-Users Mailing List
Hi,
Could this solve your problem?
100 ch = FOPEN("con"): CLS#ch
110 test ch, 25
120 print#ch,"hit a key to stop" :PAUSE#ch,-1
130 CLOSE#ch
140 :
150 DEFine PROCedure test(coucou, a)
160 PRINT#ch; coucou,a
180 END DEFine test
Only replaced 'ch' as first parameter with 'coucou'
tested in QD sbas/qd and ex the file
François Van Emelen
___
QL-Users Mailing List
Re: [Ql-Users] SBASIC interpreter bug?
Perhaps you didnt EX it? If you RUN it it may work, although a differently constructed (more complex) version would also fail. Anyway, its not about the platform, its about SMSQ/E. Ive tried it on SMSQ/E V3.25, 3.38 and 3b39 - all present with the same problem. Per On 22/11/2022 16:38, Timothy Swenson wrote: > I just tested the short program with SMSQmulator 2.3.1 (for Java 11) and I did not get an error. A black CON window opened up and printed the number 1. > > What platforms were tested that generated the error? > > Tim Swenson > ___ QL-Users Mailing List
Re: [Ql-Users] SBASIC interpreter bug?
RUNing appears to work; its when EXing this program that the problem
shows up.
I believe its possible to get an error on RUNing too, I just havent
been able to recreate the conditions.
Typical errors are:
At line nnn:
At line : undefined loop control
variable
etc, all nonsense
Clearly, EXecuted SBASIC programs get a different environment than
RUNed ones. Like the "program":
100 PRINT
110 END REPeat loop
doesnt throw an error when RUN, only when EXecuted.
Per
On 22/11/2022 17:13, Wolfgang Lenerz via Ql-Users wrote:
Hi,
Does anyone know whats going on here?
Nope...
Even stranger : once you run this and it failed, change the variable
name ("ch") to something else (like "cht") everywhere . Run it - and
it works. Save the prog with that new variable name, start a new
basic session, load the prog, run it- and it fails. Change "cht"
back to "ch" - and it works.
Have fun (?)
Wolfgang
SBASIC only: EXecute the following program:
>>
100 ch = FOPEN("con"): CLS#ch
110 test ch, 1
120 PAUSE#ch
130 CLOSE#ch
140 :
150 DEFine PROCedure test(ch, a)
160 PRINT#ch; a
180 END DEFine test
Result in this case:
At line 150:4 DEFines may not be within other clauses
However there are various error conditions depending on how the
program
is constructed. In the worst case it just hangs and must be RJOBed.
What seems to get the interpreter's knickers in a twist is a parameter
being referenced using the same name as the parameter, 'ch' in this
case.
This is supposed to be perfectly "legal". I dont know when this
behaviour
started but Ive noticed it for a while.
It would be nice if this could be fixed as, for example, in larger
projects, when using library code you dont necessarily notice that
variable
names are the same a parameter names, and so you may end up getting
unexplained hangs or obscure error messages that dont actually
relate to
the problem.
Per
___
QL-Users Mailing List
___
QL-Users Mailing List
___
QL-Users Mailing List
