The Sinclair QL Forum

The latest QLiberator is here.

This addresses the limit on the number of assembler files that can be locally included.
There had to be a limit in the past so that Qlib could DIM 3 arrays to hold the details.
Our later versions have an additional preprocessing pass, so this is used to count up the number of assembler files seen.
The arrays can then be DIM'd accordingly. This effectively makes the number of files that can be included unlimited.

EmmBee

Thanks a lot, Michael!

EmmBee wrote:The latest QLiberator is here.

This addresses the limit on the number of assembler files that can be locally included.
...This effectively makes the number of files that can be included unlimited.

Unlimited, I like that. Thanks.

BSJR

Nice work, EmmBee

I just did a rudimentary test with 17 small toolkits. It appeared to work!

I found one minor bug: If you start QLib 3.43 and then quit immediately without adding a file name it barfs with an error 11, Variable undefined. V3.42 doesnt do this.

A pity you did not see fit to include Qlib_run V3.42 as, AFAICS, it is an improvement on Qlib_run336mod - at least for SMSQ/E users.

Thanks for this! What comes next?

pjw wrote:Nice work, EmmBee

I just did a rudimentary test with 17 small toolkits. It appeared to work!

I found one minor bug: If you start QLib 3.43 and then quit immediately without adding a file name it barfs with an error 11, Variable undefined. V3.42 doesnt do this.

A pity you did not see fit to include Qlib_run V3.42 as, AFAICS, it is an improvement on Qlib_run336mod - at least for SMSQ/E users.

Thanks for this! What comes next?

Hi,

Thanks for the feedback.

The minor bug was caused by something that looked wrong to me, so I opted to put it right. Turns out that I was wrong. I'll retract this adjustment in the next release.

About Qlib_run V3.42, to be honest, this must've slipped my mind, as I was focused on the assembler files limit. But yes, it should have been included. Rest assured this will be included the next time.

So, what is coming next? I do have one idea ... Every time I compile a Qlib program, I usually get a Warning of Variable used for channel number. In this modern-day and age, everyone is using variables for their channels, especially with the commands available in TK2. There's nothing wrong with using variables for channels, and there's nothing that can be done about it, anyway. So, I am voting to disable this message, this should be a welcome change, I believe.

On looking over our source code, I realise that this is the code that came from the decompile. It probably was not written this way. For example, an IF statement covering 3 lines was undoubtedly originally a single-line construct. All this can be converted back. I can probably write a program to automate the process. There are several ON GOTOs scattered around, and these can be converted to use a SELect ON construct to make these lines more readable - and thus more understandable. I have already started on this, but there is still some way to go. Once we have a more readable program, this will hopefully pave the way to understanding how the machine code routines operate. For example, the work file may be open to #4, but does NEXT_TOKEN know about this? It could be reading from another channel - who knows?

Anyway, we do have another update in the offing. In the meantime, has anyone any requests for changes, if so, please let us know.

EmmBee

Even the earliest SB programs used a variable for channels, so it really makes no sense to do a warning. I do not know, if Liberation has used "ON...GOTO", but I do not hope it. Changing that to "SELECT ON" is likely to take a lot of effort.

Would be interesting to hear Martin, if his de-compiler seems to change "SELECT ON" things to "ON...GOTO".

RalfR wrote:Would be interesting to hear Martin, if his de-compiler seems to change "SELECT ON" things to "ON...GOTO".

No it does not. Qlib is the only program I have come across that uses ON..GOTO. I remember having to figure out how it worked, and wondered why it had been used instead of SELect.

pjw wrote:I just did a rudimentary test with 17 small toolkits. It appeared to work!

Would be interesting to know, why George Gwilt also has taken just 8 extension files to incorporate in Turbo programs.

RalfR wrote:

pjw wrote:I just did a rudimentary test with 17 small toolkits. It appeared to work!

Would be interesting to know, why George Gwilt also has taken just 8 extension files to incorporate in Turbo programs.

Probably because he was asked to provide a similar facility to that in QLiberator and just used the same number.