I'm afraid Marcel is required - horrible bug in SBASICs MultiBASICs

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

[RalfR]

What if the REMarks are on a separate line? Would that work? It would also be clearer.

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

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

[pjw]

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

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

[RalfR]

I have now found version 4.05 of QPC and it unfortunately has the same bug.

Why not use v5.02?

[ql_freak]

I want just to test, if this bug also existed in previous version(s) of QPC2.

[ql_freak]

I have now tested it (on 5.02) without any extension LRESPRed except the required Turbo Toolkit, the bug is still there.

[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