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. 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.
2) Minor things: - Pause contest countdown / starttime_enabled - tsv/yaml import scripts - results/tsv export scripts
There's no reason to disable these.
3) external IDs / external results - have only one database scheme, i.e. include columns for external_ids and _results - why don't we always use the contest shortname as ID in the API? - 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
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.
5) removed time intervals The code in calcContestTime looks fairly simple. The UI only affects the contest page. Did I miss anything?
Best, Tobi
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):
- 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. - 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.
The last point is a new idea, comments welcome.
- 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.
- 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 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.
- 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.
- 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.
- 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.
On Tue, March 27, 2018 22:24, Jaap Eldering wrote:
- 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.
Agreed, and indeed wrap it inside a feature toggle so you can be sure the entire code is not executed/no queries are done to removed_intervals table/the contests interface is not cluttered when you're not using the feature.
Thijs
Jaap Eldering jaap@jaapeldering.nl schrieb am Di., 27. März 2018, 22:25:
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):
- 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:
- No language specific logic inside generic DOMjudge code.
- 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.
- 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
- 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.
- 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.
- 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
On March 28, 2018 5:24:37 PM GMT+02:00, Tobias Werth tobias.werth@fau.de wrote:
Jaap Eldering jaap@jaapeldering.nl schrieb am Di., 27. März 2018, 22:25:
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):
- 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:
- No language specific logic inside generic DOMjudge code.
- 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.
It doesn't currently, but that sounds like a good idea and not too difficult to do.
- 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?
That's one option I had in mind, but since it's a very simple function with only the filenames as input and entry point as output, it could be any executable script, that we call from code on domserver.
The last point is a new idea, comments welcome.
- 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
- 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.
Ok, that sounds fine to me.
Jaap
- 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.
- 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.
- 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
-
Jaap Eldering -
Thijs Kinkhorst -
Tobias Werth -
Tobias Werth