HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

  • sdani: Oh... néha eszembe jut, hogy az EBI után esetleg vissza kellene menni valamennyire az akadémiai vo... (2025.03.18. 16:58) Pontos, jól behatárolt célok
  • legyen úgy: Szia, Értem és köszönöm a válaszodat! T. (2025.02.24. 18:23) Expose CTF
  • sdani: Sajnos nekem is hasonló érzéseim vannak az R kiszorulásával kapcsolatban. Remélem jobban fogja tar... (2024.04.29. 10:48) R meetup
  • sdani: Nagyon jók ezek a bejegyzések! Feszültséggel teli, fordulatos, mint egy jobb krimi. :D Abba ne hag... (2024.04.29. 10:35) Wgel CTF
  • sdani: @Travis.CG: Egy kis szerencse sosem árt. :D (2024.03.01. 13:19) A bioinformatika helyzete 2024-ben

Mozilla democompo

2011.06.18. 17:15 Travis.CG

A Mozilla Labs böngészőben futó demóknak szervez partit. A nevezett alkotásoknak a cég legújabb böngészőjén kell futnia. Öt kategóriát állítottak fel:

  • Animált GIF. Ez egyfajta grafikai kategóriának felel meg.
  • Egy effektes compo: Ez párhuzamot mutat egy introval.
  • CSS3 Compo: Ezt nem tudom minek megfeleltetni. A lényeg, hogy csak CSS3 manipulálást engedélyeznek?
  • Audio demo: A compo zenei kategóriája. Lehet generált zenével is indulni, mintha csak executable music compo lenne.
  • Full Demo: Ahol csak a képzelet szab határt.

Ha valakinek megtetszett a kiírás és úgy érzi nem tudja hol álljon neki, az látogassa meg ezt a blogot.

Szólj hozzá!

Címkék: demoscene

Presztizs

2011.06.13. 08:55 Travis.CG

Azt hiszem jó hatással vagyok a mukatársaimra. Eddig könnyedén kijelentettek dolgokat, majd mindenféle ellenőrzés nélkül elterjesztették, amit később mások igaznak fogadtak el. Ilyen kijelentés például, hogy az Amazonon a programok futását az I/O műveletek visszafogják. Ilyenkor én mindig megkérdeztem, hogy mire alapozzák a kijelentésüket, van-e bizonyítél, esetleg megmérték-e valamilyen módszerrel.

Szép lassan eljutottunk oda, hogy validálunk, ellenőrzünk, és nem csak valami homályos látomás alapján teszünk kijelentéseket, hanem tények birtokában.

De én továbbra is csak egy kis morzsa vagyok a gépezetben. Még nincs doktorim sem. Mi történik, ha két különböző ember elméletileg hasonló mérése nem egyezik meg? Mi történik, ha egy híres, külföldön tanító professzor egyszerű vizsgálatát megismétlem, és különböző eredményt kapok? Ez a professzor pedig nagyon híres. Egy zseni, egy művész. Olyan gondolatok megálmodója, amire mások képtelenek.

Vele szemben én egy senki vagyok. A proffal már találkoztam, de annak ellenére, hogy többé-kevésbé egy témán dolgozunk, a nevemet sem tudja.

Ilyenkor az a reakció, hogy bizonyára én szúrtam el a vizsgálatot. Ennek megfelelően leellenőriztem a vizsgálat menetét és megismételtem azt. A különbség megmaradt. Hibakeresés, hiba megtalálása. Az eredmények megváltoztak, de a különbség továbbra is megmaradt. Végül eljutottam oda, hogy minden apró hibát kijavítottam, amit csak találtam, de a különbség megmaradt.

Ezek után kénytelen voltam levonni a következtetést, hogy a sztárprofesszor megoldása a hibás. Csakhogy hiába mondom, hogy többszöri ellenőrzés után is ott a különbség. A főnököm, aki rá sem nézett az adatokra, sem a vizsgálat menetére, egészen biztos benne, hogy csakis én szúrhattam el valamilyen lépést. A professzort nem lehet megkérni, hogy egy ilyen bagatel hiba felderítésében segítsen, pláne nem lehet feltételezni, hogy ő elronthat valamit. Helyette egy másik ember, tőlem függetlenül megismétli a vizsgálatokat. Majd utána kiderül, hogy merjük-e zavarni a nagy embert.

Szerkesztés: A megoldás roppant egyszerű volt, nem ugyan azokat a paramétereket használtuk, tehát mindenkinek igaza volt.

Szólj hozzá!

Címkék: életmód

Hogyan járassuk le magunkat, avagy mi történt azon a bizonyos szomorú napon

2011.06.13. 08:28 Travis.CG

Már elég idő eltelt a 2010-es Function óta. Azt hiszem eléggé feldolgoztam a sokkot, hogy kiírjam magamból az ott történteket. Amikor a repülőgépes katasztrófákat felderítik, akkor legtöbbször megállapítják, hogy olyan sorozatos hibákat követtek el, ami külön-külön orvosolható lett volna, de abban a kombinációban olyan halálos elegyet alkotott, hogy a gép nem élhette túl. Körülbelül az én esetem is ilyen volt.

Egy szeptemberi hétvégén volt a Function nevű demoshow. Már jó ideje készültem rá, hogy végre megmutathassam, hogy nem
csak windows alatt lehet jó demót készíteni. Szombaton érkeztem a parti helyére, még időben, hogy
leadhassam Grass kézi rajzát és feltöltsem a demót. A demó rengeteg nagy méretű textúrát tartalmazott,
több részletes poligonnal, ezért nem meglepő, hogy bizony a mérete 39 MB-ra rúgott.

Szerencsére 64mb volt a mérethatár, így ez nem okozott gondot. Ez volt az első demóm, ahol nem a jól
ismert SDL könyvtár képezte a keretrendszert, hanem alacsony szintű függvényhívások: libpng a textúráknak,
vorbis a zene dekódolásának, alsa a hang lejátszásához, X11 az ablakkezeléshez. OpenGL tudásomat is
fejlesztettem, ezért már shaderek is voltak a demó egyes jeleneteiben, ami megakadályozta, hogy
a céges laptopon futtassam.

A parti előtt két nappal gyakorlatilag kész voltam a teljes demóval. Annyit elárulok, hogy Slackware 13.0-n
fejlesztettem, méghozzá 64 bites rendszeren. Ekkor még nem volt semmi információm arról, hogy milyen
Linuxon akarják majd levetíteni a demót, de a tavalyi tapasztalatok alapján abból a feltételezésből
indultam ki, hogy egy 32 bites Ubuntu lesz a compógép.

Telepítetem az Ubuntut, lefordítottam a demót és láss csodát, nem volt hang. Tulajdonképpen nem
lepett meg, hiszen itt PulsAudio van, aminek az Alsa-s emulációja nem teljes. Példának okáért
hiányzik az aszinkron hanglejátszás. Mondanom sem kell, hogy természetesen én azt implementáltam.

Gyorsan felvettem egy új függvényt a cg_audio.c-be, ami láss csodát, tökéletesen működött. Csak nem
Slackware alatt. Itt kellett volna még tovább finomítani a rendszert, hogy mindkét rendszer alatt
tökéletesen menjen, de ezt nem tettem, pedig Richard Marchinko is megmondta: "Soha ne feltételezz!".
Én feltételeztem. Mégpedig azt, hogy Ubuntu alatt fogják lejátszani.

A parti nagy fordulópontja az volt, mikor találkoztam Gargajjal, az egyik szervezővel. Megkérdeztem
tőle, volt-e bármilyen probléma a demóm lejátszásával.
- Ha nem Linuxos, akkor nincs vele gond - válaszolta.
- De Linuxos.
- Itt van a laptopod?
- Itt, de azon nem megy. Kell neki OpenGL 2.0.
Rövid kutakodás után találtunk valakit, akinek szintén volt egy Linuxos laptopja. Rövid próbálgatás után
azt is kiderítettük, hogy ugyancsak Intel GMA-val van felszerelve, nem megy rajta a demóm.

Láttam, hogy a helyzet kezd menthetetlen lenni. Latolgattam, hogyan jutok haza, hogy elhozzam
a saját gépemet. Charlie segített. Képes volt miattam levezetni megközelítőleg 100km-t, hogy
elhozzuk azt a gépet, amin fejlesztettem a demót. Átadtam a szervezőknek és megnyugodtam,
hogy most már semmi baj nem történhet. Ez volt a második hiba.

Az intrók után Gargaj szólt, hogy itt az ideje, hogy beüzemeljem a gépet. Kaptam áramot, hangcsatlakozót,
videó kimenetet. Egy profinak ennyi is biztosan elég lenne, de én azért kértem egy billentyűzetet is.
Hátam mögött a kíváncsi tömeggel nekiáltam az óriás kivetítőn beizzítani a rendszert. A Slackware szép
komótosan indult. Mikor az X11-et indítottam, akkor már láttam, hogy baj van. A gép 640x480 felbontásban volt. Rövid billentyűn
keresztül történő matatás után észrevettem, hogy az NVidia beállítópanel sem ismer nagyobb felbontást,
mint 640x480
. Most mi legyen? Kértem egy egeret, amivel kicsit gyorsabban folytattam a matatást.

Mögöttem már kezdett zúgolódni a tömeg. Elindítottam a demót, hátha az majd belövi a felbontást, de nem így történt. A demó bal felső sarka látszott csak.
Végül megnyitottam a forráskódot és átírtam, hogy 640x480-ban fusson le. Ez már nagyon nem tetszett a
nézőknek, hogy ott írom át a kódot. Fordítás sikeres volt, rövid teszt, működik, leállítottam, és szépen hátra
kullogtam.

- Nyomd le az entert! - hangzott fel. Visszafutottam és elindítottam a demót. Ismét hátra kullogtam. A terembe már nem mertem bemenni, csak a folyosóról hallgatóztam és a hangokból próbáltam kitalálni, hogy milyen a demó fogadtatása.

Valami nem stimmel. Miért nem hangosítják fel? Miért nincs hang? Ezt mások is megkérdezték, de nekem akkor nem
esett le. Semmit ötletem nem volt. Közben a demó szépen ment hang nélkül. Emlékeztem, hogy az elején, a teszt alatt még volt. Az első teszt alatt! A
fordítás után már nem! Akkor megértettem. Azt a kódot fordítottam le, ami Ubuntu alatt ment, de Slackware alatt
nem. A demónak a fele akkor már lement. Hallva a bekiabálásokat úgy döntöttem, hagyom így. Úgysem tetszik nekik,
akkor minek fárasszam a nézőket még zenével is? Ennek megfelelően utolsó lett, de akkor már nem foglalkoztam a
dologgal.

Minden esetre megtanultam, hogy atombiztos demót kell írni. Különösen Linux alatt. A másik, ha valami gond van
vele, inkább nem szabad hagyni, hogy lejátszák.

Később visszagondolva több módon is elkerülhettem volna a problémát. Először is, a gépemen volta Ubuntu is. Elindíthattam volna azt is. Normálisan megírhattam volna a kódot (csak egy snd_pcm_recover függvény hiányzott). Nem hagyom, hogy a két kódbázis összekeveredjen. Ehelyett egy olyan elegyet főztem, ami megpecsételte a demó sorsát.

Szólj hozzá!

Címkék: demoscene parti riport

MPI klaszter és kémiai informatika

2011.06.13. 08:02 Travis.CG

Mivel soha életemben nem foglalkoztam kémiai informatikával
és soha nem installáltam több processzoros gépre semmit, ezért
itt volt az ideje, hogy mind a kettőt kiadják nekem feladatnak.

Az Amazon rendszerén van lehetőség egy 16 processzoros, processzoronként
4 magos gép igénylésére. Erre kellett felvarázsolnom az ADF nevű
programot. Lehetőleg úgy, hogy azt a gépre bejelentkező potenciális
ügyfelek ne tudják ellopni.

Egyszerre csak helyzetet tudok kezelni, ezért az installálással kezdtem.
A program igényel egy MPI implementációt. Ha 64 bites Linuxra szeretné
telepíteni az ember, akkor két lehetőség közül választhat: HP-MPI, vagy
Intel-MPI. Az Intel mellett döntöttem, még akkor is, ha ezzel az Amigás
társadalom mély megvetésére számíthatok.

Az Intel-MPI telepítése nem igényel különösebb leírást, az elavult
telepítési útmutató több-kevésbé lefedi a lépéseket. Pl. Nem kell
liszensz fájl, mint ahogy írják. Az ingyenes futtató környezet
letöltése igaz, regisztrációt igényel, amit csak nagy vonakodva voltam
hajlandó elvégezni.

Az ADF telepítése, még ennél is könnyebb. Egyszerűen kicsomagolja magát
az aktuális könyvtárba, és nesze, használd. Egy liszensz fájlt kell
az ADF könyvtárába másolni, és már készen is áll a kémia titkainak
feltárására. Már ekkor sejtettem, hogy ebből gond lesz. Milyen jogosultságot
tudok adni neki, hogy elrejtsem ezt a felhasználó elől? Ha nincs
olvasási joga a liszensz fájlra, akkor nem indul a program. Ha van,
el tudja lopni. Ezt a problémát későbbre halasztottam és megnéztem, mit
tud a program.

Az ADF Fortran nyelven írt alkalmazás, ami laikusként annyit csinál, hogy
szöveg fájlokat olvas be és szöveg fájlokat ír ki. A bemeneti állományok
atomokat, távolságokat és szögeket tartalmaznak, a kimenet bő beszédű
leírásokat.

A rendszer rész még egy teljes értékű Python értelmező is, ami a körülbelül
180 MB-os programból 120MB-ot foglal el, valamint egy Tcl/Tk is helyet kapott.

A teszt adatok között keresgélve találtam egy érdekeset. Azt elindítottam,
az eredményt összehasonlítottam a példa eredménnyel. Nagyjából megegyezett,
ezért úgy gondoltam, készen is vagyok.

A láthatóság problémáját sodu-val oldottuk meg. Így minden egyes parancsot
sudo-val lesz kénytelen futtatni a felhasználó, de cserébe nem látja még
a könyvtár szerkezetet sem. Hátránya, hogy az eredmény fájlok más
felhasználó alatt (soduer) jelennek meg. Ez még további finomítást igényel.

A gondok itt nem értek véget. Kaptam egy másik teszt adatot, amivel szintén
ki kellett próbálni az ADF-t. Indítás után rögtön azt kaptam a képembe, hogy
nincs host. Hűha! Eddig nem kellett. Gyorsan megnéztem a régi teszt adatokat.
Bizony ott is kellett, csak valami csoda folytán túlélte a program és lefutott,
de most nem. Rövid keresgélés után kiderült, hogy kell egy mpd.hosts fájl.
Rendben, hozzuk létre. De hova? Betettem az /etc-be, a telepítés helyére, de
egyik sem tetszett neki. Végső elkeseredésemben a munkakönyvtárba helyeztem.
Az tetszett neki. Később kiderült, hogy a dokumentáció (nem a getting started,
mert az túl nyilvánvaló lett volna) egy helyen leírta, hogy az mpd.hosts
bizony csak az aktuális munkakönyvtárban helyezhető el. Érdekes! Miért
nem jó az /etc vagy a felhasználó könyvtára?

A következő probléma, hogy nem volt hajlandó egy hoston futni. Tizenhat
processzor van a gépen, de neki nem volt elég, mert csak egy hostot látott.
Beírtam neki tizenhatszor ugyan azt a hostot, de az sem segített. Végül egy trükkhöz folyamodtam.
Az Amazonon minden gépe kap egy nevet. Beírtam azt, és a localhostot. Ez
segített. Viszont nem tudott kapcsolódni saját magához.

Tehát meg kell oldanom, hogy rsh-val a számítógép önmagához kapcsolódjon.
Ez nevetséges. Kell, hogy legyen valami más megoldás. Közben kiderült, hogy
amit én a tesztek idején úgy értelmeztem, hogy lefutott, az valójában nem futott le.
Ugyan az a hibajelenség volt ott is, mint itt.

A megoldás pedig olyan egyszerű volt! Letöltöttem a HP-MPI-s verziót, és
futott minden szépen.

Szólj hozzá!

Címkék: rendszergazda cloud computing

NTFS átméretezés

2011.06.13. 07:54 Travis.CG

Unatkozik hétvégenként? A számítástechnika túl átlátható? Méretezze át NTFS partícióját!

A céges laptopomon Windows van, de úgy éreztem, hogy Linuxot kell rá telepítenem, anélkül, hogy a Windows törlésre kerülne. Az ok egyszerû: a doktorimat LaTeX alatt készítem, és kell egy olyan megoldás, amivel a akkumulátor barát módon tudom szerkeszteni azt. Erre a legegyszerûbb megoldás a Linux konzol. Konzol alatt sok olyan felaadtot el lehet látni, ami nem igényli a grafikus felületet. Az egyik ilyen a szövegszerkesztés (itt most a szöveges állományok módosítását értem, nem a kiadványszerkesztést).

Ahelyett, hogy valami kereskedelmi programot használtam volna erre, mindezt ingyenes, nyílt forráskódú programokkal akartam megoldani. Azt rögtön sejtettem, hogy a Windows partíció átméretezéséhez elõször defragmentálni kell a fájlrendszert. A rendszer saját programját használtam erre, pedig, mint késõbb megtudtam, ezt a lépést is megcsinálhattam volna Linux alatt. A program finoman szólva is nem hozza a kívánt színvonalt. Többször egymás után el kellett indítani, hogy képes legyen kitölteni a réseket a használat alatt álló blokkok között.

Olvastam, hogy Knoppix alatt megvan minden szükséges program, amivel a Windows partíciókat átméretezzem. A Knoppix egy CD-rõl vagy DVD-rõl futó Linux disztribúció, telepítés nélkül is mûködõképes. Fõleg adminisztrációs célokra használom, tehát nem volt ismeretlen számomra, de csak a 2001-es verzió volt meg. Letöltöttem a legújabb, 6.2-es verziót és nekiláttam a munkának. Gyorsan meg is találtam az NTFS resize programot. A súgó javasolta, hogy ha nem vagyunk biztosak magunkban (én nem voltam), akkor használjuk valamelyik klikkelõs keretrendszert, például a GParted-et. Klikkelõs, egyszerû, bolond biztos. Ez kell nekem! Játszottam az egérrel, húztam-vontam a csúszkákat és a Windows partíció összement. Gondoltam, ha már itt vagyok, elkészítem a Linuxos partíciókat is. Azok elkészítése is gyorsan ment. Végül következett a változtatások kiírása. Ellenõriztem, hogy minden rendben van-e, majd kiadtam a parancsot: írd ki a változtatásokat.

A program jelezte, hogy az NTFS partícióval gond van. A volume mérete nagyobb, mint a drive mérete. Gondoltam, majd átmegyek Windows alá és a chkdsk segítségével orvosolom a dolgot. Itt jött az elsõ fekete leves. Nem tudtam átmenni Win alá. Sem csökkentett módban, sem parancssorban, sehogy. Természetesen semmilyen biztonsági mentést nem csináltam a partíciós tábláról, aminek segítségével könnyedén visszaállíthattam volna a régi állapotot. Eszembe jutott, hogy van Norton Systemworkom, ami annak idején sokszor kihúzott a slamasztikából. Emlékeztem arra is, hogy a CD képes bootolni. Nincs más dologm, mint elõkeresni a CD-t kiírni, majd megoldani ezt a kis malõrt. Nem oldotta meg. Ez egy 2003-as verzió volt, ráadásul egyedül a virus irto indult csak el, amikor bootoltam a CD-vel.

Már láttam magam elõtt, amint a cég rendszergazdája kérdezi, mi történt a laptoppal. Mit mondjak? Leejtettem? Csak Linuxot akartam rá telepíteni és tönkretettem a Win partícióját? Esetleg forduljak a jó öreg kifogáshoz: Nem tudom, egyszer mûködött, de a következõ pillanatban ezt csinálta. Azt tudtam, hogy a fájlok megvannak rajta. Azt is tudtam, hogy ezt vissza lehet hozni. Csak azt nem tudtam, hogyan.

Ekkor léptem meg azt, amit már jóval korábban kellett volna. Rákerestem a Google-n. Kiderült, hogy a GParted rosszul állítja be az NTFS fájlrendszer méretét. Ugyanis annak egy szektorral kevesebbnek kell lennie, mint amennyi rendelkezésre áll. A fórumon egy segítõkész ember a neki elküldött partíciós táblákat javította. Ugy gondoltam, ezt én is meg tudom csinálni. Elõször is a jó öreg dd paranccsal lementettem a partíciós táblát, majd hexeditorral megnyitottam. A második sorban volt a méret letárolva. Kiolvastam a GParted hibanaplójából a méretet, kivontam belõle egyet, a méretet hexadecimálisba alakítottam. Itt egy kicsit tanácstalan voltam, hogy milyen bájtsorrendet kell használni, ezért a fórumban leírt méretek és hexa értékek alapján kisakkoztam. dd-vel visszaírtam a partíciós táblát és különbözõ voodoo szertartások közepette újraindítottam. Múködött! A Linux telepítése ehhez képest már semmi nem volt.

Szólj hozzá!

Címkék: rendszergazda

A húzódzkodó rúd

2011.05.31. 20:00 Travis.CG

Van egy célom. Szeretnék egy kézzel húzódzkodni. Ehhez nagyon sok húzódzkodást kell csinálni. A házunk előtt van egy szőnyeg poroló, télen viszont nagyon hideg a vascső. A kesztyű nem jó alternatíva, mert nehezíti a fogást. A hideg egyébként is növeli a sérülés veszélyt a gyorsabb kihülés miatt. De az igazi indok, hogy lusta vagyok hidegbe kimenni.

Többször gondolkodtam rajta, milyen megoldást lehet találni a problémára. Végül egy ajtókeretbe feszíthető rúd látszott a legjobb megoldásnak, amit egy ismerősöm lakásában láttam. Azonnal megtetszett a szerkezet egyszerűsége és praktikussága. Szimpatikus volt az is, hogy bármikor eltávolíthatom, anélkül, hogy maradandó károsodást okoznék a lakáson.

Rövid kutakodás után találtam egy hegymászóknak szóló blogot, ahol a hozzászólások között írták, hogy vigyázni kell, mert a rúd talpai benyomódhatnak az ajtókeretbe, célszerű valamilyen talpat használni. Megörültem a hasznos tanácsnak. Igen, erre nem is gondoltam! Szerencsére van néhány használaton kívüli laminált padló, majd abból vágok magamnak megfelelő talpat.

Szépen le is vágtam a padlót a megfelelő méretre, majd ügyesen egyensúlyoztam, hogy miközben csavartam ki a rúd talpait, azok egyenlő távolságra legyenek, valamint a padlóból vágott darabok is az ajtókeret és a talpak között maradjanak mindeközben.

Mikor már a gravitációnak ellenállt a szerkezet, elengedtem a talpakat és tovább tekertem a rudat, hogy jól beleszoruljon a helyére. Már masszívan állt, de én tartva, hogy esetleg mégis kicsúszik, még tekertem rajta. Azután még egy kicsit, csak hogy egészen biztos legyek a dolgomban. Ekkor reccsent egy nagyot az ajtófélfa. Egy hatalmas repedés keletkezett a felső sarkában. Pár hónapja festettem és javítottam le. Szörnyű volt látni, hogyan pusztítottam el a munkámat.

Csak ezután jutott eszembe, hogy van egy másik ajtófélfa is a lakásban, amit nemsokára úgyis ki is fogunk cserélni...

Talán mondanom sem kell, hogy ott semmilyen sérülés nem keletkezett a felszerelés során.

Szólj hozzá!

Címkék: sport életmód

AmiCon találkozó

2011.05.31. 19:54 Travis.CG

A hazai Amigás közösség legnagyobb összejövetele az AmiCon. Lázi ilyenkor vendégül látja ennek a különleges gépnek a rajongóit, a résztvevők pedig bemutatják, megbeszélik az amigás világ legfrissebb történéseit.

Én friss tagja vagyok a közösségnek, ez volt az első alkalom, hogy részt vettem  az AmiCon-on. Többen is megjegyezték, hogy idén kimagaslóan sokan jöttek el. Ülni csak a korán érkezőknek sikerült.

Az első érdekesség a Hollywood Designer bemutatása volt. Ezt a programot egyetlen Amigás fanatikus fejleszti. Ha a program képességeit le akarnám degradálni, azt mondhatnám, hogy egy Amigás Flash alkalmazásról van szó. Bemutatókat, prezentációkat készíthetünk vele. Interaktív tartalmakat hozhatunk létre segítségével.

Az Amigás közönség alaposan szétforgácsolódott, ahogy egyre újabb és egymással alig-alig kompatibilis rendszer jelent meg. A Hollywood Designer igyekszik minden platformon ugyan azt a felhasználói élményt nyújtani. A Windows és Mac felhasználók sem panaszkodhatnak. A program képes futtatható állományt készíteni a bemutatókról ezekre a platformokra is.

Akik előnybe részesítik a programozást a vizuális szerkesztők helyett, azok a Hollywood beépített szkriptnyelvét használhatják. A bemutatón az is elhangzott, hogy a jövőben C nyelven írt bővítményeket is lehet majd használni.

A másik nagy bejelentés egy új Amigás újság megjelenése volt. A szerzők célja, hogy elsősorban a klasszikus rendszerről jelenítsen meg minél több hasznos információt. A PDF-ben terjesztett verzió ingyenes, a nyomtatott változatért értelemszerűen fizetni kell.

A megjelenésnek természetesen mindenki nagyon örült. Reméljük a szerkesztőknek lesz elég idejük és lelkesedésük is, hogy folytathassák a munkát.

Hallottam egy jópofa történetet is, igaz C64-ről, nem Amigáról. A történet főhőse Ratman, akit egy nap felhívtak, hogy nem megy a program.

- Milyen program? - kérdezte.
- A nyilvántartó program - ekkor kezdett el derengeni neki, miről is lehet szó.

Kiment a helyszínre, ahol talált egy C64-t, egy nyomtatót és egy floppy egységet. Ratman megkérdezte, hogy kivették-e bármikor is a lemezt. Azt mondták nem. Óvatosan kivette a lemezt, amit az idő és a fejmozgás papír vékonyságúra koptatott. Már olvashatatlan volt. Reménykedve megfordította és fellélegzett. Ott volt a forráskód!

Otthon rövid debuggolás után kiderült, hogy mi volt a hiba. A program, ami a kilencvenes évek közepén készült, simán túlélte a PC-s világot fenyegető Y2K-t, de  2008-t már nem. Kijavította a hibát és visszaküldte a programot.

Én még arra voltam kíváncsi, hogy annak idején hogyan tanultak meg kódolni az emberek. Manapság elég megnyitni kedvenc keresőprogramunkat és máris tanulhatjuk a kódolás minden csínját-binját. De ez annak idején lehetetlen volt.

Mint megtudtam, az első lépés, hogy warez forrásból kellett szerezni egy fordító programot. A második lépés, hogy a szükséges dokumentációt (ami legtöbb esetben hibás volt) fénymásolt lapokon be kellett szerezni. Ezt legtöbbször egy lelkes illető lefordította angolról, további hibákat és elírásokat vétve. Végül a programozó palánta beírta és lefagyasztotta vele a gépét.

A tanulás második lépése pedig az volt, hogy ki kellett kísérletezni, mi az, ami működik és mi az, ami nem. Tehát a tudás megszerzése inkább egyfajta felfedezés volt.

Szólj hozzá!

Címkék: amiga parti riport

Linux hangképzés

2011.05.26. 21:22 Travis.CG

GNU/Linux rendszeren sokféle módja van annak, hogy hangot csiholjunk ki a gépből. Itt is megfigyelhető az a tendencia, hogy az eszközök egymásra épülnek és mindegyik célja az, hogy elfedjék szegény programozók elől a problémás részeket.

Ha viszont a lehető leghordozhatóbb megoldásra van szükségünk, akkor célszerű átvágni magunkat az API-k dzsungelén, hogy megleljük a tiszta forrást. Ez nem más, mint az ALSA. Az ALSA segítségével előállíthatunk bármilyen hangot. Szerény véleményem szerint nem olyan bonyolult a használata. Ez azonban nem jelenti azt, hogy nem érhetnek minket meglepetések. Erről majd egy következő bejegyzésben részletesen is írok.

A zenét mi Ogg/Vorbisban tároljuk, ezért a példaprogramban a vorbis könyvtárat is használni fogjuk.

Inicializálás

Első lépés, hogy beállítsuk a kívánt paramétereket. Milyen eszközön, milyen típusú puffert használunk és milyen minőségű hangot kívánunk megszólaltatni.

snd_pcm_open(&playback_handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
   snd_pcm_hw_params_malloc(&hw_params);
   snd_pcm_hw_params_any(playback_handle, hw_params);
   snd_pcm_hw_params_set_access(playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
   snd_pcm_hw_params_set_format(playback_handle, hw_params, SND_PCM_FORMAT_S16_LE);
Minden parancs snd_pcm-el kezdődik. Ezt könnyű lesz megjegyezni. Először meg kell nyitni az eszközt. Az eszköz nevét egy sztring határozza meg. Ha több hangkártya is van a gépbe, akkor explicite megadhatjuk, hogy melyik eszközt használjuk. Ha hordozható megoldásra vágyunk, akkor legyen "default".

A második sorban lefoglaljuk a memóriát a paramétereknek, majd beállítjuk azokat. A dokumentáció részletesen leírja, hogy melyik mit jelent. Ezek a beállítások függetlenek a lejátszani kívánt zenétől.

music_file = fopen(argv[i+1], "r");
ov_open(music_file, &music, NULL, 0);
music_info = ov_info(&music, -1);

A zenefájl megnyitása ennyi. A zene jellemzői a music_info struktúrába kerülnek. Ezt fogjuk felhasználni, hogy beállítsuk az ALSA-nak a hangjellemzőket.

snd_pcm_hw_params_set_rate_near(playback_handle, hw_params, &music_info->rate, 0);
   snd_pcm_hw_params_set_channels(playback_handle, hw_params, music_info->channels);
   snd_pcm_hw_params_set_period_size_near(playback_handle, hw_params, &frames, &dir);

   snd_pcm_hw_params(playback_handle, hw_params);
   snd_pcm_hw_params_get_period_size(hw_params, &frames, &dir);
   size = frames * 4;
   buffer = (char *)malloc(size);
   snd_pcm_hw_params_get_period_time(hw_params, &music_info->rate, &dir);
   snd_pcm_hw_params_free(hw_params);
   snd_pcm_prepare(playback_handle);
Ez már kellően elrettentő. A lényege röviden, hogy mi nem adhatjuk meg pontosan a paramétereket, mert az egyes hangkártyák esetleg nem ismerik azt a beállítást. Ezért mi csak annyit mondunk, hogy körül-belül ilyen beállításokat akarunk (snd_pcm_hw_params_set_period_size_near), majd a meghajtóprogram kiválasztja azt, ami a legközelebb esik hozzá, amivel mi már beállíthatjuk a kívánt paramétert (snd_pcm_hw_params_set_period_size). Beállítjuk továbbá a hangpuffer jellemzőit is.

A size = frames * 4 sor egy kis magyarázatot igényel. Az ALSA a pufferben két adatot vár, mivel sztereóban játszunk le. De a másik kettő honnan jön? Azt nem tudom. Bármilyen más értékre átírom, a mintavételezés olyan rossz lesz, hogy élvezhetetlenné válik a zene.

sample_length = ov_read(&music, buffer + pcm_index, bytes_needed, 0, 2, 1, &bitstream);
ret = snd_pcm_writei(playback_handle, buffer, frames);

Gyakorlatilag ennyi a további kód. Az ov_read segítségével kiolvassuk a következő puffernyi adatot, majd az snd_pcm_writei-vel lejátszuk.

A teljes kód:

#include <vorbis/vorbisfile.h>
#include <vorbis/codec.h>
#include <alsa/asoundlib.h>
#include <math.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>

/*
   This program is try to play an ogg-vorbis file. This version
   is working with only in 1 bitstream files.
*/

int main(int argc, char *argv[]){
   int i;
   FILE *music_file;
   OggVorbis_File music;
   vorbis_info *music_info;
   snd_pcm_uframes_t frames = 128;
   snd_pcm_sframes_t ret;
   long sample_length;
   char *buffer;
   int size;
   int bitstream;
   int playing = 1;
   int bytes_needed;
   int pcm_index;
   int dir;

   snd_pcm_hw_params_t *hw_params;
   snd_pcm_t *playback_handle;

   for(i = 1; i < argc; i++){
      if(!strcmp(argv[i], "-f")) music_file = fopen(argv[i+1], "r");
   }

   /* Alsa initialization */
   snd_pcm_open(&playback_handle, "default", SND_PCM_STREAM_PLAYBACK, 0);
   snd_pcm_hw_params_malloc(&hw_params);
   snd_pcm_hw_params_any(playback_handle, hw_params);
   snd_pcm_hw_params_set_access(playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED);
   snd_pcm_hw_params_set_format(playback_handle, hw_params, SND_PCM_FORMAT_S16_LE);

   /* Open the music*/
   ov_open(music_file, &music, NULL, 0);

   /* Get the sample rate information from vorbis file */
   music_info = ov_info(&music, -1);

   /* Set the alsa channels and rate */
   snd_pcm_hw_params_set_rate_near(playback_handle, hw_params, &music_info->rate, 0);
   snd_pcm_hw_params_set_channels(playback_handle, hw_params, music_info->channels);
   snd_pcm_hw_params_set_period_size_near(playback_handle, hw_params, &frames, &dir);

   snd_pcm_hw_params(playback_handle, hw_params);
   snd_pcm_hw_params_get_period_size(hw_params, &frames, &dir);
   size = frames * 2;
   buffer = (char *)malloc(size);
   snd_pcm_hw_params_get_period_time(hw_params, &music_info->rate, &dir);
   snd_pcm_hw_params_free(hw_params);
   snd_pcm_prepare(playback_handle);

  
   while( playing ){
      bytes_needed = size;
      pcm_index = 0;

      while(bytes_needed > 0){
         sample_length = ov_read(&music, buffer + pcm_index, bytes_needed, 0, 2, 1, &bitstream);
         switch(sample_length){
            case 0:
               playing = 0;
               bytes_needed = 0;
               break;
            default:
               pcm_index    += sample_length;
               bytes_needed -= sample_length;
         }
      }
      ret = snd_pcm_writei(playback_handle, buffer, frames);
      if(ret < 0){
         ret = snd_pcm_recover(playback_handle, ret, 0);
         printf("Recover\n");
      }
      if(ret < 0){
         printf("Underrun: %s\n", snd_strerror(ret));
      }
   }

   snd_pcm_close(playback_handle);
   ov_clear(&music);
   return(EXIT_SUCCESS);
}

Szólj hozzá!

Címkék: programozás demoscene

Demoscene fájlformátumok

2011.05.18. 23:12 Travis.CG

A demók elkészítése során számos segédeszközt használunk. Az elkészített tartalmakat (zenék, képek, stb) lehetőleg minél kevesebb munkával szeretnénk a demó részévé tenni, ezért a gondosan megválasztott fájlformátumoknak nagy szerepe van. Az intrók esetében ilyen probléma nincs, mert minden tartalmat a program állít elő.

Platform

A demó platformja nagymértékben meghatározza, hogy milyen fájlformátummal tudunk dolgozni. Egy Amigán futó program értelem szerűen nem mp3-ban tárolja a zenét. De PC-n és főleg GNU/Linux rendszerben, ahol a csapat demói készülnek, szintén számítani lehet korlátozásokra. Fedora alatt például alapértelmezetten nincs mp3 codec.

Zene

Mi Ogg/Vorbis formátumban tároljuk a demó hanganyagát. Könnyű hozzá a legelterjedtebb platformokon lejátszó könyvtárat találni. Az SDL_Music például minimális energiabefektetéssel lejátsza. A kezdetek óta használjuk. Valamennyi demónkban Ogg/Vorbis formátumban vannak a zenéink. Egyetlen alkalommal sem okozott problémát a használata, pedig Linux mellett AmigaOS4 és MorphOS alatt is használtam.

Textúrák/Képek

Ez sem nehéz választás. A PNG és JPEG egyaránt elterjedt és népszerű formátum. OpenGL példaprogramok mellett előszeretettel találunk TIFF betöltőket, ezért ha nem akarjuk a képet tömöríteni, akkor ez is egy alkalmazható módszer. Mi PNG-t használunk, mert ebben van alfa csatorna. A libpng-t valamennyi Linux disztribúció tartalmazza. Windows esetén állítólag csak egy DLL kell. Elhiszem. Az összes bitkép szerkesztő program tudja exportálni ebbe a formátumba, de ha mégsem tudna, akkor az ImageMagic ezt is megoldja. (Igen, parancssorban szoktam képeket konvertálni)

3d modellek

Poligon centrikus demók esetén fontos, hogy a különböző térbeli alakzatokat, miután elkészítettük egy modellező program segítségével, szintén minimális energia ráfordítással illeszthessük alkotásunkba. Itt már akadhatnak problémák. Először is, kevés azoknak a fájlformátumoknak a száma, amit a legtöbb modellező program exportálni tud. A másik probléma, hogy az egyes programok ugyanazon formátum különböző dialektusait beszélik. Ezért bármilyen modellt is kapok Grasstól, az első, hogy azonnal tudni akarom, hogy megfelel-e a demó keretrendszere által elvárt formának (ez egyébként valamennyi fájlra igaz).

Így jutottam el a Wavefront OBJ formátumáig. Ez egy szöveges állomány, ezért parancssor segítségével azonnal fel tudom térképezni. Pl:

grep -v "^#" modell.obj | awk '{print $1}' | sort | uniq

Ez a parancs megmondja, hogy mely mezők fordulnak elő a fájlban. A ZBrush például kihagyja a normál vektorokat.

awk '/f/{print NF}' modell.obj | sort | uniq

Ezzel pedig azt ellenőrzöm, hogy minden poligon ugyanannyi csúcspontból áll-e. A Cinema4d ugyanis néha háromnál több csúcsot tartalmazhat.

A másik nagy előnye a szöveges állományoknak, hogy könnyű módosítani őket Perl szkriptekkel. Előfordult ugyanis, hogy az egyik program egy módosítás alkalmával eltolta valamelyik tengely irányába az egész modellt. Mivel én kézzel szoktam pozícionálni a demóban, egy ilyen után meglepődve tapasztaltam, hogy a modell eltűnt. A koordináták gyors ellenőrzése segítségével viszont gyorsan kiderítettem, mi a gond.

Vektorgrafika

Most kellene azt mondanom, hogy SVG. Sajnos nem. Az SVG egy olyan formátum, ami már kétszer is megkeserítette az életemet. Az első demóm alkalmával egy saját vektoros formátumot használtam, de mivel még nem volt grafikus a csapatban, ezért a grafikákat Illustratorban (igen, ez egy Windowsos program) és Karbon14-ben (ez pedig Linuxos) készítettem. Sajnos nem volt elég tapasztalatom egyik program használatában sem, ezért mindkettővel egy részfeladatot végeztem csak el. Abban az időben sokat indítottam újra a gépet.

Ami viszont az újraindításokon túl gondot okozott, az a szabványok támogatásának hiánya. Sajnos az Illustrator, aminek elméletileg kenni-vágnia kellett volna az SVG szabványt, bizony sokszor hibázott. A Karbon14, amit valószínűleg felhasználók visszajelzései nélkül fejlesztettek és fejlesztenek mind a mai napig, viszont remekül boldogult többféle SVG dialektussal is. Ezért, ha véletlenül Karbon14-ből mentett SVG-t akartam betölteni Illustratorba, akkor volt egy kis konvertáló scriptem, ami SVG-t konvertált SVG-be.

Most, így utólag visszaolvasva, nekem is hihetetlennek tűnik, hogy mikre voltam képes. Azt még nem is említettem, hogy az SVG-k csak vonalakat tartalmaztak, egyetlen színnel. Bele sem merek gondolni, hogy mi történt volna, ha bonyolultabb alakzatokat használok.

Sajnos az SVG-től nem sikerült megszabadulnom. Az Etch-a-sketch című demónknál is kísértett szelleme. Itt is saját formátumba készítettük a vektorgrafikát. Okulva a korábbi kudarcból, készítettem egy szerkesztő programot, ami rögtön saját formátumba mentett. Legalábbis ez volt az elmélet. A gyakorlat az volt, hogy sok időt felemésztett a szerkesztő program kifejlesztése, ami nálam működött, Grassnál nem. Közeledett a party, de én ahelyett, hogy a demót programoztam volna, a szerkesztő bugjait javítottam. Grass közben nem tudott dolgozni, az idő meg telt.

Ekkor nagy levegőt vettem és azt mondta, használjunk SVG-t. Két kikötésem volt: Csak vonalat tartalmazhatott és csak egy általa választott program egy bizonyos verziójában készülhetett. Azt gondoltam a konvertáló szkript ennyivel meg fog birkózni.

Mondanom sem kell, hogy egyiket sem sikerült betartani. Szerencsére ezeket idejében észrevettem. A demó pedig elkészült.

Tanulság

A saját formátumoknak megvan az az előnyük, hogy mi tartjuk kézben, viszont több munkát ró a programozóra, akinek el kell készíteni az eszközöket, konvertáló programokat hozzá. A másik lehetőség, hogy standard fájlformátumokat használunk, de itt elképzelhetőek apró módosulások a szabványhoz képest. Ha nem elég robosztus a demó keretrendszere, hogy felismerje a formátum dialektusait, akkor célszerű csak egy program egy adott verzióját használni, és a demót ahhoz igazítani.

Szólj hozzá!

Címkék: programozás demoscene

Exome variációk kinyerése

2011.05.13. 11:17 Travis.CG

Az 1000Genome projekt elérhetővé tett nagy mennyiségű exome szekvenálásból származó adatot. Ezek egy VCF 4.0 típusú fájlban találhatóak meg egy ftp szerveren. Nincs is sok probléma vele, mindössze annyi, hogy tömörítve 61GB. Felhő ide-kimeríthetetlen tárhely oda, ez igen nagy mennyiségű adat, nem sok kedvem volt letölteni, kicsomagolni, majd kinyerni a nekem kellő rekordokat. Szerettem volna valami elegáns megoldást.

Először elkezdtem letölteni, majd egy tetszőleges időpontban megállítottam a letöltést és a zcat segítségével kinyertem az első pár ezer sort. A letöltött állomány darabka 296MB volt, kicsomagolás után csekély 2,3 GB-ra hízott. Tehát 500GB elég lenne a tömörítetlen adatoknak, amelyeknek nagy részére nem is voltam kíváncsi.

Szerencsére a VCFTools rendelkezésre bocsájt egy csomó eszközt, amivel szűrni lehet a VCF fájlokat. Már csak azt kellett megoldani, hogy ez a szűrés letöltés közben valósuljon meg. Mivel GNU/Linux alatt dolgozom, ez nem is olyan nehéz feladat, mint azt elsőre gontoltam.

A letöltést wget-el végzem. Annak a -O - kapcsolóval megadható, hogy a szabványos kimementnek adja át az állományt. A rendszerüzeneteket kikapcsoltam a -q kapcsolóval. Ezután a zcat kicsomagolja az állományt, majd a vcf-subset parancs elvégzi a szűrést. A -c kapcsolóval megadható neki egy fájl, ami a nekünk szükséges sorokat tartalmazza. Összegezve:

wget -O - -q  'ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/release/20100804/ALL.2of4intersection.20100804.genotypes.vcf.gz' | zcat | ./vcf-subset -c oszlopok. >eredmeny.vcf

Szólj hozzá!

Címkék: bioinformatika

BFast futtatás

2011.05.04. 11:08 Travis.CG

A BFast egy rendkívül jó kis short read illesztő program. Indexeli a referencia szekvenciát, amitől sebessége elég gyors lesz. Seed technikát alkalmaz, aminek az a lényege, hogy egy 0-ból és 1-ből állo sorozattal megadhatjuk, hogy mely bázisokat hasonlítsa össze és melyeket ne. Volt néhány nem egyértelmű utalás a dokumentációban, amit szeretnék világossá tenni.

Az indexelés 1-től indul

A referencia indexelésénél több seedet is felhasználhatunk, amit indexekkel különböztetünk meg. Ez az index 1-től indul, és nem 0-tól, ahogy egy C programozó várná :-)

A readek FASTQ-ba legyenek

A program FASTQ formátumban olvassa be az adatokat. Ha nem így kapja, segmentation faulttal elszáll. Szerencsére van konvertáló program (solid2fastq), ami még azt a szívességet is megteszi nekünk, hogy szétdarabolja a readeket. Erre akkor lehet szükség, ha nincs elég memóriánk. Amennyiben nem daraboljuk szét a readeket, akkor is megadhatunk intervallumot az -s és -e kapcsolókkal.

Read méret

BFast nem ad optimális eredményt, ha a read mérete kisebb 30 bázispárnál. Ettől függetlenül használható ebben az esetben is, a szerző szerint.

Legyen nukleotid referencia is

Ha color space adatokat dologzunk is fel, a lokális illesztéshez (bfast local) szükség van a nukleotid referenciára is. Ennek segítségével kapjuk meg SAM fájlunkat nukleotidok formájában.

Figyeljünk a kimenetre

A BFast eredményül egy SAM fájlt ad. Ebben megtalálhatóak az illesztett és nem illesztett readek egyaránt. Ez okozhat problémát olyan segédprogramok esetén, mint a Picard SamSort programja, ami ezekkel a readekkel nem tud mit kezdeni, mert nincs pozíciójuk. A nem illesztett rekordokat két módszerrel is kiszűrhetjük: A második oszlop 4. bitje ha be van kapcsolva, akkor a read nem illesztett. A gyakorlatban ez azt jelenti, hogy ha 4 és 20-t találunk, akkor kiszűrhetjük. A másik, vitatható, de jóval gyorsabb módszer, ha a referencia neve helyett (3. oszlop) * karakter van, akkor nem illesztett a read.
 

Szólj hozzá!

Címkék: bioinformatika

Bioscope folyamatok futtatása

2011.04.19. 15:52 Travis.CG

Korábban azt írtam, hogy csak egy bonyolult script segítségével tudtam több folyamatot egymás után futtatni. Ez a script folyamatosan cserélgette az .ini fájlokat.

Szerencsére van más módszer is, amivel parancssorban egy folyamatot tudunk összeállítani a Bioscope részére.

Létre kell hozni egy .plan kiterjesztésű állományt. Ez tartalmazza a folyamat egyes elemeit. Az elemek pedig a futtatni kívánt programok ini állományai. Tehát ha egy szekvenálás eredményét először illesztjük a referenciához, majd .bam állománnyá konvertáljuk, akkor a következő sorok szerepelhetnek a .plan állományban:

mapping.ini

matobam.ini

Létre kell hozni a két ini állományt, és a dokumentáció szerint kitölteni a paraméterekkel. Csakhogy, nincs lehetőség ciklusok és változók használatára. Tehát ha van nyolc szekvenálásunk, akkor nyolc ini fájlt kell létrehozni, még akkor is, ha csak egy sor eltérés van bennük.

Trükként lehet használni a global kulcsszót az ini fájlok elején. Ennek célja, hogy bizonyos változókat kiemeljen, amelyek több ini állományban is ugyan olyan értéket vesznek fel.

Amint készen van a .plan fájlunk, nem kell mást tenni, mint elindítani a bioscope-t:

bioscope.sh -l logfile sajat.plan

Szólj hozzá!

Címkék: bioinformatika

LaTeX hackelések

2011.04.18. 11:31 Travis.CG

Egy Microsoft központú világban nem használni Office terméket ( beleértve az ingyenes klónokat is) eretnekség. A diplomadolgozat elkészítése után váltam eretnekké, ahol annyi problémával szembesültem, hogy úgy döntöttem mellőzöm ezeket a programokat az életemből.

A dokumentációkat ettől a pillanattól kezdve LaTeX-ban készítettem, mit sem törődve a főnökök siránkozásával, hogy nem tudják szerkeszteni az általam átküldött anyagokat. Nem vagyok nagy felhasználó, de még az én szintemen is sokkal könnyebben boldogultam vele, mint annak idején a klikkelős szöveg formázó rendszerekkel.

Mikor eljött a doktori dolgozat elkészítésének ideje, nem volt kérdéses számomra, hogy LaTeX-ben fog készülni. A döntésem helyes volta rendszeresen visszaköszönt, ahogy láttam mások mennyi szenvedés árán csinálják dolgozatukat. Persze az így elkészült dolgozatról már messziről látszott, hogy ez valami eretnek termék. A betűk szépek, nincsenek hullámvonalas hosszú ő és ű-k, az oldalak elrendezése esztétikus, és a referenciák teljesen egységes felépítést mutatnak. Ez pedig csak valami gonosz műve lehet.

Rögtön bele is kötöttek házi védésnél, hogy a referenciák a műszaki tudományoknál megszokott módon vannak formázva. Ennek kijavítása rendkívül egyszerű volt. Betöltöttem a natbib csomagot, és az összes \cite parancsot \citep-re cseréltem. Mivel Linux alatt dolgoztam, ez egy sed paranccsal megoldható. Csakhogy, a \citep-nél a szerzők neve között "and" szerepelt "és" helyett. Hirtelen nem találtam rá semmilyen megoldást. Mások is szenvedtek hasonló problémákkal. Egy oldalon pedig olyan bonyolult tex megoldás szerepelt, hogy nem értettem belőle semmit.

Az idő fogyott, nekem pedig nem volt megoldásom rá. A hívők kajánul mosolyogtak nyomoromon, hogy bezzeg a Wordben bármilyen szót ki lehet cserélni, bármikor. LaTeX-ben nem. A LaTeX sok kis szövegfájlból állítja elő DVI v. PDF kimenetet, ami már nem szerkeszthető egyszerű módon. Tehát nekiálltam megkeresni azt a szövegfájlt, ami a problémát okozza. A gondot a bibtex/bst/natbib könyvtár stílusfájljai okozták. Ezekbe bele van égetve az "and" kulcsszó a format.names, format.full.names, format.lab.names függvényekbe. Tehát ezeket kell csak kicserélni és máris mindenhol magyarul jelenik meg az elválasztás. Mindenhol? Igen. Még az irodalomjegyzékben is. Ez viszont nem jó. Ha a format.names-t visszaírjuk, akkor már jó lesz. Csúnya hack, de működik.

A másik problémám a szekeszthetőség volt. Ezt a LaTeX2rtf programmal oldottam meg. Ennek viszont volt egy komoly problémája. Én ugynis UTF8-ban készítettem a dokumentumot, a program viszont csak Latin1-t volt képes kezelni, sok formázást nem volt képes maga elvégezni, ezért a következőképp kell használni:

  1. LaTeX-el hozzuk létre a dokumentumot. A folyamat során létrejönnek az átmeneti állományok.
  2. iconv segítségével alakítsuk át a programok kódolását. Én az alábbi kis scripttel oldottam meg: for i in *; do iconv -f UTF8 -t Windows-1251 $i >tmp; mv tmp $i; done
  3. Futtassuk a LaTeX2rtf programot. Ha szerencsénk van, csak a hosszú ő és ű lesz ronda. Egyéb karakterkódolással lehet kísérletezni. A teljes fordítás soha nem lesz tökéletes.

Nekem a táblázat hivatkozások, fejezet címek (chapter fejezet helyett) soha nem jelentek meg tökéletesen. De az RTF úgysem publikálásra készül, hanem arra, hogy belejavítsanak, tehát sok időt nem szabad vele foglalkozni.

Egy majd hetven oldalas dokumentumnál összesen két probléma. Ez töredéke annak, ami egy Word dokumentumnál fellép. A nyomtatás pedig PDF-ből gyerekjáték, míg Word esetén katasztrófa, ha egy másik gépre kell átvinni. Megéri eretneknek lenni.

Szólj hozzá!

Címkék: biztonság életmód

Szakmák, amikhez mindenki ért: Külcsin

2011.04.14. 14:41 Travis.CG

Ez a szakma elég megfoghatatlan számomra. Először is, mert véleményem szerint nem lehet tanulni. Ha lehetne, akkor már rég megtanultam volna és Grasst, a csapat grafikusát kirúgtam volna :-) Kétségtelen, hogy fejlesztető, de kell hozzá valami megfoghatatlan érzék, ami nekem nincs meg.

Másokban sincs meg, de őket ez nem tántorítja el, hogy meghatározzák a formáját teszem azt egy weboldalnak.

Történt ugyanis, hogy elvállaltam egy weboldal elkészítését, ráadásul teljesen ingyen, mert a szegény szervezetnek nincs pénze, nekem meg számlám, amit adhatnék. Azt viszont kikötöttem, hogy a külalakot, színeket, arányokat nem fogom megmondani, ahhoz szerezzenek egy grafikust. Én ugyanis olyan vagyok, mint a Commodore 64, csak 16 színt ismerek.

Viszont különböző furmányos okok miatt nem sikerült grafikust találni. Ekkor megkérdeztem Grasst, van-e kedve beszállni a jótékonykodási akcióba. Volt neki. Már ismerem annyira, hogy tudjam, mit szeret és mit nem, ezért elmondtam a megbízóimnak, hogy ő csak azzal a feltétellel hajlandó dolgozni, ha nem szólnak bele, hogy mit hogyan csináljon: Ő a szakember. Ebbe a feltételbe bele is mentek.

Grass elkészítette a látványtervet, ami meg kell mondjam, nagyon jól sikerült. A megbízók szerint nem. Válaszul küldtek egy színmintát (5 színből), amiből Grass válogathatott kedvére.

Más grafikusok is hasonló esetekről mesélnek. Például egy játékiparban dolgozó ismerősöm mondta, hogy a főnöke neki is rendre beleszól a látványtervekbe. Olyan szinten, hogy rámutat egy elemre az összképen és kijelenti, hogy az legyen kék. Ettől felborul a színegyensúly, nem fognak harmonizálni az árnyalatok, a kép szétesik.

Tehát egy grafikusnak nem az a szerepe, hogy megtervezzen valamit, hanem gondolatolvasóként kitalálja, hogy mit akar az ügyfél. A gondolatolvasás pedig nagyon rosszul működik. Néha még akkor is, ha hangosan kimondjuk őket.

Ha pedig ennyire markáns véleménye van a megrendelőnek, miért nem csinálja meg ő? Szerintem azért nem, mert nincs halvány elképzelése sem arról, mit is akar. Még akkor sincs, ha azt mondja, hogy van. Például a cég, ahol dolgozom, kiment egy konferenciára. Vittek "white paper"-t, "pop-up wall"-t és egyéb marketing szempontból lényeges dolgokat, amiknek nincs normális magyar nevük, vagy ha van is, inkább nem használják. Ezeknek a tartalmaknak a kreatív voltát egyetlen szóval fogalmazhatom meg: Stockphoto. Innen összevásárolva lett egy csomó nagyszerű fotójuk, csak éppen az ötlet hiányzott, hogy mihez is kellene felhasználni. Végül mégsem használták a képeket, mert kiderült, hogy a többi kiállító is a kreativitás eme kútjából merít.

Lelki szemeim előtt látom is, amint egy hatalmas csarnokban megelevenedik a Stockphoto egy kulcsszavának első találati oldala.

Bizony, nehéz eldönteni, hogy mi néz ki jól. Azt kitalálni, hogy másnak mi néz ki jól, pedig még nehezebb. Egy weboldalnál pedig ez a cél. A többi embernek legyen szép. A nézőknek, hogy szívesen visszajárjanak.

Egy korábbi munkahelyemen ezért cseréltük le a weboldalt. Az első verzió olyan volt, ami nekünk, a dolgozóknak tetszett. Fekete háttér, nagy kontrasztú színekkel. Csináltunk egy rövid felmérést, mire kiderült, hogy az oldal látogatóinak bizony nem tetszett. Ezért lecseréltük szép világosra.

Szólj hozzá!

Címkék: filozofálás

Framebuffer és Textúra

2011.03.29. 18:27 Travis.CG

Korábban bemutattam, hogyan lehet egy OpenGL keretrendszert létrehozni X11 alatt. Most röviden bemutatom, hogyan használom a Framebuffert, hogy ne csak a képernyőre rajzoljak. Miért lehet szükség arra, hogy ne a képernyőre rajzoljunk, hanem a memóriába? Először is, azért, mert további műveleteket végezhetünk a memóriában tárolt képen, mielőtt a nézők szeme elé tárulna a látvány.

Az egyik ilyen művelet az élsimítás, de a deferred rendering nevű eljárás is ezen alapul. Hosszú távon nekem ez utóbbi a célom. Amint elég tapasztalatom lesz a témával kapcsolatban, arról is írok egy bejegyzést. A környezet továbbra is OpenGL 4.1

Inicializálás

Az első lépés, hogy hozzuk létre saját framebufferünket a glGenFramebuffers segítségével. Nagyon hasonló, mint amit textúránál is csinálunk. Rögtön utána kössük is magunkhoz a glBindFramebuffer segítségével. Az első paraméter általában GL_FRAMEBUFFER lesz. Akár mit is akarunk kezdeni a framebufferünkkel, egészen biztos, hogy szükségünk lesz egy mélységi pufferre. Ha ezt nem hozzuk létre, a takarásban lévő és látható pixelek összekeverednek és nagyon ronda eredményt adnak. Tehát kell egy mélységi puffer.

A glGenRenderbuffers hasonlóan működik, mint a glGenFramebuffers. Ezt is kössük (glBindRenderbuffer), majd meghatározzuk a méretét. a glRenderbufferStorage-val. Az első paraméter a két utolsó függvénynél GL_RENDERBUFFER lesz. Más nem is lehet. Mivel mélységi puffert akarunk, ezért a glRenderbufferStorage második paramétere GL_DEPTH_COMPONENT lesz.

glGenRenderbuffers(1, &rb);
glBindRenderbuffer(GL_RENDERBUFFER, rb);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, szelesseg, magassag);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, rb);

Az utolsó lépésben a frissen keletkezett pufferünket hozzárendeljük a framebufferhez. A gyakorlatban csak a második és utolsó paramétert szokták változtatni, ha esetleg más komponenshez is puffert rendelnek. Más komponenshez? Igen! Lehetőségünk van több szín, mélység és stencil pufferbe tárolni információt. A színpufferek száma implementáció függő, a GL_MAX_COLOR_ATTACHMENTS ad róla információt.

Bár minden fórumon és blogban azt olvastam, hogy ahol csak lehet, használjunk renderbuffereket, véleményem szerint a mélységi komponens kivételével (sőt, deferred shading esetén ott sem) ne használjunk renderbuffert. Mégpedig azért ne, mert az ott tárolt információt csak arra használhatjuk, hogy kitegyük a képernyőre. Márpedig egy demóban még sokat kell játszani a képpel, hogy azt ki merjük rakni a képernyőre. De akkor hogy lehet utólagos effekteket rárakni a tárolt pufferre? A renderbuffer mellett van egy másik lehetőségünk. Textúrát is köthetünk a framebufferhez! A textúra pedig könnyedén bemenete lehet egy shadernek, amivel már megbolondíthatjuk a képet. Ezért gondolom úgy, hogy nem érdemes renderbufferekkel foglalkozni.

Textúrák hozzákötése kísértetiesen hasonlít a renderbufferek kötéséhez:

glGenTextures(1, &t);
glBindTexture(GL_TEXTURE_2D, t);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, szelesseg, magassag, 0, GL_RGBA, GL_UNSGINED_BYTE, NULL);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, t, 0);

Természetesen a textúrák esetén még nagyon sok paramétert be lehet állítani, de azokat kihagytam, mert tele velük az internet. Amire itt felhívnám a figyelmet, az a GL_COLOR_ATTACHMENT0. Ez azt mondja meg, hogy a számtalan színpuffer körül mi az elsőt kötjük össze a megadott textúrával. Ennyi.

Használat

Amennyiben használni szeretnénk pufferünket, tegyük a következőt:

glUseProgram(puffershader);
glBindFramebuffer(fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
...rajzoló rutinok...

Természetesen a képernyőn nagy feketeség fog megjelenni. Régen, mikor még nem voltak pufferjeink, akkor is tudtunk textúrába renderelni, majd négyszöget rajzoltunk, ami lefedte a képernyőt és ráhúztuk a textúrát. Ennek vége. (Igazából nem. Sok esetben még mindig egyszerűbb így rajzolni) A pufferünket egy lépésben (pontosabban három, ha az utasítások számát nézzük) a képernyőre rakhatjuk a glBlitFramebuffer segítségével.

glBindFramebuffer(GL_READ_FRAMEBUFFER, fb);
glBindFramebuffer(GL_WRITE_FRAMEBUFFER, 0);
glBlitFramebuffer(0, 0, szelesseg, magassag, 0, 0, szelesseg, magassag, GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT, GL_LINEAR);

Mint a paraméterekből kikövetkeztethető, nem muszáj a teljes képernyőt kitölteni. Ez érdekes effekt ötleteket adhat az embernek. A 0 jelű framebuffert tartja fenn a rendszer a képernyőn megjelenő képnek. Lehet több framebufferünk is, a fenti megoldással tetszőleges két framebuffer között tudunk másolni.

Szólj hozzá!

Címkék: programozás demoscene

A szerencse gyermeke

2011.03.22. 22:16 Travis.CG

Ma felhívott egy ismeretlen szám, hogy nyertem valami mobil cég és egy bank közös nyereményjátékán. Közjegyző előtt kisorsoltak és nyertem 250 ezer forintot.

- Nagyszerű - mondtam.

- Nem hallom a hangjában az örömöt.

Nem csoda, hogy nem hallotta, hiszen teljesen nyugodt voltam. Miért is kellett volna meglepődnöm ezen? Én a szerencse gyermeke vagyok. Csupa váratlan áldás szokott rám hullani. Múlt hónapban egy, az olvasók emésztésével foglalkozó lap (angol néven, hogy ne vegye el az étvágyat) nyereményjátékán nyertem, vagy legalábbis elég közel voltam a nyereményhez. Csak vissza kellett küldeni egy válaszborítékot, amiben nyerési dokumentumokat, gyorsaság bónusz kártyát és valami kaparós jegyet kellett beletenni. Ez utóbbi egy autó kódját tartalmazta, amiből teljesen véletlenül pont a sportkocsit nyertem.

A szerencse mindenhova elkísér. Egy átlagos weboldalt sem tudok úgy megtekinteni, hogy ne én legyek a 10ezredik látogató. A levelezésemben naponta átlagosan 3 nyereményről tájékoztató levél van. Annyit nyertem már, hogy a spam szűrő is nehezen bírkózik meg ezzel az áradattal.

Miért kellene meglepődnöm? Meg is mondtam neki, hogy én nagyon sokat nyertem már az interneten, ezért nem lepődök meg.

- Úgy érzem, ön szkeptikus.

Bámulatos volt a figura. Megint rátapintott a lényegre. Nem is tehettem mást, mint egyetértettem vele. Ezután letegezett, felszólított, hogy végezzek el egy jóga gyakorlatot, amiben a szám és az intim szférám is érintett volt, majd lecsapta, Úgy látszik a pénzkeresés is olyan tevékenység, amit nem csinálnak meg helyettünk. Lehet, hogy mégsem vagyok szerencsés?

Szólj hozzá!

Címkék: biztonság életmód

Bioscope 1.3

2011.03.19. 15:05 Travis.CG

A "nyílt forráskódú" bioscope verzió után megnéztem a kereskedelmi verziót is. Ezt elsősorban elosztott rendszereken lehet használni, webes felületen. Van lehetőség parancssoros futtatásra is, ami némiképp idegen lehet attól, aki rendszeresen futtat GNU/Linux alól parancssoros programokat.

A program nagy előnye, hogy szemben más alkalmazásokkal, itt az egyes programokat "összefűzhetjük" és kötegelt elemzéseket csinálhatunk anélkül, hogy összetett paranscsori szkripteket írnánk és a különböző formátumok között konvertálnánk. A webes környezet használatára nem térek ki, mert az amolyan klikkelj és futtass filozófiát követ.

Parancssorban teljesen más a helyzet. A rendszer rendelkezésünre bocsát egy demos könyvtárat, amiben az összes műveleti lépés készen várja, hogy elindítsuk. Az egyes paramétereket .ini fájlokon keresztül lehet beállítani, mint Windows 3.1 alatt. Igyekeztek mindent úgy elkészíteni, hogy a lehető legkevesebb erőforrás segítségével lehessen használni a programot. Az ini fájlok testreszabása után csak egy ./run.sh parancsot kell kiadni és az elemzés elindul.

Sajnos pont ezzel sikerült megfosztani a felhasználót a folyamatok összefűzésének lehetőségétől. Nagyon elszánt felhasználók talán átnézhetnék a run.sh parancsfájlt, aminek felépítéséről nincs semmi sem a dokumentációban. Sajnos nem volt annyi időm, hogy ezt megtegyem, ezért én úgy fűztem össze a programokat, hogy egy .ini állomány másoló programot készítettem. Nem a legjobb választás, de célnak megfelelt.

A Bioscope programjait továbbra is gyengének találom. Ezt valószínűleg a készítők is érezhetik, mivel például a readek referenciára illesztésére inkább a BFast-ot ajánlják, mint saját fejlesztésű programjukat.

Az egyetlen előnye a Bioscope-nak, hogy elfedi a felhasználó elöl az elosztott gépek indításával és leállításával, az adatok mozgatásával járó bonyodalmakat.  A végpontokról gyakorlatilag semmilyen információt nem kellett tudnom, mikor futtattam a programokat. Ez mindenképp pozitívum. Sajnos a telepítés nehézségeiről nincsenek információim, tehát nem tudom, hogy mennyivel nehezebb, mint ha valaki Condort, Oracle Grid Engine-t vagy Hadoopot használna.

Szólj hozzá!

Címkék: bioinformatika

A mérkőzés

2011.03.09. 10:20 Travis.CG

Jó estét, jó szurkolást. Mai félnehéz súlyú mérkőzésünkön két igazi nagyágyú méri össze tudását. A tét nem kevesebb, mint a CLCBio Genomics Workbench elindítása. A mérkőzés helyszínét az Amazon biztosítja. Az idő szokás szerint felhős.

A kék sarokban a címvédő Windows Server 2008. Régi játékos már, számtalan apró fogást ismer, amivel nem egy kiváló játékost küldött padlóra. A piros sarokban a kihívó, Travis. Nem sokat tudunk erről az új játékosról. Korábbi meccsein szívós és kitartó volt. Majd meglátjuk, hogy a sok Linuxos meccs után mit kezd egy számára ismeretlen ellenféllel. Google edző a ringen kívül figyeli a mérkőzést.

Megszólal a gong, a játékosok a ring közepén vannak! Óvatosan kerülgetik egymást. Windows arcáról semmit nem lehet leolvasni. Travis RDesktoppal kapcsolódik, Windows beengedi, de semmi komoly nem történik. Travis kezdeményez, megnyitja a böngészőt. Internet Explorer feljön. Windows arcán halvány mosoly fut át, mint aki számított erre a lépésre. Travis megpróbálja letölteni a Workbench-et! Merész lépés volt egy kezdőtől. De nem fut a JavaScript! A letöltés meghiúsult! Ügyesen védett Windows. Még sok meglepetést fog tartogatni nekünk ez a mérkőzés, biztos vagyok benne! Travis rezignáltan veszi tudomásul. Az oldal forráskódjából kiszedi a kívánt címet, és már meg is kezdi a program letöltését. Pontosabban kezdené, mert Windows megtiltja a futtatható állományok letöltését!

Travis fogást keres ellenfelén. Vezérlőpult, Internet beállítások körül forgolódik az egérrel. Igen, jó helyen keresgél. Engedélyezi a letöltést. Windows néhány popup ablakkal vág vissza, de mindez csak elterelés. A letöltés ezután sem megy. Még zöldfülü ez a fiú!. De nem, az UAC háza táján turkál. Igen, igen. Micsoda jobb horog! Az UAC kikapcsolva. Windows láthatóan megtántorodik. A bíró közbelép és újraindítást rendel el. Windows úgy támolyog a sarokba. Travis magabiztosan mosolyog.

Második menet.

A második menetben Travis magabiztosan kezd. Ismét megkezdi a letöltést. Nem veszi észre, hogy a kikapcsolt UAC ellenére a JavaScript továbbra sem aktív a böngészőjében. Ez nagy hiba, csak a győzelmét látja, az intő jeleket nem. Letöltés, és UAC ide-vagy oda, az továbbra sem megy. Travis kezdi elveszíteni a türelmét, ami szintén arra utal, hogy tapasztalatlan játékos. Ismét az Internet beállítások körül ólálkodik. Mindent engedélyez, amin piros jel van és biztonsági problémára figyelmeztet. Nem gondolkodik, csak klikkel. Második hiba a mérkőzés során! Miután bezárja a Vezérlőpultot, váratlanul újra megnyitja. Már kezdi kapisgálni, úgy látom. Windows az első menetben hátrányba került, de most mosolyog. Igen, van is rá oka. A változtatások ellenére a Vezérlőpulton, mintha nem is állítottak volna át semmit. Travis sem érti. Leengedi a karját, mire Windows hatalmasat üt állcsúcsára. Travis elveszti egyensúlyát. A bíró közbelép. Hármat számol, de Travis feláll, készen, hogy folytassa a mérkőzést. A gong ismételten egy menet végét jelzi. Travis a sarokba tántorog. Google edző folyamatosan súg neki, bárcsak hallanánk, hogy mit!

Harmadik menet

Travis sokkal nyugodtabb. Ha most látnánk először, még azt is hihetnénk, hogy profi játékos. Ismét az internet beállítások felől támad. Most alapértelmezetté teszi a változtatásokat és nem csak az alapértelmezett profilban, hanem mindenhol. Nem elegáns, nagyon nem elegáns. Olyan, mintha már személyes ügy lenne. Már nem a győzelem a cél, hanem az ellenfél szétzilálása. Windows erőtlenül figyelmeztető üzeneteket küld, de ezeknek már nincs semmi hatása. Windows hátrál, mintha nem tudna mit kezdeni ennyi támadással. Travis letölti a CLCBio bővítményét, és sikeresen beilleszti a Workbenchbe. Újraindítja azt. És most jön Windows ellencsapása! A bővítményt a neten keresztül kellene hitelesíteni, de mivel Travis távoli asztalról jelentkezett be, ezért Windows ezt egy hibaüzenettel meggátolja. Bumm! Travis a padlón.

Most értette meg, hogy nincs esélye a győzelemre. Amazon ringben csak távolról lehet bejelentkezni. A hitelesítési problémáról pedig a CLC is tud, ezért nem is támogatják a Windows Server semmilyen verzióját! Minden lépés csak trükk volt Windows részéről, hiszen biztos volt, hogy ő győz. Mégis játszotta a sérült, beteg, gyenge ellenfelet. Ezt nevezem én versenyrutinnak! Most a boldogan sétál a ringben és ünnepelteti magát a tömeggel. De mi ez? Travis felkel. A bíró közbe akar lépni, de ellökik! Travis terminálja a virtuális gépet! Windows eltűnik, mint egy szappanbuborék. A közönség elhülve figyeli a sportszerűtlen magatartást. A szövetség biztosan eltiltja ezt a fiút a további Windows mérkőzéstől. Travis, mintha nem is bánná...

Szólj hozzá!

Címkék: biztonság cloud computing

Képregény

2011.03.02. 14:36 Travis.CG

Véletlenül akardtam rá a PHDComics-ra, de azonnal rákaptam. Sejtettem már Asimov regényéből is, hogy a PhD hallgatók élete a föld különböző pontjain annyira nem is különböznek egymástól. Így egyben olvasni és nevetni rajta egyszerűen felemelő érzés.

Rögtön eszembe jutottak a rég elfeledett problémák, melyek akkor a világot jelentették és szembesültem azokkal a problémák, melyeket most élek át. Ajánlom mindenkinek.

Szólj hozzá!

Címkék: életmód

OpenGL apróságok

2011.02.26. 21:45 Travis.CG

A legújabb demónknál elhatároztam, hogy OpenGL 4.1-t fogok használni. Az interneten fellelhető dokumentációk jelentős része még a régebbi verziószámú rendszerre érhető el, ezért előfordul, hogy értetlenül nézek a képernyőre és nem értem, miért nem jelenik meg semmi.

Most, hogy a korábbi módszerek helyett minden shaderből megy, egyrészt jó, mert megadja azt a szabadságot, amit elvárhatok a rendszertől, másrészt elvesz néhány kényelmi szolgáltatást. Értem ez alatt a glRotate (forgatás) és glTranslate (eltolás) függvényeket. Mivel nem erős oldalam a matematika, ezek elvesztése fájt.

A három dimenziós alakzatokat puffereken keresztül lehet megadni, ahol később mi magunk mondjuk meg, hogy az adott puffer milyen szerepet töltsön be. Tehát vázlatosan valami ilyesmi kódot lát az ember:

glGenBuffer...
glBindBuffer...
glBufferData...

Ezzel nem is volt különösebb problémám. Megadunk egy puffert az alakzatunk csúcspontjának, a normálvektor irányának és a textúrák koordinátájának. Ezt szépen össze lehet fogni olyan függvényekbe, mint loadMesh() és utána minden demóban lehet használni. Ahol nekem most problémám akadt, mindezt hogyan mondjuk meg a shaderünknek?

A dokumentáció és a példaalkalmazások alapján előttem két út rajzolódott ki:

  1. A shader linkelése előtt explicit megadjuk, hogy hányadik puffer melyik shader változónak felel meg, a glBindAttribLocation() függvény segítségével.
  2. Linkelés után lekérdezzük a shader változó azonosítóját (glGetAttribLocation), majd hozzákapcsoljuk a megfelelő puffert (glBindBuffer, glVertexAttribPointer, glEnableVertexAttribArray).

Az első megoldás kényelmes, de én egy általános shader betöltőt akartam írni, ami nem foglalkozik azzal, hogy milyen változók vannak a shaderben és azoknak mi a szerepe. Csak betölti a shadert valami loadShader() függvénnyel, ami egyedül a fájl nevét kapja meg. Megjegyzem, még ebben az esetben is lehet használni az első módszert, de a glBindAttribLocation() meghívása után ki kell adni egy glLinkProgram() utasítást is. Tehát valami ilyesmi kódunk lesz:

shaderprg = loadShader("winnershader.vert", "winnershader.frag"); // van benne glLinkProgram
glBindAttribLocation(shaerprg, 0, "coolvariable");
glLinkProgram(shaderprg);

Ez viszont nem tetszik. Miért hívjak meg többször egy függvényt? A második módszer jobban tetszett. Meg is írtam a rutint. És nem működött. Ez azért is érdekes, mert Norbert Nopper kollégának működött. Már kezdtem azt hinni, hogy kénytelen leszek a béna első módszert használni, amikor Nopper programját tüzetesen megvizsgálva észrevettem a megoldást. Nevezetesen ki kell adni a glBindVertexArray-t is. Utólag belegondolva logikus is, hiszen több VertexArray-el is dolgozhatunk.

A módosítás hatására a program az elvárt végeredményt mutatta.

Ugyancsak fontos, hogy megfelelő időben aktiváljuk shader programunkat. A glUseProgram mindig előzze meg a glGetUniformLocation és glUniform parancsokat, különben GL_IVALID_OPERATION hibaüzenetet kapunk, amit nehéz felderíteni.

Szólj hozzá!

Címkék: programozás demoscene opengl

Bölcsességek

2011.02.23. 11:47 Travis.CG

Néhány bölcsesség:

  • Ne bízz abban a bioinformatikusban, aki nem tudja mennyi memória van a gépében.
  • A bioinformatikus legnagyobb ellensége a Word fájlban átadott szekvencia.
  • Kerüld azt a programozót, aki kiadványszerkesztőben ír programot és kézzel színezi a kulcsszavakat.
  • Hamar cikkírás ritkán impaktos.
  • Vigyázz azzal a bioinformatikussal, aki Windowst használ! Vagy kókler (nem tud Linuxot használni), vagy nagyon profi (úgy használja a Windowst, mint más a Linuxot)
  • Soha ne sértegess Machintosos bioinformatikust.
  • A jó bioinformatikus nem tudja, mi az Excel fájl.
  • Ha a jó bioinformatikus tudja is, mi az Excel fájl, soha nem fog neked készíteni egyet sem.
  • A PowerPoint nem poszter készítő program.
  • A Word nem képszerkesztő.
  • A Word nem honlap készítő.
  • Az Excel nem adatbázis.
  • A rossz bioinformatikus minden feladatra legalább két programot használ.
  • A még rosszabb bioinformatikus az összes feladatra egy programot használ.
  • Aki még ennél is rosszabb, az mindenre Microsoft Office programokat használ.
  • Ne taníts olyan bioinformatikust, aki ezt kérdezi: "Ez a kódolás, ez muszály?"
  • Ha sok statisztikai tesztet futtatsz, mindig használj többszörös teszt korrekciót.
  • Ha azt kérik, hogy ne használj többszörös teszt korrekciót (mert nincs elég szignifikáns eredmény), akkor is használd.
  • A főnök sürgetése nem lehet indok az új módszerek meg nem ismerésére.
  • Ha tudod, hogy rossz a bemeneti adat, akkor is bizonyítsd. Több a meló vele, de könnyebben elfogadják.
  • Ne félj hibázni. A hibától való félelem csak paralizál, míg a hibából tanulhatsz.

A listát frissíteni fogom.

Szólj hozzá!

Címkék: filozofálás bioinformatika

CUDA (5. rész)

2011.02.21. 12:11 Travis.CG

Elérkeztünk az utolsó részhez. Több gyakorlatot nem terveztem, de lesznek még CUDA-val kapcsolatos bejegyzések. Elég a bevezetőből, vágjunk bele.

A kódunk még messze nem tökéletes. Először csak rövid optimalizációkat végzünk. A szögfüggvényeknek például van a CUDA magokon futó változata. Ezt a math_functions.h fejléc állományban elfedik előlünk, hogy könnyű legyen a kód migrálása, de jobb, ha ezt magunk csináljuk, nem bízzuk egy fordítóra, amit nem mi írtunk :-) Ezért nézzük át a device_functions.h fejlécállományt. Találunk ott egy érdekes függvényt: __sincosf(). Tehát egy lépésben kiszámolhatjuk a színuszát és a koszinuszát ugyan annak a szögnek.

Általánosságban elmondható, hogy a két aláhúzással jelzett függvények eszköz kódok. Amikor csak tehetjük, használjuk őket. Szorzás helyett is nyugodtan használhatjuk az __fmul_rn függvényt. Ezek alapján az új distance függvényünk a következőképp fog kinézni:

__device__ float distance(float2 p1, float2 p2){
   float dx = p1.x - p2.x;
   float dy = p1.y - p2.y;
   float x2 = __fmul_rn(dx,dx);
   float y2 = __fmul_rn(dy,dy);
   float su = __fadd_rn(x2,y2);
   return( __fsqrt_rn(su) );
}

 

Megmondom őszintén, nem tudom, mit jelent a függvények végén az _rn. Van másik három rz, rd, ru is, nem tudom, hogy mi a különbség közöttük. Amint lesz róla információm, kijavítom ezt a bejegyzést.

__device__ void collision(float2 *p1, float2 *p2, float angle){
   float p1x2 = __fmul_rn( p1[0].x, p1[0].x );
   float p2x2 = __fmul_rn( p2[0].x, p2[0].x);
   float p1y2 = __fmul_rn( p1[0].y, p1[0].y);
   float p2y2 = __fmul_rn( p2[0].y, p2[0].y);

   float m1 = __fsqrt_rn( p1x2 + p1y2);
   float m2 = __fsqrt_rn( p2x2 + p2y2);
   float d1 = atan2f( p1[0].y, p1[0].x);
   float d2 = atan2f( p2[0].y, p2[0].x);

   float sa, ca, sb, cb; /* sin and cos of d1 - angle */

   __sincosf(d1 - angle, &sa, &ca);
   __sincosf(d2 - angle, &sb, &cb);

   float p1newx = __fmul_rn(m1,ca);
   float p1newy = __fmul_rn(m1,sa);
   float p2newx = __fmul_rn(m2,cb);
   float p2newy = __fmul_rn(m2,sb);

   __sincosf(angle + 3.14f / 2.0f, &sa, &ca);
   __sincosf(angle, &sb, &cb);

   p1[0].x = __fmul_rn(cb,p2newx) + __fmul_rn(ca, p1newy);
   p1[0].y = __fmul_rn(sb,p2newx) + __fmul_rn(sa, p1newy);
   p2[0].x = __fmul_rn(cb,p1newx) + __fmul_rn(ca, p2newy);
   p2[0].y = __fmul_rn(sb,p1newx) + __fmul_rn(sa, p2newy);
}

 

A collision függvényünket is megváltoztathatjuk. Itt ráadásul áttekinthetőbbé tettük a paramétereket. A mutatók tömbként való használata nem véletlen, ha másképp használjuk őket, akkor "error: expression must have class type" hibaüzenetet kapunk fordítási időben.

Utolsóként a calcParticlePos függvényünk következik. A globális memória elérése nem túl ideális, egyrészt a lassabb elérés miatt, másrészt a konfliktusok miatt. Előfordulhat ugyanis, hogy több szál próbál meg módosítani egy memória területet.

A memória elérés gyorsítására lehet használni a megosztott memóriát. Annak bemutatására most nem vállalkozom.

Szólj hozzá!

Címkék: programozás

Kutatók és programozás

2011.02.19. 19:08 Travis.CG

Egy érdekes cikkre bukkantam a Nature hasábjain (itt). Röviden a lényege, hogy a kutatók többsége képtelen normális kódot írni. Nem ellenőrzi, dokumentálják a programosorokat, ezért a vége jobb esetben nem működő program, rosszabb esetben hibás eredmény, amit neves újságok hasábjain publikálnak.

Szeretném hinni, hogy én nem tartozom közéjük, amire az ad okot, hogy dolgoztam programozóként is, nem csak kutatóként. Ha viszont az itt feltüntetett kódjaimban vagy a demóim forráskódjában valaki oltári nagy ostobaságot talál, akkor annak a cikkben leírtak az okai.

Komolyra fordítva. A munkám során én is találkoztam ilyen esetekkel. Az első egy hipergeometrikus eloszlást számolt GO azonosítókra. Azt vettük észre, hogy a program meglepően lassú. Megnéztem a forráskódot és meglepődve tapasztaltam, hogy minden egyes rendezés során az adatokat fájlba írta. Ez elég rossz hír volt, de a mégrosszabb az volt, hogy a program szerzője nem ismerte a hasítótáblákat, helyette tömböt használt. Minden egyes alkalommal végigjárta a teljes tömböt, ha egy elemet meg akart találni. Természetesen ezt is fájlba írta, majd visszaolvasta onnan. Mondanom sem kell, hogy a fenti két hiba kijavítása után 40-szeres sebességnövekedést értünk el.

A másik esetben a Java program tartalmazott C programrészletet, aminél súlyos memóriaszivárgás volt. Ez csak bizonyos hosszúságú szekvenciáknál okozott szegmentációs hibát. Az utolsó esetben olyan programmal találkoztam, ami gyakorlatilag érthetetlen volt a számomra. Bonyolult volt a matematikai modell is, amit alkalmazott (legalábbis nekem), de a program felépítése ezt tovább bonyolította. Az összetettséget jól példázza, hogy bárki, aki a kódhoz nyúlt és javított benne valamit, két másik hibát ejtett.

A cikkben említett jelenséget tehát én is megtapasztaltam. Kérdés, hogy mit lehet tenni ellene. Először is, ne tegyünk fel mindent egy lapra. Ha egy program kiadott egy eredményt, ne higgyük, hogy most miénk lesz a Nobel-díj. Használjunk több programot. Ahogy a laboratóriumi munkában sem fogadják el, ha csak Chip-kísérletet végznek és nem validáljuk azt QT-PCR-al, mi se dőljünk hátra, ha egyetlen program, egyetlen beálításokkal kiad egy eredményt.

Most Blastot fordítok, ezért van némi időm sztorizgatni. Például egy baktérium szekvenálása során kaptunk egy gént, ami elé egyedi volt, hogy a Blast ne adjon egyértelmű ereményt, ezért halvány sejtelmünk sem volt róla, hogy mi lehet a szerepe. Több prediktáló programot is kipróbáltunk, míg végül egyszer csak azt kaptuk, hogy transzmembrán proteint kódol. Ez sem volt egyértelmű, mert amint megváltoztattuk kicsit a program paramétereit, rögtön eltűnt az eredmény. Természetesen hozzá kell tennem, hogy ezt az eredményt kísérletesen ellenőriztük és olyan szerencsénk volt, hogy igazolni tudtuk.

Végezetül még egy tanács. Ha mi magunk írunk programokat, ne féljünk tanulni. Ne higgyük, hogy csak azért, mert elméleti algoritmusokat vagyunk képesek működő programkóddá varázsolni, máris mi vagyunk a programozás nagymesterei. Ha pedig hibás programra bukkanunk, javítsuk ki, vagy írjunk újat, mert senki nem csinálja meg helyettünk.

Szólj hozzá! · 1 trackback

Címkék: programozás filozofálás bioinformatika

Efika

2011.02.18. 13:00 Travis.CG

Még 2007 tavaszán, a SceneCon nevű demoshown láttam meg az Efikát és mondhatom szerelem volt az első látásra. Egy csendes, alacsony fogyasztású, mérsékelt (mások szerint gyenge) teljesítményű számítógép, ami a legegyszerűbb igényeket kielégíti.

Több, mint két évet kellett várnom rá, hogy az enyém legyen. Ez alatt az idő alatt az emberek többsége elpártolt a kedves kis géptől, a gyártását beszüntették. Használtan jutottam hozzá (egy váláson már túl volt), haza is vittem. Mint a kapcsolatok többségénél, itt is igaz volt, hogy lakva ismeri meg a másikat az ember. A filigrán kis házból hiányoztak a csavarok, amerikai típusú hálózati csatlakozót kaptam hozzá és két olyan videokártyát, amelyik közül egyikkel sem ment.

A legegyszerűbben a hálózati csatlakozó problémáját oldottam meg. A gép energiaellátásáról egy laptop tápegység gondoskodik (mondtam, hogy alacsony fogyasztású), ezért használtan vettem egy három ágú tápkábelt, amivel máris megetethettem árammal.

A videokártyákkal is voltak problémák. Mint említettem, kettőt kaptam. Egy Nvidia GeForce MX440-t és egy Ati Radeon 9200-t. Az Nvidiás belefért a kis házba, de nem volt hűtése és képtelen volt elviselni azt a felbontást, amit a Linuxos telepítő beállított neki. Az Ati kártya képes lett volna rá, de az nem fért bele a házba, sőt igazából az alaplap néhány kivezetése is akadályozta. Kellett szerezni egy vékonyabb kártyát. Újabb használt cikk keresés. Végül szert tettem egy Ati 9250-re, ami már illett a kisasszonyhoz. Akitől vettem, nem tudott feles takaró lemezt adni hozzá, ezért kedvenc többfunkciós fogómmal addig faragtam a lemezt, amíg a nem illeszkedett a házba.

A gép két USB-t tartalmaz. Az egyik értelemszerűen a telepítés során a pendrive-t fogadja, a billentyűzetnek és az egérnek már csak egy marad. Szereztem egy USB elosztót is, de az alacsony áramfelvételű gép USB-je nem ad elegendő feszültséget, hogy egy USB elosztót üzemeltessen (aminek nincs saját áramforrása). Ekkor felvettem macsó modoromat és kijelentettem, hogy nem kap új USB elosztót, enélkül fogok boldogulni.

Első körben Linuxot akartam rá telepíteni. A Genesi elérhetővé tett egy Debian-t, amit állítólag könnyedén lehet telepíteni a gépre, Sajnos a hálózatról akarta leszedni a szükséges kernelt, ami ennyi idő távlatából már sehol nincs fent, a telepítés ezen lépését pedig nem tudtam megkerülni. Második jelentkező a Slackware volt. Ez a a partíciók formázásánál nem tudott tovább lépni.

Végül a MorphOS mellett döntöttem. Akár milyen hihetetlen, ezt sem tudtam telepíteni. A grafikus környezetet csak billentyűvel kezeltem, a TAB és a nyilak gyors váltogatásával, de a telepítés gomb valami miatt nem volt aktív, ezért ezzel a rendszerrel is befürödtem.

Azt csak mellékesen jegyzem meg, hogy elsőre soha nem ismerte fel a rendszerindítás után a pendrive-ot. Kétszer-háromszor kellett neki kiadni az uboot parancsokat, hogy felismerje, amit fel kell ismernie.

Végül bármennyire is nem szeretem, a Suse Linux mellett döntöttem, ami még könnyebb telepítést tesz lehetővé. A dokumentáció részletesen leírja, hogy mit kell csinálni a telepítés során. Követtem is a lépéseket, de az már nem derült ki, hogy újraindítás után mit kell csinálni. A merevlemezen volt a rendszer én pedig ültem a gép előtt és azon gondolkodtam, mi legyen a következő lépés.

Természetesen a boot hd:0 boot/efika sorokkal kezdtem. Ez minden áron kereste a nem létező /dev/sda3-t. Volt még két másik kernel is a boot partíción efika19 és efika19genesi. Ezek csak kernel pánikoltak. Végül egy fórumban fedeztem fel a lényeget: root=/dev/sda1. Persze, magamtól is kitalálhattam volna.

Elindítottam a rendszert, szépen be is jött az üdvözlő képernyő, majd rájöttem, hogy nem tudom sem a felhasználói nevet, sem annak jelszavát, amivel beléphetek. Ha lenne egy CD meghajtó, máris indítanám a Knoppixot, de így? A helyzet korántsem olyan reménytelen. A rendszerfájlok ugyanis megvannak egy tömörített állományban. Ezt kicsmagoltam, és máris böngésztem az /etc/passwd állományt. Meg is találtam, amit kerestem: felhasználónév: genesi, jelszó: genesi. A rendszergazdai jogosultságnak is ez a jelszava! Hurrá!

A kis hölgy ellenállását sikerült megtörni. Most már olyan, mint egy kezes bárány. Alacsony fogyasztásának hála rengeteg lehetőség van benne. Első lépésként kíváncsi vagyok, hogy megy-e a TV kimenet a videokártyán (10.3 Suse miatt nagy rá az esély, hogy nem). Utána megnézem, mennyire szereti a webkamerákat.

Szólj hozzá!

Címkék: rendszergazda

Visz'lát SRA

2011.02.16. 12:12 Travis.CG

Nem kétséges, hogy azoka, akik tesztelési és elemzési célra újgenerációs szekvenálási adatokat akartak szerezni, először a SRA-t keresték fel. A pénzügyi problémák viszont utólérték ezt a szervezetet is, mint az ebből a blogból kiderül. Valószínű, hogy bezárják ezt az adatbázist.

Miért is jelent ez problémát? Először is, az újgenerációs szekvenálás hatalmas mennyiségű adatot termel. A marketing szövegeken túl ugyanis elég rossz minőségű szekvenciákat produkálnak ezek a készülékek (legalábbis a régi típusú Sanger szekvenáláshoz képest), amit úgy próbálnak orvosolni, hogy többször szekvenálnak meg valamit. Ezt hívják lefedettségnek. Egy 10-szeres lefedettségű emberi szekvencia elérheti a 30GB-ot is, tömörítve. Érthető módon senki nem szeret a munkaállomásán ekkora mennyiségű adatot tárolni. Ehhez még hozzájönnek az elemzések során kelektkezett állományok, és máris ott tartunk, hogy feléltük egy átlagos merevlemez kapacitását.

A másik probléma, hogy ezeknek az adatoknak elérhetőnek kell lennie mások számára is. Egyrészt, hogy ellenőrizhessék azokat, másrészt további vizsgálatokat végezhessenek. Ezért nem elég, ha ezek az adatok ott porosodnak bármilyen adathordozón, az interneten elérhetőeknek kell lenniük.

Ez a hely pedig sokáig az SRA volt. Rajta kívül van még az ENA, de engem személy szerint nem nyűgözött le a megtalálható adatok mennyiségével, bár akadnak érdekes szolgáltatásaik is.

Mit lehet tenni, hogy kiváltsuk az SRA-t? Két fő csapásirány lehetséges. Az egyik a centralizált adatbázis, a másik a decentralizált.

Centralizált megoldások

  • Jön egy új szervezet, megszámlálhatatlan mennyiségű tárhellyel és egyszerűen átveszi az SRA helyét. Például a fent említett ENA
  • Mindent felhő alapú gépekre helyezünk, például az Amazonra.

Decentralizált megoldások

  • Biotorrent. Nem csak a legújabb Hollywoodi filmeket szerezhetnénk be a hírhedt fájlcserélő szolgáltatáson keresztül, hanem kedvenc szekvenciánkat is. Csak legyen, aki seedel. :-)
  • dCache-szerű rendszer fejlesztése. A fizikusok is sok adatot termelnek, és ők ezzel oldották meg az adatelérést.

 

Szólj hozzá!

Címkék: bioinformatika

süti beállítások módosítása