PrivateEye 3.20 ready for testing

I always thought “cretin” was from Latin, and meant “a Christian”…

That might explain some of the unbelievably stupid output from Hans Christian Horner regarding the team budget

Is fench bread made in Fance?

Yes, but only at the end of a long tiring week.

I always thought “cretin” was from Latin, and meant “a Christian”…

The things you learn on the ROOL forum!

The OED agrees, and goes into a bit more detail. The original meaning was “a person whose mental and physical development has been impaired by a deficiency of thyroid hormone in fetal or early life” which has now evolved to a general term for a stupid person.

from French crétin, from Swiss French crestin ‘Christian’ (from Latin Christianus), here used to mean ‘human being’, apparently as a reminder that, though deformed, cretins were human and not beasts.

For my ROM based Iyonix, Using Zap, I copied the existing .09 module to Predesk, rebooted and run the patch, then repeated step one. The new module (in Predesk) is 1340 bytes vs 1320.
May be better ways, but with RISC OS 5.30 coming, it will do.
Seems the new module sitting in Predesk would be sufficient, just have to remember to take it out after new OS is installed.

The new module (in Predesk) is 1340 bytes vs 1320.

My patch should not alter the size of the DragAnObject module!

Was PrivateEye locking up on the Iyonix, Ronald?

but only at the end of a long tiring week.

Sadly, mine is still going.

My alarm will go off in about ten minutes. 😪

Stuart, OK perhaps the 5.28 iyonix version of the module is different and does not need patching? I never tried the new PrivateEye when 26bit code in draganobject was mentioned, thinking it had been there since RiscPC days.

The new patch is a succes! My congrats to Stuart, for that particular magic that I will never understand. One question however: how do I make the change permanent?

My other congrats are for David Th. !PrivateEye impresses me severely, and has now a permanent place on my icon bar.

26bit code in draganobject

Which is only used if SWI XOS_LeaveOS fails! I was surprised to see the offending instruction not conditionally assembled.

how do I make the change permanent

Please don’t try to do this! This is just a temporary bandage to get affected users through to a fixed 5.29 & eventual 5.30. You don’t want to be leaving cruft like this in your Boot structure.

As nobody else has said that they are doing it so far, I will work up an official patch to submit to ROOL GitLab. [Here it is: https://gitlab.riscosopen.org/RiscOS/Sources/Desktop/DragAnObj/-/merge_requests/1]

Here it is

Thanks for doing that.

Built here and working.

Built here and working.

Thanks for verifying!

I created a bug report (https://www.riscosopen.org/tracker/tickets/568) so hopefully it won’t be overlooked.

Just a quick update – finally had time to remember to test 3.20. Can confirm that the corruption issue around the pointer seems to be fixed, so almost certainly Tinct-related. Great stuff :)

Spoke too soon. Using “convert to sprite” option (for a JPEG) resulted in a corrupt rectangle under cursor.
So, to be clear, viewing the JPEG initially was fine, but when I pressed menu and clicked “Edit→Convert to sprite” there was a rectangle block under the pointer that wasn’t redrawn.
There’s a chance this is a beta graphics driver issue (I was testing on Pinebook Pro), so probably not worth wasting time on now, but just to be aware of.

Here’s the second release candidate which should hopefully make the image cache a lot better behaved:

https://github.com/dpt/PrivateEye/releases/download/privateeye-3.20-3/PrivateEye-3.20-rc2.zip

Changes over rc1:

• The cache was rewritten to cope better in low memory situations. All images are now requested through the cache. There’s now a limit of 128 entries in the cache (= total open images). If this is a problem then set “cache.entries” to a larger value in Choices.
• Choices cache size value is now shown in MBytes.

Fixed DragAnObject 0.10 appears in the today’s nightly build for Pi. [Was Bug #568]

Here’s the third release candidate:

https://github.com/dpt/PrivateEye/releases/download/privateeye-3.20-4/PrivateEye-3.20-rc3.zip

Changes over rc2:

• Filer’s Help menu entry now launches the StrongHelp manual.
• Tweaks to manual.
• Fix: Windows jumping downwards when stepping between images, etc.
• Fix: Incorrect centimetre sizes.

I note rc2 had some cache changes, but having set Cache Size in Choices to 200 MB, when I display (now with rc3) approx 25 jpegs with an average size of 5MB, the cache rises with each display to around 128MB … and then increases no further, just oscillating around that figure. However, the initial abort with rc1 has now gone. I did try adding cache.entries:200 to PrivateEye.Choices, but that had no effect.

Thanks for the improvements, and opening the manual from the menu.

It’s probably hitting the dynamic area size limit.

Should the Dynamic Area limit be set the same as the Choices size? Many modern machines have lots of meory to spare.

PrivateEye is requesting the system default value for its dynamic area’s max size and receiving however much address space that the OS clamp is currently set to (e.g. 128M). You can fiddle with the !Run file and set PrivateEye$DALimit to a non-zero value but you probably still hit the clamp.

It’s the problem of address space exhaustion.

PrivateEye ought to be using the huge WimpSlot on RO5, but I need to solve some crashes when that’s enabled.

Hopefully David won’t mind me posting that rc 6 is out now.

https://github.com/dpt/PrivateEye/releases/download/privateeye-3.20-6/PrivateEye-3.20-rc6.zip

Changes are as for PrivateEye 3.20 rc 2 plus:

Filer’s Help menu entry now launches the StrongHelp manual.
Tweaks to manual.
Fix: Windows jumping downwards when stepping between images, etc.
Fix: Incorrect centimetre sizes.

Sorry, yes: I found that rc3 had been archived incorrectly so prepared rc6.

Released! Many thanks for those who beat it with their respective sticks.

http://www.davespace.co.uk/blog/20221119-privateeye-320.html