BGAFC Vendégkönyv

Σ: 1 post

saxus (statz)

#9, Agyfasz (419)

3914 | #21b3 | ^ | Idézet | Fri, 16 Nov 2012 23:03:25 +01

31.46.*.*

*.dsl.pool.telekom.hu

Banom is en, hogy milyen a kod, (sztem otthon valahol meg meg is van, csak most hetvegere hazaneztem szulokhoz) csak ne egyesevel kelljen kicsakanyolni az osszeset. (Segitek: nem szeretek megoldott feladatokat ujra megoldani, ha nem muszaj.)

xv file meg.. Ennel picit osszetettebb. Valojaban tobb fajl osszecsomizva vegen 4 byte a fileoffset + 64 byte a fajlnev meg a legvegen a darabszam. Bar eddig trivi. Ami mar kevesbe trivibb az a material (xvm) fajl meg a modell felepitese. (xvo). Bar utobbinal vannak tippeim, bar eloszor muszaj lesz szetkapni. Mindenesetre elso blikkre leginkabb egy binaris .obj variacionak tunik. Material mar erdekesebb kerdes, viszont lovesem nincs, hogy mire szolgalhat az xvb. Talan tartalmazza, hogy a tobb xvo-t hogyan allitsam ossze, csak ahhoz meg tul nagy a merete.

"Bár öcsémnek állítólag volt valahol xv pluginja Maya-hoz"

Konkretan arra nem talaltam infot, hogy ez a DR valami sajat formatuma-e vagy valami letezo szabvanyos cucc. Inkabb az elobbinek tunt.

---

Magas/alacsony szintet latom nem sikerult megertened. Ha arrol van szo, hogy egy nagyobb, sokmodulos projektet (akar sok kulon csapatos!) felulrol kell atlatni es azokat egyuttmukodesre birni, mindezt ugy, hogy utana karbantarthato is maradjon az egesz cucc, azon a szinten nem erdekes az, hogy alacsony szinten mi tortenik. OOP abban jo, hogy ezt az architekturat letrehozd es benne rendszerbe szedd az adataid. Nem abban, hogy alacsony szinten valami muveszit alkoss, de ezt mar annyiszor kibeszeltuk. Meg azt is, hogy vannak gazdasagi erdekek is a vilagon, akar tetszik, akar nem.

"Mert OOP nélkül az absztrakció lehetetlen, ugyi."

Neme, de a jelenleg ismert egyik legjobb eszkoz ra.

"minek következtében a felülről jól megtervezett és megszervezett program belül - alacsonyszinten - olyan brutális káoszba fullad,"

Akkor az egy szarul megtervezett program. En mondtam, hogy nehez az OOP-t jol csinalni.

"(foleg parhuzamositott programoknal) egyszerubb egy zart egyseg konzisztenciajanak fenntartasa" "Miért?"

Fut ket szalad, egyik fokozatosan noveli, masik fokozatosan csokkent egy intet. Idovel teljesen biztos, hogy el fog maszni a 0-tol, mivel az inkrementalas/decrementalas alapvetoen nem atomi muvelet. Erre talaltak ki a kulonfele lockolasi technikakat. Ha te az adathoz egy jol bekorlatozott helyen fersz csak hozza (pl. setter/getter fv, vagy property), akkor csak egy helyen kell megoldanod a lockolast. Egyeb esetben neked az osszes letezo hivo helyen meg kellene valositani, amit raadasul nem tudsz kikenyszeriteni sem.

Ez kulonosen azoknal a nyelveknel, modszereknel valik erdekesse, ahol nem a shared everything, hanem a shared nothing elv ervenyesul. Pl. erlang. Ott nincs thread, vagy hasonlo, sok kis lightweright process van (ez nyelvi szintu, Actor modellben actor-nak hivjak azonosithato egy objektum szeru valamivel, de annal azert tobb), es akozott csak uzenetvaltasokkal tudsz kommunikalni. Az adott actor nem is fogad addig mas uzenetet (kb. metodushivassal parhuzamosithato), mig egyet be nem fejezett. (Az uzenetek elosztasat meg maga a runtime resz kezelte) Igy meg csak veletlenul sem fordulhat elo olyan eset, hogy egy processen/actoron/objektumon/izen/akarmin akkor kezdesz el operalni valamit, mikor az epp egy masik muvelet kellos kozepen van es valami (hivo fel szamara) total ertelmezhetetlen allapotban leledzik. Persze, igy egy process egyszerre csak egy dologgal foglalkozhat (bar erlang eseten allitolag ezt okosan megoldottak, hogy azert annyira megse), de lockolas eseten is ezt tortenik, csak ott meg tovabb ront a lock mechanizmus kezelese a dolgon. (Erlangnal pl. nem letezik lockolas).

Hogy hol jon ez a parhuzamossaghoz? Ugy, hogy mi van akkor, ha ilyen processbol kell mondjuk 20 millio? Nem veletlen, hogy a telco szektorbol szivarogtak at ezek a nyelvek es megoldasok a tobbi nyelvekbe, piacokra.