Advanced

Signal for premature results

Signal for premature results
December 03, 2017 06:18PM
Some time consuming checkers may know at some point, if the challenge is qualified or not, but the checker may continue to find a partial solution and it also generates html documents which may take even longer than the primary check.

Checker could signal the primary result (ok value) immediatelly when it is achieved.

There could be two advances achieved with this construction.
1. Automated test batch could stop the checker before it generates any unusable informative user output.
2. If the checker is running from user interface, the system could selectively give additional time to give opportunity to find the best partial solution. (For example for paying members.) At least, system could tell, if the user qualifies or not, regardless of possible time-out.
Re: Signal for premature results
December 21, 2017 02:29PM
I don't think this is technically possible as it is now. The LUA scripts can't signal back without actually exiting. A new sandbox would then have to be started to continue the calculations.
Re: Signal for premature results
December 21, 2017 03:02PM
Ok. In the case that there is some interest to make checkers to run little bit faster in batch mode. It also could be possible to insert a "batchmode" parameter, which may be used selectively to skip generating log and html output in some cases.

I think that generally this may give only marginal advance. I just get this idea when writing a script which knows early that there is no solution but then it continues to find the best partial solution which is useful only when the script is used manually.
Re: Signal for premature results
January 10, 2018 05:09PM
I agree, and it's with regret it wasn't added from start. I am unsure if it will be used a lot by the developers though. But I have had the idea myself, especially since most of the LUA executions are the auto-challenge-checkers.
Re: Signal for premature results
January 11, 2018 04:47PM
I would use it and go back to old scripts and update them as well.
Re: Signal for premature results
January 12, 2018 09:59AM
TravelingGeek Wrote:
-------------------------------------------------------
> I would use it and go back to old scripts and
> update them as well.


It was added this week actually. It was easy to do, and since I was patching around in the code anyway.

args[1].environmentSettings.cli will be true or false depending on if it's a background job or not (cli=true doesn't need any output but the ok=true/false).
Sorry, you do not have permission to post/reply in this forum.