JSUCI 1.0 - connect javascript chess engines to UCI

[Edmund]

Woo! I have Lozza working in Arena (well in principle anyway).

I was going to spawn a sub-worker with Lozza in it on UCI GO, so I could easily kill it on UCI STOP, but V8 doesn't seem to like a worker starting another one.

NB: Can't currently use Hiarcs UI because it says your exe is 'not a valid engine' - I'll post in the Hiarcs forum to find out what it required for 'validity'.

This is fab Edmund; thank you so much...

Congratulations, I am glad it is working!

As far as I understand it, it is a general issue with Chrome that Workers may not start other Workers. It would theoretically possible to add this feature with the tool I have written, but would lead to a lot of added complexity. I think it is not essential for the time being and maybe the V8 project will add support in the future themselves, as the engine is still under heavy development (already 20 commits today).

If you upload the source or post some communication of your engine we could validate whether there are any issues with UCI conformity.

[op12no2]

As far as I understand it, it is a general issue with Chrome that Workers may not start other Workers. It would theoretically possible to add this feature with the tool I have written, but would lead to a lot of added complexity. I think it is not essential for the time being and maybe the V8 project will add support in the future themselves, as the engine is still under heavy development (already 20 commits today).

I agree; there is a ticket raised on it and I'm sure it'll get resolved soon. In the mean time I'm not sure how to best go about handling STOP to stop an infinite analysis without converting to an iterative algorithm... Will publish soon - still in a totally hacked state to concept prove at the moment.

[Edmund]

As far as I understand it, it is a general issue with Chrome that Workers may not start other Workers. It would theoretically possible to add this feature with the tool I have written, but would lead to a lot of added complexity. I think it is not essential for the time being and maybe the V8 project will add support in the future themselves, as the engine is still under heavy development (already 20 commits today).

I agree; there is a ticket raised on it and I'm sure it'll get resolved soon. In the mean time I'm not sure how to best go about handling STOP to stop an infinite analysis without converting to an iterative algorithm... Will publish soon - still in a totally hacked state to concept prove at the moment.

Wouldn't it be possible to just set a flag and when the flag is set unwind the search-stack disregarding the outcome at that point and eventually post the bestmove found from a state before the flag got set?

[op12no2]

Wouldn't it be possible to just set a flag and when the flag is set unwind the search-stack disregarding the outcome at that point and eventually post the bestmove found from a state before the flag got set?

I'm quite possibly missing something here but AIUI (and from what I can see) the worker onmessage() will be blocked (single threaded) after the infinite analysis is started, so unlike unwinding after a timeout there is no way to actually set the stop flag - the UI will send it but the worker/engine will never see it.

If that's true, would it be possible for jsuci to notice stop and set a flag it its context that is readable by the worker/engine so it could then unwind like timeout...?

[Edmund]

Wouldn't it be possible to just set a flag and when the flag is set unwind the search-stack disregarding the outcome at that point and eventually post the bestmove found from a state before the flag got set?

I'm quite possibly missing something here but AIUI (and from what I can see) the worker onmessage() will be blocked (single threaded) after the infinite analysis is started, so unlike unwinding after a timeout there is no way to actually set the stop flag - the UI will send it but the worker/engine will never see it.

If that's true, would it be possible for jsuci to notice stop and set a flag it its context that is readable by the worker/engine so it could then unwind like timeout...?

I checked myself and you are right that the event is not triggered when you are in a busy loop.

Sorry for the delay, but I asked also in other forums whether there would be any nice solution - without success.

I uploaded a new version 1.1 to the server. Now it exposes the variable "lastMessage" which is also updated whenever the onmessage event is called. I don't like this solution, because of all the potential race issues it creates, but it is the best I could come up with.
I prefer this over the stop flag, because I don't like the program to actually be parsing the output (other than exit) and it is also unclear who is when responsible to reset this flag.

With this new variable lastMessage I could imagine that you have your own variable with the last processed message and keep comparing whether there is a new message.
Another advantage of this system is that you can treat more than just the stop command from within the search (e.g. setoption or ponderhit).

Please let me know whether this resolves the issue for you.

[op12no2]

With this new variable lastMessage I could imagine that you have your own variable with the last processed message and keep comparing whether there is a new message.
Another advantage of this system is that you can treat more than just the stop command from within the search (e.g. setoption or ponderhit).

Please let me know whether this resolves the issue for you.

Hi Edmund,

Thank you very much for doing this; I will try it as soon as possible.

[op12no2]

Hi Edmund,

This is an Arena log snippet. To test I'm sending "info string lastMessage" in my stats update function, but after Arena sends "stop", lastMessage does not change. Any ideas...?

Code: Select all

2014-04-02 16&#58;12&#58;11.125<--1&#58;info string go infinite
2014-04-02 16&#58;12&#58;11.140<--1&#58;info string go infinite
2014-04-02 16&#58;12&#58;11.140<--1&#58;info currmove g2g4 currmovenumber 13 
2014-04-02 16&#58;12&#58;11.156<--1&#58;info string go infinite

2014-04-02 16&#58;12&#58;11.156-->1&#58;stop

2014-04-02 16&#58;12&#58;11.156<--1&#58;info string go infinite
2014-04-02 16&#58;12&#58;11.156<--1&#58;info currmove c2c4 currmovenumber 14 
2014-04-02 16&#58;12&#58;11.156<--1&#58;info string go infinite
2014-04-02 16&#58;12&#58;11.171<--1&#58;info string go infinite
2014-04-02 16&#58;12&#58;11.171<--1&#58;info string go infinite

The exciting news is that I just watched Lozza make it's very first move in a GUI

Early days, but this code is working with your most excellent jsUCI:-

http://op12no2.me/toys/lozza/lozza.js

It's stand alone so easy to fire up in jsUCI.

[op12no2]

I swapped to Winboard as my UI.

Lozza is happily playing matches with FairyMax - they seem to be about the same level, though Lozza's lack of promotion knowledge is obvious (I'll fix that now...). Lozza searches a ply deeper ish but she has no eval function to speak of yet. Very encouraging for compiled-on-the-fly javascript.

This is great fun. Thanks Edmund (and HG for Winboard/FairyMax and google for V8). I'm getting around the stop problem (if it is indeed a problem and not me being stupid) by simply restarting the engine from the Winboard UI when needed.

It will be interesting to see Gary's Garbochess working in jsUCI - I think it's probably the most powerful javascript engine ATM...

[Edmund]

Congratulations on the progress, colin.

Regarding V8, it is getting more complicated than I thought. V8 as well as Javascript are single-threaded. That means when I start executing the javascript code it doesn't give back control to the interface till the script terminates (so it cant process the messages that enter in the meantime). I tried executing the script in a separate thread, but accessing the same javascript instance from different threads is not streight forward. That said, there probably exist ways, just that I am not smart enough to understand the documentation at that point as this is my first test project using this javascript engine. I am still awaiting feedback in the V8 developer forum.

[op12no2]

Thanks for the update. If only V8 workers could fire up sub-workers, there would be no problem.

I was wondering if the engine could listen on an event handler (like it would with browsers) without a worker, allowing the engine to fire off a worker, but jsUCI would have to poll for comms(?) and it's all a but ugly perhaps.