Modules and dates
GavinWraith (26) 1563 posts |
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 :{. |
Steve Pampling (1551) 8155 posts |
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. |
GavinWraith (26) 1563 posts |
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:
Thanks for the feedback. |
Steve Pampling (1551) 8155 posts |
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. 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
I figured the motivation in that respect. The subject of a decent updater that only replaces with new/revised versions comes up fairly regularly. |
GavinWraith (26) 1563 posts |
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. |
Steve Pampling (1551) 8155 posts |
While not mandated I thought the style guide (IIRC, could be wrong) specified it as I think I might fiddle with the offending modules. |
Rick Murray (539) 13806 posts |
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. |
Rick Murray (539) 13806 posts |
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. |
Steve Pampling (1551) 8155 posts |
Ta. Not senile yet then. :) Should the description above actually read:
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. |
Rick Murray (539) 13806 posts |
I’m just quoting the PRM. It says it in words a few lines further down (quoted also).
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. |
GavinWraith (26) 1563 posts |
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 ? |
Steve Pampling (1551) 8155 posts |
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.
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? |
Steve Pampling (1551) 8155 posts |
I’ll give it a try and see what I break :)
Perhaps an “error” message suggesting the format is non-standard and that a manual check may be required. |
Steve Pampling (1551) 8155 posts |
I have updated DateSpy and DateSet on my website to be a tad more catholic in their parsing. 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. |
Rick Murray (539) 13806 posts |
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. ;-) |
Rick Murray (539) 13806 posts |
What does this mean? Parsing works if you pray really hard? |
Steve Pampling (1551) 8155 posts |
“including a wide variety of things; all-embracing.” A quick query will give the answer although I quite like your version. |
GavinWraith (26) 1563 posts |
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. |
Steve Pampling (1551) 8155 posts |
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. 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. |
Chris Hall (132) 3554 posts |
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! |
Rick Murray (539) 13806 posts |
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?] |
Steve Pampling (1551) 8155 posts |
Which checks all files? Obey, module, RunImage etc. |
Rick Murray (539) 13806 posts |
Show me the |