Adding ResEdit and ResTest to riscpkg site

I would like to make the latest ResEdit and ResTest applications available from the RISC OS Packaging Project site (www.riscpkg.org).

If I’ve read the Castle licence correctly I should just be able to put the binary packages up with a copy of the licence in the applications directory. Has anyone any objections to me doing this?

I believe that on another thread someone had started creating some packages for the applications. If they have already done these two applications, could they let me know where I can get the control files they have already created from.

You can’t, because ROOL are lazy. ;-P

I have a large selection of packages here, auto-created from descriptor files, ResEd and ResTest (as well as the little-known lost cousin, ResCreate) among them.

The only caveat I’m aware of is that each has a dependency on the ‘ROLicence’ package, which should be distributed with them.

None of the packages have actually been tested yet, so don’t be surprised if they don’t work!

You can get them at:

http://mbazley.drobe.co.uk/rescreate_0.06.zip http://mbazley.drobe.co.uk/resed_0.51.zip http://mbazley.drobe.co.uk/restest_0.74.zip http://mbazley.drobe.co.uk/rolicence.zip

(I assume uploading them like this is OK - if not, someone let me know and I’ll remove them.)

Thanks Martin – these packages look like just what I need. I’ll try to test them over the next few days.

I’ve only had a brief look, but the one thing I would suggest is changed is the rolicence package. I’m not sure what a better name would be but CastleLicence or SharedLicence or something like that.

Also can you either rename the PDF file similarly or put it in a sub directory called CastleLicences or something like that just so it’s clear what it is when you see it on your disk. The file only needs to be renamed for the package you don’t need to do anything to ROOLs original copy.

Once I’ve tested these and you’ve decided if you will change the ROLicence package or not I will upload them to the riscpkg site unless someone objects in the next week (or whenever I’m ready – whichever is later).

Martin – There’s a problem with the Sprites definitions in the ResEd/ResTest packages.

<ResEd$@Apps.!ResEd>.!Sprites

<Packages$@Apps.!ResEd>.!Sprites

If you ever want to try these yourself you can just drag the zip file to the iconbar of !RiscPkg or !PackMan and they get added to the list so you can install them. Remember to drag the dependencies (i.e. ROLicence) first.

As these two aren’t part of the main RISC OS files any chance of moving them down into the Apps.Development directory?

You need to use Packages at the beginning of the line instead of the application name. e.g. You have for the !resedit sprite.

<ResEd$@Apps.!ResEd>.!Sprites

which should be

<Packages$@Apps.!ResEd>.!Sprites

Erm, not according to the RiscPkg policy manual. Pertinent paragraph reproduced below:

When specifying the content of a system variable or the location of a sprite file it may be necessary to translate a logical pathname to a physical pathname. This is done using an extension of the syntax implemented by OS_GSTrans:

logical-pathname-reference = '<', package-name, '$', '@', logical-pathname, '>';

For example, the logical path Apps.Admin.!RiscPkg within the package RiscPkg would be expressed as:

<<a href="mailto:RiscPkg$@Apps.Admin">RiscPkg$@Apps.Admin</a>.!RiscPkg>

As these two aren’t part of the main RISC OS files any chance of moving them down into the Apps.Development directory?

As for renaming ‘ROLicence’, that would require rebuilding all the packages and changing the build program, which in turn would require me to send ROOL the updated copy, which opens up all sorts of unpleasant synchronisation possibilities. Now that I’m sure nothing’s actually broken, I think I’d prefer not to muddy the waters.

Martin,

I’ve looked at the part of the manual and I agree it’s unclear or even downright confusing. In fact I think I would have come to the same conclusion as you if I had tried to create a package from it.

However what I’ve stated as a correction is what you need to do. I’ve checked the LibPkg source code to make sure I was correct. I’ve been using this combination for a while and I guess I probably got it from looking at existing packages rather than the manual.

(I was going to try an explain what I thought the documentation might be getting at, but I’d probably just make things more unclear.)

You may want to contact Graham Shaw at the packaging project and ask him to clarify the policy document.

Good point about the build system and Apps.Development. I doubt I’d have any luck with ROOL on that change and as it was only a personal preference, you can ignore it.

I still think the package name and file name for the licence is confusing, but it was only a suggestion so feel free to ignore it as well.

Any chance of creating new ResEdit/Test/Create packages with the sprites change that is needed so I can test/use them?

I’ve looked at the part of the manual and I agree it’s unclear or even downright confusing.

That’s a very generous way of putting it indeed. The term I would have used is “utter bollocks”.

I downloaded a package (UnixFonts) from riscos.info to check, and it did indeed use the name ‘Packages’.

Now, at this point I would have conclusively confirmed the veracity (or not) of the manual by downloading the example provided itself, and checking if that really was the same syntax used in that particular package. I was unable to do so, because riscpkg.org is down. Whoopee.

Anyone got a copy of the original RiscPkg package that I can check?

Meanwhile, as for your suggestion that I drag the files onto RiscPkg: the result was ‘Control file not found’. I initally thought this was a reflection on my packages, until I obtained exactly the same result with the aforementioned UnixFonts.

PackMan was more successful, almost installing ResEd until it reached ‘updating sprite pool’, which produced an infinite loop of “File name ’.!Sprites11’ not recognised” from “Uncaught Exception”, which required Alt-Break. I haven’t had the guts to try it with UnixFonts yet.

Anyway, I’ve updated the ResEd link above as per your request, even though I can’t validate it. Not sure what you meant by ResTest (that one doesn’t have any sprites).

Martin,

Thanks for the updated ResEd, it works a treat. I think I kept getting errors once I had messed it up with !ResEd so got confused about ResTest.

You may need to delete

!Boot.Resources.!Packages.BootSprite11++

<<a href="mailto:Packages$@Apps.Admin">Packages$@Apps.Admin</a>.!RiscPkg>.!Sprites

I think there have been some problems with the riscpkg web site server, but I believe they are being worked on. I had problems with it last week. It has always been working again when I tried the next day.

Thanks again these packages are exactly what I wanted.

I’ll work on getting them on the riscpkg site early next week. (It’s not difficult, but I want to give anyone here a chance to object to me doing so).

EDIT: ...WTF, Beast?

I guess you’re after this:

<RiscPkg$@Apps.Admin.!RiscPkg>

After much trial and error I arrived at

<pre><code></code>@<RiscPkg$@@Apps.Admin.!RiscPkg></pre>

Trevor thanks for figuring out how to get it to display correctly.

I was after

<Packages$@Apps.Admin.!RiscPkg>

as the point was it was using Packages rather than RiscPkg.

I’m impressed you managed to find the magic incarnation that worked. I tried all sorts of things yesterday with no luck.

I’ve now added the ROLicence, ResEd, ResTest and ResCreate packages to the riscpkg site so they can all be downloaded using !RiscPkg or !PackMan.

I think this is a good test to show that the applications can be packaged and distributed in this way.

Martin – one thing I didn’t notice until after I uploaded them is that it would probably be nicer if you added the package version to the end of the package version. (i.e. just put ”-1” after the version number, the application version stays unchanged). This allows for the packaging to be changed when the application version hasn’t.

Thanks for that. A next step would be for me to find some time to use your packages as an example and get a build set up where all of the main apps are built into packages. As I’m already planning on spending some time re-visiting the build that generates all of the pre-built stuff (modules and apps) I’ll probably wrap it all up into one big chore^HH^HH^H activity.