[Ql-Users] Approaches to parsing in SuperBASIC
I'm working on the command parser for my Air Traffic Control sim. I have not written a parser in this sense before. The parser takes input from the user, and parses it into meaningful instructions to pass to an aircraft. It emulates a unified ear for the pilots of all the aircraft. It deals with a limited range of input. Grammar will be strictly enforced. Arguments will be separated by spaces. As an outline to the simple parsing I need to do, there is a standard for ATC sims which I will be following: ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first As there are a maximum ten slots (thus ten aircraft) I will allow the shortcut that keys 1 thru 0 will auto enter the flight number for that slot, with a space appended. The sim continues during data entry so this is faster, but I will also allow manual typing of flight numbers. Are there any established principles of parsing that I should adhere to? I am debating where to make this a procedure or a function. I'd like to keep it sleek. I'd also like, as parsed, that it creates the string for the pilot's response as it goes and if at some point the parsing fails, I can reset the string to Huh? or something more helpful from the pilot... Discussion/ideas/snippets welcomed. Dave *For the purposes of this thread, my program is open-source (duh!) and I will happily share my code here. I will not, however, use anyone else's code without their explicit permission and agreement to have their code included within the sim as open-source. The assumption is I won't use your code. If it's key to the project, I may use the principle, but I would not use the code without the explicit permission above.* ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Game idea...
Hi all, I had a game idea back in the 80s. I feel like it might be a good followup project after the flight sim, but the idea is fun so I thought I would share it here and see what others might make of it. The game occurs in a two-dimensional gravity well. The yellow sun occupies a fixed point in the middle. The green planet orbits with an eccentricity that increases at higher levels. There will be other red bodies in random orbits too. The objective of the game is to accelerate or decelerate your ship to match orbits with the goal planet. Other bodies will affect your path. You must simply match the target's speed and velocity with a degree of accuracy that increases at higher levels. There will be a time and/or fuel limit. This game employs the N-body problem of gravitational bodies. I programmed the N-body problem in SuperBASIC in the 80s and will be able to recreate it fairly easily. I think it would be quite cool and playable and would be 100% graphical. Does anyone have any ideas to add to this, or suggestions? If you contribute ideas/code with this thread, I will presume you're sharing your ideas with the whole community and that I or others may freely use your ideas. Code, however, would only be used by explicit permission. When the game is completed, I will release it to the community, for free, with source. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] 12th February 2011
-- From: QL-MyLink (f/fh) q...@mylink.adsl24.co.uk Sent: Saturday, February 05, 2011 9:47 PM To: ql-us...@q-v-d.com Subject: Re: [Ql-Users] 12th February 2011 What do I know about Derby? It's where they say Twosdee. Just outside Derby its Twosdee, ducks, Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] 12th February 2011
What do I know about Derby? It's where they say Twosdee. Just outside Derby its Twosdee, ducks, Just down the road in Nottingham they say Shintin Duck. John Taylor ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Dave, ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first How would you handle more than one command per plane? (I.e. Climb to xxx and turn left to yyy) Your examples are not clear to me: I guesst the ABC part is some sort of plane identification? A flight #? A typical approach in any language would be a function that breaks a line into syntactical pieces (tokens) and returning the next token (here: anything separated by white space) from the input line as a string. Outside that, you'd have a lexical analyzer that checks whether the token you just got matches anything you'd expect. Your second line example would be handled lke: InitParser(ABC C N X) x$ = getNextToken () - would return ABC, your analyzer checks whether this is a valid flight # the next x$=getNextToken() would return C, you accept this because it is valid here the next x$=getNextToken() would return the new altitude - Your analyzer checks for valid numerical value the next x$=getNextToken() would return the X and the next one an empty string to signal to the analyzer that you're done with this line. obviously, the getNextToken function would need some non-local variables to keep track of where in the input line it currently is Those would need to be initialized along with the input line in initParesr for each new command line. The analyzer would be programmed as finite state machine that holds a non-local variable on where I am currently - i.e a state value that tells tehe analyzer what to expect next. Hope this helps Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) This is wonderful exercise. Thanks! Dave On Sun, Feb 6, 2011 at 4:53 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Dave, ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first How would you handle more than one command per plane? (I.e. Climb to xxx and turn left to yyy) Your examples are not clear to me: I guesst the ABC part is some sort of plane identification? A flight #? A typical approach in any language would be a function that breaks a line into syntactical pieces (tokens) and returning the next token (here: anything separated by white space) from the input line as a string. Outside that, you'd have a lexical analyzer that checks whether the token you just got matches anything you'd expect. Your second line example would be handled lke: InitParser(ABC C N X) x$ = getNextToken () - would return ABC, your analyzer checks whether this is a valid flight # the next x$=getNextToken() would return C, you accept this because it is valid here the next x$=getNextToken() would return the new altitude - Your analyzer checks for valid numerical value the next x$=getNextToken() would return the X and the next one an empty string to signal to the analyzer that you're done with this line. obviously, the getNextToken function would need some non-local variables to keep track of where in the input line it currently is Those would need to be initialized along with the input line in initParesr for each new command line. The analyzer would be programmed as finite state machine that holds a non-local variable on where I am currently - i.e a state value that tells tehe analyzer what to expect next. Hope this helps Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Also... One of the major problems I'm having is the manual I downloaded. The QPCKeywords V1_02 document has many keywords missing/ignored that I remember, like RIGHT$, LEFT$ and INSTR... and I don't remember how to use them. I would dig in the garage to find the old printed manual, but it's FREEZING out there! One of the other things that might come out of this process for me is a heavily revised and annotated new manual, with better examples yet more concise instructions. Which I'd post for everyone's benefit. Dave On Sun, Feb 6, 2011 at 5:10 AM, Plastic plasticu...@gmail.com wrote: For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) This is wonderful exercise. Thanks! Dave On Sun, Feb 6, 2011 at 4:53 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Dave, ABC C NN - 2 digits is an altitude in thousands of feet ABC C NN X - the X modifier expedites the altitude change (where possible/reasonable) ABC C NNN - 3 digits is a heading in degrees ABC C NNN L (or R) - where a course change follows the shortest turn, L or R modifier makes the turn direction explicit ABC C $$$ - where a valid beacon is given, the aircraft will fly to that beacon ABC S NNN - change speed to... ABC L XXX - cleared to land on runway XXX (eg: 14L) ABC T - clearance to take off (an altitude must be set first How would you handle more than one command per plane? (I.e. Climb to xxx and turn left to yyy) Your examples are not clear to me: I guesst the ABC part is some sort of plane identification? A flight #? A typical approach in any language would be a function that breaks a line into syntactical pieces (tokens) and returning the next token (here: anything separated by white space) from the input line as a string. Outside that, you'd have a lexical analyzer that checks whether the token you just got matches anything you'd expect. Your second line example would be handled lke: InitParser(ABC C N X) x$ = getNextToken () - would return ABC, your analyzer checks whether this is a valid flight # the next x$=getNextToken() would return C, you accept this because it is valid here the next x$=getNextToken() would return the new altitude - Your analyzer checks for valid numerical value the next x$=getNextToken() would return the X and the next one an empty string to signal to the analyzer that you're done with this line. obviously, the getNextToken function would need some non-local variables to keep track of where in the input line it currently is Those would need to be initialized along with the input line in initParesr for each new command line. The analyzer would be programmed as finite state machine that holds a non-local variable on where I am currently - i.e a state value that tells tehe analyzer what to expect next. Hope this helps Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Am 06.02.2011 12:19, schrieb Plastic: Also... One of the major problems I'm having is the manual I downloaded. The QPCKeywords V1_02 document has many keywords missing/ignored that I remember, like RIGHT$, LEFT$ and INSTR... and I don't remember how to use them. I would dig in the garage to find the old printed manual, but it's FREEZING out there! One of the other things that might come out of this process for me is a heavily revised and annotated new manual, with better examples yet more concise instructions. Which I'd post for everyone's benefit. Dave, the manual is right here and your memory is wrong ;-). One of the major differences of S*Basic against MS Basic used to be the omission of the keywords you mentioned. All of this somewhat clumsy approach of RIGHT$, LEFT$ is done with the much more elegant string slicing in S*BASIC. Replace LEFT$(x$, n) with x$(TO n) RIGHT$(x$,n) with x$(LEN(x$)-n TO) which is much more elegant, I think. INSTR is actually there. Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Tobias, thank you! I have struggled with this for a couple of days. This'll teach me for having started out on a Commodore PET. I couldn't find INSTR in this manual because it's in the wrong place. After IO_PRIORITY. It never crossed my mind to look past the place it would logically be. This is how my memory works: it's not in there. Then you show me it, and it's there like it was never gone, (usually, not always). I never felt RIGHT$ was clumsy, because it was easy and as Phoebus will tell you, I do like to be spoon-fed ;) I do remember missing it so much when I got my QL. Thanks again. Dave On Sun, Feb 6, 2011 at 5:36 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Am 06.02.2011 12:19, schrieb Plastic: Also... One of the major problems I'm having is the manual I downloaded. The QPCKeywords V1_02 document has many keywords missing/ignored that I remember, like RIGHT$, LEFT$ and INSTR... and I don't remember how to use them. I would dig in the garage to find the old printed manual, but it's FREEZING out there! One of the other things that might come out of this process for me is a heavily revised and annotated new manual, with better examples yet more concise instructions. Which I'd post for everyone's benefit. Dave, the manual is right here and your memory is wrong ;-). One of the major differences of S*Basic against MS Basic used to be the omission of the keywords you mentioned. All of this somewhat clumsy approach of RIGHT$, LEFT$ is done with the much more elegant string slicing in S*BASIC. Replace LEFT$(x$, n) with x$(TO n) RIGHT$(x$,n) with x$(LEN(x$)-n TO) which is much more elegant, I think. INSTR is actually there. Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Am 06.02.2011 12:10, schrieb Plastic: For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) Dave, anything using INSTR is probably a bad idea before actually having separated the command line into tokens - It ignores the position of the command and generates a lot of false positives - If you had a C in the flight#, for example, you'd understand Climb. About the 'language': Is this really a real life example? The distinction between climbing and turning only done by the number of digits in the value? Sounds a bit too much ambiguity for a high-security approach to me. If the operator misses a single digit, he'd let the plane turn instead of climb, with possibly fatal (lethal) results. This also results in the fact that the decision tree for this language is rather _not_ straightforward. Before having seen the #of digits in the value, the language doesn't decide whether to climb or turn. (CS theory would say It's not a simple LR parser) Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
On Sun, Feb 6, 2011 at 5:47 AM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Am 06.02.2011 12:10, schrieb Plastic: For clarity: ABC is the format of the flight number. eg: AAL2123, CAL2260, FDX1001, etc... Sometimes, there are three digit flights like BAA418, etc... I like the way you have the parser call a function to isolate each component. I have until this point been thinking in terms of... (pseudo-code alert!) IF c INSTR(cmd$) then it's a clearance and is rightmost character x?Set expedited flag. if not, a$ = (right 3 characters of cmd$) (eg: 030 or 10) (*note to self - this won't work for single digit altitudes - doh!*) check it makes a number is it a 3-digit number? (including 020 or 000) - it's a heading otherwise, it's an altitude. The other way I thought of doing it was parsing a character at a time and using the spaces as EOFs for each field. I am aware the decision tree for this language is straightforward. However, to me, it's not trivial if only because I haven't coded at this level in many years and this is truly stretching my mental muscles - which is why I am doing this ;) Dave, anything using INSTR is probably a bad idea before actually having separated the command line into tokens - It ignores the position of the command and generates a lot of false positives - If you had a C in the flight#, for example, you'd understand Climb. Indeed. Seeing this problem and others is why I asked for help. I don't have an obvious solution and need to learn a better way. About the 'language': Is this really a real life example? The distinction between climbing and turning only done by the number of digits in the value? Sounds a bit too much ambiguity for a high-security approach to me. If the operator misses a single digit, he'd let the plane turn instead of climb, with possibly fatal (lethal) results. This also results in the fact that the decision tree for this language is rather _not_ straightforward. Before having seen the #of digits in the value, the language doesn't decide whether to climb or turn. (CS theory would say It's not a simple LR parser) Yes, that's how most of the keyboard data entered simulators do it. It is prone to typo catastrophes. That's part of the charm of it. If you don't have the concentration to type straight, it's like not speaking clearly. It is the ATC operator's job to follow the aircraft acknowledgements and ensure the pilots heard what you intended, and not what you said ;) Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] Ser-USB (USBWiz) Driver Update
For anyone who is following this project: Build 009 of the driver was completed and tested today. This fully implements the io.formt trap, meaning that you can now issue the command: FORMAT USB1_ Note: The Ser-USB format routine is much simpler than the QUBIDE original; it only prompts the user for a total size in Megabytes and the block size and then does the rest for you. If the combination of total size and block size would result in a partition with more than 65536 blocks, the user is advised and asked to select a larger block size and/or smaller partition size. Formatting is also a background process, meaning that in an S*BASIC session the FORMAT command completes almost immediately, leaving the drive is formatted in the background. As Ser-USB doesn't do low-level formatting the process is as quick as the time it takes to write a new Map and root directory. Adrian (ps Geoff W. - perhaps you could add a footnote to my QL Today article to reflect this latest news. Thanks.) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Tobias Fröschle wrote, on 6/Feb/11 11:36 | Feb6: Am 06.02.2011 12:19, schrieb Plastic: Also... One of the major problems I'm having is the manual I downloaded. The QPCKeywords V1_02 document has many keywords missing/ignored that I remember, like RIGHT$, LEFT$ and INSTR... and I don't remember how to use them. I would dig in the garage to find the old printed manual, but it's FREEZING out there! snip the manual is right here and your memory is wrong ;-). One of the major differences of S*Basic against MS Basic used to be the omission of the keywords you mentioned. All of this somewhat clumsy approach of RIGHT$, LEFT$ is done with the much more elegant string slicing in S*BASIC. Replace LEFT$(x$, n) with x$(TO n) RIGHT$(x$,n) with x$(LEN(x$)-n TO) which is much more elegant, I think. Absolutely. That was the one command that struck me as so totally logical and easy to understand of all the sB differences from IBM Basic in the 70s. INSTR is actually there. Tony -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 t...@firshman.co.uk http://firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 Skype: tonyfirshman TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Ser-USB (USBWiz) Driver Update
Adrian Ives wrote: For anyone who is following this project: Build 009 of the driver was completed and tested today. This fully implements the io.formt trap, meaning that you can now issue the command: FORMAT USB1_ Well done Adrian! And thank's for supporting this project. I wish, someone could make a similar thing in QPC2, just to write the map/root onto a 1440 disk, as QDOS formatting is not possible under WinXP (and possible higher). Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Tobias helpfully said - Dave, the manual is right here and your memory is wrong ;-). - Brave Dave, Do you have a copy of Jan Jones? It's great for *all* SBasic INSTR-uctions. John in Wales ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Dave, had a lazy Sunday afternoon and was thinking about your problem - And, being a bit challenged and had nothing else to do, wrote a parser/analyzer for your Language: Ended up with quite a bit of code, the problem is not as simple as it seems (Hope I didn't over-complicate things). But I wanted to have a generic parser that could easily be extended and also probably be used for other purposes. It seems to understand most of the commands you mentioned and could be a starting point for you. Note it's currently only accepting uppercase commands. If you don't use Turbo and its toolkit, just remove the MANIFEST statemens at the beginning of lines 110 to 130, they declare the variables in the lines constant - I just like to use symbolic names for the states and commands instead of values, it's just easier to read. Now go ahead and tear it apart. Cheers, Tobias 100 DIM command$(100) 110 MANIFEST : S_REJECT_LINE = -1 : S_START = 1 : S_HAVE_FNO = 2 : S_DONE = 3 : S_GET_VALUE = 4 120 REMark some constants for the commands 130 MANIFEST : C_INVALID% = -1 : C_CHANGE% = 1 : C_SPEED% = 2 : C_TAKEOFF% = 3 : C_LAND% = 4 140 MANIFEST : C_CHANGEALT% = 5 : C_CHANGEHEAD% = 6 150 REPeat InpLoop 160 INPUT #1,Please enter a command Line:,command$ 170 valid = parseLine(command$) 180 IF (valid) THEN 190 PRINT Flight #;fNo$;, please ; 200 SELect ON command% 210 = C_SPEED% 220 PRINT Change speed to ; value 230 = C_TAKEOFF% 240 PRINT Take off 250 = C_LAND% 260 PRINT Land 270 = C_CHANGEALT% 280 PRINT Change altitude to ; value 290 = C_CHANGEHEAD% 300 PRINT Change heading to ; value 310 END SELect 320 ELSE 330 PRINT Invalid line 340 END IF 350 END REPeat InpLoop 360 : 370 DEFine PROCedure InitParser (l$) 380 linePos = 1 390 lineToParse$ = l$ 400 END DEFine 410 : 430 : 440 REMark 450 REMark * this procedure parses an entered command line into the parts needed 460 REMark * returns 1 in case of success. The variables are set as follows 470 REMark * fno$ holds the flight number 480 REMark * command% holds the command to execute (see line 130) 490 REMark * valueholds numeric value of command 500 REMark 510 DEFine FuNction parseLine(command$) 520 InitParser command$ 530 REMark Set status to Start parsing line 540 state = S_START 550 : 560 REMark enter the loop that walks through the state machine 570 REPeat parseLoop 580 token$ = getNextToken$ 590 REMark did we hit the end of line? 600 IF token$ = CHR$(10) THEN 610 REMark check whether we're done or would have needed more input to be valid 620 REMark anything except S_DONE at the end of input is a wrong line 630 SELect ON state 640 = S_REJECT_LINE 650 PRINT Line cmd$ invalid at line end 660 RETurn 0 670 = S_START 680 PRINT Empty line entered 690 RETurn 0 700 = S_HAVE_FNO 710 PRINT Something after flight number is missing 720 RETurn 0 730 = S_DONE 740 REMark valid end of command line 750 RETurn 1 760 = REMAINDER 770 PRINT Invalid state 780 RETurn 0 790 END SELect 800 ELSE 810 REMark Got a valid token, no line end 820 : 830 SELect ON state 840 = S_REJECT_LINE 850 PRINT Line rejected: Line cmd$ invalid at token$ State is:state 860 RETurn 0 870 = S_START 880 fNo$ = getFlightNo$ (token$) 890 IF fNo$ INVALID THEN 900 state = S_HAVE_FNO 910 ELSE 920 PRINT Invalid Flight number 930 state = S_REJECT_LINE 940 END IF 950 = S_HAVE_FNO 960 command% = getCommand% (token$) 970 SELect ON command% 980 = C_INVALID% 990 state = S_REJECT_LINE 1000 = C_CHANGE% 1010 REMark special handling of numerical input according to # of digits 1020 token$ = peekNextToken$ 1030 tl% = LEN(token$) 1040 SELect ON tl% 1050 = 2 1060 command% = C_CHANGEALT% 1070 = 3 1080 command% = C_CHANGEHEAD% 1090= REMAINDER 1100 state = S_REJECT_LINE 1110 PRINT Invalid number of digits after C command 1120 END SELect 1130 state = S_GET_VALUE 1140 = C_SPEED% 1150 state = S_GET_SPEED 1160 = C_TAKEOFF% 1170 state = S_DONE 1180 = C_LAND% 1190 state = S_DONE 1200END SELect 1210 = S_GET_VALUE 1220 value = getNumericValue (token$) 1230 state =
Re: [Ql-Users] Approaches to parsing in SuperBASIC
On Sun, Feb 6, 2011 at 11:58 AM, QL-MyLink (f/fh) q...@mylink.adsl24.co.ukwrote: Tobias helpfully said - Dave, the manual is right here and your memory is wrong ;-). - Brave Dave, Do you have a copy of Jan Jones? It's great for *all* SBasic INSTR-uctions. John in Wales ___ I don't have anything - restarting from scratch. I have a US QL with funky US fonts and a bad membrane (replacement on way soon), a Gold Card, backplane, QubIDE w/o drivers... and Daniele Terdina's excellent Q-Emulator for Mac 1.0, which gets all the use. I bought SMSQ/E back in the day, on floppy, but can't find it or any of my old software. Dave Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] USBWiz Driver Update
In message 001c01cbc23b$b4caf510$1e60df30$@acanthis.co.uk, Adrian Ives adr...@acanthis.co.uk writes Hi Adrian, Yes, using the USBWiz is a good idea. A new hardware project always creates interest. PS - This list is getting very busy, too. Just catching up on over 100 emails ... :-) I have no idea if anyone is remotely interested in this project to attach USB devices to a QL using a small card called a USBWiz. This device presents a serial interface and accepts AT style commands to communicate with many classes of USB device. I started working on this last year, but was delayed by some family problems and a move to another part of the country. My prototype hardware is a little black block that connects via a serial lead to a QL or Hermes serial port. The box has an SD card slot and two USB ports. In the past two weeks I have turned my original prototype driver inside out (not a trivial task, no wonder I missed an errant me equ 0 statement). The first version suffered from problems encountered when trying to do serial I/O while in supervisor mode (in effect, a driver on top of a driver). Today I successfully completed a test which involved writing a text file to a native QDOS format SD card, then reading it back again. The new driver switches to user mode to do asynchronous I/O over the standard serial port driver through an I/O queue which is managed by a Queue Manager job. In this it is very different from other device drivers and so will need a lot more testing. Not the least of which under QDOS as the driver has been developed under SMSQ. The framework is also in place to support real time communication with the driver core through a pipe mechanism. This is intended to allow queries to be sent to the driver, as opposed to its devices; a variation on a paper that I read about the possibility of implementing meta devices on the QL. Some time in the future I envisage a USB thing to act as the interface to this feature. Anyway, that's where I am. The new device driver has the name USB; USB1 is the SD card slot, USB2 and USB3 are the ports which can mount standard external hard drives or memory sticks. It reads and writes, but the format routine still needs completing (formatting is currently done with a S*BASIC utility) As well as the native QL driver I also have a File Manager which needs no driver (only a free serial port) and can read and write FAT format SD cards and USB hard drives. This software also supports the automatic saving and retrieving of the QDOS 64 byte header. This program currently runs in menu-driven character mode, but it is my intention to migrate it to a GD2 compliant pointer app in the very near future. So, my question is this: Is anyone actually interested in me devoting more time to finish this project? If (and it is still an if) the driver can be brought to a release-stable state, is there interest in a commercial product based around this? -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Finally a reply
In message 4d45ec4b.7030...@sbcglobal.net, Timothy Swenson swenso...@sbcglobal.net writes On 1/30/2011 10:48 AM, Malcolm Cadman wrote: Were Officers to be elected, directly, at an AGM, it would open the door to someone incompetent to get voted in, or some collusion to take place. Interesting, as California State code for Non-profits pretty much specifies that members vote on officers and the board. It is only the members that can make any changes to the By-laws. I'm guessing that the AGM is the same as a General Member Meeting. Most non-profits have one every year for elections. In one non-profit I'm involved with, rarely does a regular member attend these meetings and only the Board members show up (even with the required notification sent out). Hi Tim, I think that we are talking about the same thing. The full membership attends a General Meeting of Members ... in the UK called an Annual General Meeting (AGM), as it is held once a Year. The general membership are there to see the people being put forward for the Committee (Board). However, suppose at the AGM a member puts themselves forward for the Treasurer ... and all the other members present then vote for that person. Yet, the member voted in has not demonstrated any competence for the Position . see the problem? The Committee (Board) cannot then function. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Wow. You really thought about it. 221 lines of code! I have this notion that I need to scan through the characters and split the input into words. I can simplify a lot because the bounds are known and very limited. For example, S INSTR cmd$ is a very simple case and so is L - so for these simply extracting the flight and the target is straightforward. When C INSTR cmd$, if I check for a modifier (X or L) as the last character, it makes it as simple as the previous example. Let me play with some code and see what I come up with over the next couple of days. I think I can be a lot more computationally economical, but my code will not flex easily to other cases, whereas your code is applicable in a lot of other cases. If I can't do it, may I use your code example as a guide? It's well labeled, flexible and explicit. Dave On Sun, Feb 6, 2011 at 2:14 PM, Tobias Fröschle tobias.froesc...@t-online.de wrote: Dave, had a lazy Sunday afternoon and was thinking about your problem - And, being a bit challenged and had nothing else to do, wrote a parser/analyzer for your Language: Ended up with quite a bit of code, the problem is not as simple as it seems (Hope I didn't over-complicate things). But I wanted to have a generic parser that could easily be extended and also probably be used for other purposes. It seems to understand most of the commands you mentioned and could be a starting point for you. Note it's currently only accepting uppercase commands. If you don't use Turbo and its toolkit, just remove the MANIFEST statemens at the beginning of lines 110 to 130, they declare the variables in the lines constant - I just like to use symbolic names for the states and commands instead of values, it's just easier to read. Now go ahead and tear it apart. Cheers, Tobias 100 DIM command$(100) 110 MANIFEST : S_REJECT_LINE = -1 : S_START = 1 : S_HAVE_FNO = 2 : S_DONE = 3 : S_GET_VALUE = 4 120 REMark some constants for the commands 130 MANIFEST : C_INVALID% = -1 : C_CHANGE% = 1 : C_SPEED% = 2 : C_TAKEOFF% = 3 : C_LAND% = 4 140 MANIFEST : C_CHANGEALT% = 5 : C_CHANGEHEAD% = 6 150 REPeat InpLoop 160 INPUT #1,Please enter a command Line:,command$ 170 valid = parseLine(command$) 180 IF (valid) THEN 190 PRINT Flight #;fNo$;, please ; 200 SELect ON command% 210 = C_SPEED% 220 PRINT Change speed to ; value 230 = C_TAKEOFF% 240 PRINT Take off 250 = C_LAND% 260 PRINT Land 270 = C_CHANGEALT% 280 PRINT Change altitude to ; value 290 = C_CHANGEHEAD% 300 PRINT Change heading to ; value 310 END SELect 320 ELSE 330 PRINT Invalid line 340 END IF 350 END REPeat InpLoop 360 : 370 DEFine PROCedure InitParser (l$) 380 linePos = 1 390 lineToParse$ = l$ 400 END DEFine 410 : 430 : 440 REMark 450 REMark * this procedure parses an entered command line into the parts needed 460 REMark * returns 1 in case of success. The variables are set as follows 470 REMark * fno$ holds the flight number 480 REMark * command% holds the command to execute (see line 130) 490 REMark * valueholds numeric value of command 500 REMark 510 DEFine FuNction parseLine(command$) 520 InitParser command$ 530 REMark Set status to Start parsing line 540 state = S_START 550 : 560 REMark enter the loop that walks through the state machine 570 REPeat parseLoop 580 token$ = getNextToken$ 590 REMark did we hit the end of line? 600 IF token$ = CHR$(10) THEN 610 REMark check whether we're done or would have needed more input to be valid 620 REMark anything except S_DONE at the end of input is a wrong line 630 SELect ON state 640 = S_REJECT_LINE 650 PRINT Line cmd$ invalid at line end 660 RETurn 0 670 = S_START 680 PRINT Empty line entered 690 RETurn 0 700 = S_HAVE_FNO 710 PRINT Something after flight number is missing 720 RETurn 0 730 = S_DONE 740 REMark valid end of command line 750 RETurn 1 760 = REMAINDER 770 PRINT Invalid state 780 RETurn 0 790 END SELect 800 ELSE 810 REMark Got a valid token, no line end 820 : 830 SELect ON state 840 = S_REJECT_LINE 850 PRINT Line rejected: Line cmd$ invalid at token$ State is:state 860 RETurn 0 870 = S_START 880 fNo$ = getFlightNo$ (token$) 890 IF fNo$ INVALID THEN 900 state = S_HAVE_FNO 910 ELSE 920 PRINT Invalid Flight number 930 state = S_REJECT_LINE 940 END IF 950 = S_HAVE_FNO 960 command% = getCommand%
Re: [Ql-Users] Approaches to parsing in SuperBASIC
221 lines of code! Tobias, do have more 'lazy Sunday afternoons', please. Wish I could have written the same - it's poked some valuable ideas into my memory. Thank you. In there however, is a small shadow, specifically regarding your SELect ON's. Does your code rely on the additional utility provided by SBasic but which is not present in (Jan Jones') SuperBASIC? Will the code perform in the 'all native original QL' platform that Dave is anxious to use? Goodnight all, John in Wales ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Am 07.02.2011 02:11, schrieb QL-MyLink (f/fh): 221 lines of code! Tobias, do have more 'lazy Sunday afternoons', please. Wish I could have written the same - it's poked some valuable ideas into my memory. Thank you. In there however, is a small shadow, specifically regarding your SELect ON's. Does your code rely on the additional utility provided by SBasic but which is not present in (Jan Jones') SuperBASIC? Will the code perform in the 'all native original QL' platform that Dave is anxious to use? Goodnight all, John in Wales John, the code has admittedly been written in SBasic on QPC, but should, with slight modifications (if any) run on a basic QL as well. There's 'SELECT's on integer variables, and if I remember right, the original black box couln't do that, but that could easily be replaced with FPs or compiled with QLiberator. (My original black box is hidden deep in the dungeons somewhere, and I had a too lazy Sunday afternoon to search for it for a test) Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Approaches to parsing in SuperBASIC
Am Sonntag, den 06.02.2011, 17:56 -0600 schrieb Plastic: Let me play with some code and see what I come up with over the next couple of days. I think I can be a lot more computationally economical, but my code will not flex easily to other cases, whereas your code is applicable in a lot of other cases. Dave, you sure can use this however you like. It's been posted to a public mailing list and thus considered public. And I'm sure I've built some nasty bugs in there for you to chew on. I've run the code through TURBO, for example, with the result that the parser is always off by one char in the line, need to have another look into it, that's interesting. Cheers, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
