[robocheck-dev] Idei si intrebari

[Constantin Mihalache]

Oops. Am dat send la un mesaj gol. Moving on :)

Am mai facut un pull request pentru issue-ul deschis de Laura (cu metoda
din confoguration.py) si vreau mai departe sa implementez interfata pentru
tool-uri.

Intrebarea mea este daca abordarea cu abstract base class care sa fie
mostenit de fiecare tool e potrivita. Asta ar putea schimba si
modulehandler care in loc sa caute in fisiere dupa tool-urile potrivite ar
cauta prin clasele ce mostenesc interfata.

Constantin
On Jul 6, 2015 4:28 PM, "Constantin Mihalache" <mihalache.c94 at gmail.com>
wrote:

>
> On Jul 5, 2015 1:20 AM, "Andrei Tuicu" <andrei.tuicu at gmail.com> wrote:
> >
> > Imi cer scuze, am marcat cumva mailul ca citit fara sa raspund si am
> uitat ulterior. :)
> >
> > În data de 29 iunie 2015, 18:52, Laura Vasilescu <laura at rosedu.org> a
> scris:
> >>
> >> 2015-06-25 16:07 GMT+03:00 Constantin Mihalache <
> mihalache.c94 at gmail.com>:
> >> >     Am vazut ca pe wiki, la sectiunea Detected Errors, sunt cateva
> >> > puncte care sunt legate de coding style (number of lines in a function
> >> > exceeded maximum admitted, number of character in a line exceeded
> >> > maximum admitted, etc.) asa ca am implementat un modul pentru C
> >> > (codingstyle.py) care, deocamdata, verifica numarul de caractere de pe
> >> > o linie si numarul de linii din fiecare functie si returneaza o lista
> >> > de erori.
> >> >
> >> > Other things done:
> >> >     *am schimbat run-tests.sh conform issue-ului "Use pushd and
> popd..."
> >> >     *am adaugat un test pentru a verifica modulul codingstyle.py
> >> > (works as expected)
> >> >
> >> > Toate modificarile sunt in fork-ul asta [1].
> >>
> >>
> >> Sună foarte bine! Mă bucur că deja ai început chiar să și faci
> patch-uri! :)
> >> Singura observație e că codul respectiv poate duplică munca depusă și
> >> am prefera să ne bazăm cât mai mult pe tool-uri deja existente, if
> >> any.
> >>
> >> Spre exemplu, pentru a verifica coding style-ul în C ar exista mai
> >> multe variante, fiecare coding style având particularitățile lui. De
> >> regulă, la programare și SO se merge destul de mult pe linux kernel
> >> coding style care poate fi verificat rulând scriptul checkpatch.pl din
> >> tree-ul de kernel.
> >
> >
> > Este aici o mica lista de tool-uri ce planuiam sa le integram in
> robocheck:
> > https://github.com/rosedu/robocheck/wiki/tools
> >
> >>
> >>
> >>
> >> @RD: ai idee pe unde era tree-ul vechi cu sursele scrise în C? Aparent
> >> nu e niciun link către el pe wiki și ar fi fost util.
> >
> >
> > Found it: git://ixlabs.cs.pub.ro/robocheck.git
> >
> >> O referință cu niște tool-uri care erau integrate în versiunea
> >> respectivă ar fi lucrarea mea de licență (cap. 02):
> >> http://swarm.cs.pub.ro/~laura/p/bachelor-thesis/thesis.pdf
> >>
> >> > Nelamuriri:
> >> >     1. Nu stiu daca am gresit sau nu ca am scris eu parsarea surselor
> >> > si ca nu am integrat un tool care sa verifice chestii. (mi s-a parut
> >> > mai usor de controlat)
> >>
> >> See above. :D
> >> E întradevăr mai ușor de controlat, dar se poate ajunge la cod
> >> duplicat. De regulă tool-urile externe se modifică mai greu și
> >> mentenanța rămâne la ei.
> >>
> >>
> >> >     2. Daca abordarea mea e in regula, in fisierul codingstyle.py sunt
> >> > hardcodate la inceput numarul maxim de caractere pe linie si numarul
> >> > maxim de linii dintr-o functie si presupun ca ar trebui mutate intr-un
> >> > fisier de configurare or something. (any advice?)
> >>
> >> Ca idee generală, ar fi util să fie configurabile. Chiar dacă modulul
> >> este pentru C, aș vedea mai degrabă un astfel de modul care să fie
> >> configurabil per limbaj de programare (deci să nu stea în C, unless
> >> funcționalitatea nu e strict dependentă de C). Dacă funcționalitatea
> >> (în cazul ăsta lungimea linilor și a funcțiilor) nu depinde de limbaj,
> >> ar trebui ca și în repo să fie reflectat ca atare și să fie ușor de
> >> configurat. (deci dacă ar fi așa, nu ar mai fi checkpatch.pl din
> >> kernel)
> >
> >
> > Eu as vota totusi varianta cu checkpatch, deoarece verifica mai mult
> decat lungimea liniilor si a functiilor. :)
> > Daca ramane aceasta varianta, eu as sugera sa te uiti pe implementarile
> modulelor de DrMemory si Valgrind, sa vezi
> > cum sunt apelate si cum este strans output-ul lor si apoi sa
> implementezi un modul similar pentru checkpatch. Tin minte
> > ca voiam sa definesc o interfata comuna tuturor modulelor pentru a fi
> foarte clar ce trebuie implementat, dar nu mai stiu
> > daca am facut-o.
> >>
> >>
> >> >     3. Ar fi ok introducerea de unit-test-uri ?
> >>
> >>
> >> Ar fi chiar super! :)
> >
> >
> > +1 pentru unit teste. :)
> >>
> >>
> >> > Awaiting feedback,
> >>
> >> Scuze de delay, am fost plecată. O să fiu mai responsive. :)
> >>
> >> Laura
> >>
> >
> > Am facut merge la pull request-ul tau. Pe viitor, as recomanda sa creezi
> branch-uri pentru a putea face pull request-uri separate (ex. branch pt
> unit-teste, branch pt implementarea unui modul), astfel incat sa le putem
> face merge separat. :)
> >
> > Cheers,
> > Andrei
> >
> >
> > _______________________________________________
> > robocheck-dev mailing list
> > robocheck-dev at lists.rosedu.org
> > http://lists.rosedu.org/listinfo/robocheck-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosedu.org/pipermail/robocheck-dev/attachments/20150706/87395808/attachment-0001.html>