BSJR wrote:
One would hope that if it's valid for SMSQ/E it should be valid for Qlib too.
Yes, I would have thought so too, but apparently, it's not so.
What Qlib does is to take the text of the Basic program and interpret it in its own way. We have to remember that Qlib was written in the days of QDOS. I have just now tried the program using a JS ROM on Q-emuLator. Running under the Interpreter, it stops at line 240 with a bad name error.
All of this is further proof that SMSQ/E is a great improvement over QDOS. It gets things right while Qlib cannot keep up.
Since there are many people still using their BBQLs and QDOS, probably best to leave Qlib as it is.
Thats not a problem (for me!). Strings always use $, why not. If SMSQ/E do it otherwise, ok, but I have it learned the other way. The "8 $$asmb" restriction seems to be more important as it is not possible, just to put several files with "RPM" or TT's "BOOT_MAKE" together (as far as I know). QLib has to know how to initialize each.
BSJR wrote:I have not yet used any of the Qlib 3.37+ versions but reading the Readme file up to 3.42 no mention is made of the $$asmb= limits and I cannot remember if it has been addressed before.
Only 8 code files can be added this way at compile time. Is it possible to extend this limit in 3.43?
In the Qlib manual, Release 3.36, page 56, it states "The directive $$asmb may reference up to 8 modules containing extensions.
Each module can contain any number of procedures or functions."
I dont know if this could be extended, but it isnt really a limitation as the number of commands each toolkit can contain is "unlimited". You could, I presume, use Qlib's RPM utility to lump a number of toolkits together as one.
Per
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen
That slogan has rather sad connotations for me. Used by former QL luminaries who have now, sadly, defected to the dark side..
Wish, I could understand this.
I was referencing a number of people who signed off with "QL forever" or "SMSQ/E forever" and then defected to other systems. Those who became too ill or died are, of course, heartily forgiven
Per
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen
RalfR wrote:<>
The "8 $$asmb" restriction seems to be more important as it is not possible, just to put several files with "RPM" or TT's "BOOT_MAKE" together (as far as I know). QLib has to know how to initialize each.
Our message crossed.
AFAIK, provided there are no special initialisation routines other than bp.init, RPM should work. Special initialisation routines are relatively rare. Anyone needing more than eight toolkits with special initialisation requirements should consider dissembling those toolkits and merging them manually. Or somethink.
Per
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen
Agreed Have you tried it with RPM? I always thought (and think) that QLib needs the BP.INIT of every embedded MC-extension. But what, if they are put one after another, link with RPM or BOOT_MAKE?
RalfR wrote:Agreed Have you tried it with RPM? I always thought (and think) that QLib needs the BP.INIT of every embedded MC-extension. But what, if they are put one after another, link with RPM or BOOT_MAKE?
Hmm, youre right. RPM just chains all the toolkits together and adds code to jump to the bi_inipr of each. Qlib doesnt appear to recognise this arrangement, and no mention is made in either manual to say that its possible to $$asmb an RPM'ed toolkit despite all the noise about its versatility. A missed opportunity to my mind - or an unfinished feature? I dont know if MAKE_BOOT does things differently, like combing the various name tables into one..
So we're back with the eight toolkit limitation. I cant say Ive ever had a problem with that. As some of you may know, I make ad hoc toolkits for each project. Most of my toolkits are single, or a few closely related, commands designed to easily be strung together according to need. This cuts down on bloat and is simple to do. You dont need to know assembler to use them, only how to add them and link them. They are freely available you-know-ware!
Per
I love long walks, especially when they are taken by people who annoy me.
- Fred Allen
Well, accepting that strings need to have a "$" sign in SuperBASIC is maybe obvious, but omitting a nice feature of the QL - Untyped procedures and functions. The QLiberator distribution has a nice example for this feature - a sorting function that can sort strings, floating point numbers and integers, all with the same piece of code (I guess they added this to the set of example programs to distinguish from Turbo, which cannot compile stuff like that).
I'm not even sure whether this was actually an intended feature in SuperBASIC or just "works by accident" - I've not found a single mention of this technique in the manuals, but it works nicely.
RalfR wrote:Agreed Have you tried it with RPM? I always thought (and think) that QLib needs the BP.INIT of every embedded MC-extension. But what, if they are put one after another, link with RPM or BOOT_MAKE?
Hmm, youre right. RPM just chains all the toolkits together and adds code to jump to the bi_inipr of each. Qlib doesnt appear to recognise this arrangement, and no mention is made in either manual to say that its possible to $$asmb an RPM'ed toolkit despite all the noise about its versatility. A missed opportunity to my mind - or an unfinished feature? I dont know if MAKE_BOOT does things differently, like combing the various name tables into one..
So we're back with the eight toolkit limitation. I cant say Ive ever had a problem with that. As some of you may know, I make ad hoc toolkits for each project. Most of my toolkits are single, or a few closely related, commands designed to easily be strung together according to need. This cuts down on bloat and is simple to do. You dont need to know assembler to use them, only how to add them and link them. They are freely available you-know-ware!
MAKE_BOOT works nice for LRESPR, not for Qlib which needs all name defines in one place.
My SQRview program uses now 15 toolkits from various sources so I wrote a little program that merges several tools together and makes a new combined define header, skipping the original defines.
But when making changes or adding a new tools I need to merge the whole block again. Some toolkits have their defines at the end which need negative jumps, which my tool cannot handle yet. So more $$asmb's would have been more convenient.
X$ versus X: The Jan Jones book (chapter 4) states that arguments of DEF PROC/FN are always replaced by the actual parameters, including the types. So it appears it's already a QDOS feature.
tofro wrote:I'm not even sure whether this was actually an intended feature in SuperBASIC or just "works by accident" - I've not found a single mention of this technique in the manuals, but it works nicely.
I think you are referring to coercion? In which case, I'm sure it was in the original manual and pretty sure Jan Jones mentions it in her book.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
Have you tried it with RPM? I always thought (and think) that QLib needs the BP.INIT of every embedded MC-extension. But what, if they are put one after another, link with RPM or BOOT_MAKE?
