Op Sun, 12 Nov 2017 18:11:57 +0100 schreef Per Witte via Ql-Users <ql-users@lists.q-v-d.com>:

Is this the sort of issue you mean?

100 CLS
110 FOR i = 0 TO 4
120  FOR j = 0 TO 4
130   AT i * 2, j * 6: PRINT i; ','; j;
140  END FOR
150 END FOR
160 :
170 PRINT
180 PAUSE

RUNs fine under SMSQ/E, displays only the first line if compiled as a Qlib job (but no errors or warnings are given - either at compile time or when executing). Turbo, even under SMSQ/E, kicks up a fuss at parse time, and if
you load it in SuperBASIC under Qdos or Minerva lines 140 and 150 show up
as MISTake's. So its normally a good idea to try out problematic code in
different environments. It doesnt necessarily have to work 100% before
certain mistakes reveal themselves.

That's exactly what I mean.
Once fixed the compiler bug was gone and the compiled program did no longer freeze and produced it's windows.

The call to my procedure with the END FOR line was even REM'd out but still QLIB got in trouble and messed up the _obj and SMSQE.

On 12 November 2017 at 13:54, Bob Spelten via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

Op Tue, 12 Sep 2017 18:47:35 +0200 schreef Bob Spelten <b...@upcmail.nl>:

What's happening?

I have successfully compiled a new version of my program.
That's to say, there were no errors reported by BasicLinker or Qlibeator. But when the _obj is executed nothing seems to happen, no menu to act on.
It's there in the JOBS list but no channels were opened for it.
When I then kill this job it has the effect that the QD with the
programs  _bas can no longer produce lists of my Procs and FNs from the
C-F6 to C-F8 buttons or keys.

(...)

It's been 2 month since I reported this problem.
After many attempts to locate the problem Wolfgang Lenerz finally found
the culprit.
It was one missing index variable on an END FOR line.

"Unnamed NEXT, EXIT and END statements" is a feature of SMSQ/E.
Normally I am no fan of this as it can make the program more difficult to read, especially when start and end of the loop are far apart.
This one (actually two) had escaped my proof reading.

Now it turned out Q_Liberator also cannot deal with it and can, as was the case here, corrupt SMSQ/E in a sneaky way without a Sysmon alarm.
So be warned, don't use this "feature" with Qlib!


Bob


--
The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/";
_______________________________________________
QL-Users Mailing List

Reply via email to