abair@oakhill.UUCP (Alan Bair) (08/03/88)
I am having problems running Emacs on the Apollo. I have previously built & updated Emacs for the Sun, so I know the steps to build the program. I decided to try it on our Apollo and went through all the steps and built it with no problems. However, when I try to run it, the problems start. I am using Emacs 18.51 with config.h having s-bsd-4.2.h & m-apollo.h. I made the few changes mentioned in the install notes, EXCEPT I used the -O flag on the C compiler (that may be my problem). The Apollo is an DN660 with 8MB real, but <20MB free disk space (swap space shortage mentioned in notes). I just upgraded to SR9.7 from SR9.2.3, is Emacs ready for that level, nothing mentioned in the install notes. As I said the build worked fine, no errors. Of course the Apollo cannot build a dumped version. So when I start it up, all the lisp code is loaded in and then it displays the normal introduction screen. Then things go down hill. I can enter a single command like C-x C-b, but it may take several minutes before it does anything. The next command I try just goes away, no response for >5 minutes. If I check cpu usage, its got >90%, looks like its looping. At this point I kill it from another window and give up. Any ideas, does it work for anyone else? Post or e-mail, I try to look at the net once a day. Alan Bair SPS CAD Austin, Texas Motorola, Inc. UUCP cs.utexas.edu!oakhill!turbinia!abair
jec@iuvax.cs.indiana.edu (James E. Conley) (08/03/88)
We are running GNU Emacs on our Apollo system and don't have the
poor response problems that you are having. I'm not sure what might cause
your problems, but you might try the version on the latest ADUS tape. We've
run that one and it ran at a reasonable speed (it is also pre-configured
for Apollos so there shouldn't be much that you can do wrong). You might
also check their parameters and compare them with yours.
III Usenet: iuvax!jec
UUU I UUU ARPANet: jec@iuvax.cs.indiana.edu
U I U Phone: (812) 335-7729
U I U U.S. Mail: Indiana University
U I U Dept. of Computer Science
UUUIUUU 021-E Lindley Hall
I Bloomington, IN. 47405
III (Home of Bob Knight and the Indiana Hoosiers)srt@aero.ARPA (Scott R. Turner) (08/04/88)
Do you have Zubkoff's fixes? If you don't, you should get them; they will improve your Emacs considerably. (Send me e-mail at srt@cs.ucla.edu and I'll send you the stuff if you haven't got it.) -- Scott Turner
Ram-Ashwin@cs.yale.edu (Ashwin Ram) (08/04/88)
In article <1410@turbinia.oakhill.UUCP>, abair@oakhill (Alan Bair) writes: > I am having problems running Emacs on the Apollo. [...] > I am using Emacs 18.51 with config.h having s-bsd-4.2.h & m-apollo.h. > [...] The Apollo > is an DN660 with 8MB real, but <20MB free disk space (swap space > shortage mentioned in notes). I just upgraded to SR9.7 from SR9.2.3, We are running GNU Emacs 18.48 on our Apollo DN3000's running SR 9.7 with no real problems. > As I said the build worked fine, no errors. Of course the Apollo > cannot build a dumped version. 18.48 was hacked by Leonard Zubkoff to allow dumping. He also added GPR support so that Emacs runs in a GPR window rather than under the vt100 emulator. Loadup and screen update is fast. > So when I start it up, all the lisp > code is loaded in and then it displays the normal introduction screen. > Then things go down hill. I can enter a single command like C-x C-b, > but it may take several minutes before it does anything. The next > command I try just goes away, no response for >5 minutes. If I check > cpu usage, its got >90%, looks like its looping. At this point I > kill it from another window and give up. If you're running it off another node on a ring of Apollos, the response time of the ring or of the remote node could be affecting the speed. I also found that file locking takes a long time due to the necessity of accessing remote lock files, and doesn't work correctly anyway since Emacs doesn't know about DM's own locks. I built a version without file locking and got a significant improvement in file operations (visiting files, verifying their modtime, etc.) Even before Zubkoff's version we didn't encounter any problems like the ones you mention with C-x C-b. You might try using the utilities in /systest/ssr_util (e.g., ringlog) or /com/dspst to try to figure out where the bottleneck is. -- Ashwin. ARPA: Ram-Ashwin@cs.yale.edu UUCP: {decvax,ucbvax,harvard,cmcl2,...}!yale!Ram-Ashwin BITNET: Ram@yalecs