Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
On 25 Oct 2002, at 23:58, Tony Firshman wrote: How about someone being appointed as a name server. Anyone adding to QDOS/SMSQ for general release should register the name with one person. Well, François van Emelem is IT!!! Wolfgang
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
On Mon, 4 Nov 2002 at 08:57:21, wrote: (ref: 3DC63671.8337.69C9FBlocalhost) On 25 Oct 2002, at 23:58, Tony Firshman wrote: How about someone being appointed as a name server. Anyone adding to QDOS/SMSQ for general release should register the name with one person. Well, François van Emelem is IT!!! Great. What is his email? I don't seem to have him on the Ql emailshot list - at least no 'emelem' -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tonysurname.demon.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
- Original Message - From: Tony Firshman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 04, 2002 9:06 AM Subject: Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website On Mon, 4 Nov 2002 at 08:57:21, wrote: (ref: 3DC63671.8337.69C9FB@localhost) On 25 Oct 2002, at 23:58, Tony Firshman wrote: How about someone being appointed as a name server. Anyone adding to QDOS/SMSQ for general release should register the name with one person. Well, François van Emelem is IT!!! Great. What is his email? I don't seem to have him on the Ql emailshot list - at least no 'emelem' Would that be the famous QL rapper then All the best - Bill -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.demon.co.uk http://www.firshman.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
In a message dated 25/10/02 17:12:18 GMT Daylight Time, [EMAIL PROTECTED] writes: I have thought about this, and here's how I would solve the problem. Just make it a standard that a toolkit looks for an existing instance of the keyword, and if it is in use, alter the keyword in a standardised way. Eg: WIBBLE ITEM tk9_WIBBLE ITEM jms_WIBBLE ITEM But that's just me. HM! Well! What would happen to a standard program needing WOBBLE which was changed to WABBLE by this process? Actually, both Qlib and Turbo are (or very soon will be) able to "include" the extensions really needed in the program so that they do not need to be LRESPRd at run time. Although this makes for longer programs compiling them might help to solve the problem of 72 keywords all called WYBBLE and all doing different things. George
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
Dave P writes: Just make it a standard that a toolkit looks for an existing instance of the keyword, and if it is in use, alter the keyword in a standardised way. Bit of a pain that if what all you wanted to do was to redefine a keyword - a common occurance during toolkit development, for example. The simple solution is to run SBasic code that requires its own toolkit(s) in a separate instance of SBasic. When you are finished with it, kill the job and the extensions go away. Also, when you compile a program with the toolkit included with the program code (now also possible with Turbo, I believe) this does not affect keywords loaded into any instance of SBasic, including job #0. For those rare instances not covered by either of the above, ie when you want a keyword globally available that clashes with the name of another global keyword, the simplest may be to patch a copy of the toolkit file. You can call the offending keywords whatever you like as it will only affect you. The only problem I have with this issue is when I try to run an SBasic program containing DEFined keywords that clash with my default set of keywords. I then normally manually rename all instances of the keyword in the source and save the patched file with a new name. This can be quite fiddly and time consuming. Per
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
Wolfgang Lenerz wrote: On 24 Oct 2002, at 14:20, Norman Dunbar wrote: PS. Well, it has been quite here over the last couple of days - is anybody out there ? I think the usual answer is :no, there isn't... Wolfgang - www.wlenerz.com Wrong, I am. But there isn't much going on, is there?And I really don't care how people configurate their 'browser' or 'email composer'( too many messages, if you ask me). I'm not complaining about them, I just delete them. What I'd like to see, from time to time on the list, is a progress report (progress?) about SMSQE. What has already been done, what will be added, updated, when can we expect a new version, will Sbasic still be part of it or will it become a separate module,...? Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? An example to illustrate this? I've just discovered W. Lenerz' ARRAY_BIN. Nice extension, but unuseable. Why? It contains 'sort' and 'search' and these words are already present in other extensions that I use every day.( reset, search,sort,count,lower$,upper$,... are used in at least 3 toolkits/extensions ... and they aren't compatible). Why not adopt the approach used in 'ProWeSs' and 'ProForma', where all the functions and procedures have meaingful names and all start with 'PW_' or 'PF_' ? Of course, this isn't very important for most of you,I know, but my programming skills are limited to Sbasi, so I really need those Toolkits/Extensions. And now, back to listening mode for a while, I suppose. François Van Emelen
RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? Interesting. I've been thinking about the same thing recently. And not just confined to clashing toolkits. By extending SBASIC in an uncontrolled manner you run the risk of older programs not being able to run properly because the names of procedures and functions they define happen to use clashing names. Ironically, the design concept of SBASIC to allow this extensibility could well become its biggest weakness for distributable 3rd party software utilities. Not a problem when you only run your own code because you are in complete control. Apart from appointing a registrar to allocate name prefixes (but then, how would you police their use?) I can only think of radical solutions to the problem, which would involve fundamental changes to the concept of SMSQ/E and SBASIC. Ian -Original Message- From: François Van Emelen [mailto:francois.vanemelen;chello.be] Sent: 25 October 2002 12:55 To: [EMAIL PROTECTED] Subject: Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website SNIP Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? An example to illustrate this? I've just discovered W. Lenerz' ARRAY_BIN. Nice extension, but unuseable. Why? It contains 'sort' and 'search' and these words are already present in other extensions that I use every day.( reset, search,sort,count,lower$,upper$,... are used in at least 3 toolkits/extensions ... and they aren't compatible). Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
??? 25/10/2002 9:34:47 ??, ?/? [EMAIL PROTECTED] ??: Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? Interesting. I've been thinking about the same thing recently. And not just confined to clashing toolkits. By extending SBASIC in an uncontrolled manner you run the risk of older programs not being able to run properly because the names of procedures and functions they define happen to use clashing names. Ironically, the design concept of SBASIC to allow this extensibility could well become its biggest weakness for distributable 3rd party software utilities. Not a problem when you only run your own code because you are in complete control. Apart from appointing a registrar to allocate name prefixes (but then, how would you police their use?) I can only think of radical solutions to the problem, which would involve fundamental changes to the concept of SMSQ/E and SBASIC. Ian A mechanism could be devised to rename same name extensions when a conflict exists Phoebus
RE: RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
A solution would be to have a core set of commands always present in the system and others loaded as independant modules to meet local requirement. Old extensions present only for compatibility would also became a module (toolkit ?) to avoid usage in future. But we need someone/somewhere an official keyword list to avoid conflicts. Claude -Message d'origine- De : [EMAIL PROTECTED] [mailto:phoebus;dokos-gr.net] Envoyé : vendredi 25 octobre 2002 16:05 À : [EMAIL PROTECTED] Objet : Re: RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website ??? 25/10/2002 9:34:47 ??, ?/? [EMAIL PROTECTED] ??: Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? Ian A mechanism could be devised to rename same name extensions when a conflict exists Phoebus
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
What is needed is some way to load toolkits locally to a particular instance of SBasic rather than as system wide global settings. As to whether anyone could think of a way to enhance SBasic to achieve this is another matter. Dave - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 25, 2002 2:34 PM Subject: RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? Interesting. I've been thinking about the same thing recently. And not just confined to clashing toolkits. By extending SBASIC in an uncontrolled manner you run the risk of older programs not being able to run properly because the names of procedures and functions they define happen to use clashing names. Ironically, the design concept of SBASIC to allow this extensibility could well become its biggest weakness for distributable 3rd party software utilities. Not a problem when you only run your own code because you are in complete control. Apart from appointing a registrar to allocate name prefixes (but then, how would you police their use?) I can only think of radical solutions to the problem, which would involve fundamental changes to the concept of SMSQ/E and SBASIC. Ian -Original Message- From: François Van Emelen [mailto:francois.vanemelen;chello.be] Sent: 25 October 2002 12:55 To: [EMAIL PROTECTED] Subject: Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website SNIP Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? An example to illustrate this? I've just discovered W. Lenerz' ARRAY_BIN. Nice extension, but unuseable. Why? It contains 'sort' and 'search' and these words are already present in other extensions that I use every day.( reset, search,sort,count,lower$,upper$,... are used in at least 3 toolkits/extensions ... and they aren't compatible). Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
Marcel Kilgus wrote: Dave Walker wrote: What is needed is some way to load toolkits locally to a particular instance of SBasic rather than as system wide global settings. As to whether anyone could think of a way to enhance SBasic to achieve this is another matter. Easy: just lrespr it within the particular SBASIC instance. The commands will NOT show up in the other instances. Marcel This isn't a solution for the 'words clashes', I'm afraid. Let me take an example to illustrate this: I'd like to use W. Lenerz' 'array_bin' because it allows me to save arrays to a file( and load them from one). 'Array_bin' contains 'search'(to find a string in an array). The program I'm working on needs Howells' 'Dbas_sys'(database engine) which also contains 'search'(to find the content of a field). Both 'search' are incompatible. So, it is impossible to use the features of both extensionsin the same Sbasic program. François Van Emelen
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
On Fri, 25 Oct 2002 at 13:54:45, François Van Emelen wrote: (ref: [EMAIL PROTECTED]) Speaking of Sbasic... Wouldn't it be nice to avoid 'word clashes' by following some kind of convention? An example to illustrate this? I've just discovered W. Lenerz' ARRAY_BIN. Nice extension, but unuseable. Why? It contains 'sort' and 'search' and these words are already present in other extensions that I use every day.( reset, search,sort,count,lower$,upper$,... are used in at least 3 toolkits/extensions ... and they aren't compatible). Why not adopt the approach used in 'ProWeSs' and 'ProForma', where all the functions and procedures have meaingful names and all start with 'PW_' or 'PF_' ? How about someone being appointed as a name server. Anyone adding to QDOS/SMSQ for general release should register the name with one person. -- QBBS (QL fido BBS 2:252/67) +44(0)1442-828255 tony@surname.demon.co.uk http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
François Van Emelen wrote: Easy: just lrespr it within the particular SBASIC instance. The This isn't a solution for the 'words clashes', I'm afraid. Of course. I didn't say it is. Marcel
RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
Ian, thanks for pointing out my URL error, you are quite correct it should be : http://www.bountiful.demon.co.uk/qdos/index.html As to where the hard disc information lives - I believe it is usually on the very first sector of the disc (same as floppy) which, for the life of me, I cannot remember if it is at address 0 or 1. I think it is 1 but I'm not 100% sure. Cheers, Norman. PS. Nepal - that is a bit 'out of the country' :o) - Norman Dunbar Database/Unix administrator Lynx Financial Systems Ltd. mailto:Norman.Dunbar;LFS.co.uk Tel: 0113 289 6265 Fax: 0113 289 3146 URL: http://www.Lynx-FS.com - This email is intended only for the use of the addressees named above and may be confidential or legally privileged. If you are not an addressee you must not read it and must not use any information contained in it, nor copy it, nor inform any person other than Lynx Financial Systems or the addressees of its existence or contents. If you have received this email and are not a named addressee, please delete it and notify the Lynx Financial Systems IT Department on 0113 2892990.
RE: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
On 24 Oct 2002, at 14:49, [EMAIL PROTECTED] wrote: Must send my SMSQ source CD back to Wolfgang so I can get the updated one. I'm ready... Wondering whether Jochen is about. I emailed him about the Qmake disk I bought at the Byfleet show but have not had a reply. I'm pretty sure that if you haven't had a reply he hasn't got your email. he generally is pretty responsive. Just looking at the hard disk details. On a disk with a single QWA partition on it, which physical sector would that information be found in? the very first sector. wolfgang - www.wlenerz.com
Re: [ql-users] a small but perfectly formed update to QDOS INTERNALS website
Ian Pine writes: Just looking at the hard disk details. On a disk with a single QWA partition on it, which physical sector would that information be found in? The QWA file system normaly has its Primary Partition Table at sector 0. To check: open#3; win1_*d2d get#3\0; sec$: close#3 print sec$(1 to 4) If that shows QLWA then youre looking directly at your hard disk partition (a QXL.WIN-type FAT) If it says QWA youre looking at the QL PPT. To find your QLWA FAT you need to get its starting sector out of the primary partition table: start_sector = $1c7 + win_no * 12 Check the location at start_sector to see that you got a QWA flag (rather than GEM, LNX, etc). For a single partition my guess is it would be located at sector #1, but this would depend on what program was used to create the partition table(s) and how it was created, as the GEM partitioning scheme (on which QWA is based) allows for plenty of flexibility. However, I suspect, only a small subset has been implemented in the Qx0 version of SMSQ/E, and a lot of that is, lets say, in the early stages of development (SMSQ/E v 2.9x). Per
