Xref: utzoo comp.sources.bugs:1982 rec.games.hack:5517
Path: utzoo!attcan!uunet!van-bc!tessera!jtc
From: jtc@tessera.uucp (J.T. Conklin)
Newsgroups: comp.sources.bugs,rec.games.hack
Subject: Re: Nethack 3 PL5 on SCO Xenix 286
Keywords: nethack,3,patchlevel 5,sco,xenix,286,termcap.c,core dump
Message-ID: <1989Oct22.045335.1363@tessera.uucp>
Date: 22 Oct 89 04:53:35 GMT
References: <6619@pt.cs.cmu.edu>
Reply-To: jtc@tessera.UUCP (J.T. Conklin)
Organization: Tesseract Communications, Burnaby, B.C., Canada
Lines: 29

In article <6619@pt.cs.cmu.edu> libove@ius3.ius.cs.cmu.edu (Jay Libove) writes:
>On SCO Xenix 286, at patchlevel 5, what used to be a nuisance is
>now a real problem:

>In termcap.c in delay_output() there needs to be a special
>case for #ifdef M_XENIX  /* do nothing */ rather than some
>kind of bogus attempt to waste time.

No there doesn't.  What is needed is to find out why the delay
code doesn't work on your machine.  The code works fine as-is
on my Xenix/286 system.

For starters, lets get the facts straight:
  + What version of the OS, and DS are you using?

  + Are you using termcap or terminfo?

  + What is the stack trace after the core dump?


I'm not trying to point a finger at Jay; but I think it is unreasonable to
assume we (the net at large) can debug programs without proper diagnostics.
"It doesn't work", or "It dumps core" is not much to go on.

    --jtc

-- 
J.T. Conklin
	...!{ubc-cs,uunet}!van-bc!tessera!jtc