Re: Signal for premature results

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.

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.

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.

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.

I would use it and go back to old scripts and update them as well.

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

Is it worth putting an example of this into the template new checker around line 36 similiar to:

--ok=true
--Allow unattended checks to return without worrying about generating logs, html, or maps
--if args[1].environmentSettings.cli then
-- return { ok = ok}
--end

if(ok == true) then

Good suggestion. I copied your snippet and added it before the "More feedback"-block in the skeleton code. Will come with the next release.

PS! I hope your code is valid, because my LUA is as good as my German (I know some, but almost not).