[Termtools] upcoming competition

[Simon Bailey]

hi johannes,

On Oct 29, 2008, at 7:35 PM, Johannes Waldmann wrote:
> what information do you need to set up the scheduler?
> Is "name of tool and category" enough?
> (So, can "implementation" be picked later?)

the implementation at the moment selects the active implementations  
and passes them to the competition job as a List<ToolImplementation>.  
the simple reasoning behind this approach is that test jobs and user- 
submitted experiments become simple: a test-job for instance is a [non- 
public] "competition" with a single element in the  
List<ToolImplementation> and a flag telling the execution environment  
to pull 5 random problems from each category. (the other reasoning is  
that if a user manages to submit a tool while the competition is  
running, circumventing any security preventing this, his tool will not  
be considered for use in the currently running competition).

the name of the tool and the categories entered in can be determined  
from the ToolImplementation by accessing the parent Tool object.

> Then there could be a deadline for registration (say, Friday noon),
> then Simon sets the scheduler ticking (and goes home for the weekend)
> and the competition will be started at midnight using the (then)
> "selected" implementation of each registered tool.

different approach: schedule a job to fire the competition schedule  
trigger at the given deadline – this (rather trivial) possibility only  
occurred to me during dinner... my previously suggested approach would  
have been to schedule the job "by hand" after the deadline, but the  
deadline can also be automated.

> Since the issue of bylaws came up - when is a tool/implementation
> allowed to take part in the competition? Does the Steering Committee
> want to monitor the list of applicants, and "okay" them?
> (Then this should be done at the registration deadline.)

this would make a good case for a longer submission deadline, but is a  
decision for the steering committee. (the system supports it but  
currently ignores it).

> (I must say - starting directly into "autopilot" at midnight
> requires some faith in the software. But there has been extensive
> testing, so this may actually work. Was this "autostart" also tested?
> If not, we could postpone until Monday, daytimes)

well, test-jobs work like that... all previous tests running more or  
less complete versions of the competition have always been fire-and- 
forget scheduling of the competition, triggered by a web-action rather  
than an automated action. the scheduler actually makes no difference  
between an "immediate" trigger or a scheduled trigger – the immediate  
trigger is treated the same as a scheduled trigger with the trigger  
time "now".

i'll set up a test-bed for an autostart mechanism tomorrow just to be  
on the safe side, but it should work "as advertised".

as soon as the trigger for the competition has been set, as long as  
the scheduler is running (tests have shown that it is robust), the  
competition _will_ start at the scheduled time (plus/minus a second or  
two, if even).

if anyone is interested how an immediate start for the competition is  
executed, look in the method runme() here:

http://cl2-informatik.uibk.ac.at/svn/termcomp/trunk/src/action/org/aspsimon/termcomp/session/ScheduleCompetition.java

(a scheduled call would replace the makeImmediateTrigger() call with  
the corresponding date/time trigger command.

regards,
sb