All,
I’m writing a chess program that has a simple text-based interface. It’s
designed to be run by another program, which has a nice UI. Here’s the
program as it stands now, whittled to the simplest possible use case:
i = 0
moves = [“a7a6”,“a6a5”,“a5a4”,“a4a3”]
$stdin.each do |command|
if command.start_with?(“protover”)
$stdout.puts “feature ping=0 setboard=1 ics=1 usermove=1”
elsif command.start_with?(“usermove”)
$stdout.puts “move #{moves[i]}”
i+=1
end
$stdout.flush
end
The “protover” thing is needed to tell the UI program how to initialize
the
protocol, and then every time a move is made, the UI program sends
“usermove ” to my program, which responds with “move ”.
If I run this by itself, I can happily enter a few ‘usermove’ commands
manually, and get any number of canned moves back. However, when I run
this
under the UI, I get an Interrupt:
bin/winboard.rb:3:in each': Interrupt from bin/winboard.rb:3:in ’
I know that the UI program is pretty reliable, so I’m missing something
in
the way that I’m handling IO buffering or something. If you want the
nitty
gritty details, you can see them at http://www.gnu.org/software/xboard/engine-intf.html . I’m running on
MacOSX. Any suggestions?
elsif command.start_with?(“usermove”)
If I run this by itself, I can happily enter a few ‘usermove’ commands
MacOSX. Any suggestions?
Is it possible that you aren’t processing one of the commands from the
program, and the program is terminating your script, perhaps after a
timeout or incorrect response? I’m wondering what would show up if you
added this:
Thanks for the response. I really don’t have to handle every incoming
response. I put in the line you suggested, and it did indeed identify a
number of commands that are “unknown”. But that’s ok, as far as I can
tell.
As for “if” vs. “case”, in my real program, I did something even more
general: https://github.com/arwagner/tdchess/blob/master/lib/tdchess/runner.rb .
This lets you plug in any command handlers you want. I plan on having a
library of handlers for different commands, maybe a nice DSL or
something
for creating new ones, etc. Obviously, I shortened all of that to
isolate
this problem.
Happy to be able to help, even if only indirectly.
Also check out “trap” (“Signal.trap”) if you can usefully catch and use
those SIGINTs. Perhaps they’re tied to certain commands like “force” in
the protocol in case you need to stop “thinking” on a move? That’s a
wild guess based on a two-minute reading of the protocol though.
Ha, I fixed it. You were almost right, Garthy, the UI was
seemingly-randomly sending me SIGINTs. I had to tell it in the protocol
initializer not to do that. Very odd.
