val@swamps.UUCP (val) (11/18/88)
I am wondering if anyone has modified the rn term.c for use with Microport SV/AT. Would someone be kind enough to mail me a copy? Thanks. -Val Christian ...rutgers!rochester!kodak!swamps!val ...killer!swamps!val -- -Val ...rutgers!rochester!kodak!swamps!val
rd@tarpit.UUCP (Bob Thrush) (11/20/88)
In article <102@swamps.UUCP> val@swamps.UUCP (val) writes: >I am wondering if anyone has modified the rn term.c for use with >Microport SV/AT. Would someone be kind enough to mail me a copy? >Thanks. > -Val Christian >...rutgers!rochester!kodak!swamps!val >...killer!swamps!val I am using V/AT 2.3.1 and found that the curses function `tgetstr' was not working correctly. Your mileage may vary with the 2.4 version. I discovered that the following patch would work around the curses problem: ------------ snip here ----------- *** term.c Fri Nov 21 17:39:32 1986 --- term.c.uport Sat Nov 19 23:28:06 1988 *************** *** 33,39 **** --- 33,45 ---- /* guarantee capability pointer != Nullch */ /* (I believe terminfo will ignore the &tmpaddr argument.) */ + #define MICROPORT_286_CURSES_BUG + + #ifdef MICROPORT_286_CURSES_BUG + #define Tgetstr(key) ((tmpstr = tgetstr(key,tcarea)) ? tmpstr : nullstr) + #else #define Tgetstr(key) ((tmpstr = tgetstr(key,&tmpaddr)) ? tmpstr : nullstr) + #endif MICROPORT_286_CURSES_BUG #ifdef PUSHBACK struct keymap { ------------ and here ----------- Hope this helps. -- Bob Thrush UUCP: {rtmvax,ucf-cs}!tarpit!rd Automation Intelligence, 1200 W. Colonial Drive, Orlando, Florida 32804
mem@zinn.MV.COM (Mark E. Mallett) (11/20/88)
In article <102@swamps.UUCP> val@swamps.UUCP (val) writes: >I am wondering if anyone has modified the rn term.c for use with >Microport SV/AT. Would someone be kind enough to mail me a copy? >Thanks. When I upgraded to 2.4 of System V/AT, I got segmentation violations out of term.c in rn. Because of the comments I'd read here about the new curses being buggy, I simply went back to the curses library from the previous release. Voila, no more segmentation errors. -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask me about MV.COM
stever@tree.UUCP (Steve Rudek) (11/22/88)
In article <405@zinn.MV.COM>, mem@zinn.MV.COM (Mark E. Mallett) writes: > In article <102@swamps.UUCP> val@swamps.UUCP (val) writes: > >I am wondering if anyone has modified the rn term.c for use with > > When I upgraded to 2.4 of System V/AT, I got segmentation violations > out of term.c in rn. Because of the comments I'd read here about > the new curses being buggy, I simply went back to the curses > library from the previous release. Voila, no more segmentation > errors. Can anyone here second that curses is the source of the errors? I compiled rn a week ago and was disappointed that it kept complaining about segmentation violation "signals" and, supposedly, coredumping. I say "supposedly" because I could never find a coredump anywhere. I didn't have the inclination to investigate the problem at the time so I just zooed things up and resolved to ask about it in this group. Does anyone have rn working under 2.4 *with* the 2.4 curses? I'd *really* rather not go back to 2.3 curses. In fact, I'd probably forego rn altogther (it is easier to forego something that you've never experienced) than use 2.3 curses. 2.3 curses was *incredibly* buggy.
karl@ddsw1.MCS.COM (Karl Denninger) (11/23/88)
In article <153@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >In article <405@zinn.MV.COM>, mem@zinn.MV.COM (Mark E. Mallett) writes: >> >> When I upgraded to 2.4 of System V/AT, I got segmentation violations >> out of term.c in rn. Because of the comments I'd read here about >> the new curses being buggy, I simply went back to the curses >> library from the previous release. Voila, no more segmentation >> errors. >Can anyone here second that curses is the source of the errors? I'd like some confirmation of that too.... or lack thereof. We've got AKCS, our conferencing package, compiled under the new 2.4 version, and didn't see _anything_ in the way of core-dump-on-init problems that others reported here. In fact, it seemed to work much better than the older, 2.3 version of the curses libraries... AKCS uses multiple windows on one screen (newwin()s) and lots of manipulation; I expected it to crash given the early reports. It hasn't been beaten up really well yet (we don't have 2.4, but one of our customers does and we built it there) but from what we can see here the early reports of curses-caused core dumps look like lots of smoke, but no fire. On the other hand, I haven't seen _any_ change in serial I/O behavior (at 9600 baud it still can't hack even a single incoming line w/o hardware assist of some kind). -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
rd@tarpit.UUCP (Bob Thrush) (11/25/88)
In article <2209@ddsw1.MCS.COM> karl@ddsw1.MCS.COM(Karl Denninger) writes: >In article <153@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >>In article <405@zinn.MV.COM>, mem@zinn.MV.COM (Mark E. Mallett) writes: >>> >>> When I upgraded to 2.4 of System V/AT, I got segmentation violations >>> out of term.c in rn. Because of the comments I'd read here about >>> the new curses being buggy, I simply went back to the curses >>> library from the previous release. Voila, no more segmentation >>> errors. >>Can anyone here second that curses is the source of the errors? > >I'd like some confirmation of that too.... or lack thereof. > Sounds very similar to the "tgetstr" problem with 2.2 and 2.3.1 curses is definitely a problem with the (same) large/libcurses.a that came with both Release 2.2 and 2.3.1(beta). "tgetstr" is broken in this library. In a previous posting <316@tarpit.UUCP>, I described the problem that I had with rn's "term.c" using the beta 2.3.1 release of V/AT. "tgetstr" should be used as: SYNOPSIS char * tgetstr(id, area) char *id, **area; However, tgetstr behaves as though area is defined as "char *area". My patch to "term.c" merely compensates for the error in tgetstr. Release 2.4 may have a correct "tgetstr" function. Has someone built rn successfully after installing 2.4? FYI, here are the details on the 2.[23] libcurses.a and tgetstr member from my system: ls -l /usr/lib/large/libcurses.a -r--r--r-- 1 root sys 207960 Apr 14 1988 /usr/lib/large/libcurses.a ar -tv /usr/lib/large/libcurses.a | fgrep tgetstr rw-rw-rw- 0/ 3 12370 Apr 13 20:15 1988 tgetstr.o And for good measure here is the previously mentioned patch to rn's term.c: ------------ snip here ----------- *** term.c Fri Nov 21 17:39:32 1986 --- term.c.uport Sat Nov 19 23:28:06 1988 *************** *** 33,39 **** --- 33,45 ---- /* guarantee capability pointer != Nullch */ /* (I believe terminfo will ignore the &tmpaddr argument.) */ + #define MICROPORT_286_CURSES_BUG + + #ifdef MICROPORT_286_CURSES_BUG + #define Tgetstr(key) ((tmpstr = tgetstr(key,tcarea)) ? tmpstr : nullstr) + #else #define Tgetstr(key) ((tmpstr = tgetstr(key,&tmpaddr)) ? tmpstr : nullstr) + #endif MICROPORT_286_CURSES_BUG #ifdef PUSHBACK struct keymap { ------------ and here ----------- >-- >Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) >Data: [+1 312 566-8912], Voice: [+1 312 566-8910] >Macro Computer Solutions, Inc. "Quality solutions at a fair price" BTW, did my previous postings <115@tarpit.UUCP> c. 11/4/88 and <316@tarpit.UUCP> c. 11/20/88 make it out to this newsgroup? (We had some problems earlier with an upstream feed). Please reply by email. Thanks. -- Bob Thrush UUCP: {rtmvax,ucf-cs}!tarpit!rd Automation Intelligence, 1200 W. Colonial Drive, Orlando, Florida 32804