[Ql-Users] (no subject)

2021-04-19 Thread Michael Bulford via Ql-Users
Ql
 
 
 
https://bitly.com/3v6iFgH
 
 
 
 
Michael Bulford
 
___
QL-Users Mailing List

Re: [Ql-Users] Select on

2020-06-21 Thread Michael Bulford via Ql-Users
If we are talking about Selecting on single-character strings, such as when 
coding actions depending on some keypress, I would like to tell you about how I 
get around this problem. At the very beginning, I would declare some constants 
of the codes of all the alphabetical characters, all 52 of them. Underscores 
are used in the names to highlight these vars are constants and their initial 
values should not change. I will give what the code would look like under 
Minerva, and then how this would look in SMSQ/E. Note that when Selecting on 
strings, both cases, capitals and lower case letters are considered equivalent. 
This has to be taken into account.

100 : 
110 :
120 REMark In Minerva SuperBASIC
130 case$ = "" : REMark "a" == "A" - both cases
140 SELect ON case$
150 = "a" : PRINT 'Choice is "A"'
160 = "b" : PRINT 'Choice is "B"'
170 = "c" : PRINT 'Choice is "C"'
180 = "d" : PRINT 'Choice is "D"'
190 = "e" : PRINT 'Choice is "E"'
200 = "f" : PRINT 'Choice is "F"'
210 = CHR$(27) : PRINT 'Esc pressed'
220 END SELect
230 :
2000 REMark In SMSQ/E S*BASIC
2010 REMark Note: MANIFEST is optional TURBO command for extra constant checking
2020 :
2030 MANIFEST : _a =  97 : A_ = 65
2040 MANIFEST : _b =  98 : B_ = 66
2050 MANIFEST : _c =  99 : C_ = 67
2060 MANIFEST : _d = 100 : D_ = 68
2070 MANIFEST : _e = 101 : E_ = 69
2080 MANIFEST : _f = 102 : F_ = 70
2090 MANIFEST : ENTER = 10 : Esc = 27
2100 CLS
2110 REPeat loop
2120 PRINT 'Choose case: Press a letter between "a" and "F" ';
2130 case = CODE(INKEY$(#1,-1)) : IF case <> ENTER : PRINT CHR$(case); " ";
2140 SELect ON case
2150 = _a,A_ : PRINT 'Choice is "A"'
2160 = _b,B_ : PRINT 'Choice is "B"'
2170 = _c,C_ : PRINT 'Choice is "C"'
2180 = _d,D_ : PRINT 'Choice is "D"'
2190 = _e,E_ : PRINT 'Choice is "E"'
2200 = _f,F_ : PRINT 'Choice is "F"'
2210 = Esc   : PRINT 'Esc pressed' : EXIT loop
2220 = REMAINDER : PRINT 'Try again'
2230 END SELect
2240 END REPeat loop
2250 PRINT 'Test complete'
2260 PRINT #0,'Test complete'

Michael
___
QL-Users Mailing List

Re: [Ql-Users] Select on

2020-06-21 Thread Michael Bulford via Ql-Users
 If we are talking about Selecting on single-character strings, such as when 
coding actions depending on some keypress, I would like to tell you about how I 
get around this problem.  At the very beginning, I would declare some constants 
of the codes of all the alphabetical characters, all 52 of them.  Underscores 
are used in the names to highlight these vars are constants and their initial 
values should not change.  I will give what the code would look like under 
Minerva, and then how this would look in SMSQ/E. Note that when Selecting on 
strings, both cases, capitals and lower case letters are considered equivalent. 
 This has to be taken into account.
100 : 
110 :120 REMark In Minerva SuperBASIC130 case$ = "" : REMark "a" == "A" - both 
cases140 SELect ON case$150 = "a" : PRINT 'Choice is "A"'160 = "b" : PRINT 
'Choice is "B"'170 = "c" : PRINT 'Choice is "C"'180 = "d" : PRINT 'Choice is 
"D"'190 = "e" : PRINT 'Choice is "E"'200 = "f" : PRINT 'Choice is "F"'210 = 
CHR$(27) : PRINT 'Esc pressed'220 END SELect230 :2000 REMark In SMSQ/E 
S*BASIC2010 REMark Note: MANIFEST is optional TURBO command for extra constant 
checking2020 :2030 MANIFEST : _a =  97 : A_ = 652040 MANIFEST : _b =  98 : B_ = 
662050 MANIFEST : _c =  99 : C_ = 672060 MANIFEST : _d = 100 : D_ = 682070 
MANIFEST : _e = 101 : E_ = 692080 MANIFEST : _f = 102 : F_ = 702090 MANIFEST : 
ENTER = 10 : Esc = 272100 CLS2110 REPeat loop2120 PRINT 'Choose case: Press a 
letter between "a" and "F" ';2130 case = CODE(INKEY$(#1,-1)) : IF case <> ENTER 
: PRINT CHR$(case); " ";2140 SELect ON case2150 = _a,A_ : PRINT 'Choice is 
"A"'2160 = _b,B_ : PRINT 'Choice is "B"'2170 = _c,C_ : PRINT 'Choice is 
"C"'2180 = _d,D_ : PRINT 'Choice is "D"'2190 = _e,E_ : PRINT 'Choice is 
"E"'2200 = _f,F_ : PRINT 'Choice is "F"'2210 = Esc   : PRINT 'Esc pressed' : 
EXIT loop2220 = REMAINDER : PRINT 'Try again'2230 END SELect2240 END REPeat 
loop2250 PRINT 'Test complete'2260 PRINT #0,'Test complete'
Michael
___
QL-Users Mailing List

Re: [Ql-Users] QED v2.01 released!

2018-09-25 Thread Michael Bulford via Ql-Users
* TAB compression and expansion supported
* Raw and cooked LOADing and SAVing of files for CR/LF conversion
Hi Jan,
Many thanks, this is highly welcome.I use your software quite a lot.

Michael

___
QL-Users Mailing List


Re: [Ql-Users] QPC2 4.04 BUG (RWAP Software)

2018-04-23 Thread Michael Bulford via Ql-Users
> Does anyone know why the following in QPC2 reports "Invalid Channel ID"
>
> WINDOW 448,200,32,16
> PAPER #1,3
>> In fact, any attempt to change #1 after the WINDOW command reports an 
> invalid channel.>> I also found some of the character combinations were not 
> working in 
> v4.04 (eg CTRL SHIFT - did not produce a down arrow).
> That also now works in v4.05 but CTRL \ does not produce the left arrow 
> still.     Hi,    I am using both QPC2 4.04 SMSQE/E 3.26 and also QPC2 4.05 
> SMSQE/E 3.31.They both seem to work the same.I cannot replicate any of the 
> errors mentioned, except that I cannot produce the left arrow.    As Dilwyn 
> points out, doing an OPEN #1, would do an automatic CLOSE #1 first, and 
> perhaps that has caused the problems.    > On QPC2 v4.04 here I didn't have 
> to close anything - I just entered the
> two commands above as soon as it started     Perhaps there is something in 
> the Boot file causing the issue?          Michael

   
___
QL-Users Mailing List

Re: [Ql-Users] EXT_PROC

2017-11-09 Thread Michael Bulford via Ql-Users
On Wed, 8 Nov 2017 21:05:55, Per Witte  wrote:

> I was just made aware of a number of features in Q-Lberator that I havent
> seen documented anywhere: EXT_PROC, EXT_FN, GLOBAL, and possibly others. I
> believe I have a general idea of what theyre about, but should like to see
> some documentation. Ive been told there is a chapter 14 in some manuals?
> The two pdf manuals I found online, one of them claiming to be of V3.36,
> dont mention these keywords, and my printed one is altogether of an older
> vintage.


Hi Per,
See this link .. http://www.dilwyn.me.uk/qlib/index.html

There are a couple of v3.36 manuals that clearly document these EXT_FN, 
EXT_PROC and GLOBAL keywords.  They might not work as expected on QPC2, as 
SMSQ/E is being used.  But these should work on Q-emulator.

Michael
___
QL-Users Mailing List

Re: [Ql-Users] CPORT

2017-11-01 Thread Michael Bulford via Ql-Users
Hi Norman,
I have both CPORT and CFIX.  I find that CFIX doesn't work correctly in QPC2,

so to get around that problem, I use Q-emulator for that one.

CPORT does work well in QPC2, provided that memory is limited to 16M.
There's also some other related files.
I'll dig them out.  How can I get them to you?

Kind regards,
Michael
___
QL-Users Mailing List


Re: [Ql-Users] TYPE_IN

2017-10-04 Thread Michael Bulford via Ql-Users
Hi all, 


I am hoping now to explain what is going on.  First, here is some code that 
does work .. 

100 DIM Top$  (100) : Top$   = "REMark " & FILL$( "*"  ,20) 
110 DIM Final$(100) : Final$ = "REMark " & FILL$("text",20) 
120 An = 2 
1920 TYPE_IN An&":"$(10) 
1930 TYPE_IN (An+1)$$(10) 
1932 TYPE_IN (An+2)$$(10) 
1940 TYPE_IN (An+3)$$(10) 
1950 TYPE_IN "CLS#2:LIST"$(10) 
1960 PRINT #0,"Program completed successfully" 

After running the above code, you may notice that the “completed” message does 
not appear. 
To explain why, we have to consider how this code works.  If this code is 
compiled, then SuperBASIC will act immediately upon each of the TYPED_IN 
commands.  Under the Interpreter, they will not be acted upon, but will get to 
be stored in #0’s buffer.  After the “completed” message gets printed to #0, 
the code comes to an end, and the SuperBASIC cursor comes back to life.  The 
contents of the #0 buffer then gets entered into the command line, and will be 
acted upon, scrolling the “completed” message out of the way. 

Now consider what can happen if we change the first line to read FILL$(“*”,60). 
 Running the code again with this larger figure will lead to it “locking up”, 
with nothing apparently happening.  What has happened is that #0’s buffer has 
become full, and it is waiting there for some characters to be removed, which 
never happens.  The only thing to do is to press Ctrl-SPACE and Ctrl-c to 
abort. 

As long as the buffer length of 128 bytes is not exceeded during a TYPE_IN, all 
should be well. 
Each TYPE_IN will need to be made separately, with the QL stopping, then 
continuing. 
The need to STOP is necessary to force the #0 buffer to empty its contents. 
Notice that we do not STOP if COMPILED, as doing that would remove the task. 
Here is the same code as above with these amendments … 

100 DIM Top$  (100) : Top$   = "REMark " & FILL$( "*"  ,60) 
110 DIM Final$(100) : Final$ = "REMark " & FILL$("text",60) 
120 An = 2 
1920 TYPE_IN An&":"$(10)   :IF NOT COMPILED:TYPE_IN 
"CONTINUE"$(10):STOP 
1930 TYPE_IN (An+1)$$(10)  :IF NOT COMPILED:TYPE_IN 
"CONTINUE"$(10):STOP 
1932 TYPE_IN (An+2)$$(10):IF NOT COMPILED:TYPE_IN 
"CONTINUE"$(10):STOP 
1940 TYPE_IN (An+3)$$(10)  :IF NOT COMPILED:TYPE_IN 
"CONTINUE"$(10):STOP 
1950 TYPE_IN "CLS#2:LIST"$(10) :IF NOT COMPILED:TYPE_IN 
"CONTINUE"$(10):STOP 
1960 PRINT #0,"Program completed successfully" 

The above code works as expected in SMSQ/E.  It should not work under QDOS as 
after entering any new line in the code, QDOS will lose its place and would not 
be able to continue.  For QDOS it is best to compile the code.  Another point 
to bear in mind is that any line TYPED_IN with invalid syntax will lead to the 
SuperBASIC cursor being re-entered to enable the faulty line to be edited.  
There is a simple way to cope with this condition, by starting each TYPE_IN 
with a CHR$(27) - the Escape key. 
This kind of code can be far easier to write and get working if it is compiled 
with Turbo.  After any TYPE_IN to SuperBASIC, Turbo could wait in the 
background, in a loop, monitoring the SuperBASIC cursor position, and 
determining whether the typed-in line was successful or not.  This arrangement 
would allow the user to correct the command line and press ENTER.  Only when 
everything is okay could Turbo decide to exit the loop and continue.  If the 
128-character limit is too restrictive, one could use a temporary MERGE file 
instead of using TYPE_IN. 

This discussion would be more entertaining if we had more details of what is 
trying to be achieved. 
What is being used? - The QL, Q-emuLator or QPC2? - also is this compiled?  I 
notice that each TYPE_IN starts with an integer, which would mean that lines 
are being added to SuperBASIC. 
This is indeed intriguing! 

Michael 
___
QL-Users Mailing List

Re: [Ql-Users] TYPE_IN

2017-09-30 Thread Michael Bulford via Ql-Users
> Fellow QL'ers 

>

> I have a slight problem with TYPE_IN 

>

> Using it to put some commands in #0, works well in an instance until I 

> reach what appears to be a maximum set of characters, where the QL just 

> hangs. 

>

> e.g. 

>

> 1920  TYPE_IN An&":"$(10) 

> 1930  TYPE_IN (An+1)$$(10) 

> 1932  TYPE_IN (An+2)$$(10) 

> 1940  TYPE_IN (An+3)$$(10) 

>

>

> An is an integer 

> Final$ is just text 

> Top$ is a string of asterisks 

>

> it locks up displaying halfway through 1940 

>

> Is there a buffer I can clear after using TYPE_IN? 

>

> or can I increase the length of the number of characters TYPE_IN can use? 

>

> Many thanks in anticipation 

>

> Lee 


If this is a compiled Turbo program, then there should be no problems as each
of the typed-in commands would be processed separately.

Running this under the Interpreter is slightly different. Each of the typed-in

commands will only get to be processed once the SuperBASIC program has come 

to a stop. Before this stop happens, everything typed in to SuperBASIC's #0

will be stored in #0's buffer. If there are many commands to be processed, then

this buffer could be exceeded, resulting in one of the commands being truncated
and the remainder being lost. There is a simple way to overcome this problem.
The program can be deliberately stopped after each of the TYPE_INs, and then be
made to continue afterwards.  To get the program to stop, use the STOP command,
and to get the program to continue, use the CONTINUE command. This idea can be
implemented by extending each of the TYPE_IN commands in the program, as 
follows ..

: IF NOT COMPILED : TYPE_IN "CONTINUE" & CHR$(10) : STOP

Notice the STOP command at the end. This is important and is the secret. The 
STOP
command stops the program and allows the typed_in command to execute, after 
which
the CONTINUE command causes the program to continue.  By doing it this way, all
commands will be executed separately, similar to how a compiled program would 
work.
Lee, can you please try the above suggestion and let us know how you get on.
Best wishes,
Michael
___
QL-Users Mailing List


Re: [Ql-Users] Lear PCB Design v7.55

2017-09-19 Thread Michael Bulford via Ql-Users
On Mon, 18 Sep 2017 at 14:26, Dilwyn Jones  wrote:

> A new update of Malcolm Lear's PCB Design is available from the Graphics page 
> on my website. Details of the little bug fix in the REVISIONS.TXT file.
>
> version 7.55  Fixed 1 mil offset correction for snake shape with odd offset.
>
> download free of charge from  http://www.dilwyn.me.uk/graphics/index.html
>
> Dilwyn

Sorry - I meant line 31850, this hasn't been called - the procedure FreeRotate. 

Michael
___
QL-Users Mailing List


Re: [Ql-Users] Lear PCB Design v7.55

2017-09-19 Thread Michael Bulford via Ql-Users
On Mon, 18 Sep 2017 at 14:26, Dilwyn Jones  wrote:

> A new update of Malcolm Lear's PCB Design is available from the Graphics page 
> on my website. Details of the little bug fix in the REVISIONS.TXT file.
>
> version 7.55  Fixed 1 mil offset correction for snake shape with odd offset.
>
> download free of charge from  http://www.dilwyn.me.uk/graphics/index.html
>
> Dilwyn
I have noticed that the procedure FreeRotate, defined at line 1850, is never  
called. 
- Just thought I'd point this out.
Michael
___
QL-Users Mailing List


Re: [Ql-Users] Function type error

2017-09-09 Thread Michael Bulford via Ql-Users
> > On 7 Sep 2017 at 15:15, George Gwilt <ql-us...@q-v-d.com> wrote:
> >
> > Subject: Re: [Ql-Users] Function type error
> >
> > On 10 Aug 2017, at 22:49, Michael Bulford via Ql-Users 
> > <ql-users@lists.q-v-d.com> wrote:
> > 
> > Thanks for your explanations.  This is all specific to SBASIC.
> > Tobias gives an example with a LOCal name the same as the function name.
> > Although this is possible, it cannot be recommended.  You will not be able
> > to call the function recursively.  And it won't compile with either 
> > QLiberator or Turbo!
> 
> Actually TURBO does compile the program and gives the answer 331.
>
> George

Indeed, yes.  I've also tested this with Minerva on Q-emuLator.
Both under the Interpreter and Turbo, the result is again 331.
However, Q-Liberator gives only 330.7

With both compilers now free, and with more and more people using them,
it should follow that these functions need to be written with greater care in 
the future.

Michael
___
QL-Users Mailing List


Re: [Ql-Users] TURBO and testing it exists

2017-08-19 Thread Michael Bulford via Ql-Users
On Thu, 17 Aug 2017 21:08:31, Per Witte  wrote:

> Thats a nice solution. Not sufficient for all manner of keywords, though. 
A
> more general solution for checking for relevant toolkits in boot programs,
> without having to load a toolkit to do so can be found in this article:
> http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)

Hi Per, I cannot get the above link to work.  It says not found.



On Thu, 17 Aug 2017, 16:54:32, Duncan   wrote:

Hi Lee, If booting from a Win drive  on the first instance of needing to 
load the Turbo toolkit check for the existence of a file on the boot device 
called "TTKLoaded", or similar. If the file does not exist create it and 
load TurboTK. If the file is found to exist do not load the toolkit. At the end 
of the session tidy up the boot device by deleting this file. Not elegant 
but practical.


Hi Duncan,

But what if during the session the QL crashes?  The TTKLoaded file will remain 
on the Win drive, and the next time the QL session is started, it won't work 
properly.  A nice idea though.  Another way of doing this is to use environment 
variables, which I use myself.  The details are here: 
http://www.dilwyn.me.uk/tk/env.zip


Michael
___
QL-Users Mailing List


Re: [Ql-Users] EXEP_W

2017-08-16 Thread Michael Bulford via Ql-Users
On Wed, 16 Aug 2017, Duncan wrote:

Question : are you using QDOS or smsqe? with smsqe it should be possible to 
create a wrapper basic executable program that will EXEP "task; parameters" 
then continue to run and check the jobs list (you will know the task name) 
until the task it EXEP has finished before continuing with what you want to do 
next.
Hi Duncan,
Thanks for your suggestion, I did think of that idea.
Also, I have found FEP(...) which returns the id of the job created.
So, I'm guessing I could do something along these lines ...
id = FEP(etc)
REPeat wait
SUSPEND_TASK 25
IF PJOB(id)=0  : IF OJOB(id)=0  : IF JOB$(id)="" : EXIT wait
END REPeat wait
I haven't tried this yet. Doing it this way, the task name would not need to be 
known.
Michael
___
QL-Users Mailing List


[Ql-Users] EXEP_W

2017-08-16 Thread Michael Bulford via Ql-Users
Hi,

I am wanting to use EXEP some_turbo_task; arg$, "i", "u"
and then wait until that job completes before continuing.
Is there such a command that does this?
If not, then how can this be implemented?
Any ideas please

Michael
___
QL-Users Mailing List


Re: [Ql-Users] Function type error

2017-08-10 Thread Michael Bulford via Ql-Users
Thanks for your explanations.  This is all specific to SBASIC.
Tobias gives an example with a LOCal name the same as the function name.
Although this is possible, it cannot be recommended.  You will not be able
to call the function recursively.  And it won't compile with either QLiberator 
or Turbo!
Michael

On Thu, 10 Aug 2017 20:33:58, Tobias Fr?schle via Ql-Users 
 wrote:

The type of a function is not determined by the function name ending in a $ or 
% sign, but rather by what it returns - You can even write a function STRING% 
that returns a string or a function a$ that returns an integer value. The name 
you give your function is simply a hint to yourselves on what it might return.

What you actually return in your original function is the result of an 
/expression/ - and numerical expressions in S*BASIC are of type floating point. 
If you assign the value to the expression to a LOCal integer value and return 
that, you will actually get your desired result.

1000 DEFine FuNction x% (param)
1010   LOCal x%
1020   x% = param / 10
1025  REMark assign to integer variable x% to make sure INT is returned
1030  RETurn x%
1040 END DEFine x%
___
QL-Users Mailing List


[Ql-Users] Function type error

2017-08-10 Thread Michael Bulford via Ql-Users
Hi all,
I've no idea whether this has been mentioned before, but consider this … 100 
:110 PRINT #0, Min_Int%(330.7, 440.7)120 PAUSE -1130 STOP140 :150 DEFine 
FuNction Min_Int%(x%,i)160  IF x% < i : RETurn x% : ELSE : RETurn i170  END 
DEFine The correct result should be 331, sincethis is an integer function.On 
QPC2, SBASIC gives the result as 330.7QLiberator likewise also gives 330.7 Can 
anything be done? Michael
   
___
QL-Users Mailing List

[Ql-Users] Subject: Re: PCB Design v7.52

2017-07-30 Thread Michael Bulford via Ql-Users
Whenever I try to run any new SBASIC code, there is this overlapping problem of 
some variable names used are possibly already installed as resident procedures. 
 The code then either does not work as intended, or can stop with an error 
message.  In these circumstances, I usually have to go through the code and 
rename the variables. 

Compiling into machine code can solve the above mentioned problem.  I first of 
all compiled using Turbo.  There was one REFERENCE statement that had to be 
inserted for the procedure Rotation, which passes back the values x and y to 
the caller, FreeRotate, which by the way is not even called.  There was just 
one expression at line 1230 that had to be re-written, to avoid Turbo using 
integer arithmetic and stopping with an overflow error.  The resulting task 
seems to work as well as the SBASIC version. 

Next I tried Q-Liberator, which compiled the code easily enough.  The resulting 
object file fails to display the x and y coordinates at the bottom of the 
screen. 

Both Turbo and Q-Liberator issued a Warning at line 23030 of .. END IF without 
an IF. 
A few weeks back I made mention about a new proposed update to the Turbo 
parser, which I have almost finished tweaking. I tried this new version on the 
code, and this did not warn of the above condition.  It did however, give 
information messages about how variables are being used - being the difference 
between Interpreted code and Turbo code.  It transpires that if one wants the 
SBASIC code to match exactly what the Turbo version does, then a great deal of 
changes will need to be made. 

I only have one criticism of the program so far.  When the program ends it does 
a NEW.  I may have made some changes or added some REMarks, and before closing 
down I would SAVE the code.  But after a NEW, all the code has gone!  The 
existing file is replaced with a blank one. 

Michael 
___
QL-Users Mailing List


Re: [Ql-Users] Quanta Magazine

2017-07-23 Thread Michael Bulford via Ql-Users
I've received two issues this year, up to the Feb/March issue.
None received since then.  I did email John Gilpin last week, but no reply as 
yet.


Michael
Dilwyn wrote:

> I've forwarded this to committee members (don't know the answer myself), 
> hopefully a reply soon.
>
> Dilwyn
>
> -Original Message- 
> From: sba1derson via Ql-Users
> Sent: Sunday, July 23, 2017 9:08 AM
> To: ql-us...@q-v-d.com
> Subject: [Ql-Users] Quanta Magazine
>
> Has anyone received an electronic copy of Quanta magazine since the 
> January/February 2017 issue?  I've not received one since.  I've contacted 
> Quanta via their website but so far have had no response.
___
QL-Users Mailing List


Re: [Ql-Users] PCB Design v7.52

2017-07-22 Thread Michael Bulford via Ql-Users
Hi,

Wolf wrote: 
> In the boot all file separators are "." (eg. "tk.bin"), but when 
> dezipped, the file separators are "_" as they should be, so the boot 
> can't find them.

There is the -Q1 option in unzip to reverse the "_" <-> "." 
Eg. EX unzip,#1; "-Q1 dos7_PCBDesign752.zip -d ram6_"
and they all come out with dots in them !

I have run the code and this does work well using QPC2, in extended screen size.

As a matter of interest, I tried my new Turbo parser on the BASIC code, and 
this was the result ..

 ERROR at 32210: Variable assignment expected.  
 Warning at 2570: Not assigned: global WinW2  
 Warning at 2570: Not assigned: global WinH2  
 Warning at 2570: Not assigned: global WinX2  
 Warning at 2570: Not assigned: global WinY2  
 Warning at 15290: Not assigned: global GScale 

TURBO: Parsing done, at 197440 statements per minute.
1 error and 5 warnings.

The 1 ERROR refers to "CD" which presumably is CHANGE_DIR, or DATA_USE

The 5 variables would have been initialised to zero, which may be acceptable,
unless you are using "AH" or "JM", in which case you'll get an "error in 
expression".

Michael
___
QL-Users Mailing List


[Ql-Users] Turbo Parser

2017-07-17 Thread Michael Bulford via Ql-Users
I’ve been working on a new proposed update to the Turbo parser. Here is what it 
can do: Warn of duplicated parameters/locals, locals overwriting parameters, 
names used again in nested FOR/REPeat loops; locals not used - or used but not 
assigned. If MANIFEST or IMPLICIT statements are made too late, then Turbo will 
now be able to give the line number where they need to be placed. Any missing 
REFERENCE statements are now warned of with a by-ref/by-value conflict check. 
REMarks can now be attached to the top of IF/SELect/FOR/REPeat structures.
  
Besides the above additions, some existing parts of the code have been improved 
upon. Warnings of "LOCALs must follow DEFinitions." and "Meaningless command 
ignored." have not been working. This is now fixed. Some bugs are extremely 
minor - On Turbo's front panel, it is possible to overflow the report file 
window. This is now fixed.
  
May I ask everyone please, if you are aware of any problems in using Turbo, can 
you please inform me. I’m quite familiar with Turbo's code, having studied this 
for some while, so should be able to investigate.

The parser will increase in size by 11k to 91k. I presume this will be 
acceptable. I need to check my code first, before submitting this to George.

Michael
___
QL-Users Mailing List