Q_Liberator malaise

[dilwyn]

https://dilwyn.theqlforum.com/qdock/qdock101.zip
Been there since 24/08/24 but nobody had noticed/reported the broken link.

Contains bug fixes reported by Peter at that time and compiled with the latest QLiberator and Easyptr at that time - see UPDATES_DOC in the zip file.

Just replace qdock_obj and updates_doc in your existing setup, and possibly use Config or MenuConfig to set (1) default directory, and (2) whether or not to use Home Directory thing.

QDock 1.01

[Artificer]

Thanks Dilwyn for the link to Qdock v1.01, its a great application. I have infortunately found a bug in the settings menu when I changed the printer port setting from PAR to SER. The line to be edited appeared lower down the menu. Nothing serious and there was a least one other setting that showed change further down the menu. That has nothing to do with the copyback, bodging or patching.

Going on to copyback Qdock v 101 sadly like its predecessor does not like copyback. When booting with copyback on with patched runtimes and Qdock bodged to disconnect its runtimes the program typically fails to open its windows, no error messages. If copyback is turned on after the system has booted qdock appears and all seems well until programs are launched. The most repeated fault is that its window locks up, cursor goes to locked. Other that that it did complain once string is not numeric but no line number, and another time Line 2291 OPEN_IN.

Cheers

[dilwyn]

OK, removed the update for now until I can get time to fix the issue.

Just wondering with the Cache malaises, should I withdraw all my software until this is all sorted? Converting large front-end programs like Q-Dock, Launchpad and Q-Bar to Turbo is going to be far too much work, it would be easier to write new programs from scratch since we're fumbling in the dark with this issue and I don't think I have a machine with Cache to experiment on (not that I have time to do so anyway).

[pjw]

<>
Just wondering with the Cache malaises, should I withdraw all my software until this is all sorted? Converting large front-end programs like Q-Dock, Launchpad and Q-Bar to Turbo is going to be far too much work
..<>

Of course not! How many people use Q40/Q60 for any serious work anyway? Two? Four? Im sure they'll happily forego Q-Dock and most other modern programs. It works fine on all other systems and emulators which most people use.

Eventually the Qlib issue will be sorted and we can all move on.

[Artificer]

pjw wrote
Of course not! How many people use Q40/Q60 for any serious work anyway? Two? Four? Im sure they'll happily forego Q-Dock and most other modern programs. It works fine on all other systems and emulators which most people use.

Eventually the Qlib issue will be sorted and we can all move on.

I agree, there is no need, Dilwyn, to remove your excellent software or for anyone to stop using QLiberator. The cache problem is at least 2 decades and a bit more old. The solution for those of us who are fortunate to have a Qx0 is to run with caches set to writethrough when using QLIB or otherwise use Turbo, assembled or C compiled programs.

Despite writethrough reducing the speed of execution markedly, even crippled as Peter says, the Q60 is still the fastest bit of QL like hardware and fun to use.

Cheers

[Derek_Stewart]

No existing software should be withdrawn especially as such high quality as Q-Dock

[Peter]

Just wondering with the Cache malaises, should I withdraw all my software until this is all sorted?

Of course not.

But since using QLiberator brings no speed advantage, I wonder if we could work out a way to use your software in an uncompiled fashion, should fixing QLiberator fail. I understand that you do not wish to publish your sourcecode, which is perfectly okay. But if there was a way to obfuscate the sources, could you image to re-release a few of your programs uncompiled?

Im sure they'll happily forego Q-Dock and most other modern programs.

No I do not "happily forego Q-Dock". As already I wrote, I like Dilwyn's programs a lot and would be glad to run them without hindrance on my Q60.

And for me it is less about the historic machines, more about a potential new 68060 hardware development and the motivation for that huge effort. The work only makes sense to achieve the fastest possible native machine, not something running half speed.

[dilwyn]

But since using QLiberator brings no speed advantage, I wonder if we could work out a way to use your software in an uncompiled fashion, should fixing QLiberator fail. I understand that you do not wish to publish your sourcecode, which is perfectly okay. But if there was a way to obfuscate the sources, could you image to re-release a few of your programs uncompiled?

I'll think about this to see if it's easy enough to do without too much change to the programs.

I'm already aware of a few issues which would need to be addressed for both Qdock and Launchpad to run as interpreted SBASIC jobs rather than compiled executables. Current versions of both Launchpad and QDock sources can't run as SBASIC job, they were developed in Job 0 BASIC with no thought given to running as stand-alone SBASIC jobs at the time.
Ideally, I'd like to get the sources to a position where it's easy to make and maintain both single-file executables (for most users) and one which runs as an SBASIC job until the cache issues are resolved.

Launchpad in particular is a decades old program which ideally needs a brand new version to bring it up to date, if ever I have the time, energy and motivation. I think of Launchpad as "QL bloatware" after two decades of changes, though it continues to work better after two decades than I expected it to.

The real problem for me is my current mental exhaustion - ongoing very draining family issues and very severe insomnia since having 'flu in December - and just sheer lack of time (never retire, you just end up getting busier than ever).

I'd probably need to stipulate that apart from genuine bug reports I'd not enter into any correspondence at all about the sources - tinker with it and you're on your own. That's the real reason for not releasing sources so far - fear of what happens when people start to tinker beyond their abilities. That way, there's no need to 'obfuscate' sources.

While we initially try to focus on finding any issue with Q-Liberator, I'll see if I can use that time to get my sources into a suitable condition that I can produce both versions fairly easily. Knowing my luck, when I do, the QLib issue will be resolved!

No existing software should be withdrawn especially as such high quality as Q-Dock

Why, thank you Derek, very kind of you!

Can I please make a polite request? That with this thread, you all try to make it clear you're going on about the "QLib versus Cache" subject, not just running down my software. I've had messages asking me 'when I'm going to fix my programs', as if it's my fault. Focusing on QDock seems to have conveyed to people that it's a fault in my program for some reason, whereas in truth I know we're trying to first resolve any possible issues with QLib (assuming there are any!) before we move on to specific individual software. That's why I offered to withdraw the software - "I can do without this" - I'm fragile at the moment, and writing this in a rare moment in January when I've felt up to writing in response to something like this.

[Peter]

I'll think about this to see if it's easy enough to do without too much change to the programs.

Many thanks. I was just curious - not trying to burden work on you at this time. It is better to wait for a possible QLib fix first.

Focusing on QDock seems to have conveyed to people that it's a fault in my program for some reason, [...]

That QDock drew more attention just comes from the fact that it's one of the best peaces of QLiberated software.
Dilwyn's programming is not at fault in any way.

[RalfR]

@Mark & Artivicer:

The problem with the caches and QLib programs should actually also exist with QDOS classic on the Qx0, or is the behavior different to SMSQ/E?

What if you start QLib programs with copyback cache and Qmon switched on? Is there a message from Qmon? Qmon is sometimes very sensitive.