UCI/XBoard Support

[Mk-Chan]

I can see the point here: jordanbray/chess#6 but it also suggests putting all the engine communication stuff into a different library which I'm not too much a fan of as it may be harder to discover. Is there any consensus on this?
I actually would like to help out too but my Rust is not up to the mark yet.

[niklasf]

We disagree on where to draw the line, for example I think it's a good idea to at least include parsers for notation like e1h1 and Naxb3, but a full implementation of the UCI protocol (or XBoard) definitely belongs in a seperate crate. Managing dependencies is much more comfortable with cargo than with pip.

[denizsincar29]

@niklasf now how to communicate with uci chess engines via rust that beautiful way as I did in python chess? Don't want to make all dirty work and parse it myself...

[johanfleury]

Hey, I just published shakmaty-uci. It provides an enum (UciMessage) to write and parse UCI messages to and from the engine. It’s based on/inspired by vampirc-uci but uses Nom for parsing.

It does not (yet) handle actual communication with the engine, but I’ll probably add that in the future.

@niklasf if you’re interested, I started this crate as a module of shakmaty. I think it might be better to have this as a separate library, to not clutter shakmaty (especially if I add engine communication), but I could easily provide a PR if you would be interested in integrating this in your crate.