Re: [Ql-Users] More BASIC Queries
Hi, As I have not resolved my initialisation problem with Smsq as yet, I thought I would try the following boot listing. My first problem is wth Qascade not working in Qdos. Does it have to have a Minerva rom, if so, how do I install it? Arnold From: Dilwyn Jones dil...@evans1511.fsnet.co.uk To: ql-us...@q-v-d.com Sent: Thursday, 19 November, 2009 13:07:19 Subject: Re: [Ql-Users] More BASIC Queries BOOT - Choose the Operating System required and load same. (QDOS OR SMSQ) [if QDOS is selected then do nothing since QDOS is the native OS whereas if SMSQ is selected, LRESPR SMSQ_GOLD) - LRUN BOOT2 I should perhaps have qualified this - one boot can both install SMSQ and install the toolkits/extensions: 100 IF VER$HBA THEN 110 REM only offer to install SMSQE if not already present 120 INPUT1=SMSQE 2=QDOS;os 130 IF os = 2 THEN LRESPR WIN1_EXTNS_SMSQ_REXT 140 END IF 150 REM now install every other toolkit 160 IF VER$ HBA THEN 170 TK2_EXT : REM ensure TK2 enabled on QDOS systems 180 REMark install pointer environment on QDOS 190 LRESPR win1_extns_ptr_gen : REM in this order... 200 LRESPR win1_extns_wman 210 LRESPR win1_extns_hot_rext 220 END IF 230 LRESPR this 240 LRESPR that (and so on) 500 REM define hotkeys (and so on) 800 REMark activate hotkeys job 810 HOT_GO ___ 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] More BASIC Queries
- Original Message - From: arnold.cla...@talk21.com To: ql-us...@q-v-d.com Sent: Saturday, November 21, 2009 12:07 PM Subject: Re: [Ql-Users] More BASIC Queries Hi, As I have not resolved my initialisation problem with Smsq as yet, I thought I would try the following boot listing. My first problem is wth Qascade not working in Qdos. Does it have to have a Minerva rom, if so, how do I install it? Arnold Qascade is not the simplest of programs to set up, and there's two versions, Jonathan Hudson's original version and Marcel's hack for high colour systems (Marcel's version probably needs WIndow Manager 2, as well as high colour, I can't really remember) 1. Put all the Qascade files into their own directory, I use WIN1_QASCADE_ for both versions, but I've altered filenames of the executable. qascade is Marcel's version, qascade113 is Jonathan's version, which I use on QDOS systems like my Aurora and QemuLator. In other words, both versions can live in the same directory. 2. Set up a suitable qascade_rc file with the list of programs to control etc. 3. In your boot program you'll need something like this: 1470 EX win1_qascade_qascade;START win1_qascade_QASCADE_rc (Note than the bit in quotes with the START is case sensitive, If your qascade_rc is qascade_RC, you have to type it out as qascade_RC here) My experience has been that (1) if you get the case wrong or (2) make a mistake with the qascade_rc text file it doesn't work and doesn't tell you much about what went wrong. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
On 18 Nov 2009, at 23:09, John Gilpin wrote:
I am grateful to all who have contributed to this thread. Your advice has
been taken on board and I now feel confident in re-writing my BOOT
program(s). I shall be working on the following premises:-
The BOOT program should be a number of small SuperBASIC programs each one
performing a specific simple task and linked to the next one using the LRUN
command. This is to ensure that the whole of the BOOT process is carried out
by Job0. (I understand that when a SB program is LOADed it becomes resident
in memory and is allocated Job0. If another SB program (say BOOT2) is then
called at the end of BOOT, then BOOT is deleted from memory and is
replaced by BOOT2 and being then resident, BOOT2 becomes Job0 - and so on
with BOOT3, BOOT4 etc) I think that my BOOT sequence would look something
like this:-
BOOT - Choose the Operating System required and load same. (QDOS OR SMSQ)
[if QDOS is selected then do nothing since QDOS is the native OS whereas if
SMSQ is selected, LRESPR SMSQ_GOLD) - LRUN BOOT2
BOOT2 - check whether the required toolkits and extensions are loaded
(LRESPRd) and if not, load (LRESPR) them generally in line with the sequence
advised by Dilwyn (FROM Job0!!). LRUN BOOT3
BOOT3 - Check and adjust time and date if required. LRUN BOOT4
BOOT4 - Offer a menu of programs available within my 'system' - i.e. {A}
Genealogy (database manipulation, building Family Trees, Write details of
family members as a Word Processor Document - ours is a family HISTORY
project rather than just a family TREE). {B} QUANTA Membership records
(Membership address database, Mailing labels programs etc), {C}. etc.
...{R} Return to the command line in whichever OS is current. LRUN or EX the
file(s) associated with the selection OR restore any windows, and other user
settings etc to switch-on state and STOP.
Queries:- on my QLs (Aurora, SGC, QuBide, etc.) TK2 is loaded automatically
at power-on (AUTOTK2F1 command), the file BOOT is located, LOADed and runs
automatically. Are the EXTRAS within TK2 LRESPRd in the same manner as if
TK2 were LRESPRd from either the command line or from within a boot program?
OR are they 'loaded' some other way which may cause some or all of them to go
missing?
LRESPR SMSQ_GOLD causes the machine to RESET following which it
initialises again. Does this RESET remove TK2 from memory and is TK2 then
automatically reloaded again? File BOOT is then run again and only LRUNs
BOOT2 (since AFAIK there is no way of changing from SMSQ to QDOS without
manually RESETing the machine). Since it obviously takes some time to
activate TK2 (automatically or otherwise) would it be quicker to load TK2
along with all the other required extension (in BOOT2) provided no TK2
EXTRAS are required before then?
When a SB program is EXECd (from SMSQ) I have noticed that it too
becomes resident in the same way as an LRUN SB program. Does this mean that
the EXECd program also becomes Job0?
Can anyone see why this sequence of programs {which I am confident will
run on both QDOS and SMSQ on the Auroras} should not run exactly the same
under QPC2 on my Vista PCs? (which is the original point I raised with my
existing programs).
I have a different BOOT program for each computer:
Thor (not used now)
JM +Trump Card (BOOT on Floppy Disk)
QXL on Windows 3
Q40
Q60
SGC (BOOT on Floppy Disk)
SGC + Aurora + SuperHermes
QPC2 on PC laptop (Windows XP)
QPC2 on PC (Windows 98)
QPC2 on iMAC + Windows XP
QPC2 on a stick
Apart from some of the QPC2s all BOOTS are different. They reside on the
computer's hard disk apart from the ones on a floppy disk or QPC2 on a stick.
This means that I never need to use one computer's boot on another computer. It
was only on the QXL that I had to have two boots. The first boot, BOOT, called
the second boot, BOOT1. I think this was because some extras loaded in BOOT did
not work there so I had to load BOOT1 in which they did work.
And if no one wants to put together an article for the magazine, I may even
have a shot myself. Thanks for all the material for this.
Finally, I am surprised that no one has yet written a RELIABLE version of
EXTRAS as a stand alone tool to enable the name list to be investigated -
or perhaps they have? If it was called EXTRAS would it overwrite the TK2
EXTRAS?
EXTRAS lists only machine procedures and functions though the name list will
contain all names in use, including any variables used in the BOOT. Surely
that's what you want EXTRAS to do?
George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
BOOT - Choose the Operating System required and load same. (QDOS OR SMSQ) [if QDOS is selected then do nothing since QDOS is the native OS whereas if SMSQ is selected, LRESPR SMSQ_GOLD) - LRUN BOOT2 I should perhaps have qualified this - one boot can both install SMSQ and install the toolkits/extensions: 100 IF VER$HBA THEN 110 REM only offer to install SMSQE if not already present 120 INPUT1=SMSQE 2=QDOS;os 130 IF os = 2 THEN LRESPR WIN1_EXTNS_SMSQ_REXT 140 END IF 150 REM now install every other toolkit 160 IF VER$ HBA THEN 170 TK2_EXT : REM ensure TK2 enabled on QDOS systems 180 REMark install pointer environment on QDOS 190 LRESPR win1_extns_ptr_gen : REM in this order... 200 LRESPR win1_extns_wman 210 LRESPR win1_extns_hot_rext 220 END IF 230 LRESPR this 240 LRESPR that (and so on) 500 REM define hotkeys (and so on) 800 REMark activate hotkeys job 810 HOT_GO There's no problem with combining different actions in a boot program as long as it's fairly inline code and easy to follow - I tend to try to avoid calls to procs and functions in my boot programs. Equally, there's nothing to prevent you splitting it into 3 or 4 programs if it makes it easier for you to work out what's going wrong when you get problems like the ones you have with this program. Queries:- on my QLs (Aurora, SGC, QuBide, etc.) TK2 is loaded automatically at power-on (AUTOTK2F1 command), the file BOOT is located, LOADed and runs automatically. Are the EXTRAS within TK2 LRESPRd in the same manner as if TK2 were LRESPRd from either the command line or from within a boot program? OR are they 'loaded' some other way which may cause some or all of them to go missing? No, this is a full TK2 implementation, built into Super Gold Card. The AUTOTK2F1 just simply means you do not need a TK2_EXT statement in your boot program. Even if you use both, it won't do any harm - TK2_EXT just enforces the defintiions. They are installed just as if you had LRESPRed a disk based copy of toolkit 2. Even though it's built into Super Gold Card it should be listed by EXTRAS as normal. LRESPR SMSQ_GOLD causes the machine to RESET following which it initialises again. Does this RESET remove TK2 from memory and is TK2 then automatically reloaded again? File BOOT is then run again and only LRUNs BOOT2 (since AFAIK there is no way of changing from SMSQ to QDOS without manually RESETing the machine). Since it obviously takes some time to activate TK2 (automatically or otherwise) would it be quicker to load TK2 along with all the other required extension (in BOOT2) provided no TK2 EXTRAS are required before then? In this case the Super Gold Card toolkit 2 disappears and SMSQ/E takes over the machine. SMSQ/E has its own Toolkit 2 extensions built in, so you won't need to find a way of reinstalling the toolkit 2 extensions or load it from disk - in fact it's better not to try this in case any of the old QDOS toolkit 2 extensions work a little differently to SMSQ/E toolkit 2 extensions in any way. Just accept that once you are in SMSQ/E (all versions) you automatically have toolkit 2. When a SB program is EXECd (from SMSQ) I have noticed that it too becomes resident in the same way as an LRUN SB program. Does this mean that the EXECd program also becomes Job0? Umm, not quite sure what you mean here. Generally, if you EXEC a SBASIC program in SMSQ/E systems, it usually becomes a SEPARATE basic job, i.e. might be Job 1, Job 2, etc (if you list the running job with the JOBS command you'll see more than one basic program, usually job 0 has no name, while the second, third etc might have the names SBASIC - showing that you now have two instances of BASIC running. After entering the JOBS command: Job Tag Owner Priority Job-Name 00 032 1 1 0 s127 HOTKEY 2 2 0 s8SBASIC Job 0 is always the one available when SMSQ/E starts. This cannot be removed manually (unless you seriously crash it in which case it probably takes the whole of smsq/e with it, a Dilwyn-style programming crash!!!) Be a little bit careful about assuming that executed basic programs will always start a new job. It depends how you go about it. On my system I use fileinfo 2 and executing an sbasic program from disk with the QPAC2 Files menu will simply cause it to be executed in the main Job0, hence the possible source of confusion. Executing them with an EXEC or EX command from the basic job0 command line will create aa new sbasic job. Executing them with Qpac2 FIles menu, Launchpad basic launcher etc is not so easy, it depends on the setup on that system. If you want to be sure (and it will help show what happens) issue an SBASIC command first to start a new sbasic daughter job and LOAD or EXEC the program from there. At this point it starts to get a little confusing, I know. Basically, LOAD or QLOAD will start the program in the same job.
Re: [Ql-Users] More BASIC Queries
Op Thu, 19 Nov 2009 00:09:40 +0100 schreef John Gilpin
thegilp...@btinternet.com:
I think that my BOOT sequence would look something like this:-
BOOT - Choose the Operating System required and load same. (QDOS OR
SMSQ) [if QDOS is selected then do nothing since QDOS is the native OS
whereas if SMSQ is selected, LRESPR SMSQ_GOLD) - LRUN BOOT2
BOOT2 - check whether the required toolkits and extensions are loaded
(LRESPRd) and if not, load (LRESPR) them generally in line with the
sequence advised by Dilwyn (FROM Job0!!). LRUN BOOT3
BOOT3 - Check and adjust time and date if required. LRUN BOOT4
Seems like a good idea.
My BOOT (0) also writes some parameters to a file that tells it; what
machine it's running on, the mouse- and OpSys type and if ProWesS needs to
be loaded. The next BOOT's can read this file and act automatically.
Queries:- on my QLs (Aurora, SGC, QuBide, etc.) TK2 is loaded
automatically at power-on (AUTOTK2F1 command), the file BOOT is
located, LOADed and runs automatically. Are the EXTRAS within TK2
LRESPRd in the same manner as if TK2 were LRESPRd from either the
command line or from within a boot program?
GC, SGC and Trump cards have TK2 in ROM so only needs to be initialised by
TK2_EXT (or AUTOTK2F1 on the SGC), SMSQ/E has it in the code and doesn't
even need initialising. You never need to load TK2 separately on these
platforms.
When a SB program is EXECd (from SMSQ) I have noticed that it
too becomes resident in the same way as an LRUN SB program. Does this
mean that the EXECd program also becomes Job0?
No, it becomes a new job, the same way as when you issue the SBASIC
command and LRUN the SB program there.
A good way to test programs. Any LRESPRs done by this program will be
local to that job and EXTRAS from there will only show these local
keywords. If it crashes it's most likely just that job.
Can anyone see why this sequence of programs {which I am
confident will run on both QDOS and SMSQ on the Auroras} should not run
exactly the same under QPC2 on my Vista PCs? (which is the original
point I raised with my existing programs).
In contrast to George G., my BOOT's are the same for all my platforms. You
may need to add some machine testing lines though, to know which tools to
LRESPR or not. There were some examples of this in QL Today v7i23.
Finally, I am surprised that no one has yet written a RELIABLE version
of EXTRAS as a stand alone tool to enable the name list to be
investigated - or perhaps they have? If it was called EXTRAS would it
overwrite the TK2 EXTRAS?
Yes it would, so it's not clever to give it the same name.
There is a database of keywords Keywords_v21_dbs out there (The QLT Docs
CD, Dilwyns site?) to check for conflicting keyword names.
EXTRAS is part of TK2, Minerva and SMSQ/E but I assume they all act the
same.
Bob
--
The BSJR QL software site at: http://members.chello.nl/b.spelten/ql/
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Finally, I am surprised that no one has yet written a RELIABLE version of
EXTRAS as a stand alone tool to enable the name list to be investigated -
or perhaps they have? If it was called EXTRAS would it overwrite the TK2
EXTRAS?
Hi John, The VOCAB extension is part of SNG's DIY toolkit. It was written he
says due to the deficiencies of EXTRAS.
Only 276 bytes and reports on all or any of the 10 types of name table entry.
Described in QL World September 1992.
Regards
Duncan
-Original Message-
From: John Gilpin thegilp...@btinternet.com
To: ql-us...@q-v-d.com
Sent: Wed, 18 Nov 2009 23:09
Subject: Re: [Ql-Users] More BASIC Queries
I am grateful to all who have contributed to this thread. Your advice has been
taken on board and I now feel confident in re-writing my BOOT program(s). I
shall be working on the following premises:-
The BOOT program should be a number of small SuperBASIC programs each one
performing a specific simple task and linked to the next one using the LRUN
command. This is to ensure that the whole of the BOOT process is carried out by
Job0. (I understand that when a SB program is LOADed it becomes resident in
memory and is allocated Job0. If another SB program (say BOOT2) is then
called at the end of BOOT, then BOOT is deleted from memory and is replaced
by BOOT2 and being then resident, BOOT2 becomes Job0 - and so on with
BOOT3, BOOT4 etc) I think that my BOOT sequence would look something like
this:-
BOOT - Choose the Operating System required and load same. (QDOS OR SMSQ) [if
QDOS is selected then do nothing since QDOS is the native OS whereas if SMSQ is
selected, LRESPR SMSQ_GOLD) - LRUN BOOT2
BOOT2 - check whether the required toolkits and extensions are loaded
(LRESPRd) and if not, load (LRESPR) them generally in line with the sequence
advised by Dilwyn (FROM Job0!!). LRUN BOOT3
BOOT3 - Check and adjust time and date if required. LRUN BOOT4
BOOT4 - Offer a menu of programs available within my 'system' - i.e. {A}
Genealogy (database manipulation, building Family Trees, Write details of
family members as a Word Processor Document - ours is a family HISTORY project
rather than just a family TREE). {B} QUANTA Membership records (Membership
address database, Mailing labels programs etc), {C}. etc. ...{R} Return to
the command line in whichever OS is current. LRUN or EX the file(s) associated
with the selection OR restore any windows, and other user settings etc to
switch-on state and STOP.
Queries:- on my QLs (Aurora, SGC, QuBide, etc.) TK2 is loaded automatically
at power-on (AUTOTK2F1 command), the file BOOT is located, LOADed and runs
automatically. Are the EXTRAS within TK2 LRESPRd in the same manner as if TK2
were LRESPRd from either the command line or from within a boot program? OR are
they 'loaded' some other way which may cause some or all of them to go missing?
LRESPR SMSQ_GOLD causes the machine to RESET following which it
initialises again. Does this RESET remove TK2 from memory and is TK2 then
automatically reloaded again? File BOOT is then run again and only LRUNs
BOOT2 (since AFAIK there is no way of changing from SMSQ to QDOS without
manually RESETing the machine). Since it obviously takes some time to activate
TK2 (automatically or otherwise) would it be quicker to load TK2 along with all
the other required extension (in BOOT2) provided no TK2 EXTRAS are required
before then?
When a SB program is EXECd (from SMSQ) I have noticed that it too
becomes resident in the same way as an LRUN SB program. Does this mean that the
EXECd program also becomes Job0?
Can anyone see why this sequence of programs {which I am confident will
run on both QDOS and SMSQ on the Auroras} should not run exactly the same under
QPC2 on my Vista PCs? (which is the original point I raised with my existing
programs).
And if no one wants to put together an article for the magazine, I may even
have a shot myself. Thanks for all the material for this.
Finally, I am surprised that no one has yet written a RELIABLE version of
EXTRAS as a stand alone tool to enable the name list to be investigated - or
perhaps they have? If it was called EXTRAS would it overwrite the TK2
EXTRAS?
Cheers for now,
John Gilpin.
gdgqler wrote:
On 17 Nov 2009, at 21:34, Dilwyn Jones wrote:
Also, in one of my past articles, I wrote about the Name List in
SuperBasic (QL Today I mean) and gave a demo of how to list everything
in the name list.
Might help?
Turbo Toolkit also has a function to help step through name table
entries, I think I used it in my Basic Reporter program. Could be used to
write your own EXTRAS perhaps.
Turbo Toolkit has the function BASIC_INDEX%(name$). This gives the position
of the keyword name$ in the BASIC Table if present. If the keyword is not
present it returns -12 which is invalid name. This is a useful way
Re: [Ql-Users] More BASIC Queries
On 17 Nov 2009, at 21:34, Dilwyn Jones wrote: Also, in one of my past articles, I wrote about the Name List in SuperBasic (QL Today I mean) and gave a demo of how to list everything in the name list. Might help? Turbo Toolkit also has a function to help step through name table entries, I think I used it in my Basic Reporter program. Could be used to write your own EXTRAS perhaps. Turbo Toolkit has the function BASIC_INDEX%(name$). This gives the position of the keyword name$ in the BASIC Table if present. If the keyword is not present it returns -12 which is invalid name. This is a useful way of finding if an extension keyword is loaded. The string for name$ must have the correct case (usually upper). George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
I am grateful to all who have contributed to this thread. Your advice
has been taken on board and I now feel confident in re-writing my BOOT
program(s). I shall be working on the following premises:-
The BOOT program should be a number of small SuperBASIC programs each
one performing a specific simple task and linked to the next one using
the LRUN command. This is to ensure that the whole of the BOOT process
is carried out by Job0. (I understand that when a SB program is LOADed
it becomes resident in memory and is allocated Job0. If another SB
program (say BOOT2) is then called at the end of BOOT, then BOOT is
deleted from memory and is replaced by BOOT2 and being then resident,
BOOT2 becomes Job0 - and so on with BOOT3, BOOT4 etc) I think that
my BOOT sequence would look something like this:-
BOOT - Choose the Operating System required and load same. (QDOS OR
SMSQ) [if QDOS is selected then do nothing since QDOS is the native OS
whereas if SMSQ is selected, LRESPR SMSQ_GOLD) - LRUN BOOT2
BOOT2 - check whether the required toolkits and extensions are loaded
(LRESPRd) and if not, load (LRESPR) them generally in line with the
sequence advised by Dilwyn (FROM Job0!!). LRUN BOOT3
BOOT3 - Check and adjust time and date if required. LRUN BOOT4
BOOT4 - Offer a menu of programs available within my 'system' - i.e.
{A} Genealogy (database manipulation, building Family Trees, Write
details of family members as a Word Processor Document - ours is a
family HISTORY project rather than just a family TREE). {B} QUANTA
Membership records (Membership address database, Mailing labels programs
etc), {C}. etc. ...{R} Return to the command line in whichever OS is
current. LRUN or EX the file(s) associated with the selection OR restore
any windows, and other user settings etc to switch-on state and STOP.
Queries:- on my QLs (Aurora, SGC, QuBide, etc.) TK2 is loaded
automatically at power-on (AUTOTK2F1 command), the file BOOT is
located, LOADed and runs automatically. Are the EXTRAS within TK2
LRESPRd in the same manner as if TK2 were LRESPRd from either the
command line or from within a boot program? OR are they 'loaded' some
other way which may cause some or all of them to go missing?
LRESPR SMSQ_GOLD causes the machine to RESET following which
it initialises again. Does this RESET remove TK2 from memory and is TK2
then automatically reloaded again? File BOOT is then run again and
only LRUNs BOOT2 (since AFAIK there is no way of changing from SMSQ to
QDOS without manually RESETing the machine). Since it obviously takes
some time to activate TK2 (automatically or otherwise) would it be
quicker to load TK2 along with all the other required extension (in
BOOT2) provided no TK2 EXTRAS are required before then?
When a SB program is EXECd (from SMSQ) I have noticed that it
too becomes resident in the same way as an LRUN SB program. Does this
mean that the EXECd program also becomes Job0?
Can anyone see why this sequence of programs {which I am
confident will run on both QDOS and SMSQ on the Auroras} should not run
exactly the same under QPC2 on my Vista PCs? (which is the original
point I raised with my existing programs).
And if no one wants to put together an article for the magazine, I may
even have a shot myself. Thanks for all the material for this.
Finally, I am surprised that no one has yet written a RELIABLE version
of EXTRAS as a stand alone tool to enable the name list to be
investigated - or perhaps they have? If it was called EXTRAS would it
overwrite the TK2 EXTRAS?
Cheers for now,
John Gilpin.
gdgqler wrote:
On 17 Nov 2009, at 21:34, Dilwyn Jones wrote:
Also, in one of my past articles, I wrote about the Name List in
SuperBasic (QL Today I mean) and gave a demo of how to list everything
in the name list.
Might help?
Turbo Toolkit also has a function to help step through name table entries, I
think I used it in my Basic Reporter program. Could be used to write your own
EXTRAS perhaps.
Turbo Toolkit has the function BASIC_INDEX%(name$). This gives the position of the
keyword name$ in the BASIC Table if present. If the keyword is not present it returns -12
which is invalid name. This is a useful way of finding if an extension
keyword is loaded. The string for name$ must have the correct case (usually upper).
George
___
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] More BASIC Queries
Having read all the contributions to this thread, I haver decided to re-invent the wheel and start my programs from scratch, testing each section on all the platforms I expect to run it from as I go. François wrote that EXTRAS is not a reliable method of seeing whether an extension is loaded or not. All the alternatives offered seem to examine whether a specific keyword is loaded or not (FINDNAME%, EXISTS etc) - which does not provide a list of loaded 'keywords' like EXTRAS does. Is there a reliable way of listing all the 'extras' currently loaded and is there a way of getting a list of 'extras' each extension should load - say from the .bin file that is being LRESPRd?. This would be useful in determining whether an extension will overwrite a particular entry already loaded. Is there a recognised sequence that extensions should be loaded in? - i.e. TK2 before Menu_rext. Is there a way of getting say EXTRAS loaded without loading all the other 400+ 'keywords' contained in TK2? If this level of question is already covered in some document (book etc- How to write a BOOT program in SuperBASIC), could someone please point me in that direction to save you all re-inventing the wheel with me. How do I decide which extensions should be LRESPRd and which left out without the painstaking method of leave it out and if the program doesn't work, add it later I am most grateful for you comments and advice. Regards to all, John Gilpin. François Van Emelen wrote: P Witte schreef: Marcel Kilgus wrote: François Van Emelen wrote: Of course this is only true for extensions/toolkits loaded in Job 0. Yes, forgot to say that. Extensions/toolkits loaded in another Job are only available in that job. 'EXTRAS' doesn't always show all the available keywords. A bug or a feature? This was a feature on QDOS based machine (EXTRAS does not list any keywords in ROM, as only the extras should be shown) which turned into a bug on SMSQ/E based machines (there it was not guaranteed that new keywords are not in the ROM address area). I fixed that in v2f99. Unless he is refering to the feature that EXTRAS in SBasic daughters only displays keywords once they have actually been used. And that includes ALL non-language keywords (ie INPUT, but not REPeat, etc) Quite neat really, but I cant remember why ;o) Yes, that is what I was referring to. Thus 'Extras' is not a reliable method to find out whether an extension is already loaded or not. 'FINDNAME%' is probably more reliable. François Van Emelen Per ___ 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] More BASIC Queries
Is there a recognised sequence that extensions should be loaded in? - i.e. TK2 before Menu_rext. 1. Lightning or Speedscreen (if used) 2. TK2 3. Pointer environment (ptr_gen, wman, hot_rext in that order) 4. menu_rext 5. other extensions 6. after all extensions loaded, HOT_GO to activate hotkey job 7. anything else Some people might tell you to swap steps 1 and 2 above. Apart from Lightning/Speedscreen-TK2-ptr_gen-wman-hot-rext-menu_rext-others in that order, there is generally no fixed order. Some toolkits might say in their documentation they have to be loaded before or after specific extensions, but these are rare and most are just covered by step 7. Of course, if you are soft-loading SMSQ/E (e.g. Gold Card/SGC/Aurora smsqe on QemuLator), SMSQ/E comes first using a line like IF VER$'HBA' THEN LRESPR SMSQ_REXT to prevent double loading, although some versions of SMSQ/E were known to check if already present, though I can't remember which versions. SMSQE includes all TK2 extensions and pointer environment and Lightning/Speedscreen generally aren't used with SMSQ/E, so 1 and 2 don't apply for smsq/e and 3 only applies if installing smsqe. If this level of question is already covered in some document (book etc- How to write a BOOT program in SuperBASIC), could someone please point me in that direction to save you all re-inventing the wheel with me. AFAIK, not in any book unless it's in Rich Mellor's big reference books whose name escapes me right now :-( A gap in the market for someone to exploit! These days we can publish books electronically as PDFs quite cheaply. There are even sites like Lulu (IIRC) who will do short printrun specialist books for you. There's some general PE info on my website at http://www.dilwyn.me.uk/docs/ptr/index.html though I don't think there's much specifically about writing PE boot programs. QL Today have printed countless My BOOT type programs which might help. Find them using Brian Kemmett's QL Today index at http://www.dilwyn.me.uk/gen/qltoday/qltoday.html How do I decide which extensions should be LRESPRd and which left out without the painstaking method of leave it out and if the program doesn't work, add it later Generally speaking, look at the program's original BOOT file which will tell you if it loads specific extensions or not. With a bit of experience you can look at compiled basic programs in an editor and see a list of extensions used, and with a little bit more experience you might be able to find a list of included toolkits, those which have been built in using the $$asmb directive of QLiberator, or the equivalent Turbo %% directive. A couple of other tips for boot programs: 1. Don't use extensions in the same boot program as that which loads them - that work on version AH and JM ROMs. Instead, use the first program to load and install them. then chain a second program to use the extension. 2. Keeping a first boot program short and only installing extensions and defining hotkeys bfore chaining a second program to do the pretty screens etc makes it a lot easier to debug. 3. Use the One-At-A-Time method to debug problems like the ones you've had - if testing for an extension and it seems to fail, test for a different extension from another toolkit to see if the problem is specific to one toolkit or one extension. That way, you can isolate a problem. If a boot program seems to lock up or crash your machine, add or remove toolkits one at a time to find out which causes the problems. 4. LRESPR should not have this problem, but if the boot program uses RESPR statements, check that they use the right values. a duff respr statement not allocating enough space might seem to work, but sooner or later there'll be problems. Generally speaking, the RESPR value is the same as the FLEN of the toolkit file, although you should check the toolkit instructions concerned to make doubly sure this is the case just in case it needs a little extra workspace at the end of the file (very rare, and not really a good way of doign things). 5. Try to keep the flow of your boot programs logical - my boot programs tend to just do everything in a simple sequence without much by way of procedures and functions where I can avoid it. Generally speaking, that is, of course, sometimes you can't avoid it. 6. Above all, if having problems, mention them here. I've lost count of how many times I've had help on here and I consider myself a reasonably experienced user! QL-users is probably the single best source of help (and quickest) for us in this day and age. Above all I think John is right here, there is a need for a reference guide - it's surprising we're at 25-26 years of QLing and there isn't really a single reference source where all information for modern QL programming hasn't been thrown into one document! So: articles on this subject for Quanta mag defnitely welcome! Make John's day - send him an
Re: [Ql-Users] More BASIC Queries
In message 4b027da5.9030...@btinternet.com, John Gilpin thegilp...@btinternet.com writes Hi John, I think that you have started a very interesting discussion with your BOOT programs query. A - This is one of the advantages of the QL System - you can set up and write you own boot sequence. B - Or one of the disadvantages of the QL System - that there is no regular or standardised way of doing it. Depends which way you look at it . :-) I have certainly enjoyed all the numerous responses to your query. You seem to have developed, over time, a sort of SuperBoot; that then does all your setting up in one go. Although, that method is convenient. It is then can be more difficult to locate where any problems are. As many contributors have said, the alternative is to split your BOOT file in to a number of parts; which can then do more specific tasks individually. I have a small BOOT that first asks the user as to whether to boot from a win drive or a floppy ( the latter only now used very occasionally ). The usual choice is a win drive, which chains another BOOT file as : LRUN windrive$ '_myboot' MYBOOT is again, only a small amount of code, and gives another set of choices ( with LRUN ), to load specific extensions, etc. I also format a RAM disc at this point, and set the Data_use to Ram1_, and the Prog_use to Win1_ As well as to set dragable windows for SMSQ/E with - WM_MOVEMODE 2 The usual choice is chain BOOT_QDT - for the QL DeskTop - as well as setting up all of the LRESPR commands that are needed; together with the Environment Variables. This ends with : EX windrive$ 'QDT_BIN_QDT_EXE' I know that a lot of people have organised all of their QL extensions, etc, in to a SYSTEM folder, so that they are all together in one place; rather than being scattered around with different programs. Sort of depends is you are A or B ( above ) . :-) Having read all the contributions to this thread, I haver decided to re-invent the wheel and start my programs from scratch, testing each section on all the platforms I expect to run it from as I go. François wrote that EXTRAS is not a reliable method of seeing whether an extension is loaded or not. All the alternatives offered seem to examine whether a specific keyword is loaded or not (FINDNAME%, EXISTS etc) - which does not provide a list of loaded 'keywords' like EXTRAS does. Is there a reliable way of listing all the 'extras' currently loaded and is there a way of getting a list of 'extras' each extension should load - say from the .bin file that is being LRESPRd?. This would be useful in determining whether an extension will overwrite a particular entry already loaded. Is there a recognised sequence that extensions should be loaded in? - i.e. TK2 before Menu_rext. Is there a way of getting say EXTRAS loaded without loading all the other 400+ 'keywords' contained in TK2? If this level of question is already covered in some document (book etc- How to write a BOOT program in SuperBASIC), could someone please point me in that direction to save you all re-inventing the wheel with me. How do I decide which extensions should be LRESPRd and which left out without the painstaking method of leave it out and if the program doesn't work, add it later I am most grateful for you comments and advice. Regards to all, John Gilpin. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Thank you John for having these boot problems! And thanks to all those who have entered this discussion. As far as I am concerned, it's full of useful g0ooodies/reminders/tips etc.. Goodaye to all :0) John in Wales ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Op Tue, 17 Nov 2009 11:40:37 +0100 schreef John Gilpin thegilp...@btinternet.com: Is there a reliable way of listing all the 'extras' currently loaded and is there a way of getting a list of 'extras' each extension should load - say from the .bin file that is being LRESPRd?. This would be useful in determining whether an extension will overwrite a particular entry already loaded. There is a program ListNames.obj by Adrian Ives that will list all keywords in an extension file. Although I found it doesn't work on some of them. I can't recall where I picked it up from the net, probably Dilwyns site. Also HyperHelp from JMS will print all loaded keywords and it comes with text files for many of them, explaining the sytax (and I have added a few myself). I think Q-Help from Rich Mellor does a similar job, a bit differently. In my BOOT I create a log file of all the loaded extension files: --- chan=FOP_OVER(RAM1_extension_log) ... LRESPR extension1_bin: PRINT #chan;extension1_bin REM repeat for each one ... CLOSE #chan COPY_O ram1_extension_log TO win1_System_extension_log --- My BOOT file allows me to step trough the loading process to skip certain extensions for testing. Bob -- The BSJR QL software site at: http://members.chello.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
John Gilpin wrote: Is there a reliable way of listing all the 'extras' currently loaded and is there a way of getting a list of 'extras' each extension should load - say from the .bin file that is being LRESPRd?. This would be useful in determining whether an extension will overwrite a particular entry already loaded. There is no accurate way to determine which unique extensions will be loaded by any given toolkit, for mainly three reasons. 1. Extensions will overwrite any previous extension with the same name 2. A toolkit may selectively load only some extensions 3. Theoretically, (but unlikely) a toolkit could generate extension name(s) on the fly or alter the names of existing extensions! Using a program or editor to determine which extensions will be loaded may fail for the reasons above. Having said that, most toolkits are pretty straightforward, so only reason 1. above will apply. EXTRAS in job #0 is pretty reliable, except you cannot tell which keywords have been redefined. If you really need to know, youd have to load one toolkit at a time, dump the keyword list using EXTRAS, reboot and do the next. Then you could decide in which order to load the toolkits. Is there a recognised sequence that extensions should be loaded in? - i.e. TK2 before Menu_rext. Because of reason 1. given above, the order of toolkits loaded can be significant. One toolkit's PEEKS might do something completely different to another's. There is no general rule apart from testing to see what works. For the main toolkits, Id follow Dilwyn's advice, for any additional toolkits, load those that are required by the programs most important to you last! If you end up with a heart-rending conflict, youll have to resort to patching. But thats another topic ;o) Is there a way of getting say EXTRAS loaded without loading all the other 400+ 'keywords' contained in TK2? Ah, but you may need TK2 for many good reasons. Invisibly to the user, it redefines a number of existing internal keywords (such as CALL, DIR, DELETE, and many others). TK2 contains the LRESPR keyword we all find so useful, and it also contains many other useful non-keyword facilities, like bug fixes for the QL ROMs (I seem to recall). There are, however, lighter versions - and even a configurable version - out there (Dilwyn will know) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Evening all, Is there a way of getting say EXTRAS loaded without loading all the other 400+ 'keywords' contained in TK2? DJ_TOOLKIT has something in it to check if an extension is loaded - it's the CHECK() command (I think!!!) Also, in one of my past articles, I wrote about the Name List in SuperBasic (QL Today I mean) and gave a demo of how to list everything in the name list. Might help? Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Is there a way of getting say EXTRAS loaded without loading all
the
other 400+ 'keywords' contained in TK2?
DJ_TOOLKIT has something in it to check if an extension is loaded -
it's
the CHECK() command (I think!!!)
Yes, I use it quite a lot in my programs!
Something like IF CHECK('File_Select$') THEN PRINT Menu_Rext present
Also, in one of my past articles, I wrote about the Name List in
SuperBasic (QL Today I mean) and gave a demo of how to list
everything
in the name list.
Might help?
Turbo Toolkit also has a function to help step through name table
entries, I think I used it in my Basic Reporter program. Could be used
to write your own EXTRAS perhaps.
Dilwyn Jones
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Contrary to Per's comments, I am most grateful to the many people who have posted helpful advice regarding my recent BASIC problems in transferring some programs which I wrote many years ago from an Aurora, SGC, QuBide machine to QPC2 on my PCs. I am still investigating the disappearance of EXTRAS loaded from my BOOT program - a situation which only occurs in QPC2 (not on the Aurora machines). The offered solutions to my query about being able to step through the program are, as has been noted on this list, very slow and time consuming but I have attempted them in the hopes of identifying the error(s). In hindsight, what I had in mind, was something more along the lines of the trace facility found in PSION Archive and Xchange (archive) which I use extensively. From advice offered by contributors on this list, I am currently checking the full list of EXTRAS at various points in the program to see if the missing ones all disappear together or a few at a time at various points. I may well have a few VERY BASIC questions regarding the use of EXTRAS to do this, later today. Having said all this, I have to accept that the programs concerned do work well (the first time round) and it is only on the occasion when having closed a program I need to use it again that I find that without a full power-down and reBOOT the programs will not run due to missing extensions. I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Thank you all for your help and guidance. Regards, John Gilpin. P Witte wrote: giggler wrote: On 14 Nov 2009, at 16:04, P Witte wrote: The way the question was formulated, a line by line stepping through a program - specifically, a boot script - was wanted. This hardly adds to the responses already given, although its fine if only a few lines want monitoring. You can use QMON to step through an assembly program. But this is usually too time-consuming. It is better to go quickly to a specific place and step through a few instructions there. In aBASIC program it would be equally futile to examine the results of every single instruction. I think that it is the ability to examine each instruction which is wanted. I have certainly once or twice used my Puse after each instruction in a short stretch of code. Little point in us discussing it as the original petitioner seems to have found what he wanted and moved on to better things. Or perhaps hes still single-stepping through some endless loop his boot script! ;o) In which case your arguments certainly win the day! Per ___ 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] More BASIC Queries
Only poking you a bit, John. Nothing serious ;o) Id be more than happy to look at your boot script(s) to see if I can spot any obvious flaws. Sometimes all it takes is a new Per of I's Per John Gilpin wrote: Contrary to Per's comments, I am most grateful to the many people who have posted helpful advice regarding my recent BASIC problems in transferring some programs which I wrote many years ago from an Aurora, SGC, QuBide machine to QPC2 on my PCs. I am still investigating the disappearance of EXTRAS loaded from my BOOT program - a situation which only occurs in QPC2 (not on the Aurora machines). The offered solutions to my query about being able to step through the program are, as has been noted on this list, very slow and time consuming but I have attempted them in the hopes of identifying the error(s). In hindsight, what I had in mind, was something more along the lines of the trace facility found in PSION Archive and Xchange (archive) which I use extensively. From advice offered by contributors on this list, I am currently checking the full list of EXTRAS at various points in the program to see if the missing ones all disappear together or a few at a time at various points. I may well have a few VERY BASIC questions regarding the use of EXTRAS to do this, later today. Having said all this, I have to accept that the programs concerned do work well (the first time round) and it is only on the occasion when having closed a program I need to use it again that I find that without a full power-down and reBOOT the programs will not run due to missing extensions. I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Thank you all for your help and guidance. Regards, John Gilpin. P Witte wrote: giggler wrote: On 14 Nov 2009, at 16:04, P Witte wrote: The way the question was formulated, a line by line stepping through a program - specifically, a boot script - was wanted. This hardly adds to the responses already given, although its fine if only a few lines want monitoring. You can use QMON to step through an assembly program. But this is usually too time-consuming. It is better to go quickly to a specific place and step through a few instructions there. In aBASIC program it would be equally futile to examine the results of every single instruction. I think that it is the ability to examine each instruction which is wanted. I have certainly once or twice used my Puse after each instruction in a short stretch of code. Little point in us discussing it as the original petitioner seems to have found what he wanted and moved on to better things. Or perhaps hes still single-stepping through some endless loop his boot script! ;o) In which case your arguments certainly win the day! Per ___ 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 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
P Witte wrote: Only poking you a bit, John. Nothing serious ;o) Id be more than happy to look at your boot script(s) to see if I can spot any obvious flaws. Sometimes all it takes is a new Per of I's groan :-) I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Yes, that's correct. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
On 16 Nov 2009 at 9:14, John Gilpin wrote: ...I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Yes, PROVIDED the LRESPRing is done from job 0. I've similar problems to your over the years, and invariably found that they were caused by two problems: - either bad LRESPR (i.e. not LRESPRing from job 0) - or something wrong in the extension files themselves, (such the table for the SBasic keyword being set up wrongly, or the extensions having names that were too long). I would suggest the following course of action: Make one boot file, in which you load (LRESPR) ALL of the various extensions that ALL of your programs need. (L)RUN that from job 0. Take all of the LRESPR calls out of your programs (eg set a remark before them), since they are no longer needed. Tell us if the problems then still persist. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Folks, another cause of trouble could be: You're not LRESPRing, but instead something like a=RESPR(x):LBYTES mdv1_xxx.a With not enough space reserved (i.e. x too small). This will lead to all possible (and impossible) sorts of problems. Regards Tobias -Original Message- Date: Mon, 16 Nov 2009 12:34:43 +0100 Subject: Re: [Ql-Users] More BASIC Queries From: Wolfgang Lenerz w...@scp-paulet-lenerz.com To: ql-us...@q-v-d.com On 16 Nov 2009 at 9:14, John Gilpin wrote: ...I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Yes, PROVIDED the LRESPRing is done from job 0. I've similar problems to your over the years, and invariably found that they were caused by two problems: - either bad LRESPR (i.e. not LRESPRing from job 0) - or something wrong in the extension files themselves, (such the table for the SBasic keyword being set up wrongly, or the extensions having names that were too long). I would suggest the following course of action: Make one boot file, in which you load (LRESPR) ALL of the various extensions that ALL of your programs need. (L)RUN that from job 0. Take all of the LRESPR calls out of your programs (eg set a remark before them), since they are no longer needed. Tell us if the problems then still persist. Wolfgang ___ 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] More BASIC Queries
Marcel Kilgus schreef: P Witte wrote: Only poking you a bit, John. Nothing serious ;o) Id be more than happy to look at your boot script(s) to see if I can spot any obvious flaws. Sometimes all it takes is a new Per of I's groan :-) I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Yes, that's correct. Marcel Of course this is only true for extensions/toolkits loaded in Job 0. Extensions/toolkits loaded in another Job are only available in that job. 'EXTRAS' doesn't always show all the available keywords. A bug or a feature? François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Contrary to Per's comments, I am most grateful to the many people who have posted helpful advice regarding my recent BASIC problems in transferring some programs which I wrote many years ago from an Aurora, SGC, QuBide machine to QPC2 on my PCs. I am still investigating the disappearance of EXTRAS loaded from my BOOT program - a situation which only occurs in QPC2 (not on the Aurora machines). The offered solutions to my query about being able to step through the program are, as has been noted on this list, very slow and time consuming but I have attempted them in the hopes of identifying the error(s). In hindsight, what I had in mind, was something more along the lines of the trace facility found in PSION Archive and Xchange (archive) which I use extensively. From advice offered by contributors on this list, I am currently checking the full list of EXTRAS at various points in the program to see if the missing ones all disappear together or a few at a time at various points. I may well have a few VERY BASIC questions regarding the use of EXTRAS to do this, later today. Having said all this, I have to accept that the programs concerned do work well (the first time round) and it is only on the occasion when having closed a program I need to use it again that I find that without a full power-down and reBOOT the programs will not run due to missing extensions. I thought that once loaded (LRESPRd), toolkits etc remained loaded until the machine was powered-down. Do I have this BASIC premise correct? Thank you all for your help and guidance. Regards, John Gilpin. I had a look at John's boot program but lack of time prevents me from taking a very detailed look. Basically, his program revolves around code like: Get_Value_Of_Loaded% IF NOT loaded% THEN LRESPR various extensions END IF He checks the value of loaded% by sending the output of EXTRAS to a file, then reading it in line by line until he finds the Q_Liberator extension Q_L, something like loaded%=0 rep loop input #chan%,extn$ IF extn$='Q_L' THEN loaded%=1 EXIT loop end rep loop (all this from memory, not from his code, but the gist of it is there) The idea behind IF NOT loaded% THEN of course is to allow the boot program to do its other work without attempting to install extensions twice. This isn't something I'd normally do in my programs, I'd split the boot into two, the first installing the extensions, then chaining a second one to do the other work, so the second program could run without having to deal with the extensions issue. A simple change to check for anything going wrong with a particular extension or set of extensions is to change which extension namke he looks for, or even check for an extension in each of the dozen or so toolkits he loads to see if one toolkit in particular is causing the problem, adding temporary test lines like: 3230 INPUT #chan%,extn$ 3231 IF extn$ = THEN PRINTThis extension loaded 3232 IF extn$ = THEN PRINT That extension loaded and so on. A bit clumsy, but should help to isolate which extensions exactly are going missing. With a fairly long and complex boot program like this it is probably better to revert to first principles and isolate the part causing the error, i.e. loaded% is expected to be 1 on the second run, if not, why not? With such a complex boot program, better to write a second version as a test rig and just include the bits of code which are going wrong. A snag while testing was that he installs a dozen or so files with LRESPR, and I only have about 7 of those, meaning I couldn't fully test it out to rule out all possibilities. The reason why John got the specific error message at line 210 of his program is simply that MENU_REXT checks if it is being installed twice. But that doesn't of course explain why the Q_L extension is not being found when he looks for it, unless it's something to do with the order of QLiberator files being installed or something like that. Anyone looking at his program, check line 3170 where he sends the EXTRAS to a file, then opens that file for reading without closing it, which runs the risk of the file not being fully flushed: 3170 EXTRAS #chan% 3180 OPEN_IN #chan%,ram1_load_extns (better to add a CLOSE #chan% to line 3170, or even wind the file position pointer back to 0 without the OPEN_IN. (Just trying to save someone a bit of work when they take a detailed look at the program) Dilwyn Jones P.S. Congratulations John, the new white Quanta mag envelopes got through the post without being damaged ... the first for months not to be damaged in post! ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
François Van Emelen wrote: Of course this is only true for extensions/toolkits loaded in Job 0. Yes, forgot to say that. Extensions/toolkits loaded in another Job are only available in that job. 'EXTRAS' doesn't always show all the available keywords. A bug or a feature? This was a feature on QDOS based machine (EXTRAS does not list any keywords in ROM, as only the extras should be shown) which turned into a bug on SMSQ/E based machines (there it was not guaranteed that new keywords are not in the ROM address area). I fixed that in v2f99. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Marcel Kilgus schreef: François Van Emelen wrote: Of course this is only true for extensions/toolkits loaded in Job 0. Yes, forgot to say that. Extensions/toolkits loaded in another Job are only available in that job. 'EXTRAS' doesn't always show all the available keywords. A bug or a feature? This was a feature on QDOS based machine (EXTRAS does not list any keywords in ROM, as only the extras should be shown) which turned into a bug on SMSQ/E based machines (there it was not guaranteed that new keywords are not in the ROM address area). I fixed that in v2f99. Marcel What I meant is that you shouldn't rely an 'EXTRAS' to verify whether a keyword is available and consequently assume that an extension is 'loaded' or not. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Marcel Kilgus wrote: François Van Emelen wrote: Of course this is only true for extensions/toolkits loaded in Job 0. Yes, forgot to say that. Extensions/toolkits loaded in another Job are only available in that job. 'EXTRAS' doesn't always show all the available keywords. A bug or a feature? This was a feature on QDOS based machine (EXTRAS does not list any keywords in ROM, as only the extras should be shown) which turned into a bug on SMSQ/E based machines (there it was not guaranteed that new keywords are not in the ROM address area). I fixed that in v2f99. Unless he is refering to the feature that EXTRAS in SBasic daughters only displays keywords once they have actually been used. And that includes ALL non-language keywords (ie INPUT, but not REPeat, etc) Quite neat really, but I cant remember why ;o) Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Dilwyn Jones wrote: Contrary to Per's comments, I am most grateful to the many people who I had a look at John's boot program but lack of time prevents me from taking a very detailed look. Basically, his program revolves around code like: Sounds like the real problem here is one of complexity ;o) As others have already commented, all but the simplest boot files should be split into at least two files. One for loading the core components and another (or a choice of others) for the rest. (I use a third tier for the most dynamic components, such as default directory or win_drive selection. This is easily accessible from my Qascade Start Menu to pop straight up in an editor.) One of the problems is communicating between any secondary boot files and the primary one. This seems to be one of the issues here. There are many ways around it, and John's way of dumping EXTRAS to a file and parsing that file is valid, although perhaps somewhat slow and cumbersome. A quicker method might be for the primary boot file to create a status file on the fly and the secondaries to parse that instead. It should be a lot more concise and therefore quicker. However, there are a lot of toolkits that provide a way of checking whether keywords have been loaded, including my FINDNAME_BIN (258 bytes). Such a toolkit could be loaded by the primary, and the secondary boot script would use something like IF FINDNAME%(Q_L): DO_THIS: ELSE: DO_THAT (This works the same in daughter SBasics as in job#0, BTW) The problem with boot files is that they tend to grow and evolve, and as so much depends on these increasingly tweaked and convoluted creations, one finds it hard to tidy them up or start again from scratch. If you spend more than an hour or so trying to debug one, it is perhaps time to start afresh! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Dilwyn Jones wrote:
The reason why John got the specific error message at line 210 of his
program is simply that MENU_REXT checks if it is being installed twice.
But that doesn't of course explain why the Q_L extension is not being
found when he looks for it, unless it's something to do with the order
of QLiberator files being installed or something like that.
Another technique for communicating between boot files is to let the
primary boot write to the secondary directly. No parsing required!
BOOT1:
optionally lrespr Prowess and set pws flag accordingly
optionally lrespr Wman/ptrgen and set pe flag accordingly
..
..
c = fopen('flp1_BOOT2')
if pws: print#c; '1 pws = 1': else: print#c; '1 pws = 0'
if pe: print#c; '2 pe = 1': else: print#c; '2 mpe = 0'
..
close#c
..
lrun flp1_BOOT2
BOOT2:
1 pws = 0
2 pe = 0
..
..
120 if pws then
130 do_this
140 else
150 if pe then
160 do_that
170 end
180 end
..
per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
P Witte schreef: Marcel Kilgus wrote: François Van Emelen wrote: Of course this is only true for extensions/toolkits loaded in Job 0. Yes, forgot to say that. Extensions/toolkits loaded in another Job are only available in that job. 'EXTRAS' doesn't always show all the available keywords. A bug or a feature? This was a feature on QDOS based machine (EXTRAS does not list any keywords in ROM, as only the extras should be shown) which turned into a bug on SMSQ/E based machines (there it was not guaranteed that new keywords are not in the ROM address area). I fixed that in v2f99. Unless he is refering to the feature that EXTRAS in SBasic daughters only displays keywords once they have actually been used. And that includes ALL non-language keywords (ie INPUT, but not REPeat, etc) Quite neat really, but I cant remember why ;o) Yes, that is what I was referring to. Thus 'Extras' is not a reliable method to find out whether an extension is already loaded or not. 'FINDNAME%' is probably more reliable. François Van Emelen Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
On 14 Nov 2009, at 16:04, P Witte wrote: The way the question was formulated, a line by line stepping through a program - specifically, a boot script - was wanted. This hardly adds to the responses already given, although its fine if only a few lines want monitoring. You can use QMON to step through an assembly program. But this is usually too time-consuming. It is better to go quickly to a specific place and step through a few instructions there. In aBASIC program it would be equally futile to examine the results of every single instruction. I think that it is the ability to examine each instruction which is wanted. I have certainly once or twice used my Puse after each instruction in a short stretch of code. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
giggler wrote: On 14 Nov 2009, at 16:04, P Witte wrote: The way the question was formulated, a line by line stepping through a program - specifically, a boot script - was wanted. This hardly adds to the responses already given, although its fine if only a few lines want monitoring. You can use QMON to step through an assembly program. But this is usually too time-consuming. It is better to go quickly to a specific place and step through a few instructions there. In aBASIC program it would be equally futile to examine the results of every single instruction. I think that it is the ability to examine each instruction which is wanted. I have certainly once or twice used my Puse after each instruction in a short stretch of code. Little point in us discussing it as the original petitioner seems to have found what he wanted and moved on to better things. Or perhaps hes still single-stepping through some endless loop his boot script! ;o) In which case your arguments certainly win the day! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
On 8 Nov 2009, at 09:44, John Gilpin wrote: Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? The way I debug BASIC programs is to use a routine called Puse, which causes a pause. DEFine PROCedure Puse LOcal a$(2) OPEN#20,con a$=INKEY$(#20,-1) CLOSE#20 END DEFine By placing this inside the program I can see what's happening. For example 2000 Fling: REMark some procedure 2005 Puse:PRINT Line 2000:Puse allows me to see if I have gone past line 2000. Pressing any key allows the program to continue (to the next Puse). You can add a PRINT facility to Puse by: DEFine PROCedure(b$) . . PRINT#20,b$ . . END DEFine This works well even inside compiled BASIC programs. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
gdgqler wrote, On 14/11/09 08:15: On 8 Nov 2009, at 09:44, John Gilpin wrote: Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? The way I debug BASIC programs is to use a routine called Puse, which causes a pause. DEFine PROCedure Puse LOcal a$(2) OPEN#20,con a$=INKEY$(#20,-1) CLOSE#20 END DEFine By placing this inside the program I can see what's happening. For example 2000 Fling: REMark some procedure 2005 Puse:PRINT Line 2000:Puse allows me to see if I have gone past line 2000. Pressing any key allows the program to continue (to the next Puse). You can add a PRINT facility to Puse by: DEFine PROCedure(b$) . . PRINT#20,b$ . . END DEFine This works well even inside compiled BASIC programs. ... and of course further de-bugging info could be added, like printing critical global variables each time. 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] More BASIC Queries
Op Sat, 14 Nov 2009 09:46:47 +0100 schreef Tony Firshman t...@firshman.co.uk: gdgqler wrote, On 14/11/09 08:15: The way I debug BASIC programs is to use a routine called Puse, which causes a pause. ... and of course further de-bugging info could be added, like printing critical global variables each time. Tony I combine the two suggestions into one T(est)PAUSE procedure. Making use of the fact that Qmenu is always present in my QL's. At various points in the SBasic I put a call like: TPAUSE title$,message$ Where title$ identifies the Proc/Fn I'am coming from and message$ can be something like: var a$: a$ ... DEF PROC TPAUSE (t$,m$) y%=ITEM_SELECT(t$,m$,'OK') END DEF Bob -- The BSJR QL software site at: http://members.chello.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
gdgqler wrote:
On 8 Nov 2009, at 09:44, John Gilpin wrote:
Is there a way of stepping through a BASIC program, line by line, for debugging
purposes? If so how?
The way I debug BASIC programs is to use a routine called Puse, which causes a
pause.
DEFine PROCedure Puse
LOcal a$(2)
OPEN#20,con
a$=INKEY$(#20,-1)
CLOSE#20
END DEFine
By placing this inside the program I can see what's happening. For example
2000 Fling: REMark some procedure
2005 Puse:PRINT Line 2000:Puse
allows me to see if I have gone past line 2000. Pressing any key allows the
program to continue (to the next Puse).
The way the question was formulated, a line by line stepping through
a program - specifically, a boot script - was wanted. This hardly adds
to the responses already given, although its fine if only a few lines
want monitoring.
To your example I venture to suggest the following improvement:
DEFine PROCedure Puse(l%)
LOcal c%
c% = FOPEN('con_')
PRINT#c%; 'Line'! l%
or
LIST#c%; l%: rem Unless compiled, of course
PAUSE#c%; -1
CLOSE#c%
END DEFine
Call with
2005 Puse 2000
You can add a PRINT facility to Puse by:
DEFine PROCedure(b$)
.
.
PRINT#20,b$
.
.
END DEFine
This works well even inside compiled BASIC programs.
Actually,
DEFine PROCedure(b$)
doesnt work at all ;o) Probably just a ruse to see if anyone was
paying attention.
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
Tony Firshman wrote: gdgqler wrote, On 14/11/09 08:15: On 8 Nov 2009, at 09:44, John Gilpin wrote: Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? The way I debug BASIC programs is to use a routine called Puse, which causes a pause. DEFine PROCedure Puse LOcal a$(2) OPEN#20,con a$=INKEY$(#20,-1) CLOSE#20 END DEFine By placing this inside the program I can see what's happening. For example 2000 Fling: REMark some procedure 2005 Puse:PRINT Line 2000:Puse allows me to see if I have gone past line 2000. Pressing any key allows the program to continue (to the next Puse). You can add a PRINT facility to Puse by: DEFine PROCedure(b$) . . PRINT#20,b$ . . END DEFine This works well even inside compiled BASIC programs. ... and of course further de-bugging info could be added, like printing critical global variables each time. Right you are. I miss Minerva SuperBasic's watch variable facility, eg: 120 WHEN x 10: PRINT X is now too big! .. 130 FOR x = 5 TO 12: PRINT x will print 5 6 7 8 9 10 X is now too big! 11 X is now too big! 12 Pity it didnt make it into SBasic Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
At 08:15 14/11/2009 +, you wrote: Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? Lawrence gave us SSTEP etc, does it work without Minerva ? ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
P Witte wrote:
John Gilpin wrote:
Is there a way of stepping through a BASIC program, line by line, for
debugging purposes? If so how?
You could try something like this:
I wrote a somewhat more sophisticated trace program in the early days,
but it relies on the SuperBasic variables to do its stuff. That no
longer works in SBasic. So, just because I felt like it, I wrote a new
version this evening. It is very simplistic, but should be adequate
for testing simple boot scripts and the like. Alter to suit your style:
100 REMark Simple TRACE V3.00
110 REMark pjwitte 20091109
120 :
130 inp$ = 'win1_someprogram_bas'
140 oup$ = 'ram1_test_bas'
150 c% = 0: REMark Trace channel
160 t% = -1: REMark Timeout
170 :
180 ci% = FOP_IN(inp$): ERT ci%
190 co% = FOP_OVER(oup$): ERT co%
200 :
210 REPeat
220 IF EOF(#ci%): EXIT
230 INPUT#ci%; l$
240 l% = l$
250 s% = (' ' INSTR l$)
260 l$ = l$(s% + 1 TO)
270 IF OK THEN
280 PRINT#co%; l%! 'T.'! l%; ':'! l$
290 ELSE
300 PRINT#co%; l%! l$
310 END IF
320 END REPeat
330 :
340 PRINT#co%; l% + 1! 'STOP: REMark TRACE'
350 PRINT#co%; l% + 2! 'DEFine PROCedure T.(n%)'
360 PRINT#co%; l% + 3! 'LIST#'; c%; '; n% : PAUSE'! t%
370 PRINT#co%; l% + 4! 'END DEFine T.'
380 CLOSE
390 :
400 DEFine FuNction OK
410 IF ('def ' INSTR l$) = 1: RETurn 0
420 IF ('define ' INSTR l$) = 1: RETurn 0
430 IF ('loc ' INSTR l$) = 1: RETurn 0
440 IF ('local ' INSTR l$) = 1: RETurn 0
450 RETurn 1
460 END DEFine OK
470 :
NB! Only SBasic accepts procedures and variables containing a dot, so
alter accordingly for SuperBasic!
To test it try using the program as its own input!
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
John Gilpin wrote: And here's yet another one for you:- Having LRESPRed various extensions in my Boot program, what would cause some or all of the resulting EXTRAS to disappear from the EXTRAS list? Having run the boot, I have checked the EXTRAS list and been happy that what I wanted is there. Then, after allowing the boot program to call the next program in the sequence using ex 'win1_next program.exe' which subsequently returns on completion, I find that re running the same boot program fails since some of EXTRAS are no longer there. What sort of error should I be looking for? Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? Regards, John Gilpin. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Hmm - only thing I can think of is that you may have used ALCHP instead of RESPR ? -- Rich Mellor RWAP Services http://www.rwapsoftware.co.uk http://www.rwapservices.co.uk -- Try out our new site: http://sellmyretro.com ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
John Gilpin wrote: And here's yet another one for you:- Having LRESPRed various extensions in my Boot program, what would cause some or all of the resulting EXTRAS to disappear from the EXTRAS list? Having run the boot, I have checked the EXTRAS list and been happy that what I wanted is there. Then, after allowing the boot program to call the next program in the sequence using ex 'win1_next program.exe' which subsequently returns on completion, I find that re running the same boot program fails since some of EXTRAS are no longer there. What sort of error should I be looking for? Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? Two possibilities, albeit remote ones, I can think of: 1. If other jobs were running (including hotkey job) and you used LRESPR to load the extensions, it would not be able to put the extensions into RESPR space, instead it uses the equivalent of ALCHP. When the job is finished, or a NEW issued (etc etc) the heap space might get cleared and extensions lost. Always best to LRESPR extensions before you start any other jobs, including SBASICs and Hotkey jobs (i.e. before a HOT_GO). 2. If you LRESPR an extension into a daughter SBASIC, they might be local to that job and vanished when that particular SBASIC is removed. There's a little info about this on the bottom of page 27 (in my version of the manual at least) of the SMSQ/E manual. Could you possibly send a few lines of your boot so we can see what's happening? Or send it to me privately off list? Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] More BASIC Queries
John Gilpin wrote: And here's yet another one for you:- Having LRESPRed various extensions in my Boot program, what would cause some or all of the resulting EXTRAS to disappear from the EXTRAS list? Having run the boot, I have checked the EXTRAS list and been happy that what I wanted is there. Then, after allowing the boot program to call the next program in the sequence using ex 'win1_next program.exe' which subsequently returns on completion, I find that re running the same boot Do you seriously mean RE running the same boot program after LRESPRing the extensions? Some extensions may not like being LRESPRed more than once! program fails since some of EXTRAS are no longer there. What sort of error should I be looking for? If you mean that you continue running the boot program after executing some other program, you may be looking at some dodgy extensions or corrupt files Is there a way of stepping through a BASIC program, line by line, for debugging purposes? If so how? You could try something like this: (assumes no gotos etc or RENUM source file first and save) set line_number% to 10 open_in#input file_to_debug open_new#output debug_file loop until end of input file: input#input line$ remove line number from line$ print#output: line_number%! list! line_number%! :pause:! line$ increment line_number% end loop close all Then run debug_file Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
