Re: [Ql-Users] "RETurn not in procedure or function"
Am 28.06.21 um 20:59 schrieb Wolfgang Lenerz via Ql-Users:
Hi,
See my earlier answer to Bob - where does "EXISTS" come from?
>
> Wolfgang
>
http://www.dilwyn.me.uk/tk/exists.zip
Exists (3K) - Phil Borman extension function to test if an extension
name is currently installed on your system.
hello
found some oddities with Exists and SMSQE
10 if exists ("TK2_EXT"):print "TK2"
20 if exists ("MODE") :print "mode "
30 :
40 print dig_it
50 :
60 def fun dig_it
70 ret 1
80 end def
run
so far so good
now delete line 10
run again
error return not in function
turns out the error is triggered if the length of the
keyword is even
Greetings from Switzerland
Markus
___
QL-Users Mailing List
___
QL-Users Mailing List
___
QL-Users Mailing List
Re: [Ql-Users] "RETurn not in procedure or function"
Hi,
See my earlier answer to Bob - where does "EXISTS" come from?
Wolfgang
> hello
>
> found some oddities with Exists and SMSQE
>
> 10 if exists ("TK2_EXT"):print "TK2"
> 20 if exists ("MODE") :print "mode "
> 30 :
> 40 print dig_it
> 50 :
> 60 def fun dig_it
> 70 ret 1
> 80 end def
>
> run
> so far so good
>
> now delete line 10
> run again
> error return not in function
>
> turns out the error is triggered if the length of the
> keyword is even
>
> Greetings from Switzerland
>
> Markus
>
> ___
> QL-Users Mailing List
___
QL-Users Mailing List
Re: [Ql-Users] "RETurn not in procedure or function"
Hi, in my experience, this is often caused by a Basic extension not resetting the stack correctly. This generally seems to be the case either when a keyword changes the value of an entry parameter, to make it into a return parameter, or when a function returns a value (very often a string). But without having a complete program to test, this will be difficult to find out. Regards Wolfgang > "RETurn not in procedure or function" > > What is causing this error in my Basic? > The error has bugged me for weeks now. > It even seems able to move around (see below). > I have checked for the obvious and didn't find any mismatches. > Also XREF, BasicLinker or QLIB did not report any. > > Below a summary of the program section from where the error occurs. > > DEF FN GetScreen(..) > :... > IF hd =10 > MC_ProcA parms.. > ELSE > er%= MC_FnB(..) > :... > END IF > :... > IF NOT rn% : er%= SetDBS(..) > REM > rn% is set if the screen file is in the database > :... > RETurn 0 > END DEF > :... > DEF FN SetDBS(..) > :... > er= FDB_SET(..) > :... > PRINT er > REturn er > END DEF > : > > The program is numberless and testrun from QD with the F10 Sbas/qd thing. > The code for the MC_ProcA and MC_FnB keywords has also successfully been > tested in other Basics. > > MC_FnB nicely returns zero in er% and not one of the possible negative > values. > SetDBS does some DBAS handling and doesn't return an error in er, as > tested just before the RETurn line which produces the "RETurn not..." > error. Checking the database confirms that SetDBS works properly. > > Strangely when I REM the SetDBS call, the same error is given in another > FN when GetScreen has long been left by its own RETurn. > > Also the MC_ProcA route does not generate the error when doing the > SetDBS call or in the other Sbas FN if skipping SetDBS. > > When I compile the Basic with QLIB v3.36 there are no errors reported > and the compiled _obj executes without producing this error. > > Of course the Sbas version differs slightly from the _obj but this has > mainly to do with reporting variable values. Also the Basic extensions > as for the MC_xxx ones above are LRESPR'd in the Sbas run and $$asmb'd > by Qlib. > > The numbered Basic as generated by BasicLinker and then run from job 0 > produces the same error as run from QD. > > So what could be messing up my RETurns? > > Bob > ___ QL-Users Mailing List
Re: [Ql-Users] "RETurn not in procedure or function"
Am 28.06.21 um 15:49 schrieb pjwitte via Ql-Users:
On 28/06/2021 13:10, desin via Ql-Users wrote:
Am 28.06.21 um 12:31 schrieb Bob Spelten via Ql-Users:
"RETurn not in procedure or function"
<>
Bob
hello
found some oddities with Exists and SMSQE
10 if exists ("TK2_EXT"):print "TK2"
20 if exists ("MODE") :print "mode "
30 :
40 print dig_it
50 :
60 def fun dig_it
70 ret 1
80 end def
run
so far so good
now delete line 10
run again
error return not in function
turns out the error is triggered if the length of the
keyword is even
Greetings from Switzerland
Markus
Yes, that was my first thought too: A stack problem in one of the m/c
functions
Per
it must be the parser / interpreter that throws the error
because a
print dig_it
works
i was able to reproduce it on QPC1 / SMSQE 2b93
QDOS is OK
Markus
___
QL-Users Mailing List
Re: [Ql-Users] "RETurn not in procedure or function"
On 28/06/2021 13:10, desin via Ql-Users wrote:
Am 28.06.21 um 12:31 schrieb Bob Spelten via Ql-Users:
"RETurn not in procedure or function"
<>
Bob
hello
found some oddities with Exists and SMSQE
10 if exists ("TK2_EXT"):print "TK2"
20 if exists ("MODE") :print "mode "
30 :
40 print dig_it
50 :
60 def fun dig_it
70 ret 1
80 end def
run
so far so good
now delete line 10
run again
error return not in function
turns out the error is triggered if the length of the
keyword is even
Greetings from Switzerland
Markus
Yes, that was my first thought too: A stack problem in one of the m/c
functions
Per
___
QL-Users Mailing List
Re: [Ql-Users] New Tools for Microdrive preservation
On Mon, 28 Jun 2021, at 12:40 PM, desin via Ql-Users wrote: > https://github.com/mist-devel/mist-binaries/tree/master/cores/ql > > and > > The "QL Software Collection" has been moved to archive.org > > Greetings from Switzerland > > Markus Nice to see the MiST core stuff get some love too! Graeme ___ QL-Users Mailing List
[Ql-Users] New Tools for Microdrive preservation
https://github.com/mist-devel/mist-binaries/tree/master/cores/ql and The "QL Software Collection" has been moved to archive.org Greetings from Switzerland Markus ___ QL-Users Mailing List
Re: [Ql-Users] "RETurn not in procedure or function"
Am 28.06.21 um 12:31 schrieb Bob Spelten via Ql-Users:
"RETurn not in procedure or function"
What is causing this error in my Basic?
The error has bugged me for weeks now.
It even seems able to move around (see below).
I have checked for the obvious and didn't find any mismatches.
Also XREF, BasicLinker or QLIB did not report any.
Below a summary of the program section from where the error occurs.
DEF FN GetScreen(..)
:...
IF hd =10
MC_ProcA parms..
ELSE
er%= MC_FnB(..)
:...
END IF
:...
IF NOT rn% : er%= SetDBS(..)
REM > rn% is set if the screen file is in the database
:...
RETurn 0
END DEF
:...
DEF FN SetDBS(..)
:...
er= FDB_SET(..)
:...
PRINT er
REturn er
END DEF
:
The program is numberless and testrun from QD with the F10 Sbas/qd thing.
The code for the MC_ProcA and MC_FnB keywords has also successfully been
tested in other Basics.
MC_FnB nicely returns zero in er% and not one of the possible negative
values.
SetDBS does some DBAS handling and doesn't return an error in er, as
tested just before the RETurn line which produces the "RETurn not..."
error. Checking the database confirms that SetDBS works properly.
Strangely when I REM the SetDBS call, the same error is given in another
FN when GetScreen has long been left by its own RETurn.
Also the MC_ProcA route does not generate the error when doing the
SetDBS call or in the other Sbas FN if skipping SetDBS.
When I compile the Basic with QLIB v3.36 there are no errors reported
and the compiled _obj executes without producing this error.
Of course the Sbas version differs slightly from the _obj but this has
mainly to do with reporting variable values. Also the Basic extensions
as for the MC_xxx ones above are LRESPR'd in the Sbas run and $$asmb'd
by Qlib.
The numbered Basic as generated by BasicLinker and then run from job 0
produces the same error as run from QD.
So what could be messing up my RETurns?
Bob
hello
found some oddities with Exists and SMSQE
10 if exists ("TK2_EXT"):print "TK2"
20 if exists ("MODE") :print "mode "
30 :
40 print dig_it
50 :
60 def fun dig_it
70 ret 1
80 end def
run
so far so good
now delete line 10
run again
error return not in function
turns out the error is triggered if the length of the
keyword is even
Greetings from Switzerland
Markus
___
QL-Users Mailing List
[Ql-Users] "RETurn not in procedure or function"
"RETurn not in procedure or function" What is causing this error in my Basic? The error has bugged me for weeks now. It even seems able to move around (see below). I have checked for the obvious and didn't find any mismatches. Also XREF, BasicLinker or QLIB did not report any. Below a summary of the program section from where the error occurs. DEF FN GetScreen(..) :... IF hd =10 MC_ProcA parms.. ELSE er%= MC_FnB(..) :... END IF :... IF NOT rn% : er%= SetDBS(..) REM > rn% is set if the screen file is in the database :... RETurn 0 END DEF :... DEF FN SetDBS(..) :... er= FDB_SET(..) :... PRINT er REturn er END DEF : The program is numberless and testrun from QD with the F10 Sbas/qd thing. The code for the MC_ProcA and MC_FnB keywords has also successfully been tested in other Basics. MC_FnB nicely returns zero in er% and not one of the possible negative values. SetDBS does some DBAS handling and doesn't return an error in er, as tested just before the RETurn line which produces the "RETurn not..." error. Checking the database confirms that SetDBS works properly. Strangely when I REM the SetDBS call, the same error is given in another FN when GetScreen has long been left by its own RETurn. Also the MC_ProcA route does not generate the error when doing the SetDBS call or in the other Sbas FN if skipping SetDBS. When I compile the Basic with QLIB v3.36 there are no errors reported and the compiled _obj executes without producing this error. Of course the Sbas version differs slightly from the _obj but this has mainly to do with reporting variable values. Also the Basic extensions as for the MC_xxx ones above are LRESPR'd in the Sbas run and $$asmb'd by Qlib. The numbered Basic as generated by BasicLinker and then run from job 0 produces the same error as run from QD. So what could be messing up my RETurns? Bob -- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com ___ QL-Users Mailing List
