[ggo-discussion] Re: possible bug on first time installation

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: