QLiberator v3.41

Anything QL Software or Programming Related.
EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

QLiberator v3.41

Post by EmmBee »

We have a new version of QLiberator.

Some recent discussions have centred around attaching REMarks to the top line of FOR loops. Here is an example ...

Code: Select all

100 FOR n = 1 TO 7 : REMark
110   PRINT n
120 END FOR n
Per Witte has pointed out that this is only allowable with SMSQ/E. On other systems such as QDOS, Minerva, etc. the REMark is illegal, with line 100 becoming a single-line FOR loop.
With SMSQ/E this would printout 1 2 3 4 5 6 7
Other systems would just printout 7 with line 120 being ignored – clearly unwanted behaviour.

Besides FOR, this type of error can also occur with REPeat, IF, SELect and WHEN constructs.

The new version of QLiberator checks for such REMarks. If the system is SMSQ/E then this is allowed, otherwise, an error is reported at the compile stage. The line number is clearly shown, allowing the programmer to move the REMark to somewhere else.

While checking all this, I came across some other minor bugs which I was able to sort out. Some variables have also been renamed – to make them more understandable. For details, see the README file.

EmmBee
Qlib_341.zip
(98.46 KiB) Downloaded 87 times


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: QLiberator v3.41

Post by Derek_Stewart »

EmmBee wrote:We have a new version of QLiberator.

Some recent discussions have centred around attaching REMarks to the top line of FOR loops. Here is an example ...

Code: Select all

100 FOR n = 1 TO 7 : REMark
110   PRINT n
120 END FOR n
Per Witte has pointed out that this is only allowable with SMSQ/E. On other systems such as QDOS, Minerva, etc. the REMark is illegal, with line 100 becoming a single-line FOR loop.
With SMSQ/E this would printout 1 2 3 4 5 6 7
Other systems would just printout 7 with line 120 being ignored – clearly unwanted behaviour.

Besides FOR, this type of error can also occur with REPeat, IF, SELect and WHEN constructs.

The new version of QLiberator checks for such REMarks. If the system is SMSQ/E then this is allowed, otherwise, an error is reported at the compile stage. The line number is clearly shown, allowing the programmer to move the REMark to somewhere else.

While checking all this, I came across some other minor bugs which I was able to sort out. Some variables have also been renamed – to make them more understandable. For details, see the README file.

EmmBee

Qlib_341.zip
Hi,

Thank you for an excellent update to Qliberator.

I had a problem with the LIBERATE command, which could not find the compiler, which in this version the compiler is called: QLIB_BAS_341.obj

The LIBERATE command seems to be expecting the compiler filename to be QLIB_OBJ.

Renaming this to: QLIB_OBJ, all works fine.

Can the compiler filename be set with an environmental name?


Regards,

Derek
EmmBee
Trump Card
Posts: 240
Joined: Fri Jan 13, 2012 5:29 pm
Location: Kent

Re: QLiberator v3.41

Post by EmmBee »

Derek_Stewart wrote: Renaming this to: QLIB_OBJ, all works fine.
Thanks, Derek

Here is a zip with the names changed to Qlib_obj and Qlib_patch_obj
Qlib_3.41.zip
(98.43 KiB) Downloaded 81 times


User avatar
dilwyn
Mr QL
Posts: 2753
Joined: Wed Dec 01, 2010 10:39 pm

Re: QLiberator v3.41

Post by dilwyn »

Thank you EmmBee.


User avatar
Sparrowhawk
Super Gold Card
Posts: 624
Joined: Wed Dec 15, 2010 12:33 pm
Location: @131072
Contact:

Re: QLiberator v3.41

Post by Sparrowhawk »

Thanks for continuing to develop and enhance this great software.


a.k.a. Jean-Yves
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QLiberator v3.41

Post by pjw »

EmmBee wrote:We have a new version of QLiberator.
<>
Thanks EmmBee, for keeping Q-Liberator alive and kicking!

I should probably have mentioned this before, but I was only inspired
to look into the matter more sytematically due to your recent update.

The problem bothering me is that QLib refuses to compile my programs
containing hexadecimal or binary numbers!

Actually it turns out that it does. Here you can follow my doleful
path to enlightenment (Examples tested on SMSQ/E only):

Code: Select all

100 PRINT $1234
110 PAUSE
SAVE ram1_test_bas
QSAVE
LIBERATE

Enter ram1_test_sav into the QLib console. Ensure 'Winds' is off.
Click 'Compile'
Error: Needs _wrk file - not a _sav

So RENAME ram1_test_sav to ram1_test_wrk and enter that name into the
console and compile.
Error: File not found

So RENAME ram1_test_wrk to ram1_test_bas_wrk and enter that name into
the console and compile.
Error: File not found

Alter the name to ram1_test_bas in the console and try again.
BINGO!

EXecute the resulting _obj file: You get the default, black SBASIC
daughter job window with 4660 printed in the top left corner, as
expected.

Now do a LIBERATE ram1_test_bas,
(Note the terminating comma!) It should compile fine, so EXecute
ram1_test_obj:

Now you get the same 4660 printed in white on red in the TLC of your
screen, which you can check is console #1 of QLib's default windows
(despite Winds being switched off).

My preferred method for QLib-compiling stuff is to use the first
method described (above, under the code): Make a change to the code,
QSAVE. Click Compile. Test. Repeat. But clearly that doesnt work if
the source code contains binary or hex numbers.

The simplest fix, to my mind, would be to allow QLib to compile _sav
files with hex and binary numbers directly. _sav files and _wrk files
are virtually identical. (Different by one byte?)


Per
dont be happy. worry
- ?
duncan
ROM Dongle
Posts: 49
Joined: Tue Aug 15, 2017 5:08 pm

Re: QLiberator v3.41

Post by duncan »

Hi Per,

PRINT $1234 = PRINT HEX(1234) : As yo know the function HEX is in TK2 and so should run on any system as TK2 is now freely available.

I have no idea if this would not work with your preferred method of compiling with QLIB. I prefer composing in QD, testing under QBASIC and then loading the tested code into the SBASIC interpreter to pick up all my mistakes before using LIBERATE and then hotkeying up QLIB_obj to compile, but it should work for you.

This and the in line REMark problem are a consequence of QLiberator being written for Superbasic.
If Qliberator is developed for more compatibility with SBASIC should that separate the compiler into 2 versions, one for smsq/e and one for Superbasic?

Anyway EmmBee thank you for your continuing work with Qliberator, it is much appreciated here especially with the ability to use larger screens.

Cheers


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QLiberator v3.41

Post by pjw »

duncan wrote:Hi Per,

PRINT $1234 = PRINT HEX(1234) : As yo know the function HEX is in TK2 and so should run on any system as TK2 is now freely available. <>
Hi Duncan, Thanks for your input, but that isnt what this is about. In
SBASIC you can use hexadecimal and binary numbers directly as literal
constants in the source code. (Many good reason for that, Im sure you
agree!) The SBASIC parser converts these numbers to its internal
format, ie 48-bit floats, the same as any other literal number you
enter. The only difference is that they are marked with a different
token, mainly so SBASIC can accurately re-create the original listing.

Q-Liberator since V3.37 understands these new tokens. It doesnt have
to do anything special with them as the constant it refers to is the
same, and the resulting compiled code is identical, whether the
constant was entered in dec, bin, or hex. Ie no Qdos incompatibility
results from this.

SBASIC source code containing such constants is however not acceptable
to SuperBASIC. You can easily make it so, though: See my DeHex
program at Knoware.no. It simply skips through your tokenised program
in memory and alters the hex/bin tokens to decimal ones.

Using the HEX("1234") construct for constants doesnt seem a good idea
to me. Where you cant use bin/hex constants (ie SuperBASIC & MBASIC)
it would be better to use something like:

Code: Select all

num = 4660: REMark $1234
rather than

Code: Select all

num = HEX("1234")
In the second case the number must be converted and go through the
function mechanism (perhaps numerous times) at runtime, while $1234
entered directly in the code is only ever parsed and converted once -
namely as you enter the number in your code! Besides, it looks neater
:) (The only bit I dont like is that leading zeros are removed..)


Per
dont be happy. worry
- ?
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: QLiberator v3.41

Post by NormanDunbar »

pjw wrote: ...
num = HEX("1234")

In the second case the number must be converted and go through the
function mechanism (perhaps numerous times) at runtime, while $1234
entered directly in the code is only ever parsed and converted once -
namely as you enter the number in your code!
I agree, sort of!

In the case of a constant being defined, then either version is adequate as both will require parsing once.

In the case of a variable being assigned numerous hex values as the program progresses, then yes, there will be a difference. The hex() function will have to parse the digits at run time, while the $1234 variant will be parsed as "compile" time when the number is actually typed into the program/interpreter.

I have to say that I much prefer the $1234 variant over HEX('1234') -- but I do assembly and the odd occasional Pascal, where hex values are written that way. ;)


Just sticking my oar in again, usually where it's not wanted or needed! :D


Cheers,
Norm. [Tired, due to our new puppy dominating our lives at the moment!)


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QLiberator v3.41

Post by pjw »

NormanDunbar wrote:
pjw wrote: ...
num = HEX("1234")
<>
I agree, sort of!
<>
No, Norm, I agree with you. You said what I wanted to say. I just tangled my prose.
NormanDunbar wrote:Just sticking my oar in again, usually where it's not wanted or needed! :D
Keep rowing, Norm!
NormanDunbar wrote:<>
[Tired, due to our new puppy dominating our lives at the moment!)
All too soon youll look back with melancholy nostalgia.. ;)


Per
dont be happy. worry
- ?
Post Reply