hsgj@batcomputer.tn.cornell.edu (Dan Green) (12/17/86)
.> The "big file of icons" seems like a big win to .>me if one assumes that it is cached. Then closing and opening drawers .>that have once been opened becomes instantaneous. (Or nearly; you may .>have to check time of last dir modification.) Amiga needs to support .>more caching-type ideas. Memory is cheap and getting cheaper. I've .>seen Workbench windows where the whole drawer was in ram:, and those .>things are FAST (if you can afford that much ram). But if it's just .>the icons in ram, you don't use much memory and still get great .>response on opening the drawers. .> .> Charles Poirier (USENET)!vax135!cjp I don't know about the icon cache idea. On the amiga, where you can pop out the disk at any time, all caches had better well be write thru. And for icons, generally the user is going to be doing one of two things: (1) just wants to see the icons long enough to boot ye olde WordProDeluxeWithTurboSpeedMegaPower, or (2) the user wants to play around rearranging the display of the icons on the screen. For case (1), the cache doesn't pay because all the icons are only referenced once. For case (2), you are constantly moving (eg writing data) the icons, so the "cache" will always be writing thru to disk. My "vote" so far is for having one file of icons for each folder. The huge pain with this method, though, is that it is now very difficult to create an icon for a new program or file (ie you can't just dup an existing .info file). Of course, the speed benefit is nice. I think the "ideal" situation would be for the linker to reserve 512 bytes or so as the header for each program, (and fopen'ing a new file could pad the top with the header also) and then store the .info in this area. Of course TYPE would have to be smart enough to skip the header, which is trivial. The "small" problem with this is that one would have to rewrite everything. I guess its not worth it :-) My FINAL EXAM opinion is that I would rather have C/Amiga concentrate its resources more on bettering Intuition and on making neater hardware, then on worrying about the silly WorkBench... -- Dan Green -- ARPA: hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
ali@navajo.STANFORD.EDU (Ali Ozer) (12/18/86)
> ... Amiga needs to support more caching-type ideas... > Charles Poirier (USENET)!vax135!cjp Actually, I am impressed with how much the Amiga supports caching type ideas already. For example, I am working on a program which calls OpenDiskFont() to open a font I designed. For now I have this font sitting in a directory other than sys:fonts, so I have to assign fonts: df1:tmp before I use my program or else OpenDiskFont() fails. Well, then my program runs, and uses the font, and at the end, does a CloseFont() to get rid of the font. Now, if you reassign fonts: back to the original directory assign fonts: df0:fonts and then run my program again, voila, it still finds the font from the other directory, without any disk searches. I guess this is also the way libraries and stuff work: Even if the reference count is zero, it is kept in memory in anticipation that someone will need it. Am I right? And I also assume this means that if someone else needs that memory in which the font (or the library) is cached, AmigaDos gives it up. Or else I hope it does. One idea to make life under WorkBench easier is to organize the disks better, of course... Try to put no more than 5-7 files per directory, and make sure you don't have zillions of files without icons, and life will be nice and quick (relatively). For example I love the way Fred Fish organized the IFF pictures in the latest batch of Fish Disks (one of 41..46, I forget which one). You go through several layers of drawers to get to the pictures, but at every level windows pop open and show their icons pretty quickly. [Forgive me if this was already so obvious that people did this all the time and on top of this thought that the WorkBench is slow; I come from a Tops-20 background where subdirectories and hierarchical file systems are not used as often as they should be.] Ali Ozer, ali@navajo.stanford.edu
cjp@vax135.UUCP (Charles Poirier) (12/19/86)
In article <1846@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: >.> The "big file of icons" seems like a big win to >.>me if one assumes that it is cached. Then closing and opening drawers >.>that have once been opened becomes instantaneous. >.> >.> Charles Poirier (USENET)!vax135!cjp > >I don't know about the icon cache idea. On the amiga, where you can >pop out the disk at any time, all caches had better well be write thru. Yes, certainly. >And for icons, generally the user is going to be doing one of two >things: (1) just wants to see the icons long enough to boot ye olde >WordProDeluxeWithTurboSpeedMegaPower, or (2) the user wants to play >around rearranging the display of the icons on the screen. Yeah, no benefit for these two cases. (1) is most common, (2) i think is pretty uncommon. But just suppose one has a single icons file per DISK. Then one can do "browsing" type things on Workbench, painlessly. Open drawer, look around, say 'oops', close, open different drawer. All for ONE icon file read per disk. > My "vote" so far is for having one file of icons for each folder. >The huge pain with this method, though, is that it is now very difficult >to create an icon for a new program or file (ie you can't just dup an >existing .info file). Of course, the speed benefit is nice. No pain. Invoke a tool, "copy icon", then click on the pic you want. > My FINAL EXAM opinion is that I would rather have C/Amiga concentrate >its resources more on bettering Intuition and on making neater hardware, >then on worrying about the silly WorkBench... >-- Dan Green Workbench AT PRESENT is silly because the time wasted in looking up icons makes it SLOWER than using CLI. Mind, I prefer CLI anyway, but the world has both kinds of people. Why not have both interfaces the best they can be? Besides, the d**n redundant icon files get in my way when I am using CLI -- if there was a single file of icons, you not only would be free of the .icon clutter, but you could use it directly for dir listings. Correct me if I'm wrong. Of course there could be compatibility problems, but maybe a few conversion utilities would suffice -- say, for converting old-style icon disks to single-icon-file disks. And for old programs that insist on writing their own icon files, maybe a background task (or file system patch) that intercepts .icon files. I've not considered everything, but it's worth thinking about. Cheers, Charles Poirier (USENET)!vax135!cjp
cjp@vax135.UUCP (Charles Poirier) (12/19/86)
In article <1228@navajo.STANFORD.EDU> ali@navajo.UUCP (Ali Ozer) writes: >> ... Amiga needs to support more caching-type ideas... >> Charles Poirier (USENET)!vax135!cjp > >Actually, I am impressed with how much the Amiga supports caching type >ideas already. Yes. What I meant is, it demonstrably works well, so let's have more of it. Charles Poirier (USENET)!vax135!cjp
wtm@neoucom.UUCP (Bill Mayhew) (12/19/86)
Hi, Yes, indeed, the fonts and libraries will hang around in memory and intuition knows that they are there. If you do a CloseFont() or a CloseLibrary(), the font or library remains around until something else big enough comes around that wants the memory; at that point the font or library becomes history. You may want to watch out about reassigning fonts: back to df0:, as you can't count on the font sticking around, eventhough intuition is able to find it in memory some/most of the time. Depending on how you handle things you could generate a guru. --Bill Bill Mayhew Division of Basic Medical Sciences Northeastern Ohio Universities' College of Medicine Rootstown, OH 44272 USA phone: 216-325-2511 (wtm@neoucom.UUCP ...!cbatt!neoucom.wtm)
keithd@cadovax.UUCP (Keith Doyle) (12/20/86)
In article <1846@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: > My "vote" so far is for having one file of icons for each folder. >The huge pain with this method, though, is that it is now very difficult >to create an icon for a new program or file (ie you can't just dup an >existing .info file). Of course, the speed benefit is nice. > My FINAL EXAM opinion is that I would rather have C/Amiga concentrate >its resources more on bettering Intuition and on making neater hardware, >then on worrying about the silly WorkBench... >-- Dan Green I STILL think that optimizing the directory/file structure for speed better would benifit not only the WorkBench but also CLI commands. Using the original 'DIR' command to me is even more painful than opening up a window on the workbench. At least the window shows you something as it's working on it. 'DIR' is intent on sorting the directory and has to read it all, sort, and THEN finally display something. 'DIR' is SO painful, that I absolutely refuse to use it ( the output format is kinda quirky too). I've been using a version of 'ld' renamed as 'DIR', that displays as it reads. One could always add a OPT SORTED or something (or from where I'm from, '-s') and have it work the long way in the event I really care if it is sorted or not. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
keithd@cadovax.UUCP (Keith Doyle) (12/20/86)
In article <1228@navajo.STANFORD.EDU> ali@navajo.UUCP (Ali Ozer) writes: >One idea to make life under WorkBench easier is to organize the disks >better, of course... Try to put no more than 5-7 files per directory, >and make sure you don't have zillions of files without icons, and >life will be nice and quick (relatively). For example I love the way >Fred Fish organized the IFF pictures in the latest batch of Fish >Disks (one of 41..46, I forget which one). You go through several layers >of drawers to get to the pictures, but at every level windows pop open >and show their icons pretty quickly. That's the ticket! Let's put each file in it's own subdirectory that is only shared with the subdirectory for the next file i.e. file1 dir1 |__file2 dir2 |__file3 dir3 |__file4 dir4 |__file5 dir5 |_file6 dir6 etc. Keith
ralph@mit-atrp.UUCP (04/17/87)
Mitsu's recent message mentions a number of good improvements to the
workbench which will make the Amiga environment for non-hackers a better
one. This is exactly what we need Commodore to realize: that a smooth
and fast workbench will make those Amiga 500's sell (as well as the great
price). I have to continue hoping that the speed of drawer opening will
also improve as well. I think I'll direct the following questions at CBM
directly:
Dear CBM folks:
- Are these kind of improvements to the workbench being considered ?
- If they are, when will we see them ?
- If they are not being considered, why not ?
- If you have no plans to do them, will you help us do them
by giving us more information on how it is done ?
Sorry to single you folks out, but I, and others, feel that the future
of the Amiga very dependent on such improvements ! And we want the
Amiga line to go as far as it can. This means that "everyone" that trys
out an Amiga *has* to feel like it was easy,fast and exciting. This requires
ease of use and MINIMUM delays in operation.
Thanks for listening,
Ralphdillon@CORY.BERKELEY.EDU.UUCP (04/17/87)
This is only the third time I've made this comment... stick all the icons in a single file (say, .icons) per directory, and all will be fine as far is workbench is concerned. There are two reasons why I don't use the workbench: (1) Way too slow due to having to search the directory (2) .icon files make the directories too messy. -Matt
jmpiazza@sunybcs.UUCP (04/18/87)
In article <8704172157.AA15623@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > This is only the third time I've made this comment... stick all the >icons in a single file (say, .icons) per directory, and all will be fine >as far is workbench is concerned. There are two reasons why I don't use >the workbench: > > (1) Way too slow due to having to search the directory Hear hear (here here?) > (2) .icon files make the directories too messy. Huh? After following previous discussions I wonder how many people realize that the Mac collects icons and other info from each file and puts in a directory file called "Desktop." I also wonder if other people realize that the Mac isn't nearly as slow as the Amiga for directory listings. The workbench without a directory file (or what ever you want to call it) will always be too slow for many people (including me). We have 880K per disk; a directory file should never take up more than half of the odd 80K. I hope that burning AmigaDOS 1.2 into Amiga 2000/500 ROMS doesn't stick us without a directory file as long as the time I waited for 1.2 to be be released and to receive my Aztec 3.4a update. :-) Tally ho, I'm in. Flip side, joe piazza --- Cogito ergo equus sum. CS Dept. SUNY at Buffalo 14260 (716) 636-3191, 3180 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@buffalo-cs BI: jmpiazza@sunybcs GE: jmpiazza
farren@hoptoad.UUCP (04/19/87)
I would like to make this suggestion: after enough data has been
gathered to allow decent decision making (probably now, actually), go
to work on the next generation of Amiga system software: EXEC,
Workbench, Intuition, and AmigaDOS. Incorporate the necessary changes
to make all of these work as efficiently, and well, as possible. Make
compatibility with the originals a second-level consideration with one
exception: allow for easy conversion of "old" applications and files
to be usable in the new software environment. An example: change the
workbench such that all icons are resident in a single file, for easy
display. Then, provide a conversion utility that will take an older
disk, collect all of the .info files in a directory, and convert them
into the newer icon structure. Other examples are left as an
exercise.
Once all this is done, release the new systems software and the
appropriate conversion utilities, and let the normal evolutionary
process take place. Newer applications will start out by using the
newer resources. Older applications can either be converted over to
the newer setup or, if necessary, can be run using old system
software. This all makes it very inconvenient for some users for a
while, but if the newer software is clearly better, you will find
almost 100% use of the newer stuff within a year or, at the most, two.
At that point, offer replacement ROMs for all of the Amiga 500s and
2000s out there. Result: better software for everybody, minimal
disturbance to the users.
There is precedent here. When Apple released their AppleDOS 3.3, it
included a set of ROMs for the disk controller that made it instantly
incompatible with the older disk format. They also released MUFFIN, a
utility to convert older disks to the newer format. This was a pain,
but nobody seriously objected: the new format offered higher disk
speed along with greater disk capacity. It only took a little over a
year before you couldn't find anyone offering software in the older
format; everyone had converted, and even the most recalcitrant users
were switched over. And, it didn't seem to hurt Apple a whole lot;
their sales kept increasing all along.
Incompatibility isn't that big a problem, as long as you provide a
means of continuing to use the existing resources during the
transition period.
--
----------------
"... if the church put in half the time on covetousness
Mike Farren that it does on lust, this would be a better world ..."
hoptoad!farren Garrison Keillor, "Lake Wobegon Days"ccplumb@watmath.UUCP (04/19/87)
farren@hoptoad.UUCP (Mike Farren) says (in <2007@hoptoad.uucp>): >I would like to make this suggestion: after enough data has been >gathered to allow decent decision making (probably now, actually), go >to work on the next generation of Amiga system software: EXEC, >Workbench, Intuition, and AmigaDOS. Incorporate the necessary changes >to make all of these work as efficiently, and well, as possible. Make >compatibility with the originals a second-level consideration with one >exception: allow for easy conversion of "old" applications and files >to be usable in the new software environment. Yes, indeed! I, for one, would put up with vast amounts of trouble for better systems software. The Amiga's release was rushed. PLEASE don't insist on using any already present kludges just because they were there at the start. I'd switch to a highly *incompatible* OS if it were clearly superior. As Mike said, everyone will go squirrley for a while making the changeover, but if you do it *right*, and the new system is clearly superior to the old, I don't think there'd be much opposition. Large changes have been made by Apple (3.3 and ProDOS) and IBM (remember FCB's and flat directories?) without losing people. If C-A follows it's laudable tradition of releasing beta-test versions of the OS, all the developers can easily be ready for the big change by the time it's officially released. I've said it before, but the success of the Amiga is due to its technical quality. But technological leadership doesn't last too long. Keep working on improving it, not in minor ways, but in major ways. It's an exciting machine. *Please* keep it that way. -- -Colin Plumb (watmath!ccplumb) Silly quote: She has eyes like two holes in a burnt blanket.
acs@amdahl.UUCP (Tony Sumrall) (04/21/87)
In article <3050@sunybcs.UUCP> jmpiazza@gort.UUCP (Joseph M. Piazza) writes: > After following previous discussions I wonder how many people >realize that the Mac collects icons and other info from each file and puts >in a directory file called "Desktop." I also wonder if other people realize >that the Mac isn't nearly as slow as the Amiga for directory listings. Did we discuss this approach when the discussion about .info files began (way back when)? I *like* the idea of a directory whose structure parallels the root and contains nothing but .info files (e.g. if "df0:junk/junk pgm" has an icon it's in "df0:Icons/junk/junk pgm.info"): * If you're using WB it only searches the Icon directory to display the icon. * If you're *not* using WB it only searches the specified dir. I realize that this will require at least *2* accesses in order to run the program from WB but I must tell you that I'd prefer that to the horrendous errors that can occur upon the system attempting (unsuccessfully) to compress a .info file after the user has run a program that: 1) Deletes filex 2) Creates filex 3) Creates an icon file for filex while simultaneously doing the same thing from another program. Get 1/2 dozen of these things going and I think my poor li'l drive would gronk itself right out of existence! :-) Further, since all requests will have to operate on the same file requests must operate on the same file, they'd have to be single-threaded. A delete req would have to: 1) Read the whole info file in 2) Munge out the deleted icon (i.e. delete and compress) 3) Write out the whole file all while the info file is locked. A create request would be fairly simple since all it'd have to do is append the info file. I can just picture some poor li'l WB-only person wondering why the drive is shaking the computer desk to bits after a few days of "just changing my MaxiPlan worksheet a little bit". I've probably gone on far too long but, like I said earlier, how about a parallel structure for the icon files only? > joe piazza -- Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
mcinerny@rochester.ARPA (Michael McInerny) (04/21/87)
[] One of the two principles of Operating Systems (I'll leave the other to you) is "Cache It". One easy way to solve the Icon speed problem is to chache the .info files. Ideally, this would be in RAM, but we all know that RAM is volatile &c., so, what the WorkBench could do is build a .Desktop-ish file of ALL the information (maybe just the bitmaps for the icons?) it needs on a, say, directory by directory basis. This would allow the WB to render the icons with only one seek (which is where most of disk time is spent). Further, a single file is much more likely to be cached in a disk buffer than multiple .info files. But what about the current .info files? Keep 'em. The .Desktop file is a _cache_ for the .info files--it needs to be treated as such. That is, whenever the .info files change (which can be detected through timestamps or other means), the .Desktop will need to be updated, or at worse, rebuilt (a la Macintosh). This "caching" principle can be (and I believe, has been) use(d) for "normal" CLI directories and lists--again, whenever the directory is scanned, cache the results in a .directory file. When a second dir is requested, if the timestamp on the .dir file is later than the timestamp of the directory itself, use the .dir file, o.w. rebuild it. Of course, it would be nice if disk accesses themselves were optimized.... -Michael McInerny
andy@cbmvax.cbm.UUCP (Andy Finkel) (04/21/87)
In article <973@mit-amt.MEDIA.MIT.EDU> ralph@ATRP.MEDIA.MIT.EDU (Amiga-Man) writes: >Dear CBM folks: > - Are these kind of improvements to the workbench being considered ? Yes, they are. We are actively looking at improvements in the system software, including Workbench. > - If they are, when will we see them ? Good question. I'd prefer not to have a new OS release for about a year. Too many releases too quickly tends to annoy software developers (who are critical to a machines success). > - If they are not being considered, why not ? > - If you have no plans to do them, will you help us do them > by giving us more information on how it is done ? The manuals are a great place to start. In particular, RomTags, which allow the replacement of an entire module, and SetFunction, which allow you to replace a function within a library/device are key. When I get a little free time I'll write and post a RomTag (in ram) example. (BTW, even though Workbench is in rom (kickstart) the LoadWB command is on the Workbench disk. Think about it.) > >Sorry to single you folks out, but I, and others, feel that the future >of the Amiga very dependent on such improvements ! we (the technical people here at C/A) agree. And we are listening/saving messages. (its counter-productive for us to actually get involved in the debates themselves) > Thanks for listening, > Ralph you're welcome andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga /or/ pyramid!amiga!andy } "Do not meddle with the affairs of wizards, for it makes them soggy and hard to light." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
beilke@puff.WISC.EDU (Matthew Beilke) (04/23/87)
In article <27184@rochester.ARPA>, mcinerny@rochester.ARPA (Michael McInerny) writes: > One of the two principles of Operating Systems (I'll leave the other to > you) is "Cache It". One easy way to solve the Icon speed problem is to > chache the .info files. Ideally, this would be in RAM, but we all know > that RAM is volatile &c., so, what the WorkBench could do is build a > .Desktop-ish file of ALL the information (maybe just the bitmaps for the . . . > > But what about the current .info files? Keep 'em. The .Desktop file Well, I kind of do this already. Put addbuffers (need V1.2) in your startup-sequence and as long as you don't do too much disk swapping, it works nicely. example startup-sequence: bindrivers addbuffers df1: 50 ; 50 means 50K addbuffers df0: 50 path sys:system add . . . loadwb endcli > nil: As long as you don't need lots of memory, or have a memory expansion, you should be pleased with the results. This is only a temporary solution, I do like your idea, and also the idea of having all the icons in a single directory <-Note: Not file Why not a file? Try doing an alticon/setalternate/mergeicon and you'll see. - - - ---> Matt Beilke <--- - - - ============================================================================== | | | // ARPA: beilke@puff.wisc.edu | | // CSNET: beilke%puff.wisc.edu@csnet-relay | | \\ // AMIGA UUCP: ...!{ihnp4,hplabs,seismo,topaz,etc.}!uwvax!puff!beilke | | \// RULES!! SNAIL: 451 Witte B, Madison, WI, 53706, USA | | | ==============================================================================
spencer@eris.BERKELEY.EDU (Randy Spencer) (04/24/87)
In article <1701@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >we (the technical people here at C/A) agree. And we are listening/saving >messages. >andy finkel {ihnp4|seismo|allegra}!cbmvax!andy >Commodore/Amiga /or/ pyramid!amiga!andy } This has got to be the most comforting thing I have ever read on the net. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
kinner@wsucshp.UUCP (Bill Kinnersley ) (04/24/87)
acs@amdahl.UUCP (Tony Sumrall) writes: > In article <3050@sunybcs.UUCP> jmpiazza@gort.UUCP (Joseph M. Piazza) writes: > > After following previous discussions I wonder how many people > >realize that the Mac collects icons and other info from each file and puts > >in a directory file called "Desktop." I also wonder if other people realize > >that the Mac isn't nearly as slow as the Amiga for directory listings. > > Did we discuss this approach when the discussion about .info files began > (way back when)? I *like* the idea of a directory whose structure > parallels the root and contains nothing but .info files (e.g. if > > I've probably gone on far too long but, like I said earlier, how about a > parallel structure for the icon files only? Discussions about the icon structure are probably moot, being about two years too late. Nevertheless, you have to admit, the present system of having a separate icon file for each data file is really cumbersome. Carried to extremes, we could have parallel structure for .comment files, .date files, etc. Really, icons should be system information. They should be handled privately by the filing system, not kept out in public to clutter up your directory, and potentially get lost. The Right Way To Do It would be to build icons into the filing system. Dedicate a word in the file header block to point to the disk location of the corresponding icon. In fact, there are several spots in the header block currently not being used. A nil pointer of course means no icon for that file. The copy utility would be designed to automatically copy disk blocks for the icon when it copies the file, but the file size reported would not include the icon size. When Workbench opens a drawer, it would examine each file header in the drawer to see if an icon is present. (but it does this sort of thing now, looking for .icon files, since the names are kept in the headers. At least there would be fewer files.) You would need utilities to attach an icon to a file, modify it, etc. --- --Bill Kinnersley USENET: ...!ucbvax!ucdavis!egg-id!ui3!wsucshp!kinner INTERNET: kinner%wsu@RELAY.CS.NET CSNET: kinner@wsu MAIL: CS Dept, Washington State Univ, Pullman WA 99164-1210 PHONE: (509)332-3340
guilford@rpics.RPI.EDU (Jim Guilford) (04/26/87)
As long as we are talking about workbench improvements, I'll throw in my two cents (I hope I am not out in left field :-) I've noticed that it takes a lot longer to write a file than to read it. I would assume that this happens because of the following. It seems to me that when one is extending a file that they system must allocate a new disk block, update the record of what blocks are in use, and then write the actual data block. Since these are probably widely separated on the disk, a lot of head seeking needs to be done. Might it not be more efficient that when one needs a new block for a file, to grab multiple blocks (if they are available), and then when the file is closed, return any unused blocks. This would reduce the number of times that the disk allocation area has to be updated and hence speeds the file expansion. I haven't actually studied the disk format, so I may be far off. But if my assumptions are accurate, I think that this would be a relatively painless way to improve disk speed on file extension. --Jim Guilford (guilford@csv.rpi.edu)
page@ulowell.cs.ulowell.edu (Bob Page) (04/27/87)
beilke@puff.WISC.EDU (Matthew Beilke) wrote in article <693@puff.WISC.EDU>:
> addbuffers df1: 50 ; 50 means 50K
I thought it meant 50 buffers, where a buffer is about 512 bytes.
..Bob
--
Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} dillon@CORY.BERKELEY.EDU.UUCP (04/29/87)
>The Right Way To Do It would be to build icons into the filing system. >Dedicate a word in the file header block to point to the disk location of the NO NO NO NO !! Pleeeeeeese. Don't be silly. I personally have no wish to 'macify' my Amiga. -Matt
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (04/29/87)
In article <160006@wsucshp.UUCP> kinner@wsucshp.UUCP (Bill Kinnersley ) writes: >The Right Way To Do It would be to build icons into the filing system. >Dedicate a word in the file header block to point to the disk location of the >corresponding icon. In fact, there are several spots in the header block >currently not being used. A nil pointer of course means no icon for that file. Did I just hear someone say "Unix needs file types?" Oops, nope, that's an old conversation that this brings to mind. The problem with this is that you need to look at every program, and decide what it should do with that icon information. A good example is "compress." What should it do with the icon? If you don't do anything to compress, the icon will get thrown away. Of course, if you have it chase the pointer, you're still got to decide what to do with the icon. Compress it at the end of the file, with marks indicating that it should be added as an icon? What happens if you uncompress on a system that doesn't understand them. Attach the icon to the compressed file? The next time a user treats it in whatever way the old icon got treated, someone is going to be surprised. Compress the icon into a different file? Not bad, you just have to remember to move the icon with the compressed file, and attach it to the uncompressed file at the other end. Similar problems occur for arc, tar, and (most notably!) bru. In other words, while this may be ideal in terms of keeping icons attached to files, it's really lousy in terms of programs that manipulate files. Being a great believer in caching, how about a tweak to the workbench that caches icons based on file name? It could even keep the "parallel tree" structure in memory, and build it as drawers get opened. After all, icons are small. Of course, a wb option to turn this off is probably a good idea. Better yet, put the cache in icon.library... Just 'storming, <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
blgardne@esunix.UUCP (04/29/87)
in article <1226@ulowell.cs.ulowell.edu>, page@ulowell.UUCP says: > Keywords: cache disk icon > > beilke@puff.WISC.EDU (Matthew Beilke) wrote in article <693@puff.WISC.EDU>: >> addbuffers df1: 50 ; 50 means 50K > > I thought it meant 50 buffers, where a buffer is about 512 bytes. > > ..Bob > -- > Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} Has anyone done some benchmarking to determine the optimum number of buffers? The manual suggest something like 30 buffers. What's the best number if you've got some RAM to burn? (I realize that disk buffers must come out of Chip mem.) -- Blaine Gardner @ Evans & Sutherland UUCP Address: {ihnp4,decvax}!decwrl!esunix!blgardne Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne
ralph@mit-atrp.UUCP (04/29/87)
In article <8704290425.AA27217@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >>The Right Way To Do It would be to build icons into the filing system. >>Dedicate a word in the file header block to point to the disk location of the > > NO NO NO NO !! Pleeeeeeese. Don't be silly. I personally have no >wish to 'macify' my Amiga. > > -Matt But but but but....we have to admit that the drawer opening speed MUST BE IMPROVED ! I'm not too hot on the idea in the first posting, since the thing must still muck around in multiple files. Let's get this straight: (I know I'm right :-) ) the icons must be cached together to get decent performance. If they're still split up the drawer opening time will still be dismal. I really am not too concerned with the possibility that doing the internal combination of icons might make that *part* of the guts of my Amiga OS look *slightly* mac like. Heck, we both use icons and windows, No ? Except we have the "advantage" of slow drawer opening.....gosh.... :-). If there's one improvement that need to be in 1.3, that's the one ! Fear not folks, I'm gonna fix this in about 6 months when I figure it out. I'll either fix it or write a new workbench....Big project, but big win. Anybody doing this already (please ?...so I don't have to ?). I'm committed (or maybe I ought to be)...
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (04/30/87)
In article <160006@wsucshp.UUCP> kinner@wsucshp.UUCP (Bill Kinnersley ) writes: >acs@amdahl.UUCP (Tony Sumrall) writes: >Really, icons should be system information. They should be handled privately >by the filing system, not kept out in public to clutter up your directory, >and potentially get lost. > >The Right Way To Do It would be to build icons into the filing system. >Dedicate a word in the file header block to point to the disk location of the >corresponding icon. In fact, there are several spots in the header block >currently not being used. A nil pointer of course means no icon for that file. > Once again, I get to use my favorite contradictory phrase: Wrongo! Many people fail to realize that the Workbench on the Amiga is *NOT* part of the operating system. It is an *APPLICATION* that runs on top of the operating system. The fact that it happens to be stored with Kickstart doesn't change this. Workbench opens a borderless backdrop window (using Intuition), and sticks disk icon gadgets on it. When you double-click on a gadget (a function defined by Workbench and nowhere else), Workbench creates a window and starts filling it with gadgets. Gadget imgaes are stored in .info files (you already knew all this, didn't you? :-). Since Workbench is an application, it has to use the operating system as it exists. Nobody hacks an operating system to pieces just to accomodate one application. Awright, maybe they do, but it surely isn't common. The Workbench designer decided to glob-search for .info files. A perfectly reasonable approach under normal circumstances. Unfortunately, Amiga got stuck with a cheesy DOS that makes globbing the most inefficient thing you could do. I always thought that the simplest and easiest-to-implement hack to the Workbench would be to create a file called "foo" (call it whatever you like; the name isn't important). "foo" would be an ASCII text file that contains, on each line, the filenames of all the .info files in this directory. Reconstruction of this file would be pathetically simple. Using this file would be just as simple. Just open the file, read the filename, open the filename, read the icon info, close the filename, and repeat for all remaining filenames in the file (there would be one filename per line). But *PUHLEEZE* don't wack on the filesystem just to make Workbench's life easier. You'll make everyone else's life more difficult. Anyway, that's my opinion.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ ________ ___ Leo L. Schwab \ /___--__ The Guy in The Cape ___ ___ /\ ---##\ ihnp4!ptsfa!well!ewhac / X \_____ | __ _---)) ..or.. / /_\-- -----+==____\ // \ _ well ---\ ___ ( o---+------------------O/ \/ \ dual ----> !unicom!ewhac \ / ___ \_ (`o ) hplabs -/ ("AE-wack") ____ \___/ \_/ Recumbent Bikes: "Work FOR? I don't work FOR The _O_n_l_y Way To Fly! anybody! I'm just having fun."
eric@cbmvax.cbm.UUCP (Eric Cotton) (04/30/87)
In article <1226@ulowell.cs.ulowell.edu> page@ulowell.cs.ulowell.edu (Bob Page) writes: >beilke@puff.WISC.EDU (Matthew Beilke) wrote in article <693@puff.WISC.EDU>: >> addbuffers df1: 50 ; 50 means 50K > >I thought it meant 50 buffers, where a buffer is about 512 bytes. Bob is correct. As per page 25 of the 1.2 Enhancer manual: Format: ADDBUFFERS df<x>:<nn> Purpose: to reduce disk access time by adding sector cache buffers Specification: Adds <nn> buffers to the list of sector caches for drive <x>. Adding additional buffers can significantly reduce disk access time. The tradeoff is that the command uses up memory; each buffer added reduces memory by approximately 500 bytes. The improvement in disk access time is less pronounced when you add more than 25-30 extra buffers. I couldn't have said it better m'self... -- Eric Cotton Commodore-Amiga "I don't find this stuff amusing anymore." /*========================================================================*/ /*==== UUCP: {ihnp4|allegra|seismo|pyramid!amiga}!cbmvax!eric ====*/ /*==== ARPA: cbmvax!eric@seismo ====*/ /*==== US mail: Commodore Technology / 1200 Wilson Drive ====*/ /*==== West Chester, PA 19380 ====*/ /*==== phone: (215) 431-9180 ====*/ /*========================================================================*/
hadeishi@husc7.UUCP (05/01/87)
Re: Workbench improvements, compatibility, and computer revolutions Although it is clear the Workbench must be improved, it is also clear that the Amiga will improve in sales the more it is perceived as a useful tool with many applications. That is, any strategy for positioning the Amiga in the consumer market has got to eventually rest on the utility of the machine itself. The theory that Rattigan was delaying the Amiga 2000 to hurt Commodore so stock values would go down is as plausible as any other I've heard. The thing should be viewed as a kind of magic box which does what it does elegantly and inexpensively. This is the way the Apple II was perceived for many years, and this gave the machine a kind of supernatural capacity which allowed it to survive many years of apparent obsolescence while remaining extremely USEFUL and, yes, even fun to use. This comes from a painstaking dedication on the part of software designers to create things which are not full of rough edges. Most techies like us can handle the rough edges with no problem; we just think of it as a minor, though irritating, annoyance. For a typical user, however, these rough edges can mean the difference between the machine sitting in the attic or in the living room or office. The typical user, furthermore, doesn't really know WHY s/he's not using the thing, it's just not "useful" or it's not "fun." This is not a function of hardware capacity alone; it is a function of the enthusiasm and dedication of an entire community of users and developers. It is NOT helped by a corporate policy to hold development back in the interests of compatibility; certainly this is an issue, but I feel if an operating system upgrade is done properly (as in Kickstart 1.2) it can be a source of renewed enthusiasm for the machine. Users are enchanted by the idea that just by changing a disk in the machine it goes three times faster. So-called naive users may not be aware of WHY they like using the machine more, but they can FEEL it, just as a nonmusician may not be able to understand all of the technical reasons why a great musician or performance moves them so much. There is a real perceived quality of using a machine which is directly related to these little things such as the time it takes to open a drawer, the slowness of icons appearing on the screen, and so forth. There has been some discussion about the "right" and the "wrong" way to do certain things; it is certainly true that to give up some features for the sake of perceived performance or simplicity of design is an important issue; but of even greater importance is the integrity and consistency of the design and its implementation, which translates into: a lot of time and effort. I admit the Commodore brass may not feel that hard work is so necessary to create something worthwhile; the whole illusion of Wall Street is that one can make money just by playing a game (the market). All such games must eventually falter (stock prices fall again.) (Of course, we love you, CATS, but we don't always love your bosses.) But I think there must be those up there who are sympathetic to this message: produce a good product, help the user community make it better, and don't get bogged down in amorphous issues such as "compatibility." Apple changed it's operating system TOTALLY (TOTALLY) in at least two rather major revolutions; first, to DOS 3.3 (more disk space), then to ProDOS (heiarchical file system, MUCH faster disk I/O). In each case users tended to embrace the changes, especially when it came with such revolutionary programs as AppleWorks (a wonderful example of a program which doesn't know that it's too powerful and easy to use to be running on a 6502- based 8- (yes, EIGHT!) bit computer.) (At one point AppleWorks was OUTSELLING Lotus 1-2-3; in fact, it had sold more at one point in TOTAL than 1-2-3. And, of course, AW is a MUCH nicer program to use; although it lacks features, it is a beautiful, simple design, I don't think it has been outdone by any other 8-bit program.) If the new OS is presented properly, (and one IMPORTANT criterion is that it not be over-designed, like UNIX and OS/2 with it's horrible hacks to preserve compatibility such as TWO sets of BIOS calls, etc.) it could easily catch on and become THE operating system for the Amiga line. It must be well designed!!! Simple, elegant, to the point. Look, if people want to use the old OS, they can use old ROMs or old Kickstart disks. Perhaps they can even load Kickstart into normal RAM, and since RAM is going to be ultra-cheap anyway (despite the machinations of Congress) it won't be too big of a cost. Compatibility cripples new OSs. A new OS is not a new OS if it tries too hard to be "compatible." If there are horrible, ugly problems, solve them at a minor cost to the user: just replace the whole software system. (This means, at worst, new ROMs; some way to bring up the old environment could be provided, perhaps, with ROMtags in RAM or some such.) This may sound radical, and, in fact, I just thought of it right this minute. I used to think there were good arguments for incremental OS improvements; now I think machines should be able to support multiple environments (the beauty of Kickstart.) Why not? There is NO user confusion; it is quite clear, the two operating systems are totally incompatible (well, they might both use Exec and most of Intuition, but you can't exchange disks, and software in one "universe" breaks in the other.) It is much more confusing to have constant incremental OS upgrades which don't really make it incompatible, but, oh yeah, you'll have to rev all of your software. Having simply two incompatible environments makes the situation crystal-clear; I doubt people expressed much anguish that their old DOS 3.3 stuff didn't work under ProDOS. They simply kept two sets of software; and everybody was happy (as long as there was file transfer and conversion software around.) The Amiga operating system, furthermore, makes the development of alternative environments rather easy; you don't have to replace everything, you can take out subsystems and munge around, cleaning things up, and you don't have to rewrite the entire thing from the ground up. The opportunties a truly clean DOS would open up for application developers and people putting systems together would be vast; in fact, the Amiga would probably ending up having a lifetime long beyond mere hardware obsolescence. (And, anyway, you can stick in 68020 cards, etc., just like the old Apple II owners could stick in 3x accelerators, 512K RAM expansions, and the like. Magic, that's what people enjoy, and that's what they perceive underneath all of the technical mumbo jumbo. And that's our job---to provide it.) Go all the way, guys. Compatibility is a Trojan horse. -Mitsu P.S. This does not mean I think the entire Amiga software system is bad; just DOS, basically. Even Workbench would be tolerable if not a joy to use if only DOS worked right. Workbench could use some work, too, however; now that the user community has had it for a couple of years, we could all use a good replacement. In fact, Intuition is very well done and so is the library system. JUST GET RID OF DOS!
bryce@COGSCI.BERKELEY.EDU.UUCP (05/01/87)
In article <2967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > I always thought that the simplest and easiest-to-implement hack to >the Workbench would be to create a file called "foo" (call it whatever you >like; the name isn't important). "foo" would be an ASCII text file that >contains, on each line, the filenames of all the .info files in this >directory. It's called ".info" and appears in every directory that you open up from the Workbench. It consists of a date/time stamp and the ASCII text names of all the .info files in that directory. Sound about right? type sys:.info opt h When the date/time stamp does not match the modification date on the directory the workbench reads EVERYTHING and updates ".info". Face it, you where out-hacked :-) . I am not sure if Workbench UPDATES this file or RE-WRITES it. If no new .info files appeared after after a scan it could just touch the date stamp quickly. Other things that Workbench may or may not already be doing: RENAME instead of COPY if source and destination are on the same volume. When 'snapshoting' a file SEEK() to the position bytes, do not re-write the entire file. // \\// I liked the bouncy-ball logo better; but it's hard to do as text!
gbs@utgpu.UUCP (05/02/87)
Summary:Amen References: <1816@husc6.UUCP> Reply-To: gbs@gpu.utcs.UUCP (Gideon Sheps) Keywords: compatibility versus radical improvements In article <1816@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes: >Re: Workbench improvements, compatibility, and computer revolutions In a short reply to a long posting... Amen. Yes. Agreed. Go for it. Just look at ibm products (for the big machines) that make all new advances look like 1960's technology so the os can cope! I have a friend who uses CMS (?) and the machine considers his terminal to be a "virtual card reader" why in 1987 is "card reader" still in the vocabulary at ibm? IBM profits dropped sharply last year as they have been doing for some time now. But, everythings compatible! C-A is just off a losing streak, they should be looking at this sort of thing for good ideas on what NOT to do. If it needs rewriting rewrite! Damn the torpedoes full speed ahead! =========================================================================== Gideon Sheps (or Cheops, as my Egyptian relatives spell it) I am not a number ... ...I am a free variable ! gbs@gpu.utcs.toronto.edu /// gbs@utorgpu.bitnet/EARN/NetNorth \\\/// I don't need a disclamer 'cause nobody listens to me. \\\/ ============================================================================ -- =========================================================================== Gideon Sheps (or Cheops, as my Egyptian relatives spell it) I am not a number ... ...I am a free variable ! gbs@gpu.utcs.toronto.edu /// gbs@utorgpu.bitnet/EARN/NetNorth \\\/// I don't need a disclamer 'cause nobody listens to me. \\\/ ============================================================================
acs@amdahl.UUCP (Tony Sumrall) (05/02/87)
In article <1987May2.003620.11966@gpu.utcs.toronto.edu> gbs@gpu.utcs.UUCP (Gideon Sheps) writes: >In article <1816@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes: >>Re: Workbench improvements, compatibility, and computer revolutions > In a short reply to a long posting... Amen. Yes. Agreed. Go for it. > > Just look at ibm products (for the big machines) that make all > new advances look like 1960's technology so the os can cope! > I have a friend who uses CMS (?) and the machine considers his > terminal to be a "virtual card reader" why in 1987 is "card reader" > still in the vocabulary at ibm? IBM profits dropped sharply last year > as they have been doing for some time now. But, everythings compatible! > C-A is just off a losing streak, they should be looking at this > sort of thing for good ideas on what NOT to do. If it needs rewriting > rewrite! Damn the torpedoes full speed ahead! >-- >=========================================================================== >Gideon Sheps (or Cheops, as my Egyptian relatives spell it) >I am not a number ... ...I am a free variable ! >gbs@gpu.utcs.toronto.edu /// >gbs@utorgpu.bitnet/EARN/NetNorth \\\/// > I don't need a disclamer 'cause nobody listens to me. \\\/ >============================================================================ I'm not normally in the position of "defending" things but I'll make an exception in this case and also take this opportunity to correct a misconception (or misstatement): CMS considers your terminal to be a 3215, not a card reader. A CMS user *may* have a virtual card reader as well as a virtual printer (a 3800 if you like). The user may define 3270 terminals which other users may use. (This is an oversimplification but it is basically correct). Anyway, I've used the virtual card punch/reader many times to exchange data with other machines (let's not discuss why IBM won't support full-duplex or even intelligent half-duplex on their mainstay operating systems). It's not a problem, it's just an 80-byte wide hole thru which I shove/pull my data. Facilities exist to shove lines longer than 80 bytes through it and restore the file to its original state. When it comes to compatibility in the IBM-compatible mainframe community, the reasons are mostly economic. A large institution may have literally billions of dollars tied up in the thousands of modules that go to make up their applications. Even a simple re-compilation of the system to handle a single non-compatible item can take months and cost hundreds of thousands of dollars (something that most businesses don't generally take kindly to) and can take much longer if problems develop because of "assumptions" that programmer's have made about the system that is *not* true in the new, non-compatible system. Don't get me wrong, it *has* been done but it's not easy. There are still many many installations out there that have not yet gone to 370-XA mode (real storage sizes of 2G, smarter I/O subsystem) and that was introduced...what was it...5 years ago? The reason? - conversion costs. Should the Amiga be worried about maintaining compatibility? If the machine is ever gonna be anything other than a hacker's machine, yes. Why - for the same reasons outlined above albeit on a smaller scale. I'm not saying that change is bad, just that it must be planned and implemented very carefully (i.e. don't go off half-cocked - that's what got us into this situation in the first place). -- Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
ain@s.cc.purdue.edu (Patrick White) (05/04/87)
In article <2967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > I always thought that the simplest and easiest-to-implement hack to >the Workbench would be to create a file called "foo"... > > Reconstruction of this file would be pathetically simple. Using >this file would be just as simple. Just open the file, read the filename, >open the filename, read the icon info, close the filename, and repeat for >all remaining filenames in the file (there would be one filename per line). I for one like this idea -- it is compatible with the old versions as well as adding speed to new ones. Anybody want to suggest a name? How about "info"? > But *PUHLEEZE* don't wack on the filesystem just to make Workbench's >life easier. You'll make everyone else's life more difficult. Many sounds of agreement here -- its too late to change the file system now. -- Pat White -------------------------------------------------------------------------------- UUCP: { ihnp4, seismo, ucbvax, decvax } ee.ecn.purdue.edu!s.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM U.S.Mail: 271 E. Sunset Ln. West Lafayette, In 47906
doc@j.cc.purdue.edu.UUCP (05/05/87)
In article <212@s.cc.purdue.edu> ain@k.cc.purdue.edu.UUCP (Patrick White) writes: >In article <2967@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > I for one like this idea -- it is compatible with the old versions as well >as adding speed to new ones. Anybody want to suggest a name? How about >"info"? EGADS!!! No, don't use the filename "info" for anything!! That is a big conflict with one of my flavorite commands on the Amiga and I would simply go nuts having it always tell me that I cannot execute 'info'... I also like the idea, but please use something like '.info.ext' for it! Craig Norborg comp.sources.amiga moderator j.cc.purdue.edu!doc