Can someone tell me what is the best (speed wise) method of testing
for a specific file but importantly the name in lower case.
I have a recursive program running which scans my music library. I
want it to specifically test each album for the existence of a file 'folder/jpg' but to fail anything with a different case like
'Folder/jpg'.
OS_File 17 does not appear to be case sensitive.
The only way I can see is to read the contents of the directory
using OS_GBPB 9 and wildcards and then test the characters for
lower case.
I'm thinking that may be a lttle slow when doing thousands and i'm
also struggling to make it work anyway. on a short test run it fails
7 out of 10 albums and all albums had folder.jpg in them.
In article <5876ae0c64bob@sick-of-spam.invalid>,
Bob Latham <bob@sick-of-spam.invalid> wrote:
Can someone tell me what is the best (speed wise) method of testing
for a specific file but importantly the name in lower case.
I have a recursive program running which scans my music library. I
want it to specifically test each album for the existence of a file
'folder/jpg' but to fail anything with a different case like
'Folder/jpg'.
OS_File 17 does not appear to be case sensitive.
The only way I can see is to read the contents of the directory
using OS_GBPB 9 and wildcards and then test the characters for
lower case.
I'm thinking that may be a lttle slow when doing thousands and i'm
also struggling to make it work anyway. on a short test run it fails
7 out of 10 albums and all albums had folder.jpg in them.
[Snip]
Okay, found the problem (eventually) with OS_GBPB 9 buffer size!
But if anyone has a good way to test for a lowercase file name I'd
love to hear it.
Thanks
Bob.
In message <5876b6c3c3bob@sick-of-spam.invalid>
Bob Latham <bob@sick-of-spam.invalid> wrote:
But if anyone has a good way to test for a lowercase file name I'd love
to hear it.
If it is just the first letter that has to be lower case why not try for
just the first letter by the letter code e.g lower case f is CHR$(102)
while uppercase F is CHR$(70)
More generally, and allowing for a full set of possible characters:
DEF FNis_lower(string$)
LOCAL loop%, char%, byte%, bit%, alpha_table%, case_table%, alpha%, lower%
SYS "Territory_CharacterPropertyTable", -1, 2 TO lower_table%
SYS "Territory_CharacterPropertyTable", -1, 3 TO alpha_table%
FOR loop% = 1 TO LEN(string$)
char% = ASC(MID$(string$, loop%, 1))
byte% = char% DIV 8
bit% = char% MOD 8
alpha% = ((alpha_table%?byte%) AND (1 << bit%)) <> 0
lower% = ((lower_table%?byte%) AND (1 << bit%)) <> 0
IF alpha% AND (NOT lower%) THEN =FALSE
NEXT loop%
=TRUE
Thanks for that and to be honest that would probably do. I just thought it was odd that there doesn't appear to be a way of being case sensitive
without doing the testing yourself. I might have expected a flag on the
entry to OS_file 17 to say fixed case but it appears not.
In message <5876b6c3c3bob@sick-of-spam.invalid>
Bob Latham <bob@sick-of-spam.invalid> wrote:
Okay, found the problem (eventually) with OS_GBPB 9 buffer size!
But if anyone has a good way to test for a lowercase file name I'd
love to hear it.
If it is just the first letter that has to be lower case why not
try for just the first letter by the letter code e.g lower case f
is CHR$(102) while uppercase F is CHR$(70)
RISC OS filing systems are not case sensitive, full stop.
But if anyone has a good way to test for a lowercase file name I'd
love to hear it.
I might have expected a flag on the entry to OS_file 17 to say fixed case
but it appears not.
I presume this is a means to test a directory listing to make sure an
entry is lower case?
In article <5876c7ef57bob@sick-of-spam.invalid>,
Bob Latham <bob@sick-of-spam.invalid> wrote:
I might have expected a flag on the entry to OS_file 17 to say
fixed case but it appears not.
Is not, and has the filer not always been, famously case agnostic?
And as a consequence, isn't your expectation above a bit
unreasonable?
John
On 26 May, Bob Latham wrote in message
<5876c928b4bob@sick-of-spam.invalid>:
I presume this is a means to test a directory listing to make
sure an entry is lower case?
No, it's just a generic "is this string lower case" test. The two
SWIs return pointers to tables of bit flags (so 32 bytes of 8 bits
each, for all 256 characters in a RISC OS character set). In
alpha_table%, a bit is set if the character is alphabetic; in
lower_table%, its set if the character is considered lower case.
You still need OS_GBPB to find the names to test.
In message <5876b6c3c3bob@sick-of-spam.invalid>
Bob Latham <bob@sick-of-spam.invalid> wrote:
But if anyone has a good way to test for a lowercase file name I'd
love to hear it.
RISC OS filing systems are case insensitive. The only way you can
do what you want is to iterate through the filenames, and do
whatever test you want on each filename returned.
DEF FNis_lower(string$)Perhaps:
LOCAL loop%, char%, byte%, bit%, alpha_table%, case_table%, alpha%, lower%
SYS "Territory_CharacterPropertyTable", -1, 2 TO lower_table%
SYS "Territory_CharacterPropertyTable", -1, 3 TO alpha_table%
FOR loop% = 1 TO LEN(string$)
char% = ASC(MID$(string$, loop%, 1))
byte% = char% DIV 8
bit% = char% MOD 8
alpha% = ((alpha_table%?byte%) AND (1 << bit%)) <> 0
lower% = ((lower_table%?byte%) AND (1 << bit%)) <> 0
IF alpha% AND (NOT lower%) THEN =FALSE
NEXT loop%
=TRUE
Or, if you want to disentangle it, try:
Or, if you want to disentangle it, try:
DEF FNis_lower($&8100)
LOCAL upper%,char%
SYS "Territory_UpperCaseTable",-1 TO upper%
char%=&8100-1
REPEAT
char%=char%+1
UNTIL ?char%=upper%??char% OR ?char%=13
=?char%=13
Can someone tell me what is the best (speed wise) method of testing
for a specific file but importantly the name in lower case.
I have a recursive program running which scans my music library. I
want it to specifically test each album for the existence of a file 'folder/jpg' but to fail anything with a different case like
'Folder/jpg'.
OS_File 17 does not appear to be case sensitive.
The only way I can see is to read the contents of the directory using
OS_GBPB 9 and wildcards and then test the characters for lower case.
I'm thinking that may be a little slow when doing thousands and I'm
also struggling to make it work anyway. on a short test run it fails
7 out of 10 albums and all albums had folder.jpg in them.
And finally: developers of filing systems have worked for decades
to optimise the finding, reading, writing, extending and deletion
of files, using every trick in the book and inventing new ones,
because disk I/O is one of the major bottlenecks in the speed at
which programs run.
There are many ways to skin this cat and speed is hardly important these days,
And finally: developers of filing systems have worked for decades to
optimise the finding, reading, writing, extending and deletion of files, using every trick in the book and inventing new ones, because disk I/O
is one of the major bottlenecks in the speed at which programs run.
Similarly, if there's some I/O information that won't change over
the run of a program, read it once into a variable, then access the
variable.
For example:
size%=EXT#inputfile then use size% instead of EXT#
If your program is never going to change screen mode:
SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%
Similarly, if there's some I/O information that won't change over the
run of a program, read it once into a variable, then access the variable.
For example: > size%=EXT#inputfile then use size% instead of EXT#
If your program is never going to change screen mode:
SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%
For example: size%=EXT#inputfile then use size% instead of EXT#
Sorry, that's bad advice, a program should always assume filing system
data may be altered by other processes.
If your program is never going to change screen mode:
SYS whatever TO xsz%,ysz%,etc then use xsz% and ysz%
Only if its running outside the desktop. Inside the desktop the mode can change, so you need to ensure you handle the mode change message an
re-read any mode related parameters you are using.
On Thursday, 4 June 2020 20:49:57 UTC+1, druck wrote:
For example: size%=EXT#inputfile then use size% instead of EXT#
Sorry, that's bad advice, a program should always assume filing system
data may be altered by other processes.
If it's open for input, other processes *can't* alter it.
Read By Many, Write By One.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 37:48:06 |
| Calls: | 6,648 |
| Files: | 12,193 |
| Messages: | 5,329,235 |