Extended thinking output not working (CECP)

[mvanthoor]

Hi,

At the moment I'm quite far with regard to implementing the CECP-protocol for Rustic. Only a few things remain. I've implemented thinking output (and reacting to the "." command), and this works fine; but it seems I can't get the extended version to work.

The specs:
http://hgm.nubati.net/CECP.html
https://www.gnu.org/software/xboard/engine-intf.html

Code: Select all

DEPTH SCORE TIME NODES PV
DEPTH SCORE TIME NODES SELECTIVEDEPTH SPEED TABLEBASEHITS<Tab>PV

So, to implement the extended version, the PV needs to be separated by a TAB instead of a space.

I now have this:

Code: Select all

    fn search_summary(s: SearchSummary) {
        println!(
            "{} {} {} {} {}",
            s.depth,
            s.cp,
            (s.time as f64 / 10.0).round(),
            s.nodes,
            s.pv_as_string()
        );
    }

"SearchSummary" is basically a struct that contains everything the engine could output about the current search run. Thuis works:

Code: Select all

$ ./target/release/rustic.exe -c xboard
Rustic Alpha 1 by Marcel Vanthoor (xboard mode, 1 thread)
analyze
1 70 0 7 e2e4
2 0 0 114 d2d4 d7d5
3 60 0 1005 d2d4 d7d5 e2e3
4 0 0 15893 d2d4 d7d5 c1g5 c8g4
5 20 5 169855 d2d4 d7d5 c1f4 c8g4 f4e5
6 5 34 1458763 d2d4 d7d5 e2e3 c8d7 c2c4 e7e6 c4d5 e6d5
7 20 287 11665664 d2d4 d7d5 c1d2 c8f5 e2e3 e7e6 f1e2

So I though it would be easy to just do this to send the extended information:

Code: Select all

    fn search_summary(s: SearchSummary) {
        println!(
            "{} {} {} {} {} {} {}\t{}",
            s.depth,
            s.cp,
            (s.time as f64 / 10.0).round(),
            s.nodes,
            s.seldepth,
            s.nps,
            s.tbhits,
            s.pv_as_string()
        );
    }

Note the \t before the last pair of curly braces. The engine does send out the tab character and Arena receives it (confirmed in the log window), but Arena doesn't parse the string correctly.

Therefore I tried it under XBoard, and it also doesn't work. It still shows the PV (where Arena doesn't), but it keeps stating "not shown: tbhits, selective depth, speed".

Am I overlooking something or misunderstanding this?

(PS: "pv_as_string" converts the moves in the PV-vector to a string. I have checked that this string does not contain leading or trailing spaces. The function trims the string left and right after constructing it.)

Code: Select all

impl SearchSummary {
    pub fn pv_as_string(&self) -> String {
        let mut pv = String::from("");
        for next_move in self.pv.iter() {
            let m = format!(" {}", next_move.as_string());
            pv.push_str(&m[..]);
        }
        pv.trim().to_string()
    }
}

@HGM:

The specs at the Nubati site state that the response to the "." command should start with "stat01". The specs at the GNU side state "stat01:" (with extra colon). Both Winboard and Arena implement the version with the colon (I looked it up in the Winboard code, and without the colon, Arena doesn't parse the response.)

[hgm]

In WinBoard/XBoard you can open and close the columns with the various infos by right-clicking on their headers (including those listed in the 'not shown' section). This setting (which will only be applied to new lines that come in, and not retro-actively to what was printed before) will be persistent. The default setting is that it only shows the 'classical' infos (depth, score, time and nodes).

An interface that doesn't support the extended format should show the numbers in the PV field, thinking they are the leadin 'moves' of the PV.

Thanks for spotting the error in the specs draft.

[mvanthoor]

Thanks. I'll try and see if I can get this to work for Windboard.

Arena just borks on the extended format. It shows the numbers in the PV field, but not the PV itself. Maybe I'll create an option for this format, so it can be enabled for GUI's that support it.

[hgm]

That should be considered an Arena bug. In CECP the PV field is free text format, and even if the GUI would like to interpret it, if it cannot understand it, it at least should literally display it. Many CECP engines print nonsense infront of their PV (such as smileys...), and some use move numbers in their PV. So I wouldn't expect a few extra numbers to wreck things.