Re: IO buffering problem

Yep, I think you're dead-on right. Thanks again.


On Fri, Mar 15, 2013 at 8:23 PM, Garthy D <
[e-mail]> wrote:

>
> Hi Andrew,
>
> 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.
>
> Cheers,
> Garth
>
>
> On 16/03/13 11:46, Andrew Wagner wrote:
>
>> 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.
>>
>>
>> On Fri, Mar 15, 2013 at 8:09 PM, Andrew Wagner <[e-mail]
>> <mailto:wagner.andrew@gmail.**com <[e-mail]>>> wrote:
>>
>>     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<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.
>>
>>
>>     On Fri, Mar 15, 2013 at 7:57 PM, Garthy D
>>     <garthy_lmkltybr@**entropicsoftware.com<[e-mail]>
>>     <mailto:garthy_lmkltybr@**entropicsoftware.com<[e-mail]>>>
>> wrote:
>>
>>         Hi Andrew,
>>
>>
>>         On 16/03/13 09:04, Andrew Wagner wrote:
>>
>>             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 <some move>" to my program, which responds with
>>             "move <my 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 `<main>'
>>
>>             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<http://www.gnu.org/software/__xboard/engine-intf.html>
>>
>>             <http://www.gnu.org/software/**xboard/engine-intf.html<http://www.gnu.org/software/xboard/engine-intf.html>>
>> . I'm
>>             running on
>>             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:
>>
>>         else
>>            $stderr.print "Unknown command: '#{command}'\n"
>>
>>         just before the second-last line. Are you handling every
>>         incoming command as it expects?
>>
>>         Incidentally, you could always turn those if statements into
>>         case/when, something like:
>>
>>         case command
>>         when /^protover/
>>         ...
>>         when /^usermove/
>>         ...
>>         else
>>            $stderr.print "Unknown command: '#{command}'\n"
>>         end
>>
>>         This might make it easier if there are a lot of commands you
>>         need to respond to.
>>
>>         Cheers,
>>         Garth
>>
>>
>>
>>
>
>