[ggo-discussion] Re: possible bug on first time installation
- From: Peter Strempel <zotan@xxxxxx>
- To: ggo-discussion@xxxxxxxxxxxxx
- Date: Sat, 11 Jan 2003 07:41:18 +0100
Try starting gGo with:
java -jar gGo.jar -noserver -keepstderr
java -jar gGo.jar -keepstderr
java -jar gGo.jar -noserver
'java -jar gGo.jar -help' lists all commandline options
I don't know which installer you used, the "ggo" script that comes with the
RPM and the .jar installer basically only do "java -jar /path/to/gGo.jar",
you can add commandline options there, too. If you used the (crappy)
InstallAnywhere installer, commandline options will not work. But that
InstallAnywhere thing is mainly targeted for Windows users who have
absolutely no clue about computers - no offense intented, but many Go
players are no computer experts. And Java on Windows *is* a mess.
The above will disable the redirection to the logfile and the server
running on localhost which is used to reconnect a second gGo instance to
the first instance so only one VM is used. Useful if you open several sgf
files from a webbrowser when you use gGo as standard sgf viewer.
Please try and check if either the noserver or the keepstderr option fix
your problem. I'd like to know what exactly causes the failure on your
system. So far I have not recieved such a bugreport yet, so I assume it
works for most people, however the problem you encounter might appear for
someone else, so it cannot hurt I fix it. :)
The execution order is as follows:
* Read .ggorc file (that comes very very first of everything, not much
interesting going on before that)
* Apply themes and skins (does not apply if you use default settings, as
that uses the Java default look and feel)
* Open a port on localhost 9999
* Redirect stderr to logfile
* Create GUI
If we assume the missing config file does not cause your problem (and I
would really wonder if it does), the remaining reasons should be the
localhost port and the stderr redirection. You can disable both or one of
them with the above mentioned commandline options, so if you can fix your
problem with one of those options, we should have identified the reason.
The debugging stuff you mentioned doesn't mean much to me, but of the
above, only the localhost port runs in an own thread, so this might be a
hint.
Thanks for your help!
Peter
Other related posts:
