Skip to content

Conversation

@SiriusAshling
Copy link

With this, UciResponse implements FromStr and has UciResponse::new mirroring UciCommand.

Probably shouldn't be merged until #4 is fixed (see commit description).

The initial commit does not break the shape of UciResponse, but it might be worth to consider a breaking change to allow parsing into UciMove directly the same way that it works for UciCommand. Otherwise the documentation for the types feature might be misleading.

Another consideration might be to refine the types inside UciInfo, which are currently all Strings. For example, depth could be Option<u32>, which would be in line with the depth field of UciSearchOptions. refutation could be a struct with a separate String for the move being refuted and currline a struct with Option<u32> for the cpu number.

Let me know if you want any of those (or other) changes.

resolves dannyhammer#1

Note: This commit extends the impact of dannyhammer#4. The relevant codepath
mentioned there is now present regardless of the `types` feature.
As a consequence, compilation currently always fails with the
`validate-promotion-moves` feature

Not a breaking change, the shape of `UciResponse` remains unchanged.
This required some gymnastics in particular when parsing uci moves:
`UciCommand` contained `UciMove`s instead of `String`s with the `types`
feature enabled and the parsing infrastructure was specialized for this.
Since `UciResponse` stores uci moves as `String` even with the `types`
feature, the alternative parsing functions `recognize_uci_move`,
`recognize_moves` and `recognize_moves_after` were created to allow
always parsing into `String`.

Tests are a mix of made-up and grabbed from the UCI spec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant