NCSA Cray/Sun Distributed EMACS In this directory: 1) ctool.sh source for the Sun part 2) ue*.sh source for the Cray part These are both shar files (shell archive). To extract the actual source files copy the *.sh files to a unix machine. Make directories uemacs/Sun and uemacs/Cray. While in the directory uemacs/Sun, enter "sh ctool.sh" to extract the source of the Sunview program. This also unpacks a file named ".craymacros", which is hidden. This can be edited to taste and placed in your home directory. To compile, type "make". The executable "craytool" is invoked as "craytool telnet ncsad". You may wish to define an alias: cray craytool telnet ncsad -Wp 0 0 Telnet must have been modified (echo character = ^P) in order to be able to change suffixes on the cray and to have normal operation of the command line editor/macro facilities (no echoing). You will not need the ue*.sh files if you are using the NCSA Cray, as the necessary files (uemacs and uehelp) are in public. They can be extracted as above. The files uecomp and uelink are used to compile the program. Note for Sun3/110C Performance is better on the black & white screen. You can start a second (b&w) suntools session by entering suntools -d /dev/bwtwo0 -toggle_enable -n & adjacentscreens -c /dev/fb -l /dev/bwtwo0 from a shell window. Then move the mouse off the screen to the left. Notes on porting the Cray half: Except for a few shortened file names, all of the changes from standard MicroEMACS 3.8b are ifdef'd by the macros CRAY and TCPIP. These and other configuration switches are set in estruc.h. Both switches MUST be set. The non-TCPIP code is for a version that operated in an entirely different manner. The most likely ports will be to 1) Unicos Crays. 2) CTSS Crays using a different ipc system. This implementation uses the Livermore hybrid C compiler (hcc), for which the libraries are very weak. To correct one of the weakest areas, Steve Dorner's double buffered file io routines are substituted (see io.c, fileio.c, and related files). Communication is done directly at the level of sockets, using tcplib (an in-house NCSA product). On a Unix Cray these ipc calls (in termio.c) should be replaced by normal internet socket calls. This change and possibly removing the file io stuff are probably the only changes required (apart from any improvements you may wish to make). The type of distribution used (keeping the bulk of the editor on the mainframe instead of distributing at the file io end) is probably more suitable for the Cray 2 than the XMP. On a heavily loaded XMP there are annoying delays when the process is swapped out. The executable is quite small (~80kwords with hcc, roughly half that with the Cray C 1.0 compiler) and the swapping problem should disappear on the Cray 2. In anticipation of the Cray 2 I did not distribute the editor at the file io end. As it is it is rougly as network efficient as fred, but can't handle huge files because it will load the whole file into memory (on the Cray) and hence add to the swapping problems. On the plus side, actively using the editor will tend to prevent the process from being swapped out. I think it is possible to distribute MicroEMACS at the file end, even though most of the code is written assuming the whole file is in memory. The strategy that I would try would be to replace the macros lforw, lback, etc (in estruc.h) with function calls that check for the line in local memory and, on failing, request a block from a simple editing file server on the Cray. The Cray end in this case would, in addition to handling block read/write requests, perform global functions such as "replace string". However, in order to avoid having the whole file sent over the net when a keyboard macro (for example) is executed on every line, the remote server would also have to agree with the user interface on macro syntax. The final result will be an editor with rather complicated modules on both ends, or no support for such nice features. This is why I favor making the break at the display interface, as the workstation module in this case needs to know nothing of emacs. It this initial version there is a small amount of "emacs knowledge" in the user interface (to determine which characters need to be sent immediately in C-mode, for instance). This could be corrected by having the remote module send an editor-independent "update state" sequence, including a list of characters that must be immediate. Such a scheme would make it possible to port another editor (such as vi) almost directly to the Cray and have it work with the same workstation module. Porting to different workstations: The Sun part is notifier based. It was to take advantage of the notifier facilities that Sunview was used. Unfortunately, this makes porting harder. Xwindow may also provide such facilities. If so, that may be a fairly easy port. Otherwise I would recommend writing a simple notifier (catch signals on active descriptors, store them tagged by type, and invoke the appropriate handler when it's safe to do so). This reduces writing the craytool program to the task of determining what action should be taken for each event type (which is all the Sun version does). A simple version for generic unix shouldn't be too difficult.