Van: J. Wesley Cleveland [mailto:j.wesley.clevel...@gmail.com]
Verzonden: di 16-11-2010 04:47
Hi,
> From: Alexander Wagner <a.wag...@physik.uni-wuerzburg.de>
>>
>> On 11/15/10 00:11, Joost 't Hart wrote:
>>
>> Hi!
>>
>> >> 3. Capture the output from stderr also. Stockfish writes to stderr on
>> >> an error exit, but the message vanishes because there is no console
>> >> window.
>> >
>> > Hm, I like what you say but this could mean quite some work, as Scid is
>> > used to parse the stuff coming from the engine. So we would need to add
>> > the notion that something that cannot be understood should be sent in
>> > raw format to the engine window?
>>
>> I'd be pretty careful here and crosscheck what UCI definition says about
>> stderr. AFAIK it is not used and therefore one can't expect anything
>> decent on that channel. In other words: we would not want to handle very
>> other engine separately cause the programmer doesn't follow the
>> standards. More likely than parsing this and that unstructured output
>> I'd raise a bug report @ stockfish. ;)
>>
> My thought was more that if an engine exits unexpectedly, scid would
> get the return code and any messages in stderr and display them in a
> dialog box. The uci spec says nothing about errors (except copy
> protection errors), so there is no standard way to return errors,
> though putting a message to stderr is common. Here is some code from
> http://stackoverflow.com/questions/1621166/tk-tcl-exec-stderr-stdout-separately
> that appears to do what is needed. I am not a good enough tcl
> programmer to say if it could be easily adapted.
Assuming that "the engine" indeed behaves as the "command" below, this would
not be too difficult to handle. I am happy that you do not propose to make the
pipe between engine and scid a multiplex of the engine's stdout and stderr.
This would be really crazy to handle for scid.
What makes the scenario a bit awkward is that it is pretty hard to make Scid
aware that the engine actually could have crashed. Your "scid application"
simply stops "command" and checks its exit code. Why would Scid ever
want to do that, except when it is the user who closes the engine window?
Could be done on a timeout basis, but this is inherently risky. Maybe do it
only if the user stops the engine window? Yet would this be of any help?
>
> set data {here is some data}
> set command {sh -c {
> echo "to stdout"
> read line
> echo "$line"
> echo >&2 "to stderr"
> exit 42
> }}
> set pipe [open "| $command" w+]
> puts $pipe $data
> flush $pipe
> set standard_output [read -nonewline $pipe]
> set exit_status 0
> if {[catch {close $pipe} standard_error] != 0} {
> global errorCode
> if {"CHILDSTATUS" == [lindex $errorCode 0]} {
> set exit_status [lindex $errorCode 2]
> }
> }
> puts "exit status is $exit_status"
> puts "captured standard output: {$standard_output}"
> puts "captured standard error: {$standard_error}"
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
