[ggo-discussion] Re: A few newbee questions

  • From: Peter Strempel <pstrempel@xxxxxx>
  • To: ggo-discussion@xxxxxxxxxxxxx
  • Date: Sun, 5 Oct 2003 01:13:44 +0200

On Sun, Oct 05, 2003 at 12:13:04AM +0200, Steffen Dettmer wrote:

> I found GnuGo and from that, ggo as a nice client. I put gnugo
> into /usr/local/bin (PATH is including it), but ggo don't find
> it, no problem, I can set up the binary path at the properties
> dialog.

In theory gGo should find the "gnugo" command then. At least when you start
it from the bash where $PATH is defined. Maybe if you start it with an icon
from KDE/Gnome the $PATH is skipped, no idea. However, no big deal, as you
already wrote.


> Unfortunality, I don't know how to save the properties to
> a file or how to create a properties file (by $EDITOR). Is there
> a kind of example/template file?

I don't exactly understand what you want to do. gGo uses .properties files
for the translations, but they ship with gGo already, bundled into the .jar
file. No need for the end-user to edit these files. But I guess that's not
what you had in mind, but I dont know what you had in mind. :)

> Playing around with "Kogo's Joseki Dictionary" it seems that there may be
> some minor issues regarding displaying. During load, sometimes a
> "java.lang.OutOfMemoryError" occures in the .ggo.log (I think there is not
> much someone can do about JDKs memory management
> :(). Do I'm anything wrong? I use JDK-1.4.1.

The default maximum memory for the JVM is 64 MB, which is more than
sufficient to load and display Kogo. It might get critical if you try to
open Kogo several times in several windows, but that is quite unrealistic
anyways. You can tweak the JVM memory with commandline parameters to the
"java" command, check "man java". You would edit that in the "ggo" script in
/usr/local/bin.

Example:

echo Starting gGo...
$JAVA -jar /usr/local/gGo/lib/gGo.jar $@

Edit to:
$JAVA -Xmx128m -jar /usr/local/gGo/lib/gGo.jar $@

That would assign a maximum of 128 MB memory to the VM. However, I cannot
explain why your system chokes with the default 64 MB. Even with Kogo, which
sucks memory hard, 64 MB should be more than sufficient.


> I saw amazing 3D screen shots of glgo, unfortunality by SuSE 7.3
> system seems to much outdated to run it (e.g., just glibc 2.2
> instead of 2.3).

glGo is open source now, the latest release comes with sourcecode. You can
try to compile yourself. :) The automake scripts are still a mess, I am
trying to clean that up at the moment.
The new (and hopefully final) webpage for glGo is the old gGo project page at
sourceforge: http://ggo.sourceforge.net


> Is the development of ggo affected by this or will it continue?

gGo is currently quite dead. I cannot work on two clients on the same time.
I see glGo as a continuation of gGo, not as a really new client. My goal is
basically to port the Java version completely to C++. Of course that will
take much time. But I have no hurry. However, gGo 0.4 is pretty stable and
usable.

Maybe somebody wants to take over the gGo/Java development. But I simply
lack the time and motivation to work on both. And blunty said, I dont feel
obligated to work on any client at all. So if I dont want to, I dont do it. :)


Cheers,

 Peter

Other related posts: