You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the list of programming languages we define "file endings" for all languages. The implication is that this is how we determine what language should be used. For input/output validators we also allow build and run scripts, so oddities can always be handled, but that is not (and should not) be supported for submissions.
There are already collisions in the set of commonly used languages. Specifically Python 2 and Python 3 actually has the same file ending. In the legacy version we require a shebang to distinguish, in 2023-07-draft we currently require .py2 for Python 2. I would argue that both of these are workarounds, and further that the latter is even worse. What is good is that it defaults to Python, and you only have to do strange things if you want to use Python 2 (which you normally shouldn't).
I think that we opted for these workarounds because: 1. they are almost not needed anyway, it's just Python, and 2. the other (obvious) option is to have some kind of metadata file specifying this, and we wanted to avoid that if possible.
Regarding reason 1:
There are actual languages that share file endings, where one is not (more or less) a "deprecated" version of the other (i.e. Python 2 vs Python3). One such example is Objective-C, Octave and Matlab. Kattis currently supports both Objective-C and Octave.
On Kattis we already have some additional "languages" that share file endings. E.g. "C with GMP", "C++ with GMP", "C with Memory Check", "C++ with Memory Check", "Python 3 with NumPy".
Regarding reason 2:
If we store end endpoint information discussed in Specifying entry point #132, we could store this there as well. I.e. if there already is some metadata file then the additional cost for using it for this as well is minimal.
The text was updated successfully, but these errors were encountered:
I'm leaning quite strongly towards piggybacking this on the "expectations" framework (see #135), just like with #132.
Specifically, add a language property to the "filename globs" in the YAML file of the expectations framework, and call that file submissions.yaml (due to the now extended use):
Seeing as python 2 is EOL for a long time now, perhaps Prolog and Perl are better examples of a conflict. Two very different languages but same extension (.pl) used.
Related to #132.
In the list of programming languages we define "file endings" for all languages. The implication is that this is how we determine what language should be used. For input/output validators we also allow build and run scripts, so oddities can always be handled, but that is not (and should not) be supported for submissions.
There are already collisions in the set of commonly used languages. Specifically Python 2 and Python 3 actually has the same file ending. In the legacy version we require a shebang to distinguish, in 2023-07-draft we currently require .py2 for Python 2. I would argue that both of these are workarounds, and further that the latter is even worse. What is good is that it defaults to Python, and you only have to do strange things if you want to use Python 2 (which you normally shouldn't).
I think that we opted for these workarounds because: 1. they are almost not needed anyway, it's just Python, and 2. the other (obvious) option is to have some kind of metadata file specifying this, and we wanted to avoid that if possible.
Regarding reason 1:
Regarding reason 2:
The text was updated successfully, but these errors were encountered: