pa1343@sdcc15.ucsd.edu (pa1343) (02/05/89)
I wish to compile GNU-Emacs on a System V AT&T 3b20. Do I need a lisp compiler to do this? If so, is there any pd versions of lisp which would work? -- +------------------------------------------------------------------------------+ | John J. Marco -- pa1343@sdcc15.ucsd.edu | | ...!uunet!ucsd!sdcc15!pa1343 | +------------------------------------------------------------------------------+
wang@wpi.wpi.edu (William S. Ang) (02/07/89)
In article <1034@sdcc15.ucsd.edu> pa1343@sdcc15.ucsd.edu (pa1343) writes: >I wish to compile GNU-Emacs on a System V AT&T 3b20. Do I need a lisp compiler >to do this? If so, is there any pd versions of lisp which would work? > >-- >+------------------------------------------------------------------------------+ >| John J. Marco -- pa1343@sdcc15.ucsd.edu | >| ...!uunet!ucsd!sdcc15!pa1343 | >+------------------------------------------------------------------------------+ You don't need a Lisp compiler. GNU-Emacs comes with its lisp compiler in C code. As long as you have a decent C compiler, GNU-Emacs should compile with no problem. I installed GNU-Emacs on ATT 3B15 last summer. If you have any intallation problem, you can send mail directly to me. William Ang wang@wpi.wpi.edu CSNet wang@wpi.bitnet BITNET
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (02/07/89)
In article <1034@sdcc15.ucsd.edu> pa1343@sdcc15.ucsd.edu (pa1343) writes:
I wish to compile GNU-Emacs on a System V AT&T 3b20. Do I need a
lisp compiler to do this? If so, is there any pd versions of lisp
which would work?
When you get GNU Emacs, you get the source to everything you need. If
you want to think of it this way, you get both a lisp interpreter and
a huge pile of code that implements a user environment (that sometimes
behaves like a text editor :-).
But you can even ignore the fact that there's Lisp involved if you
want to. After the distribution is configured correctly, just say
"make" and away it goes.karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (02/10/89)
ron@ron.rutgers.edu (Ron Natalie) writes:
First, make sure that you
have the Sys5 R3 on [3b20s]. Any previous versions have hideous
bugs in VMIN/VTIME support that cause egregious workarounds and
sudden unexplained EMACS hangs.
Not quite true; Rel2.2 took care of these sorts of problems. GNU
Emacs has been compiling routinely on such machines since about 18.36.
No workarounds weirder than usual for SysV were necessary.
--Karlfrk@frksyv.UUCP (Frank Korzeniewski) (02/11/89)
In article <KARL.89Feb10082648@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >ron@ron.rutgers.edu (Ron Natalie) writes: > First, make sure that you > have the Sys5 R3 on [3b20s]. Any previous versions have hideous > bugs in VMIN/VTIME support that cause egregious workarounds and > sudden unexplained EMACS hangs. > >Not quite true; Rel2.2 took care of these sorts of problems. GNU >Emacs has been compiling routinely on such machines since about 18.36. >No workarounds weirder than usual for SysV were necessary. > >--Karl I beg to differ (actually I'll just differ anyway). I built 18.52 on SYS V/386 and re-worked it to emulate WordStar keys. Control-G was then the delete forward character. On using emacs, it would occasionaly die when I typed multiple control-g's. It seems that emacs uses the termio stuff to set control-g as generating SIGQUIT and SIGINTR. If you type a second control-g when the process is still paged out, SYS V then kills it. I had to map the DEL key to SIGQUIT and SIGINTR in order to make emacs useable. Frank -- ______________________________________________________________________________ || Frank Korzeniewski, Consulting Suite 137 || || Phone: (415) 799-1819 1564-A Fitzgerald Drive || || UUCP: uunet!frksyv!frk Pinole, CA 94564 ||
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (02/13/89)
frk@frksyv.UUCP (Frank Korzeniewski) writes: >[I said:] >Not quite true; Rel2.2 [on 3b20s] took care of [termio] problems. GNU >Emacs has been compiling routinely on such machines since about 18.36. >No workarounds weirder than usual for SysV were necessary. I beg to differ (actually I'll just differ anyway). I built 18.52 on SYS V/386 and re-worked it to emulate WordStar keys. Control-G was then the delete forward character. On using emacs, it would occasionaly die when I typed multiple control-g's. First, I was refering to 3b20s, which is where Ron was noting having had problems due to termio bugs. I persist that Rel2.2 for the 3b20 (!= Rel2.2 for any other CPU) cleared up these problems, and I'll ask any GNU Emacs users on cbrme.att.com to let me know if they are aware of any problems remaining. It seems that emacs uses the termio stuff to set control-g as generating SIGQUIT and SIGINTR. If you type a second control-g when the process is still paged out, SYS V then kills it. I had to map the DEL key to SIGQUIT and SIGINTR in order to make emacs useable. The problem is not at all a bug in how termio operates, but rather in unreliable SysVRel2 signals in combination with your PC's slow disc. In SysVRel2 and previous (dating all the way back into prehistory), the delivery of a signal to a process causes that process' handler for that signal to be reset to SIG_DFL. Thus, the process is momentarily susceptible to the signal in question. If a 2nd such signal arrives before the process has been allowed to run the handler, which would (one presumes) re-assert the handler definition, the process will die. Hence, the problem is that you can type ^Gs faster than your disc can page in. Now, that speaks volumes, yes?
frk@frksyv.UUCP (Frank Korzeniewski) (02/14/89)
In article <KARL.89Feb13084347@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: |frk@frksyv.UUCP (Frank Korzeniewski) writes: | >[Karl said:] | >Not quite true; Rel2.2 [on 3b20s] took care of [termio] problems. GNU | >Emacs has been compiling routinely on such machines since about 18.36. | >No workarounds weirder than usual for SysV were necessary. | | [ I described problem with emacs 18.52 and control-g ] | |The problem is not at all a bug in how termio operates, but rather in |unreliable SysVRel2 signals in combination with your PC's slow disc. | |Hence, the problem is that you can type ^Gs faster than your disc can |page in. | |Now, that speaks volumes, yes? Maybe I am missing something here. Please correct me if so. I am running Microport SYS V/386 Rel3.0 on a PRIAM 330 MB drive with a 16 ms access time. I am the only user on this system. Given these circumstances it would appear to me that anyone running emacs on SYSV is susceptible to having it killed accidentily. I agree that the problem is the poor semantics associated with the 'signal' call. However, there exist better signal handling capabilities with the 'sigset' et al routines. These should probably be used by emacs. The intent of my posting was not to imply that there was a bug in the 'termio' facilities. I am sorry about the ambiguity in my prior posting. Frank -- ______________________________________________________________________________ || Frank Korzeniewski, Consulting Suite 137 || || Phone: (415) 799-1819 1564-A Fitzgerald Drive || || UUCP: uunet!frksyv!frk Pinole, CA 94564 ||