Re: [Ql-Users] TYPE_IN

2017-10-04 Thread Lee Privett via Ql-Users
Thanks guys and especially to Michael, and to his last few questions.
Firstly I placed the query (cut down) to avoid a lengthy and possibly
boring explanation
I am periodically (while I can) in pre-production of a lengthy project that
I have dabbled in over the last two years and as I think about aspects of
the project, mini projects pop into mind. These result in functions or
procedures that I test out and if useful, I publish in QUANTA.

One such project is so large that the programming for it has to be fairly
rigorously planned out, which amongst other things includes plenty of REM
statements.
So I am writing a procedure called AutoREM which asks two questions, what
line to start at (An) and what it is all about (Final$), it will then
create REM statements and eventually DEF PROC and END PROC lines
automatically, all within the SMSQ/e environment. Specifically at the
moment QPC2. Although not compiled a version of this will be used in the
"big project" which will be.

I hope that satisfies your intrigueness (not a real word) Michael.

Lee



Lee




On Wed, Oct 4, 2017 at 9:42 AM, Michael Bulford via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> 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 

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