Feedback request: libchessinterface

[JonasThiem]

Hello fellas,

I'm planning to write a C/C++ engine handling library and would like to hear some comments on its usefulness and the interface.

Why?
I noticed many GUIs support either UCI or Winboard rather incompletely, or even just one of the two. Also, rewriting the code to set up another process with pipes for each new GUI seems to be a bit tedious (as most would probably do it the same way, the major differences lie somewhere else I suppose).

How?
So I thought I would write a library: libchessinterface. It would incorporate close to zero chess knowledge, so all the chess knowledge and support for variants etc etc would be up to the GUI. The library wouldn't be limiting you here, but also not assisting.

All the library would do is launch the process for you and provide a uniform interface that hides the differences between UCI and Winboard/CECP. Since UCI is a bit simpler due to bein stateless, the interface probably looks a bit more like Winboard than UCI.

Interface draft:
Tell me what you think. Would you use this library in your GUI? Also, please comment on the first iteration of my header file: https://github.com/JonasT/libchessinter ... nterface.h

[diep]

Hello fellas,

I'm planning to write a C/C++ engine handling library and would like to hear some comments on its usefulness and the interface.

Why?
I noticed many GUIs support either UCI or Winboard rather incompletely, or even just one of the two. Also, rewriting the code to set up another process with pipes for each new GUI seems to be a bit tedious (as most would probably do it the same way, the major differences lie somewhere else I suppose).

How?
So I thought I would write a library: libchessinterface. It would incorporate close to zero chess knowledge, so all the chess knowledge and support for variants etc etc would be up to the GUI. The library wouldn't be limiting you here, but also not assisting.

All the library would do is launch the process for you and provide a uniform interface that hides the differences between UCI and Winboard/CECP. Since UCI is a bit simpler due to bein stateless, the interface probably looks a bit more like Winboard than UCI.

Interface draft:
Tell me what you think. Would you use this library in your GUI? Also, please comment on the first iteration of my header file: https://github.com/JonasT/libchessinter ... nterface.h

No i would not use it of course. My own GUI already can load winboard and uci engines and dep. I built exception code for specific individual engines that have BUGS in their implementation of the different protocols. Most uci implementations are just total hacks you know. I bet you aren't going to do that - rendering library useless for those who still would consider using it.

Another layer of interface in between is just slowing down engines of course, not speeding them up - and look around you - all those dudes work realtime with engines. They have to achieve realtime.

There is 0 usage in such library.
It's utter useless.

What GUI you want to target for example?

Fritz?

So you are going to rape the engines by giving them 1 MB hashtable?
You give them commands avoiding to be able to ponder?

Generic stuff you cannot build here you know. Only specific stuff that targets interface X and engines ABC that's what you can build here.

No one is interested in libraries here. They're only interested in either an engine or a GUI. Not another slowdown tool

[JonasThiem]

I'm not sure how you came to the conclusion I wouldn't add engine specific hacks/workarounds/exceptions or why it would necessarily be slow. But thanks for your honest opinion!

[diep]

I'm not sure how you came to the conclusion I wouldn't add engine specific hacks/workarounds/exceptions or why it would necessarily be slow. But thanks for your honest opinion!

you speak about a proces that's in between 2 processes - so that's a huge slowdown in transfer latency - where most are playing real fast time controls online. 1 minute entire game is very common.

Every millisecond you lose is a lot. At multisocket machines you will lose a minimum of 100 milliseconds up to several seconds at occasions as all processes and threads are fighting for system time - chessprograms tend to eat EVERYTHING you have already.

Now with other adapters we already saw this problem - yet you intend to do it in C++ which will slow down even further of course. Nice objects that each move need to get allocated bla bla bla.

A recipe for disaster.

[JonasThiem]

Oh ok, that was a misunderstanding then!

I want to write a .dll you use directly in your GUI, no extra process added
I just meant that the library would spawn the engine process FOR YOU, so your GUI does no longer need to do that. No additional process involved

Also I'll write in pure C, hence the library can be used from C but also from C++ (therefore I called it C/C++ library).

[diep]

Oh ok, that was a misunderstanding then!

I want to write a .dll you use directly in your GUI, no extra process added
I just meant that the library would spawn the engine process FOR YOU, so your GUI does no longer need to do that. No additional process involved

Also I'll write in pure C, hence the library can be used from C but also from C++ (therefore I called it C/C++ library).

Of course no one is so stupid to load a DLL that *you* produce.
If you say: "i have open source software that you can compile to PRODUCE
a plugin, and you can use it COMMERCIALLY for FREE",

Then that's a different ballgame for guys who might consider setting up a new GUI.

Using compiled executables or DLL's or whatever they might need to pay for no one is gonna do of course.

Note that my GUI is in C++, the engine is in C.

Previous produced GUI's also are in C++ and in 90s i had setup one in C using winapi-C.

In all cases the engine connectivity was just a very small part of the work.

If someone builds a new building, basically you give 1 pub chair for free.
So that's useless.

The way how you set it up i don't think very convenient btw.
In my GUI i use classes if you know what that is.

Your time control definition also won't work for serious engines that can support up to 3 time controls.

It's so total incompatible with i bet every GUI that it's not even worth considering using your 1 day of effort.

[JonasThiem]

Did you take a look at the interface? I suggest you read the license header before blaming me for producing a binary blob dll.

I don't want to make some closed-down thing so you get stuck if you want something that hasn't been added yet.. everyone is free to contribute and fork.

[diep]

Did you take a look at the interface? I suggest you read the license header before blaming me for producing a binary blob dll.

I don't want to make some closed-down thing so you get stuck if you want something that hasn't been added yet..everyone is free to contribute and fork.

Yeah 5 minutes of work you put in.

Pretty amateuristic way of defining things for GUI's.

Note that GUI <==> engine communication speed and latencies are a BIG issue when the GUI is in C++. Those operating systems you know, they are 20 years behind. Not to mention the way how the GUI's of those operating systems work. It's all kind of single cpu type logics those OS-es do for their GUI's. Real pathetic.

Speed of communication is of major concern.

p.s. i had not finished editting my previous post. Maybe read what i wrote.

[JonasThiem]

Ok this is a bit pointless. You're obviously not interested in offering useful improvement advice.

Anyway, thanks for pointing out the unclear issues, it probably wasn't sufficiently obvious in my first post that it will be open-source and simply a library for loading engines, so the part everyone needs to do done in one central place (and no additional process or other unusual/fancy things).

[diep]

Ok this is a bit pointless. You're obviously not interested in offering useful improvement advice.

Anyway, thanks for pointing out the unclear issues, it probably wasn't sufficiently obvious in my first post that it will be open-source and simply a library for loading engines, so the part everyone needs to do done in one central place (and no additional process or other unusual/fancy things).

Your original posting: "I'm planning to write a C/C++ engine handling library and would like to hear some comments on its usefulness and the interface.
"

Is it useful? No

I explained why.

The way how you interface?

Amateuristic

My question to you: Have you ever looked at how C++ GUI's function at codeside?

Next question: how many guys who write GUI's for a living have you ever seen post here 'useful' suggestions or go into 'nerd talk' type discussions here? Comeon - they do it for a living - they aren't interested in helping out others.

They aren't interested in others who try to work their way into their GUI with code either.