xxiv Preface Date: Fri, 27 Feb 87 21:39:24 EST From: John Rose To: sun-users, systems Pros and Cons of Suns Well, I’ve got a spare minute here, because my Sun’s editor window evaporated in front of my eyes, taking with it a day’s worth of Emacs state. So, the question naturally arises, what’s good and bad about Suns? This is the fifth day I’ve used a Sun. Coincidentally, it’s also the fifth time my Emacs has given up the ghost. So I think I’m getting a feel for what’s good about Suns. One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven’t already. It’s inspiring to those of us whose LispMs take all morning to boot. Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to pro- ceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there’s a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you imme- diately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it’s fast! One reason Suns boot fast is that they boot less. When a LispM loads code into its memory, it loads a lot of debugging information too. For example, each function records the names of its arguments and local variables, the names of all macros expanded to produce its code, doc- umentation strings, and sometimes an interpreted definition, just for good measure. Oh, each function also remembers which file it was defined in. You have no idea how useful this is: there’s an editor command called “meta-point” that immediately transfers you to the source of any function, without breaking your stride. ANY function, not just one of a special predetermined set. Likewise, there’s a key that causes the calling sequence of a function to be displayed instantly.

The UNIX-HATERS History xxv Logged into a Sun for the last few days, my Meta-Point reflex has continued unabated, but it is completely frustrated. The program that I am working on has about 80 files. If I want to edit the code of a function Foo, I have to switch to a shell window and grep for named Foo in various files. Then I have to type in the name of the appropri- ate file. Then I have to correct my spelling error. Finally I have to search inside the file. What used to take five seconds now takes a minute or two. (But what’s an order of magnitude between friends?) By this time, I really want to see the Sun at its best, so I’m tempted to boot it a couple of times. There’s a wonderful Unix command called “strip,” with which you force programs to remove all their debugging information. Unix pro- grams (such as the Sun window system) are stripped as a matter of course, because all the debugging information takes up disk space and slows down the booting process. This means you can’t use the debugger on them. But that’s no loss have you seen the Unix debug- ger? Really. Did you know that all the standard Sun window applications (“tools”) are really one massive 3/4 megabyte binary? This allows the tools to share code (there’s a lot of code in there). Lisp Machines share code this way, too. Isn’t it nice that our workstations protect our memory investments by sharing code. None of the standard Sun window applications (“tools”) support Emacs. Unix applications cannot be patched either you must have the source so you can patch THAT, and then regenerate the applica- tion from the source. But I sure wanted my Sun’s mouse to talk to Emacs. So I got a cou- ple hundred lines of code (from GNU source) to compile, and link with the very same code that is shared by all the standard Sun win- dow applications (“tools”). Presto! Emacs gets mice! Just like the LispM I remember similar hacks to the LispM terminal program to make it work with Emacs. It took about 20 lines of Lisp code. (It also took less work than those aforementioned couple hundred lines of code, but what’s an order of magnitude between friends?) Ok, so I run my Emacs-with-mice program, happily mousing away. Pretty soon Emacs starts to say things like “Memory exhausted” and “Segmentation violation, core dumped.” The little Unix console is consoling itself with messages like “clntudp_create: out of memory.”