xanthian@well.UUCP (Kent Paul Dolan) (07/28/89)
I've heard "it's in there" about the 1.4 release. Here are my entries in
the great 1.4 wish list sweepstakes, in hopes that this is timely, and
finds some you missed.
Most important: make sure that the hard disk and other file system control
software is compatible with SCSI, removable medium, 1.5 Gbyte disks. These
drives should arrive before the 1.4 release. (Mfgr's name available to
CATS on request, if you haven't already had a demo of the existing
prototype.) In particular, limitations of "partition" sizes, numbers of
files/directories per directory node, maximum length of a path name, etc.,
should all be reviewed and improved in anticipation of truely fast, huge
(and extremely cheap; ~ $1/Mbyte drive cost) storage systems. In most
cases, hard limits should be replaced by soft limits; path name arrays ->
path name c-strings, directory name arrays -> directory name link lists,
und so weiter. I can hardly wait to put my 400 floppy disksfull of PD
software and data on one huge disk, and, at last, sort it out. [Naturally
the only practical backup for such a beast is another one just like it, so
I'll probably buy two!]
Merge list and dir commands ("ls" would be a catchy name for the result!)
and add the capabilities (as an "option") to create a directory listing
with full path names of files and also one with file path names from the
current/selected directory, compatible with the "all" option. This would
save half an hour per instance using an editor on "dir opt a" output to
prepare structured file name input for the "zoo aI" command, and similar
tasks. The existing list command's LFORMAT option could do this if list
had dir's "all" option and the path names of subordinate directories were
added to the first %S output.
Improve the list command LFORMAT option by using %P and %F for path and
file names instead of the current ambiguous (and therefore order dependent)
%S for both, and by allowing arbitrary numbers and orders of them in the
lformat string.
Smarten up the dir command to put the maximum possible number of columns of
file names, depending on the longest name in each column plus a bit of
spacing, rather than a fixed two columns. Even now, the workbench C: dir
overflows a screen in two column mode, so I use a PD routine called "ld"
for most directories, sacrificing alphabetized directories for four columns
of file names to have them all on one screen. This would work best if the
directory titles were full path names from the starting directory, so that
indentation to show depth could be avoided.
Automatic processing of the output of "dir opt a" output is made more
difficult because there is no directory line given before the files in the
current/requested directory are listed. Even '"" (dir)' would be a big
help.
Replace/supplement the existing "Pipe:" device with a real Unix(tm)-like
"|" pipe that can be used in a one line command.
Add a command to display/kill locks, to help clean things up when a disk
icon won't go away because some careless programmer left a lock engaged.
Add a capability to use extended selection for _any_ program, without
change to the object module, to make it think it is getting command line
input. I added a tool icon to my favorite microemacs (the one from
BENCHMARK Modula 2) and a project icon to files I was editing, but extended
selection won't convince the editor that it is seeing an argv[] character
string array containing a file name as argv[1]. It should be simple enough
to do this, and it would sure be nice to be able to do my work on "the
great American novel" in "point and shoot" mode, with long descriptive
project names tied to icons, rather than keeping a cli around and reverting
to short, quick to type file names.
While I'm on the subject, add paragraph flowing capability (preferably
including a fixed "indentation string" option, like GNUEmacs has) to the
Extras 1.3 MEmacs. That would make it almost usable for text processing
tasks on simple ASCII files, since it already works in extended selection
mode.
An otherwise empty, INSTALLed disk with :s/startup-sequence = "loadwb"
and :loadwb version 1.3 its only files fails to boot with a return code 20
from loadwb. The 1.3 docs for loadwb do not give any preconditions for its
successful operation, and none of the commands' docs give return code
interpretations. Both these problems need fixing. [I was trying to make
the Hack_Game: disk bootable, but it needed a workbench loaded to be
useful. No joy.]
Generically, your command documentation needs much more motivational
information added. When I read your docs, I know _how_ to use the commands,
but neither _why_, _when_, nor _where_.
Permit more than one RAD: (RAD0:, RAD1:, etc:) to be mounted, so that I can
copy several disks to memory, and give each the name its software is
expecting. Possibly this could be best accomplished by adding a "name" (or
"as") keyword to the MOUNT command: "Mount RAD0: as HACK_GAME:" or "Mount
RAD1: name HACK_GAME" are examples (note the colon for "as" but not for
"name").
Thanks for listening, as usual.
well!xanthian
Kent, the man from xanth, now just another echo from The Well.rap@peck.ardent.com (Rob Peck) (07/28/89)
In article <12878@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: > >Generically, your command documentation needs much more motivational >information added. When I read your docs, I know _how_ to use the commands, >but neither _why_, _when_, nor _where_. > I considered this same situation when I wrote the Amiga Companion. For those who are interested, it does address Kent's objections here... the chapters that are provided group commands by function type, allowing a new-ish user who has some idea what he wants to actually do a pretty good chance of finding the right command. And each option of each command is illustrated by explicit example, here's what you type, here's what you see, here's what it means, and here's WHY you are interested in knowing about it. (And at COMMODORE's request, I even explained the startup- sequence "in English".) The second edition of the Amiga Companion is now available from IDCG publications (an ad in the back of Amiga World since about a month ago) and is soon to be available at your local dealer. They ARE encouraging dealer orders now. (WHEW!) The price for the second edition remains the same as that of the first edition, even though the page count has increased by about 50. First edition purchasers should read the PREFACE for a low-cost update offer. Rob Peck
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/29/89)
I've come up with some changes I'd like made, also. This are all at the command level, and are motivated by having tools that want to be able to run commands (make, and treewalk head the list). 1) Get rid of the limits on the number of arguments for delete, join & others. I've heard that this is already in the works. Having the limits makes makefiles and treewalks break unexpectedly when they are exceeded. 2) Add an option to delete so that it won't quit when it encounters a file it can't delete. Not having this makes delete nearly useless for "make clean" type things. Under normal circumstances (i.e. - deleteing a tree), this is nice, as it stops & you can still see the name of the file that broke it. Either making the "don't stop" an option, making it print the names of all files it couldn't delete at the end, or adding it to the "quiet" flag preservers this behavior. 3) List should be included under "removing limits", so that I can get a list of more than one file at a time without invoking pattern matching. Dir would benefit less from this. That same rumor included a comment that all the commands were going to be rewritten in C. If so, I would suggest that all command interfaces be evaluated in light of automated invocation from makefiles & similar utilities. <mike -- Cheeseburger in paradise Mike Meyer Making the best of every virtue and vice mwm@berkeley.edu Worth every damn bit of sacrifice ucbvax!mwm To get a cheeseburger in paradise mwm@ucbjade.BITNET
erk@americ.UUCP (Erick Parsons) (07/29/89)
>From: xanthian@well.UUCP (Kent Paul Dolan) Message-ID: <12878@well.UUCP> > >Smarten up the dir command to put the maximum possible number of columns of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >file names, depending on the longest name in each column plus a bit of >spacing, rather than a fixed two columns. There is a PD (Shareware?) directory command called 'ls' that columnates directory listings in as many rows as can possibly be displayed on the screen (even more w/morerows). Twas posted about 2-3 months ago if my memory serves me right. Listings are sorted alphabetically w/ options to alter the sorting method. Options include: (invoked by typing ls -?) by Justin V. McCormick 1988 Usage: ls [-cdflnrstR] [path1] [path2] ... c > Show comments d > Dirs only f > Files only l > Long listing n > No sort r > Reverse sort s > Sort by size t > Sort by date R > Recursive listing Here it is for those who missed it... You'll need uudecode to extract. -------------------------------Cut here------------------------ begin 777 ls M #\P " $ 7X 8P ^D 7X)$@D $GY X M "QX 1(Y\#@F?P (#P 38(CP 0 !3J[_.DJ 9P ^"! )$ B0" \X M 8"#<4X!F^B <9PX@2='<U= @BB1)4X!@\"A)V?P 3-\' RQX 0IX M3@&@*4\!J$*L :0F;@$4< B/ , !.KO[.*6L F &<( ^0KP $!H " X M*4 !A&$ )@@:P"LT<C1R")H !#3R=/)( )R !(9*4D!L-"!4H!"9U* D#_X M_I_ 58!"=P ( )3@-2!'[( " 4X)1R/_V'[P (" 4X(?L2 ( !1RO_XX M(D\O"4ZZ%N1P & $("\ !"QX 0B; 343J[^8B \ $V"),D_P +'@ X M!$ZN_RX@'RYL :A.=4S?!P-.=7!D8,Q#^@ 0< !.KOW8*4 $U&?L3G5D;W,NX M;&EB<F%R>0!.5?_\2.<G,BX )DA*AV8&< !.NA5<+&P$U$ZN_\HI0 $3J[_X MQ"E B $ZN_RA*@&8$< !@ G !*4 %" \ !!"(\ $ 2QX 1.KO\ZX M*4 #$J 9@IP9T'Z MIA 5$? %P KZ ;0 _B!K 1P+; 09@ \E*&2AAFX M_%.(D>L !" (*@!3A4J%;P VB!K 31Q7 $!!R/%U!:P FK![$ AF]$[[X M$ 0 /V (0 4F '8 =& &@ <V %H <F $P ;F #X ;& # X M9F "( 9& !0 8V )P 2E "PI0 X8&X([ !]@9@CL $ 'V!>X M< $I0 L8%9P 2E #1@3G !*4 0&!&< $I0 !$8#YP BE $1@-G !*4 X M*& N80 ,=& H(&L !-'%< 0$"\ 2'H!]DAL O1.N@T^0>P"]&$ "^)A Q.X M3^\ #%.%8 #_)" 'D(9R ;"!;P8([ ! "M*K <9@9P RE !Q"K \O(=LX M%B &Y8!40^P"]$ZZ$RA@!%.%8)Y(; &T3KH/SEA/2H!GX M&' %0?H!$&$ UQ@#$'L ;1#[ )43KH2_! L ;5G-$'L ;0B2$H99OQ3B9/(X M<"]![ &S(@FP,!@ 9AA![ &T(DA*&6;\4XF3R$'L ;,@"4(P" !![ &T(@ATX M_BQL!-1.KO^L*4 "&8Z3J[_?"E "!![ &T0_H P$ZZ$H@@+ @0>P!M&$ X M MY@&)/)+'@ !$ZN_MHD0" J )@I0 (0BP!M" L A![ &T80 #'$JL AGX M$DJL #QG#"(L @L; 343J[_ID*L A2AKR'; A!^@!P80 *2KR'; A*K 0X M9P#^8G 0?H 7&$ GA,WTSD3EU.=4YO(%)!33\ 56YK;F]W;B!O<'1I;VX@X M)R5C)PH %-O<G)Y+"!C86XG="!P871T97)N(&UA=&-H('!A=&AS @;F]TX M(&9O=6YD * ;',Z("5S+"!%<G)O<B C)6QD"@!#86XG="!E>&%M:6YEX M(&9I;&4@;W(@9&ER96-T;W)Y"@ FS,P.S0Q;2 E<R";,&T* "5S"@ O " MX M+2!C86XG="!L;V-K(&ET(0H 5F]L=6UE(&]R(&1I<F5C=&]R>2!I<R!E;7!TX M>2X* !.;R!M871C:"X* ";)6QD0P";)6QD00";)6QD10";,&T FR!P )LPX M(' )LS,VT )LW;2 M+2!-3U)%("TM(%!R97-S(%)E='5R;CH@FS!M ";X M1IM+FS0[,S-M4&%G92 E;&0ZFS!M"@!$:7)S.B4M,VQD($9I;&5S.B4M-&QDX M($)L;V-K<SHE+35L9"!">71E<SHE+3AL9 H &-H<W!A<G=E9" " @($1IX M<F5C=&]R>2 @( @)31L9" E.&QD( ";,S-M+RH@)7,@*B^;,&T* O*B EX M<R J+PH FS!MFR!P*BI"4D5!2PH "!C(#X@4VAO=R!C;VUM96YT<PH (&0@X M/B!$:7)S(&]N;'D* "!F(#X@1FEL97,@;VYL>0H "!L(#X@3&]N9R!L:7-TX M:6YG"@ (&X@/B!.;R!S;W)T"@ @<B ^(%)E=F5R<V4@<V]R= H "!S(#X@X M4V]R="!B>2!S:7IE"@ ('0@/B!3;W)T(&)Y(&1A=&4* @4B ^(%)E8W5RX M<VEV92!L:7-T:6YG"@!(YP$2)D@N $JL AG$DJL #QG#"(L @L; 343J[_X MIDJL QG$B)L P@/ 00L> $3J[_+DJ'9QPO!R\+2'K]H$AL O1.N@B@X M0>P"]&$ !T1/[P 0( =.N@]N3-](@$YU3E7_Z$CG)S(N "9((@<D+ ,+&P$X MU$ZN_YI*@&882'K]<DAL O1.N@A>0>P"]&$ !P)@ &R2A-G/" L "A*@&\TX M2JP %&<4+PM(>OUH2&P"]$ZZ"#)/[P ,8!(O"TAZ_61(; +T3KH('D_O Q!X M[ +T80 &OB!L P@* !X2H!J$ @L $ 'V<(80 %4F 58@!V$ 5HD0" *X M9P !0DJL !!F $Z2JP -&8.("P 1"(L $ @2DZZ#$Y*K L9@@@2F$ EQ@X M!B!*80 $:@@L *V< 0@K2O_T(FW_]"!I @@* !X2H!O #:($M*&&;\X M4XB1RRQI @O2 <0>X ""Q(2AYF_%..G<@@+P <(@[0@2H 5(4@!7( +'@ X M!$ZN_SH@2TH89OQ3B)'+*T#_\"((9R@@0")+3KH."B!+2AAF_%.(D<MP.B((X ML#,8_V<,(&W_\$/Z_&Q.N@W:(FW_]"!I A-Z ((&W_\").3KH-Q"(M__!TX M_BQL!-1.KO^L+ !*AF82(&W_\&$ !:!!^OPT80 %F&!"0?K[VF$ !;0@!B!MX M__!A /Y2(@8L; 343J[_IB)M__ @!2QX 1.KO\N(&W_]"M0__0@;?_TL<IGX M"$JL !!G /\ ($IA 923.U,Y/_,3EU.=4Y5__!(YR<R+@ F2' *4 )"E X M !@I0 P0JW_\&$ !61*K 09P@@+?_P8 _"(') LL; 343J[_E"P 2H9GX M "P2JP 2&<60>L "$AL E0O"$ZZ"=903TJ 9P E" K 'A*@&\.""P ?X M9RQ2K 88 P(+ ! !]G=%*L "1!ZP ((DA*&6;\4XF3R"H)NJP ,&\$*44 X M,$JM__!F*&$ !6XK0/_P2H!G?"! (( A0 $(F@ ""Q+<D BWE')__PD;?_PX M8"AA 5&)(!F!' 8%0@4B)H @L2W! (MY1R/_\(%(A2@ $)%(DK?_P2H9FX M /\H("P &-"L "1G!B M__!@(DJL $AF$G #L*P '&8*0?KZUF$ !"9@"$'ZX M^NQA 0<< !,WTSD3EU.=4Y5_]A(YP\P)DAP 2M _]QA &B2&P 3$AL %!.X MN@5R4$\D2W +BP ,%2'2.T ?_@2.T ?_D2.T ?_H(BP 4+*'; 1\ 6 *X M( $B!TZZ#$@L "@L $Q7A&X"> $@+ 8T*P )"(&+T &$ZZ#"HJ " O !@BX M!DZZ#!Y*@6<"4H4@:@ (("@ >$J ;Q (+ !]F!& ,9A $H2JW_X&<6X M+RW_X$AZ^CY(; +T3KH$LD_O Q@!$(L O0@:@ (0^@ "$'L O1.N@M,0>P"X M]$/Z^81.N@M 0>P"]&$ S @:@ (("@ >$J ;P1A "D4JW_Y" M_^2X@&<$X MNH!F7%*M_^@B+?_HLH9F+K"$9BI*K 49R1P ;B ;PQ2K?_<("W_W&$ *R:X MA' *T#_Z"M _^ K0/_D8"(O $AZ^:Y(; +T3KH$'$'L O1A + 3^\ #-^MX M_^!"K?_D)%*URV8 _QX@!9"M_^1O&B\ 2'KY@DAL O1.N@/J0>P"]&$ HY/X M[P ,80 &DS?#/!.74YU2JP %&<(0?KY7F$ G!.=4JL !1G"$'Z^5)A )@X M3G5*K 49PA!^OE&80 "4$YU2JP %&<(0?KY/&$ D!.=4CG,0 N $'Z^3)AX M (P(BP !$'L O0D"'8!+&P$U$ZN_]8O!TAZ^39(; +T3KH#8D'L O1A (&X M3^\ #$S? (Q.=4Y5__@O"R9(< K0/_\*T#_^&&*+PM![?_\0^W_^&$ #(NX MK?_X+RW__"\L "0O+ 82'KX_DAL O1.N@,20>P"]&$ ;9A /]&)FW_]$Y=X M3G5.5?_\2.< ,"9()$DK;0 (__PB;?_\(&D "&$ #@B;?_\(&D "" H 'A*X M@&H0("@ @-&3(&D "" H 'S1DBM1__P@;?_\L>T "&;&3-\, $Y=3G5.5?]0X M2.<C,"9(? !&!LRK '1![?]40_KXIDZZ"5 D0'X < 2^@&P<< 'OH"(&PH!GX M#G (D(=![?]4T< 0O M4H=@WG (OH!L&G(![Z$D!L2!9@R0AT'M_U31P!"\X M "U2AV#@2BL D&8&&WP +?]40>L A"\(3KH$R"!*(D!.N@CL6$\D0" K 'A*X M@&\\""P ?9P MDJL !1G#"!*0_KWJDZZ",8D0"!*0_KX'$ZZ"+HD0$JLX M !1G)B!*0_KW?DZZ")@D0& 8+RL ?"\K (!(>O@&2&W_;TZZ <Q/[P 00>L X M""]( !1![?]4(F\ %$ZZ"&@@2D/Z]J).N@A>0>W_5&$ $Y*K X9SY**P"0X M9SA*K 49Q9!ZP"0+PA(>O?$+PI.N@& 3^\ #& 40>L D"\(2'KWP"\*3KH!X M:D_O Q![ +T80 "DS?#,1.74YU2.<P$"9(($M*&&;\4XB1RR(L D"R8(X M+&P$U$ZN_]!,WP@,3G5(YS 0)D@B+ ) MV 2QL!-1.KO_03-\(#$YU2.<!X M G (CP ! +'@ !$ZN_LXN @' QG#$'Z]TYAG' !*4 $$S?0(!.=4'LX M %1ABD'L 'YAA$'Z]T!A /]^0?KW3&$ _W9!^O=480#_;D'Z]UYA /]F0?KWX M:F$ _UY!^O=P80#_5D'Z]WQA /].0?KWB&$ _T9!^O>480#_/G 0?KU@F$ X M]YY.=4CG !(@/ 1!R "QX 1.KO\Z)D @"V<,( MR#-"!)T "& &< $IX M0 0( M,WT@ 3G5.5?_X2.< ,"9(( MG&"1+*U+_^"!*80 %B1M__@@;?_XX ML<MFZDS?# !.74YU2.< $B9(( MG$")+(#P $0+'@ !$ZN_RY,WT@ 3G4 X M $Y5 !(Y^#P(&T #$/M !!%^@ 6)FT ""QX 1.KOWV3-\/!TY=3G46P$YUX M3E7_X$CG.""3R2QX 1.KO[:($ K: "D__QX ' ($!A &"*T#_]&< 1XBX M/ ! %P1$ZN_SHK0/_X9P 8B1M__0B0"!M__QP 6$ 0)V!$'L .@D""(LX M L; 343J[_T R !&8 !1V$$'M_^ D""(L 1.KO_6* D;?_T(FW_X M^"!M__QP &$ , @+?_X9P@B0'!$3J[_+B M__1G "B80 !A@R$ "6\ X M )1%[?_@#"H .P $9@ A@PR ') _V8 'Q%Z@ %<@ 2&@1! # ,$@ [9QK"X M_ *TAH$ 0 P#!( .V<*POP "M(:! $ ,%)*= 4&@P" "!G !"# ( .V< X M #H, @!R9P ,@0" # ,$@ @9QK$_ *U!H$ @ P#!( (&<*Q/P "M02! ( X M,"!M P@@2!M @@@DS?!!Q.74YU2.< %"9(*DE![0 4*T@ "B!-*T@ %"M*X M !@K? ^( '$I 9P #"M\_____P H8 1"K0 H($LB32QX 1.KOZ2($I.X MKOZ ($I.KOZ,3-\H $YU2.<%)"I(*@!P_RQX 1.KOZV#(#_____9@9P & X M &@N ' B(CP 0 !3J[_.DJ 9@P@!TZN_K!P & $HD0"5- H510 )%7P X M! (%7P .%4< #Y/)3J[^VB5 !"[_ !G"B)*3J[^GB *8!)!Z@ 4X M((A8D$*H 0A2 (( I,WR2@3G4O#2I 2JT "F<*(D L> $3J[^F!M\ /\ X M""M\_____P 4< 0+0 /+'@ !$ZN_K!P(B)-3J[_+BI?3G5.50 2.<?"")MX M A^3BH1;0 QHK\!;4@!4C%Y8W>A4A .@!*16< " \/ %M, <"0 #9@ X M!%)&ND9M *FD92AV _]YX 'P 4D5![ "L'#! Q$ %F ., <"0 #X M9@ !%)&ND9O .FD921 Q$ QM /_8#(< !C;P # 2' 9& _^X@X M*0 (@/P ,C\ < P*0 &,@" _ \-@# _ \DD _ 3\#4D0_!3\$/P=(; "XX M2&P [$ZZ_*1/[P 40>P [" (3-\0^$Y=3G5![ #6( A@\"!O 1P ! 89P X M$@P "IG (# /V;L< %.=4Y5_\!(YQ P)&T ""9M Q![?_ 0^W_Q'8 X M2A)F (2A-G "X#!, *F8 $H,0P! 9P KB&+, CBC 4$-22V#644,@X M"$I#;0 $"!Q. !*$&8 910V#L2D-M ""($ F<# 4DM2L3 )'$X %!#X M8*0,$P _9@ $$H29@ 1DI#9P 6F"X$!(, ! 8P #@P %IB &!@ X M(!(3# $ 0&, X, 0!:8@ !@8! ""R &< Q*0V< "!@ /]^2A)G $X M4DI*$V< A22V _T!P 6 1P $S?# A.74YU3E4 $CG.#(D "@!)@@DX M2+:29P 2"Q*)E*VBV< "8@;@ ((FL "" "3KH .$I$9P !@A !*@&< X M 0L2R938-:USF< ! @+@ (+6H " ()4 ""128+1,WTP<3EU.=4I 9@ X M2D'H A#Z0 (2A!G R$AD, 0! 8P #@P! %IB &!@$ (! 8# 0&, X M X, !:8@ !@8 ""R &?*D %N !:8 6E- 9@ %" I 'RPJ !\;0 X M1&X $1@H%- 9@ /$'H (1#Z0"$(!&PJ ;0 )FX "8@* $D*D !,'\X M"[C0J (D*D "&X IM *8 #_9G !3G5P $YU2.<' "X +"P!%$I&:RX@X M!DC YX!![ .4*C ( $H%9Q@(!0 "9A(@!DC YX!![ .4(# (!$ZZZX!31F#.X M( =.NNM.3-\ X$YU 3E7_=$CG 3 F2'X <""^@&QZ$!-RX M(+ !9PQR"; !9P9R"K !9@12BV#H2A-G7B 'Y8!2AT'M_W31P"1(<"*P$V8BX M4HLDBTH39PIP(K 39P12BV#R2A-F"' !3KKJWF"L0AM@J"2+2A-G&! 3<B"PX M 6<0<@FP 6<*<@JP 6<$4HM@Y$H39@)@!$(;8(!*AV<&0>W_=& $(&P!I" 'X M3KKJ[G 3KKJEDS?#(!.74YU !P82((8 00V6<(4X!D^& &0AA3X M@&3Z( %.=2 (2AAF_%.($-EF_$YU !(YP P)D@D21 :%H!* &<$4HM@]" +X M3-\, $YU2.<#$"X 1^P!&" +9S (*P " !MF) @K $ &V<<("L !)"K ! LX M $J&9PX@*P <(@8@:P 03KKJ+B938,P@!TZZ_FY,WPC 3G4 '!AX M2H!J >1(!*@6H Q$@6$ "!$@4YU80 &$2 1(%.=4J!:@ #$2!80 X M!D2 3G4O DA!- %F B2$!(04A"- !G &A,$P DA - "$P3 "2$(R B0?X M3G4O W80#$$ @&0 ;AF5%##$$( &0 ;IF5E##$$@ &0 ;EF55#2D%KX M &XYE30S0 YJA(0D)"YJI(0X#!-@ P C0#2$'$P9""9 "%-#T(%D_G( X M,@-(0^>X2$#!028?)!].=2!O 1@ /WF3G$ ^P ! 0 8 X M #\@ ^H !C X M X M !0 !-FS,S;4Q3(#(N,)LP;2!B>2!*=7-T:6X@5BX@36-#;W)M:6-KX M(#$Y.#@ "E5S86=E.B!L<R!;+6-D9FQN<G-T4ET@6W!A=&@Q72!;<&%T:#)=X M("XN+@H !\<'QX?'A\?'A\>'R4P,F0M)3 R9"TE,#)D("4P,F0Z)3 R9#HEX M,#)D # P+3 P+3 P(# P.C P.C P )LP('$ X M * 3H X M %< X M @ X 2 3H $8 #[ /RX X end
limonce@pilot.njin.net (Tom Limoncelli) (07/30/89)
Note: I removed comp.sys.amiga.tech from the Newsgroups: line. Kent, with all due respect, what computer are you talking about? Certainly not the Amiga that I use! In article <12878@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: > I've heard "it's in there" about the 1.4 release. Here are my entries in > the great 1.4 wish list sweepstakes, in hopes that this is timely, and > finds some you missed. > > Most important: make sure that the hard disk and other file system control > software is compatible with SCSI, removable medium, 1.5 Gbyte disks. These SCSI support, removable medium and 2.2GIG disks are all supported in 1.3! Check out (for example) GVP, they've shipped a SCSI controller that supports removable media (even 1.2 or 1.1 included DiskChange :-) support. Basically all the driver has to do is issue a DiskChange command when media is removed. > drives should arrive before the 1.4 release. (Mfgr's name available to > CATS on request, if you haven't already had a demo of the existing > prototype.) In particular, limitations of "partition" sizes, numbers of FFS supports 2.2gig per partition therefore (a) removing the need for partitions [if you don't believe in them] or (b) permitting you to make any size partition you want [if you do believe in them] > files/directories per directory node, maximum length of a path name, etc., OFS and FFS have no limits on # of files (MS-DOS does). Max length of path name has never affected me except just now when I couldn't go more than 8 deep. I never knew there was a limit until you just mentioned this and I opened a CLI to test it out. > should all be reviewed and improved in anticipation of truely fast, huge > (and extremely cheap; ~ $1/Mbyte drive cost) storage systems. In most > cases, hard limits should be replaced by soft limits; path name arrays -> > path name c-strings, directory name arrays -> directory name link lists, > und so weiter. I can hardly wait to put my 400 floppy disksfull of PD > software and data on one huge disk, and, at last, sort it out. [Naturally > the only practical backup for such a beast is another one just like it, so > I'll probably buy two!] Ummm... what's stopping you from doing that now? > Merge list and dir commands ("ls" would be a catchy name for the result!) [deleted long tirade about a proposed improved LIST/DIR command] Ummm... is you want ls, find it on the fish disks. > Replace/supplement the existing "Pipe:" device with a real Unix(tm)-like > "|" pipe that can be used in a one line command. That's the shell, not the OS (but a 1.4 suggestion non-the-less). I've heard rumors... > Add a command to display/kill locks, to help clean things up when a disk > icon won't go away because some careless programmer left a lock engaged. How about a command to display and kill careless programmers? > Add a capability to use extended selection for _any_ program, without > change to the object module, to make it think it is getting command line > input. I added a tool icon to my favorite microemacs (the one from [Tirade deleted] That's in most of the startup code from most compilers that I've seen. Of course, all that Workbench stuff will change in 1.4 and be much better (we've been told). > While I'm on the subject, add paragraph flowing capability (preferably > including a fixed "indentation string" option, like GNUEmacs has) to the > Extras 1.3 MEmacs. That would make it almost usable for text processing > tasks on simple ASCII files, since it already works in extended selection > mode. Yes, Emacs is nice, and text editors can always use more features :-) > An otherwise empty, INSTALLed disk with :s/startup-sequence = "loadwb" > and :loadwb version 1.3 its only files fails to boot with a return code 20 > from loadwb. The 1.3 docs for loadwb do not give any preconditions for its > successful operation, and none of the commands' docs give return code > interpretations. Both these problems need fixing. [I was trying to make > the Hack_Game: disk bootable, but it needed a workbench loaded to be > useful. No joy.] That would be nice to be documented, and certainly isn't as (ummm...) outlandish as your first couple comments. I *belive* that all you need is icon.library but I've never looked into it. (hard drives do that to you :^) [Other things deleted] > Thanks for listening, as usual. > > well!xanthian > Kent, the man from xanth, now just another echo from The Well. -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University :) Is it my imagination or are a lot of people posting everything twice? (: ...or is this some new rule that I don't know about?
jwright@atanasoff.cs.iastate.edu (Jim Wright) (08/01/89)
In article <1390.AA1390@americ> erk@americ.UUCP (Erick Parsons) writes: | There is a PD (Shareware?) directory command called 'ls' that columnates | directory listings in as many rows as can possibly be displayed on the screen | (even more w/morerows). Twas posted about 2-3 months ago if my memory serves | me right. Listings are sorted alphabetically w/ options to alter the sorting | method. | Here it is for those who missed it... Unfortunately, you posted version 2.0, while version 2.2 (2.3?) has a number of significant improvements. This happened last time it was posted. I can either mail it to a few or post it for all. -- Jim Wright jwright@atanasoff.cs.iastate.edu
FelineGrace@cup.portal.com (Dana B Bourgeois) (08/01/89)
Mike Meyer is asking for unlimited arguments for list, and dir (among others). Sure sounds like ARP1.3 to me. C'mon. What do people have against small, fast, highly functional, free, already available commands? I use ARP commands and have no problems with them. I'd like to see Commodore put them into 1.4 which rumor has it is an offer already made to Commodore that they turned down! I shake my head in wonder. By using ARP one gets about 12K of space back on a workbench disk. This is significant. Can one of the CATS people comment on ARP and whether it will make it into AmigaDOS and if not why not? Dana Inquiring minds want to know. Get it at your local checkstand!
shadow@pawl.rpi.edu (Deven T. Corzine) (08/01/89)
On 31 Jul 89 19:51:41 GMT, jwright@atanasoff.cs.iastate.edu (Jim Wright) said: Jim> Unfortunately, you posted version 2.0, while version 2.2 (2.3?) Jim> has a number of significant improvements. This happened last Jim> time it was posted. I can either mail it to a few or post it for Jim> all. Post it! Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
xanthian@well.UUCP (Kent Paul Dolan) (08/02/89)
[Following up my own posting; no class!] I work in a large ram, no HD: environment (Amiga 2000 with 9Mbytes, 2 floppies). It would be extremely nice if the large files I can now make in memory could be supported as multi-floppy-volume files. This is usually a mainframe feature for magnetic tape files, not a micro feature, but it would sure be nice to capture my normal software development environment in a zoo'ed file (it takes up about 2.2 mbytes after compression) onto three diskettes, then recover at my next cold boot with just one "zoo -extract" command and a couple of disk swaps. As is, I have to do a couple of trial zoo passes to get the right partitioning of files to match the size of each diskette. And that means about an hour's extra work. Again, thanks for listening. well!xanthian Kent, the man from xanth, now just another echo from The Well.
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/02/89)
In article <20904@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes:
<Mike Meyer is asking for unlimited arguments for list, and dir (among
<others). Sure sounds like ARP1.3 to me.
Yes, but that doesn't let me write scripts, makefiles & treewalks and
give them to people without having to make sure they have some large,
nonstandard piece of software installed to work correctly.
<C'mon. What do people have against small, fast, highly functional, free,
<already available commands?
Pre 1.3 versions broke a _very_ important piece of AmigaDOS syntax. So
I backd it out. Note that taking out ARP is much harder than putting
it in. With most of 1.3 being resident and lots of resources, it's not
worth the risk of installing it. If I still had 2 floppies & .5Meg,
then it might be worth it. As it is, all I do is chew up some extra
memory (currently, I've got 3.5M of free fast ram....).
<I shake my head in wonder. By using ARP one gets about 12K of space
<back on a workbench disk. This is significant.
12K out of 60M is less than 2/100ths of a percent. This is
insignificant. Of course the arp library is also insignificant, so
it's on the disk so that applications don't fall over and die (nasty
habit) if it isn't there. It also gets used by rexxarplib.
<Can one of the CATS people comment on ARP and whether it will make it
<into AmigaDOS and if not why not?
I've heard rumors that something similar to ARP, only better designed
(not cramming everything into one library) is on 1.4. That's another
good reason for not installing it now.
<mike
--
That time we slept together Mike Meyer
That's as far as it went mwm@berkeley.edu
Yet though we're not quite lovers ucbvax!mwm
You're more than a friend mwm@ucbjade.BITNETmwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (08/03/89)
In article <12968@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes:
<[Following up my own posting; no class!]
Nah, just lazy. No worse than me pickig up your posting to make my
posting easier...
Anyway, to add to the wish list:
Unless I've broken things with a non-standard environment, currently
C-c's only get sent to the process actually talking to the terminal.
If that was started as one of a series by some program, then the
program that did the starting doesn't see the signal, just the
termination of the running program. If the broken (breaked?) program
doesn't signal that it saw a break, or the program that started it
doesn't check on these things (which it may be doing for good reason),
then the next program in the series will be started.
This is almost certainly not what the user wanted.
The suggested behavior change is obvious: make C-c stop all programs
involved. I would also suggest that C-d get the semantics that C-c has
now, so that the user can stop only the current process, and the next
one can continue if things are set up correctly (might as well do
something with all those break characters).
This should also affect a pipeline if the cli being used supports '|'
pipes, so that C-c goes to all processes in the pipeline.
Implementation: well, I can tell you how I'd tackle it, but I've been
warped by watching how Unix does it, so I won't unless asked.
<mike
--
When logic and proportion have fallen softly dead, Mike Meyer
And the white knight is talking backwards, mwm@berkeley.edu
And the red queen's off her head, ucbvax!mwm
Remember what the dormouse said. mwm@ucbjade.BITNETeachus@mbunix.mitre.org (Robert Eachus) (08/03/89)
In article <12968@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: >I work in a large ram, no HD: environment (Amiga 2000 with 9Mbytes, 2 >floppies). It would be extremely nice if the large files I can now >make in memory could be supported as multi-floppy-volume files. Sounds silly, but get a hard-disk backup program! All of the ones I am familiar with, including the PD ones, will backup to multiple floppies without pre-partioning. I won't recommend one, since my situation is not yours, and my criteria are not yours. (I do my backups over an NFS connection, so I need a backup program which uses the FS system on the target without counting on knowing too much about it.) Only on the Amiga do you need a backup program for your ram-disk! Robert I. Eachus
sparks@corpane.UUCP (John Sparks) (08/03/89)
<20904@cup.portal.com> Sender: Reply-To: sparks@corpane.UUCP (John Sparks) Followup-To: Distribution: na Organization: Corpane Industries, Inc. Keywords: In article <20904@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >C'mon. What do people have against small, fast, highly functional, free, >already available commands? The reason I don't use arp is because of the pesky arp.library that has to be around. I always seem to get into a situation where I need it but the arp program can't seem to find it. It's more a hassle than anything else. I usually say the hell with it and use AmigaDOS commands -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps ||||||||||||||| sparks@corpane.UUCP | 502/968-5401 thru -5406 As far as we know, our computer has never had an undetected error.
johnhlee@cory.Berkeley.EDU (Vince Lee) (08/04/89)
While we're on the subject of additions to 1.4, let me put in my 2 cents worth. 1. Replace the Topaz font. I have put my own font into my kickstart, and EVERYTHING looks better and nothing is worse. Programmers need to have a font they know will always be available. My font is single-width, sans serif. True, people using TV's as monitors wouldn't like it, but even a double-width sans-serif font is better than what we have. It's simple to do, and makes the Amiga look MUCH more professional in every application. 2. Improve the audio device to allow stealing and automatic return of audio channels. The current system is too UGLY. I know of no program which checks to see if a channel has been stolen and tries to get it back. All of them either chug right along or lock the channels once they get them. 3. Shrink workbench icons in interlace mode. I've suggested this before, and others have suggested enlarging them. Enlarging them makes them take too much space (I've tried). Since Amiga Icons are too big to begin with anyway, throwing away half the pixels shrinks them to a professional-looking size. Just my two cents -Vince
perley@vdsvax.crd.ge.com (Perley Donald P) (08/05/89)
In article <12968@well.UUCP> xanthian@well.UUCP (Kent Paul Dolan) writes: >I work in a large ram, no HD: environment (Amiga 2000 with 9Mbytes, 2 floppies). >It would be extremely nice if the large files I can now make in memory could be >supported as multi-floppy-volume files. This is usually a mainframe feature >for magnetic tape files, not a micro feature, but it would sure be nice to >capture my normal software development environment in a zoo'ed file (it takes >up about 2.2 mbytes after compression) onto three diskettes, then >recover at my next cold boot with just one "zoo -extract" command and a couple >of disk swaps. Take a look at DosKwiK, on fish disk 103 (there may be a newer version). It was written to do just that. It uses a non-dos format for the disks, and runs about as fast as a diskcopy to rad: (faster than "diskcopy df0: to df1:", for example). I don't think it does any compression, but the speed makes up for it. -- -don perley perley@crd.ge.com
sinclair@oakhill.UUCP (Brian Sinclair) (08/05/89)
In article <20904@cup.portal.com> FelineGrace@cup.portal.com (Dana B Bourgeois) writes: >Mike Meyer is asking for unlimited arguments for list, and dir (among >others). Sure sounds like ARP1.3 to me. > >C'mon. What do people have against small, fast, highly functional, free, >already available commands? I use ARP commands and have no problems with >them. I'd like to see Commodore put them into 1.4 which rumor has it is >an offer already made to Commodore that they turned down! > >I shake my head in wonder. By using ARP one gets about 12K of space >back on a workbench disk. This is significant. > >Can one of the CATS people comment on ARP and whether it will make it >into AmigaDOS and if not why not? > >Dana > >Inquiring minds want to know. Get it at your local checkstand! Well Dana, I dont know about the folks at CATS, but I love using ARP1.3. My only complaint is that if you perform the installation as outlined in the documentation you will no longer be able to autoboot from the RAD: device. I had the same problem with ARP1.1 under AmigaDOS1.3. I finaly did get my 1000 to autoboot from RAD: using ARP1.1 by reinstalling some of the original AmigaDOS files. I havent had time to investige the problem using ARP1.3. I am however still running ARP1.3 anyway! P.S. this is my first netmail message so PLEASE forgive any errors. Regards, Brian Sinclair *:-)
451061@UOTTAWA.BITNET (Valentin Pepelea) (08/06/89)
John Sparks <sparks@corpane.uucp> writes in message <927@corpane.UUCP> > The reason I don't use arp is because of the pesky arp.library that has to be > around. I always seem to get into a situation where I need it but the arp > program can't seem to find it. It's more a hassle than anything else. God! Did you not know you are supposed to put the arp.library in the LIBS: directory? There is even a program, ArpInstall which will do everything easely for you! How did you ever manage to get on this net? Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
jms@tardis.Tymnet.COM (Joe Smith) (08/06/89)
John Sparks <sparks@corpane.uucp> writes in message <927@corpane.UUCP> The reason I don't use arp is because of the pesky arp.library that has to be around. I always seem to get into a situation where I need it but the arp program can't seem to find it. It's more a hassle than anything else. In article <8908060117.AA03288@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >God! Did you not know you are supposed to put the arp.library in the LIBS: >directory? There is even a program, ArpInstall which will do everything >easely for you! > >How did you ever manage to get on this net? Valentin, did you ever stop to think - most of us have more than one bootable Workbench disk. If you copy even just one ARP command to the C: directory, you have to copy arp.library as well. Many times. Over and over. I have some floppies that are so tight that arp.library won't fit. (These are special purpose floppies where replacing all commands in C: may be contra-productive.) -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
jtreworgy@eagle.wesleyan.edu (08/07/89)
In article <490@tardis.Tymnet.COM>, jms@tardis.Tymnet.COM (Joe Smith) writes: > John Sparks <sparks@corpane.uucp> writes in message <927@corpane.UUCP> > The reason I don't use arp is because of the pesky arp.library that has to be > around. I always seem to get into a situation where I need it but the arp > program can't seem to find it. It's more a hassle than anything else. > > In article <8908060117.AA03288@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >>God! Did you not know you are supposed to put the arp.library in the LIBS: >>directory? There is even a program, ArpInstall which will do everything >>easely for you! >> >>How did you ever manage to get on this net? > > Valentin, did you ever stop to think - most of us have more than one bootable > Workbench disk. If you copy even just one ARP command to the C: directory, > you have to copy arp.library as well. Many times. Over and over. > I have some floppies that are so tight that arp.library won't fit. > (These are special purpose floppies where replacing all commands in C: > may be contra-productive.) I think that most of us who use our Amigae more that just trivially have only one REAL bootable disk, that is, the disk we work off of. (Don't take that literally, flamers... of course almost every game I have boots by itself). Any disk on which you have a substantial subset of the C directory will not be taxed by changing to ARP. As for any disk which does NOT have a substantial subset, why bother? You probably don't do enough with that disk to make it worthwhile. I have one Workbench disk I use. I can't imagine having to update several disks every time I make changes to my operating environment.What possible reason is there for having more than one? It wastes enormous amounts of disk space. Actually, I take that back. There is one reason, which is you only have one disk drive, and want to have enough on every disk so you don't have to continually swap disks. But since I got a second disk drive (should be standard equipment for any Amiga! Crippled without it) I have found no reason to keep duplicate copies of all that stuff. -- James A. Treworgy "You should have seen me with the poker man, jtreworgy@eagle.wesleyan.edu I had a honey and I bet a grand, jtreworgy%eagle@WESLEYAN.BITNET Just in the nick of time I looked at his hand" Box 5033 Wesleyan Station -Paul McCartney Middletown, CT 06475
pmf@mimsy.UUCP (Paul M. Franceus) (08/07/89)
Actually, you CAN reboot out of RAD: while using ARP. Just put a "BootPri=0" in the mountlist for the RAD and it will work fine. Paul Franceus StarLight Technologies
451061@UOTTAWA.BITNET (Valentin Pepelea) (08/07/89)
jms@tardis.tymnet.com writes in Message-ID: <490@tardis.Tymnet.COM> > Valentin, did you ever stop to think - most of us have more than one bootable > Workbench disk. If you copy even just one ARP command to the C: directory, > you have to copy arp.library as well. Many times. Over and over. > I have some floppies that are so tight that arp.library won't fit. > (These are special purpose floppies where replacing all commands in C: > may be contra-productive.) Either you install the entire ARP package (saving 20% space on the floppy) or you don't. The situation where you boot from a disk, issue an ARP command and then are caught without arp.library cannot occur. The writer of the original poster has to be pretty wacked to install only some commands in the first place, and then not install the arp.library at all in the second place. Frankly, the logic here is beyond me. Valentin _________________________________________________________________________ The godess of democracy? "The Name: Valentin Pepelea tyrants may destroy a statue, Phonet: (613) 231-7476 but they cannot kill a god." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Confucius Planet: 451061@acadvm1.UOttawa.CA
davewt@nc386.uucp (David Wright) (08/09/89)
In article <16025@pasteur.Berkeley.EDU> johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >While we're on the subject of additions to 1.4, let me put in my 2 cents >either chug right along or lock the channels once they get them. > >space (I've tried). Since Amiga Icons are too big to begin with anyway, > Icons on the Amiga are not hard coded. If you think that the icons are too big, there are several PD programs that let you edit them and some have a "shrink" option built in. There is nothing stopping you from completely replacing the icons with 2 pixel wide lines, if that is what you wanted to do. Personally, I rarely use the workbench/icons anyway, but I like to see the big icons that people have drawn for their program. It lets me gloat over certain other computers in which the size of an icon is limited to a 1x1 inch or so square.... Dave
sparks@corpane.UUCP (John Sparks) (08/09/89)
In article <8908060117.AA03288@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >John Sparks <sparks@corpane.uucp> writes in message <927@corpane.UUCP> > >> The reason I don't use arp is because of the pesky arp.library that has to >>be >> around. I always seem to get into a situation where I need it but the arp >> program can't seem to find it. It's more a hassle than anything else. > >God! Did you not know you are supposed to put the arp.library in the LIBS: >directory? There is even a program, ArpInstall which will do everything >easely for you! > One of the situations I am talking about above: My System: A1000, 512K, 2 floppy drives One problem is with VLT. I didn't have enough memory to put an ARP workbench in df0: and run VLT from df1:. Also there wasn't enough space on the VLT disk to install ARP. So to run VLT I had to boot from the VLT disk in df0:, but Then VLT couldn't find ARP. If I booted with the ARP workbench, I didn't have enough memory for VLT. Very frustrating. >How did you ever manage to get on this net? It followed me home one day. :-) -- John Sparks | {rutgers|uunet}!ukma!corpane!sparks | D.I.S.K. 24hrs 1200bps ||||||||||||||| sparks@corpane.UUCP | 502/968-5401 thru -5406 If we weren't supposed to juggle, tennis balls wouldn't come three to a can.
johnhlee@cory.Berkeley.EDU (Vince Lee) (08/10/89)
In article <1989Aug8.220028.13827@nc386.uucp> davewt@nc386.UUCP (David Wright) writes: >In article <16025@pasteur.Berkeley.EDU> johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >>space (I've tried). Since Amiga Icons are too big to begin with anyway, > > Icons on the Amiga are not hard coded. If you think that the icons ^^^^^^^^^^^^^^ >are too big, there are several PD programs that let you edit them and >some have a "shrink" option built in. There is nothing stopping you from >completely replacing the icons with 2 pixel wide lines, if that is No SH*T. I haven't been programming my Amiga for 3 years while failing to realize that I could edit my icons! When I first got my machine, IconEd was one of the two pieces of software I had (the other was preferences). What I want to see is auto-shrinking of icons in interlace so I don't have to edit EVERY GODDAMN ICON on EVERY DISK that I get! One of the biggest problems with the Amiga is that most of the developers I know have absolutely NO artistic talent. The Amiga Topaz font and "insert workbench" hand are constant painful reminders of this. Although the Amiga is a great machine, what most people see is the incredibly cheezy-looking workbench with its C64-looking icons. When they compare this with the sleek, professional-looking Mac with its sharp, crisp text and icons, it's no wonder Amiga's penetration into the business market is near nill. Editting my own icons won't change the Amiga's appearance for everyone else. Interlace mode, even with a flicker-fixer looks stupid because everything is wide and flat. What I'm saying is this: I don't wan't shrinking of icons just to make my own workbench look better. That misses the point completely. I think shrinking of icons would make the Amiga look more professional to people considering purchasing an Amiga instead of a Mac or Clone, and that would make it all worthwhile. > Dave -Vince
jtreworgy@eagle.wesleyan.edu (08/10/89)
In article <16163@pasteur.Berkeley.EDU>, johnhlee@cory.Berkeley.EDU (Vince Lee) writes: > > What I want to see is auto-shrinking of icons in interlace so I don't have > to edit EVERY GODDAMN ICON on EVERY DISK that I get! > > One of the biggest problems with the Amiga is that most of the developers > I know have absolutely NO artistic talent. The Amiga Topaz font and > "insert workbench" hand are constant painful reminders of this. Although > the Amiga is a great machine, what most people see is the incredibly > cheezy-looking workbench with its C64-looking icons. When they compare > this with the sleek, professional-looking Mac with its sharp, crisp text > and icons, it's no wonder Amiga's penetration into the business market is > near nill. > The cheezy looking workbench hand is no more on my Kickstart disk. Neither is topaz. But I don't think that the workbench itself is cheezy looking. Maybe commodore shoudl make an alternate workbench (maybe SnoreBench?) where every icon for a directory looks like a folder and everything is black & white (or green and white?) and so on. ... also I don't think the way the AMiga looks has much to do with it's business market penetration. Look at the Mac, it somehow managed to penetrate the business market with a 6 inch screen! I get headaches every time I have to use one of those miserable machines. When you turn it on, you see a picture of a Mac smiling at you!!! Yuck. > What I'm saying is this: I don't wan't shrinking of icons > just to make my own workbench look better. That misses the point completely. > I think shrinking of icons would make the Amiga look more professional to > people considering purchasing an Amiga instead of a Mac or Clone, and that > would make it all worthwhile. People aren't often trying to decide between a Mac and a clone. I don't think anyone would choose a mac over an Amiga because of the way it looks. Have you ever been to a computer store that doesn't specialize in Amigas? I mean, one that sells everything (macs, pcs, and Amigas). The Amiga is almost always sitting in a corner gathering dust. You go in there without knowing anything. You say you want something to manage a huge inventory, they sell you a PC. You say you want something easy to use to run a small business (we tried to use a mac to manage a huge inventory, forget it... that thing is pathetic) or do smaller scale computing, and you know nothing about computers, they sell you a mac. You have to practically force them to sell you an Amiga. It's because they don't know anything about the machine, and don't care. The only good Amiga dealerships are the small (not large chain) stores that are run by someone who hasn't been using PC's for five years. And business owners don't shop there. -- James A. Treworgy "You should have seen me with the poker man, jtreworgy@eagle.wesleyan.edu I had a honey and I bet a grand, jtreworgy%eagle@WESLEYAN.BITNET Just in the nick of time I looked at his hand" Box 5033 Wesleyan Station -Paul McCartney Middletown, CT 06475
C506634@umcvmb.missouri.edu (Eric Edwards) (08/11/89)
jms@tardis.tymnet.com writes in Message-ID: <490@tardis.Tymnet.COM> > > Valentin, did you ever stop to think - most of us have more than one bootable > Workbench disk. If you copy even just one ARP command to the C: directory, > you have to copy arp.library as well. Many times. Over and over. > I have some floppies that are so tight that arp.library won't fit. > (These are special purpose floppies where replacing all commands in C: > may be contra-productive.) > I used to have lots of bootable Workbench disks. That is until I upgraded to 1.3 last year. First I tried the direct approach, upgrading each disk one by one. Unfortunately, each one had a different subset of Workbench environment and the task of re-hacking each disk was so large that I just chucked the whole idea and concentrated on developing one, general disk. I now have only two bootables: Workbench (general) and my Compiler disk. The later has a special startup-sequcence to get me back up and running as fast as possible after a GURU. I was able to convert entirely to ARP in an evening, something I never could have done with the old system. Bitnet: C506634@umcvmb.bitnet __________________________ Internet: C506634@umcvmb.missouri.edu / \.--------. / \ "The Amiga just isn't reliable enough unless you | | Eric |---------+ | know a lot about the machine" -- Jerry Pournelle | `--------' ! | ================================================|| .--------. ! | "I did notice that at my party people stood in | | Edwards|_________+ | line to play with the Amiga"-- Jerry Pournelle | /`--------' | BYTE, October '88 \__________________________/
johnhlee@cory.Berkeley.EDU (Vince Lee) (08/13/89)
In article <8908060117.AA03288@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >John Sparks <sparks@corpane.uucp> writes in message <927@corpane.UUCP> > >> The reason I don't use arp is because of the pesky arp.library that has to >>be >> around. I always seem to get into a situation where I need it but the arp >> program can't seem to find it. It's more a hassle than anything else. > >God! Did you not know you are supposed to put the arp.library in the LIBS: >directory? There is even a program, ArpInstall which will do everything >easely for you! > What on earth are you talking about? I'm sure EVERYBODY knows where the arp library goes. That's not the problem. I have arp, and I stand by it, but I cannot recommend it for everyone until the arp.library is in ROM. I can't count the number of times when I have been given a self-booting demo of some type which fails in the startup sequence. Ok, I say, I'll just put my workbench in the other drive and use its commands to type the startup-sequence out. RECOVERABLE ALERT! Oh, gee, I forgot I have to re-assign the libs: directory first... Wait, my assign command is an ARP command too!!! SH*T! Where is my original WB disk???? Get the picture? -Vince
johnhlee@cory.Berkeley.EDU (Vince Lee) (08/13/89)
In article <455@eagle.wesleyan.edu> jtreworgy@eagle.wesleyan.edu writes: >In article <16163@pasteur.Berkeley.EDU>, johnhlee@cory.Berkeley.EDU (Vince Lee) writes: > >commodore shoudl make an alternate workbench (maybe SnoreBench?) where every >icon for a directory looks like a folder and everything is black & white (or Wait a minute! I said nothing of the kind. I like my color and custom icons. What I was trying to say was that Amiga Icons tend to look UGLY. Icons in interlace ALWAYS look ugly. The only solution is to either: 1) process icons when running an interlaced WB to get their aspect ratio back. This means either shrinking them horizontally or stretching them vertically. The former means the loss of some detail. The latter would nullify much of the benefit of an interlaced wb in the first place. You'd have to resize your windows to fit the bigger icons. 2) extend the icon format to allow for two images, one for either resolution, with the option of doing #1 above if the second image is not present. Any shrinking/expanding would be a preference option, of course. The second issue I was trying to address was that Icons on the amiga tend to be too big. This must come from developers with inadequacy complexes trying to show "my computer is better 'cause its got BIG icons!" Unfortunately, the big icons are usually poorly-designed, lack detail, and are just downright GAUDY AS HELL. Part of this has to do with the fact that Workbench's vertical resolution is pretty low in non-interlace, and that most monitors used with the Amiga are pretty coarse in dot pitch compared to the MAC. The above shrinking option would solve both problems. For people running in non-interlace, it would do nothing. For those of us who like an interlace WB, it would make disk icons square again, eliminate double-pixel wide lines, and make the icons half as large in either direction, giving a professional look. Amiga stores could run a 2500 w/ a flicker-fixer on this workbench and not have to explain why the icons are all so squat. Awhile back, I wrote a WB replacement called WORPbench (WOrkbench Replacement Program -Bench) which had the option of shrinking icons. It used a smart algorithm with had a color precedence when doing the reduction, thus keeping single-wide pixels from disappearing and keeping icon symmetry. Surprisingly, It worked very well. Every Icon I tried it on looked better when shrunk. >green and white?) and so on. ... also I don't think the way the AMiga looks has >much to do with it's business market penetration. Look at the Mac, it somehow >managed to penetrate the business market with a 6 inch screen! I get headaches ^^^^^^^^^^^^^^ I think that just proves my point. The Mac's 9-inch screen is LESS FUNCTIONAL than the Amiga's, but it LOOKS BETTER because of the dot pitch. In the same vein, the mac desktop LOOKS MUCH BETTER than the standard Amiga Workbench, which tends to look like a toy. Unfortunately, of course, it currently works better than WB too. >mac to manage a huge inventory, forget it... that thing is pathetic) or do ^^^^^^^^^^^^^^^^^ Yeah, but it looks nice. You want something that works? Why'd you buy IT then? -Vince
jmpiazza@sunybcs.uucp (Joseph M. Piazza) (08/13/89)
In article <16246@pasteur.Berkeley.EDU> johnhlee@cory.Berkeley.EDU.UUCP (Vince Lee) writes: >... The Mac's 9-inch screen is LESS FUNCTIONAL >than the Amiga's, but it LOOKS BETTER because of the dot pitch. ... Definitely. The Mac display on my A-Max Mac-u-lator looks pretty horrid on my Max-15 hi-res monochrome multisynch monitor with long persistence phosphor (try typing t h a t ten times fast). It already shows how archaic the Mac Plus/SE 1-bitplane display is. The Amiga's 640 x 400 display gives a comfortably larger desktop then the Mac's pitiful 512 x 342. Note that the Amiga's interlaced rendition of the Mac's display flickers even on my LP-phosphor Max-15 while my true Amiga display seems rock solid to me (your flicker-mileage may vary). The Mac display on my 1080 would make even Genghis Kahn puke. :-) Apple would be doing themselves a big favor if they gave up the profit margin on the puny Plus/SE CRTs and used at least a Lisa sized (10 inch 600-or-so x 342?) screen. Instead, they offer the rest of us the puny 1-bitplaned SE/30 with no slots or the $,$$$$ Mac II/c/x/i. Normally I wouldn't toast the Mac like this -- hell, if anything I tend to defend it in comp.sys.amiga from various forms of misinformation -- but the A-Max makes the Mac's display deficiency so censored o b v i o u s. If nothing else, I think this should show that Amiga's flicker problems shouldn't be judged too briefly. It also show how unremarkable the Mac Plus/SE hardware is (currently) -- it's what is in them ROMs that counts. Flip side, joe piazza --- Disclaimer: I disclaim. --- "Where's my other sock?" A. Einstein CS Dept. SUNY at Buffalo 14260 UUCP: ..!{ames,boulder,decvax,rutgers}!sunybcs!jmpiazza BITNET: jmpiazza@sunybcs.BITNET Internet: jmpiazza@cs.Buffalo.edu
sdl@linus.UUCP (Steven D. Litvintchouk) (08/16/89)
In article <16163@pasteur.Berkeley.EDU> johnhlee@cory.Berkeley.EDU (Vince Lee) writes: > What I want to see is auto-shrinking of icons in interlace so I don't have > to edit EVERY GODDAMN ICON on EVERY DISK that I get! I agree. Workbench 1.4 should incorporate this feature. > ....the Amiga is a great machine, [but] what most people see is the > incredibly cheezy-looking workbench with its C64-looking icons. > When they compare this with the sleek, professional-looking Mac with > its sharp, crisp text and icons.... It's not just the text and icons, it's also the appearance of the *windows*. Workbench's windows (featureless white borders on a blue background, with no drop shadows) are the worst looking of any modern window system I've seen. (Yes, of course you can change the colors, but not the design of the window borders.) Compare the Amiga's windows with those on the NeXT user interface, for example. NeXT also has a 2-bitplane desktop, but the windows use colors so as to give the window borders a pleasing, two-dimensional appearance. At the very least, Workbench 1.4 should provide a dropshadow feature comparable to the PD "Dropshadow 2.0" program. If there ever is a "Workbench 2.0," I hope it will offer windows that look like those on OSF/Motif, for example. Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp.
joe@vixen.uucp (Joe Hitchens) (08/22/89)
I agree with Vince that the Amigas icons are mostly of very poor quality, and often unneccessarily quite large. I too am impressed with the slick and polished effect that the Mac has in comparison. I also have a simple solution to the problem. If you would all just spend a few bucks to hire a professional artist (such as myself) to render the icons for your packages before publishing/distributing them, the problem would be solved. I have a farily sophisticated philosophy about what an icon is and what it should do. I have made quite a few of them. There is a very special art to designing and rendering an icon. It is a carefully thought out image whose purpose is to convey a maximum of information about a "thing" or about what a person wants to convey about a "thing", in a minimum of space. When done properly, an icon can be very gratifying to look at and to have created, and has a special kind of magic. I wouldn't want to make an ad out of this article, but I "am" available for icon creation. And not just for the cash. I have a sort of minor "mission from god" to do something about the poor state of the Amiga visually. (C-A, if that other guy isn't working out on 1.4, you know who to call ...) I have a great deal of respect for Amiga programmers, as far as their programming prowess goes, but please .... please ... please ... oh great code guru, let me do this simple thing for you! I shan't disappoint you. j.h. -- ========================================================================== Joe Hitchens -- Artist, Sculptor, Animator of Sculpture, Iconologist Adept joe@vixen ...!uunet!iconsys!caeco!vixen!joe joe@amie ...!uunet!iconsys!caeco!i-core!amie!joe
jimm@amiga.UUCP (Jim Mackraz) (08/29/89)
In article <64360@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: ) )In article <16163@pasteur.Berkeley.EDU> johnhlee@cory.Berkeley.EDU (Vince Lee) writes: ) )> What I want to see is auto-shrinking of icons in interlace so I don't have )> to edit EVERY GODDAMN ICON on EVERY DISK that I get! ) )I agree. Workbench 1.4 should incorporate this feature. I also like it. There are some other icon manipulations that I can see happening, either at run-time or batch, such as dithering down the icons to work on a 1 bitplane WB or swapping colors around to change the "color scheme" (see below). )> ....the Amiga is a great machine, [but] what most people see is the )> incredibly cheezy-looking workbench with its C64-looking icons. )> When they compare this with the sleek, professional-looking Mac with )> its sharp, crisp text and icons.... ) )It's not just the text and icons, it's also the appearance of the )*windows*. Workbench's windows (featureless white borders on a blue )background, with no drop shadows) are the worst looking of any modern )window system I've seen. (Yes, of course you can change the colors, )but not the design of the window borders.) I agree. They're not as bad as in V1.1, though (stripes were even thinner). )Compare the Amiga's windows with those on the NeXT user interface, for )example. NeXT also has a 2-bitplane desktop, but the windows use )colors so as to give the window borders a pleasing, two-dimensional )appearance. You know what the big problem with trying to do that is? Lack of a palette "color scheme." The NeXT has four grays. Other modern systems let you pick a subtle general "hue" and dictate four shadings of that. If people are free to pick any colors at all, it's pretty hard to get reliable 3D effects. Also, if we pick a color scheme to try to standardize, it would have to be one with dark text on light background, for several compelling reasons (which I won't list, for fear of discussing them yet again). This would make what little 3D that there is (in icons) inverted. Hence the need for an icon color swizzler. This program might be represented by an icon. You drop your application/drawer icons on it, and they get swizzled and spit back out. )At the very least, Workbench 1.4 should provide a dropshadow feature )comparable to the PD "Dropshadow 2.0" program. There are some technical problems with that: the extra bitplane sucks up some performance. I wrote DS, and I have some nice ideas as enhancements (fade away during recalculations, and hotkey pop up for the control window, as well as the "sundial" mode), and I wish that it could be used without speed penalty. It will probably be part of some standard release, as a demo for Commodities Exchange. In V1.4, you can specify a 1 bitplane WB (your icons will need swizzling), and use the shadows on that, with no penalty. I'd probably prefer the shadows to the colors, myself ;^) )If there ever is a "Workbench 2.0," I hope it will offer windows that )look like those on OSF/Motif, for example. Let's just say we have both short and long term plans to improve the appearance of things. The highest levels of Commodore management have publicly stated that the appearance of the screen has very high priority for improvement. jimm -- Jim Mackraz, I and I Computing "... the signs are very ominous, {cbmvax,well,oliveb}!amiga!jimm and a chill wind blows." - Justice Blackmun Opinions are my own. Comments are not to be taken as Commodore official policy.
langz@asylum.SF.CA.US (Lang Zerner) (08/30/89)
In article <4472@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: >)In article <16163@pasteur.Berkeley.EDU> johnhlee@cory.Berkeley.EDU (Vince Lee) writes: >)> ....the Amiga is a great machine, [but] what most people see is the >)> incredibly cheezy-looking workbench with its C64-looking icons. >)> When they compare this with the sleek, professional-looking Mac with >)> its sharp, crisp text and icons.... > >The highest levels of Commodore management have publicly stated that the >appearance of the screen has very high priority for improvement. The latest (Sep 89) issue of Computer Shopper magazine further suggests that relief is in sight: "[New Commodore President Harry] Copperman pitched professionalism and consistency to developers, saying that CATS should provide standards for things ike user interfaces and support, icons, requesters, and spiral-bound manuals, upon which developers could imprint unique characteristics as appropriate." [p. 563, col.1] While some developers griped about this attitude of standards of appearance, I have to say I wouldn't mind if there were some kind of guiding principle to the appearance of the elements on the screen. And as a software user, I like being able to adjust my shelf to a specific height and knowing that most software will fit nicely. [An aside: MS-DOS users already know about this, since their developers use the standard 5.5"x8.5" boxed binders. Of course, there are situations where it makes more sense to use a larger format. If the Commodore publications group is like most others I know, they'll put together a four-member "family" of page standards -- large and small page size with one- or two-column format in eachh size.] -- Be seeing you... --Lang Zerner langz@asylum.sf.ca.us UUCP:bionet!asylum!langz ARPA:langz@athena.mit.edu "...and every morning we had to go and LICK the road clean with our TONGUES!"
c162-de@zooey.Berkeley.EDU (Class Account) (09/02/89)
In response to the request for icon shrinkage, I have a little (I hope) to add. Having designed a WB replacement, I went to some trouble to get a range of views on what should be done about interlace rendering, etc. The problem is that many people have very differing opinions (gee, so when am I going to say anything useful anyway?). Some wanted to design dithering schemes to the interlace mode, some wanted dithering schemes to the non-interlaced mode, some wanted two separate icon images (I wonder what they will do with 1-bitplane, four images??), the list goes on. When I designed Jazzbench (well, when I wrote it -- I didn't actually design the thing...just kinda came together [mostly]) I decided to avoid the issue entirely. I'm now designing (yes, designing) Jazz 0.9, and am going to have enough hooks to add your favorite scruncher-decruncher-icon loader-window opens-etc. (I'm looking for somebody to make seamless operation on the IBM side as well...). At any rate, it seems to me the easiest way to resolve this is to use a callback function, and then supply a default "cruncher". That way people with 256K (gads!!), will still be able to run clock (and that's about it :-}), and people with lots of memory can have more features. In other words, there is no reason to build an architecturally closed user- interface on an architecturally open machine. 'nough said. David Navas c162-de@zooey.Berkeley.Edu Author of Jazzbench -- suggestions appreciated And that's all there was, cause there ain't no more