[QGHG-it-dev-list] Zadatak 8 - ucitavanje kompleksa iz fajla
Nenad Korolija
nenadko at gmail.com
Wed Nov 30 15:06:09 CET 2022
Zvuci kao dobar plan! :)
On Wed, Nov 30, 2022 at 3:00 PM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>
> Ok, slazem se sa svim idejama oko testiranja. :-)
>
> Testiranje moze da bude prva stvar na koju cemo da se koncentrisemo kad
> zavrsimo ove zadatke koje imamo sada. Bilo bi lepo da ovo dosadasnje
> zavrsimo do nove godine, pa onda od januara da
> pripremimo ozbiljan test-suite koji ce da proverava sve ovo kako kazes.
>
> A do nove godine bi bilo dobro da pocistimo ove stvari koje imamo do sada,
> da bi gui mogao da pocne da radi (poslacu zaseban mail o tome na listu).
>
> :-)
> Marko
>
>
> Dr. Marko Vojinovic
> Group for Gravitation, Particles and Fields
> Institute of Physics
> University of Belgrade
> ======================
> home page: www.markovojinovic.com
> e-mail: vmarko at ipb.ac.rs
>
>
>
> On Mon, 28 Nov 2022, Nenad Korolija wrote:
>
> > Cak i za find_neighbor, mozemo da definisemo kompleks i znamo sta
> mozemo, a sta ne da nadjemo.
> > Za add_neighbor mozemo da testiramo na nekoliko slucajeva da li radi to
> sto treba da radi - da li ih je povezala u oba smera.
> > Za golden complex, collect_vertices treba za pojedine cvorove da vrati
> pojedine skupove.
> > print i print_compact se testiraju poredjenjem output-a sa zakucanim. :)
> > get_uniqueID trazenjem da li samo za one za koje treba vraca da su
> uniqueID obojeni.
> > delete_my_neighbor proverom brisanja susedstva, itd.
> > To su zapravo standardni nacini testiranja koji imaju cilj da uhvate
> trenutak kad neko nenamerno menjanjem necega izazove bag na skroz drugom
> mestu - bolje je odmah na tih 10-ak novih
> > linija koda videti sta se desilo, nego naici slucajno na gresku nakon
> 1000 promenjenih linija...
> >
> > Vidimo se,
> > Nenad
> >
> > On Mon, Nov 28, 2022 at 5:01 PM Marko Vojinovic <vmarko at ipb.ac.rs>
> wrote:
> >
> > Ok, slazem se, to je dobra ideja, i to mozemo uvek (ili zamalo
> uvek).
> >
> > Znaci, za svaku funkciju koja radi na kompleksu neku dobro
> definisanu operaciju --- osmislimo prototip primer za testiranje,
> seed-ujemo neki odgovarajuci pocetni kompleks,
> > uradimo print_detailed() da dobijemo strukturu "pre", izvrsimo
> funkciju koju treba testirati, uradimo opet print_detailed() da dobijemo
> strukturu "posle", i onda to sve
> > uporedimo sa predefinisanim zlatnim primerima za "pre" i "posle".
> Ako se poklapa, f-ja radi svoj posao. :-)
> >
> > Takve testove mozemo da uradimo za pristojno veliki broj stvari:
> > - seed f-je,
> > - Pachner-ove poteze i ostale manipulacije nad kompleksom,
> > - I/O f-je,
> > - dodavanje i brisanje boja.
> >
> > Jedino f-je u osnovnim klasama (SimpComp i KSimplex) su mozda
> suvise "elementarne" da bi imale output koji moze da se ispise na ekran
> itd. Ali takvih valjda nemamo puno,
> > njih mozemo da tretiramo kao izuzetke i da smislimo za njih neke
> specijalnije testove.
> >
> > :-)
> > Marko
> >
> >
> > Dr. Marko Vojinovic
> > Group for Gravitation, Particles and Fields
> > Institute of Physics
> > University of Belgrade
> > ======================
> > home page: www.markovojinovic.com
> > e-mail: vmarko at ipb.ac.rs
> >
> >
> >
> > On Mon, 28 Nov 2022, Nenad Korolija wrote:
> >
> > > U potpunosti se slazem.
> > >
> > > Sto se tice testiranja, ne moramo da izmisljamo toplu vodu.
> Ljudi se bave debagovanjem debagera, i ako oni testiraju tako sto imaju
> pozive neke funkcije sa vise input-a i
> > proveru da li
> > > su rezultati isti kao sto su ranije bili... :)
> > > Dakle, jednom provereno crtanjem na papiru/ekranu postaje zlatni
> primerak, print detailed snimamo u txt i svaki put ocekujemo taj izlaz. Ako
> neko promeni redosled sa
> > dovoljnim razlogom,
> > > napravi se novi zlatni izlaz za svaku od funkcija koje pogadja.
> :)
> > >
> > > Pozdrav,
> > > Nenad
> > >
> > > On Mon, Nov 28, 2022 at 1:11 PM Marko Vojinovic <
> vmarko at ipb.ac.rs> wrote:
> > >
> > > Imalo bi smisla da implementiramo raznorazne f-je unutar
> test.cpp, koje bi testirale raznorazne funkcionalnosti (na neki nacin koji
> definisemo). I onda mozemo da
> > pozovemo
> > > neku od tih test-funkcija bilo iz main(), bilo da
> napravimo neku malu standalone tester-aplikaciju koja ce da prodje kroz sve
> f-je i kaze nam da li je sve ok ili
> > nije.
> > >
> > > Takodje, uskoro cemo povezati biblioteku sa gui-jem, i
> onda ce se iz gui-ja neke greske relativno ocigledno videti ako se pojave.
> Jedna od poenti gui-ja je da
> > "upotrebljava"
> > > sve funkcionalnosti biblioteke, pa bi dobar broj gresaka
> trebalo da se uoci i na taj nacin.
> > >
> > > I trece, pri kraju smo sa ovim osnovnim funkcijama za
> kreiranje i low-level manipulaciju kompleksima. Kad zavrsimo ove zadatke
> koji su zadati dosad, trudicemo se da
> > vise ne
> > > cackamo postojeci (testirani) kod, nego da nadalje pravimo
> samo high-level funkcije koje ce da se oslanjaju na ove low-level f-je, ali
> nece da zahtevaju njihovu
> > modifikaciju
> > > ili sl.
> > >
> > > Ono sto je glavni problem u celoj prici sa testiranjem je
> sto u velikom broju slucajeva ne postoje dobro-definisani testovi koje
> treba izvesti. Test
> > snimaj-citaj-snimaj za
> > > I/O je jedan od retkih primera gde moze eksplicitno da se
> proveri da li sve radi kako treba. Za veliku vecinu stvari uopste ne umem
> da osmislim kako da formulisemo
> > test,
> > > osim ovako kako smo dosad radili --- da za svaku f-ju
> ponaosob napravimo neki mini-primer upotrebe u main()-u, ispisemo output na
> stdout, i onda pogledamo da li taj
> > output
> > > ima smisla.
> > >
> > > Na primer, nacin na sam ja testirao f-je za seed-ovanje je
> sledeci:
> > >
> > > (1) seed-ujes npr. sferu za D=3,
> > > (2) pozoves print_detailed() da ti ispise celu strukturu
> na ekran,
> > > (3) uzmes papir i olovku i nacrtas sve nodove, linije,
> trouglove i ostalo, pa proveris da li taj crtez odgovara matematickoj
> definiciji 3-sfere.
> > >
> > > Jasno, za korak (3) ne postoji algoritam. Gui ce u nekom
> trenutku umeti da mi nacrta to, pa mi nece trebati papir i olovka, ali
> automatski test (koji bi dao output
> > "radi/ne
> > > radi") ne vidim bas kako da napravimo. :-)
> > >
> > > Sve u svemu, za sada "testiram" celu stvar tako sto
> eksplicitno citam kod, gledam da li algoritam radi ono sto ocekujem da
> radi, i da li ima nekih corner-case-ova na
> > koje
> > > treba obratiti paznju. Ako imate bilo kakvu ideju za bilo
> sta inteligentnije, slobodno javljajte! ;-)
> > >
> > > :-)
> > > Marko
> > >
> > >
> > > Dr. Marko Vojinovic
> > > Group for Gravitation, Particles and Fields
> > > Institute of Physics
> > > University of Belgrade
> > > ======================
> > > home page: www.markovojinovic.com
> > > e-mail: vmarko at ipb.ac.rs
> > >
> > >
> > >
> > > On Sat, 26 Nov 2022, Nenad Korolija wrote:
> > >
> > > > Sve vise mislim da nam trebaju testovi, tako da se lako
> primeti ako neko polomi staru funkcionalnost (najcesce covek polomi
> svoju:)...
> > > >
> > > > On Sat, Nov 26, 2022 at 10:32 AM Marko Vojinovic <
> vmarko at ipb.ac.rs> wrote:
> > > >
> > > > Hmm, mozda sam ovo kazao malo preuranjeno:
> > > >
> > > > > Inace, koliko mogu da vidim i koliko smo Nenad i
> ja testirali kod, f-ja
> > > > > add_neighbor() radi tacno ono sto bi trebalo da
> radi --- dodeljuje jedan
> > > > > simpleks kao sused drugom, i obratno (jer je
> susedstvo simetricna relacija).
> > > >
> > > > Tacno je da add_neighbor() radi upravo to, ali
> osim toga je i rekurzivno dodavala podsimplekse, a za to nisam bas skroz
> siguran da je radilo kako treba. Pa
> > sam zato
> > > > prepravio celu f-ju, izbacio rekurziju, i malo
> eksplicitnije organizovao algoritam za dodavanje podsuseda, tako da sada
> vise ne bi smelo da bude nikakvog
> > > nepredvidjenog
> > > > ponasanja te f-je. Takodje sam dodao i proveru
> slucajeva kada su simpleksi jednaki i kada su istog nivoa, i f-ja sada
> prijavljuje eksplicitne greske u tim
> > > slucajevima.
> > > >
> > > > Probaj dakle sada da reprodukujes taj famozni bag,
> da li se i dalje pojavljuje --- gledaj u output od print_detailed(),
> uporedjuj to sa snimljenim .xml
> > fajlom iz
> > > koga citas
> > > > kompleks, pa ako se i dalje nesto ne slaze,
> posalji mi oba fajla (i output od print_detailed() i .xml fajl) da pogledam
> u cemu je problem.
> > > >
> > > > :-)
> > > > Marko
> > > >
> > > >
> > > > Dr. Marko Vojinovic
> > > > Group for Gravitation, Particles and Fields
> > > > Institute of Physics
> > > > University of Belgrade
> > > > ======================
> > > > home page: www.markovojinovic.com
> > > > e-mail: vmarko at ipb.ac.rs
> > > >
> > > >
> > > >
> > > > On Sat, 26 Nov 2022, Marko Vojinovic wrote:
> > > >
> > > > >
> > > > > Pozdrav Dusane,
> > > > >
> > > > > Hvala za popravke. :-)
> > > > >
> > > > > Za curenje memorije nemoj da brines za sada ---
> kad budemo zavrsili sa
> > > > > konstrukcijom svih "elementarnih" funkcija (onih
> koje eksplicitno pozivaju
> > > > > "new" ili "delete"), onda cemo Nenad i ja da
> uradimo jednu temeljnu proveru
> > > > > svih curenja memorije i da sve zapusimo. Kad se
> to zavrsi, plan je da sve
> > > > > naredne funkcije koje cemo pisati budu
> "izvedene" iz ovih elementarnih, i u
> > > > > njima se nikad nista ne alocira "rucno", pa
> curenja memorije vise nece
> > > > > biti...
> > > > >
> > > > > Za delimiter kapiram sta je i cemu ti sluzi,
> nego sam propustio da vidim
> > > > > definiciju u .hpp fajlu. :-) Ali sam se vise
> zbunio oko toga kako kompajler
> > > > > hoce da prihvati pozivanje f-je sa samo tri
> argumenta, ako je ona deklarisana
> > > > > i definisana da ih bude cetiri... Ali ok,
> izgleda je C++ tu fleksibilan,
> > > > > dokle god je cetvrti parametar eksplicitno
> definisan u .hpp fajlu. To nisam
> > > > > znao da moze.
> > > > >
> > > > > Switch/case struktura u
> colorize_node_from_string() se ni meni ne svidja, ali
> > > > > neka je tako za sada --- radi nam posao, a
> momentalno imamo vaznije stvari da
> > > > > resavamo, na to mozemo da se vratimo kasnije.
> > > > >
> > > > > Sto se tice baga sa UniqueID bojom, nemam nista
> protiv da to popravis
> > > > > kasnije, samo nemoj da zaboravis --- naznaci u
> kodu u komentaru da to treba
> > > > > da se popravi, i kako (stavi zakomentarenu
> ispravnu verziju koda, da posle ne
> > > > > razmisljamo sta i kako treba da se uradi na tom
> mestu).
> > > > >
> > > > > A sto se tice ovog baga sa susedima i
> add_neighbor() na koji se zalis ---
> > > > > onaj fajl output.txt koji si mi poslao je
> previse nepregledan, nista nisam
> > > > > uspeo da vidim odatle. Pa sam zato sad
> implementirao f-ju
> > > > >
> > > > > SimpComp::print_detailed()
> > > > >
> > > > > koja na lep i pregledan nacin ispisuje ceo
> simplicijalni kompleks, sa svim
> > > > > detaljima, bojama i susedima svih simpleksa,
> tako da moze cela struktura lepo
> > > > > da se vidi, procita i prekontrolise. Pa bi bilo
> dobro da git merge-ujes
> > > > > najnoviji main branch u svoj 8_XML_reading
> branch, i onda mi posalji output
> > > > > od print_detailed() kad reprodukujes bag, da
> mozemo lepo da vidimo sta se tu
> > > > > tacno dogadja sa susedima.
> > > > >
> > > > > Inace, koliko mogu da vidim i koliko smo Nenad i
> ja testirali kod, f-ja
> > > > > add_neighbor() radi tacno ono sto bi trebalo da
> radi --- dodeljuje jedan
> > > > > simpleks kao sused drugom, i obratno (jer je
> susedstvo simetricna relacija).
> > > > > E sad, ako joj trazis da stavi simpleks kao
> sused samom sebi, to je tvoj
> > > > > problem, tj. add_neighbor() nije kriva za to.
> Mozda bismo mogli da unapredimo
> > > > > add_neighbor() da proverava i prijavljuje gresku
> ako korisnik pokusava da
> > > > > poveze simpleks sa samim sobom (ili sa drugim
> simpleksima istog nivoa), ali
> > > > > to ce samo da maskira pravi problem koji se
> nalazi negde drugo --- ti
> > > > > generalno nikad ne bi smeo da dodjes u situaciju
> da se simpleks povezuje kao
> > > > > sused sa samim sobom, bez obzira da li ce
> add_neighbor() to pristati da ti
> > > > > uradi ili ne.
> > > > >
> > > > > Ali 'ajde da vidimo tacno sta radi bag, pa cemo
> da utrejsujemo gde je zapravo
> > > > > greska... ;-)
> > > > >
> > > > > I za kraj --- videh da si u triangulator.hpp
> dodao ovo:
> > > > >
> > > > > class KSimplex; // Had to do a
> predeclaration because is used in
> > > > > get_color_from_str
> > > > >
> > > > > To je visak, obrisi to odatle. Ista ta
> forward-deklaracija se vec nalazi na
> > > > > pocetku fajla color.hpp (odmah iza #ifndef -
> #endif strukture), i sigurno ne
> > > > > treba da stoji u triangulator.hpp fajlu --- tu
> treba da stoje samo ostale
> > > > > #include direktive. A forward-deklaracije mozes
> da stavljas u ostale .hpp
> > > > > fajlove gde ti je potrebno, i *ako* ti je
> potrebno. Naime, redosled #include
> > > > > direktiva u triangulator.hpp fajlu je tako
> namesten da smo vec pokrili sve
> > > > > neophodne forward-deklaracije, ne vidim gde jos
> moze da ti zafali neka.
> > > > >
> > > > > Btw, nisam nasao f-ju get_color_from_str() nigde
> u tvom kodu, jel' to typo u
> > > > > komentaru? Odnosno jesi mislio mozda na f-ju
> get_color_value_as_str(), iz
> > > > > klase Color?
> > > > >
> > > > > :-)
> > > > > Marko
> > > > >
> > > > >
> > > > > Dr. Marko Vojinovic
> > > > > Group for Gravitation, Particles and Fields
> > > > > Institute of Physics
> > > > > University of Belgrade
> > > > > ======================
> > > > > home page: www.markovojinovic.com
> > > > > e-mail: vmarko at ipb.ac.rs
> > > > >
> > > > >
> > > > >
> > > > > On Thu, 24 Nov 2022, Dušan Cvijetić wrote:
> > > > >
> > > > >> Pozdrav,
> > > > >>
> > > > >> Ubacio sam komentare i doxygen dokumentaciju u
> svoj kod. Javite da li ste
> > > > >> zadovoljni time, ili da menjam.
> > > > >>
> > > > >> Proverio sam curenja memorije pomoću
> Valgrind-a. Bilo ih je nekoliko u I/O
> > > > >> delu, to bi trebalo da je sada sređeno. Postoji
> još curenja, ali čini mi se
> > > > >> da su ona u klasi za boje, pa bi valjalo da još
> neko to pogleda i proveri,
> > > > >> jer nisam mnogo radio sa Valgrind-om.
> > > > >>
> > > > >> Sad, kod:
> > > > >>
> > > > >> (1) Uklonjeno, bilo je višak.
> > > > >>
> > > > >> (2) "Nepostojeći" argument u oba slučaja je
> string koji predstavlja
> > > > >> delimiter između elemenata niza, a u .hpp fajlu
> mu je zadata default
> > > > >> vrednost ",". Napravio sam tako da bi funkcija
> bila fleksibilnija pri
> > > > >> eventualnim kasnijim dodavanjima drugih
> formata. Dodao sam objašnjenje u
> > > > >> komentar, pa bi trebalo da bude jasnije šta se
> dešava.
> > > > >>
> > > > >> (3) Slažem se, provera je suvišna i uklonio sam
> je.
> > > > >>
> > > > >> (4) Uradio po predlogu, ali svakako mislim da
> treba da nađemo rešenje koje
> > > > >> izbegava switch u nekom momentu.
> > > > >>
> > > > >> Po pitanju (5) nisam ništa uradio. Postoji
> nepovezana greška koja se
> > > > >> provlači još od prethodne verzije. Proverio sam
> da li problem 5 utiče na
> > > > >> ovu grešku, i nema razlike ni kada unesem
> ispravku iz prethodnog mejla, pa
> > > > >> sam ostavio za sad da bude kao i ranije, jer je
> preglednije šta se dešava.
> > > > >>
> > > > >> Već par sati pokušavam da provalim gde leži
> bag, ali mi se trenutno čini da
> > > > >> nije u I/O kodu, već u funkciji add_neighbor().
> Dodao sam u funkciju
> > > > >> read_ksimplex_node() deo koji štampa izgled
> kompleksa nakon svakog
> > > > >> dodavanja komšije nekom simpleksu, i izlaz koji
> sam dobio je u fajlu
> > > > >> output.txt u prilogu. Da li add_neighbor() radi
> kako treba? Neki simpleksi
> > > > >> su ovde dodati da sami sebi budu komšije, iako
> to nigde nisam eksplicitno
> > > > >> tražio. Čini mi se da ova funkcija uvodi neku
> međuzavisnost kod komšija
> > > > >> koja mi nije očekivana ni trivijalna.
> > > > >>
> > > > >> Može li još neko da pogleda ovaj problem?
> > > > >>
> > > > >> Pozdravi,
> > > > >> Dušan
> > > > >>
> > > > >>
> > > > >> On 20/11/2022 10:57, Marko Vojinovic wrote:
> > > > >>>
> > > > >>> Pozdrav Dusane,
> > > > >>>
> > > > >>> Evo pogledao sam I/O kod --- nisam ga jos
> testirao, ali ovako iz citanja i
> > > > >>> pregledanja mogu da ti dam par komentara i
> saveta.
> > > > >>>
> > > > >>> Prvo, kod je super! :-) To sto je dugacak nema
> veze, i to sto treba
> > > > >>> pocistiti detalje oko error-handling i memory
> leaks nije veliki problem.
> > > > >>> Odlicno si uradio posao, svaka cast! ;-)
> > > > >>>
> > > > >>> Drugo, buduci da je kod relativno dugacak,
> bilo bi pametno da ubacis
> > > > >>> komentare --- osnovnu ideju, bazicnu strukturu
> .xml fajla koji se
> > > > >>> snima/ucitava, kao i cemu koji deo koda sluzi
> i sta radi, u glavnim
> > > > >>> crtama. To je potrebno za slucaj da se kasnije
> vratimo na taj kod (bilo
> > > > >>> ti, bilo neko drugi), da bi bilo jasno sta se
> dogadja i kojim redom.
> > > > >>> Komentare bi bilo dobro da ubacis dok ti je
> cela stvar sveza u glavi, jer
> > > > >>> posle nece ni tebi biti jasno sta si tu sve
> radio... ;-) Inace, i ja
> > > > >>> planiram ovih dana da ubacim gooomilu
> komentara u ceo dosad napisani kod
> > > > >>> projekta, da sve bude bolje i jasnije
> objasnjeno i dokumentovano.
> > > > >>>
> > > > >>> Trece, ima par sitnih detalja koje mozes malo
> da pocistis u kodu, u f-ji
> > > > >>> read_complex_from_xml_file(
> rapidxml::xml_document<>& doc ):
> > > > >>>
> > > > >>> (1) Negde na sredini f-je stoji "bool first =
> true;" pri cemu se
> > > > >>> varijabla first nigde kasnije ne koristi.
> Pretpostavljam da je to visak?
> > > > >>>
> > > > >>> (2) Pri kraju f-je u petlji pozivas dve f-je,
> > > > >>>
> > > > >>> read_level_node(current_node, sc,
> > > > >>>
> stoi(current_node->first_attribute()->value()));
> > > > >>> read_ksimplex_node(current_node, sc);
> > > > >>>
> > > > >>> koje imaju redom tri odnosno dva argumenta, a
> nize si te iste dve f-je
> > > > >>> definisao kao
> > > > >>>
> > > > >>> void read_level_node(rapidxml::xml_node<>*
> node, SimpComp* sc, int
> > > > >>> level, string delimiter)
> > > > >>> void
> read_ksimplex_node(rapidxml::xml_node<>* node, SimpComp* sc,
> > > > >>> string delimiter)
> > > > >>>
> > > > >>> tako da imaju cetiri odnosno tri argumenta.
> Taj dodatni nepostojeci
> > > > >>> argument (string delimiter) se onda
> eksplicitno prosledjuje f-ji
> > > > >>> parse_level(), koja ga koristi (na
> netrivijalan nacin). Nije mi jasno kako
> > > > >>> ovo uopste hoce da se kompajlira (broj
> argumenata u f-jama se ne slaze), i
> > > > >>> nije mi jasno gde je "delimiter" zapravo
> definisan? Ako je on neka
> > > > >>> globalna varijabla unutar namespace rapidxml
> ili nesto tako, zasto ga onda
> > > > >>> prosledjujes eksplicitno kao argument u
> parse_level(), a to isto ne radis
> > > > >>> u read_level_node() i read_ksimplex_node()?
> Kako to sve zapravo radi?
> > > > >>>
> > > > >>> (3) Na samom kraju f-je, u poslednjoj petlji,
> brises privremene UniqueID
> > > > >>> boje. Nisam siguran da li ti treba provera "if
> (!ks->colors.empty())", jer
> > > > >>> bi svaki simpleks trebalo da ima taj
> privremeni ID. Naime, kad si snimao
> > > > >>> fajl, f-jom save_complex_to_xml_file(), odmah
> na pocetku si uradio
> > > > >>>
> > > > >>>
> UniqueIDColor::colorize_entire_complex(simpComp);
> > > > >>>
> > > > >>> sto je obojilo bukvalno sve simplekse. Kada
> posle radis
> > > > >>> read_complex_from_xml_file(), ti zapravo citas
> bas te brojeve (privremene
> > > > >>> id-jeve), i struktura snimljenog fajla bi
> trebalo da ti garantuje da svaki
> > > > >>> simpleks u novokreiranom kompleksu sigurno ima
> makar tu boju, ako nista
> > > > >>> drugo. Pa zato ne vidim da li postoji
> situacija kada uslov "if
> > > > >>> (!ks->colors.empty())" nije zadovoljen?
> > > > >>>
> > > > >>> Cetvrta tema --- pitanje sta uciniti sa f-jom
> colorize_node(). Moj predlog
> > > > >>> je sledeci. Prvo, po nekoj ideji dizajna, f-je
> za I/O treba da budu
> > > > >>> agnostic o tipovima i vrednostima boja, i
> slicnim detaljima --- krajnji
> > > > >>> korisnik ce mozda zeleti da definise svoje
> custom boje, i da ih snima i
> > > > >>> cita iz fajlova, ali mi sigurno ne zelimo da
> krajnji korisnik ceprka po
> > > > >>> kodu I/O f-ja da bi mu to radilo. Za snimanje
> u fajl imamo lepo resenje
> > > > >>> --- svaka boja u klasi Color ima definisanu
> f-ju get_color_value_as_str(),
> > > > >>> i ti to koristis kada snimas boju u fajl, tako
> da te uopste ne zanima kako
> > > > >>> je definisana vrednost boje (to je prosto neki
> string koji ces da snimis).
> > > > >>>
> > > > >>> Istu filozofiju treba primeniti i u slucaju
> citanja iz fajla, na sledeci
> > > > >>> nacin --- prepravi f-ju colorize_node() tako
> da bude prosto wrapper f-ja
> > > > >>> koja ce da poziva novu f-ju,
> > > > >>>
> > > > >>> void Color::colorize_node_from_string(
> KSimplex* ks, int color_type,
> > > > >>> string color_value );
> > > > >>>
> > > > >>> i samo toj f-ji prosledi pointer ks i parametre
> > > > >>>
> > > > >>> int color_type =
> stoi(color_node->first_attribute()->value());
> > > > >>> string color_value = color_node->value();
> > > > >>>
> > > > >>> pa ce posao te f-je da bude da oboji simpleks
> kako treba, a ti samo
> > > > >>> zavrsis colorize_node() f-ju. Pritom, celu
> switch/case strukturu preseli u
> > > > >>> tu novu f-ju --- ona ce da zivi u klasi Color
> (prebaci je u color.cpp i
> > > > >>> color.hpp fajlove), i nju ce krajnji korisnik
> moci da azurira kada/ako
> > > > >>> bude dodavao svoje custom boje.
> > > > >>>
> > > > >>> Ovakvim wrapper-zahvatom postizemo dve stvari:
> (a) dodavanje novih boja
> > > > >>> vise nema direktne veze sa I/O f-jama, nego se
> vrsi samo modifikovanjem
> > > > >>> f-ja u klasi Color, i (b) kasnije cemo mozda
> switch/case strukturu da
> > > > >>> zamenimo necim inteligentnijim, mozda za svaku
> boju da zahtevamo da ima
> > > > >>> definisanu f-ju set_color_value_from_str(),
> poput ove koju si uveo za
> > > > >>> ScreenCoordinateColor, itdisl. Generalno, to
> sve dalje vise nije tvoj
> > > > >>> problem (za I/O f-je), a klasu Color cemo
> verovatno jos dosta da
> > > > >>> (re)dizajniramo i doterujemo kasnije (bilo ti,
> bilo neko drugi, bilo
> > > > >>> krajnji korisnik, o tom potom)...
> > > > >>>
> > > > >>> Mislim da bi ovakav dizajn bio generalno
> mudriji, pa vidi da tako
> > > > >>> reorganizujes taj kod.
> > > > >>>
> > > > >>> I konacno, peta tema --- cini mi se da sam
> pronasao i jedan mali bag.
> > > > >>> Naime, u switch/case strukturi unutar
> colorize_node() imas izmedju ostalog
> > > > >>> i sledeci kod:
> > > > >>>
> > > > >>> case TYPE_UNIQUE_ID:
> > > > >>> color = new
> UniqueIDColor(stoi(color_node->value()));
> > > > >>>
> ks->colors.push_back(static_cast<UniqueIDColor*>(color));
> > > > >>> break;
> > > > >>>
> > > > >>> koji se izvrsava ako je snimljeni kompleks
> imao neke simplekse obojene
> > > > >>> UniqueID bojama. Kada u nekoj kasnijoj sesiji
> (neki drugi main(), tj.
> > > > >>> drugi program) ucitavas taj fajl i konstruises
> novi kompleks, moze da se
> > > > >>> desi da su te snimljene UniqueID boje (iz
> fajla) vec iskoriscene za neki
> > > > >>> drugi kompleks (seed-ovan ranije u ovoj novoj
> sesiji), sto vodi do
> > > > >>> dupliranja UniqueID boja, sto ne sme da nam se
> dogodi. :-)
> > > > >>>
> > > > >>> Ovo dakle mora da se popravi, tako sto se dati
> simpleks ne oboji UniqueID
> > > > >>> bojom koja je procitana iz fajla, nego mu se
> dodeli prvi slobodan UniqueID
> > > > >>> iz tekuce sesije, ovako:
> > > > >>>
> > > > >>> case TYPE_UNIQUE_ID:
> > > > >>> ks->colors.push_back(new
> UniqueIDColor());
> > > > >>> break;
> > > > >>>
> > > > >>> Jasno, tada vrednosti id-jeva za kompleks vise
> nece da se poklapaju sa
> > > > >>> id-jevima koji pisu u fajlu. Ali to sto se ne
> poklapaju niti moze da se
> > > > >>> garantuje, niti je vazno --- vazno je samo da
> su jedinstveni, tj. da nema
> > > > >>> preklapanja ni sa jednim drugim simpleksom
> koji je trenutno u memoriji.
> > > > >>> Tako da obavezno popravi i taj detalj. ;-)
> > > > >>>
> > > > >>> :-)
> > > > >>> Marko
> > > > >>>
> > > > >>>
> > > > >>> Dr. Marko Vojinovic
> > > > >>> Group for Gravitation, Particles and Fields
> > > > >>> Institute of Physics
> > > > >>> University of Belgrade
> > > > >>> ======================
> > > > >>> home page: www.markovojinovic.com
> > > > >>> e-mail: vmarko at ipb.ac.rs
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Sat, 19 Nov 2022, Dušan Cvijetić wrote:
> > > > >>>
> > > > >>>>
> > > > >>>> Pozdrav,
> > > > >>>>
> > > > >>>> Dovršio sam kod za ispis u fajl. Ostalo mi je
> da ga iskomentarišem i
> > > > >>>> ozbiljnije istestiram. Na prvi pogled se čini
> da radi, i da je i redosled
> > > > >>>> svih stavki očuvan.
> > > > >>>>
> > > > >>>> Planiram, takođe, još malo da ulepšam I/O
> funkcije, trenutno su mahom
> > > > >>>> ogromne i ružne. Ostalo mi je par nedoumica
> oko nekih rešenja, koja sam
> > > > >>>> označio u komentarima sa // NOTE: ili //
> > > > >>>> TODO:. Uglavnom se tiču izuzetaka, ili rada u
> okviru postojeće
> > > > >>>> arhitekture (konkretno, čitanje različitih
> boja sam rešio putem case
> > > > >>>> strukture, što možda nije najsrećnije, ali mi
> ništa
> > > > >>>> drugo nije palo na pamet).
> > > > >>>>
> > > > >>>> Pre nego što nastavim sa testiranjem, imam
> još jedan predlog: nedavno sam
> > > > >>>> počeo da učim cmake, pa bih voleo da pokušam
> da napravim cmake za naš
> > > > >>>> projekat, ako se slažete. Tako bismo
> > > > >>>> mogli bolje da organizujemo testove i
> kompajliranje.
> > > > >>>>
> > > > >>>> Pozdravi,
> > > > >>>> Dušan
> > > > >>>>
> > > > >>>> On 10/11/2022 11:55, Nenad Korolija wrote:
> > > > >>>> Zdravo Marko,
> > > > >>>>
> > > > >>>> Ni ja se nisam dalje bavio triangulatorom,
> ali sam bar završio i
> > > > >>>> poslednje repove sa Amerikancima i valjda
> skoro sve oko papirologije za
> > > > >>>> reizbor (tu je bilo komplikacija, ali će
> > > > >>>> valjda sve proći u redu:).
> > > > >>>> Ako ćeš imati vremena da baciš pogled na moje
> đubre, možda možemo i da
> > > > >>>> budemo na vezi, pa da mi odmah kažeš šta da
> menjam (umesto da kucaš
> > > > >>>> email), pa da nastaviš gledanje kad
> > > > >>>> promenim...
> > > > >>>>
> > > > >>>> Vidimo se,
> > > > >>>> Nenad
> > > > >>>>
> > > > >>>> On Thu, Nov 10, 2022 at 11:52 AM Nenad
> Korolija <nenadko at gmail.com>
> > > > >>>> wrote:
> > > > >>>> Zdravo Dušane,
> > > > >>>>
> > > > >>>> Koliko vidim, snimanje simplicijalnog
> kompleksa radiš redom.
> > > > >>>> for (unsigned int lvl = 0; lvl <
> simpComp->elements.size(); lvl++) {
> > > > >>>> for (auto ks :
> simpComp->elements[lvl]) {
> > > > >>>> Dakle, verovatno je redosled snimanja i
> učitavanja isti, tj. nema potrebe
> > > > >>>> da sortiraš po ID-u ili šta već.
> > > > >>>> Dakle, trebalo bi da Markov predlog dobro
> testira snimanje i učitavanje -
> > > > >>>> poređenje snimljenog sa onim što si nakon
> toga učitao pa snimio.
> > > > >>>>
> > > > >>>> Vidimo se,
> > > > >>>> Nenad
> > > > >>>>
> > > > >>>> On Wed, Nov 9, 2022 at 10:52 PM Marko
> Vojinovic <vmarko at ipb.ac.rs> wrote:
> > > > >>>>
> > > > >>>> Pozdrav Dusane i Nenade,
> > > > >>>>
> > > > >>>> Evo konacno sam se vratio u Srbiju i
> uspeo malo da se organizujem.
> > > > >>>> Dosad se nisam odazivao jer sam bio bas
> pretrpan obavezama, nisam stizao
> > > > >>>> da pogledam sta ste
> > > > >>>> radili... :-( Ali nadalje cu biti malo
> bolji sa odgovaranjem na
> > > > >>>> mail-ove. ;-)
> > > > >>>>
> > > > >>>> Dusane, vidim da si poceo da radis na
> citanju kompleksa iz fajla, i
> > > > >>>> otprilike sam bacio pogled na ono sto si
> stavio u svoj branch dosad.
> > > > >>>> Nisam testirao, ali
> > > > >>>> pretpostavljam da radi, tj. da ispisuje
> na ekran ono sto procita?
> > > > >>>> :-) Sto se tice posebne klase za I/O, svakako
> je napravi ako mislis da je
> > > > >>>> potrebna, i Nenad i
> > > > >>>> ja se slazemo. Javi dokle si stigao i
> kako ide.
> > > > >>>>
> > > > >>>> Btw, fundamentalni test za I/O moze da
> ide otprilike ovako:
> > > > >>>>
> > > > >>>> (1) seed-ujes neki kompleks SimpComp
> *G1 (npr. 5-sferu ili stagod),
> > > > >>>>
> > > > >>>> (2) snimis G1 u fajl-prvi.xml f-jom za
> snimanje (koju si napravio),
> > > > >>>>
> > > > >>>> (3) ucitas fajl-prvi.xml u novi
> kompleks SimpComp *G2, f-jom za
> > > > >>>> citanje (koju sad pravis),
> > > > >>>>
> > > > >>>> (4) snimis G2 u fajl-drugi.xml f-jom za
> snimanje,
> > > > >>>>
> > > > >>>> (5) uporedis fajl-prvi.xml i
> fajl-drugi.xml (npr. diff-om ili cime
> > > > >>>> god).
> > > > >>>>
> > > > >>>> Ako su dva fajla uglavnom identicna (do
> na vrednosti UniqueID
> > > > >>>> brojeva i eventualne izmene u redosledu
> zapisivanja isl), test je prosao,
> > > > >>>> i zadatak je resen. ;-)
> > > > >>>>
> > > > >>>> Osim toga, ako bi uspeo jos da namestis
> obe f-je (za citanje i
> > > > >>>> snimanje) tako da cak i redosled kojim su
> stavke zapisane u dva fajla
> > > > >>>> bude isti, tj. da fajlovi
> > > > >>>> budu potpuno identicni (do na
> UniqueID-ove), to bi onda bila bas
> > > > >>>> prava stvar. :-) Ali to nije obavezno ---
> redosled stavki u fajlovima u
> > > > >>>> principu nije bitan,
> > > > >>>> dokle god mozemo pouzdano da se ubedimo
> da fajlovi zaista sadrze
> > > > >>>> iste podatke.
> > > > >>>>
> > > > >>>> :-)
> > > > >>>> Marko
> > > > >>>>
> > > > >>>> P.S. Drago mi je da si se lepo proveo u
> CERN-u, i da postoji
> > > > >>>> mogucnost da ides opet, svakako iskoristi
> priliku ako ti se ukaze...
> > > > >>>>
> > > > >>>>
> > > > >>>> Dr. Marko Vojinovic
> > > > >>>> Group for Gravitation, Particles and
> Fields
> > > > >>>> Institute of Physics
> > > > >>>> University of Belgrade
> > > > >>>> ======================
> > > > >>>> home page: www.markovojinovic.com
> > > > >>>> e-mail: vmarko at ipb.ac.rs
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Mon, 7 Nov 2022, Nenad Korolija
> wrote:
> > > > >>>>
> > > > >>>> > Zdravo Dušane,
> > > > >>>> >
> > > > >>>> > Ja se slažem. Ima smisla izdvojiti
> celu I/O funkcionalnost u
> > > > >>>> posebnu klasu, tj. fajl.
> > > > >>>> >
> > > > >>>> > Pozdrav,
> > > > >>>> > Nenad
> > > > >>>> >
> > > > >>>> > On Sun, Nov 6, 2022 at 5:16 PM Dušan
> Cvijetić
> > > > >>>> <dusancvijetic2000 at gmail.com> wrote:
> > > > >>>> > Pozdrav,
> > > > >>>> >
> > > > >>>> > Predlažem da se za I/O
> funkcionalnosti napravi nova klasa,
> > > > >>>> pošto
> > > > >>>> > trenutno radim na čitanju
> kompleksa iz fajla i imam mnogo
> > > > >>>> pomoćnih
> > > > >>>> > funkcija koje sam napravio, a
> koje trenutno plutaju u etru,
> > > > >>>> pa bi bilo
> > > > >>>> > lepše grupisati ih.
> > > > >>>> >
> > > > >>>> > Pozdravi,
> > > > >>>> > Dušan
> > > > >>>> >
> > > > >>>> > On 30/10/2022 19:58, Dušan
> Cvijetić wrote:
> > > > >>>> > > Pozdrav,
> > > > >>>> > >
> > > > >>>> > > Radim na čitanju iz fajla,
> pošto sam konačno prešao na
> > > > >>>> Ubuntu.
> > > > >>>> > >
> > > > >>>> > > Da li treba sada da
> razmišljam i o hvatanju izuzetaka,
> > > > >>>> ili je to tema
> > > > >>>> > > kojoj ćemo kasnije da se
> posvetimo?
> > > > >>>> > >
> > > > >>>> > > Pozdravi,
> > > > >>>> > > Dušan
> > > > >>>> > >
> > > > >>>> > > On 07/03/2022 06:00, Marko
> Vojinovic wrote:
> > > > >>>> > >>
> > > > >>>> > >> Vazi. :-)
> > > > >>>> > >>
> > > > >>>> > >> Sto se citanja iz fajla
> tice, obrati samo paznju kako
> > > > >>>> ces da
> > > > >>>> > >> instanciras UniqueID boje
> --- moraces "rucno" da im
> > > > >>>> menjas vrednosti
> > > > >>>> > >> na osnovu onoga sto procitas
> iz .xml fajla, jer
> > > > >>>> konstruktor
> > > > >>>> > >>
> UniqueIDColor::UniqueIDColor() zadaje te id-jeve
> > > > >>>> automatski.
> > > > >>>> > >>
> > > > >>>> > >> Takodje, kad sve zavrsis,
> treba da setujes vrednost za
> > > > >>>> > >>
> UniqueIDColor::next_free_uid_number na ono sto bi
> > > > >>>> trebalo da bude
> > > > >>>> > >> prvi slobodan id broj. To je
> valjda id vrednost prvog
> > > > >>>> simpleksa u
> > > > >>>> > >> fajlu, jer su oni u fajlu
> poredjani rastucim redom, a ti
> > > > >>>> id-jevi iz
> > > > >>>> > >> fajla ne treba da postoje u
> konacnoj strukturi u
> > > > >>>> memoriji, pa bi prvi
> > > > >>>> > >> od njih trebalo da bude
> "slobodan" na samom kraju...
> > > > >>>> > >>
> > > > >>>> > >> Jedino nisam siguran kako ce
> next_free_uid_number da
> > > > >>>> funkcionise u
> > > > >>>> > >> kontekstu veceg broja
> istovremeno instanciranih
> > > > >>>> kompleksa, ali to je
> > > > >>>> > >> pitanje dizajna o kome moram
> jos da razmislim.
> > > > >>>> > >>
> > > > >>>> > >> Ostatak algoritma osmisli
> sam, kako mislis da je
> > > > >>>> najzgodnije.
> > > > >>>> > >>
> > > > >>>> > >> :-)
> > > > >>>> > >> Marko
> > > > >>>> > >>
> > > > >>>> > >>
> > > > >>>> > >> Dr. Marko Vojinovic
> > > > >>>> > >> Group for Gravitation,
> Particles and Fields
> > > > >>>> > >> Institute of Physics
> > > > >>>> > >> University of Belgrade
> > > > >>>> > >> ======================
> > > > >>>> > >> home page:
> www.markovojinovic.com
> > > > >>>> > >> e-mail: vmarko at ipb.ac.rs
> > > > >>>> > >>
> > > > >>>> > >>
> > > > >>>> > >>
> > > > >>>> > >> On Mon, 7 Mar 2022, Dusan
> Cvijetic wrote:
> > > > >>>> > >>
> > > > >>>> > >>> Pozdrav,
> > > > >>>> > >>>
> > > > >>>> > >>> S obzirom da sam radio
> ispis u .xml fajl, preuzeću i
> > > > >>>> učitavanje
> > > > >>>> > >>> kompleksa iz fajla.
> > > > >>>> > >>>
> > > > >>>> > >>> Pozdravi,
> > > > >>>> > >>> Dušan
> > > > >>>> > >>>
> > > > >>>> > >>> пет, 11. феб 2022. у 23:17
> Marko Vojinovic
> > > > >>>> <vmarko at ipb.ac.rs> је
> > > > >>>> > >>> написао/ла:
> > > > >>>> > >>>
> > > > >>>> > >>> Implementirati metod
> u klasi SimpComp koji ce da
> > > > >>>> procita dati
> > > > >>>> > >>> fajl i instancira u
> memoriji simplicijalni kompleks na
> > > > >>>> osnovu
> > > > >>>> > >>> podataka iz fajla:
> > > > >>>> > >>>
> > > > >>>> > >>> SimpComp*
> SimpComp::read_complex_from_file(
> > > > >>>> file* f );
> > > > >>>> > >>>
> > > > >>>> > >>> Input: Pointer na
> fajl iz koga se citaju
> > > > >>>> podaci.
> > > > >>>> > >>> Output: pointer na
> instancirani simplicijalni
> > > > >>>> kompleks
> > > > >>>> > >>> kreiran na osnovu podataka
> iz fajla.
> > > > >>>> > >>>
> > > > >>>> > >>> Ovaj zadatak treba da
> instancira nov prazan
> > > > >>>> kompleks, zatim da
> > > > >>>> > >>> cita dati fajl,
> interpretira sintaksu iz zadatka 7, i
> > > > >>>> da na osnovu
> > > > >>>> > >>> tih podataka popuni
> kompleks odgovarajucim
> > > > >>>> > >>> simpleksima datih
> nivoa, a zatim i boje i susede
> > > > >>>> svakog
> > > > >>>> > >>> simpleksa ponaosob. Ovo je
> u sustini inverzni algoritam
> > > > >>>> u odnosu na
> > > > >>>> > >>> zadatak 7, i zavisi od
> tacne implementacije tog
> > > > >>>> > >>> zadatka (tj. od tacne
> sintakse snimljenog fajla),
> > > > >>>> pa ovaj
> > > > >>>> > >>> zadatak treba raditi tek
> kada budemo sigurni da smo
> > > > >>>> skroz zadovoljni
> > > > >>>> > >>> sa radom f-ja za snimanje u
> fajl.
> > > > >>>> > >>>
> > > > >>>> > >>> I u ovom slucaju cemo
> mozda uraditi vise verzija
> > > > >>>> f-je za
> > > > >>>> > >>> citanje, po jednu za svaki
> format fajla.
> > > > >>>> > >>>
> > > > >>>> > >>>
> > > > >>>> > >>> :-)
> > > > >>>> > >>> Marko
> > > > >>>> > >>>
> > > > >>>> > >>>
> > > > >>>> > >>> Dr. Marko Vojinovic
> > > > >>>> > >>> Group for
> Gravitation, Particles and Fields
> > > > >>>> > >>> Institute of Physics
> > > > >>>> > >>> University of Belgrade
> > > > >>>> > >>> ======================
> > > > >>>> > >>> home page:
> www.markovojinovic.com
> > > > >>>> > >>> e-mail:
> vmarko at ipb.ac.rs
> > > > >>>> > >>>
> > > > >>>> > >>>
> > > > >>>> > >>> --
> > > > >>>> > >>> QGHG-it-dev-list
> mailing list
> > > > >>>> > >>>
> QGHG-it-dev-list at ipb.ac.rs
> > > > >>>> > >>>
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > > >>>> > >>>
> > > > >>>> > >>>
> > > > >>>> > >>>
> > > > >>>> > >>
> > > > >>>> > --
> > > > >>>> > QGHG-it-dev-list mailing list
> > > > >>>> > QGHG-it-dev-list at ipb.ac.rs
> > > > >>>> >
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > > >>>> >
> > > > >>>> >
> > > > >>>> >--
> > > > >>>> QGHG-it-dev-list mailing list
> > > > >>>> QGHG-it-dev-list at ipb.ac.rs
> > > > >>>>
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >--
> > > > QGHG-it-dev-list mailing list
> > > > QGHG-it-dev-list at ipb.ac.rs
> > > >
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > >
> > > >
> > > >--
> > > QGHG-it-dev-list mailing list
> > > QGHG-it-dev-list at ipb.ac.rs
> > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > >
> > >
> > >--
> > QGHG-it-dev-list mailing list
> > QGHG-it-dev-list at ipb.ac.rs
> > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >
> >
> >--
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list at ipb.ac.rs
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20221130/2bf8c08e/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list