Comments (6)
Als je de generieke judge enkel gebruikt voor het beoordelen van Python oefeningen, dan kan je wellicht voorlopig gewoon de python docker gebruiken.
from universal-judge.
Het is gebeurd!
from universal-judge.
Enkele eerste observaties uit eerste ingediende oplossingen, waarbij verschillen zichtbaar zijn met feedback van Python judge. Deze kunnen dus alvast op lijstje gezet worden van mogelijke TODOs voor generieke judge:
- geen ondersteuning voor Python Tutor
- evaluatie duurt iets meer dan 2x zo lang (kunnen timings uit databank gehaald worden?)
- Python judge doet extra opkuis van stack traces, bijvoorbeeld bij ingediende oplossing 4974428 wordt de volgende stack trace weergegeven
waarin de bestandsnamen eigenlijk interne keuken zijn van de judge; de Python judge zou de regel met de verwijzing naar./context_1_1.py
niet weergeven, in andere regels het bestand./submission.py
hernoemen naar<code>
, met ook een link van die regel naar de corresponderende regel in de code-tab - Python strings standaard weergeven met enkele quotes (Python default) in plaats van dubbele quote (tenzij er bijvoorbeeld letterlijke enkele quotes in de string zelf voorkomen)
- geen linting op ingediende code (voor elke programmeertaal zou bijvoorbeeld de optie kunnen voorzien worden om ook een linter te configureren)
- vertaling van onderdelen van testcases (variabelenamen, functienamen, messages, ...) en mogelijkheid om testcases specifiek aan natuurlijke taal te koppelen
- syntax highlighting van return value (doet de Python judge ook niet)
- korte beschrijving van feedback (top-level), bv
Alle testen geslaagd
Features die de generieke judge heeft, die Python judge niet ondersteunt:
- stack trace bij runtime errors consistent weergeven als
exception
channel - syntax highlighting van statement/expressie dat wordt uitgevoerd in testcase
- onafhankelijk uitvoeren van contexten
- parallel uitvoeren van contexten
- meegeven van invoer op
stdin
per context (en per testcase?) - verwachte uitvoer weergeven als er zich een timeout voordoet
- meegeven van command line argumenten bij het uitvoeren van de testcode voor een context
- mogelijkheid om individuele timeout in te stellen per context/testgeval?
from universal-judge.
Rapporteren van enkele crash-testen die ik bewust heb uitgevoerd:
- compilatiefout: correct opgevangen maar deel van de gerapporteerde compitatiefout verwijst naar interne keuken van de judge, in dit geval de naam dat aan het bestand gegeven wordt dat de ingediende oplossing bevat (
./submission.py
); rapportering over de compilatiefout wordt nu boven de tabs van de feedbacktabel gezet, maar misschien is het mooier als dit in een eigenCompile
tab gezet wordt (ik dacht dat de Java judge het zo doet, en dat vind ik properder); verwijzing naar regel in ingediende code zou ook effectief naar ingediende code kunnen doorlinken, zoals Python judge dat doet met runtime errors - runtime error: delen door nul: correct opgevangen maar deel van de gerapporteerde stack trace verwijst naar interne keuken van de judge (zie hoger) en verwijzing naar regels in de ingediende code zou ook effectief naar ingediende code kunnen doorlinken (zie vorige)
- oneindige lus die niets berekent: correct opgevangen met tijdslimiet overschreden, behalve dat de tijdslimiet voor deze oefening op 600s staat en het dus heel lang duurt om hierop feedback te krijgen als student; aanbeveling: tijdslimiet instellen op 15s (zoals dat het geval is voor de oorspronkelijke oefening)
- extra informatie uitgeschreven op
stdout
: niet opgevangen; omdat er niet expliciet "verwachte uitvoer" is opstdout
lijkt het erop dat alles wat opstdout
wordt uitgeschreven, genegeerd wordt; lijkt misschien beter om als default uit te gaan van lege uitvoer opstdout
, zodat alles wat toch wordt uitgeschreven als foutief aangeduid wordt - extra informatie uitgeschreven op
stderr
: correct opgevangen; dit lijkt me inconsistent met de afhandeling vanstdout
, en dus zou ik de twee gelijk behandelen:stdout
afhandelen zoalsstderr
nu afgehandeld wordt - extra informatie uitgeschreven op file descriptor 3: verkeerdelijk geïnterpreteerd als return value met nog een extra boodschap die niet te begrijpen valt (
Received spam , which caused Could not parse spam as valid json. Additional errors: for get_values.
) - oneindige lus die telkens één lange regel uitschrijft op
stdout
: resulteert in een interne fout; probeer maximale limiet te zetten op uitvoerbuffers, en zorg ervoor dat er slechts een deel daarvan wordt opgenomen in de feedbacktabel om de maximale grootte van de feedback niet te overschrijden; willen we in Dodona ook expliciet een status voor eenoutput buffer overflow
? - oneindige lus die telkens één korte regel uitschrijft: dit botst op tijdslimiet overschreden wat op zich correcte feedback, maar we zouden even goed ook kunnen rapporteren over de overflow aan uitvoer op
stdout
, of rapporteren over beide - oneindige lus die telkens een string verdubbelt: individuele testgevallen botsten op een tijdslimiet die wordt overschreden, maar de globale status van de feedback is
Fout
(Geen returnwaarde
); aangezien "tijdslimiet overschreden" een zwaardere fout lijkt dan "fout", zou ik denken dat we finaal de zwaarst opgetreden fout rapporteren; hoe wordt de globale status van de feedback trouwens bepaald?; ik had deze test uitgevoerd om te zien of we de geheugenlimiet niet zouden overschrijden, maar daarover wordt hier niet gerapporteerd (misschien omdat die is ingesteld op 500Mb?) - oneindige lus die telkens de elementen van een lijst verdubbelt: in de testgevallen van
is_isbn
(eerste tab) wordt niet gerappporteerd over de oneindige lus, wel bij een aantal individuele testgevallen vanare_isbn
(tweede tab); zou ook verwacht hebben dat de globale status van de feedback zou rapporteren over het feit dat de tijdslimiet is overschreden (in dit geval blijkbaar voor een aantal individuele testgevallen); hoe wordt de tijdslimiet voor het beoordelen van de ingediende oplossing verdeeld over de individuele testgevallen?; wat als een aantal testgevallen finaal niet konden beoordeeld worden wegens tijdslimiet overschreden? worden die nog weergegeven in de feedback? hebben we in Dodona nood aan een status voor niet-beoordeelde testgevallen, zodat die toch op een structurele manier kunnen meegenomen worden in de feedback (zie JavaScript judge) - code die zelf eindigt met exit status nul: correct opgevangen
- code die zelf eindigt met ``quit(): correct opgevangen
- code die zelf eindigt met exit status verschillend van nul: correct opgevangen in die zin dat er hier ook niet expliciet een "verwachte exit status" was, en het feit dat er een niet-nul exit status gegeven wordt dus ook geen impact heeft op de beoordeling; vraag is of we bijvoorbeeld niet willen uitgaan van een default exit status 0, en willen rapporteren als de exit status van de ingediende oplossing daarvan afwijkt (zoals bijvoorbeeld het geval is bij de
bash
judge); dit zou dan in lijn zijn met hoe we nustderr
afhandelen, en hoe we volgens mij ook beterstdout
zouden afhandelen - oneindige lus in alle testgevallen: bij vorige testen zat de oneindige lus slechts in één of een beperkt aantal testgevallen; in dit geval krijgt de student zelfs geen testgevallen meer te zien maar enkel een globale status timeout en de lesgever krijgt een extra boodschap Judge exited with status code 137; het lijkt me in dit geval beter om nog steeds alle testgevallen weer te geven aan de student, waarbij sommige testgevallen (waarvan de beoordeling gestart is) weer te geven met status
timeout
, en de testgevallen waarvan de beoordeling nog niet gestart was weer te geven met statusniet beoordeeld
/not tested
from universal-judge.
Rapporteren van enkele testen waarbij een foutief antwoord gegenereerd wordt:
- ander type teruggeven in plaats van bool: aanbevolen om in dit geval een extra boodschap bij de return-test te zetten die aangeeft dat de return-value niet het juiste type heeft; daarvoor is noodzakelijk om gegevenstype van return value (expected en actual) te kennen voor de programmeertaal waarvoor de oplossing werd ingediend
- grote hoeveelheid data teruggeven: aanbevolen om pretty printing te voorzien voor return values, waarbij bv. samengestelde gegevenstypes met veel elementen afgekort weergegeven worden, lange strings afgekort weergegeven worden, geneste datastructuren multiline met insprongen weergegegeven worden, ...
- uitvoer genereren op
sdout
naast teruggeven van het correcte antwoord: ingediende oplossing word niet fout gerekend; als er geenstdout
verwacht werd, maar er wordt er wel gegeneerd, dan zou de beoordeling dezelfde moeten zijn dan wanneer er een legestdout
verwacht wordt; althans dat lijkt me een intuïtieve default, waarbij eventueel met een parameter expliciet kan opgegeven worden dat er geen beoordeling dient te gebeuren vanstdout
- string teruggeven in plaats van boolean: string literal wordt niet als string literal (met single quotes) voorgesteld als return value, waardoor verwarring ontstaat waarom het antwoord verkeerd is
- float teruggeven: float literal als return value wordt weergegeven als een int, waarbij deel na de komma wordt afgekapt
- samengesteld gegevenstype teruggeven: elementen van samengesteld gegevenstype (list, tuple, set, ...) worden altijd als strings weergegeven
- lijst met getallen teruggeven: lijst met getallen wordt weergegeven als een lijst met de stringvoorstellingen van de getallen; dit is een voorbeeld van het voorgaande
- tuple met getallen teruggeven: tuple met getallen wordt weergegeven als een lijst met de stringvoorstellingen van de getallen
- tuple met één enkel element teruggeven: dit geeft ook een lijst terug (zie vorige), maar test werd uitgevoerd omdat in Python een tuple met één enkel element op een speciale manier wordt uitgeschreven (met een komma na het element)
- set met getallen teruggeven: bij pretty printing van verzameling, kunnen de elementen best in oplopende volgorde opgelijst worden, zodat vergelijking tussen expected/actual makkelijker wordt; in de python judge worden zelfs eerst de gemeenschappelijke elementen van expected/acual opgelijst, gevolgd door de unieke elementen van expected/actual
- dict teruggeven: interne fout als gevolg van runtime error in TESTed bij verwerken van dicts
- datetime.date object teruggeven: interne fout als gevolg van runtime error in TESTed bij verwerken van
datetime.date
object deze test was specifiek uitgevoerd om na te gaan hoe TESTed reageert om gegevenstypes die niet behoren tot de ondersteunde basistypes - multiline strings teruggeven: dit wordt nu effectief als een multiline string weergegeven, maar dit moet ook zo blijven wanneer string objecten die teruggegeven worden, effectief ook als een string voorgesteld worden
Aanbevelingen (standaard gedrag)
- extra boodschap weergeven als een resultaat verwacht was op een bepaald channel, terwijl er geen resultaat gegenereerd werd en antwoord ook fout rekenen
- extra boodschap weergeven als een resultaat gegenereerd was op een bepaald channel, terwijl er geen resultaat verwacht werd
- extra boodschap weergeven als gegevenstype van return value niet compatibel is met verwachte waarde en antwoord ook fout rekenen
- pretty printing van return values (expected en actual)
from universal-judge.
De meeste issues heb ik nu bekeken en opgelost, of ze zijn extra functionaliteit die opgenomen is in #40, met uitzondering van geheugenlimieten, waarvoor een andere issue bestaat: #37.
from universal-judge.
Related Issues (20)
- Support large numbers
- Conditional statements for specific programming language don't work
- Haskell compile options -O2
- Render Haskell arguments without brackets HOT 1
- Better dependency management
- Add formatter for TESTed
- Rename "rational" to "real"
- Rename test plan to test suite
- Add support for C# HOT 1
- Show prompt character for main calls
- Don't cast integers in C#
- DSL Configuration options at root not passed to evaluator
- Support value access for dictionaries/maps HOT 1
- Support for array access
- Support options for automated conversion of casings
- Merge contexts across tabs
- Run linting parallel to test processing
- Improve performance of feedback generation
- Analyse overhead for TESTed in Dodona HOT 9
- Add support for coverage information
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from universal-judge.