UCI way to communications. Wich kind of inputs?

[bob]

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.

What else is there to read from? Must be a descriptor-like thing as used in Unix. I would think if 0/1 don't work, and since 2 is stderr, one might try 3, 4, etc. I think there are even good system calls to ask "what is this?"

[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.

What else is there to read from? Must be a descriptor-like thing as used in Unix. I would think if 0/1 don't work, and since 2 is stderr, one might try 3, 4, etc. I think there are even good system calls to ask "what is this?"

See the link:

stdin/stdout are the standard input/output for C, and though QB64 doesn't use them (It uses SDL's to get keyboard input and then writes it to the SDL window) (...)

Apparently QB64 reads directly from the keyboard, converting keyboard events to input strings (in the case of an INPUT statement).

It is possible to open files in QB64 and assign them to descriptor-like things (OPEN "filename" AS #1, then PRINT #1 etc.), but it does not seem to be possible to "open" stdin or stdout.

Maybe in the future this will be possible:
http://www.qb64.net/wiki/index.php?title=OPEN

Devices such as "KYBD:", "SCRN:", "CONS:", "COMn" and "LPTn:" are currently NOT supported in QB64!

but it seems likely that PRINT#ing to KYBD: will work as PRINT works now, i.e. not to stdout but directly into some kind of console.

[Luis Babboni]

Thanks for your time!

Cause my poor english and programming knowledge, it tooks me 10 times yours to understand what are you talking about.... but I bet soon or later I will do

[Luis Babboni]

Anyone knows if there is any GUI that shows the console "conversation" between the GUI and the engines?

Thanks

[bob]

Anyone knows if there is any GUI that shows the console "conversation" between the GUI and the engines?

Thanks

Xboard has always had this. Enable debug mode.

[Luis Babboni]

Thanks Robert!
I could see it in Arena (a pitty Arena do not be enough clear to newbies.... I still do not understand how to choice if engine vs human; human ves engine; engine1 vs engine 2 or engine 2 vs engine 1 )

[Luis Babboni]

As I said, I could see the conversation between Arena and the engines....
but my problem is that just could paly me vs an engine, no way to make two differents engines play themself in arena

[bob]

As I said, I could see the conversation between Arena and the engines....
but my problem is that just could paly me vs an engine, no way to make two differents engines play themself in arena

Xboard will do either, and it will produce a debug file if you want, with all the messages to and from BOTH engines or between the human and the engine.

[sje]

This may not be applicable to the QB64 environment, but in Unix-like systems one can employ named pipe files as an alternative to standard I/O redirection. I've had to use this with otherwise uncooperative interpreters.

But it seems like an unnecessary complication here. Perhaps there is some way of running the engine as a regular application, not in the QB64 console environment.

[OneTrickPony]

Maybe check buffering settings. On some systems (Windows) line buffering doesn't work and printf doesn't automatically flush after a new line (as it does under Linux with line buffering which the default for printf).