Hi
Thanks to everyone who answered my initial post on this peculiar issue
of MRUN not continuing to run the remaining program after merging some
definitions.
Firstly, I tried the simple cases suggested and yes, MRUN works just as
expected.
Secondly, line numbers of the merged definitions were not at fault (no
overlap with existing lines).
Then I started to carry out (what turned out to be) an exhaustive bit of
testing with my own boot program and have now been able to replicate
this curious behaviour.
This testing appears to have isolated a _possible_ problem with SBASIC
when LRESPRing a significant number of SB resident extentions from
within a PROC. It's more than open to interpretation, but if you're
still interested, let me explain (it's a bit long winded, but then I
test software as part of my real job and get a bit fastidious about it).
Take the following simple example (no MRUN involved here):
Scenario A: LRESPR in the main program - OK.
10 LRESPR <some_extn_file> : REMark ** LRESPR some useful SB extentions
20 dummy_proc : REM ** Call a PROC that
doesn't exist in this program
Because the PROC dummy_proc doesn't exist, the following (expected)
error is returned:
At line 20:1 unknown procedure
OK, so far.
Scenario B: LRESPR from within an invoked PROC - Unusual.
10 init_extns : REMark ** Call a PROC that LRESPRs some
useful SB extentions
20 dummy_proc : REM ** Call a PROC that doesn't exist in this proram
...
100 DEF PROC init_extns
110 LRESPR <some_extn_file>
120 END DEF
Now, the invocation of PROC dummy_proc still causes an error, but this
time is thus:
At line 120:1 unknown procedure
Curious - the SB program pointer appears to have gotten screwed. No
biggie in this simplistic case.
However, coming back to the MRUN issue (finally), let's assume that
dummy_proc is contained in another file <dummy_proc_def>, like this:
200 DEF PROC dummy_proc
210 PRINT 'Running dummy_proc...'
220 END DEF
Now let's see what happens...
Scenario C: LRESPR in the main program, with MRUN - OK.
10 LRESPR <some_extn_file> : REMark ** LRESPR some useful SB extentions
15 MRUN <dummy_proc_def>
20 dummy_proc : REM ** Call a PROC that has
just been MERGEd
Because the PROC dummy_proc now exists, it runs without error as
expected, printing the debug message 'Running dummy_proc...'
Scenario D: LRESPR from within an invoked PROC, then MRUN - Unhelpful.
10 init_extns : REMark ** Call a PROC that LRESPRs some
useful SB extentions
15 MRUN <dummy_proc_def>
20 dummy_proc : REM ** Call a PROC that has just been MERGEd
...
100 DEF PROC init_extns
110 LRESPR <some_extn_file>
120 END DEF
In this case, the invocation of dummy_proc just never happens, no debug
message is printed and the program simply halts withour error. An
inquisitive LISTing shows dummy_proc is safely merged.
This is the behaviour that lead to my initial posting.
I've tested with various SB resident extention files - DIY Toolkits,
Turbo (full) TK, the QLib1.6 TK, as well as FileInfo and Menu_rext.
All result in the same obserevd behaviour, _except_ when LRESPRing the
simple ENV extentions.
My _guess_ for the difference in behaviour between TKs is that ENV
doesn't add as many extra SB resident procs/fns as the others and the
growth in the name table while running inside the init_extns proc is
clobering some return stack or SB variable. Now I'm talking well out of
my league, so will stop here.
It's hardly a show-stopper - I can simply move my LRESPRs outside a
defined proc, but thought that there might be at least one of you who'd
be marginally interested (Marcel?)
Oh, I'm running QPC 3.34, SMSQ/E 3.13 HBA with 16MB RAM.
Regards,
Martyn Hill
London.
Martyn Hill wrote:
Hi again
Could anyone say whether the behaviour that I'm seeing when using MRUN
in a running SBASIC prog is expected?
As part of my initial SB boot prog, I include an MRUN statement that
successfully merges some useful SB definitions (only).
I expect the boot prog to continue to execute the next statement, but
it simply stops after merging the DEFs.
I'm running this in QPC. Is this expected behaviour? I read in the
manual that MRUN in a program _should_ continue with the next runnable
statement in the program.
Regards,
Martyn Hill
London.
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
