[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Problem using command files for rollouts.

From: Holger
Subject: Re: [Bug-gnubg] Problem using command files for rollouts.
Date: Tue, 25 Feb 2003 18:14:37 +0100

At 17:22 25.02.2003 +0100, Jim Segrave wrote:
On Tue 25 Feb 2003 (16:16 +0100), Holger wrote:
> At 00:12 25.02.2003 +0100, Jim Segrave wrote:
> >If we had a global that was set in gnubg.c:LoadCommands() to indicate
> >it was running a command file, then maybe the rollout command could
> >issue a "clicked" signal to the OK button for the Rollout window (of
> >course that part of the code would go in gtkgame.c, not rollout.c, but
> >rollout.c could call a function to conditionally clear the window if
> >we're running a command file.
> >
> >Do any gtk experts know if this is the right way to achieve this?
> I'm no expert, but will give my 2ct:
> I suppose it might help if outputresume() isn't called until the global
> flag isn't cleared. So if there are queued tasks and no errors no output is
> given, and only at the end of LoadCommands() outputresume() gets called.
> Maybe then the global could even be omitted.
> If the queued text might get too much, one could also think about writing
> all into a file.

I would have thought that if I were running a command file with a few
rollouts in it, I'd like to be able to see what sort of progress it
was making - an untruncated rollout of 6 moves can take a couple of
days even on a 2.4G machine with lots of memory. Personally, I'd want
to see how far it had got and be able to estimate how long it would
take to complete and what sort of results it was showing (if it's
rolled out 400 games and the STD of the results is down around .0015,
I might decide to stop it there, even if it meant editing my command
file to start with the next position, rather than run another several
hours of rolling out a position which I think is already clearly

OK, I see. And I have to admit that I've never done a rollout before.

I'm far from sure, but I guess outputpostpone() and outputresume() might still be used (probably with a check that GTK is used since TTY behaviour should be left as it is). I had a look at the various GTKRollout*() functions. They don't really use any output*(). In GTKRolloutUpdate() the rows are written using gtk_clist_set_text() which shouldn't be affected. So I guess the table with the current figures and progress should appear and be updated, actually everything that uses GTK features such as dialogues, lists and so on. But I can be wrong. I can't try anything right now as I don't have a compiler installed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]