HardDisc4 has missing files in !Printers

Both of the HardDisc4 images on the following page:
https://www.riscosopen.org/content/downloads/other-zipfiles
have files missing from the included !Printers so it will not run.

However version 1.75 of !Printers on the following page:
https://www.riscosopen.org/content/downloads/desktop-zipfiles
contains the missing !Boot !Run !RunImage etc files and needs to be copied over the top of the version from the HardDisc4 image.

Alan

Thanks for the heads-up. The disc-based components are always a PITA because a) we don’t build them as often and b) it’s harder to spot when something has broken – which it often does.

I really, really need to get around to updating all of the pre-built components which are hosted on our site. They are very out-of-date now and probably very few of them are ARMv7 safe.

Well, I’ve rebuilt and uploaded lots of components. This is the first step of a few more steps – but at least it’s a start and most things are fully up-to-date, if perhaps not built for the ARMv7 platform yet.

Th problem has repeated itself – the latest HardDisc4 has an incomplete set of files in !Printers (empty other than a lot of folders, all of which except PDumpers and Modules are themselves empty)

OK. I probably need to bodge the AutoBuilder to load !Printers before doing the Disc build because if you don’t do that, then !Printers fails to build. Talk about chicken and egg…

I probably need to bodge the AutoBuilder to load !Printers before doing the Disc build

It should be doing that already, although I’ll admit I can’t remember how recently I checked that it worked properly!

rmensure freeway rmload <Build$Dir>.Modules.Freeway
AMU: File ‘HostFS:$.Build.Modules.Freeway’ not found

This is probably why it’s failing. I’m having a stab at fixing it today.

Right, all fixed. The HardDisc4 archives on the web site have !Printers back to its former glory.

Jeffrey: FYI, I inserted an “RMReInit Freeway” into the ‘script’ Obey file (after the apps are filer_booted, but clearly the position doesn’t matter too much) in the autobuilder.

OK, cheers. From looking at the PrinterManager makefile it looks like it may only need all those modules loading in order to allow the ‘squish’ tool to perform SWI name → number translation. I don’t suppose you’ve got a non-squished version of squish anywhere, have you? I’m thinking that it should be possible to improve it so that it can use a file (e.g. swis.h as generated by clib) to perform SWI number lookup instead of relying on OS_SWINumberFromString.

Yes, you’re correct about squish. That’s a good idea – but I’ve no idea if a ‘source’ version of squish still exists. I’ll do some digging – although I think this should be lower on our priority lists than other stuff that we could be looking at.

Understood!

:)

I needed something to help me keep my sanity while waiting for builds, so over the past few days I’ve un-squished the squish binary and produced some moderately readable source code:

http://www.riscosopen.org/viewer/view/castle/RiscOS/Tools/Sources/Squish/

Still plenty of work to do, but it’s a good start!