TLIMONCE@DREW.BITNET (06/16/88)
Recently someone said that they are looking for ideas for programs to write. Recently I have had a couple ideas. One is ideal for shareware/freeware and the other could make a reasonable comercial program. The last is definitely for a comercial-only product. Idea #1: When I do a MAKE or SEARCH or DIR it takes a long time to search all the directories for all the files. That is, ARP programs find out what files match *.c (for example) first, then SEARCH throught each file. I use FACCII (bought it right from Perry at JAUG, if I remember correctly) and that does a good job of reducing the work for the directory scan but the scan is still very... well... it still gronks. What if before I did MAKE or SEARCH or any wildcard operation a program would read all the directory entries therefore putting them in the cache. That is, MAKE's initial searches (when if figures out dependicies) goes really quickly if I first do a DIR. Of course, the time of a slow DIR then a fast MAKE is longer than a slow MAKE. Yeah, but what if your program reads the first directory entry, then figures what the next sectors to be read will be and then reads them in ascending order. In reading those, it finds other sectors to be read. Once it gets to the highest one, it starts doing the same in decending order. Now this "put 'em in the cache"-program WOULD speed things up. This idea came about when the discussion of adding an elevator algorithm to the trackdisk.device was batted down by someone reminding us that the elevator algorithm has no effect on one-request-at-a-time scenerios. Of course, this could be added to ARP's wildcard routines to produce faster throughput even without FaccII (what? There are people that don't own FaccII? Oh, I must have meant "people that haven't bought it yet". Forgive me.) So, the result is a nice freeware idea, because once this is done internally by ARP (how pretensious of me :-), it wouldn't be needed anymore. Anyway, it could be a learning experience :-) for someone. A FFS version could be written too. Actually, it would be nice if more programs did a pre-sort when they knew they were going to read a number of sectors... and knew what they were ahead of time. IDEA #2: I promise this one will be shorter. Disk Optimizers are the craze in the IBM PeeCee world and I know we just purchaced one for our VAX, but you don't see many for the Amiga. Now, how about a FFS and a SFS disk optimizer? If anyone is going to do this, I have some ideas for the algorithm that would make the optimization better, and the algorithm faster (than the ones I see on the IBM, at least). If anyone would like to talk about these ideas to be put into a comercial product can contact me at the address in my signature. This would be an especially good product to package along with a low-cost hard drive controller. Any developers interested? :-) (Does that constitute a comercial message?) IDEA #3: Has anyone seen the IBM program Disk Technician? It maintains a list of what sectors have gone bad and have been blocked out, and what sectors have required retries before they were able to be read. Using this data and an expert system it moves files off certain sectors. It is a very effective product if you run in once a day (takes about 2 minutes). I would love to see that for the Amiga. It could be dependent on a particular hard drive controller making it a very good program to include with a hard drive controller or for an extra cost. Imagine, "Buy our hard drive controller and for an extra $50 we'll include a program that [ insert A.I. hype here :-) ] and helps you stop hard drive problems BEFORE they happen!" Does any of this make sence? Does any of this pique your interest? Feel free to write to me. Tom A // Tom Limoncelli -- TLimonce@Drew.Bitnet \ M // "Never trust a person that doesn't know machine language!" \ I \\// See you at the march in NYC on June 26! /\ G XX "Have you hugged your SO today?" / \ A -------------------------------------------------------------------------- "The above are my views, not those of Drew University or my employer"