252u3130@fergvax.unl.edu (Phil Dietz) (11/14/90)
Hmmmph....with the discussion of wild cards, people have been coming
out of the cracks and harassing ARP. Boy if my memory works right (256
bit of course), when ARP came out, it was the hottest thing to use.
Everyone mentioned how ALL the c:commands were so and so smaller, so and
so faster cauz they were written in Assembly, and so and so better
because they offered more flags!!!!! Plus it offered full UNIX
wildcards and even a shell with built in commands.....
But now......
People want to suddenly change...why? True, you do have to use their
library (that always likes to stay open), but what does an extra 12k
mean when you have the more powerful commands.....plus it has a nice
short file requestor built in that ALOT of programs use (like muchmore
and much much more :)
Explain.....and I shall let you live...... :)
Phil Dietz
<<<=================--------- Cheap Ad ---------===================<<<
Phil Dietz SWL Lincoln 565 MEGS! 2 lines
252u3130@fergvax.unl.edu (402)421-1963 AMIGA, IBM, MAC, GIFS
IBM'ers and Mac'ers are shopping for a life. Amiga the best!peter@sugar.hackercorp.com (Peter da Silva) (11/14/90)
In article <1990Nov14.034507.19784@hoss.unl.edu> 252u3130@fergvax.unl.edu (Phil Dietz) writes: > Hmmmph....with the discussion of wild cards, people have been coming > out of the cracks and harassing ARP. Boy if my memory works right (256 > bit of course), when ARP came out, it was the hottest thing to use. Not me, dude. I've been harassing ARP since the beginning. (a) It's all in assembler. That's a big no-no for me. (b) They never got it all together. It was missing major programs (like copy) and the programs that did come out tended to have weird bugs (um, non standard features if you like). I'm sure (b) was due to (a). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
DXB132@psuvm.psu.edu (11/15/90)
In article <7039@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) says: >In article <1990Nov14.034507.19784@hoss.unl.edu> 252u3130@fergvax.unl.edu >(Phil >Dietz) writes: >> Hmmmph....with the discussion of wild cards, people have been coming >> out of the cracks and harassing ARP. Boy if my memory works right (256 >> bit of course), when ARP came out, it was the hottest thing to use. >Not me, dude. I've been harassing ARP since the beginning. >(a) It's all in assembler. That's a big no-no for me. >(b) They never got it all together. It was missing major programs (like copy) > and the programs that did come out tended to have weird bugs (um, non > standard features if you like). >I'm sure (b) was due to (a). Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of very talented and enthusiastic programmers, and they did a damn fine job, a lot better than those cheesy BCPL crap-garbage-explitive commands!!! Feel free to flame me, but stop flaming ARP! -- Dan Babcock
cedman@golem.ps.uci.edu (Carl Edman) (11/15/90)
In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: In article <7039@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) says: >In article <1990Nov14.034507.19784@hoss.unl.edu> 252u3130@fergvax.unl.edu >(Phil >Dietz) writes: >> Hmmmph....with the discussion of wild cards, people have been coming >> out of the cracks and harassing ARP. Boy if my memory works right (256 >> bit of course), when ARP came out, it was the hottest thing to use. >Not me, dude. I've been harassing ARP since the beginning. >(a) It's all in assembler. That's a big no-no for me. >(b) They never got it all together. It was missing major programs (like copy) > and the programs that did come out tended to have weird bugs (um, non > standard features if you like). >I'm sure (b) was due to (a). Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of very talented and enthusiastic programmers, and they did a damn fine job, a lot better than those cheesy BCPL crap-garbage-explitive commands!!! I am very happy that there are a few more people out there who give ARP the good grades it deserves. It was and is one of the greatest programmers tools for the amiga and I still use it today. It is to this day the only shell which made all the right design choices, starting from being small and fast to being largly compatible and implemented in as a system library. BTW, what is this about there not being an ARP Copy ? I just checked my ARP directory (as if I needed to...) and there it is and works fine since years. What about founding the AADL , the "Anti Arp Defamation League" ? :-) Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
cedman@golem.ps.uci.edu (Carl Edman) (11/15/90)
In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: In article <7039@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) says: >In article <1990Nov14.034507.19784@hoss.unl.edu> 252u3130@fergvax.unl.edu >(Phil >Dietz) writes: >> Hmmmph....with the discussion of wild cards, people have been coming >> out of the cracks and harassing ARP. Boy if my memory works right (256 >> bit of course), when ARP came out, it was the hottest thing to use. >Not me, dude. I've been harassing ARP since the beginning. >(a) It's all in assembler. That's a big no-no for me. >(b) They never got it all together. It was missing major programs (like copy) > and the programs that did come out tended to have weird bugs (um, non > standard features if you like). >I'm sure (b) was due to (a). Assembler is a minus ? What are you getting at ? Assembler programming certainly is the best and most taxing way of programming for programmers. It produces invariably the smallest and fastest code for users. Maybe programmers who don't write in assembler can be forgiven for their by their users if they: a) use C and the fastest C-compilers on the market b) are aware that they are sacrifying the quality of the programm and the convinience of the user against their laziness and development time. And now using assembler is a "big no-no" ? What is the world coming to ? I remember a time when people (e.g. me) wrote full-screen editors in hex, because they didn't have an assembler and nowadays people write cr/lf-filters in smalltalk with 200 kb runtime libraries and clocktools under X-Windows with full debugging information (for the tool and x-windows, just in case...) at 500 kbytes. Only slightly exagerating Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/15/90)
In <CEDMAN.90Nov14192256@lynx.ps.uci.edu>, cedman@golem.ps.uci.edu (Carl Edman) writes: > >I am very happy that there are a few more people out there who give >ARP the good grades it deserves. It was and is one of the greatest >programmers tools for the amiga and I still use it today. It is to >this day the only shell which made all the right design choices, >starting from being small and fast to being largly compatible and >implemented in as a system library. While I use and like many of the ARP commands, I would point out that WShell is also small, fast, and implemented as a system library. I feel that it has better design than ASH, but that's pretty subjective. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
hclausen@adspdk.UUCP (Henrik Clausen) (11/15/90)
In article <1990Nov14.034507.19784@hoss.unl.edu>, Phil Dietz writes: > Hmmmph....with the discussion of wild cards, people have been coming > out of the cracks and harassing ARP. > Explain.....and I shall let you live...... :) The first releases of ARP where nice, but whith the coming of the ARP shell, many things broke: The Shell was not compatible enough, breaking several installation scripts, including Lattice C. Many programs would simply fail with ARP installed, for instance remote shells on DNet. A fanatic DNet user, this was some problem. Lots of Harddisks have been sold since the first ARP came out - reducing the acuteness of command size. And, finally, lots of the ARP stuff made it into the new Kickstart! 8-) This includes much smaller Shell commands - many are actually shorter than the ARP equivalents!! You can have '*' for wildcard as well now. -Henrik Do I survive?? | Henrik Clausen, Graffiti Data | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Do not accept the heart that is the slave to reason" - Qawwali trad__/
himacdon@maytag.uwaterloo.ca (Hamish Macdonald) (11/16/90)
>>>>> In article <CEDMAN.90Nov14193209@lynx.ps.uci.edu>, >>>>> cedman@golem.ps.uci.edu (Carl Edman) writes: Carl> And now using assembler is a "big no-no" ? What is the world coming to ? Today's CPUs are becoming more and more complicated, making it more difficult to write correct assembler code (especially RISC CPUs, or a multiprocessor environment, or a combination of the two). Of course, the compiler writers have similar problems in ensuring that the code their compilers generate is correct, but at least that is done in only one place, not in every program you write (I know, I know, it is difficult if not impossible to _prove_ that a compiler generates correct code in all instances...) In any case, compilation by a C compiler followed either by hand-optimization of the assembly code generated (if any), or by going back to the code and re-coding inefficient-generated or most-used sections should get you both the fast-development time and the program performance you require. Hamish. -- -------------------------------------------------------------------- himacdon@maytag.uwaterloo.ca watmath!maytag!himacdon
cedman@golem.ps.uci.edu (Carl Edman) (11/16/90)
In article <1990Nov15.160222.23856@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes: >>>>> In article <CEDMAN.90Nov14193209@lynx.ps.uci.edu>, >>>>> cedman@golem.ps.uci.edu (Carl Edman) writes: Carl> And now using assembler is a "big no-no" ? What is the world coming to ? Today's CPUs are becoming more and more complicated, making it more difficult to write correct assembler code (especially RISC CPUs, or a multiprocessor environment, or a combination of the two). Of course, the compiler writers have similar problems in ensuring that the code their compilers generate is correct, but at least that is done in only one place, not in every program you write (I know, I know, it is difficult if not impossible to _prove_ that a compiler generates correct code in all instances...) In any case, compilation by a C compiler followed either by hand-optimization of the assembly code generated (if any), or by going back to the code and re-coding inefficient-generated or most-used sections should get you both the fast-development time and the program performance you require. I absolutely agree. This is the way I've been doing it since many years. If you've got a good C compiler then programming much of the "driving" software in C is excuseable, and maybe even the users benefit from having a better program. You can get 90% of the speed by in the end "down-coding" the critical portions (tight loops a.s.o.). What I really objected to was the idea that if some group of idealistic and very good programmers actually goes to such lengths to produce the optimal code for their users , this is called a "big no-no". Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
ben@epmooch.UUCP (Rev. Ben A. Mesander) (11/16/90)
>In article <18366c2e.ARN04050@adspdk.UUCP> hclausen@adspdk.UUCP (Henrik Clausen) writes: > The first releases of ARP where nice, but whith the coming of the ARP >shell, many things broke: > > The Shell was not compatible enough, breaking several installation >scripts, including Lattice C. [other stuff deleted about dnet, which I have no knowledge of] That's pretty weird. Don't tell my computer about this - I installed Lattice 5.05 _and_ SAS/C 5.10 with ARP shell and all the ARP commands. Maybe my computer never knew about this... >| Henrik Clausen, Graffiti Data | I've also heard assertations that the ARP shell uses wildcards and not regular expressions. NONSENSE! I say. ARP shell supports the normal AmigaDOS regexps, and it also supports '*' as a synonym for '#?'. In addition to that, it supports character classes: [characters], and a negation character '~'. So I can delete all the non-source-code files out of a directory with: delete ~*.[ch]. Or I can zoo up the files in a directory and get rid of everything but the zoo file with: delete ~*.zoo. I can rename all the data files in a directory from #?.dat to old.#?.dat like this: move #?.dat old.#?.dat There have also been claims that you have to install ConMan to get pipes. NONSENSE! I say. Just grab the conman library, put it in LIBS:, put the handler in L:, and you have pipes. To be honest, I'm not even sure what ConMan _does_, and I never installed it. Before people flame on about this, RTFM! Really. Re: assembly versus C source code: Well, to each his own. Don't be a language-nazi. Some people can develop as quickly in assembly as HLL's, some people even write assembler code for a living. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
cedman@golem.ps.uci.edu (Carl Edman) (11/16/90)
In article <ggk.658699652@tirith.UUCP> ggk@tirith.UUCP (Gregory Kritsch) writes: cedman@golem.ps.uci.edu (Carl Edman) writes: >In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: > a) use C and the fastest C-compilers on the market > b) are aware that they are sacrifying the quality of the programm > and the convinience of the user against their laziness and > development time. >And now using assembler is a "big no-no" ? What is the world coming to ? Assembly language has some advantages and disadvatages. As time progresses, compilers are getting better and more standard, and assembler is becoming more complex. What may have been the case a while ago is no longer the case. One reason I like C over assembler is portability. For example, if I get really sick of the mail program on Watstar (ie I ever have to use it again...), I can probably take a copy of dmail sources which I use, and compile it pretty much straight up. I agree. For some applications the difference of quality between the same application written in assembler or C may be small. And the developement time for C may be MUCH smaller. Still you are sacrificing a little speed and size for a lot of development time. That may be a perfectly reasonable, even adviseable tradeoff. The only thing about the original poster which annoyed me was that he wrote that assembler is a "big no-no". Well, maybe anything less will do, but counting being written in assembler against(!) a program is a real perversion of standards. Your argument about portability does apply to many machines and programs, but not at all to ARP, the original subject. ARP was never intended to be ported to any other machine, and wouldn't be useful to port. Portability is not an issue against it. [ ... ] >I remember a time when people (e.g. me) wrote full-screen editors >in hex, because they didn't have an assembler and nowadays people write >cr/lf-filters in smalltalk with 200 kb runtime libraries and clocktools >under X-Windows with full debugging information (for the tool and >x-windows, just in case...) at 500 kbytes. So, whats your point? It probably took 2 minutes to do the cr-lf program, and 5 for the clock. And if they don't work, it'll take another 2 minutes to find out why not. What I am complaining about ? [raving-prophet-of-the-doom-of-computerdom-and-the-decadence-of- -the-young-programmers-mode on ] It is a terrible abuse of resources. The new computers are great in term of power/memory/hd sizes. These are things I've dreamed about for decades. I've for years again and again conceived great projects and programs to do things that no program has done before and so have others. And the only thing that again and again prevented the full execution, was the limitation of the machinery. But now machines which can do wonders are available to everyone. But what happens ? Do new, imaginative mind-blowing programs appear at every turn ? No, not a chance. Instead of using the new machines to their full potential programers merely go around and do the same things they used to do with the old machines over again. Only this time they are far less careful. They squander resources on a few minutes laziness. Most games e.g. are as simple and boring as they've ever been. No one adds really great plots or elements which were impossible before. The programs stay the same, all people do is add 16-bit sound sampled at 44 kHz and 1024x640 graphics in 16 Mcolors. Of course,not drawn graphics or composed sounds. No, digitized sounds and graphics. Maybe with a few hours of programming you could write a program which generates the same sounds in a few kBytes. But , who cares ? Put it in the digitizer and generate a Mbyte sample, it is so much easier. Creating a few kbytes of carefully handcrafted assembly language takes days. Creating a few MBytes of sampled sound is a matter of seconds. I think that users are cheated out of a revolution in new programs made possible by the new machines by the laziness of programmers. That is what I am complaining about. [mode off] In assembly, you're looking at a much longer development time, and if you don't include debug info, you looking at a much longer debug time as well. Debug info ? fine. I use debuggers, too. A lot. But NOT in distribution copies of the program, which go to people who don't know debuggers, or don't have debuggers, or even if they had would take weeks to understand your program well enough to get any use out of it. >Only slightly exagerating > Carl Edman I am using large machines with lots of memory today, too. But I learned to program on a computer with 1 kByte of memory and if you used more than half of it, the screen was turned of as the screen memory was used for the program. Maybe that shows. I hope it does. Carl "When you have 'cat', who needs compilers ?" Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
jesup@cbmvax.commodore.com (Randell Jesup) (11/16/90)
In article <CEDMAN.90Nov14192256@lynx.ps.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes: {talking about the ARP shell} > It is to >this day the only shell which made all the right design choices, >starting from being small and fast to being largly compatible and >implemented in as a system library. Well, there are as many definitions of what a shell "should be" as there are users, I'm afraid. And ASH made one MAJOR boo-boo: it creates it's own process structures, and this will NOT work under 2.0. Crash, burn, up in flames. :-( (Note: this is what Charlie told me, I never bothered trying it myself.) Arp had some nice ideas, but parts of it suffered from a lack of overall design and had some flaws related to the way in which it was coded (tight, tricky assembler is small, but it can lead to some nasty boo- boos, especially when you don't have a tight design first). The basic premise of Arp was good, which was why we incorporated a fair amount of Arp (or it's equivalents, designed with hindsight) into 2.0 when I rewrote it in C/asm. And of course, with all those new calls and with the new commands written in C, they got smaller (or went into the shell, or got a number of useful new features). Plus they're a lot easier to maintain and debug in C. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/16/90)
In <CEDMAN.90Nov15163504@lynx.ps.uci.edu>, cedman@golem.ps.uci.edu (Carl Edman) writes: >In article <ggk.658699652@tirith.UUCP> ggk@tirith.UUCP (Gregory Kritsch) writes: >What I am complaining about ? >[raving-prophet-of-the-doom-of-computerdom-and-the-decadence-of- > -the-young-programmers-mode on ] > >It is a terrible abuse of resources. The new computers are great in >term of power/memory/hd sizes. > > [ ... ] > >But what happens ? Do new, imaginative mind-blowing programs appear at >every turn ? > >No, not a chance. Instead of using the new machines to their full >potential programers merely go around and do the same things they used >to do with the old machines over again. Only this time they are far >less careful. They squander resources on a few minutes laziness. It has always been this way, and will always be this way. "No matter how good the hardware guys make it, the software guys just piss it away." -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (11/16/90)
In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: > Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of > very talented and enthusiastic programmers, and they did a damn fine job, a > lot better than those cheesy BCPL crap-garbage-explitive commands!!! Well, I beg to differ. I'm sure they're great guys and all but they spent a lot of energy solving a problem that didn't exist. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (11/17/90)
In article <CEDMAN.90Nov14192256@lynx.ps.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes:
I am very happy that there are a few more people out there who give
ARP the good grades it deserves. It was and is one of the greatest
programmers tools for the amiga and I still use it today. It is to
this day the only shell which made all the right design choices,
starting from being small and fast to being largly compatible and
implemented in as a system library.
I'm willing to give it good grades; if you're so desperate for space
you're willing to live with buggy and/or non-standard commands, then
it's great. But they broke the fastest editor on the Amiga, and I
couldn't live with that.
I never even tried ASH; it doesn't run on my system, and breaks
CLI scripts on other peoples systems.
WShell, on the other hand, has all the features you applaud in ASH,
doesn't break CLI scripts (though even WShell isn't 100% compatable,
but Bill tries _very_ hard to make it so), and runs reasonably on my
system.
BTW - I'm not desperate for space; I keep the arp stuff installed on
the off chance that I get something that actually _needs_ one of the
incompatabilities of the ARP commands. I just never use them myself.
<mike
--manes@vger.nsu.edu (11/20/90)
In article <90318.162021DXB132@psuvm.psu.edu>, DXB132@psuvm.psu.edu writes: > > Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of > very talented and enthusiastic programmers, and they did a damn fine job, a > lot better than those cheesy BCPL crap-garbage-explitive commands!!! > > Feel free to flame me, but stop flaming ARP! > > -- Dan Babcock I have absolutely hated ARP since its very beginning. The name 'AmigaDOS Replacement Project' says it all. It says to me anyway, that Commodore does not know what it is doing and look with ARP we can do it "right". Well history has proven that ARP has produced more strange problems, incompatibilities and other oddities than it ever solved. It also proves that the masses can't do a better job. The *only* thing that came from the ARP Project (??) was the arp.library. This finally gave a fairly simple (though brain-damaged) file requestor. Personally, if I find a commercial package that relies on the ARP command set, I get rid of it. It is hard enough for most to learn AmigaDOS, adding a command set that doesn't work particularly well does nothing but add a support headache for Commodore and their dealers, and makes the outsiders believe that AmigaDOS needed replacement. I support Dan Silva's position on this. -mark= +--------+ ================================================== | \/ | Mark D. Manes "Mr. AmigaVision" | /\ \/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ==================================================
static@phoenix.pub.uu.oz.au (geoff c wing) (11/20/90)
In <CEDMAN.90Nov14193209@lynx.ps.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes: >In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: > In article <7039@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da > Silva) says: > >In article <1990Nov14.034507.19784@hoss.unl.edu> 252u3130@fergvax.unl.edu > >(Phil > >Dietz) writes: > >> Hmmmph....with the discussion of wild cards, people have been coming > >> out of the cracks and harassing ARP. Boy if my memory works right (256 > >> bit of course), when ARP came out, it was the hottest thing to use. > >Not me, dude. I've been harassing ARP since the beginning. > >(a) It's all in assembler. That's a big no-no for me. > >(b) They never got it all together. It was missing major programs (like copy) > > and the programs that did come out tended to have weird bugs (um, non > > standard features if you like). > >I'm sure (b) was due to (a). >Assembler is a minus ? What are you getting at ? Assembler programming >certainly is the best and most taxing way of programming for programmers. Agreement. >It produces invariably the smallest and fastest code for users. Maybe >programmers who don't write in assembler can be forgiven for their >by their users if they: > a) use C and the fastest C-compilers on the market Disagreement. > b) are aware that they are sacrifying the quality of the programm > and the convinience of the user against their laziness and > development time. Agreement. >And now using assembler is a "big no-no" ? What is the world coming to ? [..... stuff deleted .....] C has only one good use for real programmers, and that is that it is portable. If you want to do some proper coding without being lazy then assembly is the only choice. Amiga's LHArc was originally in C. Wasn't that a fast program? Of course, ARP was a big advancement in programming in DOS, especially the tracking functions, because now you can LAZY and not close anything or free memory, just like C. Wow. So all you lowclass programmers who can only program in one language(especially if you can only code in C) stop posting this rubbish to amiga.tech. If you have to post it post it to alt.garbage.dump -- +---------------------------------+ _ _ _ _ __ | Geoff //| /\ |\/| | / _ /\ | static@phoenix.pub.uu.oz.au \X/ | //\\ | | _|_ \__| //\\ +---------------------------------+
dailey@frith.uucp (Chris Dailey) (11/20/90)
In article <7056@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >> Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of >> very talented and enthusiastic programmers, and they did a damn fine job, a >> lot better than those cheesy BCPL crap-garbage-explitive commands!!! >Well, I beg to differ. I'm sure they're great guys and all but they spent a >lot of energy solving a problem that didn't exist. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I beg to differ. I used switched to ARP when I didn't have enough space on the old WorkBench disk. I had already moved the fonts to a separate disk, and with the miscellaneous .library files on WB there was no more room for anything else. After installing ARP, I had room to add one additional item (namely, MSH), which I could not have done otherwise. I have had no problems with it for the things I use it for. (Not-So-Nonexistent) Problem solved. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu BRD += DDR; DDR = NULL; num_countries --;
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/21/90)
In <253.2747d0bd@vger.nsu.edu>, manes@vger.nsu.edu writes: >In article <90318.162021DXB132@psuvm.psu.edu>, DXB132@psuvm.psu.edu writes: >> >> Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of >> very talented and enthusiastic programmers, and they did a damn fine job, a >> lot better than those cheesy BCPL crap-garbage-explitive commands!!! >> >> Feel free to flame me, but stop flaming ARP! >> >> -- Dan Babcock > >I have absolutely hated ARP since its very beginning. The name >'AmigaDOS Replacement Project' says it all. It says to me anyway, >that Commodore does not know what it is doing and look with ARP >we can do it "right". Yup... says it all. That CBM adopted much of ARP's philosophy says a lot too. CBM knew all along that the BCPL stuff adopted at the last minute was ill fitting with the rest of the machine, that it presented anomaly's that were unacceptable and would have to eventually be eliminated. >Well history has proven that ARP has produced more strange problems, >incompatibilities and other oddities than it ever solved. It also >proves that the masses can't do a better job. Oh? I had problems with exactly 3 of the ARP commands, and no more. I wish I could have said the same for the supplied Amigados commands. Remember, we are talking about history here, and not the supplied commands as we now know them, highly influenced by many third party ideas, ARP included. >The *only* thing that came from the ARP Project (??) was the arp.library. >This finally gave a fairly simple (though brain-damaged) file requestor. Sure, if you don't count better help (command followed by question mark, followed by another question mark), more consistent operation and use of options, smaller size (important when HDs were as scarce as meaningful Usenet postings), added capability in many commands, and so on. >It is hard enough for most to learn AmigaDOS, adding a command set that >doesn't work particularly well does nothing but add a support headache >for Commodore and their dealers, and makes the outsiders believe that >AmigaDOS needed replacement. I would agree, though I fail to see where the ARP command set "doesn't work particularly well". As of the inception of ARP, the Amigados command set did not work particularly well, or consistently. It _did_ need replacement. The interfaces to the Amigados functions _did_ need revamping. That CBM apparently agrees is ample proof that ARP was, if not the total answer, at least a demonstration that the concepts were valid. >I support Dan Silva's position on this. Oh.. does Dan share those views too? I haven't seen anything from him since that paint program with the braindead file requester, the severe bugs, and no usage of the ARP library, which shoule make you happy, at least. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jdege@ (Jeff Dege) (11/21/90)
In article <1990Nov20.045016.8678@phoenix.pub.uu.oz.au> static@phoenix.pub.uu.oz.au (geoff c wing) writes: > >C has only one good use for real programmers, and that is that it is portable. >If you want to do some proper coding without being lazy then assembly is the >only choice. Amiga's LHArc was originally in C. Wasn't that a fast program? >Of course, ARP was a big advancement in programming in DOS, especially >the tracking functions, because now you can LAZY and not close >anything or free memory, just like C. Wow. So all you lowclass programmers who >can only program in one language(especially if you can only code in C) stop >posting this rubbish to amiga.tech. If you have to post it post it to >alt.garbage.dump There is a significant difference between efficient use of programmers time and laziness. Considering the cost of software development and the relative productivity of higher-level languages, I'm constantly amazed that there are still folks around who believe that assembly is suitable for general purpose programming. Assembly has its place, but if you ever plan on making a living at it, you had better get off your high horse and find a more efficient method for meeting the customer's needs. ----------------------------
cedman@golem.ps.uci.edu (Carl Edman) (11/21/90)
In article <1990Nov20.045016.8678@phoenix.pub.uu.oz.au> static@phoenix.pub.uu.oz.au (geoff c wing) writes: In <CEDMAN.90Nov14193209@lynx.ps.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes: >Assembler is a minus ? What are you getting at ? Assembler programming >certainly is the best and most taxing way of programming for programmers. Agreement. >It produces invariably the smallest and fastest code for users. Maybe >programmers who don't write in assembler can be forgiven for their >by their users if they: > a) use C and the fastest C-compilers on the market Disagreement. > b) are aware that they are sacrifying the quality of the programm > and the convinience of the user against their laziness and > development time. Agreement. >And now using assembler is a "big no-no" ? What is the world coming to ? [..... stuff deleted .....] C has only one good use for real programmers, and that is that it is portable. If you want to do some proper coding without being lazy then assembly is the only choice. Amiga's LHArc was originally in C. Wasn't that a fast program? Of course, ARP was a big advancement in programming in DOS, especially the tracking functions, because now you can LAZY and not close anything or free memory, just like C. Wow. So all you lowclass programmers who can only program in one language(especially if you can only code in C) stop posting this rubbish to amiga.tech. If you have to post it post it to alt.garbage.dump Now please, don't be offensive. Being quite a high-class programmer :-> and being able to write software in at least half a dozen languages (counting only major differences in languages , and software only large projects) easily and able to read at least 3 dozen more languages without problem, I don't think your comment applies to me (if you intended it to). But lets remember one thing: There was a time when all of us only knew one language (if we learned to program at all :-) and if that one language was C or assembler and not BASIC or PASCAL, then that is already quite a good start. The only good use of C is portability ? I deny that. On almost all environments a well-written C program (compiled with a decent compiler) is second only to a well-written assembler program in speed and size. That there are badly written C-programs (like LHArc) is no point against C. There are just as many (and I might venture to guess, more) badly-written assembler programs, which lose just as badly. About not closing things ? True: One of the worst sins of brainless coders is it not to return resources to the system as soon as possible. But HOW he causes that to happen really isn't terribly important. Having ARP return the resources creates smaller code, prevents any resources from being forgotten in one uncommon termination, allows external termination of the program with correct return of resources, and (for most resources) only insignificantly affects the size of the required resources (for tracking information). Merely spewing abuse over ARP for offering (not requireing !) this service doesn't make any point. BTW, how did you ever get the idea that you don't have to free memory/files when using C ? You aren't using c-library routines which do tracking instead of the system calls , and get linked at link-time to create HUGE execs, are you ? Carl "Who wouldn't have thought to get attacked from that corner" Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
peter@sugar.hackercorp.com (Peter da Silva) (11/21/90)
In article <253.2747d0bd@vger.nsu.edu> manes@vger.nsu.edu writes: > I support Dan Silva's position on this. Hmmm. What's Dan Silva's position on ARP? Last I heard he wasn't even doing Amiga stuff any more. Oh, you mean "Peter da Silva"... (I really do get a lot of this... sigh...) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
wemmp@cutmcvax.cs.curtin.edu.au (Peter Wemm) (11/22/90)
OK, That was the last straw!!!!! This argument has gone on long enough!! Into the kill file it goes! For what it is worth, If you like arp, use it! If you dont, then simple: dont! Dont try and force your ideas on others! I quite liked ARP and used it continuously since I first got it. Personally I am quite pleased that most of ARP (extended commands, filerequester etc) has gone into 2.0. All that "non-standard" stuff is becoming standard! -- Peter Wemm ------------------------------------------------------------------------------ wemmp@cutmcvax.oz.au (wemmp@cutmcvax.oz or ..!munnari!cutmcvax.oz.au!wemmp) "To understand Recursion, you need to understand Recursion." - I forgot who..
manes@vger.nsu.edu (11/27/90)
In article <2254@lpami.wimsey.bc.ca>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > In <253.2747d0bd@vger.nsu.edu>, manes@vger.nsu.edu writes: >>In article <90318.162021DXB132@psuvm.psu.edu>, DXB132@psuvm.psu.edu writes: >>I have absolutely hated ARP since its very beginning. The name >>'AmigaDOS Replacement Project' says it all. It says to me anyway, >>that Commodore does not know what it is doing and look with ARP >>we can do it "right". > > Yup... says it all. That CBM adopted much of ARP's philosophy says a lot too. > CBM knew all along that the BCPL stuff adopted at the last minute was ill > fitting with the rest of the machine, that it presented anomaly's that were > unacceptable and would have to eventually be eliminated. I agree that it needed replacement, but by Commodore not the masses. > >>Well history has proven that ARP has produced more strange problems, >>incompatibilities and other oddities than it ever solved. It also >>proves that the masses can't do a better job. > > Oh? I had problems with exactly 3 of the ARP commands, and no more. I wish I > could have said the same for the supplied Amigados commands. Remember, we are > talking about history here, and not the supplied commands as we now know them, > highly influenced by many third party ideas, ARP included. Have you ever tried to run a installation script on a piece of commercial software that thought it had the ARP command set? Have you ever had a commercial package attempt to replace all of your Commodore supplied commands with ARP versions? My problem with ARP is simple. It did not come from Commodore. It had little or no support, and in my opinion was not as useful as some of the 'shells' that have been in the PD for the longest time. > >>It is hard enough for most to learn AmigaDOS, adding a command set that >>doesn't work particularly well does nothing but add a support headache >>for Commodore and their dealers, and makes the outsiders believe that >>AmigaDOS needed replacement. > > I would agree, though I fail to see where the ARP command set "doesn't work > particularly well". As of the inception of ARP, the Amigados command set did > not work particularly well, or consistently. It _did_ need replacement. The > interfaces to the Amigados functions _did_ need revamping. That CBM apparently > agrees is ample proof that ARP was, if not the total answer, at least a > demonstration that the concepts were valid. See above. Who should change it? Commodore. > >>I support Dan Silva's position on this. Eeek, did I type that... Sorry Peter! :-) > > -larry > > -- > The only things to survive a nuclear war will be cockroaches and IBM PCs. > +-----------------------------------------------------------------------+ > | // Larry Phillips | > | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | > | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | > +-----------------------------------------------------------------------+ -mark= +--------+ ================================================== | \/ | Mark D. Manes "Mr. AmigaVision" | /\ \/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ==================================================
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/28/90)
In <305.27511607@vger.nsu.edu>, manes@vger.nsu.edu writes: >In article <2254@lpami.wimsey.bc.ca>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >> In <253.2747d0bd@vger.nsu.edu>, manes@vger.nsu.edu writes: >>>In article <90318.162021DXB132@psuvm.psu.edu>, DXB132@psuvm.psu.edu writes: [ Some discussion of ARP vs. CBM-supplied commands. >I agree that it needed replacement, but by Commodore not the masses. Aside from the term 'masses', as applied to a small group of folks, I agree that CBM should have replaced many of the supplied commands. Unfortunately, CBM had other priorities. I am not one to second-guess their setting of priorities, but they obviously felt that getting the CLI commands in order was of less importance than the ARP group felt. The ARP bunch supplied what was obviously in demand, and did a pretty good job of it. It isn't as if you were forced into using ARP. Even if you used some parts of it, you could still leave out any part you didn't like or that you had problems with. >>>Well history has proven that ARP has produced more strange problems, >>>incompatibilities and other oddities than it ever solved. It also >>>proves that the masses can't do a better job. >> >> Oh? I had problems with exactly 3 of the ARP commands, and no more. I wish I >> could have said the same for the supplied Amigados commands. Remember, we are >> talking about history here, and not the supplied commands as we now know them, >> highly influenced by many third party ideas, ARP included. > >Have you ever tried to run a installation script on a piece of commercial >software that thought it had the ARP command set? Have you ever had a >commercial package attempt to replace all of your Commodore supplied commands >with ARP versions? No I haven't. If you have, all I can say is that you have a lot more faith than I have in the infallibility of those who assume anything at all about your machine and write scripts to mess with the setup. I do not run scripts without first checking them out very carefully, making changes as necessary, or simply seeing what they do and doing it manually. Running a script without doing so leaves you in a poor position to blame ARP for any woes that you may incur. >My problem with ARP is simple. It did not come from Commodore. It had >little or no support, and in my opinion was not as useful as some of the >'shells' that have been in the PD for the longest time. ARP had as much support as any third party piece of software, which at times has been as much support as you could expect for the CBM supplied commands. At the time of the first appearance of ARP, what shells were in use? Matt Dillon's comes to mind, and of course the noermal CBM supplied CLI, but neither of these addressed the problems beyond any built-in commands in Matt's shell. >> >>>It is hard enough for most to learn AmigaDOS, adding a command set that >>>doesn't work particularly well does nothing but add a support headache >>>for Commodore and their dealers, and makes the outsiders believe that >>>AmigaDOS needed replacement. >> >> I would agree, though I fail to see where the ARP command set "doesn't work >> particularly well". As of the inception of ARP, the Amigados command set did >> not work particularly well, or consistently. It _did_ need replacement. The >> interfaces to the Amigados functions _did_ need revamping. That CBM apparently >> agrees is ample proof that ARP was, if not the total answer, at least a >> demonstration that the concepts were valid. > >See above. Who should change it? Commodore. And as I say, I agree. Since they did not, ARP was born, and served its purpose, which was at least twofold. One, it supplied the functionality and consistency the users wanted, and two, it showed CBM some good ideas that they later adopted. Saying that only CBM should ever write programs for the Amiga is nonsense (I know you agree with this sentiment), but where do you draw the line. Should we all be stuck with Ed and Emacs just because CBM supplied them in the earliest releases? Should we use Edit instead of See or Sed? Should I always use List or Dir instead of ls? (I use all three, for different reasons). Early on, I wrote a small Echo replacement. I wrote it for two reasons. The first reason was that there was no documentation on the BCPL conventions of supplying ESC sequences to a command, and I wanted to be able to make use of colour, typestyles, and so on. The second reason was that I wanted something to write using assembler. The result was quite functional, and a lot of folks used it for a long time. The users who used it certainly felt that it was worth having (especially at the price, completely free). Was I wrong to write it? I think not. Funny, I didn't hear a lot of people flaming me for writing it either, or flaming the program because CBM didn't supply it. Perhaps it's just because you weren't using Amigas then or didn't see my little program. Sounds to me like you should be flaming those who write scripts that make assumptions, rather than those who make damned fine attempts to help the Amiga community. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
dillon@overload.Berkeley.CA.US (Matthew Dillon) (11/28/90)
In article <1990Nov20.154005.18828@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes: >In article <7056@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: >>> Oh, give me a break!!! ARP was a not-for-profit (ad)venture by a group of >>> very talented and enthusiastic programmers, and they did a damn fine job, a >>> lot better than those cheesy BCPL crap-garbage-explitive commands!!! >>Well, I beg to differ. I'm sure they're great guys and all but they spent a >>lot of energy solving a problem that didn't exist. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I beg to differ. I used switched to ARP when I didn't have enough >space on the old WorkBench disk. I had already moved the fonts to a >separate disk, and with the miscellaneous .library files on WB there >was no more room for anything else. After installing ARP, I had room >to add one additional item (namely, MSH), which I could not have done >otherwise. I have had no problems with it for the things I use it for. I've found that, over the years, it is much more efficient to simply invest in a hard disk (or more hard disks :-)) or more memory when one begins to get crammed. Frankly, the time saved by having an HD pays for it very quickly. I've never used ARP .. simply because there are so many incompatibilities with it verses what 99% of amiga owners use (AmigaDOS/NewShell) that I CAN'T use it. Also, I would never even consider installing something with such great consequences to the system without full sources. I've probably saved myself a couple hundred hours of bug tracing and installation problems (of other software) by not touching ARP. P.S. I use arp.library as well, at least for non 2.0 stuff. P.S. Note diplomatic phrasing: I never said I didn't like ARP, just that I do not use it! -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
manes@vger.nsu.edu (11/30/90)
In article <2271@lpami.wimsey.bc.ca>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > In <305.27511607@vger.nsu.edu>, manes@vger.nsu.edu writes: >>In article <2254@lpami.wimsey.bc.ca>, lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>> In <253.2747d0bd@vger.nsu.edu>, manes@vger.nsu.edu writes: >>>>In article <90318.162021DXB132@psuvm.psu.edu>, DXB132@psuvm.psu.edu writes: > > [ Some discussion of ARP vs. CBM-supplied commands. > > > > No I haven't. If you have, all I can say is that you have a lot more faith than > I have in the infallibility of those who assume anything at all about your > machine and write scripts to mess with the setup. I do not run scripts without > first checking them out very carefully, making changes as necessary, or simply > seeing what they do and doing it manually. Running a script without doing so > leaves you in a poor position to blame ARP for any woes that you may incur. It was this very thing that caused me to start looking at every installation script. It was a education. :-) Larry, how about all those folks who *dont* know what ARP is, and what the potential problems they may endure? What about the people who bought the Amiga to use it, and who have not invested the time to 'learn' the CLI commands and their potential effects? I dare say that most Amiga users don't understand many concepts that you (and I) take for granted. > >>My problem with ARP is simple. It did not come from Commodore. It had >>little or no support, and in my opinion was not as useful as some of the >>'shells' that have been in the PD for the longest time. > > ARP had as much support as any third party piece of software, which at times > has been as much support as you could expect for the CBM supplied commands. At > the time of the first appearance of ARP, what shells were in use? Matt Dillon's > comes to mind, and of course the noermal CBM supplied CLI, but neither of these > addressed the problems beyond any built-in commands in Matt's shell. > Larry, you lost me there. Was there a company that I could call and get questions answered about it? When ARP first came out, if memory serves, it was for AmigaDOS 1.2. Commodore's concentration at that time was working on a standard for booting hard disks, this certainly is much more important than the oddities of the BCPL based CLI commands. >>> >>>>It is hard enough for most to learn AmigaDOS, adding a command set that >>>>doesn't work particularly well does nothing but add a support headache >>>>for Commodore and their dealers, and makes the outsiders believe that >>>>AmigaDOS needed replacement. >>> >>> I would agree, though I fail to see where the ARP command set "doesn't work >>> particularly well". As of the inception of ARP, the Amigados command set did >>> not work particularly well, or consistently. It _did_ need replacement. The >>> interfaces to the Amigados functions _did_ need revamping. That CBM apparently >>> agrees is ample proof that ARP was, if not the total answer, at least a >>> demonstration that the concepts were valid. >> >>See above. Who should change it? Commodore. > > And as I say, I agree. Since they did not, ARP was born, and served its > purpose, which was at least twofold. One, it supplied the functionality and > consistency the users wanted, and two, it showed CBM some good ideas that they > later adopted. Saying that only CBM should ever write programs for the Amiga is > nonsense (I know you agree with this sentiment), but where do you draw the > line. Should we all be stuck with Ed and Emacs just because CBM supplied them > in the earliest releases? Should we use Edit instead of See or Sed? Should I > always use List or Dir instead of ls? (I use all three, for different reasons). My concern is that 'replacement' commands not supplied from Commodore may not always be 100% compatible, and introduce a "unreliability belief" in the work that Commodore has done. If Commodore's work was ok, then why would someone want to replace it? Ah, it must be buggy. You and I know different, but will the rest of the world? I certainly grant that for the knowledgable user, ARP gives many wonderful things. Certainly the most important is the freedom of choice. I suppose if all users were knowledgable I would not have a beef with ARP. Unfortunately as you and I both know, there is a steep learning curve in using the Amiga and having programs that rely on ARP only makes it more difficult. Perhaps if the ARP commands came with different names so that the Commodore supplied set was not replaced there would not be a problem, as the 'experienced' user could delete the Commodore one with the knowledge of what he/she is doing. Further, if it was easy to identify the difference (without comparing byte sizes) between the ARP command set and the Commodore set then the problem would be less. I am looking at this with two views. The first view, as a person who uses the machine and understands the circumstances of using PD software, and the second view of a person who has to answer the phone at a Amiga dealership. > > Early on, I wrote a small Echo replacement. I wrote it for two reasons. The > first reason was that there was no documentation on the BCPL conventions of > supplying ESC sequences to a command, and I wanted to be able to make use of > colour, typestyles, and so on. The second reason was that I wanted something > to write using assembler. The result was quite functional, and a lot of folks > used it for a long time. The users who used it certainly felt that it was > worth having (especially at the price, completely free). Was I wrong to write > it? I think not. Funny, I didn't hear a lot of people flaming me for writing > it either, or flaming the program because CBM didn't supply it. Perhaps it's > just because you weren't using Amigas then or didn't see my little program. I am certain that ECHO is on the less than dangerous side of things, don't you think? MOUNT on the other hand, if you wrote a replacement for it, and called it MOUNT I would flame you. There is a difference. > > Sounds to me like you should be flaming those who write scripts that make > assumptions, rather than those who make damned fine attempts to help the Amiga > community. Certainly agree there, and I have. :-) Help is a relative term. The only people who prospered from ARP where those who understood what it was, and why it was. It did not HELP those who did not realize (perhaps care?) about the problems with the Commodore supplied commands. I am not knocking the idea of ARP, but I am knocking the implementation and the original arrogance of the individuals who were involved with the AmigaDOS Replacement Project (the original name). > > -larry > > -- > The only things to survive a nuclear war will be cockroaches and IBM PCs. > +-----------------------------------------------------------------------+ > | // Larry Phillips | > | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | > | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | > +-----------------------------------------------------------------------+ -mark= +--------+ ================================================== | \/ | Mark D. Manes "Mr. AmigaVision" | /\ \/ | manes@vger.nsu.edu | / | (804) 683-2532 "Make up your own mind! - AMIGA" +--------+ ==================================================
dillon@overload.Berkeley.CA.US (Matthew Dillon) (12/02/90)
My opinion is simple.
ARP is a boon to the people who use and like it.
On the other hand, ARP has caused more hair pulling in the history
of the Amiga... Its design goals are inherently destabilizing to the
entire Amiga community:
(1) ARP decided to name its replacement commands the same as the
C-A commands in C: (90% of hairpulling due to this)
(2) ARP did not make the commands completely compatible with the
original C: commands, causing otherwise perfectly valid script
files to fail on arp-installed systems.
(3) Many ARP developers and programmer-users wrote programs that
depended on ARP extensions, calling C: programs or Execute() with
the assumption that they were the ARP executables or certain
patches were installed. Total havoc is reeked on the non-arp users
that make up the majority of amiga owners.
Worse, some programs distributed some of the 'replacement'
executables just so they would work, requiring non-ARP users to
partially install ARP on their systems to use the programs.
(4) ARP never caught up with Commodore enhancements (1.3.2 or 2.0),
and never will. The compatibility problem gets worse because of
this.
As far as I am concerned, the only really great thing about ARP is
ARP.LIBRARY .... not because it's a good library (which it is pretty
much), but because it doesn't screw around with existing system
commands or libraries. You can install it without turning your
system into a garbage pile.
-Matt
--
Matthew Dillon dillon@Overload.Berkeley.CA.US
891 Regal Rd. uunet.uu.net!overload!dillon
Berkeley, Ca. 94708
USAlphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/03/90)
In <321.27552470@vger.nsu.edu>, manes@vger.nsu.edu writes: > >It was this very thing that caused me to start looking at every installation >script. It was a education. :-) This is an education I received long before ARP came along. I would set up my system to do what I wanted it to do, and some script would cause me hours of problems after trashing my setup. >Larry, how about all those folks who *dont* know what ARP is, and what >the potential problems they may endure? What about the people who bought >the Amiga to use it, and who have not invested the time to 'learn' the >CLI commands and their potential effects? I dare say that most Amiga >users don't understand many concepts that you (and I) take for granted. While this is true, I would hasten to point out that ARP was not alone in this. Many programs, PD and commercial, caused problems, either through sloppy programming, or through a misplaced 'This is the only way we allow you to do it' attitude. As a final point, I refer you to DiskDoctor, which was supplied by CBM, and has been mistaken for a virus since it became available, and as recently as last week, on this very network. >Larry, you lost me there. Was there a company that I could call and get >questions answered about it? No, there was a group of people you could call about it, or who could be asked questions via various networks, this one included. Calling the CBM customer support line has not been cnsistently productive for most; being referred to a local dealer is not always helpful, if that dealer knows less than you do about the machine. If you include documentation as 'support', you might consider that ARP came fully documented, while the Amigados commands were documented in a third party book. I wish I could count the number of people who _learned_ how to use the CLI because of the ARP documentation. >When ARP first came out, if memory serves, it was for AmigaDOS 1.2. >Commodore's concentration at that time was working on a standard for >booting hard disks, this certainly is much more important than the >oddities of the BCPL based CLI commands. Do you really think so? I never had much of a problem with booting from floppy. My startup-sequence at that time consisted of about three commands or so, and time spent reading from floppy was minimal. Now if you want to talk about hard disk standardization, and making them work properly, I would agree that it was of more importance than purging BCPLisms, though I would point out that this goal was only one of the stated goals of ARP. Consistency was another, and the ARP commands were more consistent. Size was another, and they succeeded there. Providing things like argument parsing and file requesters, resource tracking, and so on... all these goals were met. Again, nobody was forced to use the entire distibution. >My concern is that 'replacement' commands not supplied from Commodore may >not always be 100% compatible, and introduce a "unreliability belief" in >the work that Commodore has done. If Commodore's work was ok, then why >would someone want to replace it? Ah, it must be buggy. You and I >know different, but will the rest of the world? Comodore provided ample reason for folks to feel that the Amiga (including the CLI commands) was unreliable. As you know, CBM's work passed through the entire range of reliability and functinality from 'totally buggy' and 'nearly unusable' to where it is today. Part of that increased functionality we see from CBM today, if not the increased reliability, is due to CBM adopting ideas and/or programs put out by non-CBM people, including the ARP folks. >I certainly grant that for the knowledgable user, ARP gives many wonderful >things. Certainly the most important is the freedom of choice. I suppose >if all users were knowledgable I would not have a beef with ARP. If all users were knowledgeable, I would _still_ have a beef with DiskDoctor and Join, to name just two CBM-supplied programs, and with a great variety of commercial offerings. Owning a computer is like owning anything else. A certain rudimentary knowledge is required, as well as the knowledge of your own limitations, if you are to run anything but single commercial programs, one at a time. >Unfortunately as you and I both know, there is a steep learning curve in >using the Amiga and having programs that rely on ARP only makes >it more difficult. Perhaps if the ARP commands came with different names >so that the Commodore supplied set was not replaced there would not be >a problem, as the 'experienced' user could delete the Commodore one with >the knowledge of what he/she is doing. Further, if it was easy to >identify the difference (without comparing byte sizes) between the ARP >command set and the Commodore set then the problem would be less. It is relatively easy to identify the ARP commands, and the way to do it is documented. type the command name with a question mark, and it shows a template, as do the CBM commands. Typa another question mrk, and a different, usually more detailed explanation of the command is given. Just part of the increased functionality of ARP commands. >I am certain that ECHO is on the less than dangerous side of things, don't >you think? MOUNT on the other hand, if you wrote a replacement for it, and >called it MOUNT I would flame you. There is a difference. Certainly it's less dangerous, but I did name it the same. What if I had written a MOUNT that corrected a problem inherent in the CBM MOUNT, and called it MOUNT? Would I still get a flame for it? If I called it something other than MOUNT, it would njust mean that a lot of folks would rename it to MOUNT, just as anyone is free to rename any ARP program to something else. Personally, after DIR, LIST, and LS, I have a problem with attempting to come up with another meaningful name, should I actually want to keep some of the others around. >Help is a relative term. The only people who prospered from ARP where those >who understood what it was, and why it was. It did not HELP those who did >not realize (perhaps care?) about the problems with the Commodore supplied >commands. Agreed. The only people who benefit from a word processor are those that require its functionality, and use it. >I am not knocking the idea of ARP, but I am knocking the implementation and >the original arrogance of the individuals who were involved with the >AmigaDOS Replacement Project (the original name). I didn't see the ARP authors as arrogant at all. I do see folks like MSS as arrogant; providing commercial releases that break the rules, that are buggy, and so on, who will, when asked if they are going to be fixing XModem in the next release, will answer with "Well, probably not, you are only the second person to request that enhancement.". The ARP authors saw a problem, and offered to help out. When that offer was declined, they struck out on their own to provide what they saw as relief to users and programmers alike. That they now receive flames for doing so is a surprise to me, since nobody is forcing anyone to all or any part of it. Anyway, I think this about beats my point of view to death. :-) -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
SteveX@omx.UUCP (Steve Tibbett) (12/16/90)
>In article <2312@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Certainly it's less dangerous, but I did name it the same. What if I had >written a MOUNT that corrected a problem inherent in the CBM MOUNT, and called >it MOUNT? Would I still get a flame for it? If I called it something other than >MOUNT, it would njust mean that a lot of folks would rename it to MOUNT, just >as anyone is free to rename any ARP program to something else. Personally, >after DIR, LIST, and LS, I have a problem with attempting to come up with >another meaningful name, should I actually want to keep some of the others >around. I'd flame you for it. Two reasons... 1: When I update my C: directory with a new set of C: commands, your mount would be a special case that I'd have to copy back on after every update (or I'd just have to call it something else) 2: There is no way of knowing that your MOUNT will have all the functionality of all future MOUNT's. If your mount is called LPMount or some other name, then I can use it specifically for the things I can't use the CBM mount for. If the user takes LPMount and calls it MOUNT, then he's asking for his own trouble, not being given it by you. -- ...Steve Tibbett...bix=s.tibbett...Plink=STEVEX...BBS=613-731-3419... ...VirusX=4.01...Insert Disclaimer Here...
glee@tigris.uucp (Godfrey Lee) (12/27/90)
In article <SteveX.3234@omx.UUCP> SteveX@omx.UUCP (Steve Tibbett) writes: >>In article <2312@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: [discussions on replacement commands, whether they should be same name or not] >>If I called it something other than >>MOUNT, it would njust mean that a lot of folks would rename it to MOUNT, > 1: When I update my C: directory with a new set of C: commands, > your mount would be a special case that I'd have to copy back > on after every update (or I'd just have to call it something else) Well, that is why people invented the PATH concept, if you are adventurous, you put the ARP commands ahead of C: (or make it C:), if you are not, put them after. If you are methodical, split ARP commands into two sets, the set that you have tested, put them in front of the regular commands, the set that you might not trust, put them after (or not at all). The trick is to arrange that any updates you need to do, either to the official set or the ARP set, you can do it without disrupting the other. > 2: There is no way of knowing that your MOUNT will have all the > functionality of all future MOUNT's. That is problematic regardless. If you get used to using the alternate command, then you not only have to notice that the official one changed and you should use it, you also have to re-train your fingers to type a different command. It is still easier, once you discover which one is better to use, you just switch them in the PATH (once). In general, if someone names a command the same as the official one, and you use it, you are in effect trusting that it will have the same functionality, and probably that it will get updated along with the official command. >If the user takes LPMount and calls it MOUNT, then he's asking for his >own trouble, not being given it by you. The converse of that is that if someone copies the alternate set over the official set, then he's asking for his own trouble. On balance, I definitely prefer that the replacement commands (same functionality, perhaps with extensions, definitely same syntax) be named the same as the official commands. Of course, all commands should be able to tell you who they are (version, author), so you can find out which one you are executing. -- Godfrey Lee cunews!tigris!glee or glee@tigris.ocunix.on.ca
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/31/90)
In <SteveX.3234@omx.UUCP>, SteveX@omx.UUCP (Steve Tibbett) writes: >>In article <2312@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>Certainly it's less dangerous, but I did name it the same. What if I had >>written a MOUNT that corrected a problem inherent in the CBM MOUNT, and called >>it MOUNT? Would I still get a flame for it? If I called it something other than >>MOUNT, it would njust mean that a lot of folks would rename it to MOUNT, just >>as anyone is free to rename any ARP program to something else. Personally, >>after DIR, LIST, and LS, I have a problem with attempting to come up with >>another meaningful name, should I actually want to keep some of the others >>around. > >I'd flame you for it. > >Two reasons... > > 1: When I update my C: directory with a new set of C: commands, > your mount would be a special case that I'd have to copy back > on after every update (or I'd just have to call it something else) I see this as an operational limitation imposed upon you, by yourself. This is one of the reasons for the 'PATH' command. Why remember two names for something, when one will do? When you need the 'other one', just prefix it with 'c:'. > 2: There is no way of knowing that your MOUNT will have all the > functionality of all future MOUNT's. If your mount is called > LPMount or some other name, then I can use it specifically for > the things I can't use the CBM mount for. Or the other way around. In either case, you are imposing limitations on yourself with your seeming reluctance to use the system's capabilities, specifically, 'rename' and 'path', in this case. >If the user takes LPMount and calls it MOUNT, then he's asking for his >own trouble, not being given it by you. Well, nobody is forcing anyone to actually replace any command with any other command, to place it in any particular place, or to call it any particular thing. To each his own. You may as well flame me for my early 'echo' command, though those that used it thanked me for it. -larry -- The best way to accelerate an MsDos machine is at 32 ft/sec/sec. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (01/02/91)
I've had people mucking around with my system screw me over with that before. You know, someone comes over and wants to run HAMGIF or whatever and starts mucking about with C:. Last time they managed to remove setpatch, then claim it was all due to a bug in 2.0 that setpatch disappeared. Right, and the same bug made nushow and hamgif materialise in C:? NEVER stick anything in C: that's not part of the distribution. It's just asking for trouble. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/02/91)
In <7434@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >I've had people mucking around with my system screw me over with that >before. You know, someone comes over and wants to run HAMGIF or whatever >and starts mucking about with C:. Last time they managed to remove >setpatch, then claim it was all due to a bug in 2.0 that setpatch >disappeared. Right, and the same bug made nushow and hamgif materialise >in C:? > >NEVER stick anything in C: that's not part of the distribution. It's just >asking for trouble. Directory "c:" on Wednesday 02-Jan-91 [ much deleted ] 508 files - 4 directories - 19696 blocks - 9625879 bytes I NEVER let anyone mess with my C: directory. Not even by remote control, via scripts. :-) -larry -- The best way to accelerate an MsDos machine is at 32 ft/sec/sec. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
scot@amigash.UUCP (Scot L. Harris) (01/03/91)
>In article <SteveX.3234@omx.UUCP> SteveX@omx.UUCP (Steve Tibbett) writes: > > 1: When I update my C: directory with a new set of C: commands, > your mount would be a special case that I'd have to copy back > on after every update (or I'd just have to call it something else) > > >If the user takes LPMount and calls it MOUNT, then he's asking for his >own trouble, not being given it by you. > >-- > ...Steve Tibbett...bix=s.tibbett...Plink=STEVEX...BBS=613-731-3419... > ...VirusX=4.01...Insert Disclaimer Here... Some good points. However why not create a C2 directory and make an assign for C2: where you put all the NON-CBM commands. This way your C: directory is pure CBM. Just put the C2: directory in your path and the new commands are available. If they don't work then get rid of the bad commands or pull the C2: directory from your path. This way updates from CBM are trivial. -- _ /// /_\ Scot L. Harris ...!tarpit!bilver!amigash!scot \XX/ / \ M I G A Orlando, FL (407)273-1759 [Falcon Mission Disk II. Must be great, haven't gotten any work done for days]
peter@sugar.hackercorp.com (Peter da Silva) (01/03/91)
In article <2450@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > >NEVER stick anything in C: that's not part of the distribution. It's just > >asking for trouble. [Larry lists his C:] > 508 files - 4 directories - 19696 blocks - 9625879 bytes OK, why? What's wrong with path:? > I NEVER let anyone mess with my C: directory. Not even by remote control, > via scripts. :-) You obviously don't have people coming over while you're at work, when your wife doesn't now enough about the machine to keep an eye on them. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
nfs1675@dsacg3.dsac.dla.mil ( Michael S Figg) (01/04/91)
In article <7434@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: > I've had people mucking around with my system screw me over with that > before. You know, someone comes over and wants to run HAMGIF or whatever > and starts mucking about with C:. Last time they managed to remove > setpatch, then claim it was all due to a bug in 2.0 that setpatch > disappeared. Right, and the same bug made nushow and hamgif materialise > in C:? > > NEVER stick anything in C: that's not part of the distribution. It's just > asking for trouble. > -- > Peter da Silva. `-_-' That sounds like a real good idea to me, but, are there any reports or knowledge of (poorly written) programs that look for something other than genuine AmigaDos release stuff in C:? I've probably put more than is healthy in my C: and should clean it out. ----- --Mike -- -------- o A herd of bagels | Michael Figg DSAC-FSD | | -- oo o o escaping from a deli. | DLA Systems Automation Center | | -- ooo oo Looking for Lox in | Cols, Ohio mfigg@dsac.dla.mil -------- o o all the wrong places | CIS: 73777,360
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/04/91)
In <7448@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <2450@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >> >NEVER stick anything in C: that's not part of the distribution. It's just >> >asking for trouble. > >[Larry lists his C:] >> 508 files - 4 directories - 19696 blocks - 9625879 bytes > >OK, why? What's wrong with path:? Path is braindead. One day I will write an ARexx front-end for it so that I can delete one entry in the path, or insert an entry, without having to muck about doing things to it manually. I only use PATH under a few circumstances, and then I like to reset it and forget about it. >> I NEVER let anyone mess with my C: directory. Not even by remote control, >> via scripts. :-) > >You obviously don't have people coming over while you're at work, when your >wife doesn't now enough about the machine to keep an eye on them. Right. I am pretty much the sole user of my machines. My wife plays the occasional game, or writes a few letters, but for the most part, it's under my direct control. -larry -- The best way to accelerate an MsDos machine is at 32 ft/sec/sec. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/04/91)
In <2845@dsacg3.dsac.dla.mil>, nfs1675@dsacg3.dsac.dla.mil ( Michael S Figg) writes: >In article <7434@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: >> I've had people mucking around with my system screw me over with that >> before. You know, someone comes over and wants to run HAMGIF or whatever >> and starts mucking about with C:. Last time they managed to remove >> setpatch, then claim it was all due to a bug in 2.0 that setpatch >> disappeared. Right, and the same bug made nushow and hamgif materialise >> in C:? >> >> NEVER stick anything in C: that's not part of the distribution. It's just >> asking for trouble. >> -- >> Peter da Silva. `-_-' > > >That sounds like a real good idea to me, but, are there any reports or >knowledge of (poorly written) programs that look for something other than >genuine AmigaDos release stuff in C:? I've probably put more than is >healthy in my C: and should clean it out. Aterm looks for something in C:, but it is not mandatory that it be there. It looks for AtermClock in current dir first, then in C: if it is not found in current dir. At the time, there were few choices that were acceptable. No environment variables, and really, no other place that made sense for executables, without arbitrarily forcing the user to create a special directory. Since I consider a terminal program a command, and not an application, C: was the logical choice for me. Others felt better about running it from the current directory, and placed Aterm in it's own directory. If I were to do it again, now, I would allow putting it anywhere, and specifyiing the place with an environment variable. I very much enjoy the freedom to do things my own way, and do not begrudge anyone else the same freedom, no matter how strange it seems to me. -larry -- The best way to accelerate an MsDos machine is at 32 ft/sec/sec. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <2467@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > Path is braindead. Expand on this. I don't have any problems with it. > One day I will write an ARexx front-end for it so that I can > delete one entry in the path, or insert an entry, without having to muck about > doing things to it manually. PATH directory REMOVE PATH directory ADD How automatic would you like to get? Here's my PATH: 1.SYS> PATH Current directory Ram Disk: System2.0:C System2.0:Utilities System2.0:Rexxc System2.0:System System2.0:S System2.0:Prefs System2.0:Wbstartup System2.0:Tools Work:c Work:System Work:uucp/c Work:Aztec/Bin C: Do you really have ALL that junk in C:? Sigh... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dfrancis@tronsbox.xei.com (Dennis Heffernan) (01/06/91)
In article <7460@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <2467@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >> Path is braindead. > >Expand on this. I don't have any problems with it. > >> One day I will write an ARexx front-end for it so that I can >> delete one entry in the path, or insert an entry, without having to muck about >> doing things to it manually. > >PATH directory REMOVE >PATH directory ADD > >How automatic would you like to get? > >Peter da Silva. `-_-' Using PATH ADD will add a directory to the end of your path- what if you want to change something in the MIDDLE? You have to reset the whole darn thing. As far as ARP goes, the Commode (sic) commands were out of my C directory within hours of my machine's setup. Never had a problem with them. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "I don't understand why you make such a big deal out of everything...haven't you learned; if it's not happenning to me it's not important?" -Murphy Brown
peter@sugar.hackercorp.com (Peter da Silva) (01/07/91)
In article <418@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > Using PATH ADD will add a directory to the end of your path- what if > you want to change something in the MIDDLE? You have to reset the whole darn > thing. I think this goes in the category of "getting too cute with your setup". I've got a pretty hairy PATH and I've never even considered that it might be nice to have that capability. What would you need to do that for (real life examples, please, not hypotheticals...)? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (01/07/91)
In article <7460@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >PATH directory REMOVE >PATH directory ADD >How automatic would you like to get? In another message, Peter requested a "real life" example where these commands are not sufficient. Here's one that I have encountered several times. There is no convenient way to add a directory the end of your search path. You have to RESET and ADD everything back. On UNIX it's simple: $ PATH=$PATH:newdirectory Maybe we'll never see "PATH directory INSERT", but I'd sure like to have "PATH directory APPEND". Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
dfrancis@tronsbox.xei.com (Dennis Heffernan) (01/07/91)
In article <7471@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <418@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >> Using PATH ADD will add a directory to the end of your path- what if >> you want to change something in the MIDDLE? You have to reset the whole darn >> thing. > >I think this goes in the category of "getting too cute with your setup". I've >got a pretty hairy PATH and I've never even considered that it might be nice >to have that capability. What would you need to do that for (real life examples, >please, not hypotheticals...)? I've done it in the past, though always due to weird situations that have only cropped up from having to meddle around with floppies. I'd probably do it more often if it wasn't such a pain to accomplish. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "Using C will definitely cut your life expectancy by 10 years or more." -- Carl Sassenrath, GURU'S GUIDE TO THE COMMODORE AMIGA
sdesmara@sobeco.com (s.desmarais) (01/08/91)
In <7471@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <418@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: >> Using PATH ADD will add a directory to the end of your path- what if >> you want to change something in the MIDDLE? You have to reset the whole darn >> thing. Well, not even Unix allows that, short of using tools like 'sed' and such. At least, however, it allows adding to either the end or the front of the PATH. >I think this goes in the category of "getting too cute with your setup". I've >got a pretty hairy PATH and I've never even considered that it might be nice >to have that capability. What would you need to do that for (real life examples, >please, not hypotheticals...)? >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. One such example is when you have some commands with the same name has the Commodore supplied one, and want your own before in the PATH. However, it's true that you usually do that in the startup-sequence. It would be nice to be able to add either to the end or front (I know, I'm repeating myself). sdesmara@sobeco.com -- Stephane M. Desmarais sdesmara@sobeco.com Division STS - Groupe Sobeco Inc. {uunet | mcgill-vision}!sobeco.com!sdesmara 505 boul Rene-Levesque Ouest bur: (514) 878-9090 poste 297 Montreal, Quebec fax: (514) 875-2673
eachus@linus.mitre.org (Robert I. Eachus) (01/09/91)
Sheer self protection everyone: part of my startup-sequence
at work and at home (where ALL I have to worry about is my kids) is to
assign C: to RAM: and set my search path to include the (protected) C
directory on my hard disk. I also have aliases for cd, makedir,
protect, and delete with the originals squirreled off so that scripts
and such which use these commands either get the bowdlerized versions
or don't work. (I have to include cd, which is a pain, so that plain
"cd :C" or some such nasty doesn't get around the other safeguards.
But better safe than sorry.) For obvious reasons, I'm not going to
include my workarounds in this newsgroup, but they have allowed me to
survive "Click here to Install" toys without having to read them.
--
Robert I. Eachus
When the dictators are ready to make war upon us, they will not
wait for an act of war on our part." - Franklin D. Rooseveltjms@tardis.Tymnet.COM (Joe Smith) (01/11/91)
In article <7434@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >I've had people mucking around with my system screw me over with that before. Me too. When I executed the harddisk-install program for FontWorks, it wiped out a perfectly good version of arp.library with an obsolete version, and overwrote C:copy WITHOUT MY PERMISSION. >NEVER stick anything in C: that's not part of the distribution. It's just >asking for trouble. >Peter da Silva. `-_-' I agree. The bogus version of "copy" did not understand "copy clone a b" which caused various scripts in S: to fail mysteriously. In this case, overwriting a CBM-provided command in C: caused damage to my system. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
davids@ucscf.UCSC.EDU (Dave Schreiber) (01/12/91)
In article <1409@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >In article <7434@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>I've had people mucking around with my system screw me over with that before. >Me too. When I executed the harddisk-install program for FontWorks, it >wiped out a perfectly good version of arp.library with an obsolete version, >and overwrote C:copy WITHOUT MY PERMISSION. Do you keep your boot partition LOCKed? I lock both my boot partition and my executables partition to prevent exactly this sort of thing. While it's not foolproof (the 1.3 preferences program can write to a locked partition :-), it's better than nothing. >Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com [I've set the Followup-To: line to c.s.a.applications; this seems to be the appropriate group] -- Dave Schreiber davids@slugmail.ucsc.edu or (but not both) davids@ucscb.ucsc.edu "It was fun learning about logic, but I don't see where or when I will ever use it again."
ovb10@cs.kun.nl (Patrick Atoon) (01/15/91)
I haven't read the articles in this thread, so I don't know if this has
already been mentioned, but this is what is wrong with ARP:
Picture this s: directory....
Startup-Sequence
SPAT
...
...
Now use the Arp-copy command in this way:
copy s:s(t#?|p#?)
This will copy both Startup-Sequence and SPAT. Now use it this way:
copy s:s(t*|p*) ; Notice that the #? has been replaced by a *
This will only copy SPAT.
What is this?!?! Is "#?" not equal to "*"? Why? And I thought ARP was great
(well, actually I still think it's great, you just shouldn't use "*" in con-
junction with "|").
Just wanted to point the attention to this (little) error. See you,
Patrick
+-----------------------------------------------------+
| Patrick Atoon | "READY. |
| University of Nijmegen | ?OUT OF DATA ERROR." |
| E-mail: ovb10@cs.kun.nl | C=64 |
+-------------------------+---------------------------+ggk@tirith.UUCP (Gregory Kritsch) (11/16/20)
cedman@golem.ps.uci.edu (Carl Edman) writes: >In article <90318.162021DXB132@psuvm.psu.edu> DXB132@psuvm.psu.edu writes: > a) use C and the fastest C-compilers on the market > b) are aware that they are sacrifying the quality of the programm > and the convinience of the user against their laziness and > development time. >And now using assembler is a "big no-no" ? What is the world coming to ? Assembly language has some advantages and disadvatages. As time progresses, compilers are getting better and more standard, and assembler is becoming more complex. What may have been the case a while ago is no longer the case. One reason I like C over assembler is portability. For example, if I get really sick of the mail program on Watstar (ie I ever have to use it again...), I can probably take a copy of dmail sources which I use, and compile it pretty much straight up. Thing is, those machines are IBMs, running MS-DOS, with 8086 to 80386 processors. dmail is for Amiga, 8000 to 68030. My assembler files are going to be ENTIRELY rewritten, whereas my .c files are going to need only minor modifications (I imagine the calls to Execute() will have to be replaced by calls to system(), but thats only about 4 places). >I remember a time when people (e.g. me) wrote full-screen editors >in hex, because they didn't have an assembler and nowadays people write >cr/lf-filters in smalltalk with 200 kb runtime libraries and clocktools >under X-Windows with full debugging information (for the tool and >x-windows, just in case...) at 500 kbytes. So, whats your point? It probably took 2 minutes to do the cr-lf program, and 5 for the clock. And if they don't work, it'll take another 2 minutes to find out why not. In assembly, you're looking at a much longer development time, and if you don't include debug info, you looking at a much longer debug time as well. >Only slightly exagerating > Carl Edman -- Gregory Kritsch | University of Waterloo Fido: 1:221/208.11110 [1:163/109.30] | 1A Computer Engineering UUCP: ggk@tirith.UUCP |-------------------------- ...!watmath!xenitec!tirith!ggk | Amiga Fanatic