Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
Plastic wrote: Apologies for the off-topicness, but one thing I'd like to see from Turbo or other compilers is a command maker that can take a PROCedure or FuNction, compile it, and package it up so it can be loaded to extend BASIC. Works with QLib (and also Turbo, I think). With QLib, if you start such a resident extension, it results in creating a JOB (even if without windows), so I think, not quite what you want. Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
On Fri, Jan 28, 2011 at 5:33 AM, Ralf Reköndt ralf.rekoe...@t-online.dewrote: Plastic wrote: Apologies for the off-topicness, but one thing I'd like to see from Turbo or other compilers is a command maker that can take a PROCedure or FuNction, compile it, and package it up so it can be loaded to extend BASIC. Works with QLib (and also Turbo, I think). With QLib, if you start such a resident extension, it results in creating a JOB (even if without windows), so I think, not quite what you want. Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Yes, not. I was thinking specifically of it creating superbasic extensions deliberately for that purpose, to be LRESPR'd and linked into the keyword list. It would make for an interesting website to host, where people could submit keywords with manual entries, and release updated versions, etc. The commands could be coded in native assembly, or in BASIC, with sources or not. Where sources were offered, people could check for errors, or offer enhancements/patches. By extending this to existing keywords, skilled people could make functionality or performance enhancements that could then feed back into the OS. I would be happy to code and host such a site, if there was interest. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
- Original Message - From: Norman Dunbar nor...@dunbar-it.co.uk To: ql-us...@q-v-d.com Sent: Thursday, January 27, 2011 11:51 AM Subject: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ? I may regret starting this, but as the subject says, what would you like to see in QDOSMSQ given that we were starting from scratch with the intention of writing a completely new OS? Disclaimer: No, I'm NOT thinking of writing one! For me, the following: * Ability to hook into the OS from any language, Basic, Assembler, C, whatever. * A windowing system that is simple to use. From any language. * Libraries that applications can link to at run time, as opposed to static linking at compile time. * Multitasking, obviously! * A file system that is not restricted to 36 characters. See http://qdosmsq.dunbar-it.co.uk/blog/2009/05/whats-wrong-with-this-file-system/ for a pseudo-rant on the matter. * Industry standard floating point format. * Industry standard graphics format(s) - PNG, for example. JPG if we must! SVG would be nice. * Speed and efficiency! ;-) Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm I would like to be able to do something like: LET a=PI PRINT #3,HEX$(a) which would write an ASCII string of the form $ which would be the internal representation of the floating point value. In reverse, something like: INPUT #3,a$ LET a=REAL(a$,0) would recover the original value. The second argument is the value to be returned if the first argument is garbage or NAN. Omitting the second argument would return an error instead. Why do I want this? PUT writes in binary. An ASCII representation would allow the full internal precision to be preserved in an easily viewed/edited format. I know this could be done in S*BASICusing PEEK/POKE but an efficient built-in would be useful. Ian. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
On 28 Jan 2011, at 13:28, Ian Pine wrote: I would like to be able to do something like: LET a=PI PRINT #3,HEX$(a) which would write an ASCII string of the form $ which would be the internal representation of the floating point value. In reverse, something like: INPUT #3,a$ LET a=REAL(a$,0) would recover the original value. The second argument is the value to be returned if the first argument is garbage or NAN. Omitting the second argument would return an error instead. This is something I would like too. In my BOOT i have a procedure which prints a given a$, but the format of the fp number is QDOS. For example a$ could be $080004000. Of course in QDOS there are no NANs. I'm pretty sure that my BOOT also has the reverse procedure, but either I never use it or I have not used it for along time. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
On Fri, Jan 28, 2011 at 9:09 AM, gdgqler gdgq...@gmail.com wrote: This is something I would like too. In my BOOT i have a procedure which prints a given a$, but the format of the fp number is QDOS. For example a$ could be $080004000. Of course in QDOS there are no NANs. I'm pretty sure that my BOOT also has the reverse procedure, but either I never use it or I have not used it for along time. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm Hmmm. a$ = CONVERT$(number, from_base, to_base) from_base and to_base could be eg: 2, 10, 16, FP (for floating point) If the conversion was invalid, simply leave a$ unset or to an impossible value. a$ could be commuted to a if the value was decimal - which would be explicit to the programmer. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
Know what? Call me outdated, but I'm just about fine with what I have. I'm particulary fine with size, overhead and speed of both the OS and Basic. I'm fine that our OS (and windowing system) is ASM-centric, and that's the only reason I still use it. (Have you ever tried to do Windows or X11/Gnome/KDE/Cocoa/whatever-Programming in assembler? B. I'm fine that the OS is open for extension and (somewhat) well documented, sources are available. And I might be quite a back number, but I still like the streamlined M68k assembler most. I never really got down to using another language (except the odd S*Basic Program) on my QLs, even if I do the very same on other systems for a living.) Summing up all what you guys describe, boils down near a decent Windows/Linux/MacOS (with all the overhead and hardware requirements they've got plus a huge implementation task - And - you'd be ending up with just another clone of those, thank you). QDOSSMSQ's shine stands and falls with the slim design without any overheads in my opinion. I can very well trade in some functionality and ease of use for that. Ahhm, yes, there's one thing I'm missing every now and then - portable BitBlt functionality to do fast raster graphics using bitmaps. You can to some extent use huge sprites, but you cannot portably read them back from screen. And every other now and then I seem to be missing symbolic debugging tools with what they used to call source line debugging back then. Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
gdgqler wrote: * A windowing system that is simple to use. From any language. This also is true of SMSQE Ahem...he meant *simple*... ;-) Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
On 27 Jan 2011, at 15:14, Ralf Reköndt wrote: * A windowing system that is simple to use. From any language. This also is true of SMSQE Ahem...he meant *simple*... ;-) Yes . . Well . I've tried Visual Basic and I very much prefer ... TurboPTR. (And also Assembler, after prodding by Norman.) George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
gdgqler wrote: It seems dangerous to me to rely on a routine which might have changed since the last time you looked at it. How can you know that the next time your program runs it won't produce different or faulty results because the DLL now contains something different? Hmm, this seems to work in Windows...and ... why not? A routine to decode i.e. an JPG just needs to be once in such a system. OK, Photon works well, no question. I would like to enhance my database of VHS videos with a picture. So, I have to (re-)write my own encoder for a JPG...and I am not able to do so. And so have others. That's why noone have inbuilt JPG (or other formats) in their programs. Would be better as a kind of THG% in the system. Cheers...Ralf ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version ofQDOSMSQ?
Hi Ralf, Would be better as a kind of THG% in the system. I see you beat me to it! However, that is in the existing QDOSMSQ system. A brand new one may decide to implement the JPEG Thing differently, perhaps. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
