Re: [Ql-Users] Lookup%
Hi, I personally would have no problem with adding a UQLX type into the SMSQE "keys_sys" file, at sys_mtyp (offset A7, as Per pointed out). Wolfgang > The bits in the SMSQmulator readme and QPC Keywords manuals that > describe the JVA_xxx/QPC_xxx keywords. > > EMU_EXIT, EMU_VER$, EMU_MINIMISE, EMU_NETNAME$, EMU_NETADDR$, > EMU_HOSTOS$ are things you might consider. It seems to me to make sense > to support the existing command set rather than invent parallel ones. > > Its a while since I used xQLx, so I may be talking through my hat here. > Back then it seemed to masquerade as a QL emulator with a few extras > thrown in. But it now seems to me to be a true alternative > platform/system in its own right. Maybe its time it came out of the > closet? In which case, and while youre at it, you may wish to confer > with Wolfgang about adding some bits and pieces to the system variables, > eg sys_mtyp, $00A7, and possibly others.. > > Per > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] Lookup%
I'm a bit late to this conversation so may be missing the point - there is some documentation regarding the use of the Machine system variables and functions on my website, at http://www.dilwyn.me.uk/docs/articles/index.html - scroll down to the Machine Type... articles. They're rather old so may be missing the most up to date information I suppose, but will give Graeme the basic info on how it's set up and used. Dilwyn On Tue, 6 Jul 2021 at 18:54, pjwitte via Ql-Users wrote: > On 06/07/2021 16:51, Graeme Gregory via Ql-Users wrote: > > > > On Tue, 6 Jul 2021, at 3:44 PM, pjwitte via Ql-Users wrote: > >> <> > >> If it were only that easy.. :o( > >> > >> I havent gone through all of it, but just a couple of things: > >> > >> MACHINE would be better for sorting out wots wot, except not all > >> systems implement it. However, you can get the same info directly from > >> the system variables. I dont have the details to hand, but Im sure > >> someone will produce them any moment now.. > >> > >> EMU_VER$ was a result of my nagging to get some semblance of > >> conformity across the various emulators (Why does each emulator have a > >> different command to do the same thing!) The idea was that EMU_xxx > >> would replace JVA_xxx and QPC_xxx and anything else like it. Sadly, > >> that didnt happen only SMSQmulator complied (but then still kept the > >> old JVA_xxx) However, one day QPC (and/or any other) may conform and > >> then BANG! goes your test for SMSQmulator. If you want to do it that > >> way, better target JVA_VER$. > >> > >> Just a wee logical slip up: You cant use FDEC$ unless either TK2 or > >> SMSQ/E (or some other toolkit I dont know about) are present. > >> > > I can add that to sQLux pretty easilly (the EMU_VER$) any documentation > I should read? > > > > Graeme > > The bits in the SMSQmulator readme and QPC Keywords manuals that > describe the JVA_xxx/QPC_xxx keywords. > > EMU_EXIT, EMU_VER$, EMU_MINIMISE, EMU_NETNAME$, EMU_NETADDR$, > EMU_HOSTOS$ are things you might consider. It seems to me to make > sense to support the existing command set rather than invent parallel > ones. > > Its a while since I used xQLx, so I may be talking through my hat > here. Back then it seemed to masquerade as a QL emulator with a few > extras thrown in. But it now seems to me to be a true alternative > platform/system in its own right. Maybe its time it came out of the > closet? In which case, and while youre at it, you may wish to confer > with Wolfgang about adding some bits and pieces to the system > variables, eg sys_mtyp, $00A7, and possibly others.. > > Per > > ___ > QL-Users Mailing List > ___ QL-Users Mailing List
Re: [Ql-Users] Lookup%
On 06/07/2021 16:51, Graeme Gregory via Ql-Users wrote: On Tue, 6 Jul 2021, at 3:44 PM, pjwitte via Ql-Users wrote: <> If it were only that easy.. :o( I havent gone through all of it, but just a couple of things: MACHINE would be better for sorting out wots wot, except not all systems implement it. However, you can get the same info directly from the system variables. I dont have the details to hand, but Im sure someone will produce them any moment now.. EMU_VER$ was a result of my nagging to get some semblance of conformity across the various emulators (Why does each emulator have a different command to do the same thing!) The idea was that EMU_xxx would replace JVA_xxx and QPC_xxx and anything else like it. Sadly, that didnt happen only SMSQmulator complied (but then still kept the old JVA_xxx) However, one day QPC (and/or any other) may conform and then BANG! goes your test for SMSQmulator. If you want to do it that way, better target JVA_VER$. Just a wee logical slip up: You cant use FDEC$ unless either TK2 or SMSQ/E (or some other toolkit I dont know about) are present. I can add that to sQLux pretty easilly (the EMU_VER$) any documentation I should read? Graeme The bits in the SMSQmulator readme and QPC Keywords manuals that describe the JVA_xxx/QPC_xxx keywords. EMU_EXIT, EMU_VER$, EMU_MINIMISE, EMU_NETNAME$, EMU_NETADDR$, EMU_HOSTOS$ are things you might consider. It seems to me to make sense to support the existing command set rather than invent parallel ones. Its a while since I used xQLx, so I may be talking through my hat here. Back then it seemed to masquerade as a QL emulator with a few extras thrown in. But it now seems to me to be a true alternative platform/system in its own right. Maybe its time it came out of the closet? In which case, and while youre at it, you may wish to confer with Wolfgang about adding some bits and pieces to the system variables, eg sys_mtyp, $00A7, and possibly others.. Per ___ QL-Users Mailing List
Re: [Ql-Users] Lookup%
On Tue, 6 Jul 2021, at 3:44 PM, pjwitte via Ql-Users wrote:
> On 06/07/2021 16:18, desin via Ql-Users wrote:
> > Am 06.07.21 um 15:07 schrieb Graeme Gregory via Ql-Users:
> >>
> >>
> >> On Tue, 6 Jul 2021, at 1:59 PM, desin via Ql-Users wrote:
> >>>
> I agree with Francois, using LOOKUP% as alternative for EXISTS.
> I use it a lot. It returns the place in the name table which can
> also be
> used to test for conflicting keywords if found out of place.
>
> Bob
>
> >>> on QDOS
> >>> Lookup% can not distinguish between
> >>> SCR_XLIM and SCRXLIM
> >>> http://www.dilwyn.me.uk/tk/scrxlim.zip
> >>>
> >>> if SCRXLIM_cde is loaded
> >>> print Lookup% ("SCR_XLIM") gives 160
> >>> print Lookup% ("SCRXLIM") gives 162
> >>>
> >>> conclusion
> >>> QDOS -> EXISTS_bin
> >>> SMSQE -> Function_code
> >>>
> >> That looks right to me, assuming uQLx based code.
> >>
> >> Lookup%(SCR_YLIM) will give 161 (its the last extension installed
> >> by uQLx), and SCRXLIM is the first user one at 162.
> >>
> >> Graeme
> >> ___
> >> QL-Users Mailing List
> >>
> >
> >
> > On the other hand; would it be safe to presume; for all Systems;
> > if SCR_XLIM is not present; the default screen resolution is used ?
> >
> > my reason is a simple system info
> > depends on
> > Exists_bin
> > scrxlim_cde
> >
> > CLS
> > PRINT
> > IF EXISTS ("EMU_VER$") : PRINT " SMSQmulator"
> > IF EXISTS ("QPC_EXIT") : PRINT " QPC2 "_ver$
> > IF EXISTS ("UQLX_RELEASE$"): PRINT " UQLX "_RELEASE$
> > smsqe% = 0 : min% = 0 : tk% = 0
> > IF "HBA" INSTR VER$ : smsqe% = 1
> > IF "JSL1" INSTR VER$ : min% = 1
> > IF EXISTS ("ED") : tk% = 1
> > IF smsqe% : PRINT " SMSQE " $ (1)
> > IF min% : PRINT " Minerva ROM "$ (1)
> > IF NOT min% AND NOT smsqe% : PRINT " ";VER$ &" ROM"
> > fr_mem%=FREE_MEM/1024
> > IF fr_mem% > 1024:PRINT " "$ (fr_mem%/1000,4,1) &" Mb free"
> > if fr_mem% <= 1024:PRINT " "_mem%&" Kb free"
> > if tk% and not smsqe% : PRINT " Toolkit2 enabled"
> > IF EXISTS ("HIS_USE") and not smsqe% : PRINT " History enabled"
> > IF exists ("PINFO") and not smsqe% : PRINT " Pointer enabled"
> > IF EXISTS ("RAM_USE") and not smsqe% : PRINT " Ramdisk enabled"
> > xx%=512:yy%=256
> > IF EXISTS ("SCR_XLIM"):xx%=SCR_XLIM :yy%=SCR_YLIM
> > IF EXISTS ("SCRXLIM") :xx%=SCRXLIM(0):yy%=SCRYLIM(0)
> > PRINT " Screen "%&"x"%
> >
> > Markus
>
> If it were only that easy.. :o(
>
> I havent gone through all of it, but just a couple of things:
>
> MACHINE would be better for sorting out wots wot, except not all
> systems implement it. However, you can get the same info directly from
> the system variables. I dont have the details to hand, but Im sure
> someone will produce them any moment now..
>
> EMU_VER$ was a result of my nagging to get some semblance of
> conformity across the various emulators (Why does each emulator have a
> different command to do the same thing!) The idea was that EMU_xxx
> would replace JVA_xxx and QPC_xxx and anything else like it. Sadly,
> that didnt happen only SMSQmulator complied (but then still kept the
> old JVA_xxx) However, one day QPC (and/or any other) may conform and
> then BANG! goes your test for SMSQmulator. If you want to do it that
> way, better target JVA_VER$.
>
> Just a wee logical slip up: You cant use FDEC$ unless either TK2 or
> SMSQ/E (or some other toolkit I dont know about) are present.
>
I can add that to sQLux pretty easilly (the EMU_VER$) any documentation I
should read?
Graeme
___
QL-Users Mailing List
Re: [Ql-Users] Lookup%
On 06/07/2021 16:18, desin via Ql-Users wrote:
Am 06.07.21 um 15:07 schrieb Graeme Gregory via Ql-Users:
On Tue, 6 Jul 2021, at 1:59 PM, desin via Ql-Users wrote:
I agree with Francois, using LOOKUP% as alternative for EXISTS.
I use it a lot. It returns the place in the name table which can
also be
used to test for conflicting keywords if found out of place.
Bob
on QDOS
Lookup% can not distinguish between
SCR_XLIM and SCRXLIM
http://www.dilwyn.me.uk/tk/scrxlim.zip
if SCRXLIM_cde is loaded
print Lookup% ("SCR_XLIM") gives 160
print Lookup% ("SCRXLIM") gives 162
conclusion
QDOS -> EXISTS_bin
SMSQE -> Function_code
That looks right to me, assuming uQLx based code.
Lookup%(SCR_YLIM) will give 161 (its the last extension installed
by uQLx), and SCRXLIM is the first user one at 162.
Graeme
___
QL-Users Mailing List
On the other hand; would it be safe to presume; for all Systems;
if SCR_XLIM is not present; the default screen resolution is used ?
my reason is a simple system info
depends on
Exists_bin
scrxlim_cde
CLS
PRINT
IF EXISTS ("EMU_VER$") : PRINT " SMSQmulator"
IF EXISTS ("QPC_EXIT") : PRINT " QPC2 "_ver$
IF EXISTS ("UQLX_RELEASE$"): PRINT " UQLX "_RELEASE$
smsqe% = 0 : min% = 0 : tk% = 0
IF "HBA" INSTR VER$ : smsqe% = 1
IF "JSL1" INSTR VER$ : min% = 1
IF EXISTS ("ED") : tk% = 1
IF smsqe% : PRINT " SMSQE " $ (1)
IF min% : PRINT " Minerva ROM "$ (1)
IF NOT min% AND NOT smsqe% : PRINT " ";VER$ &" ROM"
fr_mem%=FREE_MEM/1024
IF fr_mem% > 1024:PRINT " "$ (fr_mem%/1000,4,1) &" Mb free"
if fr_mem% <= 1024:PRINT " "_mem%&" Kb free"
if tk% and not smsqe% : PRINT " Toolkit2 enabled"
IF EXISTS ("HIS_USE") and not smsqe% : PRINT " History enabled"
IF exists ("PINFO") and not smsqe% : PRINT " Pointer enabled"
IF EXISTS ("RAM_USE") and not smsqe% : PRINT " Ramdisk enabled"
xx%=512:yy%=256
IF EXISTS ("SCR_XLIM"):xx%=SCR_XLIM :yy%=SCR_YLIM
IF EXISTS ("SCRXLIM") :xx%=SCRXLIM(0):yy%=SCRYLIM(0)
PRINT " Screen "%&"x"%
Markus
If it were only that easy.. :o(
I havent gone through all of it, but just a couple of things:
MACHINE would be better for sorting out wots wot, except not all
systems implement it. However, you can get the same info directly from
the system variables. I dont have the details to hand, but Im sure
someone will produce them any moment now..
EMU_VER$ was a result of my nagging to get some semblance of
conformity across the various emulators (Why does each emulator have a
different command to do the same thing!) The idea was that EMU_xxx
would replace JVA_xxx and QPC_xxx and anything else like it. Sadly,
that didnt happen only SMSQmulator complied (but then still kept the
old JVA_xxx) However, one day QPC (and/or any other) may conform and
then BANG! goes your test for SMSQmulator. If you want to do it that
way, better target JVA_VER$.
Just a wee logical slip up: You cant use FDEC$ unless either TK2 or
SMSQ/E (or some other toolkit I dont know about) are present.
Per
___
QL-Users Mailing List
Re: [Ql-Users] Lookup%
Hi,
I would do it the other way around. First check for "HBA" in vers$, if
it is that then you're on SMSQE and you can use the return from the
MACHINE function to find out what machine you're on.
Wolfgang
> On the other hand; would it be safe to presume; for all Systems;
> if SCR_XLIM is not present; the default screen resolution is used ?
>
> my reason is a simple system info
> depends on
> Exists_bin
> scrxlim_cde
>
> CLS
> PRINT
> IF EXISTS ("EMU_VER$") : PRINT " SMSQmulator"
> IF EXISTS ("QPC_EXIT") : PRINT " QPC2 "_ver$
> IF EXISTS ("UQLX_RELEASE$"): PRINT " UQLX "_RELEASE$
> smsqe% = 0 : min% = 0 : tk% = 0
> IF "HBA" INSTR VER$ : smsqe% = 1
> IF "JSL1" INSTR VER$ : min% = 1
> IF EXISTS ("ED") : tk% = 1
> IF smsqe% : PRINT " SMSQE " $ (1)
> IF min% : PRINT " Minerva ROM "$ (1)
> IF NOT min% AND NOT smsqe% : PRINT " ";VER$ &" ROM"
> fr_mem%=FREE_MEM/1024
> IF fr_mem% > 1024:PRINT " "$ (fr_mem%/1000,4,1) &" Mb free"
> if fr_mem% <= 1024:PRINT " "_mem%&" Kb free"
> if tk% and not smsqe% : PRINT " Toolkit2 enabled"
> IF EXISTS ("HIS_USE") and not smsqe% : PRINT " History enabled"
> IF exists ("PINFO") and not smsqe% : PRINT " Pointer enabled"
> IF EXISTS ("RAM_USE") and not smsqe% : PRINT " Ramdisk enabled"
> xx%=512:yy%=256
> IF EXISTS ("SCR_XLIM"):xx%=SCR_XLIM :yy%=SCR_YLIM
> IF EXISTS ("SCRXLIM") :xx%=SCRXLIM(0):yy%=SCRYLIM(0)
> PRINT " Screen "%&"x"%
>
> Markus
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List
Re: [Ql-Users] Lookup%
Am 06.07.21 um 15:07 schrieb Graeme Gregory via Ql-Users:
On Tue, 6 Jul 2021, at 1:59 PM, desin via Ql-Users wrote:
I agree with Francois, using LOOKUP% as alternative for EXISTS.
I use it a lot. It returns the place in the name table which can also be
used to test for conflicting keywords if found out of place.
Bob
on QDOS
Lookup% can not distinguish between
SCR_XLIM and SCRXLIM
http://www.dilwyn.me.uk/tk/scrxlim.zip
if SCRXLIM_cde is loaded
print Lookup% ("SCR_XLIM") gives 160
print Lookup% ("SCRXLIM") gives 162
conclusion
QDOS -> EXISTS_bin
SMSQE -> Function_code
That looks right to me, assuming uQLx based code.
Lookup%(SCR_YLIM) will give 161 (its the last extension installed by uQLx), and
SCRXLIM is the first user one at 162.
Graeme
___
QL-Users Mailing List
On the other hand; would it be safe to presume; for all Systems;
if SCR_XLIM is not present; the default screen resolution is used ?
my reason is a simple system info
depends on
Exists_bin
scrxlim_cde
CLS
PRINT
IF EXISTS ("EMU_VER$") : PRINT " SMSQmulator"
IF EXISTS ("QPC_EXIT") : PRINT " QPC2 "_ver$
IF EXISTS ("UQLX_RELEASE$"): PRINT " UQLX "_RELEASE$
smsqe% = 0 : min% = 0 : tk% = 0
IF "HBA" INSTR VER$ : smsqe% = 1
IF "JSL1" INSTR VER$ : min% = 1
IF EXISTS ("ED") : tk%= 1
IF smsqe% : PRINT " SMSQE " $ (1)
IF min%: PRINT " Minerva ROM "$ (1)
IF NOT min% AND NOT smsqe% : PRINT " ";VER$ &" ROM"
fr_mem%=FREE_MEM/1024
IF fr_mem% > 1024:PRINT " "$ (fr_mem%/1000,4,1) &" Mb free"
if fr_mem% <= 1024:PRINT " "_mem%&" Kb free"
if tk%and not smsqe% : PRINT " Toolkit2 enabled"
IF EXISTS ("HIS_USE") and not smsqe% : PRINT " History enabled"
IF exists ("PINFO") and not smsqe% : PRINT " Pointer enabled"
IF EXISTS ("RAM_USE") and not smsqe% : PRINT " Ramdisk enabled"
xx%=512:yy%=256
IF EXISTS ("SCR_XLIM"):xx%=SCR_XLIM :yy%=SCR_YLIM
IF EXISTS ("SCRXLIM") :xx%=SCRXLIM(0):yy%=SCRYLIM(0)
PRINT " Screen "%&"x"%
Markus
___
QL-Users Mailing List
Re: [Ql-Users] Lookup%
On Tue, 6 Jul 2021, at 1:59 PM, desin via Ql-Users wrote:
>
> > I agree with Francois, using LOOKUP% as alternative for EXISTS.
> > I use it a lot. It returns the place in the name table which can also be
> > used to test for conflicting keywords if found out of place.
> >
> > Bob
> >
> on QDOS
> Lookup% can not distinguish between
> SCR_XLIM and SCRXLIM
> http://www.dilwyn.me.uk/tk/scrxlim.zip
>
> if SCRXLIM_cde is loaded
> print Lookup% ("SCR_XLIM") gives 160
> print Lookup% ("SCRXLIM") gives 162
>
> conclusion
> QDOS -> EXISTS_bin
> SMSQE -> Function_code
>
That looks right to me, assuming uQLx based code.
Lookup%(SCR_YLIM) will give 161 (its the last extension installed by uQLx), and
SCRXLIM is the first user one at 162.
Graeme
___
QL-Users Mailing List
Re: [Ql-Users] Lookup%
I agree with Francois, using LOOKUP% as alternative for EXISTS.
I use it a lot. It returns the place in the name table which can also be
used to test for conflicting keywords if found out of place.
Bob
on QDOS
Lookup% can not distinguish between
SCR_XLIM and SCRXLIM
http://www.dilwyn.me.uk/tk/scrxlim.zip
if SCRXLIM_cde is loaded
print Lookup% ("SCR_XLIM") gives 160
print Lookup% ("SCRXLIM") gives 162
conclusion
QDOS -> EXISTS_bin
SMSQE -> Function_code
Markus
___
QL-Users Mailing List
Re: [Ql-Users] loopy bug
On 06/07/2021 14:13, Wolfgang Lenerz via Ql-Users wrote: Hi Per, an interesting pitfall, thanks for pointing that out. It does seem that Qlib sets the value of the repeat loop control variable to 0 at the start of the loop. Do you know how this fares on plain QDOS, not SMSQE? Regards Wolfgang I dont know if this has been documented anywhere, but Im putting it out here as it caused me some grief. It appears that Q-Liberator zeroes the loop variable on entry to a loop. The following demo, which is acceptable (although perhaps not very elegant) S*BASIC, will not work in the same way once compiled with Qlib. 100 loop = 3 110 cnt = 0 120 PRINT 'Start:'! loop, cnt 130 REPeat loop 140 PRINT loop, cnt 150 cnt = cnt + 1 160 IF cnt >= loop: EXIT loop 170 END REPeat loop 180 PRINT 'End:'! loop, cnt 190 PAUSE: QUIT In the Qlib-compiled version the loop is exited after a single run as the condition cnt >= loop is met immediately, to wit 1 >= 0 The worrying part of this is that while I was figuring out what was wrong, running an embedded routine like this many times, the system crashed due to memory corruption. Whether this was due to the SBASIC or Qlib compiled version I cant say right now. So just beware and keep on progging! NB: This works, though. As long as you start out with loop = 0 100 loop = 0 110 cnt = 3 120 PRINT 'Start:'! loop, cnt 130 REPeat loop 140 PRINT loop, cnt 150 loop = loop + 1 160 IF loop >= cnt: EXIT loop 170 END REPeat loop 180 PRINT 'End:'! loop, cnt 190 PAUSE: QUIT I tested it under Qdos JS and both loops work exactly like in Qlib! Minerva, as one might have guessed, behaves like SBASIC. Clearly the smarter approach (why forbid something when it doesnt matter, and which might even come in handy?) but since its not consistent across the board, its best avoided. Bob, Dilwyn: I only discovered this by chance, due to a spelling mistake. Per ___ QL-Users Mailing List
Re: [Ql-Users] loopy bug
Hi Per, an interesting pitfall, thanks for pointing that out. It does seem that Qlib sets the value of the repeat loop control variable to 0 at the start of the loop. Do you know how this fares on plain QDOS, not SMSQE? Regards Wolfgang > I dont know if this has been documented anywhere, but Im putting it out > here as it caused me some grief. > > It appears that Q-Liberator zeroes the loop variable on entry to a loop. > The following demo, which is acceptable (although perhaps not very > elegant) S*BASIC, will not work in the same way once compiled with Qlib. > > 100 loop = 3 > 110 cnt = 0 > 120 PRINT 'Start:'! loop, cnt > 130 REPeat loop > 140 PRINT loop, cnt > 150 cnt = cnt + 1 > 160 IF cnt >= loop: EXIT loop > 170 END REPeat loop > 180 PRINT 'End:'! loop, cnt > 190 PAUSE: QUIT > > In the Qlib-compiled version the loop is exited after a single run as > the condition cnt >= loop is met immediately, to wit 1 >= 0 > > The worrying part of this is that while I was figuring out what was > wrong, running an embedded routine like this many times, the system > crashed due to memory corruption. Whether this was due to the SBASIC or > Qlib compiled version I cant say right now. So just beware and keep on > progging! > > NB: This works, though. As long as you start out with loop = 0 > > 100 loop = 0 > 110 cnt = 3 > 120 PRINT 'Start:'! loop, cnt > 130 REPeat loop > 140 PRINT loop, cnt > 150 loop = loop + 1 > 160 IF loop >= cnt: EXIT loop > 170 END REPeat loop > 180 PRINT 'End:'! loop, cnt > 190 PAUSE: QUIT > > Per > > ___ > QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] loopy bug
I have encountered this before, but, like Bob said, assumed it was just a question of a new type of variable being set up. In other words, I assumed I was doing something wrong and simply avoided whatever was happening. Dilwyn On Tue, 6 Jul 2021, 11:55 Bob Spelten via Ql-Users, < ql-users@lists.q-v-d.com> wrote: > pjwitte via Ql-Users wrote: > > I dont know if this has been documented anywhere, but Im putting it out > > here as it caused me some grief. > > > > It appears that Q-Liberator zeroes the loop variable on entry to a loop. > > The following demo, which is acceptable (although perhaps not very > > elegant) S*BASIC, will not work in the same way once compiled with Qlib. > > > > 100 loop = 3 > > 110 cnt = 0 > > 120 PRINT 'Start:'! loop, cnt > > 130 REPeat loop > > 140 PRINT loop, cnt > > 150 cnt = cnt + 1 > > 160 IF cnt >= loop: EXIT loop > > 170 END REPeat loop > > 180 PRINT 'End:'! loop, cnt > > 190 PAUSE: QUIT > > > > In the Qlib-compiled version the loop is exited after a single run as > > the condition cnt >= loop is met immediately, to wit 1 >= 0 > > > > The worrying part of this is that while I was figuring out what was > > wrong, running an embedded routine like this many times, the system > > crashed due to memory corruption. Whether this was due to the SBASIC or > > Qlib compiled version I cant say right now. So just beware and keep on > > progging! > > > > NB: This works, though. As long as you start out with loop = 0 > > > > 100 loop = 0 > > 110 cnt = 3 > > 120 PRINT 'Start:'! loop, cnt > > 130 REPeat loop > > 140 PRINT loop, cnt > > 150 loop = loop + 1 > > 160 IF loop >= cnt: EXIT loop > > 170 END REPeat loop > > 180 PRINT 'End:'! loop, cnt > > 190 PAUSE: QUIT > > > > Not that I have ever had this problem but when using a REPeat variable > as a value I've always made sure it was only used within the Loop. > > In the Name Table a simple variable is marked differently ($0202) from a > REPeat index ($0602), the question is who is doing it right? > When Qlib encounters the 2nd 'loop' it probably sets up a new zero entry > with the same name. > > In your second example the first 'loop = 0' is most likely not relevant. > > Bob > > > -- > Deze e-mail is gecontroleerd op virussen door AVG. > http://www.avg.com > > ___ > QL-Users Mailing List ___ QL-Users Mailing List
Re: [Ql-Users] loopy bug
pjwitte via Ql-Users wrote: I dont know if this has been documented anywhere, but Im putting it out here as it caused me some grief. It appears that Q-Liberator zeroes the loop variable on entry to a loop. The following demo, which is acceptable (although perhaps not very elegant) S*BASIC, will not work in the same way once compiled with Qlib. 100 loop = 3 110 cnt = 0 120 PRINT 'Start:'! loop, cnt 130 REPeat loop 140 PRINT loop, cnt 150 cnt = cnt + 1 160 IF cnt >= loop: EXIT loop 170 END REPeat loop 180 PRINT 'End:'! loop, cnt 190 PAUSE: QUIT In the Qlib-compiled version the loop is exited after a single run as the condition cnt >= loop is met immediately, to wit 1 >= 0 The worrying part of this is that while I was figuring out what was wrong, running an embedded routine like this many times, the system crashed due to memory corruption. Whether this was due to the SBASIC or Qlib compiled version I cant say right now. So just beware and keep on progging! NB: This works, though. As long as you start out with loop = 0 100 loop = 0 110 cnt = 3 120 PRINT 'Start:'! loop, cnt 130 REPeat loop 140 PRINT loop, cnt 150 loop = loop + 1 160 IF loop >= cnt: EXIT loop 170 END REPeat loop 180 PRINT 'End:'! loop, cnt 190 PAUSE: QUIT Not that I have ever had this problem but when using a REPeat variable as a value I've always made sure it was only used within the Loop. In the Name Table a simple variable is marked differently ($0202) from a REPeat index ($0602), the question is who is doing it right? When Qlib encounters the 2nd 'loop' it probably sets up a new zero entry with the same name. In your second example the first 'loop = 0' is most likely not relevant. Bob -- Deze e-mail is gecontroleerd op virussen door AVG. http://www.avg.com ___ QL-Users Mailing List
[Ql-Users] loopy bug
I dont know if this has been documented anywhere, but Im putting it out here as it caused me some grief. It appears that Q-Liberator zeroes the loop variable on entry to a loop. The following demo, which is acceptable (although perhaps not very elegant) S*BASIC, will not work in the same way once compiled with Qlib. 100 loop = 3 110 cnt = 0 120 PRINT 'Start:'! loop, cnt 130 REPeat loop 140 PRINT loop, cnt 150 cnt = cnt + 1 160 IF cnt >= loop: EXIT loop 170 END REPeat loop 180 PRINT 'End:'! loop, cnt 190 PAUSE: QUIT In the Qlib-compiled version the loop is exited after a single run as the condition cnt >= loop is met immediately, to wit 1 >= 0 The worrying part of this is that while I was figuring out what was wrong, running an embedded routine like this many times, the system crashed due to memory corruption. Whether this was due to the SBASIC or Qlib compiled version I cant say right now. So just beware and keep on progging! NB: This works, though. As long as you start out with loop = 0 100 loop = 0 110 cnt = 3 120 PRINT 'Start:'! loop, cnt 130 REPeat loop 140 PRINT loop, cnt 150 loop = loop + 1 160 IF loop >= cnt: EXIT loop 170 END REPeat loop 180 PRINT 'End:'! loop, cnt 190 PAUSE: QUIT Per ___ QL-Users Mailing List
