Re: [Ql-Users] SBASIC interpreter bug?
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?
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?
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?
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?
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?
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?
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
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
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
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
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
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...
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...
On Thu, Jun 28, 2018 at 2:03 AM, Wolfgang Lenerz via Ql-Users < ql-users@lists.q-v-d.com> wrote: > Hi, > > I made a small Sbasic testcase (SMSQE, not QDOS). > > That seems a quite definitive test case. Asked and answered! Thank you. -- Dave Park d...@sinclairql.com ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
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...
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...
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...
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 > -- Dave Park d...@sinclairql.com ___ QL-Users Mailing List
Re: [Ql-Users] sBASIC overloading...
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 > 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...
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...
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...
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...
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...
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...
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
>> 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
- 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
- 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 Dilwyn Jones ___ QL-Users Mailing List
Re: [Ql-Users] SBASIC 'ls' procedure
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
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
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
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 'ls' procedure
On Sunday 29 Jan 2017, Jan Bredenbeek wrote: > Okay, here it is. Merge this into your BOOT file and you'll have a > Unix-like 'ls' command, and even a 'lsr' command to list directories > recursively. It lists one file per line, with type, size and date info, and > without the subdirectory names in front of each filename (unlike DIR and > WSTAT). Hi Jan, Wow! This is some powerful program. Also so short as well. This is so welcome. Thanks very much for this. Michael ___ QL-Users Mailing List
Re: [Ql-Users] SBasic Thing documentation
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
From: "Marcel Kilgus" > As far as I can see it does not have any effect in the latest SMSQ/E > versions at all. I have never used to change this. PAR has ever worked perfectly ;-) Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] SBASIC extras
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
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
> > 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
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