On 27/03/18 20:54, Tobias Werth wrote:
> Hi,
>
> I want to get rid of the ICPC-live branch as soon as possible after the finals. I also think that we should do this first before we do any further symfony migration.
I agree with both statements! And first next step should also be to sit down and cleanup, because we have accumulated too much cruft in the mixed old/new API.
> This is a list of the differences to get the discussion started (I probably missed some things):
>
> 1) entry_point handling
> Options:
> a) add a global configurationÂ
> b) always require an entry_point if the language itself requires an entry_point
> c) detect entry_point on domserver
>
> I would go with b). By default we can use compile scripts that auto-detect and configure languages as such.
> In a setting primary/shadow setting, we can require entry points as we do now.
I'm not exactly sure what these options imply. My two constraints in order of preference:
1. No language specific logic inside generic DOMjudge code.
2. Allow auto-detection of the entry_point wherever this is possible (and highly reliable)
a) global configuration sounds like it violates 1, so sounds like a no-go to me.
c) means that we can't do the current Java reflection to detect a main class signature during the compile phase on a judgehost, which is the most reliable way to detect the main Java (or Kotlin) class.
So I would propose that we roughly do what we currently have:
- Have an option require_entry_point to force that languages that need an entry_point, get it set during submission time. We would use this, for example, during the WFs when there's API clients that need the entry_point at submission time.
- If require_entry_point=false, and it is not provided at submission time, then it is the responsiblity of the compile script to either detect it as required, or fail.
Does the compile script return the used entry_point in the metadata for posterity? Then we could after the fact compile a submissions.json or an event log with entry point for easier replaying.
- We create an API endpoint that can be called to guess an entry point from a list of submission file names. This can be called both from JavaScript code in the browser, from the submit client, and the domserver internally, so we have a single place for guessing the entry_point at submission time. That code can be stored as part of the language data or compile script.
In what language do you expect to write that code snippet? PHP?
The last point is a new idea, comments welcome.
> 2) Minor things:
> - Pause contest countdown / starttime_enabled
> - tsv/yaml import scripts
> - results/tsv export scripts
>
> There's no reason to disable these.
Sounds fine to me to integrate, although I would say that we need to cleanup/improve the {im,ex}port pages to make it clear what is {im,ex}ported.
+1 to cleanup
> 3) external IDs / external results
> - have only one database scheme, i.e. include columns for external_ids and _results
Does that mean that we have external_ids for all tables that possibly could be imported with an external ID, and if an external ID is not set, then copy our internal ID to the external_id column?
Why copy? Use the external id if it exists. Otherwise fall back to the internal one.
> - why don't we always use the contest shortname as ID in the API?
Good question, I've lost track of the variations of identifiers a bit, when including what we use, what's in the Contest API specification, and dealing with upstream systems.
It would be good to review our DB system and simplify/match this with the Contest API, but I think it would be best to discuss at the WFs if we think we should make any changes in the Contest API spec. For example, whether we're keeping the contest name and full_name fields there.
We should do the same with contestproblem:shortname,problem:externalid and in the API spec id,label,name. Although here the mapping seems fairly straightforward contestproblem:shortname==label, problem:externalid==id, so maybe we should just rename shortname to label.
Sounds good to me.
> - can we drop the expected result in favor of external results? (note that we didn't do a comparison on testcase level in the past but might want to do it in the future)
> - external_ids and _results can be used even in primary mode where we could fetch the results from the secondary
I consider external and expected results to be two separate things that I would prefer to keep separate. Especially in the last case: if we load jury submissions, then the expected results are relevant, and should not be replaced by results from a secondary system.
Good point.
> 4) display test case results in submission lists
> Options:
> a) make it configurable (either per contest or globally)
> b) always display them (for jury of course)
>
> I don't think the test case results clutter the submission page too much, so I would just keep them always on for simpler code.
That sounds ok me. One can always remove them manually.
> 5) removed time intervals
> The code in calcContestTime looks fairly simple. The UI only affects the contest page. Did I miss anything?
Yes, there's very little interaction with the rest of the code. There's also a single extra column on the contests page and some code in lib/www/checkers.jury.php, but that's about it.
I would still wrap it inside a configuration setting (buried in etc/domserver-config.php) to not expose this abomination to people, unless you *explicitly* ask for it.
_______________________________________________
DOMjudge-devel mailing list
DOMjudge-devel@domjudge.org
https://www.domjudge.org/mailman/listinfo/domjudge-devel