The Sinclair QL Forum

Artificer wrote: Tue Jan 21, 2025 6:50 pmFrom the Qlib error reports, if the reports are reasonably accurate, one of the issues Qlib has with copyback is with string and array manipulation. Turbo has fixed sizes for arrays and strings unlike Qlib. C programs also have declaired sizes for these.

So maybe you should size all strings?

RalfR wrote: Tue Jan 21, 2025 8:32 pm

Artificer wrote: Tue Jan 21, 2025 6:50 pmFrom the Qlib error reports, if the reports are reasonably accurate, one of the issues Qlib has with copyback is with string and array manipulation. Turbo has fixed sizes for arrays and strings unlike Qlib. C programs also have declaired sizes for these.

So maybe you should size all strings?

Turbo reminds you to DIM your strings with every compilation run.

Artificer wrote: Tue Jan 21, 2025 3:47 pm Alas after bodging qtrans and qdock and patching the resident qlib runtimes and rebooting the Q60 with copyback enabled neither worked giving up the ghost with QLIb error messages.

Thanks for trying and reporting. These are my favorite QLiberated programs by the way.

Artificer wrote: Tue Jan 21, 2025 6:50 pm From the Qlib error reports, if the reports are reasonably accurate, one of the issues Qlib has with copyback is with string and array manipulation. Turbo has fixed sizes for arrays and strings unlike Qlib. C programs also have declaired sizes for these.

But why should dynamic string/array manipulation collide with copyback cache? The data cache does not care about fixed size or not. Must be self-modifying executable code again.

Peter wrote
But why should dynamic string/array manipulation collide with copyback cache? The data cache does not care about fixed size or not. Must be self-modifying executable code again.

I agree that is the question. My thinking from the error messages QLib produces is that dynamic management strings/arrays of data by the QLib pseudo interpreter runtime system may move data while cached code is to process the same data. Hence flushing the cache can only be part of a solution.

As far as the suggestions of recompiling with turbo or using fixed sizes for arrays QLib etc, yes I am already on board and started with those suggestions which will take time but naturally these won't sort programs written by others like qdock.

Cheers

We don't know whether the error occurs when compiling or when the program is running.

Artificer wrote: Tue Jan 21, 2025 3:47 pmQtrans with line 4760 index out of range and qdock with line 4874 string is not numeric.

The two lines reported as errors are (according to Dilwyn) REMark lines. Maybe the QLib got confused with the error display.

Artificer wrote: Wed Jan 22, 2025 8:09 am My thinking from the error messages QLib produces is that dynamic management strings/arrays of data by the QLib pseudo interpreter runtime system may move data while cached code is to process the same data.

Moving data as wildly as you like is no problem for copyback cache, as long as the executable code ist not changed.
The problem ist that QLiberator does just that, AKA self-modifying code. This is very likely also the case here.

RalfR wrote: Wed Jan 22, 2025 12:52 pm

Artificer wrote: Tue Jan 21, 2025 3:47 pmQtrans with line 4760 index out of range and qdock with line 4874 string is not numeric.

The two lines reported as errors are (according to Dilwyn) REMark lines. Maybe the QLib got confused with the error display.

Or Artificer did not test the same Q-Dock version.

Peter wrote: Wed Jan 22, 2025 1:16 pmOr Artificer did not test the same Q-Dock version.

Which is v1.01.

I have Q-dock v 1.00 which is the identical version to the Q-dock version that is downloadable tonight from Dilwyn Jones site. I would not put much value on the QLib crash reports line numbers as I have found in my own software as Dilywn has that the actual line numbers may not contain code relevant to the error type. On the other hand the error type might be relevant.

Cheers