Fermitpu: by Lauri Loebel Carpenter (sort of). WHAT IS FERMITPU? And other items of interest. ---------------------------------------------- TPU is a programming language designed for writing editors. nu_tpu is a port by a/Soft Development Company of Digital's TPU to UNIX. It is good, but it has some fundamental differences in behavior from Digital's TPU. nu_tpu comes with two different editing interfaces: - SI, the Simple Interface, has an EDT-style keypad, and the EVE_ commands from some ancient version of EVE, but none of the underlying support EVE$ routines. (i.e., they reimplemented everything and put EVE_command wrappers around it). It is not suitable for anybody who wants to write EVE-style code (nor for anybody maintaining existing TPU code, such as their section file definitions). It is easily breakable if you do things involving more than one buffer (e.g., HELP or ambiguous commands). - EVE, which is a port of the EVE interface from VMS V5.4. This was an unstable version of EVE even on VMS, and it is more unstable under nu_tpu. They've done some strange things with it -- for example, file names are mixed case, but they've forced buffer names to be all UPPER CASE (i.e., the buffer name no longer matches the file name. Huh?!?!) It is easily broken, and it is NOT from a version of EVE which resembles the EVE that was current during the time at Fermilab when we were migrating en masse from VMS to UNIX. Therefore, I did my own port of the EVE from VMS V6.1 (the latest and greatest, as far as I can tell). NUMEROUS LITTLE THINGS NEEDED TO BE CHANGED, to work around the different behaviour in (or outright bugs in) nu_tpu, but all in all it seems to be a better choice for people who want a reliable and solid (and familiar) editing interface -- that is, folks who either: - have used EVE/TPU under VMS, and want an EVE/TPU under UNIX which strongly resembles the one they used before, - want something that looks an awful lot like EDT but isn't EDT. I've also added a few features that I believe to be quite handy. In particular, you can GET or INCLUDE filenames which contain environmental variables within fermitpu. That is, under SI and/or EVE, you would need to type explicitly: Do: get /home/dcdsv0/lauri/.profile but in fermitpu you can Do: get $HOME/.profile etc. This is *really* handy in lots of situations! It's not perfect, and never will be, but for those of us who are frozen into the EDT-style keypad of editing, and who like to write little macros to do repetative tasks, and can't find the time to learn how to do it in emacs (and can't abide vi or mouse-based editors), I hope this port is useful. FILES: ------ The $FERMITPU_DIR directory contains: - README, this file - bin, contains the fermitpu.sec section file - eve-VMS61, for reference, contains the original VMS 6.1 EVE source code - eve-help, the modified-for-nu_tpu online help from VMS 6.1 (corresponds to the EVE source code) - eve-source, contains the source code actually used to build fermitpu.sec (i.e., modified from the eve-VMS61 files) - ups, contains the ups product files INVERSE HISTORY OF FERMITPU --------------------------- v1_1c: (based on nu_tpu v5_0a) ----- Frank Nagy reports that he cannot use commands of the form DEFINE KEY=GOLD/X exit After much searching and winnowing, I can't seem to fix it. There is something funky going on in the synonyms module routines, probably in eve$$define_key_translation or eve$$define_key_modifiers, where the comment field of some special keys of the 'English' language keymaplist are not being made. It looks like the eve$$define_key_modifiers routine just barfs and dies, no error message. I think maybe its trying to access invalid or unpredictable memory locations with the optional SYNONYM_2 etc. parameters. But I just can't figure it out, and I don't have enough time to really dig around. So, instead -- DOCUMENT it as a known bug in the on-line help by editing the file eve-help/evehelp.hlb and the fermitpu man page. (29Aug97). v1_1b: (based on nu_tpu v5_0a) ----- Bug fix to file.tpu, procedure eve$$write_file. If you don't have WRITE permissions (AFS or regular) and you try to write a file, it doesn't get caught and you don't see the error message (and, EXIT will actually exit eventhough it couldn't write the file! ARGH!). Add features to the BUILD script and build.tpu to figure out where the section file is being built (nodename and operating system) so that we can track it. See the $FERMITPU_DIR/eve-source/fermitpu.list file for the name of the node and the operating system where the section file was built. Teach eve$set_paragraph_breaks (format.tpu) to understand that "---------" is a paragraph separator (it's the mail header separator; useful to be able to wrap the first paragraph in a mail message without leaving a blank line above it or screwing up the mail headers...). v1_1a: (based on nu_tpu v5_0a) ------ a/Soft gave us a new tpu image for OSF1, and compiling things works again on the OSF1 platform. That change was rolled into tpu v5_0a. Since fermitpu depends upon a specific release of tpu, a new release of fermitpu was required. The ONLY technical change in fermitpu v1_1a is to have the product dependency (i.e., ups/declare.dat file) changed to use tpu v5_0a. (And documentation, such as this file, noting that it is now OK to build section files on OSF1, yippee!). v1_1: (based on nu_tpu v5_0). ----- New release of nu_tpu, v5_0. It fixes many of the bugs in nu_tpu v4_1, but introduces some new ones. The SI interface is still primitive and easily broken. The EVE interface with nu_tpu v5_0 comes from VMS V5.4, still a downrev and not-robust version of EVE. So fermitpu is still necessary, sigh. Details on nu_tpu v5_0 can be found in the READ_ME file included with nu_tpu v5_0. I've gone through and removed *many* of the changes I needed to make in the previous release, because the underlying tpu bugs have been fixed. In particular: - lots of the keywords that I had to cludge (define as constants) are now known. - the map bug (TPU$_WINDNOTVIS errors when issuing a map command) seems to be gone. - range which includes text that a user is in the process of entering now grows with the user-entered text properly - nu_tpu now seems to be able to pass strings containing (or equal to) a null character without crashing or scribbling on memory - pre/post processing of keystrokes now appears to be trapped as on VMS, instead of on EVERY SINGLE KEYSTROKE However, some new sorts of bugs must have been introduced, and some new changes have been required. Look for "!lll" in the $FERMITPU_DIR/eve-source/*.tpu files for details. Specific bugs or differences in behavior, which do not seem to be covered by the differences listed in the $TPU_DIR/READ_ME file: - map occlusion: see $FERMITPU_DIR/eve-source/terminals.tpu for the details. Under VMS, a window whose bottom is occluded by a map(new_window, buf) command will automatically, AS PART OF THE MAP ATOM ITSELF, resize itself to be smaller so that the status line is moved upwards to just above the new_window starting point (and therefore be visible). This does NOT happen in nu_tpu -- the window status line merely remains occluded. This particularly affected the eve$map_choices routine, and caused very confusing display because there was no distinction between where the "real" buffer ended and the "choices" buffer began. Workaround: make the CHOICES buffer fill the entire available screen so that it occludes everything. - perhaps related, when windows are unmapped in nu_tpu, the now-not-occluded windows do NOT necessarily have their status lines updated automatically. This affects [at least] the screen display in [at least] the following situations: 1) when you exit the HELP facility 2) when you exit the CHOICES (ambiguous command or command arguments) facility Workaround: call fermi$fix_status_lines (new routine in fermi.tpu) to repair status lines after you unmap the help window or the choices window. - marker movement: see $FERMITPU_DIR/eve-source/help.tpu for the details. Moving to the beginning of a range, then creating a mark, then copying text (in OVERSTRIKE mode) at that point, causes the mark to move in nu_tpu. This is NOT the case in VMS. Workaround: some real cludgy (but functional) modifications to the eve$draw_keypad routine to force the editing position back to where it was supposed to be. (I suspect that this difference is at the heart of the problem with the BOX CUT/PASTE/SELECT/etc. routines, but I don't have the time to figure out how to fix it. I've merely disabled the BOX editing functions entirely.) - create_process and send do some *real* weird things, and provoke really screwy screen displays (and, usually, coredumps soon afterword). I've disabled the eve_shell (aka eve_dcl) commands. - OSF1 screw-up: There are definite bugs in the OSF1 implementation of nu_tpu itself. One serious bug (just one of many, but this is easy to demonstrate) is: procedure eve_doit message("how" + " " + "do" + " " + "I" + " " + "do" + " " + "this?"); endprocedure; On OSF1, this will compile but yield RUN-TIME errors: parameter 1's data type, UNSPECIFIED, unsupported -occurred in built-in MESSAGE On the other platforms (SunOS, IRIX, AIX) this will compile and run properly. Another way to provoke the OSF1 problems: try to build the fermitpu (or any other) section file via: $ set default $FERMITPU_DIR/eve-source $ build ! aka tpu -nodisp -nosec -noinit -command=./build.tpu fermitpu This aborts on OSF1, but functions properly on the other platforms. It appears that OSF1 machines can USE section files built on the other platforms, it just doesn't do the right thing when BUILDING section files itself. I have built the section files in use for fermitpu on SunOS, for the record. METHODOLOGY FOR INVOKING fermitpu has also been changed. Use a wrapper script to launch tpu. Use the environmental variable TPU_SECTION_FILE to point to the file which should be used as the section file. Let fermitpu set this environmental variable to point to its own section file. The tpu command still invokes the tpu product script. Note that in previous releases of fermitpu we used the $TPU_DEFAULTS_FILE mechanism. This is the name of a file containing lots of potential defaults, including the section file name, BUT it does not handle environmental variables! In the previous releases of fermitpu, I used the defaults file mechanism and relied upon making links in /usr/local/products/fermitpu. That is, $TPU_DEFAULTS_FILE pointed to $FERMITPU_DIR/lib/fermitpu.def which contained the line SECTION_FILE:/usr/local/products/fermitpu/v1_0/lib/fermitpu.ini: to point to the hard-coded section file. This is a pain in the butt to maintain, and prone to problems. Instead, I've changed the method of invoking tpu so that the TPU_SECTION_FILE variable IS used. (See the $TPU_DIR/bin/tpu wrapper script for details). I have kept the help files that were generated in the earlier version of fermitpu. (See the README file in the $FERMITPU_DIR/eve-help directory for details on how these help files were generated). v1_0: (based on nu_tpu v4_1) ----- Modify the online help to indicate that PARAGRAPH WRAP and BOX * (e.g., BOX CUT, BOX COPY, etc.), DO NOT WORK. Don't even think about trying to fix them. b1.1: (based on nu_tpu v4_1) ---- A few enhancements have been added: - EVEKEYPAD: the environmental variable EVEKEYPAD may be set to any supported keypad (EDT, VT100, WPS, EVE) to determine the startup keypad mapping. - hopefully, the screen repaint problem will not be so bad (many refresh statements were removed) - environmental variable expansion in filename for GET, GET_WILDCARDED, INCLUDE, WRITE, and @EVE-INIT-FILE. Users may now use environmental variables to reference files. b1.0: (based on nu_tpu v4_1) ---- The files in this directory are my attempt at porting EVE from VMS V6.1 to nu/tpu V4.1 running under unix. There are many subtle differences between nu/tpu and DECTPU, as well as differences between VMS and unix, which caused this to be a much more enormous project than I had originally anticipated. However, I believe that I have at least put together something that is in large part compatible with the EVE/DECTPU that was in use when the VMS->unix migration at Fermilab went into full swing. It certainly has helped make my life easier to have an editor that is so close to what I'm used to! The EVE source code was obtained from an alphastation running VMS V6.1. Many modifications were necessary to nearly all of the EVE modules in order to make it run as well as possible on an alphastation running OSF1 V3.2. The EVE source modules, along with the necessary master.fil, version.dat and build procedure are located in the ./eve-source subdirectory. The updated online help modules (massaged into nu/tpu syntax) are in the ./eve-help subdirectory. The section file and defaults file are moved to the ./lib subdirectory. The ./ups directory contains the locally necessary setup modules etc., man pages, etc.