New QLiberator v3.37

Anything QL Software or Programming Related.
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: New QLiberator v3.37

Post by RWAP »

Great news - glad to have played my part in this (having tracked down the Liberation team and obtained their permission)...

Good to see some further development.


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

Re: New QLiberator v3.37

Post by EmmBee »

Hi everyone,
We now consider the next round of improvements, bug fixes, etc. Here is the list so far ...


+ Add a binary-chop method to detect_screen_limits, defined at line 32524. The extra speed gained should lead to the compiler starting up almost instantly!

+ Use environment variables to record the front panel position. The compiler and Patch program will now appear at the same place, even outside of 512x256. Attached is a zip file to fully explain environment variables.

+ Patch program line 3880: Rename unsigned_PEEK_L to unsigned_long_input, which is a more accurate description. Additionally, there is an error in this piece of code. The number 65535 needs to be 65536, which is 2^16. Currently, if a user sets a heap space or stack value of 2^16 or higher, the Patch program, if used, because of the error, will display a value of one byte less. Unless the user changes this value to an even number, the QL will crash when running the compiled object file. The reset button then needs to be pressed.

+ The maximum value of heap has increased from half a megabyte to 999999; however, that is an odd number and would crash the QL. We need to change that value to one less, 999998. See Patch program line 5100 edit_panel.

+ For error trapping, QLIB uses Q_ERR, but does not always follow the rule of testing Q_ERR immediately, and once only, after being used. Afterwards, Q_ERR goes to zero, with the outcome of misleading error messages or no messages at all. To cure the problem, assign Q_ERR to a variable, then test the variable. See line 22640: a more appropriate message here is “Error “ & e.

+ Literal strings, those delimited by quote marks, are limited to a maximum of 512 chars. Any further chars get ignored, with no error message given. It is easy to check for this and provide an error message. The check could be added in at line 32598 in the procedure convert_hex_bin_tokens.

+ Patch: At line 1990 check_win is a procedure that does absolutely nothing. I thought we might use this to check that the filename ends with “_obj”, and if not then supply it.

+ Per Witte has reported that while one of his programs works perfectly with the original v3.36, it errors on v3.37. He is currently investigating the problem with Martin Head, and I wish them well in their efforts. Depending on what they find, there may have to be some further changes to the code.


The above is the list so far. Would you like to add to this list? You can supply code or just suggest ideas. All comments and suggestions are welcome. We have the source code now, and so anything is possible. If we all agree, the plan is to make this update in about a week or so.

As mentioned earlier, to give everyone a foretaste of what’s to come, I attach the zip file on environment variables.
environment_variables.zip
(16.46 KiB) Downloaded 74 times


User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: New QLiberator v3.37

Post by RalfR »

As far as I have found out (long time ago), Q_ERR_ON on "AT" does not work. I once got an unrecoverable error from QLib itself of this,


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

Re: New QLiberator v3.37

Post by pjw »

Impressive!

Still working on the issue with different output of V3.36 and V3.37. Thats to say, Im producing the problem and Martin has been trying to solve it!

My biggest wish for a Qlib update is for a $30 char job name length!


Per
dont be happy. worry
- ?
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: New QLiberator v3.37

Post by Martin_Head »

pjw wrote:Impressive!

Still working on the issue with different output of V3.36 and V3.37. Thats to say, Im producing the problem and Martin has been trying to solve it!

My biggest wish for a Qlib update is for a $30 char job name length!
I would think that's possible. But you may have to have a special runtime module, and Qlib_patch program. This could cause problems when having 'old' and 'new' compiled programs running at the same time.


User avatar
dden
ROM Dongle
Posts: 43
Joined: Thu Jan 19, 2017 8:56 am

Re: New QLiberator v3.37

Post by dden »

Martin, thank you ever so much for all the hard work you've put into the decompilers, and to EmmBee for producing the new QLiberator.

I tend to lurk here rather than participate, but during the current situation I am using my QL and QPC2 quite a lot to keep myself occupied at home. The work you and everyone else puts into keeping the QL community going is greatly appreciated.


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

Re: New QLiberator v3.37

Post by EmmBee »

Martin_Head wrote:
pjw wrote:Impressive!

Still working on the issue with different output of V3.36 and V3.37. Thats to say, Im producing the problem and Martin has been trying to solve it!

My biggest wish for a Qlib update is for a $30 char job name length!
I would think that's possible. But you may have to have a special runtime module, and Qlib_patch program. This could cause problems when having 'old' and 'new' compiled programs running at the same time.
You'll probably have to update QLIB_USE as well. Even currently, the Job Name length seems to be limited to a maximum of about 22 chars. Any more and it goes wrong.


User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: New QLiberator v3.37

Post by RalfR »

EmmBee wrote:
Martin_Head wrote:
pjw wrote:Impressive!

Still working on the issue with different output of V3.36 and V3.37. Thats to say, Im producing the problem and Martin has been trying to solve it!

My biggest wish for a Qlib update is for a $30 char job name length!
I would think that's possible. But you may have to have a special runtime module, and Qlib_patch program. This could cause problems when having 'old' and 'new' compiled programs running at the same time.
You'll probably have to update QLIB_USE as well. Even currently, the Job Name length seems to be limited to a maximum of about 22 chars. Any more and it goes wrong.
If this is in QLIB_BIN, ask MK, as he said that he has dissassembled all of the ASM stuff of QLiberator (as far as I remember...). So perhaps he can help.


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

Re: New QLiberator v3.37

Post by pjw »

EmmBee wrote:
Martin_Head wrote:
pjw wrote:Impressive!

Still working on the issue with different output of V3.36 and V3.37. Thats to say, Im producing the problem and Martin has been trying to solve it!

My biggest wish for a Qlib update is for a $30 char job name length!
I would think that's possible. But you may have to have a special runtime module, and Qlib_patch program. This could cause problems when having 'old' and 'new' compiled programs running at the same time.
You'll probably have to update QLIB_USE as well. Even currently, the Job Name length seems to be limited to a maximum of about 22 chars. Any more and it goes wrong.
Actually, Martin has already written a simple patch which stretches a compiled job so it can take a 48 char name! :)
I have been testing it today and it seems solid. However, I havent had time to really stress test it yet.
Since its not my code I havent shared it, but I dont suppose Martin minds me announcing it..


Per
dont be happy. worry
- ?
User avatar
BSJR
Trump Card
Posts: 182
Joined: Sun Oct 18, 2015 12:53 pm
Location: Amsterdam
Contact:

Re: New QLiberator v3.37

Post by BSJR »

EmmBee wrote:Hi everyone,
We now consider the next round of improvements, bug fixes, etc. Here is the list so far ...
As a big fan of Qlib I must congratulate all who contribute to this project.
I have not yet tested it but would like to see a few issues fixed in any final 3.37.

1. The INSTR_CASE keyword as featured in SMSQ/E is not working in 3.36, no error is reported but its setting is ignored and the behaviour of INSTR is not changed.
2. A missing name after an END FOR, which is allowed in SBasic, prevented a compiled version of my program from running.
It kept me searching for weeks and was in the end found by Wolfgang Lenerz.
Normally it's not a feature I would use but as it's allowed it should be accepted by Qlib for END FOR (& END REP & NEXT) or at least produce an alert at compile time.

BSJR


Post Reply