New QLiberator v3.37

Anything QL Software or Programming Related.
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: New QLiberator v3.37

Post 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.


Per
dont be happy. worry
- ?
EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: New QLiberator v3.37

Post 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


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: New QLiberator v3.37

Post 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.


Per
dont be happy. worry
- ?
User avatar
BSJR
Trump Card
Posts: 182
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: New QLiberator v3.37

Post 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


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: New QLiberator v3.37

Post 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..


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: New QLiberator v3.37

Post 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!


Per
dont be happy. worry
- ?
User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: New QLiberator v3.37

Post 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?


4E75 7000
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: New QLiberator v3.37

Post 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.


Per
dont be happy. worry
- ?
stevepoole
Super Gold Card
Posts: 712
Joined: Mon Nov 24, 2014 2:03 pm

Re: New QLiberator v3.37

Post 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.


EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: New QLiberator v3.37

Post 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?


Post Reply