c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) (02/20/88)
I think this classifies as a flame, so beware. I love the Amiga, but I also loved the Apple II and wouldn't use one now. So here goes. * * * It takes 1 minute to copy a disk on the Apple II, if you include the 20 seconds to load the "fast copy" program. It takes 10 minutes to copy a disk on the Amiga. I wanted to back up a work disk and meanwhile draw some sprites in Dpaint. I was in the CLI and did a "run diskcopy". Diskcopy asked me to press return, but because it was being run in the background, didn't accept any input from my CLI. It did, however, change my disk names to "DF0:BUSY" and "DF1:BUSY", so that I couldn't access them. With 1 meg of stuff loaded in ram disk, I was forced to reboot the system. So I booted up my off-the-shelf Workbench 1.2, intending to copy from there, while running Dpaint. Unfortunately, upon inserting the target disk, the system just hung. Apparently my target disk had some soft errors (nothing wrong with the disk itself.) But that didn't matter - I was about to write over it! Reboot again. I picked a fresh disk. I ran Dpaint and then pushed the "screen to back" gadget, so I could do the disk copy. Uh oh - Dpaint closed the Workbench screen! Arrgh! So I booted a commercial copy program which effectively takes over the machine. So much for multitasking. I have been wondering lately what the "next" generation of user-interfaces will be like. Where can we go from here, now that the ideas of the Macintosh user interface have pretty much taken over? I think the next user interface will recognize and exploit patterns in your behavior, and additionally allow a natural language description of a command that may actually involve many programs. (Following paragraph will make Amiga owners feel good, if above story depressed them.) If you want to hear me flame on high, ask me how long it took me to do a global substituition of a carriage return for an asterisk on 37 Macintosh text files. On top of the fact that the Mac had no "*" for referring to all the files in the directory at once, MacWrite couldn't perform global substituition on a carriage return. The reason for all this? A workaround for a bug in Microsoft BASIC text file handling that I incurred in doing the workaround for another bug in Microsoft BASIC that prevented any writing to the LaserWriter, Apple's flagship printer. Neither bug is fixed in the latest versions.) Arrgh! I just screwed up this whole file because I held down "j" with caps lock on in VI. Future generations will laugh at late '80s claims of "ease of use". *&(Jonathan Dubman)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/20/88)
>Reboot again. I picked a fresh disk. I ran Dpaint and then pushed the >"screen to back" gadget, so I could do the disk copy. Uh oh - Dpaint >closed the Workbench screen! Arrgh! > >So I booted a commercial copy program which effectively takes over the >machine. So much for multitasking. Moral of the story: Do not attempt to copy disks while playing badly protected games. -Matt
agollum@engr.uky.edu (David Herron aka Admiral Gollum) (02/21/88)
In episode <887@pasteur.Berkeley.Edu>, we heard c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) say: >I was in the CLI and did a "run diskcopy". Diskcopy asked me to press >return, but because it was being run in the background, didn't accept any >input from my CLI. It did, however, change my disk names to "DF0:BUSY" and >"DF1:BUSY", so that I couldn't access them. With 1 meg of stuff loaded in >ram disk, I was forced to reboot the system. So what's wrong with "copy df0: to df1: all quiet"? Or, if you had workbench loaded, just drag the from disk onto the to disk and diskcopy starts up... Kenneth Herron
john13@garfield.UUCP (John Russell) (02/22/88)
>In episode <887@pasteur.Berkeley.Edu>, we >heard c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) say: > >>I was in the CLI and did a "run diskcopy". Diskcopy asked me to press >>return, but because it was being run in the background, didn't accept any >>input from my CLI. For programs that really need stdin and stdout to already be there, there's IsInteractive() <- although it's not publicized as much as it should be. For programs that need a stdin properly connected (eg not 'run' in the back- ground) there is a quick and easy way which I saw (here?) a couple of months ago. Perhaps the check code ought to be put into system programs that need it, and everyone be informed of its existence. Wish I could remember exactly what it was / who it was from! John -- "Fanaticism is all right... as long as you're ALONE! HAHAHAHA!" -- Pat Robertson shares a gem of wisdom told to him by Richard Nixon, and thus becomes the first politician to whom I can honestly apply the term "scares the willies out of me"
lphillips@lpami.van-bc.UUCP (Larry Phillips) (02/22/88)
really a line eater any more?> In <887@pasteur.Berkeley.Edu>, (Jonathan Dubman) writes: >It takes 1 minute to copy a disk on the Apple II, if you include the 20 >seconds to load the "fast copy" program. >It takes 10 minutes to copy a disk on the Amiga. Odd. It takes about 1.5 minutes on my Amiga. let's read on and see what the problem could be. >I was in the CLI and did a "run diskcopy". Diskcopy asked me to press >return, but because it was being run in the background, didn't accept any >input from my CLI. It did, however, change my disk names to "DF0:BUSY" and >"DF1:BUSY", so that I couldn't access them. Ahh... there's the culprit.. operator error. Well, I guess that won't happen again, right? > With 1 meg of stuff loaded in ram disk, I was forced to reboot the system. Compunded by an operator oversight. It always pays to have access to another CLI, whether from the NewCLI command or by having PopCLI active. >So I booted up my off-the-shelf Workbench 1.2, intending to copy from there, >while running Dpaint. Unfortunately, upon inserting the target disk, the >system just hung. Apparently my target disk had some soft errors (nothing >wrong with the disk itself.) But that didn't matter - I was about to >write over it! Hmmm... should have stuck with the CLI. :-) This is an area where flames are deserved. To allow a disk with any kind of error to hang the system or cause a GURU is inexcusable, especially so when you are about to completely rewrite it. >Reboot again. I picked a fresh disk. I ran Dpaint and then pushed the >"screen to back" gadget, so I could do the disk copy. Uh oh - Dpaint >closed the Workbench screen! Arrgh! Nothing to do with the Amiga of course. When a programmer does something you don't like, you can legitimately flame the programmer, provided of course that you have considered the problems that might happen if your wishes were followed. >So I booted a commercial copy program which effectively takes over the >machine. So much for multitasking. This is a choice made by the operator of the machine. >I think the next user interface will recognize and exploit patterns in your >behavior, and additionally allow a natural language description of a command >that may actually involve many programs. I think what you are wishing for here is a user interface that exploits patterns in _your_ behaviour. They already exploit patterns in _my_ behaviour. I (and many other Amiga owners) have no trouble adjusting to many of the program requirements that are necessitated by the multitasking nature of the machine, the way things have been implemented, programs that behave in particular ways, or even flaws in the system software. As with any tool that is more powerful than the tool you have previously used, there are cautions to be observed. Considering the power and complexity of the Amiga when compared to your last computer, it is rather amazing that it is as easy to use as it is. I can recall spending a very frustrating week attempting to install a serial card on an Apple IIe. I never did get it working properly, and to this day have no idea why not, except that perhaps a few months of experience might have made the job trivial. If there is a lesson here, it is that one should always get to know the tool, learn its strengths and weaknesses, and both exploit and be wary of its power. A power saw is a great improvement over a hand saw, but you can easily misuse it, causing more damage, more quickly, and perhaps causing you to look upon the new tool with a skewed perspective. > *&(Jonathan Dubman) Larry Phillips. -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+
dca@kesmai.COM (David C. Albrecht) (02/23/88)
> I wanted to back up a work disk and meanwhile draw some sprites in Dpaint. > I was in the CLI and did a "run diskcopy". Diskcopy asked me to press > return, but because it was being run in the background, didn't accept any > input from my CLI. It did, however, change my disk names to "DF0:BUSY" and > "DF1:BUSY", so that I couldn't access them. With 1 meg of stuff loaded in > ram disk, I was forced to reboot the system. > > *&(Jonathan Dubman) Personally I think Commodore should have issued some form of PopCLI with the workbench considering how small/simple/useful it is. It is a major improvement to the CLI environment and it's a bit silly to have new users have to ransack the public domain to get it. I can't really fault them for not including the ability to open a window in each of the various utilities accessable from the CLI, its extra space added for little purpose when Popcli will let you pop a new CLI any time you want. In your case, if you know beforehand that you were going to want another CLI, you should have typed 'newcli' to get another cli and then could have operated dpaint under one cli and your diskcopy under the other. David Albrecht
dpvc@ur-tut.UUCP (Davide P. Cervone) (03/01/88)
>>In episode <887@pasteur.Berkeley.Edu>, we >>heard c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) say: >> >>>I was in the CLI and did a "run diskcopy". Diskcopy asked me to press >>>return, but because it was being run in the background, didn't accept any >>>input from my CLI. How about using something like RUN DISKCOPY <CON:0/0/640/75/Diskcopy DF0: to DF1: (use your own favorite CON window). This would at least have the input come from a window where you could type stuff in. I don't know wither this would work: RUN DISKCOPY <* DF0: to DF1: but it might. Unfortunately, I don't know how to get a RUN program to use the SAME window for both input and output. Just a thought. Davide P. Cervone dpvc@tut.cc.rochester.edu
c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) (03/02/88)
>> I was in the CLI and did a "run diskcopy". Diskcopy asked me to press >> return, but because it was being run in the background, didn't accept any >> input from my CLI. It did, however, change my disk names to "DF0:BUSY" and >> "DF1:BUSY", so that I couldn't access them. With 1 meg of stuff loaded in >> ram disk, I was forced to reboot the system. >> >> *&(Jonathan Dubman) >I can't really fault them for not including the ability to open a window in >each of the various utilities accessable from the CLI, its extra space added >for little purpose when Popcli will let you pop a new CLI any time you want. >In your case, if you know beforehand that you were going to want another >CLI, you should have typed 'newcli' to get another cli... >David Albrecht Yes - I should have typed newcli, but I didn't, and my computer became useless. DiskCopy locked both of my drives so nothing else could access them, and it was waiting for a RETURN that it would never get because I can't send any characters to a task running as a result of the "run" command. I know how to get around these things, but new users will not. I suppose new users do not start background tasks from the CLI, so it is not such a problem. Moral of the story: Don't run things in the background if they may require input! I think there is a basic deficiency here: shouldn't tasks be forbidden from requesting input if run as a background task without redirected input? DiskCopy probably did a getchar() which is really an AmigaDOS read(), I think. Now the output file handle is inherited from the CLI when you run a task with the "run" command; what is the input file handle? (I suppose this depends on the startup code...) Any ideas on any of this? *&(Jonathan Dubman)
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/03/88)
In article <1150@pasteur.Berkeley.Edu> (Jonathan Dubman) writes: >I think there is a basic deficiency here: shouldn't tasks be forbidden from >requesting input if run as a background task without redirected input? >DiskCopy probably did a getchar() which is really an AmigaDOS read(), I think. >Now the output file handle is inherited from the CLI when you run a task >with the "run" command; what is the input file handle? (I suppose this >depends on the startup code...) Yes and no, (on the deficiency that is). First off, there is a DOS call IsInteractive() which is pretty analagous to the UNIX isatty() call. If that returned FALSE you probably want to abort the diskcopy *or* have diskcopy open a new window where the I/O should go. On a side comment on the original problem : A) Deluxe Paint II has a menu option to turn the workbench back 'on' (it reopens it). B) Neither Deluxe Paint I or Deluxe Paint II can close the workbench if there is an open CLI on it so 'running' DPaint from a CLI will keep the WB there and you can pop back to it to do what ever you chose (and have memory for). The example of Deluxe Paint is a bad one since here is a program that is *desperate* for chip memory. Closing the workbench can help there, especially on small memory machines, and since the way to get the workbench back is clearly documented I don't understand why all the frustration. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
cthulhu@athena.mit.edu (Jim Reich) (03/05/88)
In article <43849@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <1150@pasteur.Berkeley.Edu> (Jonathan Dubman) writes: >>I think there is a basic deficiency here: shouldn't tasks be forbidden from >>requesting input if run as a background task without redirected input? No, they shouldn't be forbidden. The best way I know to handle this is the way UNIX (or at least the cshell) does -- suspend interactive processes and warn the user. That way, they can be brought into the foreground with a command such as 'fg' and can resume once they're interactive... >Yes and no, (on the deficiency that is). First off, there is a DOS call >IsInteractive() which is pretty analagous to the UNIX isatty() call. >If that returned FALSE you probably want to abort the diskcopy *or* >have diskcopy open a new window where the I/O should go. Or suspend it. Hmm, sounds like a yet another feasible, useful, neat project which I don't have time for. I wonder, how much modification would it take to the CLI to allow ANOTHER CLI to take over such a process and make it interactive in another window (as in "OOPS. Put diskcopy in the background. What can I do? I know, I'll pop up another CLI, look up the ID of the evil diskcopy and then fg it in the other CLI." Any takers for this project? Perhaps the next version of Matt's shell? -- Jim