jordanbray / chess_uci

Traits to implement a chess UCI engine

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Want to contribute

UlisseMini opened this issue · comments

What things do you need done? I was going to make something like this, but since you're already working on it I'd love to see how I can help.

So, this library is currently pretty ugly, but the bones are pretty solid. That's my main concern with it. I think there are the following issues (probably should all be separate github issues).

  1. The timer is total crap. This entire structure probably needs to be re-written from scratch, to do chess timer things. Bonus points for making it testable somehow.

  2. Nom switched to functions instead of macros. Starting with NOM 5, they are switching away from their old "macros everywhere" style and switched to functions to replace each macro. This library uses the macros, because the functions didn't exist at the time. This is probably not hard work, but it's painfully monotonous.

  3. mod engine_base; This section of code comes from my experience writing chess engines, and the goal of it is to provide traits that the user can implement which result in a working engine. Most of the details are pretty ok, but the final engine class hasn't been finished. (Search, TimeManager, Eval (score), Evaluate (function), EngineOptions, SearchWindow, IterativeDeepening are all looking at minimum passable). There are also default implementations for each trait (an important goal from my perspective), to get potential users up and running more quickly and to have a "known-stable" thing to test against. I'm pretty happy with the structure here. It will provide what I was looking for.

  4. Overall structure. I'm not happy with the way the library is organized. I don't like engine (containing commands) and engine_base (containing traits) (not descriptive). I don't like mod timer::timer; (confusing). I don't like the manually-implemented Error.

  5. Documentation. I haven't done it yet because the structure is still kind-of bad, and I don't want to have to re-write it.

Oh, and part 6.
If you want to write new code, one thing that would be very helpful is a syzygy and opening book library. Both of these details should be handled by this library, but that may be a 2.0 feature, not a 1.0. A PGN parser probably needs to be written as well.

Thanks! I'll work on switching nom to using functions

This look good to you?

pub fn parse_rank<'a>(input: &'a str) -> IResult<&'a str, Rank> {
    alt((
        value(Rank::First, tag("1")),
        value(Rank::Second, tag("2")),
        value(Rank::Third, tag("3")),
        value(Rank::Fourth, tag("4")),
        value(Rank::Fifth, tag("5")),
        value(Rank::Sixth, tag("6")),
        value(Rank::Seventh, tag("7")),
        value(Rank::Eighth, tag("8")),
    ))(input)
}

I'll convert the others in the meantime.

Yeah. That looks fine to me. I believe you can remove the lifetime parameter there.

I've converted about half, I've got to go now; but I'll PR my changes tomorrow :)

So, there are way more parsers then I thought, I thought the only ones were in parsers.rs,
might not be worth converting them to the new style. I can PR my changes if you want, but having a few parsers be function-based, and the rest macro based does not make that much sense imo

EDIT: Maybe a separate branch for the nom rewrite?

Continued in #2