[QGHG-it-dev-list] Zadatak 2 - bojenje kompleksa
Marko Vojinovic
vmarko at ipb.ac.rs
Sun Feb 27 04:51:34 CET 2022
E odlicno, sad je print_compact() bas super! Hvala! :-) To je to, zadovoljan sam kako sad radi i sta ispisuje, igrao sam se malo i testirao razne varijante.
Nego tokom igranja i testiranja, pade mi na pamet jedno nevezano pitanje --- nakon seed-ovanja edge-a, trougla i tetraedra u main.cpp, mi ih nigde posle nismo deinstancirali/obrisali. Nakon sto se main.cpp zavrsi, jel' se ta memorija automatski dealocira, ili ostane da visi, kao memory leak? Takodje, kada hocu namerno da deinstanciram neki postojeci kompleks, jel' dovoljno da pozovem
triangle-> ~SimpComp();
(ili kako vec ide sintaksa), i to ce onda samo od sebe da obrise i kompleks, i sve njegove simplekse, i sve boje u tim simpleksima, i tabele suseda, itd? Ili treba napraviti neku f-ju tipa SimpComp::delete_everything() koja bi se spustila rekurzivno po svim tim strukturama i deinstancirala ih jednu po jednu? Znaci koja je pedantna procedura brisanja celog kompleksa iz memorije?
Naravno, u ovom main.cpp koji upotrebljavamo za testiranje me nije mnogo briga da li ce to lepo da se obrise ili ne, ali generalno za nekog korisnika, ili npr. kad budemo pravili gui, to treba da bude jedna od eksplicitnih opcija negde (Delete this complex), pa rekoh da pitam kako bi se to pravilno radilo.
I na kraju da ne zaboravim ovih par komentara:
> Napravio print_vertices_in_parentheses(). Morala je u SimpComp, ne KSimplex.
U pravu si, SimpComp je prirodnija klasa za to.
> Mozes da proveris da li classes.cpp:229-231 treba da postoje:
Ummm, tr... hmm... da da, treba. Neka ispisuje one id-jeve koji postoje, to mi sve deluje ok.
> Trenutno ispisuje i one -Simplex za falece ID-jeve. Ako hoces, mogu da ne ispisujem nista, ali bih promenio u odnosu na prethodni izlaz.
Svidja mi se ovako kako je sada, neka ispise -Simplex kad fali neki id. Dobro je ovako, nista vise tu ne moras da diras.
> Ako bih isto hteo za strukturu gde imam poseban ispis po razlicitim nivoima
Jok, ne treba nam razlicit ispis za razlicite nivoe. Ovo sto si sada napravio je sasvim dovoljno --- kad budemo implementirali neki drugaciji ispis bice relativno jasno gde sta treba da se promeni, i to je to. ;-)
:-)
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 Feb 2022, Nenad Korolija wrote:
> > (l.254) for(size_t i = 1; i < elements[k].size(); i++){
> Hvala!
> Ispravio da k ide od 0.
>
> Napravio print_vertices_in_parentheses(). Morala je u SimpComp, ne KSimplex.
> Trudio sam se da nista u ispisu ne promenim.
> Mozes da proveris da li classes.cpp:229-231 treba da postoje:
> UniqueIDColor* pColor = elements[k][i]->get_uniqueID();
> if(pColor)
> s.insert( static_cast<UniqueIDColor*>(pColor)->id );
>
> > KSimplex::print_vertices_in_parentheses()
> > koja bi ispisivala te zagrade ako su svi verteksi datog k-simpleksa obojeni, odnosno prazan string ako nisu.
> Trenutno ispisuje i one -Simplex za falece ID-jeve. Ako hoces, mogu da ne ispisujem nista, ali bih promenio u odnosu na prethodni izlaz.
> Naravno, mogu da dodam bool argument da pozivalac bira da li u tom slucaju hoce -Simplex, ili da se ne stampaju ni zagrade ni nista.
>
> Svidja mi se sto razmisljas o unifikovanju pisanja na ekran/fajl/GUI/gde god i valjda ne moras da pricas o tome ni pocetnicima - koliko god da je neko pocetnik, verovatno mu se desavalo
> da se vrati svom kodu posle n meseci i da nema pojma sta sta radi - meni se ko zna koliko puta :).
> Za sad ne vidim na prvi pogled sta mi je ciniti (nije ni cudo koliko je sati:).
> Jos pre citanja ideje sam razdvojio:
> collect_vertices(s);
> if(s.size())
> print_set(s);
> Ako bih isto hteo za strukturu gde imam poseban ispis po razlicitim nivoima, pa na svakom nivou sa zarezima 4(11-12), 5(13-14)..., mogao bih da napravim da generisem vektor (nivoa)
> vektora (za svaki nivo) za ispis, pa da ispisuje ko koko hoce. E sad, ovi 4 i 5 ne bi potpali pod tu strukturu, pa bih mogao jos da je zakomplikujem, ali mislim da bi stvar time vec
> izgubila smisao. Vidis li koji su to elementi koji ce trebati uvek? Mozda samo za jedan nivo da napravim nesto tipa vektor za 4 i 5 i vektor vektora za 11..14.
>
> Pozdrav,
> Nenad
>
>
> On Fri, Feb 25, 2022 at 2:31 AM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>
> Evo pregledao sam izmene i testirao sva tri slucaja stampanja --- slucajevi "vAll and sAll" i "vAll and not sAll" rade ok, ali slucaj "not vAll" ispisuje po jedan simpleks
> manje na svakom nivou (preskoci prvi). Nasao sam i sta treba popraviti: u petlji u liniji 254 samo krenes od i=0 umesto od i=1, i onda ce i "not vAll" slucaj da proradi kako
> treba:
>
> (l.254) for(size_t i = 1; i < elements[k].size(); i++){
>
> Sto se tice f-ja koje si dodao, sve su ok i slazem se da su zgodne. Uslov "level > D" je tacan.
>
> Nego imam dve sugestije oko generalnog dizajna celog koda za print_compact f-je...
>
> Prva sugestija je da nije zgodno da imas dva nezavisna koda za ispisivanje verteksa u zagradama, (5-6-7). Jedan kod se nalazi u KSimplex::print_compact(), a drugi u
> SimpComp::print_compact(). Mislim da bi ceo kod mogao znacajno da se pojednostavi ako bi napravio zasebnu f-ju
>
> KSimplex::print_vertices_in_parentheses()
>
> koja bi ispisivala te zagrade ako su svi verteksi datog k-simpleksa obojeni, odnosno prazan string ako nisu. Tada bi obe gornje print_compact() f-je bile drasticno lakse.
>
> Druga sugestija je vezana za to da cemo kasnije pisati druge KSimplex::print_nekako() f-je, po ugledu na KSimplex::print_compact(), pa bi bilo dobro da ona bude
> implementirana "modularno". Primera radi, kasnije cemo za potrebe GUI-ja mozda da napravimo f-ju KSimplex::print_hyperlink(), koja bi umesto "17 (2-3-4)" ispisivala recimo
> nesto ovako:
>
> 17 <a href="simplex-id-17.html">(2-3-4)</a>
>
> ili slicno. Ne znam unapred kakve sve sintakse ispisivanja ce nam trebati u buducnosti, ali za svaku sintaksu cemo imati odgovarajucu KSimplex::print_nekako() f-ju. Pa bi
> bilo dobro da tvoja KSimplex::print_compact() f-ja budu napisana "studentima za ugled", da posle student moze lako da je razume, da je copy-paste-uje, preimenuje, i
> minimalno izmeni, i da time dobije novu KSimplex::print_nekako() f-ju koja ispisuje ono sto njemu treba.
>
> Jedan znacajan element tog dizajna je da te kasnije f-je mozda nece da stampaju uvek na stdout (nego potencijalno u fajl ili negde drugo), pa je verovatno zgodno da odvojis
> u zasebnu f-ju postupak konstrukcije stringa koji treba stampati, a onda iz KSimplex::print_compact() samo pozoves tu f-ju da ti konstruise string, i zatim ga odstampas na
> stdout.
>
> Ili tako nekako... Razmisljaj na sledeci nacin --- zamisli da cu kroz godinu dana traziti *tebi* da napravis jedno 5-6 novih print_nekako() f-ja, koje ce da ispisuju stvari
> razlicito i na razlicita mesta. Osmisli dizajn za KSimplex::print_compact() tako da za oko godinu-dve (kad zaboravis detalje sta i kako u njoj radi) mozes lako da realizujes
> tih 5-6 drugih. ;-)
>
> Malo mi je glupo da te gnjavim sa ovako trivijalnom temom (ispisivanje brojeva na ekran), ali dizajn tih f-ja ce nam stvarno biti znacajan za kasnije, pa ako ga sad na
> pocetku uradimo kako treba, kasnije nece da nas boli glava... :-)
>
> :-)
> 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 Feb 2022, Nenad Korolija wrote:
>
> > Modifikovao, ali ti je jasno da nemam pojma zasto ti to treba. :)
> > U skladu sa mojim nagadjanjima, napravio sam funkcije koje bi mogle da nam olaksaju zivot tipa:
> > - nadji prvu uniqueID boju i
> > - nadji sve vertekse.
> >
> > Mozes da pogledas sve izmene i testiras kopiranjem poslednjih linija main-a i jednostavnim komentarisanjem i menjanjem broja u zagradi:
> > UniqueIDColor::colorize_simplices_at_level(tetrahedron, 0);
> > UniqueIDColor::colorize_entire_complex(tetrahedron);
> >
> > Nadam se da sa > D nisam omanuo uslov:
> > bool SimpComp::all_uniqueID(int level){
> > size_t i = 0;
> > if(level > D)
> > return false;
> >
> > Pozdrav,
> > Nenad
> >
> > On Wed, Feb 23, 2022 at 5:54 AM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
> >
> > Da, ovakvo ispisivanje sa & u compact_print nije zgodno. Uradi ovako --- za svaki simpleks, pronadji prvu instancu UniqueID boje i ispisi uvek samo nju, a ostale
> instance
> > ignorisi (ako postoje). To je najjednostavnija varijanta, i dovoljna je za nase potrebe.
> >
> > Takodje, ako vec sredjujes print_compact, mozes da namestis i sledecu logiku ispisivanja (smislio sam pre neki dan precizna pravila):
> >
> > * Prvo proveri da li su verteksi (k=0) obojeni svi (v=all), ili ima nekih koji nisu obojeni (v=notall).
> > * Zatim proveri da li su ostali simpleksi (k>0) obojeni svi (s=all), ili ima nekih koji nisu obojeni (s=notall).
> >
> > Kad to saznas, onda ih ispisuj ovako:
> >
> > * Ako je v=all i s=all --- ispisi standardno prvo boje svih verteksa: 1, 2, 3,..., pa zatim za ostale simplekse njihove boje i u zagradama boje njihovih
> verteksa. Sve
> > sortiraj. Primer: 14 (2-4-8), 15 (3-5-9), ...
> > * Ako je v=all i s=notall --- ispisi boje svih verteksa: 1, 2, 3,..., pa zatim za ostale simplekse samo boje njihovih verteksa u zagradama, sortirane: (2-4-8),
> (3-5-9),
> > ...
> > * Ako je v=notall i (s=all ili s=notall) --- i za vertekse i za ostale simplekse samo napisi boju ako je ima, odnosno rec "Simplex" ako je nema, bez zagrada i
> bez
> > sortiranja: 8, 4, Simplex, 15, ...
> >
> > Ova pravila pokrivaju sve slucajeve. Naravno, u svemu ovome gore razvrstavas ispisivanje po nivoima, za svako k jedan zaseban red, kao i dosad sto je bilo.
> >
> > U main.cpp testiraj prvi slucaj tako sto obojis ceo tetraedar, drugi slucaj tako sto obojis k=0 level za tetraedar, a treci tako sto obojis recimo k=2 level za
> tetraedar,
> > Dusanovim f-jama. Naravno, instanciraj tri nezavisna tetraedra za ovo, da mozes sve odjednom da testiras.
> >
> > Btw, smisao ovih pravila: prva dva slucaja (v=all) su regularna i verovatno ce se cesto pojavljivati u praksi, dok treci slucaj (v=notall) nije regularan i
> signalizira da je
> > korisnik nesto negde zabrljao sa bojama (ispisivanjem reci "Simplex" bar na nekom mestu). ;-)
> >
> > :-)
> > 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 Wed, 23 Feb 2022, Nenad Korolija wrote:
> >
> > > Marko, planirao sam sortiranje UniqueID boja i ispisivanje redom. To se kosi sa potrebama. Kakvo ispisivanje zelis u slucaju ivice sa 4&7 izmedju verteksa sa 8&9 i
> 10&11,
> > > 4&7 (8&9-10&11)?
> > >
> > > On Tue, Feb 22, 2022 at 11:23 PM Nenad Korolija <nenadko at gmail.com> wrote:
> > > Sa svim se slazem...
> > > Marko, druge funkcije color.cpp su ispale 0-3 linije koda, ali bih rado ubio colorize_simplices_at_level, ako sama po sebi nema svrhu, iako Dušanove imaju po 4
> linije. :)
> > > Vidim da si ti kreirao naziv funkcija koje sam komentarisao. Ako stari nazivi imaju neku interpretaciju koju ne vidimo, javi da vratimo.
> > >
> > > On Tue, Feb 22, 2022 at 9:52 PM Dusan Cvijetic <dusancvijetic2000 at gmail.com> wrote:
> > > Da, nisam u prošlom mejlu napisao, kada je dozvoljeno da simpleks ima više UniqueIDColor objekata, štampanje pobrljavi. Boje simpleksa se štampaju spojeno, a
> pošto
> > pri
> > > štampanju samo prolazi kroz skup svih UniqueIDColor-a, ukoliko, recimo, želimo da štampamo ivicu, kada tačke imaju po dva UniqueIDColor objekta, ištampaće
> ivice kao
> > da
> > > imaju četiri suseda. Recimo, ukoliko verteksi v1 i v2 imaju UniqueIDColor boje 1, 5 i 2, 6, redom (tako je trenutno u main.cpp fajlu), ivicu 9 koja je između
> njih
> > > štampa kao Simplices k = 1: 9 (1-2-5-6), pri čemu vertekse štampa kao 15 i 26. Nisam siguran je li nameravano da se funkcija za štampanje ovako ponaša, pa
> samo da
> > > napomenem.
> > >
> > > уто, 22. феб 2022. у 21:45 Dusan Cvijetic <dusancvijetic2000 at gmail.com> је написао/ла:
> > > Pozdrav,
> > >
> > > nemoj da proveravas da li simpleks vec ima UniqueID boju
> > >
> > > Prepravio i pushovao, proverite je li sad u redu.
> > >
> > > samo bi mozda imalo smisla staviti forward deklaracije u color.hpp a ne direktno u triangulator.hpp.
> > >
> > > Premešteno.
> > >
> > > Nase klase su samo malo komplikovaniji slucaj istog tog koncepta --- unakrsno referenciraju jedna drugu u svojim definicijama.
> > >
> > > Imao sam, pre oko godinu dana, problem s ovim u svom kodu i nisam znao kako da ga rešim, pa sam reorganizovao klase. Sad mi je interesantan ovaj način rešavanja
> > > unakrsne rekurzije, ne bi mi palo na pamet jer smo na fakultetu učili jedan šablon, koji je predstavljen kao Sveto Pismo, pa nisam nikad od njega divergirao.
> > >
> > > Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako:
> > >
> > > Trebalo bi da moj deo koda sad prati ove konvencije, ostalo nisam hteo da diram, ali mogu kroz sve da prođem, ako želite.
> > >
> > > neka zasad f-je uvek vracaju samo true
> > >
> > > Prepravljeno.
> > >
> > > Pozdravi,
> > > Dušan
> > >
> > >
> > >
> > > уто, 22. феб 2022. у 17:54 Marko Vojinovic <vmarko at ipb.ac.rs> је написао/ла:
> > >
> > > Evo da vam odgovorim obojici odjednom... :-)
> > >
> > > Dusane, odlicno si ovo uradio, svidja mi se, samo cu da te zamolim za jednu sustinsku izmenu --- nemoj da proveravas da li simpleks vec ima UniqueID boju.
> > > Obe f-je treba prosto da dodaju
> > > *nove* boje, cak i ako su simpleksi vec bili obojeni sa UniqueID. Ne zelimo da dopunjavamo kompleks bojama, nego da ga obojimo "jos jednom", da se tako
> > > izrazim. Inace, ne postoji nikakav problem da isti simpleks nosi dve UniqueID boje (obrnuto naravno ne sme), u zadatku 7 se cak oslanjamo na to.
> > >
> > > Sto se tice konkretnih pitanja, ovako:
> > >
> > > > Tek kada sam izvršio commit sam se setio da poruke treba da pišem na engleskom
> > >
> > > Nije problem, samo pazi na to ubuduce --- neko ko ne zna srpski ce mozda pozeleti da gleda GitHub, zato je sve na engleskom. Btw, budite srecni sto vas ne
> > > teram da i komunikacija na mailing listi bude na engleskom. :-D
> > >
> > > > Color traži da budu već deklarisani SimpComp i KSimplex, a KSimplex traži da već bude deklarisan Color, a SimpComp traži KSimplex: Color > SimpComp >
> > > KSimplex > Color. Naterao sam
> > > > ga da radi dodavši forward deklaracije za KSimplex i SimpComp u triangulator.hpp, ali ne mislim da je to dobro rešenje.
> > >
> > > Naprotiv, forward deklaracije su upravo ono sto nam treba. :-) Te tri klase su ukrstene by design --- jer to tacno odgovara matematickim strukturama sa
> > > kojima radimo. U tom kontekstu, bilo kakvo uvodjenje nekih dodatnih klasa da se to "popravi" bi bilo skroz vestacko i nepotrebno. Znaci dobro si uradio,
> > > samo bi mozda imalo smisla staviti forward deklaracije u color.hpp a ne direktno u triangulator.hpp.
> > >
> > > > Trenutno mi deluje neprijatno da polje klase namešta samo sebe
> > >
> > > Sigurno si vec naviknut na koncept dinamicke liste --- nju kreiras strukturom koja u svojoj definiciji referencira samu sebe. Nase klase su samo malo
> > > komplikovaniji slucaj istog tog koncepta --- unakrsno referenciraju jedna drugu u svojim definicijama. Unakrsnu rekurziju [1] si sigurno video u
> > > algoritmima (npr. rekurzivni spust), jedino mozda nisi navikao da pravis klase na istu foru. ;-)
> > >
> > > > Koristio sam konvenciju sa donjom crtom umesto camelCase-a jer je tako stajalo u potpisu funkcija, meni je takođe svejedno kako ćemo pisati.
> > >
> > > Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako: imena funkcija su under_scored, imena klasa su CamelCase, imena promenljivih su camelCase, a
> > > imena konstanti su UNDER_SCORED_CAPS. Bice zabavno. ;-) Inace, sto se tice generalnih konvencija kucanja koda, ponekad se trazi i word-wrap na 79-toj
> > > koloni, ali mene to strasno nervira na velikom monitoru pa se ja prvi necu pridrzavati toga, niti cu vas da teram. ;-)
> > >
> > > > nije naznačeno šta označava bool vrednost koju funkcija vraća, pa sam namestio da vraća true ukoliko je bar jedan simpleks obojen njenim pozivom.
> > > > Ne vidim koje bi se greške mogle javiti pri bojenju
> > >
> > > Ovo sam ja zaboravio da preciziram u zadatku --- f-je treba da vrate false samo ukoliko ne uspeju da urade svoj posao. Jedine situacije u kojima je ovo
> > > zamislivo su out-of-memory problemi, npr. ako "new UniqueIDColor()" odbije da adresira memoriju, ili sl. Ali posto o takvim stvarima za sada generalno ne
> > > brinemo nigde u kodu, necemo ni ovde --- neka zasad f-je uvek vracaju samo true, pa cemo to da promenimo kad (ako) budemo radili code hardening.
> > >
> > > > Druga stvar koja mi je zapala za oko je colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda colorize_simplices_at_level?
> > >
> > > Jeste, ovo je prirodnije ime, vidim da ga je Dusan vec popravio.
> > >
> > > > Sledece bi u sustini trebalo da ne bude u classes.hpp (mada nama tako za sad odgovara zbog grupisanja funkcionalnosti), vec da se podeli u dva fajla:
> > >
> > > Jeste, podelite classes.hpp na simpcomp.hpp i ksimplex.hpp (i odgovarajuce .cpp-ove). I naravno dodajte unutra forward-deklaracije klasa koje vam trebaju.
> > >
> > > :-)
> > > Marko
> > >
> > > [1] https://en.wikipedia.org/wiki/Mutual_recursion
> > >
> > >
> > >
> > > 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 Tue, 22 Feb 2022, Dusan Cvijetic wrote:
> > >
> > > > Pozdrav,
> > > >
> > > > Ono sto sam primetio je drugacije imenovanje
> > > >
> > > > Koristio sam konvenciju sa donjom crtom umesto camelCase-a jer je tako stajalo u potpisu funkcija, meni je takođe svejedno kako ćemo pisati. Moj deo koda
> > > je mali i lako ćemo ga
> > > > prepraviti da isprati bilo koji sistem.
> > > >
> > > > Druga stvar koja mi je zapala za oko je colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda colorize_simplices_at_level?
> > > >
> > > >
> > > > Slažem se, ime koje ste predložili mi je jasnije. Promenio sam u kodu, pa mogu ponovo da ga ispravim ukoliko nije po volji - još nemamo toliko mnogo koda
> > > da bi prepravljanje bilo
> > > > ozbiljan posao.
> > > >
> > > > Ova petlja bez potrebe nastavlja i posle nadjene odgovarajuce boje:
> > > >
> > > > Ispravio.
> > > >
> > > > Ovde mi se ne svidja neuniformnost:
> > > >
> > > > Mislim da je ovo ispravljeno menjanjem imena funkcije za bojenje po nivoima.
> > > >
> > > > Deluje da ce colorization biti successful ako se bar jedan simplex oboji. Jel treba tako?
> > > >
> > > > To sam zaboravio da spomenem u mejlu, nije naznačeno šta označava bool vrednost koju funkcija vraća, pa sam namestio da vraća true ukoliko je bar jedan
> > > simpleks obojen njenim pozivom.
> > > > Ne vidim koje bi se greške mogle javiti pri bojenju, a da ih mi hvatamo, osim da simpleksi ne postoje, a tada vraća false. Nije mi bilo logično da vraća
> > > false ukoliko ne oboji bar neki
> > > > simpleks jer je moguće da neki nivo neće imati simplekse (ne znam da li je to sa strane primene tako, ali mi je situacija u kome postoje samo 3D elementi
> > > u 8D kompleksu zamisliva), pa
> > > > bi bilo mnogo false slučajeva za situacije koje su legitimne. Trebalo je ranije da pitam, ali šta je ideja sa bool vrednošću koju f-ja vraća?
> > > >
> > > > Usput, kako si testirao?
> > > >
> > > > Koristio sam samo onaj kod iz main.cpp, gde sam obojio tetrahedron. Uz to, testirao sam je uz pravljenje dva tetraedra da bih proverio kako se ponaša
> > > kada ubacimo više objekata, i bilo
> > > > je OK. Taj deo nisam hteo da ostavljam da ne bih previše remetio main.cpp.
> > > >
> > > > Moj bespotrebni kod si mogao slobodno da ubijes, umesto da ga ostavljas iskomentarisanog.
> > > >
> > > > Urađeno.
> > > >
> > > > Pozdravi,
> > > > Dušan
> > > >
> > > >
> > > > уто, 22. феб 2022. у 11:04 Nenad Korolija <nenadko at gmail.com> је написао/ла:
> > > > Zdravo Dušane,
> > > >
> > > > Marko ce videti validnost bojenja.
> > > >
> > > > Ja pisem ocima najgoreg neprijatelja, cisto da bi se svi navikavali na to da obracaju paznju i na detalje (mozda nakon sto napisu kako im je najlakse,
> > > mada verovatno bolje od
> > > > starta):
> > > >
> > > > Ono sto sam primetio je drugacije imenovanje (sa underscore, tj. _) u odnosu na moje (camel case, npr. " bool hasUniqueColor = false;"). Meni je OK
> > > bilo koja varijanta, samo da
> > > > bude uniformno, a ne da neko ko radi na kodu treba svaki cas da prilagodjava mindset prema tome ko je kucao taj deo koda. :)
> > > >
> > > > Druga stvar koja mi je zapala za oko je colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda colorize_simplices_at_level?
> > > >
> > > > Ova petlja bez potrebe nastavlja i posle nadjene odgovarajuce boje:
> > > > already_has_unique_id = false;
> > > > for (auto cl : simplex->colors)
> > > > if (cl->type == TYPE_UNIQUE_ID)
> > > > already_has_unique_id = true;
> > > >
> > > > Ovde mi se ne svidja neuniformnost:
> > > > colorize_entire_complex
> > > > samo ide po nivoima i poziva:
> > > > colorize_all_simplices
> > > >
> > > > Funkcije su kratke i lako se razumeju, ali je nezahvalno da neko mora da cita kod i zakljucuje, a da su nazivi funkcija neuniformni i misleading.
> > > >
> > > > Deluje da ce colorization biti successful ako se bar jedan simplex oboji. Jel treba tako?
> > > >
> > > > Usput, kako si testirao?
> > > >
> > > > Moj bespotrebni kod si mogao slobodno da ubijes, umesto da ga ostavljas iskomentarisanog. Sad imamo cist nacin, a ono moje je bilo cisto za testiranje
> > > print_compact.
> > > >
> > > >
> > > > Sto se tice toga kako treba uvezivati, mi smo inicijalno radili sve u jednom fajlu, pa smo razdelili, pa se Marko potrudio da napravi biblioteku i
> > > razresi neke probleme.
> > > > Radio sam za Italijane, Amerikance, Nemce i Engleze i svuda smo imali Makefile koji je kompajlirao pojedine cpp fajlove u .o objekte, pa ih link-ovao.
> > > Verovatno je ovo nase
> > > > trenutno include-ovanje nesto sto smeta VS-u.
> > > > Sledece bi u sustini trebalo da ne bude u classes.hpp (mada nama tako za sad odgovara zbog grupisanja funkcionalnosti), vec da se podeli u dva fajla:
> > > > class KSimplex;
> > > > class SimpComp{
> > > > public:
> > > > Ali ako je VS problem resen, mozemo da radimo dalje.
> > > > Hvala za forward deklaracije za KSimplex i SimpComp. :)
> > > >
> > > > Pozdrav,
> > > > Nenad
> > > >
> > > > On Tue, Feb 22, 2022 at 10:09 AM Dusan Cvijetic <dusancvijetic2000 at gmail.com> wrote:
> > > > Pozdrav,
> > > >
> > > > Odradio sam funkcije za zadatak, proverite je li sve u redu.
> > > >
> > > > Tek kada sam izvršio commit sam se setio da poruke treba da pišem na engleskom, ispraviću sledeći put, nadam se da nije veliki problem.
> > > >
> > > > I pored refaktorisanog koda, organizacija klasa Color i KSimplex/SimpComp stvara probleme. Color traži da budu već deklarisani SimpComp i KSimplex, a
> > > KSimplex traži da već
> > > > bude deklarisan Color, a SimpComp traži KSimplex: Color > SimpComp > KSimplex > Color. Naterao sam ga da radi dodavši forward deklaracije za KSimplex i
> > > SimpComp u
> > > > triangulator.hpp, ali ne mislim da je to dobro rešenje. Iz mog ograničenog iskustva, ovo mi deluje kao loša delegacija odgovornosti. Možda bi bolje bilo
> > > da SimpComp samog
> > > > sebe boji, ili da imamo posebnu klasu "molera" koja će da boji simplekse po potrebi? Tako bi ona mogla da uključi i Color i KSimplex i SimpComp, bez
> > > problema koje trenutno
> > > > imamo. Trenutno mi deluje neprijatno da polje klase namešta samo sebe, lepše mi je da to bude odgovornost samog objekta, ili nekog njemu nadređenog.
> > > >
> > > > Opet, moje iskustvo s ovakvim problemima se svodi na samo jedan iole ozbiljniji projekat koji sam radio, tako da mi javite ukoliko grešim, zanima me kako
> > > se ove strukture
> > > > obično rešavaju u praksi.
> > > >
> > > > Pozdravi,
> > > > Dušan
> > > >
> > > > уто, 22. феб 2022. у 01:26 Marko Vojinovic <vmarko at ipb.ac.rs> је написао/ла:
> > > >
> > > > Pozdrav Dusane,
> > > >
> > > > Potpuno si u pravu da f-je za bojenje ne mogu (i ne treba) da se pozivaju za pojedinacnu boju. Dakle svakako, stavi ih kao static za klasu. Ja sam
> > > to zaboravio
> > > > da naglasim u definiciji zadatka, ali iz smisla tih f-ja je relativno ocigledno. :-)
> > > >
> > > > A taman posla da isti pointer dodeljujes celom kompleksu, to uopste nije bila ideja... ;-)
> > > >
> > > > Sto se tice rekurzivnog ukljucivanja fajlova generalno, slazem se da to moze bolje da se uradi, i to cu da reorganizujem uskoro (veceras ili sutra,
> > > poslacu
> > > > zaseban mail o tome). Reorganizacija ce da pomogne i za Visual Studio --- da se include-uju samo .hpp fajlovi a ne i .cpp fajlovi, da mozete da
> > > napravite
> > > > projekat, mozda cak da koristite i njegov kompajler, itdisl.
> > > >
> > > > A sto se tice rekurzivnog ukljucivanja fajlova u kontekstu zadatka 2, nemoj da se sekiras za to, nego treba samo da uradis sledece --- da
> > > deklaracije f-ja stavis
> > > > u color.hpp fajl (gde im je mesto u njihovoj klasi), a da implementacije tih f-ja stavis u color.cpp, gde se nalaze implementacije i za sve ostale
> > > f-je koje su
> > > > deklarisane u color.hpp. I onda kad si to uradio, testiraj f-je tako sto ces u main.cpp fajlu da obojis ceo tetrahedron (ili samo njegove vertekse,
> > > level=0) i da
> > > > ga ispises ponovo --- tj. nakon pozivanja njegovog tetrahedron->print_compact(), uradi
> > > >
> > > > UniqueIDColor::colorize_entire_complex( tetrahedron );
> > > >
> > > > ili umesto toga uradi
> > > >
> > > > UniqueIDColor::colorize_all_simplices( tetrahedron , 0 );
> > > >
> > > > i onda iza toga jos jednom pozovi tetrahedron->print_compact(). Zatim kompajliraj main.cpp i uporedi output-e ispisivanja tetrahedron-a pre i
> > > posle, da vidis
> > > > kako tvoje f-je menjaju ono sto se ispisuje. I to je to. ;-)
> > > >
> > > > :-)
> > > > 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, 21 Feb 2022, Dusan Cvijetic wrote:
> > > >
> > > > > Pozdrav,
> > > > >
> > > > > Konačno jedno pitanje koje se ne tiče Visual Studio-a, već samog koda.
> > > > >
> > > > > Naime, koliko sam razumeo iz potpisa funkcija, one treba da budu članice klase UniqueIDColor. Pošto je kroz ovu funkciju iz jednog poteza
> > > potrebno dodeliti
> > > > boje celom skupu simpleksa, a
> > > > > svaki simpleks dobija svoju jedinstvenu boju, ne vidim kako bi se ona mogla pozivati za pojedinačne objekte ove klase (trebalo bi pozvati
> > > konstruktore boje za
> > > > svaki simpleks), pa sam
> > > > > mislio da je realizujem kao statičnu funkciju članicu klase. Da li sam pogrešno razumeo ovaj deo, i zapravo treba dodeliti pokazivač na istu boju
> > > celom delu
> > > > simplicijalnog kompleksa,
> > > > > tj. čitavom kompleksu?
> > > > >
> > > > > Nezavisno od prethodnog tumačenja, imam problem sa hijerarhijom klasa koji ne mogu da savladam. Potrebno je da KSimplex ima vektor pokazivača na
> > > objekte klase
> > > > Color, pa je u classes.hpp
> > > > > uključen color.cpp. S druge strane, u color.hpp potrebno je uključiti classes.hpp, da bih mogao da iteriram kroz vektor simpleksa u kompleksu i
> > > dodeljujem
> > > > boje. Ovo vodi do rekurzivnog
> > > > > uključivanja fajlova: classes.hpp->color.cpp->color.hpp->classes.hpp. Čak i da se klasa KSimplex deklariše pre #include "color.cpp", ostaje isti
> > > problem, pošto
> > > > bez definicije klase ne
> > > > > mogu da pristupam njenim poljima, jer je i dalje nepotpuni tip. Trenutno ne vidim način da se ovo izbegne, osim da se izmeni hijerarhija klasa,
> > > ili raspored po
> > > > .hpp fajlovima. Propuštam
> > > > > li nešto ovde? Nikad nisam radio sa tuđim kodom na ovaj način, pa se izvinjavam što mi treba više vremena da savladam sve.
> > > > >
> > > > > Pozdravi,
> > > > > Dušan
> > > > >
> > > > > пон, 21. феб 2022. у 22:36 Dusan Cvijetic <dusancvijetic2000 at gmail.com> је написао/ла:
> > > > > Pozdrav,
> > > > >
> > > > > Hvala Vam mnogo, ponovio sam korake koje ste naveli u poruci, i Visual Studio sada uspeva da izgradi i izvrši kod, a čak uspeva i da mi farba
> > > kod bez dodatnih
> > > > koraka. Ipak, ne
> > > > > vidim koja je razlika u odnosu na ono što sam ja radio (File/New project from existing code), osim što se fajlovi nalaze na drugom mestu. Nije mi
> > > jasno zašto
> > > > isti kod hoće da
> > > > > izvrši kada se u projekat unese na jedan način, a baca greške kada se uveze na drugi...
> > > > >
> > > > > Isprva sam pokušao da ispratim vaše korake bez prethodno kreiranog main.cpp fajla, i video da tada Visual Studio uopšte ne nudi meni
> > > > Debug/Properties/Configuration Properties/C++,
> > > > > pretpostavljam zato što nema koda na osnovu kog bi zaključio u kom jeziku ću pisati (?). Pretpostavljajući da će pronaći ispravan kompajler
> > > ukoliko direktno u
> > > > VS kreiram main
> > > > > funkciju, prekopirao sam sve .hpp i .cpp fajlove u direktorijum projekta, prethodno napravivši main.cpp u VS uz kopiranje koda iz originala.
> > > Nadao sam se da ću
> > > > tako izbeći
> > > > > uključivanje dodatnih direktorijuma, i eventualno namestiti da mi se projekat nalazi u lokalnom git direktorijumu, što bi mi bilo najzgodnije
> > > (ako je ovo iz
> > > > nekog razloga loša
> > > > > praksa, napomenite mi, da odmah odustanem). Međutim, kada fajlove uvezem na ovaj način, ponovo baca iste greške kao i ranije.
> > > > >
> > > > > Pošto ovakva konfiguracija za sad radi, držaću se nje, ali ako neko ima ideju šta mi se dešava, bio bih zahvalan na objašnjenju.
> > > > >
> > > > > Pozdravi,
> > > > > Dušan
> > > > >
> > > > > пон, 21. феб 2022. у 18:09 Jaroslav Blagojevic <jaroslav.blagojevic at gmail.com> је написао/ла:
> > > > > Ja sam napravio prazan Visual Studio 2019 projekat, u drugom direktorijumu nego download-ovani repozitorijum, samo sa main.cpp fajlom kao
> > > "source files"
> > > > (hpp fajlovi
> > > > > kao "include files" i dodao direktorijum sa download-ovanim repozitorijumom u
> > > Dеbug->Properties->Configuration Properties->C++->General->Additional
> > > > Include
> > > > > Directories).Taj projekat sam izvršio uspešno, a za potrebe menjanja, pošto nije hteo da mi farba kod, sam morao da copy&paste-ujem .hpp
> > > fajlove (i cpp
> > > > fajl na kome
> > > > > radim) iz download-ovanog repozitorijuma u direktorijum projekta, izmenim .hpp fajlove (dodao sam nastavak '1' na svaki) da ne uključuju
> > > .cpp, kopiram i
> > > > .cpp fajl
> > > > > (isto dodajući nastavak '1'), izmenim, testiram i copy&paste-ujem promene nazad. Neće da farba kod u .cpp fajlovima, zato što ih ne tretira
> > > kao include
> > > > fajlove. Dotle
> > > > > sam stigao. Visual Studio traži da mu se svi .cpp fajlovi stave u projekat, a ne da se include-ju .cpp fajlovi u okviru jedan drugog.
> > > Pretpostavljam da
> > > > ako to uradimo,
> > > > > da će biti problem sa g++-om (da li on podržava projekte?)
> > > > >
> > > > > Pozdrav,
> > > > >
> > > > > Jaroslav
> > > > >
> > > > >
> > > > > On Sun, Feb 20, 2022 at 7:13 AM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
> > > > >
> > > > > Pozdrav Dusane,
> > > > >
> > > > > Meni se cini da svi problemi na koje si naisao izgleda dolaze iz neke greske prilikom import-ovanja koda u Visual Studio. Ja ne koristim VS
> > > i ne umem da
> > > > ti
> > > > > pomognem oko toga, ali Jaroslav rece da je uspesno importovao kod u VS, pa verovatno moze on da ti pomogne.
> > > > >
> > > > > Trenutna verzija koda je inace skroz kompletna, sve je definisano, implementirano i radi kako treba --- ja ga u Linux-u prosto kompajliram
> > > iz komandne
> > > > linije,
> > > > > ovako:
> > > > >
> > > > > g++ main.cpp -o izvrsi-me
> > > > >
> > > > > i onda kad izvrsim fajl "izvrsi-me", dobijem ocekivani output. Kompajler ne prijavljuje nikakve greske, sve prolazi savrseno glatko.
> > > > >
> > > > > > Koliko sam video, greške koje mi kompajler baca se uglavnom odnose na imena koja ne može da identifikuje, a koja dolaze iz standardne
> > > biblioteke.
> > > > >
> > > > > Pomoglo bi da nam posaljes te greske (makar prvih nekoliko), da vidimo o cemu se radi.
> > > > >
> > > > > > Video sam da je using namespace std iskorišćen na početku triangulator.hpp fajla, ali me je zanimalo zašto ta komanda ne stoji na početku
> > > svakog .hpp
> > > > fajla? Da
> > > > > li bi to bilo redudantno?
> > > > >
> > > > > Da, bilo bi redundantno. Dizajn je da main.cpp include-uje samo triangulator.hpp, a da ovaj u sebi include-uje sve ostalo sto mu treba. Ne
> > > vidim zasto bi
> > > > zeleo
> > > > > da deklarises namespace std vise puta. Mada mi se cini da cak i ako to uradis, ne bi trebalo da nastane nikakav problem.
> > > > >
> > > > > Bila bi dobra ideja da na papiru nacrtas "drvo include-ova": koren je main.cpp, pogledas koji fajlovi su tu include-ovani, pa se onda
> > > spustas po granama
> > > > tako sto
> > > > > onda otvoris te include-ovane fajlove i vidis sta oni include-uju, itd. Ja sam to bio uradio jednom, i preporucujem i tebi --- to drvo ti
> > > pruza vrlo lep
> > > > uvid u
> > > > > organizaciju koda.
> > > > >
> > > > > > Da li postoji neko pravilo kada treba da uključujem .hpp, a kada .cpp fajlove?
> > > > >
> > > > > Genericki receno, .hpp fajlovi sadrze definicije klasa i deklaracije njihovih metoda i f-ja, a .cpp fajlovi sadrze implementacije tih
> > > metoda i f-ja
> > > > deklarisanih
> > > > > u .hpp fajlovima. Oni su vec namesteni da include-uju jedni druge, prema onom drvetu, ti tu ne bi morao nista dodatno da radis.
> > > > >
> > > > > > Još jedna od praksi koje su nas uvek terali da ispoštujemo je dodavanje zaštite u zaglavlja u vidu #ifndef - #define - #endif strukture
> > > > >
> > > > > Ta praksa je sigurno dobra, ali mi smo #define-ovali konstante samo u constants.hpp fajlu, i nigde drugo. Iz drveta mozes da vidis da je
> > > constants.hpp
> > > > > include-ovan samo jedanput (unutar classes.hpp), pa ne bi smela nigde da ti se pojavi dupla definicija tih konstanti. Kasnije cemo
> > > verovatno da dodamo
> > > > #ifndef
> > > > > strukturu u constants.hpp, da budemo u skladu sa praksom, ali to nije sad najhitnija stvar --- kod momentalno radi ispravno i bez toga. :-)
> > > > >
> > > > > > pa bih cenio bilo kakvu pomoć koju možete da mi pružite.
> > > > >
> > > > > Jaroslave, jel' bilo neceg netrivijalnog oko ubacivanja koda u Visual Studio? Jel' imas neki hint za Dusana?
> > > > >
> > > > > :-)
> > > > > 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, 20 Feb 2022, Dusan Cvijetic wrote:
> > > > >
> > > > > > Pozdrav,
> > > > > >
> > > > > > Počeo sam da radim drugi zadatak kao što smo pričali, i imam problem sa pokretanjem koda. Nisam ništa menjao u fajlovima, samo sam
> > > napravio projekat u
> > > > Visual
> > > > > Studio-u 2019
> > > > > > (File/New/Project from existing code, sa svim default opcijama), i kada pokušam da ga pokrenem, kompajler mi baci gomilu grešaka. Da li
> > > je u ovom
> > > > trenutku
> > > > > generalno nemoguće pokrenuti
> > > > > > main.cpp, ili ja pravim neku grešku?
> > > > > >
> > > > > > Koliko sam video, greške koje mi kompajler baca se uglavnom odnose na imena koja ne može da identifikuje, a koja dolaze iz standardne
> > > biblioteke. Video
> > > > sam da
> > > > > je using namespace std
> > > > > > iskorišćen na početku triangulator.hpp fajla, ali me je zanimalo zašto ta komanda ne stoji na početku svakog .hpp fajla? Da li bi to bilo
> > > redudantno?
> > > > > >
> > > > > > Kada smo na fakultetu radili C++, uvek smo #include direktive koristili da uvezemo neke header-e u trenutni fajl, no video sam da se u
> > > kodu ovde nekada
> > > > > uključuju .hpp, a nekada .cpp
> > > > > > fajlovi. Da li postoji neko pravilo kada treba da uključujem .hpp, a kada .cpp fajlove?
> > > > > >
> > > > > > Još jedna od praksi koje su nas uvek terali da ispoštujemo je dodavanje zaštite u zaglavlja u vidu #ifndef - #define - #endif strukture
> > > (tražili su nam
> > > > da ne
> > > > > koristimo #pragma once jer
> > > > > > zavisi od kompajlera) kako bismo izbegli višestruku definiciju pri uključivanju zaglavlja. Da li mi koristimo neku drugu zaštitu za
> > > zaglavlja? Dosta
> > > > grešaka
> > > > > koje mi je kompajler bacio
> > > > > > je bilo zbog redefinicije promenljivih, pa pretpostavljam da je to zbog odsustva zaštite zaglavlja.
> > > > > >
> > > > > > Na par mesta su se pojavila imena koja ranije nisu definisana. Pretpostavljam da je to zato što još uvek nemamo ceo kod, pa nisu sve
> > > funkcije i
> > > > promenljive
> > > > > uvedene, no hteo sam ovde da
> > > > > > spomenem i te greške za slučaj da su problem samo kod mene.
> > > > > >
> > > > > > Na kraju sam pokušao da izmenim kod na mestima koje sam gore spominjao, samo da vidim mogu li ga naterati da se pokrene, i iako je
> > > kompajler prestao da
> > > > se
> > > > > javlja, linker je počeo da mi
> > > > > > baca greške. Pretpostavljam da postoji neko sistematičnije rešenje za moje probleme (do sada mi se linker javljao samo kada ne startujem
> > > projekat u VS
> > > > kako
> > > > > treba), pa bih cenio bilo
> > > > > > kakvu pomoć koju možete da mi pružite.
> > > > > >
> > > > > > Pozdravi,
> > > > > > Dušan
> > > > > >
> > > > > >
> > > > > > пет, 11. феб 2022. у 22:34 Marko Vojinovic <vmarko at ipb.ac.rs> је написао/ла:
> > > > > >
> > > > > > Upoznati se sa osnovnom klasom Color i njenim child-klasama kroz problem dodeljivanja boje UniqueIDColor datom delu simplicijalnog
> > > kompleksa,
> > > > odnosno
> > > > > celom kompleksu:
> > > > > >
> > > > > > bool UniqueIDColor::colorize_all_simplices( SimpComp* G , int level );
> > > > > > bool UniqueIDColor::colorize_entire_complex( SimpComp* G );
> > > > > >
> > > > > > Input: pointer na simplicijalni kompleks, nivo "k" za k-simplekse koje treba obojiti.
> > > > > > Output: true ako je uspesno izvrseno bojenje, false ako je doslo do neke greske.
> > > > > >
> > > > > > F-ja colorize_all_simplices() treba da prodje kroz sve simplekse iz G.elements[level] (ili se pise G->elements[level]?), i svakom
> > > od njih da
> > > > dodeli
> > > > > instancu boje klase
> > > > > > UniqueIDColor. F-ja colorize_entire_complex() treba da izvrsi prethodnu f-ju za sve vrednosti 0 <= level <= D. Nakon toga,
> > > zakomentariti kod koji
> > > > > dodeljuje ovu boju u seed
> > > > > > f-ji seed_single_triangle() (boju boundary ne dirati, ona treba da ostane u seed f-ji), i umesto toga u main() f-ji eksplicitno
> > > pozvati
> > > > > colorize_entire_complex() da oboji
> > > > > > kompleks za trougao, odmah nakon sto se ovaj instancira.
> > > > > >
> > > > > >
> > > > > > :-)
> > > > > > 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
> > >
> > > --
> > > 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