Page 3 of 6

Re: New QLiberator v3.37

Posted: Wed Mar 18, 2020 9:00 pm
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.

Re: New QLiberator v3.37

Posted: Sun Mar 29, 2020 7:18 pm
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 75 times

Re: New QLiberator v3.37

Posted: Sun Mar 29, 2020 7:59 pm
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,

Re: New QLiberator v3.37

Posted: Sun Mar 29, 2020 10:56 pm
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!

Re: New QLiberator v3.37

Posted: Mon Mar 30, 2020 11:02 am
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.

Re: New QLiberator v3.37

Posted: Mon Mar 30, 2020 11:35 am
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.

Re: New QLiberator v3.37

Posted: Wed Apr 01, 2020 5:18 pm
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.

Re: New QLiberator v3.37

Posted: Wed Apr 01, 2020 5:38 pm
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.

Re: New QLiberator v3.37

Posted: Wed Apr 01, 2020 8:21 pm
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..

Re: New QLiberator v3.37

Posted: Thu Apr 02, 2020 12:26 pm
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