Re: [Ql-Users] "RETurn not in procedure or function"

2021-07-01 Thread Bob Spelten via Ql-Users

Wolfgang Lenerz via Ql-Users wrote:

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?


As expected it was stack problem with my MC_FnB.
Not being an expert I had looked at some examples and ended up using a mix.
It has now been sorted and I can go on with testing the rest of the program.

I agree with Francois, using LOOKUP% as alternative for EXISTS.
I use it a lot. It returns the place in the name table which can also be 
used to test for conflicting keywords if found out of place.


Bob



--
Deze e-mail is gecontroleerd op virussen door AVG.
http://www.avg.com

___
QL-Users Mailing List

Re: [Ql-Users] "RETurn not in procedure or function"

2021-07-01 Thread François Van Emelen via Ql-Users

Op 28/06/2021 om 13:10 schreef desin via Ql-Users:

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


You could replace 'EXISTS' with 'LOOKUP%'.

'LOOKUP%' can be found in 'function_code' by Simon Goodwin's toolkit series.

Have a fine day.

François Van Emelen



___
QL-Users Mailing List

Re: [Ql-Users] "RETurn not in procedure or function"

2021-06-29 Thread pjwitte via Ql-Users

On 29/06/2021 11:44, Bob Spelten via Ql-Users wrote:

Wolfgang Lenerz via Ql-Users wrote:

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.


Thanks for the suggestions.

My function does not change any of the entry parameters, only sets 
the return value. I have written other functions that do the same 
but without this anomaly, also with 8 chr names.
Anyway I will check the exit section to see what I did differently 
from previous and consult the Assembly Language PDFs to get it right. 

Bob,
If theres no problem with your S*BASIC structure (which I presume is 
the case since youre desperate enough to write here) then the problem 
must almost certainly be with one of the extensions used. A problem 
with SBASIC itself is possible but even less likely.
A string function is the most likely culprit as its easy to make a 
mistake with the return stack, but as Wolfgang mentioned, it could 
also be a bplet issue. My usual test rig for any function I write 
looks something like this:


rem Testing the function TEST$
m = free_mem: mm = m
for i = 0 to 
:
t$ = 'x' & TEST$('abc')
t$ = TEST$('abc') & 'x'
t$ = 'x' & TEST$('abc') & 'x'
:
t$ = 'x' & TEST$('abcd')
t$ = TEST$('abcd') & 'x'
t$ = 'x' & TEST$('abcd') & 'x'
:
if m <> free_mem then
 print m - free_mem
 m = free_mem
endif
endfor i
print 'Memory eaten:'! mm - free_mem

A healthy function should never eat memory as it goes! A function like 
that may well mess up the interpreter's return stack.


NB: The routine may crash the system if theres a serious problem with 
the function. But at least then youll know.


HTH, Per

___
QL-Users Mailing List

Re: [Ql-Users] "RETurn not in procedure or function"

2021-06-29 Thread Bob Spelten via Ql-Users

Wolfgang Lenerz via Ql-Users wrote:

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.


Thanks for the suggestions.

My function does not change any of the entry parameters, only sets the 
return value. I have written other functions that do the same but 
without this anomaly, also with 8 chr names.
Anyway I will check the exit section to see what I did differently from 
previous and consult the Assembly Language PDFs to get it right.


Thanks,
Bob



--
Deze e-mail is gecontroleerd op virussen door AVG.
http://www.avg.com

___
QL-Users Mailing List


Re: [Ql-Users] "RETurn not in procedure or function"

2021-06-28 Thread desin via Ql-Users

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"

2021-06-28 Thread Wolfgang Lenerz via Ql-Users
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"

2021-06-28 Thread Wolfgang Lenerz via Ql-Users
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"

2021-06-28 Thread desin via Ql-Users

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"

2021-06-28 Thread 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

___
QL-Users Mailing List

Re: [Ql-Users] "RETurn not in procedure or function"

2021-06-28 Thread desin via Ql-Users

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