Page 4 of 6
Re: New QLiberator v3.37
Posted: Thu Apr 02, 2020 1:09 pm
by pjw
BSJR wrote:<>
1. The INSTR_CASE keyword as featured in SMSQ/E is not working in 3.36, no error is reported but its setting is ignored and the behaviour of INSTR is not changed.
I wouldnt be surprised if Qlib used its own routines for this. If so, it may be hard to fix until someone gets very familiar with the code.
2. A missing name after an END FOR, which is allowed in SBasic, prevented a compiled version of my program from running.
It kept me searching for weeks and was in the end found by Wolfgang Lenerz.
Normally it's not a feature I would use but as it's allowed it should be accepted by Qlib for END FOR (& END REP & NEXT) or at least produce an alert at compile time.
I agree that this should be flagged, but as above, making it SMSQ/E compatible might not be easy, especially if the resulting object code is still to be compatible with other platforms.
Regarding your elusive bug: I find it sometimes helps to let the Turbo parser have a go at recalcitrant code. Its pretty good at uncovering obscure errors.
Re: New QLiberator v3.37
Posted: Thu Apr 02, 2020 11:23 pm
by EmmBee
BSJR wrote:EmmBee wrote:Hi everyone,
We now consider the next round of improvements, bug fixes, etc. Here is the list so far ...
As a big fan of Qlib I must congratulate all who contribute to this project.
I have not yet tested it but would like to see a few issues fixed in any final 3.37.
1. The INSTR_CASE keyword as featured in SMSQ/E is not working in 3.36, no error is reported but its setting is ignored and the behaviour of INSTR is not changed.
2. A missing name after an END FOR, which is allowed in SBasic, prevented a compiled version of my program from running.
It kept me searching for weeks and was in the end found by Wolfgang Lenerz.
Normally it's not a feature I would use but as it's allowed it should be accepted by Qlib for END FOR (& END REP & NEXT) or at least produce an alert at compile time.
BSJR
Hi BSJR,
Thanks for adding these two to the list.
The Qlib compiler contains a full-blown parser in SuperBASIC. It will be easy to check for a missing name. For example, Parse_key_Repeat is defined at line 6840. Line 6870 would become ... Getsym : IF sym1% <> name% : program_error 1,28. Then at line 22262 ... = 28 : er$ = "name expected". The line number would also get printed, along with the message. Qlib does need to have the names to remain compatible with QDOS.
For "INSTR_CASE", we could look through Qlib's name table to see whether it's present. To find the line number where it would have been used is slightly more complicated. I will have to look deeper into this.
It could be a good idea to create a list of such SMSQ/E procedures that don't work in Qlib, then we can search for each one and report on them if they are used.
To start the list off, we have "INSTR_CASE". If anyone knows of any more, then please let us know.
I believe it would be good if we leave at least a month between versions. v3.37 was released on 15th March, so for this next coming update, which will be v3.38, I suggest we don't release this until 15th April. That should give us plenty of time to implement all these new features, test them out and make sure they work. In the meantime, if anybody wants to add to the list, then please do so. The more improvements we make the better it will be. Of course, there will be further updates in due course.
EmmBee
Re: New QLiberator v3.37
Posted: Fri Apr 03, 2020 10:50 am
by pjw
Well, theres DIV and MOD for starters: SMSQ/E works on long integers, Qdos on word. But Qlib uses its own internal word-sized routines. Making those long shouldnt hurt.
Re: New QLiberator v3.37
Posted: Fri Apr 03, 2020 11:41 am
by BSJR
pjw wrote:BSJR wrote:<>
Normally it's not a feature I would use but as it's allowed it should be accepted by Qlib for END FOR (& END REP & NEXT) or at least produce an alert at compile time.
I agree that this should be flagged, but as above, making it SMSQ/E compatible might not be easy, especially if the resulting object code is still to be compatible with other platforms.
Regarding your elusive bug: I find it sometimes helps to let the Turbo parser have a go at recalcitrant code. Its pretty good at uncovering obscure errors.
Surely it should not be the task of Qlib to make SMSQ/E SBasic compatible for QDOS platforms.
It's up to the programmer to make clear if it's QDOS or SMSQ/E only. SuQcess comes in two flavours "1.20" for QDOS and "2.07" for SMSQ/E. Other programs may use QDOS sections to avoid incompatibilities.
During my bug search I tried XREF to analyse the code but the program was simply too big for the old XREF.
I also tried analysing sections and got reports of missing Procs & FNs (because in the other section) but the missing name did not surface.
BSJR
Re: New QLiberator v3.37
Posted: Sat Apr 04, 2020 11:19 am
by pjw
BSJR wrote:<>
Surely it should not be the task of Qlib to make SMSQ/E SBasic compatible for QDOS platforms.
It's up to the programmer to make clear if it's QDOS or SMSQ/E only. SuQcess comes in two flavours "1.20" for QDOS and "2.07" for SMSQ/E. Other programs may use QDOS sections to avoid incompatibilities.
I probably didnt explain very well what I mean. No matter, I know what I mean
During my bug search I tried XREF to analyse the code but the program was simply too big for the old XREF.
I also tried analysing sections and got reports of missing Procs & FNs (because in the other section) but the missing name did not surface.
I havent found the limits to Xref yet. I use V 3.10. However Xref isnt a parser but basically a nametable analyser+. Turbo actually parses the tokenised program. Here is the Turbo report of some rubbish Qlib swallows raw:
Code: Select all
100 REMark Test Turbo
110 ch = FOPEN("con")
120 CLS#ch
130 :
140 REPeat lp
150 FOR i = 1 TO 99
160 IF 1 THEN : EXIT
**** ERROR at 160: Incorrect SuperBasic syntax.
170 END FOR i
180 PRINT#ch; 'got here'
190 EXIT
**** ERROR at 190: Incorrect SuperBasic syntax.
200 PRINT#ch; 'Whats this?'
210 END REPeat
**** ERROR at 210: Incorrect SuperBasic syntax.
220 PAUSE#ch
++++ Warning at 220: END REPeat lp assumed.
TURBO: Parsing done, 3 errors and 1 warning .
I presume that, provided Turbo didnt give up due to the code being too big or complex, it would have uncovered your bug. As I said, in extremis, I usually try this before getting out my gun and whiskey..
Re: New QLiberator v3.37
Posted: Sat Apr 04, 2020 11:41 am
by pjw
PS: During testing I compiled a version of the test program above with Qlib. It compiled and seem to run, although incorrectly. It may have quietly crashed my system. However, I dont know which version it freaked out on, and cant be bothered to try to find out now. So just be warned!
Re: New QLiberator v3.37
Posted: Sat Apr 04, 2020 12:02 pm
by RalfR
pjw wrote:PS: During testing I compiled a version of the test program above with Qlib. It compiled and seem to run, although incorrectly. It may have quietly crashed my system. However, I dont know which version it freaked out on, and cant be bothered to try to find out now. So just be warned!
Does 3.36 and 3.37 gave the same results?
Re: New QLiberator v3.37
Posted: Sat Apr 04, 2020 2:15 pm
by pjw
RalfR wrote:pjw wrote:PS: During testing I compiled a version of the test program above with Qlib. It compiled and seem to run, although incorrectly. It may have quietly crashed my system. However, I dont know which version it freaked out on, and cant be bothered to try to find out now. So just be warned!
Does 3.36 and 3.37 gave the same results?
Blithely compiling program lines with bits missing when it cant handle the case is an untrapped error in Qlib. Unless it has been fixed in V3.37 I presume it will give a similar result, ie a non-working program at best, and total meltdown at second-worst.
Re: New QLiberator v3.37
Posted: Sat Apr 04, 2020 10:27 pm
by stevepoole
Hi Emmbee,
Nice work you are doing on Qliberator.
Would it be possible to allow keywords such as LIST etc to be recognised, to make programs be compatible with, say, QPC2 .
There are of course simple workarounds in this case, but for other missing commands, not so....
Best Wishes,
Steve.
Re: New QLiberator v3.37
Posted: Sun Apr 05, 2020 11:13 am
by EmmBee
Hi Steve,
Yes, thanks for the idea. Keywords such as LIST, SAVE, LOAD, etc. only work in Basic - they won't work compiled. There are about a dozen or so of these keywords. I'll add them all to the list of prohibited names to be checked for.
I note that "INSTR_CASE" also does not work in Turbo. Perhaps someone would like to write a QLIB external INSTRcase(x$,y$) function?