Re: [Ql-Users] SBASIC interpreter bug?

[François Van Emelen via Ql-Users]

Op 23/11/2022 om 16:40 schreef pjwitte via Ql-Users:

On 23/11/2022 14:51, François Van Emelen via Ql-Users wrote:

Op 22/11/2022 om 13:26 schreef pjwitte via Ql-Users:

Does anyone know whats going on here?
<>

Could this solve your problem?

100 ch = FOPEN("con"): CLS#ch
110 test ch, 25
120 print#ch,"hit a key to stop" :PAUSE#ch,-1
130 CLOSE#ch
140 :
150 DEFine PROCedure test(coucou, a)
160 PRINT#ch; coucou,a
180 END DEFine test

Only replaced 'ch' as first parameter with 'coucou'

tested in QD sbas/qd and ex the file

François Van Emelen


Thanks for playing, François,

But its not MY problem. It is A problem. I normally manage to work 
around it these days, as I do numerous other little quirks and 
"features".


It only became a problem for me 'tother day  after I merged some some 
well-tested library routines with a larger project, not realising that 
some of my global variables happened to have the same name as the 
parameters of some function (Duh!) Then I wasted a stressful hour and 
a half trying to figure out why the program would just hang without 
there being anything "wrong" with it. (It compiled with Qlib and the 
Turbo parser did not report any relevant errors, etc.) I made some 
changes and then I kept getting nonsense structural errors instead. In 
other words a huge time waster; just the sort of thing to put people 
off writing decent, modern programs  in SBASIC for SMSQ/E!


That being said, I dont expect anyone to try to fix it! It takes some 
skill and, more importantly, "being in the picture". Ie it takes time 
to get into the thing, especially if it has been a while. And bug 
hunting can be a dreadful, time consuming business even for the best.


At least by bringing it up here, where there still appears to be some 
interest in SMSQ/E and QL software, people may be made aware and save 
themselves some head/heartache.


Per
___
QL-Users Mailing List


Hi Per,

I know that is not Your problem but when I saw that Wolgang seemed 
somewhat puzzled too, I decided to reply to your question.


The error ‘DEFines may not be within other clauses’ has already been a 
topic but I can’t remember where it was. Here or private mail ?


Many thanks to you and Martin Hill for Qlib 3.45.

I am not a member of ql forum (only have a look now and then)

François Van Emelen

___
QL-Users Mailing List

Re: [Ql-Users] SBASIC interpreter bug?

[pjwitte via Ql-Users]

On 23/11/2022 14:51, François Van Emelen via Ql-Users wrote:

Op 22/11/2022 om 13:26 schreef pjwitte via Ql-Users:

Does anyone know whats going on here?
<>

Could this solve your problem?

100 ch = FOPEN("con"): CLS#ch
110 test ch, 25
120 print#ch,"hit a key to stop" :PAUSE#ch,-1
130 CLOSE#ch
140 :
150 DEFine PROCedure test(coucou, a)
160 PRINT#ch; coucou,a
180 END DEFine test

Only replaced 'ch' as first parameter with 'coucou'

tested in QD sbas/qd and ex the file

François Van Emelen


Thanks for playing, François,

But its not MY problem. It is A problem. I normally manage to work 
around it these days, as I do numerous other little quirks and 
"features".


It only became a problem for me 'tother day  after I merged some some 
well-tested library routines with a larger project, not realising that 
some of my global variables happened to have the same name as the 
parameters of some function (Duh!) Then I wasted a stressful hour and 
a half trying to figure out why the program would just hang without 
there being anything "wrong" with it. (It compiled with Qlib and the 
Turbo parser did not report any relevant errors, etc.) I made some 
changes and then I kept getting nonsense structural errors instead. In 
other words a huge time waster; just the sort of thing to put people 
off writing decent, modern programs  in SBASIC for SMSQ/E!


That being said, I dont expect anyone to try to fix it! It takes some 
skill and, more importantly, "being in the picture". Ie it takes time 
to get into the thing, especially if it has been a while. And bug 
hunting can be a dreadful, time consuming business even for the best.


At least by bringing it up here, where there still appears to be some 
interest in SMSQ/E and QL software, people may be made aware and save 
themselves some head/heartache.


Per
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC interpreter bug?

[Wolfgang Lenerz via Ql-Users]

Hi,

Per wrote:

> Perhaps you didnt EX it? If you RUN it it may work, although a
> differently constructed (more complex) version would also fail.

I didn't ex it, just ran it - the problem was already seen under an 
SBasic daughter job.



Derek wrote:


It looks like the variable for the FOPEN parameter is getting mixed up with the 
parameter on the Procedure parameter.


Indeed, but I believe that the point Per was making is that it shouldn't.


Wolfgang
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC interpreter bug?

[Derek via Ql-Users]

Hi 

I changed the ch in the FOPEN variable to chan and it worked with EX, SBAS.

It looks like the variable for the FOPEN parameter is getting mixed up with the 
parameter on the Procedure parameter.

I also tried the original program on Minerva with MultiBasic executing the 
program with: EX pipep;"test_bas>" 

Seemed work without any problem, clearlt SMSQ/E is a little stricter than 
Minerva on variable.
---
Regards,
Derek
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC interpreter bug?

[François Van Emelen via Ql-Users]

Op 22/11/2022 om 13:26 schreef pjwitte via Ql-Users:

Does anyone know whats going on here?

SBASIC only: EXecute the following program:

100 ch = FOPEN("con"): CLS#ch
110 test ch, 1
120 PAUSE#ch
130 CLOSE#ch
140 :
150 DEFine PROCedure test(ch, a)
160 PRINT#ch; a
180 END DEFine test

Result in this case:

At line 150:4 DEFines may not be within other clauses

However there are various error conditions depending on how the program
is constructed. In the worst case it just hangs and must be RJOBed.

What seems to get the interpreter's knickers in a twist is a parameter
being referenced using the same name as the parameter, 'ch' in this case.
This is supposed to be perfectly "legal". I dont know when this behaviour
started but Ive noticed it for a while.

It would be nice if this could be fixed as, for example, in larger
projects, when using library code you dont necessarily notice that 
variable

names are the same a parameter names, and so you may end up getting
unexplained hangs or obscure error messages that dont actually relate to
the problem.

Per


___
QL-Users Mailing List


Hi,

Could this solve your problem?

100 ch = FOPEN("con"): CLS#ch
110 test ch, 25
120 print#ch,"hit a key to stop" :PAUSE#ch,-1
130 CLOSE#ch
140 :
150 DEFine PROCedure test(coucou, a)
160 PRINT#ch; coucou,a
180 END DEFine test

Only replaced 'ch' as first parameter with 'coucou'

tested in QD sbas/qd and ex the file

François Van Emelen



___
QL-Users Mailing List

Re: [Ql-Users] SBASIC interpreter bug?

[pjwitte via Ql-Users]

Perhaps you didnt EX it? If you RUN it it may work, although a 
differently constructed (more complex) version would also fail.


Anyway, its not about the platform, its about SMSQ/E. Ive tried it on 
SMSQ/E V3.25, 3.38 and 3b39 - all present with the same problem.


Per
On 22/11/2022 16:38, Timothy Swenson wrote:
> I just tested the short program with SMSQmulator 2.3.1 (for Java 
11) and I did not get an error. A black CON window opened up and 
printed the number 1.

>
> What platforms were tested that generated the error?
>
> Tim Swenson
>

___
QL-Users Mailing List

Re: [Ql-Users] SBASIC interpreter bug?

[pjwitte via Ql-Users]

RUNing appears to work; its when EXing this program that the problem 
shows up.
I believe its possible to get an error on RUNing too, I just havent 
been able to recreate the conditions.


Typical errors are:
At line nnn: 
At line : undefined loop control 
variable

etc, all nonsense

Clearly, EXecuted SBASIC programs get a different environment than 
RUNed ones. Like the "program":


100 PRINT
110 END REPeat loop

doesnt throw an error when RUN, only when EXecuted.

Per

On 22/11/2022 17:13, Wolfgang Lenerz via Ql-Users wrote:

Hi,



Does anyone know whats going on here?



Nope...

Even stranger : once you run this and it failed, change the variable 
name ("ch") to something else (like "cht") everywhere . Run it - and 
it works. Save the prog with that new variable name, start a new 
basic session, load the prog, run it- and it fails. Change "cht" 
back to "ch" - and it works.


Have fun (?)

Wolfgang


SBASIC only: EXecute the following program:
 >>




100 ch = FOPEN("con"): CLS#ch
110 test ch, 1
120 PAUSE#ch
130 CLOSE#ch
140 :
150 DEFine PROCedure test(ch, a)
160 PRINT#ch; a
180 END DEFine test

Result in this case:

At line 150:4 DEFines may not be within other clauses

However there are various error conditions depending on how the 
program

is constructed. In the worst case it just hangs and must be RJOBed.

What seems to get the interpreter's knickers in a twist is a parameter
being referenced using the same name as the parameter, 'ch' in this 
case.
This is supposed to be perfectly "legal". I dont know when this 
behaviour

started but Ive noticed it for a while.

It would be nice if this could be fixed as, for example, in larger
projects, when using library code you dont necessarily notice that 
variable

names are the same a parameter names, and so you may end up getting
unexplained hangs or obscure error messages that dont actually 
relate to

the problem.

Per


___
QL-Users Mailing List


___
QL-Users Mailing List


___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

[Giorgio Garabello via Ql-Users]

 Yes, it works perfectly!
Thanks for your advice which has become fundamental for me
Do you think I wrote on the mailing list because I didn't want to disturb
you. :-)

Regards
Gio

P.Š. I looked at those things that you added on your fantastic site
. WOW 

Il giorno dom 22 mar 2020 alle ore 22:11 pjwitte via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:

> I was just pointing out, to anyone interested, that there is a lot
> more one can do with this ;o) Obviously a myprog_bas program has to
> exist and be valid, and the exclamation mark was informative and not
> meant to be part of the command.
> But EXEP 'SBASIC' should do what I presume you were trying to do.
> Per
> On 22/03/2020 21:35, Giorgio Garabello via Ql-Users wrote:
> > Il giorno dom 22 mar 2020 alle ore 18:22 pjwitte via Ql-Users <
> > ql-users@lists.q-v-d.com> ha scritto:
> >
> >> Try EXEP 'SBASIC',
> >
> > this work well!
> >
> >
> >> or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!
> >>
> > this not
> >
> > Giorgio
> >
> >> Per
> >> On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:
> >>> I'm trying to run the SBASIC command inside a compiled program (with
> >>> Qliberator) but nothing happens .
> >>> Ideas?
> >>>
> >>> 100 PRINT "STEP 1"
> >>> 110 SBASIC
> >>> 120 PRINT "STEP 2" Regards Giorgio
> >>> ___
> >>> QL-Users Mailing List
> >>> .
> >>
> >> ___
> >> QL-Users Mailing List
> >>
> > ___
> > QL-Users Mailing List
> > .
>
>
>
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

[pjwitte via Ql-Users]

I was just pointing out, to anyone interested, that there is a lot 
more one can do with this ;o) Obviously a myprog_bas program has to 
exist and be valid, and the exclamation mark was informative and not 
meant to be part of the command.

But EXEP 'SBASIC' should do what I presume you were trying to do.
Per
On 22/03/2020 21:35, Giorgio Garabello via Ql-Users wrote:

Il giorno dom 22 mar 2020 alle ore 18:22 pjwitte via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:


Try EXEP 'SBASIC',


this work well!



or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!


this not

Giorgio


Per
On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:

I'm trying to run the SBASIC command inside a compiled program (with
Qliberator) but nothing happens .
Ideas?

100 PRINT "STEP 1"
110 SBASIC
120 PRINT "STEP 2" Regards Giorgio
___
QL-Users Mailing List
.


___
QL-Users Mailing List


___
QL-Users Mailing List
.




___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

[Giorgio Garabello via Ql-Users]

that's not true, it works
Didn't I just understand the use of the exclamation mark?

Il giorno dom 22 mar 2020 alle ore 21:35 Giorgio Garabello <
g.garabe...@gmail.com> ha scritto:

>
>
> Il giorno dom 22 mar 2020 alle ore 18:22 pjwitte via Ql-Users <
> ql-users@lists.q-v-d.com> ha scritto:
>
>> Try EXEP 'SBASIC',
>
>
> this work well!
>
>
>> or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!
>>
>
> this not
>
> Giorgio
>
>>
>> Per
>> On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:
>> > I'm trying to run the SBASIC command inside a compiled program (with
>> > Qliberator) but nothing happens .
>> > Ideas?
>> >
>> > 100 PRINT "STEP 1"
>> > 110 SBASIC
>> > 120 PRINT "STEP 2" Regards Giorgio
>> > ___
>> > QL-Users Mailing List
>> > .
>>
>>
>> ___
>> QL-Users Mailing List
>>
>
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

[Giorgio Garabello via Ql-Users]

Il giorno dom 22 mar 2020 alle ore 18:22 pjwitte via Ql-Users <
ql-users@lists.q-v-d.com> ha scritto:

> Try EXEP 'SBASIC',


this work well!


> or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!
>

this not

Giorgio

>
> Per
> On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:
> > I'm trying to run the SBASIC command inside a compiled program (with
> > Qliberator) but nothing happens .
> > Ideas?
> >
> > 100 PRINT "STEP 1"
> > 110 SBASIC
> > 120 PRINT "STEP 2" Regards Giorgio
> > ___
> > QL-Users Mailing List
> > .
>
>
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC

[pjwitte via Ql-Users]

Try EXEP 'SBASIC', or even EXEP 'SBASIC'; 'lrun"myprog_bas"'!

Per
On 22/03/2020 17:52, Giorgio Garabello via Ql-Users wrote:

I'm trying to run the SBASIC command inside a compiled program (with
Qliberator) but nothing happens .
Ideas?

100 PRINT "STEP 1"
110 SBASIC
120 PRINT "STEP 2" Regards Giorgio
___
QL-Users Mailing List
.



___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[pjwitte via Ql-Users]

On 28/06/2018 09:03, Wolfgang Lenerz via Ql-Users wrote:

Hi,

I made a small Sbasic testcase (SMSQE, not QDOS).

I made a program with procedures all called "abcdefghijklmnopqrt"+ a 5
digit number at the end.

The program starts at line 100, is increased by one and very 12th line a
new 10 line procedure is created. The first statement therein is
"return", so that I don't meausre the body of the procedure. The rest of
the lines on the procdure are filled with "Print".

(so
100 def proc abcdefghijklmnopqrt00100
101 return
102 print
...
110 print
111 end def
112 def proc abcdefghijklmnopqrt00112

etc, until just after line 3.

The last procedure then is always

31000 def proc abcdefghijklmnopqrt31000

I then measured how long it takes to call the first procedure and the
last procedure.

Measured with the millisecond timer of SMSQmulator:

calling the fist procedure 1 million times takes 5742 milliseconds
calling the last procedure 1 million times takes 5768 milliseconds

Strange. I wonder whats eating the 26 nanoseconds..
Per
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Dave Park via Ql-Users]

I think it depends on which types of variables you're coercing...

In this case, because integers are stored as floats and are a wicked lie,
ints and floats are already the same thing logically speaking. So the only
invalid coercion is string to float where the string contents are of the
wrong type.

I wonder the history behind the shortcut?

On Thu, Jun 28, 2018 at 1:01 AM, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> I can't help but wonder whether the time taken to parse all your
> parameters to check whether they are the right type won't be longer than
> having several procedures.
>
> Wolfgang
>
>
>
> > I'll make sure to respond right away in future, before I've fully
> > understood the subtleties and implications of your replies. :D
> >
> > I was digesting the reply. I've been neck deep in developing a USB
> keyboard
> > solution for the QL - a project that has become a multi-headed beast that
> > required getting into elements of the 8302/8049 relationship I just never
> > knew I'd have to think about. Also neck deep in fence building after a
> > neigborhood dog broke into the pen and killed many of my chickens.
> >
> > It does seem that coercion gives similar results - if everything is
> passed
> > as a string, it can be coerced however we'd like, as long as the data is
> > checked for validity.
> >
> > It does seem the functionality of overloading can be implemented in
> > roundabout yet still brief and readable ways.
> >
> > Thank you.
> >
> >
> >
> > On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users <
> > ql-users@lists.q-v-d.com> wrote:
> >
> >> So sorry for wasting my time trying to answer your question. It wont
> happen
> >> again.
> >>
> >> On 21 June 2018 at 16:38, Per Witte  wrote:
> >>
> >>> Im not familiar with C++ overloading, but S*BASIC allows some
> "parametric
> >>> polymorphism", viz:
> >>>
> >>> dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
> >>> Test 'abc', 2.99, x%
> >>> :
> >>> def proc Test(a, b%, c)
> >>> print a\ b% \ c, \
> >>> enddef Test
> >>> :
> >>> Result:
> >>> abc
> >>> 2.99
> >>> 9  8  7
> >>>
> >>> The SBASIC compiler performs a number of additional passes to
> >> SuperBASIC's
> >>> parser, to end up with a much purer "executable". The compiled program
> is
> >>> not machine code, of course, it consists of fixed length tokens that
> >> still
> >>> need to be "interpreted". But all useless baggage has been eliminated
> >> from
> >>> the program flow, expressions teased into simple RPN steps, and
> locations
> >>> resolved to absolute addresses. So no, the size of the program or
> >> distance
> >>> to procedures does not effect the speed of execution.
> >>>
> >>>
> >>> On 20 June 2018 at 22:35, Dave Park via Ql-Users <
> >> ql-users@lists.q-v-d.com
>  wrote:
> >>>
>  Hi all,
> 
>  How hard would it be to extend sBASIC functions to support C++ style
>  overloading?
> 
>  Separately, does the sBASIC in SMSQ or Minerva still scan for
>  procedures/functions from the beginning of the program, so earlier
>  FN/PROCs
>  have a speed advantage over later ones like in JM/JS?
> 
> 
>  --
>  Dave Park
>  d...@sinclairql.com
>  ___
>  QL-Users Mailing List
> 
> 
> >>>
> >> ___
> >> QL-Users Mailing List
> >>
> >
> >
> >
> ___
> QL-Users Mailing List
>



-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Wolfgang Lenerz via Ql-Users]

Hi,

I made a small Sbasic testcase (SMSQE, not QDOS).

I made a program with procedures all called "abcdefghijklmnopqrt"+ a 5
digit number at the end.

The program starts at line 100, is increased by one and very 12th line a
new 10 line procedure is created. The first statement therein is
"return", so that I don't meausre the body of the procedure. The rest of
the lines on the procdure are filled with "Print".

(so
100 def proc abcdefghijklmnopqrt00100
101 return
102 print
...
110 print
111 end def
112 def proc abcdefghijklmnopqrt00112

etc, until just after line 3.

The last procedure then is always

31000 def proc abcdefghijklmnopqrt31000

I then measured how long it takes to call the first procedure and the
last procedure.

Measured with the millisecond timer of SMSQmulator:

calling the fist procedure 1 million times takes 5742 milliseconds
calling the last procedure 1 million times takes 5768 milliseconds

Wolfgang








> 
> I can't help but wonder whether the time taken to parse all your
> parameters to check whether they are the right type won't be longer than
> having several procedures.
> 
> Wolfgang
> 
> 
> 
>> I'll make sure to respond right away in future, before I've fully
>> understood the subtleties and implications of your replies. :D
>>
>> I was digesting the reply. I've been neck deep in developing a USB keyboard
>> solution for the QL - a project that has become a multi-headed beast that
>> required getting into elements of the 8302/8049 relationship I just never
>> knew I'd have to think about. Also neck deep in fence building after a
>> neigborhood dog broke into the pen and killed many of my chickens.
>>
>> It does seem that coercion gives similar results - if everything is passed
>> as a string, it can be coerced however we'd like, as long as the data is
>> checked for validity.
>>
>> It does seem the functionality of overloading can be implemented in
>> roundabout yet still brief and readable ways.
>>
>> Thank you.
>>
>>
>>
>> On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users <
>> ql-users@lists.q-v-d.com> wrote:
>>
>>> So sorry for wasting my time trying to answer your question. It wont happen
>>> again.
>>>
>>> On 21 June 2018 at 16:38, Per Witte  wrote:
>>>
 Im not familiar with C++ overloading, but S*BASIC allows some "parametric
 polymorphism", viz:

 dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
 Test 'abc', 2.99, x%
 :
 def proc Test(a, b%, c)
 print a\ b% \ c, \
 enddef Test
 :
 Result:
 abc
 2.99
 9  8  7

 The SBASIC compiler performs a number of additional passes to
>>> SuperBASIC's
 parser, to end up with a much purer "executable". The compiled program is
 not machine code, of course, it consists of fixed length tokens that
>>> still
 need to be "interpreted". But all useless baggage has been eliminated
>>> from
 the program flow, expressions teased into simple RPN steps, and locations
 resolved to absolute addresses. So no, the size of the program or
>>> distance
 to procedures does not effect the speed of execution.


 On 20 June 2018 at 22:35, Dave Park via Ql-Users <
>>> ql-users@lists.q-v-d.com
> wrote:

> Hi all,
>
> How hard would it be to extend sBASIC functions to support C++ style
> overloading?
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier
> FN/PROCs
> have a speed advantage over later ones like in JM/JS?
>
>
> --
> Dave Park
> d...@sinclairql.com
> ___
> QL-Users Mailing List
>
>

>>> ___
>>> QL-Users Mailing List
>>>
>>
>>
>>
> ___
> QL-Users Mailing List
> 
> 
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Wolfgang Lenerz via Ql-Users]

Hi,

I can't help but wonder whether the time taken to parse all your
parameters to check whether they are the right type won't be longer than
having several procedures.

Wolfgang



> I'll make sure to respond right away in future, before I've fully
> understood the subtleties and implications of your replies. :D
> 
> I was digesting the reply. I've been neck deep in developing a USB keyboard
> solution for the QL - a project that has become a multi-headed beast that
> required getting into elements of the 8302/8049 relationship I just never
> knew I'd have to think about. Also neck deep in fence building after a
> neigborhood dog broke into the pen and killed many of my chickens.
> 
> It does seem that coercion gives similar results - if everything is passed
> as a string, it can be coerced however we'd like, as long as the data is
> checked for validity.
> 
> It does seem the functionality of overloading can be implemented in
> roundabout yet still brief and readable ways.
> 
> Thank you.
> 
> 
> 
> On Tue, Jun 26, 2018 at 1:57 PM, Per Witte via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> So sorry for wasting my time trying to answer your question. It wont happen
>> again.
>>
>> On 21 June 2018 at 16:38, Per Witte  wrote:
>>
>>> Im not familiar with C++ overloading, but S*BASIC allows some "parametric
>>> polymorphism", viz:
>>>
>>> dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
>>> Test 'abc', 2.99, x%
>>> :
>>> def proc Test(a, b%, c)
>>> print a\ b% \ c, \
>>> enddef Test
>>> :
>>> Result:
>>> abc
>>> 2.99
>>> 9  8  7
>>>
>>> The SBASIC compiler performs a number of additional passes to
>> SuperBASIC's
>>> parser, to end up with a much purer "executable". The compiled program is
>>> not machine code, of course, it consists of fixed length tokens that
>> still
>>> need to be "interpreted". But all useless baggage has been eliminated
>> from
>>> the program flow, expressions teased into simple RPN steps, and locations
>>> resolved to absolute addresses. So no, the size of the program or
>> distance
>>> to procedures does not effect the speed of execution.
>>>
>>>
>>> On 20 June 2018 at 22:35, Dave Park via Ql-Users <
>> ql-users@lists.q-v-d.com
 wrote:
>>>
 Hi all,

 How hard would it be to extend sBASIC functions to support C++ style
 overloading?

 Separately, does the sBASIC in SMSQ or Minerva still scan for
 procedures/functions from the beginning of the program, so earlier
 FN/PROCs
 have a speed advantage over later ones like in JM/JS?


 --
 Dave Park
 d...@sinclairql.com
 ___
 QL-Users Mailing List


>>>
>> ___
>> QL-Users Mailing List
>>
> 
> 
> 
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Per Witte via Ql-Users]

Im not familiar with C++ overloading, but S*BASIC allows some "parametric
polymorphism", viz:

dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
Test 'abc', 2.99, x%
:
def proc Test(a, b%, c)
print a\ b% \ c, \
enddef Test
:
Result:
abc
2.99
9  8  7

The SBASIC compiler performs a number of additional passes to SuperBASIC's
parser, to end up with a much purer "executable". The compiled program is
not machine code, of course, it consists of fixed length tokens that still
need to be "interpreted". But all useless baggage has been eliminated from
the program flow, expressions teased into simple RPN steps, and locations
resolved to absolute addresses. So no, the size of the program or distance
to procedures does not effect the speed of execution.


On 20 June 2018 at 22:35, Dave Park via Ql-Users 
wrote:

> Hi all,
>
> How hard would it be to extend sBASIC functions to support C++ style
> overloading?
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier FN/PROCs
> have a speed advantage over later ones like in JM/JS?
>
>
> --
> Dave Park
> d...@sinclairql.com
> ___
> QL-Users Mailing List
>
>
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Jan Bredenbeek via Ql-Users]

On 21 June 2018 at 15:21, Dave Park via Ql-Users 
wrote:

> > SuperBASIC is quite unique in that it stores the *difference* in length
> of
> > a line compared to the previous line, along with its line number. This
> way,
> > because the current line length is also stored in a system variable, it
> can
> > search for lines in both backward and forward direction. So a proc/fn
> call
> > will be faster when the definition is closer to the calling line. This is
> > also mentioned in the Minerva documentation.
>
> ​Hmmm. Are they stored in a known order, eg: alphabetical or order of
> creation/declaration
>

They are stored in order of line number (it's Basic, after all...).


> > You cannot define a proc/fn multiple times but you can check the type and
> > usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
> > functions in TK2 and act accordingly. An example of this is in my 'ls'
> > procedure which uses an extra parameter as a flag for recursive directory
> > searches. When this parameter is empty it only lists the current
> directory.
>
> ​I suppose it does reduce these stresses that while sBASIC has "strict"
> typing of variables, it allows easy transfer between variable types.​ It
> also has the concepts of undefined variables and defined but unset
> variables.
>

It's not as strict as it seems. What's also unique in S*BASIC is
'coercion'. You want to assign a numeric value to a string variable and
S*BASIC will happily do this, by converting the number to a string (in
other BASICs you would have to use STR$). And the other way round assign a
string value to a numeric variable (provided the string contains a valid
number).
The type of a parameter in a procedure or function is determined when the
function is *called*, not when it's defined. In a machinecode function you
can find out what type a parameter is and choose to evaluate it as a
number, string or name (in a BASIC function you can use the four TK2
functions mentioned above though you're probably a bit more restricted by
parameter types).
Also, variables are never undefined (they're defined as soon as you enter
their name in a program line) but they can be unset...


> Quite amazing for a language that fit in a very small part of 48K.


 And all written in 68K assembler in a few weeks time...

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Dave Park via Ql-Users]

On Thu, Jun 21, 2018 at 3:13 AM, Jan Bredenbeek via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> SuperBASIC is quite unique in that it stores the *difference* in length of
> a line compared to the previous line, along with its line number. This way,
> because the current line length is also stored in a system variable, it can
> search for lines in both backward and forward direction. So a proc/fn call
> will be faster when the definition is closer to the calling line. This is
> also mentioned in the Minerva documentation.


​Hmmm. Are they stored in a known order, eg: alphabetical or order of
creation/declaration


> You cannot define a proc/fn multiple times but you can check the type and
> usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
> functions in TK2 and act accordingly. An example of this is in my 'ls'
> procedure which uses an extra parameter as a flag for recursive directory
> searches. When this parameter is empty it only lists the current directory.


​I suppose it does reduce these stresses that while sBASIC has "strict"
typing of variables, it allows easy transfer between variable types.​ It
also has the concepts of undefined variables and defined but unset
variables.

Quite amazing for a language that fit in a very small part of 48K.


-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Jan Bredenbeek via Ql-Users]

On 21 June 2018 at 00:43, Dave Park via Ql-Users 
wrote:

> My reason for asking was, I was wondering if an analysis of how frequently
> functions were called, and from where, could affect how quickly they would
> be stepped to. I have seen this behavior in SuperBASIC on JM/JS and
> achieved often useful gains in improvements by placing the most frequently
> called functions at the beginning or the program.
>

SuperBASIC is quite unique in that it stores the *difference* in length of
a line compared to the previous line, along with its line number. This way,
because the current line length is also stored in a system variable, it can
search for lines in both backward and forward direction. So a proc/fn call
will be faster when the definition is closer to the calling line. This is
also mentioned in the Minerva documentation.


> I was wondering if this was still true with the BASIC on SMSQ/Minerva.
>

AFAIK, Minerva is not very different in the way data structures are stored
compared to Sinclair ROMs, but SMSQ is.


> That let to the overloading question, which would allow the collapsing of
> many functions into a single function using polymorphism.
>

You cannot define a proc/fn multiple times but you can check the type and
usage of a parameter using the PARTYP, PARUSE, PARNAM$ and PARSTR$
functions in TK2 and act accordingly. An example of this is in my 'ls'
procedure which uses an extra parameter as a flag for recursive directory
searches. When this parameter is empty it only lists the current directory.

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Dave Park via Ql-Users]

My reason for asking was, I was wondering if an analysis of how frequently
functions were called, and from where, could affect how quickly they would
be stepped to. I have seen this behavior in SuperBASIC on JM/JS and
achieved often useful gains in improvements by placing the most frequently
called functions at the beginning or the program.

I was wondering if this was still true with the BASIC on SMSQ/Minerva.

That let to the overloading question, which would allow the collapsing of
many functions into a single function using polymorphism.

On Wed, Jun 20, 2018 at 5:10 PM, Jan Bredenbeek via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On 20 June 2018 at 22:35, Dave Park via Ql-Users  >
> wrote:
>
> > Hi all,
> >
> > Separately, does the sBASIC in SMSQ or Minerva still scan for
> > procedures/functions from the beginning of the program, so earlier
> FN/PROCs
> > have a speed advantage over later ones like in JM/JS?
>
>
> SuperBASIC (JM/JS/Minerva) stores line numbers along with proc/fn names in
> the name table and can search backward and forward for them in the program.
> So it merely depends on how far away the proc/fn definition is from the
> calling code in terms of lines.
> I don't know how SBASIC handles this but as it is said to be more a
> compiler than an interpreter it could be very well different (the most
> efficient way would of course be to store addresses rather than line
> numbers but this could break if the program is changed and then
> CONTINUEd/RETRYd).
>
> Jan.
>
> --
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
> ___
> QL-Users Mailing List
>



-- 
Dave Park
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Jan Bredenbeek via Ql-Users]

On 20 June 2018 at 22:35, Dave Park via Ql-Users 
wrote:

> Hi all,
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier FN/PROCs
> have a speed advantage over later ones like in JM/JS?


SuperBASIC (JM/JS/Minerva) stores line numbers along with proc/fn names in
the name table and can search backward and forward for them in the program.
So it merely depends on how far away the proc/fn definition is from the
calling code in terms of lines.
I don't know how SBASIC handles this but as it is said to be more a
compiler than an interpreter it could be very well different (the most
efficient way would of course be to store addresses rather than line
numbers but this could break if the program is changed and then
CONTINUEd/RETRYd).

Jan.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC 'ls' procedure

[Jan Bredenbeek]

>> To save you reinventing the wheel Jan, Norman Dunbar's DJToolkit has an
> extension called LEVEL2 which tests for a Level 2 filing system. The
> assembler source djtoolkit_asm is included with the toolkit - just search
> for 'level2' in that source.
>
> http://www.dilwyn.me.uk/tk/djtk.zip
>
Hmm, I should have explained a bit more rather than leaving you to do it.

Just call trap #3 D0=$4F IOF.XINF after reserving a 64 byte block (call
with d1=0, d2.b=0, d3.w=timeout, a0=channel ID, a1=pointer to the 64 byte
buffer.). If no info block is returned (check d0 on return), there is no
level 2.


I'm aware of that, but just want to avoid having to load SB extensions. Oh
well, I'm already CALLing SD.CHENQ code from SB so it shouldn't be much
hassle to implement.
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC 'ls' procedure

[Dilwyn Jones]

- NOTE: On non-V2 drivers which don't support subdirectories, ls will 
fail

because the FNAME$ function stops with 'bad parameter' on directory
channels. This can be avoided by adjusting line 1710 in the code (as
indicated in the REMarks). I'll probably have to design another machine
code call to find out whether a device is V2 or not :(
To save you reinventing the wheel Jan, Norman Dunbar's DJToolkit has an 
extension called LEVEL2 which tests for a Level 2 filing system. The 
assembler source djtoolkit_asm is included with the toolkit - just search 
for 'level2' in that source.


http://www.dilwyn.me.uk/tk/djtk.zip

Hmm, I should have explained a bit more rather than leaving you to do it.

Just call trap #3 D0=$4F IOF.XINF after reserving a 64 byte block (call with 
d1=0, d2.b=0, d3.w=timeout, a0=channel ID, a1=pointer to the 64 byte 
buffer.). If no info block is returned (check d0 on return), there is no 
level 2.


Dilwyn


___
QL-Users Mailing List

Re: [Ql-Users] SBASIC 'ls' procedure

[RWAP Software]

On 2017-02-12 16:43, Jan Bredenbeek wrote:
On 12 February 2017 at 15:29, RWAP Software  
wrote:



Hi Jan,

That is great - it is a nice function which can be useful.

Could I ask you to consider moving (or Forking?) the repository to the 
new

SInclair QL Github, as this is intended to keep all of the QL stuff
together -



Done that - the directory structure is a bit strange now but I'll 
correct

that asap.


Thanks Jan - I have also found a few more Github repositories and forked 
them across :)


Rich Mellor RWAP Software www.rwapsoftware.co.uk www.sellmyretro.com


___
QL-Users Mailing List

Re: [Ql-Users] SBASIC 'ls' procedure

[Jan Bredenbeek]

On 12 February 2017 at 15:29, RWAP Software  wrote:

> Hi Jan,
>
> That is great - it is a nice function which can be useful.
>
> Could I ask you to consider moving (or Forking?) the repository to the new
> SInclair QL Github, as this is intended to keep all of the QL stuff
> together -
>

Done that - the directory structure is a bit strange now but I'll correct
that asap.

-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] SBASIC 'ls' procedure

[RWAP Software]

Hi Jan,

That is great - it is a nice function which can be useful.

Could I ask you to consider moving (or Forking?) the repository to the 
new SInclair QL Github, as this is intended to keep all of the QL stuff 
together -


https://github.com/SinclairQL

Rich

On 2017-02-12 14:24, Jan Bredenbeek wrote:

I've updated the code with various improvements and fixes:

- Listing now adjusts to window size and can be aborted by pressing 'Q' 
or

ESC, even when recursing directories;
- Redirection by DEV device is now handled correctly (so long as you 
don't

rename the DEV device itself ;))
- SMSQ is no longer required; it will now also work on native QL with 
TK2

and Minerva fitted.
- NOTE: On non-V2 drivers which don't support subdirectories, ls will 
fail

because the FNAME$ function stops with 'bad parameter' on directory
channels. This can be avoided by adjusting line 1710 in the code (as
indicated in the REMarks). I'll probably have to design another machine
code call to find out whether a device is V2 or not :(

https://github.com/janbredenbeek/QL/blob/master/SBASIC/ls_bas

Jan.

On 3 February 2017 at 11:31, Jan Bredenbeek  wrote:


Hi Wolfgang,

On 3 February 2017 at 05:01, Wolf  wrote:

Are you aware of the SUB device by Phil Borman? It does the same 
thing,

and there is no copright problem since it's on Dilwyn's page (
http://www.dilwyn.me.uk/tk/index.html)



Thanks, I can vaguely remember it (it might as well be in my BBS 
archive).
Pity it has no source code but indeed a nice thing to learn using 
DISA. As

for the copyright issue, I only do it out of curiosity but it might be
useful inspiration to improve the DEV device ;).

regards,

--
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net


Rich Mellor RWAP Software www.rwapsoftware.co.uk www.sellmyretro.com


___
QL-Users Mailing List

Re: [Ql-Users] SBASIC 'ls' procedure

[Jan Bredenbeek]

I've updated the code with various improvements and fixes:

- Listing now adjusts to window size and can be aborted by pressing 'Q' or
ESC, even when recursing directories;
- Redirection by DEV device is now handled correctly (so long as you don't
rename the DEV device itself ;))
- SMSQ is no longer required; it will now also work on native QL with TK2
and Minerva fitted.
- NOTE: On non-V2 drivers which don't support subdirectories, ls will fail
because the FNAME$ function stops with 'bad parameter' on directory
channels. This can be avoided by adjusting line 1710 in the code (as
indicated in the REMarks). I'll probably have to design another machine
code call to find out whether a device is V2 or not :(

https://github.com/janbredenbeek/QL/blob/master/SBASIC/ls_bas

Jan.

On 3 February 2017 at 11:31, Jan Bredenbeek  wrote:

> Hi Wolfgang,
>
> On 3 February 2017 at 05:01, Wolf  wrote:
>
> Are you aware of the SUB device by Phil Borman? It does the same thing,
>> and there is no copright problem since it's on Dilwyn's page (
>> http://www.dilwyn.me.uk/tk/index.html)
>>
>
> Thanks, I can vaguely remember it (it might as well be in my BBS archive).
> Pity it has no source code but indeed a nice thing to learn using DISA. As
> for the copyright issue, I only do it out of curiosity but it might be
> useful inspiration to improve the DEV device ;).
>
> regards,
>
> --
> *Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
>



-- 
*Jan Bredenbeek* | Hilversum, NL | j...@bredenbeek.net
___
QL-Users Mailing List

Re: [Ql-Users] SBasic Thing documentation

[gdgqler]

On 26 Mar 2009, at 08:59, Christopher Cave wrote:


Does anyone know what the SBasic thing expects on the stack when it is
used? Or can anyone please tell me where the appropriate documentation
can be found (I have the SMSQ source but no idea where in it to look)?
Looking at Jonathan Hudson's code, I can see that it can be passed a
command string (cmd$) and up to 4 channel ids. Of the channels, one
relates to a program to load (but is this necessary and how can the  
thing

tell when no program is meant to be passed?).



The manual says:

On being invoked, SBASIC expects to find some channel IDs on the  
stack (standard QDOS conventions).


SBASIC will normally treat the first ID as the SBASIC program source  
file, the next ID as channel #0, the next ID as #1 and so on. The  
string defines the initial value of the CMD$ variable within the  
SBASIC program.


I have not been able to start a program in this way using EXEP. So I  
wrote the keyword EXEG which does work. This is available by using the  
address:


http://web.ukonline.co.uk/george.gwilt/

and going via downloads to the sqlug site.

This contains an example.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] SBASIC extras

[George Gwilt]

On 11 Aug 2007, at 13:57, Dilwyn Jones wrote:


 PAR_WAIT  (presumably something to do with parallel port)


This is part of SMSQ/E but its definition is not in my QPC2 manual.  
The code seems to set a pause for a period of time. Perhaps the  
author knows what  for?

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] SBASIC extras

[Marcel Kilgus]

George Gwilt wrote:
 PAR_WAIT  (presumably something to do with parallel port)

 This is part of SMSQ/E but its definition is not in my QPC2 manual.  
 The code seems to set a pause for a period of time. Perhaps the  
 author knows what  for?

That would be Tony.

According to the QDOS Classic docs:

-=-=-=
PAR_WAIT (port, wait cycles) sets the length of time that the parallel
port drive will wait for the printer to be ready before it gives up
and lets the Q40 do something else. This has no effect in FIFO mode,
but in original PC mode it allows the buffer in the printer to be
stuffed in bursts. The default value is 0. The larger the value, the
higher the probability that a more than one byte of data can be sent
on each interrupt, but the higher the load on the machine.

If the IO card does not provide IRQ7 and the machine is busy,
PAR_PULSE with have a much greater effect than if IRQ7 is used and/or
the machine is idle.

PAR_WAIT 2,20give the printer on PAR2 a high priority.
PAR_WAIT 0   . . . set PAR 1 use the minimum of processor time.

For an Epson Stylus COLOR Pro printer, PAR_PAUSE 10 and PAR_PAUSE 50
improved the transfer speed by 30% on an idle machine: the rate was
primarily determined by the printer. On a busy machine with no
interrupts, PAR_PAUSE 10 improved the transfer speed by a factor of 3
and PAR_PAUSE 50 improved the transfer speed by a factor of 5. The
speed of other tasks in the machine was reduced. Q40 Hard Disks
-=-=-=

As far as I can see it does not have any effect in the latest SMSQ/E
versions at all.

Marcel

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] SBASIC extras

[Dilwyn Jones]

  Looking at a list of SBASIC extensions created with an EXTRAS
  command,
  there are 3 extensions I noticed that I don't know what they do. 
  Not
  in my (admittedly old) manual. Anyone know?
 
  CHK_HEAP  (Some form of heap check suggested by the name)
 
  HOME_CSET (presumably something to do with Home Thing)
 
  PAR_WAIT  (presumably something to do with parallel port)

 HOME_CSET [job_ID], directory$

 Part of SMSQ/E, documented in extras_new_home_info_txt in the 
 SMSQ/E
 source files:

 Set the current directory for the job. The directory must the a 
 valid
 directory.


 CHK_HEAP

 Part of SMSQ/E, documented in QPC_Keywords and possibly elsewhere:

 This enables debugging routines in the SBASIC core for SBASIC
 development and should not be used by any users.
Thank you.
-- 
Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] SBASIC extras

[P Witte]

Dilwyn Jones writes:

  Looking at a list of SBASIC extensions created with an EXTRAS
  command,
  there are 3 extensions I noticed that I don't know what they do. Not
  in my (admittedly old) manual. Anyone know?
 
  CHK_HEAP  (Some form of heap check suggested by the name)
 
  HOME_CSET (presumably something to do with Home Thing)
 
  PAR_WAIT  (presumably something to do with parallel port)

HOME_CSET [job_ID], directory$

Part of SMSQ/E, documented in extras_new_home_info_txt in the SMSQ/E 
source files:

Set the current directory for the job. The directory must the a valid 
directory.


CHK_HEAP

Part of SMSQ/E, documented in QPC_Keywords and possibly elsewhere:

This enables debugging routines in the SBASIC core for SBASIC 
development and should not be used by any users.


Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm