			    Setup Problems
	$Id: PROBLEMS,v 1.3 1995/07/21 02:53:17 zappo Exp $

  Much of this file was written for etalk0.8, and updated for
etalk0.9.  The problems mentioned here result if you don't try to use
gtalkd as the daemon.

  I have seen different versions the "etalk-0.8" program compile
flawlessly on:

O Linux 0.99 and 1.72 and 1.2, GCC 2.4.5, 2.5.8 for OTALK, NTALK.
O IRIX 4.05h, GCC 2.x and cc, NTALK.
O IRIX 5.1.1.2 and 5.2, cc, NTALK.
O OSF1 v1.3 112 alpha, cc, NTALK.
O sunOS 4.1.3, cc (standard c), OTALK.
O HP-UX 8, cc, with no daemon, but mail worked ok.

  I have seen etalk0.9, gtalkd0.1, and xphone compile and run on:

O Linux 1.2.0, gcc 2.5.8 for OTALK, NTALK, GTALK

  I have seen gtalkd build on:

O IRIX 5.1.1.2 and 5.2, cc, NTALK.
O sunOS 4.1.3, cc (standard c), OTALK.
O HP-UX 8, cc, with no daemon, but mail worked ok.

  The results of a make check for the NTALK protocol can be found
int the etalk-t.out file.

  When building this program, there are several things which can go
wrong.  Primarily, I have found that talk daemons on different systems
can be very finicky about answering your queries.

  When etalk does not initially contact a daemon, the result is really
quite anticlimactic.  It doesn't blow up or anything quite so
satisfactory, it just does nothing.  The following have happened to me,
and I have tried my best to account for these problems.

  No talk daemon at all.

  HP-UX (at least the version I have used) let me build with no
problem, but had no talk capability.  Installation of the GNU talk
daemon will solve this problem.

  64 bit architecture.

  The alpha is the obvious culprit.  I have checks for this, but if
your system doesn't have 4byte ints, it still won't work. If
"protocols/talkd.h" exists, try using that instead of the talk.h that
comes with etalk.  If you still have problems, change the entries in
talk.h and otalk.h so that the id_num variable is SOMETHING that is 1)
an integer type number 2) 4bytes long.  Remeber that if you build and
install gtalkd, it will work locally because etalk and gtalkd use the
same header files.  You could be making your machine incompatible with
other boxes on the net, be sure to test against them as well.

  gethostbyname fails.

  For IRIX, when this program is built on IRIX4 (COFF objects) and run
on IRIX5 (ELF objects) gethostbyname gets all kinds of upset.  You must
have 2 binaries for the two platforms.  This can also effect emacs!  If
you use COFF emacs on IRIX5, you must change the variable
@var{etalk-local-host} to be your local system ip address before you can
even connect locally.  (You can use "127.0.0.1", but that breaks other
systems which can't parse the numbers, ACK)
@refill

  Announcements are sent, but person can't reply.

  If you and the person you are calling are on machines with different
daemons, etalk will happily make announcements.  If the other user
attempts to use normal talk, they will not be able to connect.  Both
sides MUST use etalk (or ytalk possibly) to make such a connection.
Etalk compiled with OTALK_ONLY can cause this as well, so make sure that
there is a hosts.talk file specifying the correct daemon type on both
sides. (See etalk-completion in the info file)

  Someone is logged on, but etalk always responds "Not Here". 

  Solution 1:
  This problem can occur when someone starts emacs on a machine to an X
display, and promptly logs out.  The result is that there is no TTY for
the daemon to write to.  The person can call you, but you can't call
them.  The solution resides in that individual using the "set ringer on"
command in thier etalk session.

  Solution 2:
  When using completion, it is possible to end up with something like:
"zappo@hal.gnu.ai.mit.edu ttyq" The problem here is that the tty
representation is incomplete because there are two posibilities.  Hit
TAB to choose the tty with the least idle time.

  Solution 3:
  When using completion, you can get a result like:
"zappo@gnu.ai.mit.edu ttyq1" As many know, the GNU finger daemon will
list me at the generic site, when I am actually logged into some other
machine. Use M-TAB to get a sub-listing, where a portion of the machine
that user is really on will be listed for you.  If users on systems like
this use the "set ringer on" command, then your requests will be
forwarded to the correct machine.

  Solution 4:
  If you spend much time in the completion buffer, you can get out-of
date listings of users.  Use C-r to clear up this problem periodically.

  Posibility 5:
  It could be that etalk built itself incorrectly.  Obvious problems are
all checked for by "make check", which include:

Message sizes: 
   The messages sizes are all verified each time etalk starts.
Daemon protocol type:
   The protocol is examined by the check target to verify correct
   responses.
Daemon byte order
   The byte order of sent addresses is tested by the check target.

  If the problem gets really hairy, and you are familiar with how the
talk protocol works, or would like to know, rebuild etalk with the
option: "--enable-TALKDTEST" to enable extra options.  Start etalk
from the command line, and use the commands LOOKUP, LEAVE, ANNOUNCE
etc to send specific messages to your daemon.  Set the verbosity as
well (a value of 2 gives more complete information).  This may help
you identify specific errors.

  An example series of commands may look like this:

  name zappo
  look zappo
  leave zappo
  look zappo
  dele invite
  ann zappo
  dele announce

  Be sure to replace zappo with your user name (of course).  This will
test each of the parts of the talk daemon services.  It is very
similar to the first bit of the "make check" rule, except you can
examine all this parts one at a time.  Don't forget that the talk
daemon will drop your invites and announcements after 30 seconds, so
you must be prompt!

Lisp Problems:

  "etalk-batch", or "etalk" for the first time in one session fails to
get socket ids or user ids.  I have implemented delays to accommodate
this, but it may still happen on other slower systems.  This can be
fixed by doing each part separately.

M-x load-library RET etalk RET
M-x etalk-start-one-process RET
M-x etalk RET

  As of etalk V 0.9B, this problem was solved for "etalk" command by
starting the process before the user types in a name.

  "It claims I am already talking to somebody."  

  This can occur when something is killed and the sentinel doesn't get
called right. If you are talking to people, return to the buffer which
was hung up and hit "C-c C-c" a second time just to make sure.  If you
have killed all buffers, the variable etalk-tcp-list needs to be
niled.  Do this with the command "M-x etalk-zorch-all-processes RET".

  "My first keystroke in tyrant mode does something weird" 

  This occurs with emacs 19.22 and 19.23.  I believe it may may occur in
earlier versions of 19 as well.  Emacs 19.24 has this problem fixed.
What happens is your first keystroke is sent to the previously displayed
buffer. To handle this, make sure anyone using these buggy versions of
emacs hits "C-h" first thing.  Mouse actions are not affected by
this.

  "My first keystroke after tyrant mode does something weird" 

  This appears to be a bug in emacs 19.27, but I havn't had time to
research it completely.  It is usually harmless, but if you just happen
to choose "C-cC-c" to hang up, the entire etalk session can hose itself.
I suggest caution.

  "Game buffers suddenly appear as remote's talk buffer." 

  Etalk depends on some amount of user kindness.  When playing a tyrant
game, do not switch back to the talk buffer and try to do anything.  The
result will de-synchronize the game buffers, and confuse the other
person to no end.  Tyrant mode tends to be very finicky, and is quite
dependent on synchonization.

  "While loading, etalk-x complains that hilit-translate is not bound."

  This is because hilit-translate is a macro, and when etalk is byte
compiled in batch mode it refuses to expand itself.  This file can be
left alone.  As of etalk-0.10, hilit19 tries to load itself, and
fails.  That prevents this file from being compiled at all.