[robocheck-dev] Idei si intrebari

Mon Jul 6 16:54:34 EEST 2015

În data de 6 iulie 2015, 16:41, Constantin Mihalache <
mihalache.c94 at gmail.com> a scris:

> 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.
>
Mie-mi place ideea de astract base class pentru tool-uri. Vad ca n-am
definit-o eu, asa ca o poti crea tu si sa faci si celelalte tool-uri sa o
mosteneasca.

Asta ar putea schimba si modulehandler care in loc sa caute in fisiere dupa
> tool-urile potrivite ar cauta prin clasele ce mostenesc interfata.

Aici nu stiu sa zic concret cum ar fi mai bine. Este un tradeoff intre a
importa toate modulele, a le instantia si a cauta prin instante sau a
 incarca dinamic doar modulele de care este nevoie. Poate Razvan sau Laura
au o recomandare sau o preferinta.

Dupa cum am scris si in comentariul la pull request, mie mi-ar placea
foarte mult sa avem, inainte de orice altceva, o suita de teste pe care sa
le putem rula si pentru care sa nu fie nevoie de inspectie vizuala pentru a
vedea daca au trecut/picat (daca tot ai venit cu ideea :P ). Privind
inapoi, ceea ce am scris eu, nu se pot numi teste. :) Of course, aceasta
este doar o recomandare si un best practice, imi dau seama ca este un
aspect un pic mai boring.

Cheers,
Andrei

> 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
>>
>
> _______________________________________________
> 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/33a8e01f/attachment.html>