Re: [Fresco-devel] Problem running the demo

Matty Noble wrote:
> When I run the server alone, it works as it should, closing upon request
> from the window manager.  When I run it with the demo (or when I run the
> demo separately with the server in the background), the server refuses to
> close, and the demo does nothing.

Our server's error recovery semantics are interesting to say the least. 
(I wouldn't want to go on record saying that they're totally busted.)

> Here's a log I generated:
> 
> $ berlin -l -R ior -e demo
[...]
> [1.49004:0:loader]	Server started.
> 
> WARNING: id might exist (TRANSIENT)
> 
> WARNING: Overwriting stale server-id [FrescoServer]
> [1.51397:0:corba]	Server location published.
> [1.51742:0:loader]	Starting client "democoServerh democoServerh (null)
> ERROR: Client could not get started.
> [1.5225:0:loader]	Running the ScreenManager now.
> [1.53983:0:focus]	0x80e5db8 receiving focus for 1

That "starting client" line looks unusual.

Would you mind telling us exactly which version of Fresco? The M1 
release, or a snapshot of CVS (from what date)?

> Can anyone help me with this?  I'm pretty good with C++, so if I can get a
> starting point I might be able to work it out on my own.

The "Client could not get started." looks like your problem right there. 
A few things to try:
* if this isn't M1 release, the demo isn't named "demo" anymore, rather 
fresco-demo. Please make certain it exists.
* run the server in one terminal and the demo in another to seperate the 
errors (may clean up that garbled "democoServerh" line)
* run the demo with "-R ior" like you do with the server.

> BTW, I'm compiling with G++ 2.95.2.1, and I had to make a bunch of changes
> to get it to compile, mainly with respect to G++'s pre-3.0 strstream
> wierdness, and also the absence of the push_back method for strings.  If
> anyone is interested in a patch, I think I managed to avoid doing anything
> destructive to the code, and I could provide one pretty easily.

We're moving away from supporting older compilers. I think we document a 
requirement for 2.95.4 or greater. We'd be interested in a patch only if 
it doesn't disrupt any other versions of compilers that we currently 
support, most importantly g++3.2.

Thanks,
Nick Lewycky