>>>> Given that ABC is text-line-based, *can* a program go straight to a
>>>> tune, random-access-like, without having read all the intervening lines?
>>> random-access-"like"... yes, it's possible. My JedABC has an index mode
>>> that does what you want; so does BarFly in "Split Screen Mode".
>> But BarFly will have read the entire file before it goes into split-
>> screen mode, and I suspect JedABC will have done too.  You would need
>> something like ISAM to do what Richard is talking about, and I don't
>> think anybody is implementing ABC software in MVS Cobol or in S3 on
>> ICL VME.
[Richard Robinson]
> Uh ? Are we at cross purposes here ?
> Read through the file, from 1st line to last line, keep a note of what
> "global" headers are in force, as each tune is met add these in as
> appropriate. Dunno about COBOL, I agree C is not the prettiest language
> for handling text, but surely it's not impossible ? Very simple in the
> "scriptier" languages, like perl for example.

May be you didn't write it? but the query I quote in the first two
lines was about kinds of access that *don't* read through the file.
Instead, open the file and seek straight to the tune you want.
Database systems do this sort of thing all the time, but it needs
an external index.  On mainframe OSes that's supported at a low
level by the file system manager; on Unix you usually have to roll
your own (and probably implement your own entire i/o system as well
if you really care about meeting serious requirements for keeping
your data uncorrupted, but that's another flame war).  For people
writing payroll systems for an entire country's civil service on
hardware with less CPU power than a modern microwave oven, or when
accessing files directly on tape, this was essential, but it's hard
to imagine an ABC tune repository big enough to need it now.


>> Richard's tunebook is the only ABC file I've got on this machine that
>> requires me to increase BarFly's memory allocation above the default
>> (and it's very slow to load).
> This is the old Mac systems issue, is it, of having to specify memory
> for each program individually ?

It's not a big problem for any modern machine.  I think I could
probably use your file as is even on my usual library-transcribing
laptop (with all of 12Mb), but I try not to allocate more memory
to programs than is strictly necessary.


> I remember now, I used to split this file into alphabetically-sorted
> chunks so as to get smaller file sizes [...]  I'm not very keen to
> reinstate this, but will give it some thought if this issue is a
> general nuisance. Mac users ?

It never really mattered.  Anyone who wants it in small chunks will
have the means to split it up; there have been freeware file split/join
utilities around since 1984 and umpteen editors and WPs can do it.

-----------------------------------------------------------------------------
Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760
<http://www.purr.demon.co.uk/jack>     *     food intolerance data & recipes,
Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro".
------> off-list mail to "j-c" rather than "abc" at this site, please <------


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Reply via email to