Feature request non-blocking sandbox, ev. needs yielding engine about sandbox HOT 9 CLOSED

The Tau Prolog sandbox is just that, a sandbox, and it allows you to set an inference limit to prevent the browser from freezing. It is built using the 3 main methods of Tau Prolog: consult, query and answer.

http://tau-prolog.org/manual/a-simple-tutorial

You can set up a sandbox that runs a query with a limit of, say, 1000 inferences. If the limit of inferences is reached, in the callback of the answer method, you can make it continue looking for the answer. That way the interpreter can stop working automatically from time to time, so that the browser takes care of the rest of the events.

In our current sandbox, when the query stops the user has to explicitly request that the search continue, requesting another answer. But this behavior can be changed by modifying the callback.

Regarding sleep/1 predicate, every time you stop the execution so that the browser processes the rest of the events, whatever way it is, there may be a delay. Precisely because you stop for other events to be processed. JavaScript is single-thread, and this is just a negative effect of its concurrency model. In any case, both with sleep/1 predicate or with the inference limit, the user can choose how often to stop the execution.

from sandbox.

Added. You only have to uncheck the stop option (the limit of inferences is still necessary).

You can check the option while running to stop the execution in the next limit of inferences.

from sandbox.

Tau Prolog is non-blocking, but as a National Department of Traffic slogan said: we can't drive for you. To release the browser you have two options: call an asynchronous predicate (such as sleep/1) that sleeps execution for a while, or use the inference limit that you can set in Tau Prolog.

For instance, the following code doesn't freeze the browser:

:- use_module(library(os)).

p :-
    sleep(0),
    write(p), nl,
    p.

Tau Prolog allows you to create a sandbox that sleeps every x inferences, but it doesn't by default because that delays execution.

from sandbox.

Ok, interesting, you can als cancel, by checking stop again.
But what is a good limit value? The default 10000 seems a
little too high, the GUI feels jiggy.

from sandbox.

It depends on the browser and the program. Something like 1000 should be fine, but it's a matter of testing I guess. (Note that you have to reconsult after setting the limit).

from sandbox.

Strange I have hit some browser incompatibility, on MacOSX.

The new feature works in Seamonkey:

It does not work in Chrome:

from sandbox.

It does not work in Chrome:

That is probably due to the browser cache. Refresh with Cntrl+F5 or clear the cache.

from sandbox.

Will check the browser later again.

I always admire Steve Jobs, how he introduced the MacIntosh
with a mouse that only had one button. Those times there were
mouses with 3 buttons.

So currently trying to figure out what a good GUI would be.
I cannot speak for Tau Prolog. But in my system Limit is a
system resource, that the end-user has nothing

to do with. It is planned that for non-blocking via some
auto-tuning the optimal value is found. Browsers have
a certain affinity to 60 frames per second.(*)

Not yet sure how this turns out. For the control buttons,
I am rather think of something else. Don't know yet what.
Was just having a look at SWISH, it shows me an animation

and an abort button:

after a while it shows stats:

the abort button shows again after redo:

(*)
I found some docu about that. A browser might also updrade
or downgrade the frequency. There is also something related
to animation, called requestAnimationFrame(), but this is

probably not needed for DOM updates.

from sandbox.

You can check here, but a monitor might have more Hz:

https://www.testufo.com/animation-time-graph

from sandbox.