portuesi@tweezers.esd.sgi.com (Michael Portuesi) (08/02/89)
In article <1331@osupyr.mps.ohio-state.edu> vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) writes: In article <26872@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >I've heard rumors that something similar to ARP, only better designed >(not cramming everything into one library) is on 1.4. I am not sure that not cramming everything in one library will save space: [speculations on storage costs of 1.4 libraries deleted] I think that when Mike said "better designed", he was referring to design philosophy rather than storage requirements. I.E. by putting only related functionality into each library, you get more efficient library usage -- you're not loading a bunch of excess baggage when you open a library to do something, but loading a bunch of related functions you probably needed to use anyway. Currently, the ARP library is sort of a hodge-podge of unrelated functions. It gets away with it because it's not very large, but it is not good from the standpoint of future expansion. In Mike's earlier message, he said that the 12K savings from using ARP commands over AmigaDOS commands was "insignificant." Well, I haven't had my hard disk long enough to forget what using a floppy-based system was like, and 12K is very significant when you only have an 880K disk to boot from and half of it is taken up by necessary things like libraries and devices. In fact, that was the major reason why I bought a hard disk -- I wanted a huge environment with every command I could think of available to me at all times. --M -- Michael Portuesi Silicon Graphics Computer Systems, Inc. portuesi@SGI.COM
vkr@osupyr.mps.ohio-state.edu (Vidhyanath K. Rao) (08/03/89)
In article <26872@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >Pre 1.3 versions broke a _very_ important piece of AmigaDOS syntax. Hmm... I don't remember this. >Note that taking out ARP is much harder than putting >it in. Not really: If you have a big, i.e. less than 80% full, hard disk, (as I do) put the ARP commands in a directory by themselves, say "ac", and put it in your path. To take out arp, just remove it from your path. It worked for me during the 1.2->1.3 switch. If you have floppies only, make whole new boot disks. Didn't take long for me:-^ I don't remeber having trouble with the standard run in c:. With ARP shell the difference between c:run and ac/run is supposed to be immeterial. >I've heard rumors that something similar to ARP, only better designed >(not cramming everything into one library) is on 1.4. I am not sure that not cramming everything in one library will save space: Assuming that 1.4 puts lots of things into shared libraries [note the plural] I will expect every shareware/commercial programs to use AmigaDOS style wildcards and templates for commands (rather than downloading programs from #?x and ??-dos). Keeping just GADS, FindFirst/FindNext, PreParse/PatternMatch and the necessary resource management routines used by these from arp.library is likely to save may be 20% of memory used by arp.library. In fact, if one is not careful in designing the hierarchy of the libraries one may end up using more ram than arp.library, even if the seperate libraries are each about 20-30%. Incidentatly, are there any estimates on how long it will take for a significant proportion of Amiga owners (especially 500 owners) to upgrade to 1.4? After all, I am supposed to be able include the arp.library with my programs for free. CBM is not likely to allow one to do that with the new 1.4 libraries. What happens with this scenario? -- It is the man, not the method, that Nath solves the problem. vkr@osupyr.mps.ohio-state.edu -Poincare. (614)-366-9341
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/03/89)
< In article <26872@agate.BERKELEY.EDU>
< mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
< >I've heard rumors that something similar to ARP, only better designed
< >(not cramming everything into one library) is on 1.4.
< I am not sure that not cramming everything in one library will save space:
< [speculations on storage costs of 1.4 libraries deleted]
<
<
<I think that when Mike said "better designed", he was referring to
<design philosophy rather than storage requirements. I.E. by putting
<only related functionality into each library, you get more efficient
<library usage -- you're not loading a bunch of excess baggage when you
<open a library to do something, but loading a bunch of related
<functions you probably needed to use anyway.
This is indeed what I meant. It probably does mean that with everything
loaded, you're using up more memory. On the other hand, if you've got
a large application and are tight for memory, you may be able to ditch
one or more libraries. If everything is in one monster library, this
just doesn't work.
<In Mike's earlier message, he said that the 12K savings from using ARP
<commands over AmigaDOS commands was "insignificant." Well, I haven't
<had my hard disk long enough to forget what using a floppy-based
<system was like, and 12K is very significant when you only have an
<880K disk to boot from and half of it is taken up by necessary things
<like libraries and devices.
Like to point out that I said it was insignificant on my hard drive,
and that if I were using a less resource-rich Amiga, I'd seriously
consider looking at ARP1.3. However, given that 1) it only changes
useage of resources I have more than enough of; 2) I've got "fixed"
variations of the AmigaDOS commands whose limits really bother me; and
3) 1.4 is liable to have something similar in it, I don't see a lot of
reason to look at arp. If either of the first two were false, it'd be
high on the list; if the third were false, it'd be somewhere on the
list. As things stand, I have more important things to do (like finish
mg3a...).
<>Pre 1.3 versions broke a _very_ important piece of AmigaDOS syntax.
<Hmm... I don't remember this.
Question: what's the fastest editor for writing short programs on
AmigaDOS?
If you didn't say "copy *" or something similar, you're wrong. I tend
to create short programs by saying "copy * testit.c" or some such.
About the third time I did that and ARP copy stated copying every file
onto testit.c one at a time, I blew it away. Continued interference
with the standard meaning of "*" made me back the rest of the mess
out. I've been told that 1.3 fixes this.
<>Note that taking out ARP is much harder than putting
<>it in.
<Not really: If you have a big, i.e. less than 80% full, hard disk, (as I do)
<put the ARP commands in a directory by themselves,
Except that this requires _not_ doing the installation the way it was
suggested with the distribution I got. I did, of course, back up all
the stuff it was going to replace. That still left me stumbling over
commands every once in a whlie that I hadn't restored correctly.
<I don't remeber having trouble with the standard run in c:. With ARP shell
<the difference between c:run and ac/run is supposed to be immeterial.
Since we're on the topic: Does the ARP shell support ARexx macros
properly? Most importantly, can I build a pair of macros "cd" &
"back", where cd records the current directory, and back goes back to
the last saved directory (I find this much more useful than any
directory stack implementation I've ever used).
<mike
Note to AmigaDOS bashers: "*" is another one of the things that
AmigaDOS does right that Unix does wrong. With this, you don't have to
hack every program to understand some magic token to mean "read from
standard input instead of opening the file." Good Unix systems (like
the 4BSD ones I run :-) have something similar but more powerful in
/dev/fd.
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, mwm@berkeley.edu
Enmimes sont les gougebosqueux, ucbvax!mwm
Et le momerade horsgrave. mwm@ucbjade.BITNETrokicki@polya.Stanford.EDU (Tomas G. Rokicki) (08/04/89)
> Note to AmigaDOS bashers: "*" is another one of the things that > AmigaDOS does right that Unix does wrong. With this, you don't have to > hack every program to understand some magic token to mean "read from > standard input instead of opening the file." Good Unix systems (like > the 4BSD ones I run :-) have something similar but more powerful in > /dev/fd. Hi, Mike! I've always wanted to be able to fopen("|lpr", "w"), for instance, to spool things automatically, or anything else with pipes. Why hasn't any operating system (that I know of) allowed file names to also specify new processes? I mean, I can open `par:' or `ser:' or even `speak:'. Just a thought. > Il brilgue: les toves lubricilleux > Se gyrent en vrillant dans le guave, > Enmimes sont les gougebosqueux, > Et le momerade horsgrave. Clever; I like this. -tom
shadow@pawl.rpi.edu (Deven T. Corzine) (08/06/89)
On 3 Aug 89 11:13:56 GMT, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) said: Mike> Note to AmigaDOS bashers: "*" is another one of the things that Mike> AmigaDOS does right that Unix does wrong. With this, you don't Mike> have to hack every program to understand some magic token to Mike> mean "read from standard input instead of opening the file." Mike> Good Unix systems (like the 4BSD ones I run :-) have something Mike> similar but more powerful in /dev/fd. AmigaDOS's "*" is _exactly_ analogous to Unix's "/dev/tty". "*" is NOT synonymous with stdin. You can do "cp /dev/tty file" under Unix and get exactly the same effect as "copy * file" under AmigaDOS. /dev/fd is something completely different which AmigaDOS has no equivalent to. Also, most Unix programs were not "hacked to understand some magic token" -- the traditional approach is to accept a file argument, or a number of them, or to use stdin if no files are specified. True, often "-" is interpreted as "use stdin", but you CAN'T do the same thing with AmigaDOS. For example, "ls -l | cat file1 - file2 > file3" will not work under AmigaDOS. Apart from not having pipes available, "list | join file1 * file2 >file3" would not take stdin for the second file. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.