Xref: utzoo comp.sys.amiga:37819 comp.sys.amiga.tech:6469
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!decwrl!ucbvax!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: Relying on ARP (was Re: My AmigaDOS 1.4 wishlist (one among thousands!))
Message-ID: <26915@agate.BERKELEY.EDU>
Date: 3 Aug 89 11:13:56 GMT
References: <12878@well.UUCP> <26758@agate.BERKELEY.EDU> <20904@cup.portal.com> <26872@agate.BERKELEY.EDU> <1331@osupyr.mps.ohio-state.edu> <PORTUESI.89Aug2152814@tweezers.esd.sgi.com>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Distribution: na
Organization: Missionaria Phonibalonica
Lines: 84

<   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.BITNET