reid@sask.UUCP (05/21/87)
I have the PD version of Terminfo/Curses by Pavel Curtis at Cornell
(cornell!pavel). I have the fix posted from ncoast (by Brandon Alberry, I
think) to work around problems with overflowing the C preprocessor, but this
didn't include any of the other Berkeleyectomies he said were necessary.
If anyone has made the package more system-independent, or has specific
fixes for Unix V7, I'd like to hear from you. Patches which can be applied
against the original mod.sources distribution would be just ducky, but
failing that even some good instructions would be appreciated.
I know, I know, I could hack it myself; I'm just too busy reading the
Net :-).
--
- !Baboo - (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid)
When I was a child I was an imaginary playmate.allbery@ncoast.UUCP (Brandon Allbery) (05/23/87)
As quoted from <730@sask.UUCP> by reid@sask.UUCP (I am NOT your Sweet Baboo): +--------------- | I have the PD version of Terminfo/Curses by Pavel Curtis at Cornell | (cornell!pavel). I have the fix posted from ncoast (by Brandon Alberry, I | think) to work around problems with overflowing the C preprocessor, but this | didn't include any of the other Berkeleyectomies he said were necessary. +--------------- I never got it working on ncoast when it was the R/S Mod 16 (when I posted the patches), I never got it working on ncoast-the-Plexus either. I finally gave up; the source is on tape somewhere. Basically, I got it to compile, but the "compile" command (aka Sys5 "tic") would always dump core and I could never find out why. compile -v9 gave me no useful information on what was going on; it would compile the first few entries, then get some garbage which I couldn't trace and explode. Suggestion #1: get System V. (Works fine at TDI.) BTW, sys5 terminfo looks suspiciously like Curtis's terminfo. (There's even a tstp.o (empty)!) Even more interesting is that the manual talks about job control.... Suggestion #2: try it with a real debugger. I have yet to get anything better than adb, which doesn't cut it. If you have sdb, you may have a chance; I'm waiting for Plexus to release sVr3 with the add-on compiler package (Green Hills compiler and cdb). Suggestion #3: throw out my preprocessor hack and use shortc. (At the time, it didn't exist.) Suggestion #4: the primary Berzerkeley fixes are to remove all references to the tstp() function, and ditto for the "struct ltchars". ++Brando -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. ---- Moderator for comp.sources.misc ---- Brandon S. Allbery {decvax,cbatt,cbosgd}!cwruecmp!ncoast!allbery Tridelta Industries {ames,mit-eddie,talcott}!necntc!ncoast!allbery 7350 Corporate Blvd. necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060 +01 216 255 1080 (also eddie.MIT.EDU)
rlk@chinet.UUCP (Richard Klappal) (05/24/87)
In article <2547@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >... >Basically, I got it to compile, but the "compile" command (aka Sys5 "tic") >would always dump core and I could never find out why. compile -v9 gave me >no useful information on what was going on; it would compile the first few >entries, then get some garbage which I couldn't trace and explode. >... In working on curses for my Fortune, I located that bug. I don't recall which file it was in, in the 'compile' files, but one of the tests for the need for a byte-swap is inverted. Search the code for 'needswap', (I think). The swapping action for one of them swaps when its not needed, and vice-versa, compared to all others. I don't understand the need for making the compiled files 'machine-independent' in this kind of file, unless someone intends to distribute only compiled data files, with no data sources. Thus, I am slowly in the process of re-working this set of libraries. When (if) I get finished, I will repost it (unless I am prevented by the copy-right. Will check with the legal-eagle.) I will attempt to isolate any machine dependencies, bu can't promise it given the V7/SYSIII/BSD2.?/BSD4.1 hybridicity of this machine. -- --- UUCP: ..!ihnp4!chinet!uklpl!rlk || MCIMail: rklappal || Compuserve: 74106,1021 ..!ihnp4!ihu1h!rlk ---
guy%gorodish@Sun.COM (Guy Harris) (05/24/87)
> BTW, sys5 terminfo looks suspiciously like Curtis's terminfo. As far as I know, it isn't. It's more like Mark Horton and others' terminfo (Tony Hansen's name is attached to a number of the pieces, and other names appear there as well - I guess what seems to be the AT&T corporate policy of anonymity for developers seems not to have been applied here). However, the S5R3 terminfo compiler *is* Curtis's terminfo compiler. If Curtis's terminfo was developed after Horton's, I suspect he deliberately tried to make the database format the same. > (There's even a tstp.o (empty)!) Even more interesting is that the > manual talks about job control.... Naah, not all that interesting. I believe Horton originally developed it under 4.1BSD, which does have job control. There are all sorts of bits floating in curses to support various flavors of UNIX. (One system the job control stuff *doesn't* support, BTW, is 4.2BSD; it still thinks that if you install a signal handler as the signal action with "signal", the signal action gets reset to SIG_DFL when the signal occurs.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.UUCP (05/27/87)
In article <2547@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >BTW, sys5 terminfo looks >suspiciously like Curtis's terminfo. (There's even a tstp.o (empty)!) Even >more interesting is that the manual talks about job control.... You should put that the other way around. Pavel implemented his public- domain version of terminfo after AT&T (actually Mark Horton) came out with theirs. There was undoubtedly input from Mark during this development. Job control is not at all strange, since terminfo curses evolved from termcap curses and presumably continues to be usable on 4BSD systems too.