Page 1 of 2
I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Thu Feb 27, 2025 10:14 pm
by ql_freak
I wanted to test my SuperBASIC-Library "hps_sbl" (sbl for SuperBasicLibrary) with
Code: Select all
t$='1234 ':print '"';rstrip$(t$);'"','"';t$;'"'
You can define the following hotkey for the above command:
Code: Select all
ERT HOT_KEY('y', "t$='1234 ':print '"&'"'&"';rstrip$(t$);'"&'"'&"','"&'"'&"';"&"t$;'"&'"'&"'")
The result of the command is (only in a MultiBASIC not in job 0,0):
At line 20592: fatal error in SBASIC interpreter
Line 20592 (to) is:
Code: Select all
20592 DEFine FuNction hps_openOver%(c%,fnam$):REMark Opens device for writing
... (comments removed)
20608 IF DEVICE_STATUS(0,fnam$)>=0:DELETE fnam$
20612 IF DEVICE_STATUS(1,DATAD$&fnam$)>=0:RETurn -15:REMark A fully qualified
20616 REMark filename must be passed to this function!
20620 RETurn FOP_NEW(#c%,fnam$)
20624 END DEFine :REMark hps_openOver()
I have then tried to track down, where the problem is. You will find my shortened versions of the lib in the attached zip-file. Run from hps_sbl, hps01_sbl to hps03_sbl. There are other errors and WARNING: hps03_sbl will hang the SBASIC job, not even CTRL+SPACE is working, you must remove the job.
I have tested all versions on UQLX with a Minerva 1.98 MultiBASIC job and all versions run successfully.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Fri Feb 28, 2025 8:56 am
by RalfR
What if the REMarks are on a separate line? Would that work? It would also be clearer.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Fri Feb 28, 2025 11:09 am
by Martin_Head
I know putting a REMark on the end of a DEFine line can confuse some QL operating system versions.
It thinks you are trying to do a one line definition like this.
DEFine FuNction test (x) : RETurn x=x*x : END define test
I would also avoid adding anything after the END DEFine, and I would put the proc/fun name on the end of the END DEFine.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 6:41 am
by ql_freak
I have now written a fourth version (based on hps04_sbl) where I have removed the REMarks after the DEFine and END DEFine lines. Same result, SBASIC hangs.
As far as I know it is NOT(!) allowed to write the name of a PROCedure or FuNction after the END DEFine (except for Minerva and SBASIC). The examples in the official QL manual in the Beginner's Guide do not add the name after the END DEFine. This is why I used the REMark FuNctionNAME construct.
And as I have said: On Minerva all examples are working (in MultiBASIC jobs) as expected and they work on SBASIC in the first (0,0) job. So I'm nearly sure it must be a bug in the MultiBASIC jobs of SBASIC.
BTW: For testing I loaded all programs and immediately tested it with:
Code: Select all
t$='1234 ':print '"';rstrip(t$);'"','"';t$;'"'
This is why I have added the HOT_KEY definition to insert this command.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 9:45 am
by pjw
ql_freak wrote: Sat Mar 01, 2025 6:41 am
<>
As far as I know it is NOT(!) allowed to write the name of a PROCedure or FuNction after the END DEFine (except for Minerva and SBASIC). The examples in the official QL manual in the Beginner's Guide do not add the name after the END DEFine. This is why I used the REMark FuNctionNAME construct.
<>
It is perfectly possible to add the procedure/function name after the END DEFine! At least from JM and up. The interpreter doesnt care whether you do or dont, or even if you misspell it. Recent versions of Qlib, however, complain if there is a mismatch between the DEFine name and the END DEFine name, although it too doesnt care if you dont put a name there at all.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 3:26 pm
by ql_freak
Thank you Per, don't know why I thought it's forbidden to add the name after the END DEFine.
I have now found version 4.05 of QPC and it unfortunately has the same bug. My example works in SBASIC job 0,0 but fails in additional SBASIC jobs.
It seems there is a problem with the parameter c% of hps_openOver(c%,fnam$). If I change it to chan% it is working.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 3:43 pm
by RalfR
ql_freak wrote: Sat Mar 01, 2025 3:26 pmI have now found version
4.05 of QPC and it unfortunately has the same bug.
Why not use v5.02?
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 4:21 pm
by ql_freak
I want just to test, if this bug also existed in previous version(s) of QPC2.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 4:41 pm
by ql_freak
I have now tested it (on 5.02) without any extension LRESPRed except the required Turbo Toolkit, the bug is still there.
Re: I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs
Posted: Sat Mar 01, 2025 5:40 pm
by martyn_hill
Hi Peter!
After a bit of playing around, I think I can more accurately describe the anomaly that you have been seeing - the below may assist who so ever takes it upon themselves to review and update the (open source) SBASIC parser in SMSQe.
If the first variable enumerated when the SBASIC daughter job is parsed is then used as a formal parameter in a function/procedure, very odd things happen (TM).
The effects vary slightly as to whether that variable appears as the
first formal parameter, or
later (first being catastrophic, later in the param list, ignored, but upsets the structure parsing.)
To test this theory, simply change line 101 (taking hps03.sbl) from:
Code: Select all
101 c%=1:f%=4: REMark c%: Console channel - f%: File channel
to:
Code: Select all
101 c2%=1:f%=4: REMark c%: Console channel - f%: File channel
Then without any further changes, you should find that your test routines work as expected.
There are some other, unrelated refinements one could offer to the existing coding of those routines, but not relevant to the issue you're trying to overcome.
Good find
