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] SMSQ Reference Manual and QPTR manual online
On 15 Nov 2009, at 19:21, P Witte wrote: iob.elin (trap#3, $4) was a terrible mess. I wrote to TT about it and he agreed, but I dont know it was ever fixed After several years I managed to get this trap to work. As far as I can tell it works perfectly. But the descriptions in the various manuals are not very clear. I now think it is in fact a good, almost essential, trap. George ___ 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
[Ql-Users] Envelope for Quanta Magazine - sorted
Hi, I have just received my Issue of the Quanta Magazine, in a white envelope, which has survived the rigours of the Post in the UK without any damage like slits along one side ... :-) -- Malcolm Cadman ___ 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
[Ql-Users] The best date...
Hi Summer 2010 an international QL-meeting will take place in Prottes (Austria - near to Vienna) Please help me, finding the best date for this performance (2-3 days) Interested people can tell me when they may have time to come (between end of june and end of august) Please use this link : http://www.doodle.com/cseb3py768aym9aq Please hurry up: the date may be defined at end of november. Gerhard ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
