Modules and dates

Most relocatable modules contain a date in their help string, which may or may not coincide with the datestamp of a file in which it is distributed. I have just uploaded two applications, DateSpy and DateSet, accessible from http://www.wra1th.plus.com/throw.html concerning dates of relocatable modules. The first lets you compare them, the second lets you reset the file’s datestamp to the date in the help string. To use them, put a copy into a directory and doubleclick it. They will scan all the modules in the same directory and its subdirectories and subapplications, recursively. It will cope with up to 9999 modules, but it may be rather slow if the directory has a lot of objects – everything has to be scanned to see if it has type &FFA, i.e. is a module :{.

It will cope with up to 9999 modules, but it may be rather slow if the directory has a lot of objects – everything has to be scanned to see if it has type &FFA, i.e. is a module :{.

Have you tried it on the extreme case: drop into !boot and run. Running in RPCEmu it counts 5 in seconds and then seems to stop even if left for hours.

Even more extreme case: I put it in the root directory of the SD card on my Raspberry Pi and it counted 433 modules. Two, both in charm, had no date in the help string. One had a date in the form (01-01-2008), one in the form (01 January 2008) and all the rest were in the standard form (01 Jan 2008).

I don’t have RPCEmu but I do have VRPC-SA. It works OK on that. It will appear to stop when it is searching through objects but not finding modules. I could make it display the number of objects counted, which would give confirmation that it was still doing something, but of course that would slow it down.

I made it because Jim Nagel emailed me:

Wanted: A utility that will datestamp a Module file (filetype &ffa) to accord with the date stored internally in the module. … Motivation: It is SO tiresome to sort out newer from older modules (e.g. within various versions of !Printers, which is aggravating me at this moment) after careless foreign filesystems have repeatedly mangled the datestamps. ..

Thanks for the feedback.

I don’t have RPCEmu but I do have VA-SA. I will try it on that, and see if I can give it better error handling. It will appear to stop when it is searching through objects but not finding modules. I could make it display the number of objects counted, which would give confirmation that it was still doing something, but of course that would slow it down.

I figured the time could be big, hence leaving it running for a while to see if it was a large file number issue or just an unreported error causing it to hang.
Note: Some modules have text after the date string which causes DateSpy to report “undated”
DateSpy output and snippets of !SID output for the help string details:

02/04/2014  :  15/03/2015  :  HostFS::HostFS.$.Utilities2.!GuardDD.GuardDD
- undated   :  03/01/2003  :  HostFS::HostFS.$.Utilities2.!ThrowBack.Throwback
- undated   :  31/10/2004  :  HostFS::HostFS.$.Utilities2.!Timeless.Timeless

Mod_HelpStr                                             ; Address &40, referenced once
        DCB     "GuardDD"
        DCB     9
        DCB     "0.06 (02 Apr 2014)", 0
        ALIGN
 
Mod_HelpStr                                             ; Address &40, referenced once
        DCB     "Timeless"
        DCB     9
        DCB     "1.02 (2004-10-31) © Bent Bracke & Mark Greenwood", 0
        DCB     &52, &45
             
Mod_HelpStr                                             ; Address &40, referenced once
        DCB     "ResourceFSThrowback"
        DCB     9
        DCB     9
        DCB     "1.10 (9th Dec 1992) !Utils ", 0
        ALIGN

Wanted: A utility that will datestamp a Module file (filetype &ffa) to accord with the date stored internally in the module. … Motivation: It is SO tiresome to sort out newer from older modules.

I figured the motivation in that respect.
I did wonder whether something similar would be useful for general system updates – i.e. When merging a set of modules (among other things) it would be useful if the update only replaced modules / utilities/ applications with newer build dates and/or version numbers.

The subject of a decent updater that only replaces with new/revised versions comes up fairly regularly.
Optional overwrite everything to defaults for those extreme cases of a broken current install.

Some modules have text after the date string which causes DateSpy to report “undated” DateSpy output

No, it is not the text after the date string which is the cause. It is my lack of imagination about the possible variant date formats that authors indulge in. In the case of Timeless it is the back-to-front Year-Month-Day format, and in ResourceFSThrowback it is the needless th that is throwing my pattern matching efforts off track.

The problem is that there is no mandated format for dates, nor for what goes into a module’s help string. I can keep on extending my pattern matching code to cater for these two modules, but I obviously cannot go on for ever. At the moment my code first looks for stuff in parentheses. It presumes that it will find as prefix two digits for the day and as suffix four digits for the year. For the stuff in between it will search for the month either as a number or as a name. For the latter it will ignore case and look only at the first three letters.

Thanks again for this valuable feedback.

The problem is that there is no mandated format for dates,

While not mandated I thought the style guide (IIRC, could be wrong) specified it as
“n.nn (nn aaa nnnn) optional-text”

I think I might fiddle with the offending modules.

It’s in the PRM, p1-218 (p231 in PDF version).

module_name Tab[Tab] v.vv (DD MMM YYYY)

And:

The creation date is of the form 06 Jun 1987.

While it is not, as far as I know, actively parsed by RISC OS; I would consider that to be sufficiently mandated.

Follow-up: Is there an error in the PRMs here? The same bit of text says It is advisable that this string is present to avoid confusion.

Well… uh… Just how the hell would RISC OS know a module’s version number (RMEnsure, etc) otherwise ?

Tested it with hacking my OLED module. *Help Modules shows it as “<untitled>”, and *RMEnsure no longer works.

It’s in the PRM, p1-218 (p231 in PDF version).

module_name Tab[Tab] v.vv (DD MMM YYYY)

And:

The creation date is of the form 06 Jun 1987.

Ta. Not senile yet then. :)

Should the description above actually read:
module_name Tab[Tab] v.vv (DD Mon YYYY)
to make it clear the month is three alpha character representation (hence my use of “aaa” although I suppose I should have said “Aaa”

While it is not, as far as I know, actively parsed by RISC OS; I would consider that to be sufficiently mandated.

That’s probably not currently actively parsed. If someone builds a decent updater it would need to know version number and date rather than the datestamp of a file. Unless you ran Gavins DateSet before checking the modules for replacement.

Should the description above actually read:
module_name Tab[Tab] v.vv (DD Mon YYYY)

I’m just quoting the PRM. It says it in words a few lines further down (quoted also).

If someone builds a decent updater it would need to know version number and date rather than the datestamp of a file.

I would trust a baked in version/date instead of a random datestamp. Indeed, when comparing modules, I wouldn’t even look at the datestamp at all. That tells me when the file itself was last modified and has no bearing whatsoever on the module’s creation date.

I have updated DateSpy and DateSet on my website to be a tad more catholic in their parsing. They now parse the contents of the parentheses as follows: divide the string into a prefix and suffix, with the middle delimited by spaces or punctuation characters; expect the prefix and suffix to be digits followed possibly by characters; take whichever is the lesser of the two numbers specified by these to be the day of the month and the greater to be the year; expect the middle section to be alphanumeric; if numeric take that as number of months, otherwise, disregarding case and characters beyond the third, expect the name of a month. Anything else gives undated .

Perhaps we could take a leaf out of the obfuscated code competition and celebrate the most unparsable date that an author of a module has in good faith uttered to the RISC OS community. … April Fool’s day this year of our Lord the centenary of the first synthesis of luminal ?

I would trust a baked in version/date instead of a random datestamp. Indeed, when comparing modules, I wouldn’t even look at the datestamp at all. That tells me when the file itself was last modified and has no bearing whatsoever on the module’s creation date.

Indeed. Unfortunately, the current options for users updating items in their system seem to rely on the system detecting “newer” by the file datestamp and the actual creation date as embedded is ignored.
As it stands an update to things like modules in !Boot requires that the user either:

1. Examines every file looking for differences in a fashion that determines which copy should be used (old or “new”)
2. Trust to luck and assume everything needs replacing and dumping the whole lot in won’t break anything.

Where the alteration is an edited obey file for something like, oh Harinezumi, then the latter blows away your custom obey file. How do we identify obey file versions in the hypothetical updater utility? Borrow something from the unix world and add a comment line in the first line that identifies the version number and don’t overwrite unless the version is higher?
Identify it as custom and cause the updater to flag this to the user showing both versions side by side?

I have updated DateSpy and DateSet on my website to be a tad more catholic in their parsing.

I’ll give it a try and see what I break :)

Anything else gives undated.

Perhaps an “error” message suggesting the format is non-standard and that a manual check may be required.

I have updated DateSpy and DateSet on my website to be a tad more catholic in their parsing.

I’ll give it a try and see what I break :)

Both cope with the erroneous format strings. Nothing broke. Must try harder :)

Now to try on !Boot (the whole disc would take a very long time so that’s a “later” test)

Edit: Ah, give it something that isn’t a module but has the right filetype… now that breaks it.

How do we identify obey file versions in the hypothetical updater utility?

That would probably have to be done by the file version as no alternative method exists.

Weren’t we talking about modules though? Those are supposed to have an embedded date and version. ;-)

a tad more catholic in their parsing

What does this mean? Parsing works if you pray really hard?

What does this mean? Parsing works if you pray really hard?

“including a wide variety of things; all-embracing.”

A quick query will give the answer although I quite like your version.

OK, versions 0.02 now on my website. These should not break with non-modules of filetype &FFA.

Excuse my extravagant language – hypertrophy of the verbal lobe, probably. Parsing often needs prayer too. I once had a car that needed an exorcist rather than a mechanic – a Jensen CV8. Too long a story for anywhere but Aldershot.

Weren’t we talking about modules though? Those are supposed to have an embedded date and version. ;-)

The thread was, but I believe the technique is valid for use in a not-yet-existing updater for RISC OS.

Any updater needs to know the version of the file it is being asked to bring up to date with a replacement.
Essentially the request from Jim Nagel is based on a requirement that shouldn’t really exist because updates should be done in RO on the basis of the version not the datestamp. However, Jim was/is faced with the datestamp method to distinguish things quickly and not have to examine every module by doing something like dropping it onto Verma.

If we had an updater that checked the file version and date before replacing a module no one would need this utility except in rather obscure circumstances because the updater would be looking at the right information.
It being an updater it needs to cope with more than just modules and I considered how we could conceivably mark an obey file with a date or version. Some people already do, what is needed is a consistent method.

Surely the existing ‘merge’ facility does exactly that – looks at the version and replaces the existing module only if the ‘new’ version is a later version? It would obviously be no use looking at date stamps!

There is the Installer module which, at a brief look at the module code in Zap, suggests that it looks at module versions; though I don’t see the source to this in my collection. [is it third party?]
I would hope the “Install” option in !Boot (and previously, SysMerge) would do the same sort of thing.

There is the Installer module

Which checks all files? Obey, module, RunImage etc.

Which checks all files? Obey, module, RunImage etc.

Show me the money source and I’ll give you an answer…