From lucian.grijincu at gmail.com  Thu Jul 24 18:00:22 2008
From: lucian.grijincu at gmail.com (Lucian Adrian Grijincu)
Date: Thu, 24 Jul 2008 18:00:22 +0300
Subject: [vmchecker-user] FYI: Discutii PT despre vmchecker
Message-ID: <acf3f2e60807240800w6276d82es11a8e174d31cd87b@mail.gmail.com>

Pentru posteritate forwardez o parte a mailurilor pe care le-am
schimbat cu Virgil ?nainte de ?nceputul vacan?ei.


---------- Forwarded message ----------
From: Virgil Palanciuc <virgil.palanciuc at gmail.com>
Date: Wed, Jun 25, 2008 at 09:49
Subject: Re: vmchecker - testare automatizat?
To: Lucian Adrian Grijincu <lucian.grijincu at gmail.com>
Cc: Bogdan Nitulescu <bogdannitulescu at yahoo.com>

[snip]

 In esenta - noi am avea nevoie sa ruleze un compilator facut de ei
(ne pot face "submit" doar de executabil, e ok).
 Din punctul meu de vedere, "cerintele" ideale pt PT ar fi cam
urmatoarele (discutam, daca voi aveati in plan sa faceti altceva):

1. Userul (studentul) se autentifica, face "submit" de un executabil;
acesta este pus intr-o locatie prestabilita si redenumit in mod
standard (e.g. "tema.bin")
2. Inainte de asta, asistentul sa poata cumva sa "configureze" tema
(sa puna un "fisier de configurare", in care sa scrie cum trebuie
rulat testul - pt. fiecare rulare, sa puna o linie de genul "tema.bin
-options /tests/t3/file1.in -o /results/file1.out", si  una sau mai
multe linii in care sa scrie cum se testeaza acea rulare - e.g.
"simulator /file1.out <my_data1 > my_results; compare my_results
my_reference1; simulator /file1.out <my_data2 >my_results; compare
my_results my_reference2")
3. Pe baza configurarii, se ruleaza pe rand tema studentului pe
fiecare test, si se testeaza daca rezultatele sunt corecte.
 3.a. Se ruleaza tema studentului ("tema.bin -options
/tests/t3/file1.in -o /results/file1.out"); se captureaza, in fisiere
diferite, stdout si stderr. Daca stderr nu e gol, se declara testul
"FAILED" si i se trimite studentului (ca feedback)  output-ul de pe
stdout si cel de pe stderr.
 3.b.  Daca pe stderr nu a fost scris nimic, se trece la rularea
liniilor de "simulare"; ultima linie din liniile de "simulare" va fi
cea care va produce un "raport sintetic", scriind pe stderr "ce teste
au picat" si pe stdout "ce teste au trecut"; statusul (FAIL/PASS) se
deduce din dimensiunea "fisierului" stderr (daca e gol, testul e
"passed")
 3.c. Pentru un test, i se trimit inapoi studentului:
        i. status (Failed/passed)
        ii. daca e "FAILED" in 3.a - output-ul lui de pe stderr + cel
de pe stdout
        iii. altfel, output-ul de pe stdout din pasul 3.a + ouput-ul
de stdout/stderr din pasul 3.b (cea care produce "raportul").
 3.d Daca status-ul e "passed", se trece la executarea urmatorului
test ( "tema.bin -options /tests/t3/file2.in -o /results/file2.out");

4. toate mesajele trimise studentului + binarul trimis de student, se
logheaza intr-un "history" al temei ( se tine minte si "cine a trimis
binarul", "data/ora")
5. Trebuie sa existe posibilitatea ca scripturile asistentului sa
modifice o "stare globala" care nu se reseteaza niciodata (e.g. sa
scrie undeva "de cate ori a incercat fiecare student sa testeze tema",
sa scrie chestii de genul "testul  1 a rulat in 1.2 s, testul 2 in 0,4
s samd")
6. Trebuie ca "ultima linie de simulare" (i.e. programul care produce
"raportul de test" sa poata accesa niste date globale, (ideal ar fi sa
fie stocate intr-o baza de date) - ca sa poata produce "on the fly"
clasamente (de ex., daca mai dam o tema ca T4 unde e 'competitie' pt.
100++, sa poata sa-i spuna studentului ca "programele optimizate de
tine au rulat in medie  in 231512 cicli, momentan esti pe locul 4";
eventual si sa-i spune "pe testul 1 ai cel mai bun timp, pe testul 2
esti pe locul 10; pe testul 3 pe locul 4 samd")

7. Aici e o cerinta mai "tricky": nu vreau sa poata studentii sa-si
"afiseze programul de intrare". Daca vrem sa stie testele, le publicam
noi.
  I.e., daca facem "concurs", nu e ok ca ei sa vada input-ul (daca ei
fac 'submit' cu un program de "echo", o sa le zicem 'failed' si atasam
programul de intrare) ... si atunci, trebuie sa putem filtra output-ul
lor pe baza de "regular expression" sau macar pe baza de "substring,
case-insensitive".
Ma gandesc ca vom pune o regula in care zicem, "se considera copiere
si luati 0/picati materia daca afisati programul de intrare pe STDOUT,
in scopul de a-l vedea" - dar as vrea si ceva care sa verifice
"automat" ( de ex. - sa punem numele variabilelor "vljklsdhautas" si
daca gasim acest string in output - sa se blocheze automat trimirea
output-ului catre student, si sa fie notificat asistentul pt. a vedea
daca studentul a incercat sa "triseze" sau pur si simplu a afisat de
ex o eroare de parsare (sa zicem ca nu si-a definit bine regula pt.
'identificator' si nu recunostea cuvantul "vljklsdhautas" ) ).

   Cam asta ar fi... sper ca nu am fost prea incoerent :), astept
sugestii/sa discutam cum altfel s-ar putea face.

  BTW, exista un server (utilizabil) care sa reziste la 50 de
submit-uri paralele?  Ca ma gandesc, ca nu e exclus ca in ziua de
dinainte de deadline, serverul ala sa fie super-incarcat... bine,
puteti sa faceti rularea testelor asincron (si asa trebuie facuta daca
vrem sa avem sanse sa nu pice serverul de web)... da' totusi, ar
trebui sa se termine intr-un timp decent testarea/rularea. Stiu ca
exista teoretic un super-mega calculator la dl. Cristea, da' nu stiu
daca avem voie sa-l folosim noi pt acest "test framework'


-- 
Lucian

From lucian.grijincu at gmail.com  Thu Jul 24 18:02:02 2008
From: lucian.grijincu at gmail.com (Lucian Adrian Grijincu)
Date: Thu, 24 Jul 2008 18:02:02 +0300
Subject: [vmchecker-user] FYI: Discutii PT despre vmchecker
Message-ID: <acf3f2e60807240802l64ed14f4i294542cd8dcd7c58@mail.gmail.com>

Part 2.


---------- Forwarded message ----------
From: Lucian Adrian Grijincu <lucian.grijincu at gmail.com>
Date: 2008/6/25
Subject: Re: vmchecker - testare automatizat?
To: Virgil Palanciuc <virgil.palanciuc at gmail.com>
Cc: Bogdan Nitulescu <bogdannitulescu at yahoo.com>


Cam cum merge acum sistemul de la SO (?i aproape sigur ?i PSO):
* ca la PT temele se trimit din interfa?a web de pe cs.pub.ro/~so
* o tem? trebuie s? aib? un Makefile cu ac?iunea "build" ?i s? creeze
un fi?ier executabil, o bibliotec?, etc. cu nume specificat ?n tem?.
* tema studentului e copiat? pe un vmware (care este pus ?i la
dispozi?ia studen?ilor - ei au pe calc. personale acela?i sistem cu al
nostru pentru testare).
* se copie pe vmware ?i sistemul de testare al temei respective.
* exist? un alt fi?ier Makefile (Makefile.checker) scris de asisten?ii
SO care este rulat dup? ce s-a rulat "build" din Makefile-ul
studentului. Makefile.checker compileaz? pe loc un tester (dac? e
nevoie) ?i execut? o serie de teste.
* dac? `make build` ?i `make -f Makefile.checker` ruleaz? cu succes ?i
se termin? ?n timpul alocat outputul testerului (stdout, stderr) este
trimis ?ntr-un fi?ier pe
so at cs.pub.ro:~/teme/ok/stud/$(NUME_STUDENT)/$(DATA_ORA_UPLOAD)/NOTA.
?n so at cs.pub.ro:~/teme/ok/stud/$(NUME_STUDENT)/$(DATA_ORA_UPLOAD) se
mai pune ?i con?inutul arhivei temei studentului.
* dup? ?nt?rzierile, warningurile din output ?n fi?ierul NOTA se scrie
punctajul maxim pe care l-ar putea lua acel student la acea tem?. ?n
sesiune asisten?ii mai scad ?n func?ie de implementare (nu se
elibereaz? resurse, erori neprinse de tester, etc.).
* ma?ina virtual? este restaurat? la versiunea original? pentru a nu
influen?a rezultatul testelor pt al?i studen?i.

?i acum punctual:

>  In esenta - noi am avea nevoie sa ruleze un compilator facut de ei (ne pot
> face "submit" doar de executabil, e ok).
>  Din punctul meu de vedere, "cerintele" ideale pt PT ar fi cam urmatoarele
> (discutam, daca voi aveati in plan sa faceti altceva):
>
> 1. Userul (studentul) se autentifica, face "submit" de un executabil; acesta
> este pus intr-o locatie prestabilita si redenumit in mod standard (e.g.
> "tema.bin")
Momentan fi?ierul executabil este creat cu Makefile. Cred c? e varianta corect?.

> 2. Inainte de asta, asistentul sa poata cumva sa "configureze" tema (sa puna
> un "fisier de configurare", in care sa scrie cum trebuie rulat testul - pt.
> fiecare rulare, sa puna o linie de genul "tema.bin -options
> /tests/t3/file1.in -o /results/file1.out", si  una sau mai multe linii in
> care sa scrie cum se testeaza acea rulare - e.g. "simulator /file1.out
> <my_data1 > my_results; compare my_results my_reference1; simulator
> /file1.out <my_data2 >my_results; compare my_results my_reference2")
Ficare tem? are Makefile.checker ?i ni?te fi?iere adi?ionale (tester,
input, output standard, etc.) scrise de echipa SO ?i care sunt puse la
dispozi?ia studen?ilor.

> 3. Pe baza configurarii, se ruleaza pe rand tema studentului pe fiecare
> test, si se testeaza daca rezultatele sunt corecte.
>  3.a. Se ruleaza tema studentului ("tema.bin -options /tests/t3/file1.in -o
> /results/file1.out"); se captureaza, in fisiere diferite, stdout si stderr.
> Daca stderr nu e gol, se declara testul "FAILED" si i se trimite studentului
> (ca feedback)  output-ul de pe stdout si cel de pe stderr.
>  3.b.  Daca pe stderr nu a fost scris nimic, se trece la rularea liniilor de
> "simulare"; ultima linie din liniile de "simulare" va fi cea care va produce
> un "raport sintetic", scriind pe stderr "ce teste au picat" si pe stdout "ce
> teste au trecut"; statusul (FAIL/PASS) se deduce din dimensiunea
> "fisierului" stderr (daca e gol, testul e "passed")
>  3.c. Pentru un test, i se trimit inapoi studentului:
>         i. status (Failed/passed)
>         ii. daca e "FAILED" in 3.a - output-ul lui de pe stderr + cel de pe
> stdout
>         iii. altfel, output-ul de pe stdout din pasul 3.a + ouput-ul de
> stdout/stderr din pasul 3.b (cea care produce "raportul").
>  3.d Daca status-ul e "passed", se trece la executarea urmatorului test (
> "tema.bin -options /tests/t3/file2.in -o /results/file2.out");

> 4. toate mesajele trimise studentului + binarul trimis de student, se
> logheaza intr-un "history" al temei ( se tine minte si "cine a trimis
> binarul", "data/ora")
aici sunt salvate sursele ?i log-ul testerului:
so at cs.pub.ro:~/teme/ok/stud/$(NUME_STUDENT)/$(DATA_ORA_UPLOAD)

> 5. Trebuie sa existe posibilitatea ca scripturile asistentului sa modifice o
> "stare globala" care nu se reseteaza niciodata (e.g. sa scrie undeva "de
> cate ori a incercat fiecare student sa testeze tema", sa scrie chestii de
> genul "testul  1 a rulat in 1.2 s, testul 2 in 0,4 s samd")
Se poate extinde. Momentan, dac? vrei un raport trebuie s? te ui?i ?n
toate variantele pe care le-a uploadat studentul (sunt p?strate toate
?i sunt verificate toate cu Moss - poate se trimit teme copiate pe
care le modific? c?t pot p?n? c?nd moss-ul le consider? suficient de
diferite. P?strarea tuturor variantelor ajut? ?i atunci studentul
trimite tema2 ?n locul temei1 din neaten?ie: se poate ?terge uploadul
gre?it ?i restaura ultima variant? la cea corect?.)

> 6. Trebuie ca "ultima linie de simulare" (i.e. programul care produce
> "raportul de test" sa poata accesa niste date globale, (ideal ar fi sa fie
> stocate intr-o baza de date) - ca sa poata produce "on the fly" clasamente
> (de ex., daca mai dam o tema ca T4 unde e 'competitie' pt. 100++, sa poata
> sa-i spuna studentului ca "programele optimizate de tine au rulat in medie
>  in 231512 cicli, momentan esti pe locul 4"; eventual si sa-i spune "pe
> testul 1 ai cel mai bun timp, pe testul 2 esti pe locul 10; pe testul 3 pe
> locul 4 samd")
Se poate extinde. Momentan exist? un tabel generat automat cu notele
maxime alte fiecarui student ?i outputul temei lui. Din nou, "notele
maxime" inseamn? notele generate pe baza testerului. Se mai scade pe
calitatea codului, buguri neprinse de checker, etc.

> 7. Aici e o cerinta mai "tricky": nu vreau sa poata studentii sa-si "afiseze
> programul de intrare". Daca vrem sa stie testele, le publicam noi.
>   I.e., daca facem "concurs", nu e ok ca ei sa vada input-ul (daca ei fac
> 'submit' cu un program de "echo", o sa le zicem 'failed' si atasam programul
> de intrare) ... si atunci, trebuie sa putem filtra output-ul lor pe baza de
> "regular expression" sau macar pe baza de "substring, case-insensitive".
> Ma gandesc ca vom pune o regula in care zicem, "se considera copiere si
> luati 0/picati materia daca afisati programul de intrare pe STDOUT, in
> scopul de a-l vedea" - dar as vrea si ceva care sa verifice "automat" ( de
> ex. - sa punem numele variabilelor "vljklsdhautas" si daca gasim acest
> string in output - sa se blocheze automat trimirea output-ului catre
> student, si sa fie notificat asistentul pt. a vedea daca studentul a
> incercat sa "triseze" sau pur si simplu a afisat de ex o eroare de parsare
> (sa zicem ca nu si-a definit bine regula pt. 'identificator' si nu
> recunostea cuvantul "vljklsdhautas" ) ).
Cred c? se poate ?i mai simplu: s? avem dou? seturi de teste:
* unele care verific? doar func?ionalitatea temei ?i
outputul/stderr-ul s? fie vizibile ?n log
* unele cu stdout=stderr=/dev/null - degeaba afi?eaz? ei outputul, noi
nu-l b?g?m ?n seam?.

>    Cam asta ar fi... sper ca nu am fost prea incoerent :), astept
> sugestii/sa discutam cum altfel s-ar putea face.
>
>   BTW, exista un server (utilizabil) care sa reziste la 50 de submit-uri
> paralele?  Ca ma gandesc, ca nu e exclus ca in ziua de dinainte de deadline,
> serverul ala sa fie super-incarcat... bine, puteti sa faceti rularea
> testelor asincron (si asa trebuie facuta daca vrem sa avem sanse sa nu pice
> serverul de web)... da' totusi, ar trebui sa se termine intr-un timp decent
> testarea/rularea. Stiu ca exista teoretic un super-mega calculator la dl.
> Cristea, da' nu stiu daca avem voie sa-l folosim noi pt acest "test
> framework'

Temele sunt puse intr-o coad?. Pe sistem e ?nregistrat? ora de upload
?i ?n func?ie de aceasta se calculeaz? penaliz?rile. Tema poate s? fie
corectat? f?r? nici o problem? cu c?teva ore dup? dac? sunt mul?i ?n
coad?. Noi avem un calc special la SO ?i PSO: sanctuary.cs.pub.ro care
nu face (cel pu?in nu ?tiu eu) alceva dec?t rulare de teste.


--
Lucian