Peter Skinner wrote:Not everyone uses Winboard/Xboard _just_ with engines. I use Winboard as my everyday interface to FICS/ICC.
So I would like the event to happen regardless of an engine attached or not. I think others would like this as well.
Peter
This is not correct:
The timer is (re-)started every time XBoard sends a _move_ to the ICS. It does not matter if it is a move generated by an engine or a Human. But you have to play. If you login and then not play a single game in the first hour, and also not engage in any other activity for which the ICS would suspend your demise, the ICS would kick you out. And quite justifiably, so, I would think...
But anyway, I made the -keepAlive feature auto-starting now, and when there has been no input whatsoever from the ICS before the next date-ping, it triggers a fatal error and XBoard exits. For those wanting to try it: the sources can be obtained on-line as the latest snapshot from my git repository at:
Of course I have not been able to test it, although logging on to my own ICS and then disconnecting the network cable ofr that might actually provide such a test. (I am not sure what would time out faster; XBoard or the TCP connection.) But I don't want to do that when there are users logged on to my ICS...
An alternative would of course be to upgrade the low-level event-scheduling code to handle a list of events.
I would consider this a priority. In a gui application one should be able to create timers freely.
It might also expose bugs since some code might depend on timer events occuring in a particular order.
Well, my main aim is not to uncover bugs or improve the code. It is to add new features with the least possible effort. Reprogramming such low-level support functions is a very efficient way to introduce bugs, if not uncovering them, for no real benefit at all. Versions with refactored code are immediately suspect, and can ony be cleared through extensive testing. In our current release policy, they would not qualify as stable versions, and could not be released in the v4.4.x line. So unless absolutely necessary, I try to refrain from such activity.
for which autotools / automake should be installed. That should create the ./configure, which is really the only file not in the git snapshot (if I have understood Arun correctly).
I was missing automake & flex .. so I installed those (btw I believe the makefile does not detect a missing flex correctly - it was trying to execute "/missing" not "./missing"). But now I get:
gcc -o xboard backend.o book.o childio.o gamelist.o lists.o moves.o parser.o pgntags.o uci.o xboard.o xedittags.o engineoutput.o xengineoutput.o evalgraph.o xevalgraph.o xgamelist.o xhistory.o xoptions.o selfile.o draw.o path.o dir.o zippy.o -lm -lXaw -lXpm -lSM -lICE -lXmu -lX11 -lXt
xboard.o: In function `main':
xboard.c:(.text+0x35ac): multiple definition of `main'
parser.o:parser.c:(.text+0x0): first defined here
backend.o: In function `ParseBoard12':
backend.c:(.text+0x91fa): undefined reference to `currentMoveString'
backend.o: In function `ParseOneMove':
backend.c:(.text+0xae56): undefined reference to `yylexstr'
backend.c:(.text+0xaeba): undefined reference to `currentMoveString'
backend.c:(.text+0xaedb): undefined reference to `currentMoveString'
backend.c:(.text+0xaf0f): undefined reference to `currentMoveString'
backend.c:(.text+0xaf30): undefined reference to `currentMoveString'
backend.c:(.text+0xaf64): undefined reference to `currentMoveString'
backend.o:backend.c:(.text+0xb195): more undefined references to `currentMoveString' follow
backend.o: In function `ParseGameHistory':
backend.c:(.text+0x154e2): undefined reference to `yynewstr'
backend.c:(.text+0x154ee): undefined reference to `yyboardindex'
backend.c:(.text+0x154f3): undefined reference to `yylex'
backend.c:(.text+0x15524): undefined reference to `yy_text'
backend.c:(.text+0x15592): undefined reference to `currentMoveString'
backend.c:(.text+0x155b5): undefined reference to `currentMoveString'
backend.c:(.text+0x155f8): undefined reference to `currentMoveString'
backend.c:(.text+0x1561b): undefined reference to `currentMoveString'
backend.c:(.text+0x1565e): undefined reference to `currentMoveString'
backend.o:backend.c:(.text+0x15679): more undefined references to `currentMoveString' follow
backend.o: In function `ParseGameHistory':
backend.c:(.text+0x1573b): undefined reference to `yy_text'
backend.c:(.text+0x15763): undefined reference to `yy_text'
backend.c:(.text+0x157e7): undefined reference to `yy_text'
backend.c:(.text+0x1580f): undefined reference to `yy_text'
backend.c:(.text+0x1592f): undefined reference to `yy_text'
backend.o:backend.c:(.text+0x159a1): more undefined references to `yy_text' follow
backend.o: In function `ParseGameHistory':
backend.c:(.text+0x15bca): undefined reference to `currentMoveString'
backend.o: In function `LoadGameOneMove':
backend.c:(.text+0x1a917): undefined reference to `yyboardindex'
backend.c:(.text+0x1a94e): undefined reference to `yylex'
backend.c:(.text+0x1a98d): undefined reference to `yy_text'
backend.c:(.text+0x1a9aa): undefined reference to `yy_text'
backend.c:(.text+0x1a9e9): undefined reference to `yy_text'
backend.c:(.text+0x1a9f5): undefined reference to `currentMoveString'
backend.c:(.text+0x1aa0b): undefined reference to `currentMoveString'
backend.c:(.text+0x1aa2e): undefined reference to `currentMoveString'
backend.c:(.text+0x1aa71): undefined reference to `currentMoveString'
backend.c:(.text+0x1aa94): undefined reference to `currentMoveString'
backend.o:backend.c:(.text+0x1aad7): more undefined references to `currentMoveString' follow
backend.o: In function `LoadGameOneMove':
backend.c:(.text+0x1aaf4): undefined reference to `yy_text'
Hmm, it seems that your flex is not working as it should. All these undefined references should be in parser.c.
Now the snapshot should contain a ready-made parser.c for the benefit of WinBoard users that want to build with MSVC and do not have flex, in the winboard directory. So try
cp winboard/parser.c .
and then try to build again.
(Very nice how this forum software judges the mood of linker errors... )
Thanks, that did it. I was able to compile. I specified -keepAlive on the command line but the behavior is still the same. After a while I have no response from ICC. If I login under my human account and do "fi arasanx" it says it has disconnected. Very strange. I don't see any indication of the ping in the debug file - should I?
Well, the debug file shoud list the 'date' commands that are sent to ping the ICS, and the date string the ICS sent in reply.
What value did you use for the -keepAlive option? The patch I made will only conclude that the connection is dead when there is no reply on the Nth date command it sent by the time it is ready to send the (N+1)th. So if you would set it for 10 min, (-keepAlive 10), it could take between 10 and 20 min for it to detect the connection is broken.
If it does not exit when there is no message from the ICS between two 'date' pings, and XBoard did not exit, the patch is not working. So it would still be useful to see the debug file.
)