Toekomstig werk

[pdawyndt]

Ik begin met de hoofdstuk 5 van de thesis te lezen, en wil graag een overzicht maken van "ontbrekende features die we halen uit analyse van bestaande judges" en "ontbrekende features om meertalige oefeningen te ondersteunen in Dodona". Voor mij ligt nu nog niet vast of dit uiteindelijk nog in hoofdstuk 5 moet komen, en ik vraag me op dit moment ook nog niet af of we de features wel willen en of we ze finaal ook moeten implementeren. Is in eerste plaats een boekhouding van ideeën die nog opkomen, en die eventueel kunnen meegenomen worden in een vervolgthesis of bij het verder afwerken van TESTed.

[pdawyndt]

ontbrekende features voor TESTed

Dit is een oplijsting van nice to haves en ideeën uit andere judges.

• domeinspecifieke taal als frontend voor testplan (eventueel meerdere DSLs voor verschillende types oefeningen)
• aanbieden van oefeningen in meerdere natuurlijke talen
  • feedback aangepast aan geselecteerde natuurlijke taal
  • naamgeving aangepast aan geselecteerde natuurlijke taal
  • boilerplate aangepast aan geselecteerde natuurlijke taal (en programmeertaal)
• tijds- en geheugenmetingen (per context)
  • Tijds
  • Geheugen
• analyse van tijds- en geheugencomplexiteit (asynchroon: feedback wordt later toegevoegd) (Measure/estimate complexity (time and memory) #522)
  • Tijds
  • Geheugen
• pretty printing voor (samengestelde) types: lijsten, sets, dictionaries, files, 2-dimsionale lijsten (zie Pretty print (nested) collections #350)
  • kan helpen bij het vergelijken van verwachte en gegenereerde resultaten (diff)
  • verkorte weergave van grote datastructuren (met mogelijkheid om die volledig te zien)
• statische code-analyse
  • introspection: examine classes, functions and keywords to know what they are, what they do and what they know (e.g. check if a function is defined recursively, check if for loop has been used, check if code contains at least three comment blocks) (zie Support custom static analysis #392)
• optionele contexten/testgevallen: als de context of het testgeval niet ondersteund wordt in een bepaalde programmeertaal, dan wordt die niet uitgevoerd, in plaats van meteen aan te geven dat de oefening de programmeertaal niet ondersteunt (zie Optional context / testcase #50)
• speciale soorten testgevallen:
  • testgevallen die niet getoond worden in de feedback (maar wel uitgevoerd)
  • testgevallen die niet uitgevoerd worden (maar wel getoond)
  • testgevallen waarvan het verwachte resultaat niet getoond wordt (om het antwoord niet weg te geven)
  • misschien worden bovenstaande enkel gebruikt om iets anders te tonen dan wat er uitgevoerd wordt
• compilatie eerst globaal (batchcompilatie), dan per tab (tabcompilatie - bestaat nog niet) en dan per context (contextcompilatie) uitvoeren; extra tussenstap levert tijdswinst op als bv. een functie niet geïmplementeerd werd (typisch getest in een afzonderlijke tab)
• bij het uitvoeren van de context zorgen dat de ingediende oplossing zo goed mogelijk afgeschermd wordt van:
  • andere testcode
  • bestanden voor TESTed en van andere contexten
• keten van partiële evaluatie (Partiële evaluaties met orakel #43)
• parallelle uitvoer van beoordelingen, niet enkel van ingediende oplossingen
• parallelle uitvoering van alle contexten, niet enkel van contexten binnen eenzelfde tab (zie Merge contexts across tabs #329)
• alle beoordeelde contexten tonen, als status “niet beoordeeld” ondersteund wordt door Dodona (zie issue bij Dodona)
• linting parallel uitvoeren met testen van juistheid (en eventueel andere types checks) (zie Run linting parallel to test processing #330)

[pdawyndt]

ontbrekende features voor Dodona

• beperking ondersteunde programmeertalen per oefening (liefst zoveel mogelijk geautomatiseerd, manueel door ontwikkelaar waar mogelijk)
• lesgever kan programmeertalen inperken (per cursus, reeks, oefening)
• gebruiker kan programmeertaal selecteren
• programmeertaal bijhouden per ingediende oplossing (voor opnieuw beoordelen, weergave en statistieken)
• natuurlijke taal bijhouden per ingediende oplossing (zelfde redenen als voor programmeertalen)
• aanpassen syntax highlighting van editor aan geselecteerde programmeertaal
• beschrijving van oefening past zich aan (e.g. terminologie gegevenstypes, voorbeelden) aan geselecteerde programmeertaal
• beschrijving van voorzieningen per programmeertaal (zou ook voor individuele judges nuttig zijn); oa. versie programmeertaal, oplijsting van beschikbare packages/libraries/modules, ... (eventueel ook OS voor judges); ik denk dat deze info voor alle gebruikers mag beschikbaar zijn (en uiteraard in alle ondersteunde natuurlijke talen)
• bij gebruik van het partieel outputformaat voor de feedback, de afgewerkte contexten zo snel mogelijk rapporteren aan gebruiker (interactievere gebruikerservaring)
• partieel outputformaat uitbreiden zodat een onderdeel van de feedback (tab, context, testgeval, test) later terug kan bezocht worden, bijvoorbeeld om bijkomende informatie toe te voegen; kan bijvoorbeeld geïmplementeerd worden door een optionele ID toe te voegen aan de onderdelen van de feedback
• dynamisch gegenereerde boilerplate voor een oefening op basis van gegeven natuurlijke taal en programmeertaal
• afzonderlijke threads voor verschillende types feedback (correctheid, linting, complexiteitsanalyse, ...); onderscheid maken tussen synchrone en asynchrone threads voor weergave feedback

[niknetniko]

Most if not all of these are either implemented or extracted to another issue.