xanthian@well.UUCP (Kent Paul Dolan) (07/28/89)
I've heard "it's in there" about the 1.4 release. Here are my entries in
the great 1.4 wish list sweepstakes, in hopes that this is timely, and
finds some you missed.
Most important: make sure that the hard disk and other file system control
software is compatible with SCSI, removable medium, 1.5 Gbyte disks. These
drives should arrive before the 1.4 release. (Mfgr's name available to
CATS on request, if you haven't already had a demo of the existing
prototype.) In particular, limitations of "partition" sizes, numbers of
files/directories per directory node, maximum length of a path name, etc.,
should all be reviewed and improved in anticipation of truely fast, huge
(and extremely cheap; ~ $1/Mbyte drive cost) storage systems. In most
cases, hard limits should be replaced by soft limits; path name arrays ->
path name c-strings, directory name arrays -> directory name link lists,
und so weiter. I can hardly wait to put my 400 floppy disksfull of PD
software and data on one huge disk, and, at last, sort it out. [Naturally
the only practical backup for such a beast is another one just like it, so
I'll probably buy two!]
Merge list and dir commands ("ls" would be a catchy name for the result!)
and add the capabilities (as an "option") to create a directory listing
with full path names of files and also one with file path names from the
current/selected directory, compatible with the "all" option. This would
save half an hour per instance using an editor on "dir opt a" output to
prepare structured file name input for the "zoo aI" command, and similar
tasks. The existing list command's LFORMAT option could do this if list
had dir's "all" option and the path names of subordinate directories were
added to the first %S output.
Improve the list command LFORMAT option by using %P and %F for path and
file names instead of the current ambiguous (and therefore order dependent)
%S for both, and by allowing arbitrary numbers and orders of them in the
lformat string.
Smarten up the dir command to put the maximum possible number of columns of
file names, depending on the longest name in each column plus a bit of
spacing, rather than a fixed two columns. Even now, the workbench C: dir
overflows a screen in two column mode, so I use a PD routine called "ld"
for most directories, sacrificing alphabetized directories for four columns
of file names to have them all on one screen. This would work best if the
directory titles were full path names from the starting directory, so that
indentation to show depth could be avoided.
Automatic processing of the output of "dir opt a" output is made more
difficult because there is no directory line given before the files in the
current/requested directory are listed. Even '"" (dir)' would be a big
help.
Replace/supplement the existing "Pipe:" device with a real Unix(tm)-like
"|" pipe that can be used in a one line command.
Add a command to display/kill locks, to help clean things up when a disk
icon won't go away because some careless programmer left a lock engaged.
Add a capability to use extended selection for _any_ program, without
change to the object module, to make it think it is getting command line
input. I added a tool icon to my favorite microemacs (the one from
BENCHMARK Modula 2) and a project icon to files I was editing, but extended
selection won't convince the editor that it is seeing an argv[] character
string array containing a file name as argv[1]. It should be simple enough
to do this, and it would sure be nice to be able to do my work on "the
great American novel" in "point and shoot" mode, with long descriptive
project names tied to icons, rather than keeping a cli around and reverting
to short, quick to type file names.
While I'm on the subject, add paragraph flowing capability (preferably
including a fixed "indentation string" option, like GNUEmacs has) to the
Extras 1.3 MEmacs. That would make it almost usable for text processing
tasks on simple ASCII files, since it already works in extended selection
mode.
An otherwise empty, INSTALLed disk with :s/startup-sequence = "loadwb"
and :loadwb version 1.3 its only files fails to boot with a return code 20
from loadwb. The 1.3 docs for loadwb do not give any preconditions for its
successful operation, and none of the commands' docs give return code
interpretations. Both these problems need fixing. [I was trying to make
the Hack_Game: disk bootable, but it needed a workbench loaded to be
useful. No joy.]
Generically, your command documentation needs much more motivational
information added. When I read your docs, I know _how_ to use the commands,
but neither _why_, _when_, nor _where_.
Permit more than one RAD: (RAD0:, RAD1:, etc:) to be mounted, so that I can
copy several disks to memory, and give each the name its software is
expecting. Possibly this could be best accomplished by adding a "name" (or
"as") keyword to the MOUNT command: "Mount RAD0: as HACK_GAME:" or "Mount
RAD1: name HACK_GAME" are examples (note the colon for "as" but not for
"name").
Thanks for listening, as usual.
well!xanthian
Kent, the man from xanth, now just another echo from The Well.mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/29/89)
I've come up with some changes I'd like made, also. This are all at the command level, and are motivated by having tools that want to be able to run commands (make, and treewalk head the list). 1) Get rid of the limits on the number of arguments for delete, join & others. I've heard that this is already in the works. Having the limits makes makefiles and treewalks break unexpectedly when they are exceeded. 2) Add an option to delete so that it won't quit when it encounters a file it can't delete. Not having this makes delete nearly useless for "make clean" type things. Under normal circumstances (i.e. - deleteing a tree), this is nice, as it stops & you can still see the name of the file that broke it. Either making the "don't stop" an option, making it print the names of all files it couldn't delete at the end, or adding it to the "quiet" flag preservers this behavior. 3) List should be included under "removing limits", so that I can get a list of more than one file at a time without invoking pattern matching. Dir would benefit less from this. That same rumor included a comment that all the commands were going to be rewritten in C. If so, I would suggest that all command interfaces be evaluated in light of automated invocation from makefiles & similar utilities. <mike -- Cheeseburger in paradise Mike Meyer Making the best of every virtue and vice mwm@berkeley.edu Worth every damn bit of sacrifice ucbvax!mwm To get a cheeseburger in paradise mwm@ucbjade.BITNET
FelineGrace@cup.portal.com (Dana B Bourgeois) (08/01/89)
Mike Meyer is asking for unlimited arguments for list, and dir (among others). Sure sounds like ARP1.3 to me. C'mon. What do people have against small, fast, highly functional, free, already available commands? I use ARP commands and have no problems with them. I'd like to see Commodore put them into 1.4 which rumor has it is an offer already made to Commodore that they turned down! I shake my head in wonder. By using ARP one gets about 12K of space back on a workbench disk. This is significant. Can one of the CATS people comment on ARP and whether it will make it into AmigaDOS and if not why not? Dana Inquiring minds want to know. Get it at your local checkstand!
xanthian@well.UUCP (Kent Paul Dolan) (08/02/89)
[Following up my own posting; no class!] I work in a large ram, no HD: environment (Amiga 2000 with 9Mbytes, 2 floppies). It would be extremely nice if the large files I can now make in memory could be supported as multi-floppy-volume files. This is usually a mainframe feature for magnetic tape files, not a micro feature, but it would sure be nice to capture my normal software development environment in a zoo'ed file (it takes up about 2.2 mbytes after compression) onto three diskettes, then recover at my next cold boot with just one "zoo -extract" command and a couple of disk swaps. As is, I have to do a couple of trial zoo passes to get the right partitioning of files to match the size of each diskette. And that means about an hour's extra work. Again, thanks for listening. well!xanthian Kent, the man from xanth, now just another echo from The Well.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/02/89)
In article <20904@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
<Mike Meyer is asking for unlimited arguments for list, and dir (among
<others). Sure sounds like ARP1.3 to me.
Yes, but that doesn't let me write scripts, makefiles & treewalks and
give them to people without having to make sure they have some large,
nonstandard piece of software installed to work correctly.
<C'mon. What do people have against small, fast, highly functional, free,
<already available commands?
Pre 1.3 versions broke a _very_ important piece of AmigaDOS syntax. So
I backd it out. Note that taking out ARP is much harder than putting
it in. With most of 1.3 being resident and lots of resources, it's not
worth the risk of installing it. If I still had 2 floppies & .5Meg,
then it might be worth it. As it is, all I do is chew up some extra
memory (currently, I've got 3.5M of free fast ram....).
<I shake my head in wonder. By using ARP one gets about 12K of space
<back on a workbench disk. This is significant.
12K out of 60M is less than 2/100ths of a percent. This is
insignificant. Of course the arp library is also insignificant, so
it's on the disk so that applications don't fall over and die (nasty
habit) if it isn't there. It also gets used by rexxarplib.
<Can one of the CATS people comment on ARP and whether it will make it
<into AmigaDOS and if not why not?
I've heard rumors that something similar to ARP, only better designed
(not cramming everything into one library) is on 1.4. That's another
good reason for not installing it now.
<mike
--
That time we slept together Mike Meyer
That's as far as it went mwm@berkeley.edu
Yet though we're not quite lovers ucbvax!mwm
You're more than a friend mwm@ucbjade.BITNETmwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/03/89)
In article <12968@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes:
<[Following up my own posting; no class!]
Nah, just lazy. No worse than me pickig up your posting to make my
posting easier...
Anyway, to add to the wish list:
Unless I've broken things with a non-standard environment, currently
C-c's only get sent to the process actually talking to the terminal.
If that was started as one of a series by some program, then the
program that did the starting doesn't see the signal, just the
termination of the running program. If the broken (breaked?) program
doesn't signal that it saw a break, or the program that started it
doesn't check on these things (which it may be doing for good reason),
then the next program in the series will be started.
This is almost certainly not what the user wanted.
The suggested behavior change is obvious: make C-c stop all programs
involved. I would also suggest that C-d get the semantics that C-c has
now, so that the user can stop only the current process, and the next
one can continue if things are set up correctly (might as well do
something with all those break characters).
This should also affect a pipeline if the cli being used supports '|'
pipes, so that C-c goes to all processes in the pipeline.
Implementation: well, I can tell you how I'd tackle it, but I've been
warped by watching how Unix does it, so I won't unless asked.
<mike
--
When logic and proportion have fallen softly dead, Mike Meyer
And the white knight is talking backwards, mwm@berkeley.edu
And the red queen's off her head, ucbvax!mwm
Remember what the dormouse said. mwm@ucbjade.BITNETeachus@mbunix.mitre.org (Robert Eachus) (08/03/89)
In article <12968@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: >I work in a large ram, no HD: environment (Amiga 2000 with 9Mbytes, 2 >floppies). It would be extremely nice if the large files I can now >make in memory could be supported as multi-floppy-volume files. Sounds silly, but get a hard-disk backup program! All of the ones I am familiar with, including the PD ones, will backup to multiple floppies without pre-partioning. I won't recommend one, since my situation is not yours, and my criteria are not yours. (I do my backups over an NFS connection, so I need a backup program which uses the FS system on the target without counting on knowing too much about it.) Only on the Amiga do you need a backup program for your ram-disk! Robert I. Eachus
sparks@corpane.UUCP (John Sparks) (08/03/89)
<20904@cup.portal.com> Sender: Reply-To: sparks@corpane.UUCP (John Sparks) Followup-To: Distribution: na Organization: Corpane Industries, Inc. Keywords: In article <20904@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >C'mon. What do people have against small, fast, highly functional, free, >already available commands? The reason I don't use arp is because of the pesky arp.library that has to be around. I always seem to get into a situation where I need it but the arp program can't seem to find it. It's more a hassle than anything else. I usually say the hell with it and use AmigaDOS commands -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps ||||||||||||||| sparks@corpane.UUCP | 502/968-5401 thru -5406 As far as we know, our computer has never had an undetected error.
perley@vdsvax.crd.ge.com (Perley Donald P) (08/05/89)
In article <12968@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: >I work in a large ram, no HD: environment (Amiga 2000 with 9Mbytes, 2 floppies). >It would be extremely nice if the large files I can now make in memory could be >supported as multi-floppy-volume files. This is usually a mainframe feature >for magnetic tape files, not a micro feature, but it would sure be nice to >capture my normal software development environment in a zoo'ed file (it takes >up about 2.2 mbytes after compression) onto three diskettes, then >recover at my next cold boot with just one "zoo -extract" command and a couple >of disk swaps. Take a look at DosKwiK, on fish disk 103 (there may be a newer version). It was written to do just that. It uses a non-dos format for the disks, and runs about as fast as a diskcopy to rad: (faster than "diskcopy df0: to df1:", for example). I don't think it does any compression, but the speed makes up for it. -- -don perley perley@crd.ge.com
sinclair@oakhill.UUCP (Brian Sinclair) (08/05/89)
In article <20904@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >Mike Meyer is asking for unlimited arguments for list, and dir (among >others). Sure sounds like ARP1.3 to me. > >C'mon. What do people have against small, fast, highly functional, free, >already available commands? I use ARP commands and have no problems with >them. I'd like to see Commodore put them into 1.4 which rumor has it is >an offer already made to Commodore that they turned down! > >I shake my head in wonder. By using ARP one gets about 12K of space >back on a workbench disk. This is significant. > >Can one of the CATS people comment on ARP and whether it will make it >into AmigaDOS and if not why not? > >Dana > >Inquiring minds want to know. Get it at your local checkstand! Well Dana, I dont know about the folks at CATS, but I love using ARP1.3. My only complaint is that if you perform the installation as outlined in the documentation you will no longer be able to autoboot from the RAD: device. I had the same problem with ARP1.1 under AmigaDOS1.3. I finaly did get my 1000 to autoboot from RAD: using ARP1.1 by reinstalling some of the original AmigaDOS files. I havent had time to investige the problem using ARP1.3. I am however still running ARP1.3 anyway! P.S. this is my first netmail message so PLEASE forgive any errors. Regards, Brian Sinclair *:-)
pmf@mimsy.UUCP (Paul M. Franceus) (08/07/89)
Actually, you CAN reboot out of RAD: while using ARP. Just put a "BootPri=0" in the mountlist for the RAD and it will work fine. Paul Franceus StarLight Technologies