Hi Lee,

Yes, I am most satisfied, thanks so much, yours is a very nice reply.

I was thinking first off perhaps you was up to doing some SBASIC
self-modifying code - I wonder if anyone has ever tried this.  There 
could be some instances where doing this could make the code more
efficient - who knows?

It turns out though you are using this for REM statements - apparently 
simple stuff.  Nevertheless these ideas that start out being easy in nature 
can sometimes produce lots of bugs. It can be very nerve-wracking at 
times. We write code to do something in particular - and it doesn't work, 
and can take ages to fathom out.  Anyway, I hope my attempts at trying 
to resolve this particular issue turns out to be helpful.

All the best,

Michael 



> On Wed, 4 Oct 2017 at 10:49, Lee Privett <lee.priv...@gmail.com> wrote:



> 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 = 20000
> > 1920 TYPE_IN An&":"&CHR$(10)
> > 1930 TYPE_IN (An+1)&Top$&CHR$(10)
> > 1932 TYPE_IN (An+2)&Final$&CHR$(10)
> > 1940 TYPE_IN (An+3)&Top$&CHR$(10)
> > 1950 TYPE_IN "CLS#2:LIST"&CHR$(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 = 20000
> > 1920 TYPE_IN An&":"&CHR$(10)       :IF NOT COMPILED:TYPE_IN 
> > "CONTINUE"&CHR$(10):STOP
> > 1930 TYPE_IN (An+1)&Top$&CHR$(10)  :IF NOT COMPILED:TYPE_IN 
> > "CONTINUE"&CHR$(10):STOP
> > 1932 TYPE_IN (An+2)&Final$&CHR$(10):IF NOT COMPILED:TYPE_IN 
> > "CONTINUE"&CHR$(10):STOP
> > 1940 TYPE_IN (An+3)&Top$&CHR$(10)  :IF NOT COMPILED:TYPE_IN 
> > "CONTINUE"&CHR$(10):STOP
> > 1950 TYPE_IN "CLS#2:LIST"&CHR$(10) :IF NOT COMPILED:TYPE_IN 
> > "CONTINUE"&CHR$(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
> >


End of Ql-Users Digest, Vol 164, Issue 3

****************************************
_______________________________________________
QL-Users Mailing List

Reply via email to