×

To be able to write in the forum you need to authenticate. Meanwhile it's read-only.

Signal for premature results

Signal for premature results
December 03, 2017 05: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 01: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 02: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 04: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 03:47PM
I would use it and go back to old scripts and update them as well.
Re: Signal for premature results
January 12, 2018 08: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).
Re: Signal for premature results
May 23, 2021 08:54PM
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
Re: Signal for premature results
May 23, 2021 08:59PM
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).
Sorry, you do not have permission to post/reply in this forum.