Author: Rudolf Huber
Date: 00:11:22 02/27/01
Go up one level in this thread
You are guessing right. commands are sent in "lines" which are terminated by a \n character. So when you fgets() you have a normal string which one can analyze. I do token processing on this input line, not on stdin itself. >'If one command is not send its value should be interpreted >as it would not influence the search. ... should mean that if you do not get a *parameter* (for example with the go command) then do not use the value of that parameter of the last go command. Yes, the meaning of above sentence is unclear. Of course, it should not be necessary to figure out details by examining logfiles. Stefan will have to update this. Rudolf On February 26, 2001 at 14:09:08, Peter McKenzie wrote: >Thanks Rudolf, >You were right, the version of the spec that I was looking at had been converted >into HTML and had lost alot of formating information! The RTF version is much >better! > >I am still a little puzzled though. The text explaining the 'go' command says >this: > >* go >start calculating on the current position. There are a number of commands that >can follow this command, all will be sent in the same string. If one command is >not send its value should be interpreted as it would not influence the search. > >'all will be sent in the same string' - what exactly does that mean? Does it >mean that the following commands will be on the same line? Or does it just mean >that they will all be send at the same time? I mean, literally speaking, the >'same string' may include newline characters. > >And what denotes the end of this 'same string' ? > >I am guessing (because I don't believe it is possible to be sure from the above >explanation) that you mean that the sub-commands of the go command are all sent >on the same line!? > >If my guess is correct, then it is rather awkward for me because my input >processing is not line oriented at all. I use the C++ 'cin >> string' type of >input which just gives me the next token and strips out the whitespace >(including the newline). Oh well, I'm sure I can find a way around it. > >So the problem for me is that you seem to be using '\n' as a command terminator >for commands which have a variable number of arguments. This is a different >paradigm to the winboard way, I would say inferior even. I would prefer to have >a normal token denoting the end of a command sequence but I guess its too late >to change it now... > >Actually, I noticed this problem with your 'position' command where a sequence >of moves appear on the end of the line. I ended up using some messy logic to >handle that (check each string to see if it was a move, if it didn't then exit >my move input loop). > >Also, the sentence 'If one command is not send its value should be interpreted >as it would not influence the search.' does not make alot of sense to me. > >Sorry to complain alot, I could figure this stuff out by doing some more logging >etc but I don't see why I should have to :-) I think that if you make the spec >more clear, then more people will implement it! > >Regards, >Peter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.