UCI way to communications. Wich kind of inputs?

[Luis Babboni]

I read UCI description: http://wbec-ridderkerk.nl/html/UCIProtocol.html
and found this:

* The specification is independent of the operating system. For Windows,
the engine is a normal exe file, either a console or "real" windows application.

* all communication is done via standard input and output with text commands,


So I made a QB64 exe starting this way:

INPUT GUI$
IF GUI$ = "uci" THEN
PRINT "id name Soberango \n"
...

it seems its works if instead of CraftyGUI or Shredder GUI, is me who put the inputs. But not if are the GUI´s whos try to "talk" with my .exe

In fact they cannot recognize the exe as UCI engine....

I do not know if anyone here know QB64.... but I guess anyone could understand it and then could give me a hint about what I´m doing wrong.

BTW: What are the GUI´s sees to know if an engine is or not an UCI one?

Thanks!

[elcabesa]

you should reply to the "uci" command with those lines

id name NAME
id author AUTHOR
uciok


maybe you need to turn off output buffering or using a command like "flush output"
I don't now how it could be done in QB64

[hgm]

The problem is most likely that the PRINT statement gets buffered by QB rather then immedieately given as output. Only when it thinks someone is waiting to actually read the output (which it assumes when you run the program in a console window), it outputs the printed text immediately. When it thinks no one is looking, e.g. because the standard output is a file or pipe, it just keeps the printed text in memory until it has collected a lot of it (say 4096 characters), and only then flushes the collected text to the output. Many programming languages have this behavior; when programming in C you woudl have it too.

This is of course fatal when programming an engine: the GUI is waiting for an answer of the engine to a command it sent (like waiting for 'uciok' after having sent 'uci'). But the engine thinks it already sent it, and is waiting for the GUI to proceed with a new command (like 'isready'). While the GUI did not receive it, because it still is waiting in a memory buffer in the QB I/O system, for the engine to provide some more output (which will never happen).

So it is essential you make QB flush the output buffer after every PRINT you want the GUI to see immediately. (I.e. before the engine starts waiting for a response.) How to do that in QB I do not know; I don't know QB at all.

[Luis Babboni]

Thanks guys!
I´m going right now to QB64 forum!

[Luis Babboni]

Mmmm..... nothing for the moment on QB64 that could helps me

[syzygy]

I agree that the problem is likely that the output from your engine gets buffered and therefore does not reach the GUI. However, it might be good to exclude the possibility that it is your engine that is somehow not receiving commands from the GUI.

To check this, simply let your engine exit after it has received some input. With some help of the QB64 wiki:

Code: Select all

INPUT $GUI
SYSTEM

If your engine exits (which will probably make the GUI produce an error message), you know that your program receives input from the GUI.

By the way, you should not include "\n" in your print statements:

Code: Select all

PRINT "id name Soberango"

In C or C++, the \n is converted to a newline character. In BASIC this does not work. But the PRINT statement of BASIC already adds a newline character to printed strings (unless you add a semicolon immediately after the string), so you do not need to add it yourself.

[Luis Babboni]

Mmmm..... my

input GUI$
system

engine just wait till game time ends.

Its seems its not receive nor send messages.

[cdani]

First time I read about QB64.
I searched a bit. Are you using this?

http://www.qb64.net/wiki/index.php?title=Console_Window

http://www.network54.com/Forum/585676/m ... ng+in+qb64

Maybe it's necessary.

[syzygy]

http://www.qb64.net/forum/index.php?topic=5380.0

Apparently QB64 does not read from stdin and does not write to stdout. So INPUT and PRINT cannot be used to communicate with a UCI GUI.

Ah, I see you have already found that thread and even posted a question
So I think you're on the right track, but whether a solution exists is not so clear.

[Luis Babboni]

Well, I´ll try José Daniel´s idea (here in Argentina is common to have José as first anme and other as 2nd, no so common José as 2nd. ie: José Carlos; José Antonio; José Manuel or José María as Aznar in Spain)
Yes this is the language I´m using.

Here specially in point 6 talks about this problem:
http://www.open-aurec.com/wbforum/WinBo ... -intf.html