Re: [ql-users] Q-Starter
In a message dated 15/04/05 02:08:28 GMT Daylight Time, [EMAIL PROTECTED] writes: > > George Gwilt writes: > > >>An array descriptor merely presents a logical view of the data. If Turbo > >>at present just sees that a parameter is an array and ignores any > indices, > >>then parsing those indices would have to be implemented - something that > >>could be a major job! If, however, the indices are accessable to Turbo, > then > >>its simply a matter of creating a descriptor based on those indices - > not > >>much more difficult than creating the descriptor for the whole array? > >> > >> > > > >The problem as I see it is that the slicing information, which could only > be > >used by Turbo for a machine code extension, would have to be sent by > Parser > >via the intermediate code to codegen which would then have to package it > so that > >in the "proc/fn_rom" section in the entry code (taken from the Turbo > library > >and put in every compiled task) the appropriate (new) code could use the > >information to set a correct S*BASIC type descriptor. > > > >The new code in the entry code is easy. It is the other bits that are not. > > Perhaps SNG could suggest something? > > > Perhaps SNG could! However, I am well on the way to having written the necessary code to allow array slicing for parameters to machine code extensions. How many new bugs it will introduce I dare not speculate upon. This enhancement of Turbo seems to me to be necessary anyway since the current version (4e21) does not allow an array element to be sent on its own as a reference parameter which it should. Thus GET#3\42,v%(6) should be allowed by Turbo. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 14/04/05 14:38:06 GMT Daylight Time, [EMAIL PROTECTED] writes: > > [EMAIL PROTECTED] wrote: > >As far as I know BP_LET changes a parameter by copying the value on > >the maths stack to the address at byte 4 of the parameter entry on > >the Name Table. I had assumed that this 4-byte pointer would be set. > >Instead MWDEF seems to be copying both the pointer into the name > >table as well as the 8-byte entry from the name table. > > Yes, it copies that to ensure that the name table entry is still the > same (i.e. it's just used for comparison and as a safety net). > Question being, is this check necessary, is there any case where just > storing the variable address can corrupt memory because of it being > moved or anything? I guess for Turbo the answer is a sound "no", but > I'm not so sure about the interpreters. > I suppose that the address of the variable (ch% say) at byte 4 of the name table entry could be changed in S*BASIC. For example if ch% were redefined as an array (DIM ch%(5), say). Then the old address stored would become wrong. Of course in that case the error code could not be set in ch%. However, the code in the program putting the error code into ch% could check that ch% was still available. What a a palaver! George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
George Gwilt writes: > > An array descriptor merely presents a logical view of the data. If Turbo > > at present just sees that a parameter is an array and ignores any indices, > > then parsing those indices would have to be implemented - something that > > could be a major job! If, however, the indices are accessable to Turbo, then > > its simply a matter of creating a descriptor based on those indices - not > > much more difficult than creating the descriptor for the whole array? > > > > > > The problem as I see it is that the slicing information, which could only be > used by Turbo for a machine code extension, would have to be sent by Parser > via the intermediate code to codegen which would then have to package it so that > in the "proc/fn_rom" section in the entry code (taken from the Turbo library > and put in every compiled task) the appropriate (new) code could use the > information to set a correct S*BASIC type descriptor. > > The new code in the entry code is easy. It is the other bits that are not. Perhaps SNG could suggest something? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: > As far as I know BP_LET changes a parameter by copying the value on > the maths stack to the address at byte 4 of the parameter entry on > the Name Table. I had assumed that this 4-byte pointer would be set. > Instead MWDEF seems to be copying both the pointer into the name > table as well as the 8-byte entry from the name table. Yes, it copies that to ensure that the name table entry is still the same (i.e. it's just used for comparison and as a safety net). Question being, is this check necessary, is there any case where just storing the variable address can corrupt memory because of it being moved or anything? I guess for Turbo the answer is a sound "no", but I'm not so sure about the interpreters. It stores the address of the name table instead if the address of the variable itself because it lets BP_LET do the work (and that code is shared with a lot of other possible variants, so I'd need to extract that code path somehow and make it separate). > I assume that at the time the code you quote is obeyed A3 still > points to the name table entry for the channel parameter, but that > A5 has been set to the address of the window definition (perhaps > plus a constant). Almost, A5 points to an internal variable space, allocated as a thing (the "easymenu01230123" things one can see in the thing list). Ciao, Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 13/04/05 16:35:54 GMT Daylight Time, [EMAIL PROTECTED] writes: > > > >Oops, I confess I'm pretty new to all this, but for me it looks like > >actually this IS how it works: > > > > move.w 2(a6,a3.l),d0 ;set error return variable > > blt.s @1 > > ext.l d0 > > lsl.l #3,d0 > > add.l $18(a6),d0 > > move.l d0,error_var(a5) > > move.l 0(a6,d0.l),error_id1(a5) > > move.l 4(a6,d0.l),error_id2(a5) > >@1 > > > >But I can change everything. I guess the right way to do it is to > >check that the type of the parameter is $0203? > > > I have now tried this method, but storing the address of the channel variable from its position in the parameter information at the end of the Name Table. This address is the same as that in the original entry in the Name Table for the variable. Since the first word in the Name Table entry for a variable headed by # and preceded by a comma will be $0293 it will be safer to mask this with $FF0F before testing for $0203. The storing of the pointer to the variable's value can then be something like: move.l 4(a3,a6.l),error_var(a5) I have used this method successfully on Q60 and on a JM rom plus trump card. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 12/04/05 20:37:00 GMT Daylight Time, [EMAIL PROTECTED] writes: > > There are often good reasons for using array slices. Although work-arounds > are usually possible, they may require shifting data into other arrays which > is both time and space consuming. > > An array descriptor merely presents a logical view of the data. If Turbo > at present just sees that a parameter is an array and ignores any indices, > then parsing those indices would have to be implemented - something that > could be a major job! If, however, the indices are accessable to Turbo, then > its simply a matter of creating a descriptor based on those indices - not > much more difficult than creating the descriptor for the whole array? > > The problem as I see it is that the slicing information, which could only be used by Turbo for a machine code extension, would have to be sent by Parser via the intermediate code to codegen which would then have to package it so that in the "proc/fn_rom" section in the entry code (taken from the Turbo library and put in every compiled task) the appropriate (new) code could use the information to set a correct S*BASIC type descriptor. The new code in the entry code is easy. It is the other bits that are not. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 12/04/05 12:01:19 GMT Daylight Time, [EMAIL PROTECTED] writes: > > [EMAIL PROTECTED] wrote: > >The only snag I can see is if the code for MWDEF, which has to tell > >whether the channel is sent by reference or value, gets it wrong for > >Turbo. This could happen if, for example, MWDEF assumes (wrongly) > >that the parameter is passed by value if the pointer to the Name > >List in the Name Table is -1. I imagine this is very unlikely. > > Oops, I confess I'm pretty new to all this, but for me it looks like > actually this IS how it works: > > move.w 2(a6,a3.l),d0 ;set error return variable > blt.s @1 > ext.l d0 > lsl.l #3,d0 > add.l $18(a6),d0 > move.l d0,error_var(a5) > move.l 0(a6,d0.l),error_id1(a5) > move.l 4(a6,d0.l),error_id2(a5) > @1 > > But I can change everything. I guess the right way to do it is to > check that the type of the parameter is $0203? > > As far as I know BP_LET changes a parameter by copying the value on the maths stack to the address at byte 4 of the parameter entry on the Name Table. I had assumed that this 4-byte pointer would be set. Instead MWDEF seems to be copying both the pointer into the name table as well as the 8-byte entry from the name table. Yes, the type of parameter should indeed be $0203. I assume that at the time the code you quote is obeyed A3 still points to the name table entry for the channel parameter, but that A5 has been set to the address of the window definition (perhaps plus a constant). Cheers George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes: > P Witte wrote: > >> But I can change everything > > Oh yes? ;)) > > "Can", not "will" ;-) I knew I must be dreaming.. ;) > > One "very" "simple" "improvement" that could be made to MAWDRAW > > would be to allow it to take an address instead of an array. The address > > would point to a data area with the following structure - which you will > > recognise as the last part of a Menu Application Window Definition: > > Well, MAWDRAW are 1000 lines of code that are not exactly easy to > understand, I'd rather not dig too deep in there. And quite frankly, I > guess nobody except you would know how to use it. You know best. Its just if it were easy to do.. Youre probably right that it is not very useful. > Plus if one really needs it, it could probably just be done by a few > POKEs, MWDEF does return the working definition after all. This would > be the equivalent to MAWSETUP, the menu can then be drawn using > MAWDRAW. Just speaking freely, no idea whether it really works, of > course. I agree it should be possible. > > This would allow extra flexibility when needed to produce 1) 2-dimensional > > lists with the exact number of elements (not rounded up as now) > > Rounded up? For example, if you have 10 items to display with three items per line, you have to supply the data in a two-dimensional array, eg DIM arr$(3, 2, 10). arr$ has 12 elements, not 10, so you get two unwanted places tacked on the end. This is not a feature of Wman but of EP having to use arrays. Not a big deal, but it has just that whiff of mickey mouse technology to it. > > 2) Mixed object type lists, > > MAWDRAW can do this, can't it? Sort of. I forgot you could also specify string objects using the '@»' & adr construct. The latter is an unfortunate scheme though. It may have been ok-ish in the sub 16Mb days, but with more than 16Mb memory you get rounding errors on the addresses! (unless suitable precautions are taken). Why didnt Albin just use floating point arrays for this, I wonder? > > 4) Turbo-compatible lists with DIY slicing, > > As a workaround for this, how about a command that somehow explicitly > creates a header for an array that has sliced indexes? Just a thought. But how would you pass that descriptor to a command? Its possible if the relevant commands that take array parameters could simply take the descriptor instead, but they dont. Ive used a similar idea for a different reason, so Im pretty sure the concept is sound. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: >> But I can change everything > Oh yes? ;)) "Can", not "will" ;-) > One "very" "simple" "improvement" that could be made to MAWDRAW > would be to allow it to take an address instead of an array. The address > would point to a data area with the following structure - which you will > recognise as the last part of a Menu Application Window Definition: Well, MAWDRAW are 1000 lines of code that are not exactly easy to understand, I'd rather not dig too deep in there. And quite frankly, I guess nobody except you would know how to use it. Plus if one really needs it, it could probably just be done by a few POKEs, MWDEF does return the working definition after all. This would be the equivalent to MAWSETUP, the menu can then be drawn using MAWDRAW. Just speaking freely, no idea whether it really works, of course. > This would allow extra flexibility when needed to produce 1) 2-dimensional > lists with the exact number of elements (not rounded up as now) Rounded up? > 2) Mixed object type lists, MAWDRAW can do this, can't it? > 4) Turbo-compatible lists with DIY slicing, As a workaround for this, how about a command that somehow explicitly creates a header for an array that has sliced indexes? Just a thought. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes: <> > But I can change everything Oh yes? ;)) One "very" "simple" "improvement" that could be made to MAWDRAW would be to allow it to take an address instead of an array. The address would point to a data area with the following structure - which you will recognise as the last part of a Menu Application Window Definition: dc.w $0001;number of actual columns dc.w $000A;number of actual rows dc.w $;x offset to start of menu (section) dc.w $0006;y offset to start of menu (section) dc.w list1-* ;pointer to x (column) spacing list dc.w list2-* ;pointer to y (row) spacing list dc.w 0;pointer to x (column) index list dc.w 0;pointer to y (row) index list dc.w list3-* ;pointer to menu row list ; list1 ;column spacing list : dc.w $FFB0;object hit size dc.w $FFAE;object spacing list2 ;row spacing list : dc.w $FFF6;object hit size dc.w $FFF5;object spacing ;menu row list : list3 dc.w list4-* ;pointer to object row list start dc.w list5-* ;pointer to object row list end ...etc, etc The header part (the first 18b) would have to be copied to EP's internal structures and the pointers adjusted accordingly, the rest simply remains in situ. This would allow extra flexibility when needed to produce 1) 2-dimensional lists with the exact number of elements (not rounded up as now), 2) Mixed object type lists, 3) Indexed lists, 4) Turbo-compatible lists with DIY slicing, 5) Pre-defined lists that can be loaded from disk on demand, 6) rapid switching between multiple lists... Dangerous but powerful! Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
George Gwilt writes: > Turbo cannot set sliced arrays as parameters to S*BASIC procedures or > functions. This is because of the way the array descriptors are defined. However it > is theoretically possible to set a sliced array as parameter to a machine code > extension since Turbo defines an S*BASIC descriptor. Unfortunately I cannot > see at the moment a way of doing this in practice. Also I had thought that > programs could be fairly easily written to avoid slicing. There are often good reasons for using array slices. Although work-arounds are usually possible, they may require shifting data into other arrays which is both time and space consuming. An array descriptor merely presents a logical view of the data. If Turbo at present just sees that a parameter is an array and ignores any indices, then parsing those indices would have to be implemented - something that could be a major job! If, however, the indices are accessable to Turbo, then its simply a matter of creating a descriptor based on those indices - not much more difficult than creating the descriptor for the whole array? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: > The only snag I can see is if the code for MWDEF, which has to tell > whether the channel is sent by reference or value, gets it wrong for > Turbo. This could happen if, for example, MWDEF assumes (wrongly) > that the parameter is passed by value if the pointer to the Name > List in the Name Table is -1. I imagine this is very unlikely. Oops, I confess I'm pretty new to all this, but for me it looks like actually this IS how it works: move.w 2(a6,a3.l),d0 ;set error return variable blt.s @1 ext.l d0 lsl.l #3,d0 add.l $18(a6),d0 move.l d0,error_var(a5) move.l 0(a6,d0.l),error_id1(a5) move.l 4(a6,d0.l),error_id2(a5) @1 But I can change everything. I guess the right way to do it is to check that the type of the parameter is $0203? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 12/04/05 01:28:10 GMT Daylight Time, [EMAIL PROTECTED] writes: > >passed. > In Easyptr, the MAWDRAW command often needs a sliced array. > > Consider a list of files, stored in f$(). We assume a maximum of, say, > 480 files: > > DIM f$(480,36) > > If the list was only 60 files long, the application window menu might > be set up with: > > MAWDRAW #ch%,1,f$(0 to 59) > > (example from memory, open to correction of course). > > This sort of example could probably be rewritten in most cases to do 2 > passes to read the number of files (pass 1), then dimension the array > accordingly, then pass 2 does the actual reading of filenames to the > array f$(), thus avoiding the need for an array slice. > > I presume this means this would not be possible under Turbo as it > stands (sliced arrays cannot be passed to m/code extensions, although > in this case only passing by value of the array slice is required), > although what you have already done to Turbo is of course a most > welcome development. > > -- > Turbo cannot set sliced arrays as parameters to S*BASIC procedures or functions. This is because of the way the array descriptors are defined. However it is theoretically possible to set a sliced array as parameter to a machine code extension since Turbo defines an S*BASIC descriptor. Unfortunately I cannot see at the moment a way of doing this in practice. Also I had thought that programs could be fairly easily written to avoid slicing. Incidentally there is no difference between passing an array by value and by reference in the sense that the only way you can pass an array is by giving the address of the descriptor (which is by reference anyway). George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 11/04/05 20:34:25 GMT Daylight Time, [EMAIL PROTECTED] writes: > However, it gets more >complicated: You can set EasyPtr up so that instead > >of a channelnumber you > >pass a pointer to the working definition. A designated variable then gets > >any error code instead > > > > > 100 adr = MWDEF(#ch%) > > 110 REPeat loop > > 120 ch% = 0 > > 130 action = MCALL(#adr) > > 140 if ch% <0: PRINT 'Error during MCALL:'! ch%: EXIT loop ... > > How does line 120 indicate that ch% is the variable that MCALL is to return > the error code? > If I knew that I could perhaps tell what Turbo would do!! > > > > >Luckily, both these behaviours are optional. Their main use is for aiding > >program development. Turbo should now be able to handle the first scenario > >in any case. But it probably doesnt handle the second? > On reflection I can see that MWDEF, being passed the variable ch% by reference, can store its address (which is given in the Name Table relative to the VV area) in a spare long word attached to the window definition at "adr". This will allow all subsequent extensions which are given adr as parameter to access the variable ch%. Hence MCALL could easily send the error code to ch%. If this is how it works then all that is needed is that ch% be passed to MWDEF by reference. Since Turbo does this MCALL should operate as hoped. The only snag I can see is if the code for MWDEF, which has to tell whether the channel is sent by reference or value, gets it wrong for Turbo. This could happen if, for example, MWDEF assumes (wrongly) that the parameter is passed by value if the pointer to the Name List in the Name Table is -1. I imagine this is very unlikely. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: >> 100 adr = MWDEF(#ch%) >> 110 REPeat loop >> 120 ch% = 0 >> 130 action = MCALL(#adr) >> 140 if ch% <0: PRINT 'Error during MCALL:'! ch%: EXIT loop ... > How does line 120 indicate that ch% is the variable that MCALL is to > return the error code? It doesn't, the MWDEF in line 100 does that. > If I knew that I could perhaps tell what Turbo would do!! I guess you should already be fine if the MWDEF gets the variable by reference. EasyPtr will keep the reference and use it on the next error. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
>The latest beta test version of Turbo, v4d21, should soon be on >the SQLUG >site. This one has compiled QPTR's "demo_bas" (after some >modifications). I'm curious, what kind of modifications? Dimensioning of strings? I've read the readme of v4c21 and it sounds pretty promising. What grade of compatibility do you think you'll be able to achieve? Turbo won't pass undimensioned simple strings as parameters to machine code routines. Nor will it pass sliced arrays. All other types of parameter can be passed. In Easyptr, the MAWDRAW command often needs a sliced array. Consider a list of files, stored in f$(). We assume a maximum of, say, 480 files: DIM f$(480,36) If the list was only 60 files long, the application window menu might be set up with: MAWDRAW #ch%,1,f$(0 to 59) (example from memory, open to correction of course). This sort of example could probably be rewritten in most cases to do 2 passes to read the number of files (pass 1), then dimension the array accordingly, then pass 2 does the actual reading of filenames to the array f$(), thus avoiding the need for an array slice. I presume this means this would not be possible under Turbo as it stands (sliced arrays cannot be passed to m/code extensions, although in this case only passing by value of the array slice is required), although what you have already done to Turbo is of course a most welcome development. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.6 - Release Date: 11/04/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 09/04/05 15:28:16 GMT Daylight Time, [EMAIL PROTECTED] writes: > > All EasyPtr keywords can return an error code in the channel parameter, > provided it is supplied as an integer, ie #ch%. > > That seems OK. > > However, it gets more > complicated: You can set EasyPtr up so that instead > of a channelnumber you > pass a pointer to the working definition. A designated variable then gets > any error code instead > > 100 adr = MWDEF(#ch%) > 110 REPeat loop > 120 ch% = 0 > 130 action = MCALL(#adr) > 140 if ch% <0: PRINT 'Error during MCALL:'! ch%: EXIT loop ... How does line 120 indicate that ch% is the variable that MCALL is to return the error code? If I knew that I could perhaps tell what Turbo would do!! > > Luckily, both these behaviours are optional. Their main use is for aiding > program development. Turbo should now be able to handle the first scenario > in any case. But it probably doesnt handle the second? > > The main stumbling block was that Turbo couldnt handle arrays being passed > as parameters. With this considerable inconvenience overcome, a major > disincentive to use Turbo has been removed. > I am indeed glad of that. It as also nice to be able to use GET, BGET etc. > > George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 09/04/05 07:13:20 GMT Daylight Time,
[EMAIL PROTECTED] writes:
> >The latest beta test version of Turbo, v4d21, should soon be on the SQLUG
> >site. This one has compiled QPTR's "demo_bas" (after some modifications).
>
> I'm curious, what kind of modifications? Dimensioning of strings?
> I've read the readme of v4c21 and it sounds pretty promising. What
> grade of compatibility do you think you'll be able to achieve?
>
Turbo won't pass undimensioned simple strings as parameters to machine code
routines. Nor will it pass sliced arrays. All other types of parameter can be
passed.
> EasyPtr has sometimes a very powerful but also very complex syntax,
> e.g.
>
> {} = alternative
> [] = optional
>
> MAWDRAW [#ch%] {,}{;}{\} num[, [array$][, xst%, yst%[, [under%]
> [, [xsz%], [ysz%][, [xju%][, [yju%]]]
>
> MAWDRAW #3,1,array$,0,0,,,16
No problem that I can see here.
> but I think it only passes back simple integers or integer arrays in
> its parameters (with MINPUT being the only exception, it alters a
> given string using SB.PUTP). Could Turbo manage all this stuff?
>
Simple string parameters to be altered will be dimensioned by Turbo, since
all simple strings are perforce dimensioned. This means that a machine code
routine altering a simple string parameter must allow the possibility that the
string will be dimensioned. In QPTR the extension RPTR returns a string
paramter.
I have checked that that this routine does allow both a dimensioned and an
undimensioned string. However, some other routines in QPTR only allow
undimensioned strings but these can be passed by value. Very odd!
I don't understand how arrays can be "passed back2. I assume simply that the
values of the arrays are altered. Anyway, I can't see that Turbo will fail
here since it passes the address of a S*BASIC type descriptor as parameter. The
only difference between Turbo and S*BASIC is that Turbo does not have a pointer
to the Name List.
>
>
>
>
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 09/04/05 15:28:16 GMT Daylight Time, [EMAIL PROTECTED] writes: > > It sounds very promising! It must also be a major achievement as, IIUC, > Turbo gains some of its speed advantage by not mimicking certain SuperBasic > interpreter structures. Are these structures now being emulated by Turbo? > And without a significant speed penalty? > I think that passing fp numbers and possibly integers by reference instead of by value to machine code routines can actually increase the speed of the compiled task. This will certainly be true where long strings are passed by reference. In other cases I think the speed loss will be pretty small. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Dear George
Another of interest
John
- Original Message -
From: "P Witte" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 09, 2005 3:27 PM
Subject: Re: [ql-users] Q-Starter
> Marcel Kilgus writes:
>
> > [EMAIL PROTECTED] wrote:
> > > The latest beta test version of Turbo, v4d21, should soon be on the
> SQLUG
> > > site. This one has compiled QPTR's "demo_bas" (after some
> modifications).
> >
> > I'm curious, what kind of modifications? Dimensioning of strings?
> > I've read the readme of v4c21 and it sounds pretty promising. What
> > grade of compatibility do you think you'll be able to achieve?
>
> It sounds very promising! It must also be a major achievement as, IIUC,
> Turbo gains some of its speed advantage by not mimicking certain
SuperBasic
> interpreter structures. Are these structures now being emulated by Turbo?
> And without a significant speed penalty?
>
> > EasyPtr has sometimes a very powerful but also very complex syntax,
> > e.g.
> >
> > {} = alternative
> > [] = optional
> >
> > MAWDRAW [#ch%] {,}{;}{\} num[, [array$][, xst%, yst%[, [under%]
> > [, [xsz%], [ysz%][, [xju%][, [yju%]]]
> >
> > MAWDRAW #3,1,array$,0,0,,,16
> >
> > but I think it only passes back simple integers or integer arrays in
> > its parameters (with MINPUT being the only exception, it alters a
> > given string using SB.PUTP). Could Turbo manage all this stuff?
>
> All EasyPtr keywords can return an error code in the channel parameter,
> provided it is supplied as an integer, ie #ch%. However, it gets more
> complicated: You can set EasyPtr up so that instead of a channel number
you
> pass a pointer to the working definition. A designated variable then gets
> any error code instead!
>
> 100 adr = MWDEF(#ch%)
> 110 REPeat loop
> 120 ch% = 0
> 130 action = MCALL(#adr)
> 140 if ch% < 0: PRINT 'Error during MCALL:'! ch%: EXIT loop
> ...
>
> Luckily, both these behaviours are optional. Their main use is for aiding
> program development. Turbo should now be able to handle the first scenario
> in any case. But it probably doesnt handle the second?
>
> The main stumbling block was that Turbo couldnt handle arrays being passed
> as parameters. With this considerable inconvenience overcome, a major
> disincentive to use Turbo has been removed.
>
> 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] Q-Starter
Marcel Kilgus writes:
> [EMAIL PROTECTED] wrote:
> > The latest beta test version of Turbo, v4d21, should soon be on the
SQLUG
> > site. This one has compiled QPTR's "demo_bas" (after some
modifications).
>
> I'm curious, what kind of modifications? Dimensioning of strings?
> I've read the readme of v4c21 and it sounds pretty promising. What
> grade of compatibility do you think you'll be able to achieve?
It sounds very promising! It must also be a major achievement as, IIUC,
Turbo gains some of its speed advantage by not mimicking certain SuperBasic
interpreter structures. Are these structures now being emulated by Turbo?
And without a significant speed penalty?
> EasyPtr has sometimes a very powerful but also very complex syntax,
> e.g.
>
> {} = alternative
> [] = optional
>
> MAWDRAW [#ch%] {,}{;}{\} num[, [array$][, xst%, yst%[, [under%]
> [, [xsz%], [ysz%][, [xju%][, [yju%]]]
>
> MAWDRAW #3,1,array$,0,0,,,16
>
> but I think it only passes back simple integers or integer arrays in
> its parameters (with MINPUT being the only exception, it alters a
> given string using SB.PUTP). Could Turbo manage all this stuff?
All EasyPtr keywords can return an error code in the channel parameter,
provided it is supplied as an integer, ie #ch%. However, it gets more
complicated: You can set EasyPtr up so that instead of a channel number you
pass a pointer to the working definition. A designated variable then gets
any error code instead!
100 adr = MWDEF(#ch%)
110 REPeat loop
120 ch% = 0
130 action = MCALL(#adr)
140 if ch% < 0: PRINT 'Error during MCALL:'! ch%: EXIT loop
...
Luckily, both these behaviours are optional. Their main use is for aiding
program development. Turbo should now be able to handle the first scenario
in any case. But it probably doesnt handle the second?
The main stumbling block was that Turbo couldnt handle arrays being passed
as parameters. With this considerable inconvenience overcome, a major
disincentive to use Turbo has been removed.
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote:
> The latest beta test version of Turbo, v4d21, should soon be on the SQLUG
> site. This one has compiled QPTR's "demo_bas" (after some modifications).
I'm curious, what kind of modifications? Dimensioning of strings?
I've read the readme of v4c21 and it sounds pretty promising. What
grade of compatibility do you think you'll be able to achieve?
EasyPtr has sometimes a very powerful but also very complex syntax,
e.g.
{} = alternative
[] = optional
MAWDRAW [#ch%] {,}{;}{\} num[, [array$][, xst%, yst%[, [under%]
[, [xsz%], [ysz%][, [xju%][, [yju%]]]
MAWDRAW #3,1,array$,0,0,,,16
but I think it only passes back simple integers or integer arrays in
its parameters (with MINPUT being the only exception, it alters a
given string using SB.PUTP). Could Turbo manage all this stuff?
Marcel
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In a message dated 06/04/05 00:46:40 GMT Daylight Time, [EMAIL PROTECTED] writes: > > You bet! Besides, with all the work George put into Turbo it might > start being a real alternative. I've never been a fan of Turbo but > I think he's really moving something. > The latest beta test version of Turbo, v4d21, should soon be on the SQLUG site. This one has compiled QPTR's "demo_bas" (after some modifications). George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
RE: [ql-users] Q-Starter
And what cruel devil put as "s" in lisp? A thermos flask keeps hot things hot and cold things cold - how does it know? Or if you unwrap some cling film from a block of cheese, then eat half the cheese, even though there is half as much the cling film still doesn't cover it? -Original Message- From: Wolfgang Uhlig [mailto:[EMAIL PROTECTED] Sent: 06 April 2005 17:46 To: [EMAIL PROTECTED] Subject: Re: [ql-users] Q-Starter > Why did the chicken cross the road ? > What came first, the chicken or the egg ? > What do women want ? Or: Why is abbreviation such a long word? Is there another word for synonym? etc ;) Cheers, 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] Q-Starter
- Original Message - From: "Marcel Kilgus" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 06, 2005 5:58 PM Subject: Re: [ql-users] Q-Starter Wolfgang Uhlig wrote: Why is abbreviation such a long word? Is there another word for synonym? And in that vain: isn't dyslexic a rather cruel word to describe this condition? Marcel Oh I don't know seems KO to me All the best - Bill ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: > Im aware of the embedded message, but at some point I changed to using 0,82 > (ie dont call the initialisation routine at all) and it has apparently > worked. What deos the initialisation code do? Oh dear, you're right. I didn't know "0" means "do not call at all" and wouldn't have expected it as it seems somewhat of a bad design decision. A quick look shows that the EasyPtr init routine just seems to check whether the THING system is available, so you might well get away with not calling the initialisation. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Wolfgang Uhlig wrote: > Why is abbreviation such a long word? > Is there another word for synonym? And in that vain: isn't dyslexic a rather cruel word to describe this condition? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, April 06, 2005 2:14 PM Subject: Re: [ql-users] Q-Starter [EMAIL PROTECTED] wrote: Am Wed, 06 Apr 2005 12:21:48 +0100 hat <[EMAIL PROTECTED]> geschrieben: Hi Norman, > We may never know ! No problem, there are more things we may never know ;) Indeed - such as : Why did the chicken cross the road ? - to get to the other side What came first, the chicken or the egg ?- the cockerel What do women want ? - Whatever you didn't get them Next level please and don't forget the known things we know, the known things we do not know, the unknown things we do not know, the known unknowns and .. if that's not enough there's the next month to get through. All the best - Bill ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Why did the chicken cross the road ? What came first, the chicken or the egg ? What do women want ? Or: Why is abbreviation such a long word? Is there another word for synonym? etc ;) Cheers, Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
P Witte wrote: > Im aware of the embedded message, but at some point I changed to > using 0,82 (ie dont call the initialisation routine at all) No, this is not what's it doing: QLiberator wants 2 parameters, one for the offset of an initialisation routine that should NOT contain a call to sb.inipr and one for the procedure/function table in a format suitable for sb.inipr, so that QLiberator can link in the functions itself. The EasyPtr extensions provide 2 entry points: 0 and 4. 0 does the same initialisation that 4 does, but additionally has a call to sb.inipr so that the file can just be LRESPRed to link in the basic functions. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> Indeed - such as : > > Why did the chicken cross the road ? > What came first, the chicken or the egg ? > What do women want ? > > Cheers, > Norman. > > PS. The answer to the second one is 'the egg'. Birds (and therefore chickens) > are decendants of the dinosaurs and they laid egs - so, the egg came first. > :o) On the same line, and on-topic: Q. Which came first, the QL or the Q60? A. The Q60 of course. The QL is smaller than the Q60 and the trend in electronics is towards miniaturisation, therefore the QL must have been made later than the Q60 because it's smaller. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: > Am Wed, 06 Apr 2005 12:21:48 +0100 hat <[EMAIL PROTECTED]> > geschrieben: > > Hi Norman, > > > We may never know ! > No problem, there are more things we may never know ;) > Indeed - such as : Why did the chicken cross the road ? What came first, the chicken or the egg ? What do women want ? Cheers, Norman. PS. The answer to the second one is 'the egg'. Birds (and therefore chickens) are decendants of the dinosaurs and they laid egs - so, the egg came first. :o) ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Am Wed, 06 Apr 2005 12:21:48 +0100 hat <[EMAIL PROTECTED]> geschrieben: Hi Norman, We may never know ! No problem, there are more things we may never know ;) Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: > > No, it doens't not. It's in the "ptrmen_cde", too. > Morning Wolfgang. I did say that I was 95% sure - and it has been a long time since I had the problem. The question now has to be, if it isn't MSTAT% then what EasyPtr command was it I fell over on ? We may never know ! Cheers, Norman. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Marcel Kilgus writes: > P Witte wrote: > >> The compiler directive is correct, or at least as per what is in > >> ptrmen_cde ($$asmb=filename,4,82) > > If the filename above should happen to be ptrmen_cde the correct parameters > > are > > $$asmb=filename,0,82 > > No, "4,82" is the correct one. Address 4 is the entry point without > sb_inipr, 0 is the one with it. Qliberator wants the one without it. Im aware of the embedded message, but at some point I changed to using 0,82 (ie dont call the initialisation routine at all) and it has apparently worked. What deos the initialisation code do? Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Norman Dunbar writes: <> > MSTAT% is not in the redistributable code, it lives solely in the > ptrmenR code, ie, the resident stuff which you are not allowed > to link into your programs. I never noticed. But it definitely is in the runtime version of the toolkit now, and has been since V3.50 at least. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Am Wed, 06 Apr 2005 08:01:59 +0100 hat <[EMAIL PROTECTED]> geschrieben: How about this : MSTAT% is not in the redistributable code, it lives solely in the ptrmenR code, ie, the resident stuff which you are not allowed to link into your programs. No, it doens't not. It's in the "ptrmen_cde", too. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> > The compiler directive is correct, or at least as per what is in > > ptrmen_cde ($$asmb=filename,4,82) > > I just had a look and saw that ptrmen is broken, I've had 2 lines in > the wrong order. > > Marcel Thanks (again) Marcel, this should resolve the problem. Serves me right for jumping the gun and releasing a program (albeit a test program) before Easyptr full release is ready. But I suppose if it helps to identify a problem it's probably worth it. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> MSTAT% is not in the redistributable code, it lives solely in the ptrmenR > code, ie, the resident stuff which you are not allowed to link into your > programs. > > I'm pretty sure (ok, about 95%) that this will be your problem as I had it a > long time ago myself when DJC was still selling my stuff. Well, the keyword seems there, and I'm sure I've used it in previous programs with ptrmen_cde (Launchpad uses it a lot I'm sure). When I get a chance, I'm going to try what was in Marcel's email and see how I get on. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> > > The compiler directive is correct, or at least as per what is in > > > ptrmen_cde ($$asmb=filename,4,82) > > > > > > If the filename above should happen to be ptrmen_cde the correct parameters > > are > > > > $$asmb=filename,0,82 > > > > Per > I used ?,4,82 because that's what it says embedded in ptrmen_cde - I've > always followed the embedded instruction with Easyptr code files linked to > QLib programs without problem. I might ask Marcel if he is aware of any > relevant issues with this as I'm having difficulties with this one. Drat, with my usual defective timing I notice there's another email from Marcel on this very subject, so ignore the email I just sent. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> > The compiler directive is correct, or at least as per what is in > > ptrmen_cde ($$asmb=filename,4,82) > > > If the filename above should happen to be ptrmen_cde the correct parameters > are > > $$asmb=filename,0,82 > > Per I used ?,4,82 because that's what it says embedded in ptrmen_cde - I've always followed the embedded instruction with Easyptr code files linked to QLib programs without problem. I might ask Marcel if he is aware of any relevant issues with this as I'm having difficulties with this one. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> >>Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) > > I think you would be taking your life in your hands > > You bet! Besides, with all the work George put into Turbo it might > start being a real alternative. I've never been a fan of Turbo but > I think he's really moving something. Yes, his work on getting reference parameter passing to work in v4b21 and 4c21 is an important step. And the work he's put into making it possible to have configuration, assembler files linked to the program and even the TurboPTR system for writing PE software is real progress. There is some good ground work going on which is all promising for software development. Programs like QDT, QWord and DMiner (to mention only a few) show us that great things are possible with the right mindset. Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
[EMAIL PROTECTED] wrote: > Hmmm, this is a bit more difficult than I thought. > > The compiler directive is correct, or at least as per what is in > ptrmen_cde ($$asmb=filename,4,82) > > Seems strange that > the program would get past MDRAW and MITEM keywords and fail at > MSTAT%, I guess my assumption re. the linking in of the easyptr > extensions must have been incorrect, the fault is more likely to be > finding or setting up the appended menus in the compiled program, > which probably works when I run it interpreted because it's loaded as > a file from disk rather than located in an appended file/ > How about this : MSTAT% is not in the redistributable code, it lives solely in the ptrmenR code, ie, the resident stuff which you are not allowed to link into your programs. I'm pretty sure (ok, about 95%) that this will be your problem as I had it a long time ago myself when DJC was still selling my stuff. HTH Cheers, Norman. > I'll need to spend a bit more time on it when I'm less tired. > > Actually, this is a good advert for the little USB Memory Pens which > were discussed here a few days ago. I can just dump the sources and a > copy of QPC2 and QLiberator in my USB memory pen and take it anywhere > there's a PC and some spare minutes to work on it! (usually means > lunchtime at work!) > > -- > Dilwyn Jones > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 01/04/2005 > > ___ > 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] Q-Starter
P Witte wrote: >> The compiler directive is correct, or at least as per what is in >> ptrmen_cde ($$asmb=filename,4,82) > If the filename above should happen to be ptrmen_cde the correct parameters > are > $$asmb=filename,0,82 No, "4,82" is the correct one. Address 4 is the entry point without sb_inipr, 0 is the one with it. Qliberator wants the one without it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Dilwyn Jones writes: > The compiler directive is correct, or at least as per what is in > ptrmen_cde ($$asmb=filename,4,82) If the filename above should happen to be ptrmen_cde the correct parameters are $$asmb=filename,0,82 Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Roy wood wrote: >>Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) > I think you would be taking your life in your hands You bet! Besides, with all the work George put into Turbo it might start being a real alternative. I've never been a fan of Turbo but I think he's really moving something. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Dilwyn Jones wrote: > The compiler directive is correct, or at least as per what is in > ptrmen_cde ($$asmb=filename,4,82) I just had a look and saw that ptrmen is broken, I've had 2 lines in the wrong order. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
Hi, tried it & got the Qlib error message : Line 600 MSTAT% Invalid name - an easy ptr extension? Can you distribute the easy ptr runtimes with it? Duncan Neithercut Hmmm, this is a bit more difficult than I thought. The compiler directive is correct, or at least as per what is in ptrmen_cde ($$asmb=filename,4,82) The preceding two lines of code include a MDRAW and MITEM command which it gets through, but the channel number is used as error return so that might be protecting an earlier error. There is one earlier part which sets the menu names etc slightly differently depending on whether interpreted in job 0 or compiled with menus appended to ptrmen_cde linked in the normal way. I must have made a mistake somewhere in that bit of code but can't find it. Seems strange that the program would get past MDRAW and MITEM keywords and fail at MSTAT%, I guess my assumption re. the linking in of the easyptr extensions must have been incorrect, the fault is more likely to be finding or setting up the appended menus in the compiled program, which probably works when I run it interpreted because it's loaded as a file from disk rather than located in an appended file/ I'll need to spend a bit more time on it when I'm less tired. Actually, this is a good advert for the little USB Memory Pens which were discussed here a few days ago. I can just dump the sources and a copy of QPC2 and QLiberator in my USB memory pen and take it anywhere there's a PC and some spare minutes to work on it! (usually means lunchtime at work!) -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 01/04/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In message <[EMAIL PROTECTED]>, gwicks <[EMAIL PROTECTED]> writes - Original Message - From: "Phoebus R. Dokos (Öïßâïò Ñ. Íôüêïò)" To: <[EMAIL PROTECTED]> Sent: Monday, April 04, 2005 9:14 PM Subject: Re: [ql-users] Q-Starter On Mon, 04 Apr 2005 15:06:37 -0400, Malcolm Cadman wrote: By the way QWord has its own Icon with QDT and launches successfully, and drops back into QDT, even though there is a colour mode change on my system. Yes, Jim had the foresight to ask us to create one ahead of time. Actually Jim was very helpful over icons. You will note there are also special icons for Just Words! progams. He even created a special folder icon when I told him that some people keep all of their Just Words! programs in Just Words! directory, OK ... I've missed that one, Geoff. As I do not have Just Words! -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In message <[EMAIL PROTECTED]>, Dilwyn Jones <[EMAIL PROTECTED]> writes I thought I had, but will check later. Maybe I put them in and made a mistake with the $$asmb compiler directive. Case of "better luck next time Dilwyn" I think! Thanks for letting me know. I have had the same error come up. I emailed Dilwyn privately to perhaps save embarrassment ... From: "Duncan Neithercut" <[EMAIL PROTECTED]> Date: 2005/04/04 Mon PM 08:22:08 GMT To: <[EMAIL PROTECTED]> Subject: RE: [ql-users] Q-Starter Hi, tried it & got the Qlib error message : Line 600 MSTAT% Invalid name - an easy ptr extension? Can you distribute the easy ptr runtimes with it? Duncan Neithercut -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In message <[EMAIL PROTECTED]>, Dilwyn Jones <[EMAIL PROTECTED]> writes >Hopefully, experience gained from writing this program will help and >encourage me to write more programs to take advantage of the new >facilities Marcel has worked so hard to bring us! > >http://homepages.tesco.net/dilwyn.jones/software/freeware/freeware.html Thanks, Dilwyn. I will download a copy this evening. I would like a 'new colours' aware version of Launchpad as I run it on QPC2. It is quite possibly on the agenda! That is what I figured ... :-) Once I'm happy the techniques I use in QStarter work to my satisfaction, I plan on tackling Launchpad, although it may be a bit more of a job than just redoing the menus, as there's some changes I want to implement for my own use too/ Yes. The intention of Launchpad to work on quite basic QL systems is fine ... and it should still do not. Just have the option to recognise a system with more enhanced features and use those features. I have now switched over to QDT as my preferred desktop, yet I am still using QTrans all time which is launched from an icon in the Util Folder. This was always how it would have been - QDT the system of choice for those with the system necessary to run it, Launchpad for those with older systems. That way, all users were catered for. Of course ... different intentions and market users. And already having Launchpad on my system has meant that QDT has recognised it, so it can be run at the same time, just like any other program. This is fun ... now we need software writers to get going with some new applications. From what I understand, it'll happen in the near future. I've written some articles for QL Today on the subject of developing programs using the new facilities with the new Easyptr when it's released. Good. New applications are what we really need. Many of the utilities and helper software are already there. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In message <[EMAIL PROTECTED]>, =?windows-1253?B?UGhvZWJ1cyBSLiBEb2tvcyAo1u/f4u/yINEuIM30/Orv8ik=?= <[EMAIL PROTECTED]> writes On Mon, 04 Apr 2005 15:06:37 -0400, Malcolm Cadman <[EMAIL PROTECTED]> wrote: By the way QWord has its own Icon with QDT and launches successfully, and drops back into QDT, even though there is a colour mode change on my system. Yes, Jim had the foresight to ask us to create one ahead of time. Yes, I noticed it was the only 'unique' one. Trust you to be first in ... :-) -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
He he, I knew there was little or no chance of this happening for that very reason, so I figured I could get away with pulling Marcel's leg. Poor lad, he's worked so hard on QL stuff lately and all we do is tease him! I'd better wear my flame proof suit for the AGM or he'll charge me double for the new Easyptr ;-) Dilwyn Jones > > From: "gwicks" <[EMAIL PROTECTED]> > Date: 2005/04/05 Tue PM 07:01:36 GMT > To: <[EMAIL PROTECTED]> > Subject: Re: Re: [ql-users] Q-Starter > > > - Original Message - > From: "Dilwyn Jones" > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 05, 2005 11:09 AM > Subject: Re: Re: [ql-users] Q-Starter > > > > Any news on the availability of the official Easyptr 4, Roy? Marcel did > > mention some time ago he hoped it might be at the AGM, the money for the > > upgrade is burning a hole in my pocket! > > > > Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) > > > > Being serious, not much chance of that unless we can trace and get the > co-operation of the missing author! > > Best Wishes, > Geoff > > > ___ > 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] Q-Starter
- Original Message - From: "Phoebus R. Dokos (Φοίβος Ρ. Ντόκος)" To: <[EMAIL PROTECTED]> Sent: Monday, April 04, 2005 9:14 PM Subject: Re: [ql-users] Q-Starter On Mon, 04 Apr 2005 15:06:37 -0400, Malcolm Cadman wrote: By the way QWord has its own Icon with QDT and launches successfully, and drops back into QDT, even though there is a colour mode change on my system. Yes, Jim had the foresight to ask us to create one ahead of time. Actually Jim was very helpful over icons. You will note there are also special icons for Just Words! progams. He even created a special folder icon when I told him that some people keep all of their Just Words! programs in Just Words! directory, Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
- Original Message - From: "Dilwyn Jones" To: <[EMAIL PROTECTED]> Sent: Tuesday, April 05, 2005 11:09 AM Subject: Re: Re: [ql-users] Q-Starter Any news on the availability of the official Easyptr 4, Roy? Marcel did mention some time ago he hoped it might be at the AGM, the money for the upgrade is burning a hole in my pocket! Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) Being serious, not much chance of that unless we can trace and get the co-operation of the missing author! Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In message <[EMAIL PROTECTED]>, Dilwyn Jones <[EMAIL PROTECTED]> writes Any news on the availability of the official Easyptr 4, Roy? Marcel did mention some time ago he hoped it might be at the AGM, the money for the upgrade is burning a hole in my pocket! We are hoping for release at the AGM Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) I think you would be taking your life in your hands -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 skype : royqbranch web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> >tried it & got the Qlib error message : > >Line 600 MSTAT% Invalid name > > - an easy ptr extension? > >Can you distribute the easy ptr runtimes with it? > The runtimes are not distributable because they are part of the > commercial package but they can be compiled within the program itself. ...which is where I went wrong I think. Any news on the availability of the official Easyptr 4, Roy? Marcel did mention some time ago he hoped it might be at the AGM, the money for the upgrade is burning a hole in my pocket! Shall we annoy Marcel and tell him he's working on QLiberator next ;-)) (I think that would very quickly be a case of "smack, ouch!") Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: RE: [ql-users] Q-Starter
I thought I had, but will check later. Maybe I put them in and made a mistake with the $$asmb compiler directive. Case of "better luck next time Dilwyn" I think! Thanks for letting me know. Dilwyn Jones > From: "Duncan Neithercut" <[EMAIL PROTECTED]> > Date: 2005/04/04 Mon PM 08:22:08 GMT > To: <[EMAIL PROTECTED]> > Subject: RE: [ql-users] Q-Starter > > Hi, > > tried it & got the Qlib error message : > Line 600 MSTAT% Invalid name > - an easy ptr extension? > Can you distribute the easy ptr runtimes with it? > > Duncan Neithercut > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dilwyn > Jones > Sent: 03 April 2005 22:52 > To: QL Users List > Cc: QL News List > Subject: [ql-users] Q-Starter > > > Q-STARTER > > Q-Starter is a simple experimental program to see if I can > successfully create a program which will run on anything from a QDOS > system with pointer environment to the latest Window Manager 2 and use > the System Palette. It is also my first attempt at writing a program > to use scalable menus. In theory, it ought to display Launchpad-style > menus on systems prior to Window Manager 2, and display System Palette > colour menus on Window Manager 2 systems (SMSQ/E v3.09 or later). I > would welcome feedback on this program, in particular any problems > found in running it on older systems, being as my main "QL" at the > time of writing is a QPC2 emulator! > > Oh, does this program do anything useful? Actually, yes it does. It's > a mini program launcher, which searches for all program files it can > find on your system starting from the drive/directory specified > (optionally reading through subdirectories) and presenting these in a > menu from which you can simply click on the program file to be > executed. Leave it sat in your QPAC2 button frame to have it always > available as a quick if slightly dirty program starter! > > Apologies to Marcel Kilgus for jumping the gun slightly - I've used > the pre-release of Easyptr 4 to creating this program, which is an > experimental release to invite feedback on any shortcomings. My hopes > are that if this program works OK on older and newer systems, I'll be > able to update my existing programs to use the excellent new > facilities of Easyptr 4 as soon as the official release happens. > > I hope plenty of people will download and use Q-Starter (which is > Freeware) and let me know if it works on their systems. My systems > are: > QPC2 v3.30 with SMSQ/E 3b09 > Aurora (MinisQL) with JM ROM (Q-Starter has problems on SMSQ/E v3.06 > for unknown reasons) > > Q-Starter works on QPC2 v3.30 and Aurora with JM QDOS ROM, I'd like to > hear about success or otherwise on other systems. > > Hopefully, experience gained from writing this program will help and > encourage me to write more programs to take advantage of the new > facilities Marcel has worked so hard to bring us! > > http://homepages.tesco.net/dilwyn.jones/software/freeware/freeware.htm > l > > -- > Dilwyn Jones > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 01/04/2005 > > ___ > 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] Q-Starter
In message <[EMAIL PROTECTED]>, Duncan Neithercut <[EMAIL PROTECTED]> writes Hi, tried it & got the Qlib error message : Line 600 MSTAT% Invalid name - an easy ptr extension? Can you distribute the easy ptr runtimes with it? The runtimes are not distributable because they are part of the commercial package but they can be compiled within the program itself. -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 skype : royqbranch web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
RE: [ql-users] Q-Starter
Hi, tried it & got the Qlib error message : Line 600 MSTAT% Invalid name - an easy ptr extension? Can you distribute the easy ptr runtimes with it? Duncan Neithercut -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dilwyn Jones Sent: 03 April 2005 22:52 To: QL Users List Cc: QL News List Subject: [ql-users] Q-Starter Q-STARTER Q-Starter is a simple experimental program to see if I can successfully create a program which will run on anything from a QDOS system with pointer environment to the latest Window Manager 2 and use the System Palette. It is also my first attempt at writing a program to use scalable menus. In theory, it ought to display Launchpad-style menus on systems prior to Window Manager 2, and display System Palette colour menus on Window Manager 2 systems (SMSQ/E v3.09 or later). I would welcome feedback on this program, in particular any problems found in running it on older systems, being as my main "QL" at the time of writing is a QPC2 emulator! Oh, does this program do anything useful? Actually, yes it does. It's a mini program launcher, which searches for all program files it can find on your system starting from the drive/directory specified (optionally reading through subdirectories) and presenting these in a menu from which you can simply click on the program file to be executed. Leave it sat in your QPAC2 button frame to have it always available as a quick if slightly dirty program starter! Apologies to Marcel Kilgus for jumping the gun slightly - I've used the pre-release of Easyptr 4 to creating this program, which is an experimental release to invite feedback on any shortcomings. My hopes are that if this program works OK on older and newer systems, I'll be able to update my existing programs to use the excellent new facilities of Easyptr 4 as soon as the official release happens. I hope plenty of people will download and use Q-Starter (which is Freeware) and let me know if it works on their systems. My systems are: QPC2 v3.30 with SMSQ/E 3b09 Aurora (MinisQL) with JM ROM (Q-Starter has problems on SMSQ/E v3.06 for unknown reasons) Q-Starter works on QPC2 v3.30 and Aurora with JM QDOS ROM, I'd like to hear about success or otherwise on other systems. Hopefully, experience gained from writing this program will help and encourage me to write more programs to take advantage of the new facilities Marcel has worked so hard to bring us! http://homepages.tesco.net/dilwyn.jones/software/freeware/freeware.htm l -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 01/04/2005 ___ 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] Q-Starter
On Mon, 04 Apr 2005 15:06:37 -0400, Malcolm Cadman <[EMAIL PROTECTED]> wrote: By the way QWord has its own Icon with QDT and launches successfully, and drops back into QDT, even though there is a colour mode change on my system. Yes, Jim had the foresight to ask us to create one ahead of time. Ffibys ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: Re: [ql-users] Q-Starter
> >Hopefully, experience gained from writing this program will help and > >encourage me to write more programs to take advantage of the new > >facilities Marcel has worked so hard to bring us! > > > >http://homepages.tesco.net/dilwyn.jones/software/freeware/freeware.html > > Thanks, Dilwyn. I will download a copy this evening. > > I would like a 'new colours' aware version of Launchpad as I run it on > QPC2. It is quite possibly on the agenda! Once I'm happy the techniques I use in QStarter work to my satisfaction, I plan on tackling Launchpad, although it may be a bit more of a job than just redoing the menus, as there's some changes I want to implement for my own use too/ > I have now switched over to QDT as my preferred desktop, yet I am still > using QTrans all time which is launched from an icon in the Util Folder. This was always how it would have been - QDT the system of choice for those with the system necessary to run it, Launchpad for those with older systems. That way, all users were catered for. > This is fun ... now we need software writers to get going with some new > applications. >From what I understand, it'll happen in the near future. I've written some >articles for QL Today on the subject of developing programs using the new >facilities with the new Easyptr when it's released. -- Dilwyn Jones ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] Q-Starter
In message <[EMAIL PROTECTED]>, Dilwyn Jones <[EMAIL PROTECTED]> writes Q-STARTER Q-Starter is a simple experimental program to see if I can successfully create a program which will run on anything from a QDOS system with pointer environment to the latest Window Manager 2 and use the System Palette. It is also my first attempt at writing a program to use scalable menus. In theory, it ought to display Launchpad-style menus on systems prior to Window Manager 2, and display System Palette colour menus on Window Manager 2 systems (SMSQ/E v3.09 or later). I would welcome feedback on this program, in particular any problems found in running it on older systems, being as my main "QL" at the time of writing is a QPC2 emulator! Oh, does this program do anything useful? Actually, yes it does. It's a mini program launcher, which searches for all program files it can find on your system starting from the drive/directory specified (optionally reading through subdirectories) and presenting these in a menu from which you can simply click on the program file to be executed. Leave it sat in your QPAC2 button frame to have it always available as a quick if slightly dirty program starter! Apologies to Marcel Kilgus for jumping the gun slightly - I've used the pre-release of Easyptr 4 to creating this program, which is an experimental release to invite feedback on any shortcomings. My hopes are that if this program works OK on older and newer systems, I'll be able to update my existing programs to use the excellent new facilities of Easyptr 4 as soon as the official release happens. I hope plenty of people will download and use Q-Starter (which is Freeware) and let me know if it works on their systems. My systems are: QPC2 v3.30 with SMSQ/E 3b09 Aurora (MinisQL) with JM ROM (Q-Starter has problems on SMSQ/E v3.06 for unknown reasons) Q-Starter works on QPC2 v3.30 and Aurora with JM QDOS ROM, I'd like to hear about success or otherwise on other systems. Hopefully, experience gained from writing this program will help and encourage me to write more programs to take advantage of the new facilities Marcel has worked so hard to bring us! http://homepages.tesco.net/dilwyn.jones/software/freeware/freeware.html Thanks, Dilwyn. I will download a copy this evening. I would like a 'new colours' aware version of Launchpad as I run it on QPC2. I have now switched over to QDT as my preferred desktop, yet I am still using QTrans all time which is launched from an icon in the Util Folder. This is fun ... now we need software writers to get going with some new applications. By the way QWord has its own Icon with QDT and launches successfully, and drops back into QDT, even though there is a colour mode change on my system. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[ql-users] Q-Starter
Q-STARTER Q-Starter is a simple experimental program to see if I can successfully create a program which will run on anything from a QDOS system with pointer environment to the latest Window Manager 2 and use the System Palette. It is also my first attempt at writing a program to use scalable menus. In theory, it ought to display Launchpad-style menus on systems prior to Window Manager 2, and display System Palette colour menus on Window Manager 2 systems (SMSQ/E v3.09 or later). I would welcome feedback on this program, in particular any problems found in running it on older systems, being as my main "QL" at the time of writing is a QPC2 emulator! Oh, does this program do anything useful? Actually, yes it does. It's a mini program launcher, which searches for all program files it can find on your system starting from the drive/directory specified (optionally reading through subdirectories) and presenting these in a menu from which you can simply click on the program file to be executed. Leave it sat in your QPAC2 button frame to have it always available as a quick if slightly dirty program starter! Apologies to Marcel Kilgus for jumping the gun slightly - I've used the pre-release of Easyptr 4 to creating this program, which is an experimental release to invite feedback on any shortcomings. My hopes are that if this program works OK on older and newer systems, I'll be able to update my existing programs to use the excellent new facilities of Easyptr 4 as soon as the official release happens. I hope plenty of people will download and use Q-Starter (which is Freeware) and let me know if it works on their systems. My systems are: QPC2 v3.30 with SMSQ/E 3b09 Aurora (MinisQL) with JM ROM (Q-Starter has problems on SMSQ/E v3.06 for unknown reasons) Q-Starter works on QPC2 v3.30 and Aurora with JM QDOS ROM, I'd like to hear about success or otherwise on other systems. Hopefully, experience gained from writing this program will help and encourage me to write more programs to take advantage of the new facilities Marcel has worked so hard to bring us! http://homepages.tesco.net/dilwyn.jones/software/freeware/freeware.html -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 01/04/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
