[QGHG-it-dev-list] Zadatak 8 - ucitavanje kompleksa iz fajla
Marko Vojinovic
vmarko at ipb.ac.rs
Mon Nov 28 12:11:10 CET 2022
Pozdrav Dusane,
Da, izgleda da si bio u pravu, bag je zaista bio u add_neighbor() f-ji, drago mi je da smo to regulisali. :-)
Elem, uradio sam par push-eva, najpre na tvoj branch 8_XML_reading da bih rascistio konflikte sa main branch-em koji je u medjuvremenu izdivergirao, i malo jos pocistio kod. A onda sam prihvatio pull-request, merge-ovao ceo branch u main, i obrisao ga (da nas ne zbunjuje jer je skroz merge-ovan).
Tako da je to to, sto se tice 8. zadatka. Hvala!
Ti se sad koncentrisi da namestis cmake (mozes i za ovo da napravis zaseban branch, kao sto si uradio za 8. zadatak).
Btw, malo sam se i poigrao sa citanjem i snimanjem, sve radi kako treba, test snimi-citaj-snimi radi savrseno (rezultujuci .xml fajlovi su identicni, do na id-jeve koji moraju da se razlikuju). Jedini problem na koji sam naisao je da kod ima probleme ako neki string sadrzi razmak, na primer ako za ime kompleksa stavim "moja sfera". U takvim situacijama rapidxml nesto ne parse-uje kako treba, i doceka me greska:
terminate called after throwing an instance of 'rapidxml::parse_error'
what(): expected =
Aborted (core dumped)
Nisam gledao da li XML standard dozvoljava razmake u stringovima, ali svejedno ovo moze da bude nezgodno. Kasnije cemo ovo da pogledamo detaljnije i u opstem slucaju. Naime, korisnik moze generalno da definise svoje boje i odgovarajuce f-je
get_color_value_as_str()
set_color_value_from_str()
koje mogu da ubace a priori bilo kakve stringove u .xml fajl. To je problem jer ti stringovi onda mogu da naruse XML standard (npr. ako korisnik u svojim bojama koristi znake < i > isl.). To cemo najverovatnije da resimo jednom novom f-jom koja ce (u skladu sa XML standardom) da escape-uje sve specijalne karaktere u svim stringovima pre nego sto se snime u .xml fajl, i drugom f-jom koja ce da unescape-uje te iste karaktere kada se stringovi citaju iz .xml fajla. Tada u specijalne karaktere mozemo da stavimo i razmak, tako da se i on escape-uje i da nemamo problema, sta god korisnik stavljao u stringove. ;-)
Ali o tom potom... ;-)
:-)
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 Sun, 27 Nov 2022, Dušan Cvijetić wrote:
>
> Pozdrav,
>
> Vidim sad da sam slučajno poslao prethodni mejl samo profesoru Koroliji, pa ponavljam isti tekst ispod, ovaj put za celu listu.
>
> >>>>>>>>>> ORIGINALNI TEKST <<<<<<<<<<
>
> Nova verzija add_neighbor() rešava onaj bag koji sam imao, sada su .xml fajlovi koje proizvodi identični, tako da ću da napravim pull request. Planirao sam još neke testove da napravim,
> ali to ću ostaviti za nakon što sredim cmake, jer ćemo onda imati sistematski način da ih dodajemo.
>
> Pozdravi,
> Dušan
>
> On 26/11/2022 13:53, 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
>
>
>
>
More information about the QGHG-it-dev-list
mailing list