results on Starting X Server - still stuck

[mdr@ctt.bellcore.com (Mike Rychener)]

This is a followup on my SLUG posting about troubles getting
an X server to do anything useful on my XL-400 under 8.0.1.
After following the advice given by the first two respondents,
the X server did in fact start up and display the client's
screens.  It blew up when I went further in the application
and started to display another window.

That one time is the only time I've been able to get the
server to work.  All other attempts before and since have
resulted in a message about unable to connect to server.
The exception is starting X screens from another Symbolics.
Actually, the one time anything happened was immediately after
such an exception.  Maybe that had something to do with it.

Any further hints would be appreciated.  I'm looking for ways
to work around this; bug fixes from Symbolics seem hightly
unlikely (see final reply fragment below).  I'll annotate a
couple of things below.  Many thanks to those who've already
responded.

> From: morse@virga.ucar.edu (Corinne Morse) Tue Oct  2 14:04:13 1990
> Subject: Re:  starting X server

> Did you also load system RPC and system Embedding Support?  This was required
> in order for our X stuff to work.  Actually I have only been able to get the
> normal Genera applications to work on the Sun and not our site-specific
> applications.  I have a message into Customer Support on that one but so far
> no response.  To get the application on the Sun I used Start X Screen sun-host 
> on the Symbolics.

> Cory Morse   morse@ncar.ucar.edu

OK, I tried it and it led to a success, but has not been
repeatable, so I'm not sure if it was really the crucial
ingredient.

- - - - -

> From: Barry Margolin <barmar@think.com> Tue, 2 Oct 90 15:01 EDT
> Subject: starting X server

> This happens if (ASSOC NIL FS:*DEFAULT-PATHNAME-DEFAULTS*) is (NIL).
> The C runtime initialization code expects the CDR of this to be the
> default default pathname.  It should be using a functional interface to
> pathname default merging, as the functions know how to handle this
> situation.  Send a bug report to Symbolics.

> A workaround should be to do (fs:set-default-pathname "some path")
> before doing "Start X Server".

> By the way, this error shouldn't happen at the time a client tries to
> connect, but when you do the "Start X Server".  The connection is only
> refused when the server isn't running.  I suspect that you tried the Sun
> client before it had finished initializing the window, and the Lispm
> client precisely when the window had finished initlizing and it was
> trying to initialize the software; at the point where it died, the
> server has initialized enough that connections are accepted, but it
> doesn't do anything with them.

>                                                barmar

OK, this was an easily fixed obstacle.  After it, the
initialization proceeded, and the one success occurred (I had
also done the load systems suggested above).  It doesn't seem
to be generally needed; the defaults were just messed up that
one time due to another program that I was working on.

There is a funny thing about a delay sometimes in proceeding
with initialization on starting the x server - as indicated
by loading fonts, etc. that show up on the status line at
bottom of screen.  Sometime the init. doesn't seem to happen
until a 'switch mode' is done.

- - - - -

> From: RUSHING@TITAN.KSC.NASA.GOV (Sam Rushing)

> We've been puzzled by the exact same problem - try logging in before
> starting the X server.  We've repeated the experiment several times,
> (starting with a freshly booted machine), and logging in seems to be
> the magic procedure.

> By the way, has anyone successfully X'd into a Symbolics from a PC? (gag)
> We've tried two commercial packages, XVIEW and XVISION (which run under
> Windows), with no success.

I don't find this to be an incantation that works for me.  But
maybe there's something in your lispm-init that has some
useful effect?  Details would be appreciated.  I tried, for
instance, reset network, to no avail.  I haven't tried it on a
freshly booted machine ... (if that's what's required, it's
not really workable anyway, for day-to-day use)  The one time
it worked was not on a freshly rebooted machine.

- - - - -

(following is in response to a bug that occurred during the
one time that I got the X server to function)

> From MUNOZ@yukon.scrc.symbolics.com Thu Oct  4 17:07:09 1990

> ... I don't expect to have individual
> fixes available for server issue; instead, our effort is in 
> preparing an R4 based server for Genera 8.1. 
 
>  - Rick

	Mike R.
	Bellcore
	Piscataway, NJ
	(908)699-7896
	mdr@ctt.bellcore.com