Oefening: ISBN

[niknetniko]

• Implementeer testplan
• Test met bestaande implementaties
• Docker image in Dodona
• Judge in Dodona
• Voeg data en "channel" toe aan partieel outputformaat #16: channel aan output toevoegen, misschien iets als niknetniko/dodona@07eb031

[pdawyndt]

Als je de generieke judge enkel gebruikt voor het beoordelen van Python oefeningen, dan kan je wellicht voorlopig gewoon de python docker gebruiken.

[niknetniko]

Het is gebeurd!

[pdawyndt]

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?

[pdawyndt]

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 eigen Compile 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 op stdout lijkt het erop dat alles wat op stdout wordt uitgeschreven, genegeerd wordt; lijkt misschien beter om als default uit te gaan van lege uitvoer op stdout, zodat alles wat toch wordt uitgeschreven als foutief aangeduid wordt
• extra informatie uitgeschreven op stderr: correct opgevangen; dit lijkt me inconsistent met de afhandeling van stdout, en dus zou ik de twee gelijk behandelen: stdout afhandelen zoals stderr 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 een output 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 van are_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 nu stderr afhandelen, en hoe we volgens mij ook beter stdout 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 status niet beoordeeld/not tested

[pdawyndt]

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 geen stdout verwacht werd, maar er wordt er wel gegeneerd, dan zou de beoordeling dezelfde moeten zijn dan wanneer er een lege stdout 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 van stdout
• 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)

[niknetniko]

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.