HTML

Az élet kódjai

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

Friss topikok

  • Travis.CG: Annyiban én is hibás vagyok, hogy könnyen előjönnek belőlem negatív posztok, ezt akartam ellensúly... (2025.05.22. 19:34) Ne csak a rosszat halljátok
  • 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

LibreOffice távvezérlés

2013.11.01. 21:42 Travis.CG

Nemrég megkértek, hogy a UEA kimenetét formázzam be Excellel, de úgy, hogy a rekordok ne egymás alatt legyenek, hanem külön munkafüzeteken. A probléma az volt, hogy körülbelül 2500 rekord volt. Rögtön a régi vicc jutott eszembe:

- Az micsoda?
- Cukorborsó.
- Kérek egy kilót. Külön-külön becsomagolva. Selyempapírba.

Már majdnem elküldtem a fenébe a kérelmezőt, hogy nekem nincs is Excellem, csak LibreOffice-m, amikor eszembe jutott, hogy ez nem is hátrány. A beépített makrók segítségével biztosan meg lehet oldani a feladatot. Elkezdtem utána olvasni a LibreOffice programozásának, és még jobbat találtam. A program ugyanis vezérelhető egy másik alkalmazásból! A Java-t választottam a lehetséges nyelvek közül.

Először is telepíteni kell a LibreOffice SDK-t, ami Ubuntu alatt fájdalom mentes. Ha Eclipse-el dolgozunk, meg kell adni négy jar-t a projektnek: juh.jar, jurt.jar, ridl.jar, unoil.jar. A táblázatkezelő vezérléséhez a következő osztályokra lesz szükség:

import com.sun.star.beans.PropertyVetoException;
import com.sun.star.beans.UnknownPropertyException;
import com.sun.star.beans.XPropertySet;
import com.sun.star.comp.helper.BootstrapException;
import com.sun.star.container.NoSuchElementException;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.lang.IllegalArgumentException;
import com.sun.star.lang.IndexOutOfBoundsException;
import com.sun.star.lang.WrappedTargetException;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.table.XCell;
import com.sun.star.table.XCellRange;
import com.sun.star.uno.Exception;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
import com.sun.star.sheet.XSpreadsheet;

A legfontosabb osztály, amit én csak excel-nek neveztem el:

private com.sun.star.sheet.XSpreadsheetDocument excel = null;

A távvezérlés egyfajta szerializálással történik, ezért tűnik bonyolultnak az inicializálás. Általában itt is elmondhatjuk, hogy a dokumentáció elég hiányos. A hivatalos javadoc pont a lényeget nem tartalmazza. A példaprogramok viszont első rangúak, azon belül is a Helper végződésű osztályokat érdemes nézni.

XComponentContext comp = com.sun.star.comp.helper.Bootstrap.bootstrap();
            System.err.println("Connecting...");
            XMultiComponentFactory multi = comp.getServiceManager();
            XComponentLoader loader = UnoRuntime.queryInterface(XComponentLoader.class, multi.createInstanceWithContext("com.sun.star.frame.Desktop", comp));
            XComponent xc = loader.loadComponentFromURL("private:factory/scalc", "_blank", 0, new com.sun.star.beans.PropertyValue[0]);
            excel = UnoRuntime.queryInterface(com.sun.star.sheet.XSpreadsheetDocument.class, xc);

A cellák feltöltése ezek után már gyerekjáték: Ha számot akarunk beírni, a setValue metódust használhatjuk, minden más esetben a setFormula a nyerő:

excel.getSheets().insertNewByName(name, limit);
            XSpreadsheet page = UnoRuntime.queryInterface(XSpreadsheet.class, excel.getSheets().getByName(name));
XCell cell = page.getCellByPosition(0, 2);
double value = 5.0;
cell.setFormula("Chromosome");
cell = page.getCellByPosition(1, 4);
cell.setValue(value);

Ha formázni is szeretnénk a cellákat, először ki kell jelölni a cellákat, majd a setPropertyValue segítségével beállítjuk azt, amit szeretnénk.

XCellRange cells = page.getCellRangeByPosition(0, 0, 20, 40);
XPropertySet prop = UnoRuntime.queryInterface(XPropertySet.class, cells);
prop.setPropertyValue("CharFontName", "Courier");

Egy kis segítség az elérhető jellemzők listájához:

Property[] p = prop.getPropertySetInfo().getProperties();
for(Property i:p){
   System.out.println(i.Name + " " + i.Type.toString());
}

Ennek segítségével már tudtam írni egy programot, ami elkészítette a kívánt táblázatot. Mikor a megrendelő meglátta, már ő is látta, mennyire áttekinthetetlen.

Szólj hozzá!

Címkék: java programozás

Nesze, dolgozz

2013.11.01. 21:42 Travis.CG

neszedolgozz_1383221883.png_854x865

A Word dokumentum, olyan, mint egy bonbon. Soha nem tudod, mit találsz benne.

(A nem bioinformatikus lelkű olvasóimnak: ahelyett, hogy koordináták szerint adták volna meg az elemezni kívánt szakaszokat, beszínezték nekem.)

De nem sikerült kiszúrniuk velem. Az egész 9 oldalas dokumentumot elmentettem szövegként, majd egységes formára hoztam őket: fejléc, szekvencia, üres sor, jellemzők felsorolás. Ezután már csak egy szkriptet kellett írni, hogy elmentse GFF formátumba.

Szólj hozzá!

Címkék: életmód bioinformatika

Redis - kirándulás NoSQL országban

2013.10.27. 22:36 Travis.CG

Perlben előszeretettel használok hash of hash, hash of array és más adatstruktúrát. Javaban is sokszor látni generikusokat a kódomban. Egyetlen probléma velük, hogy csak a rendelkezésre álló memória határain belül lehet élni lehetőségeikkel.

A nagyományos SQL alapú adatbázis kezelőkben hasonló struktúrák elkészítése nem egyszerű feladat, de szerencsére nincs is rá szükség, mert van egy adatbázis, ami pont a fent említett struktúrákat támogatja. A neve Redis.

A lényege, hogy nem táblázatban kell gondolkodni, hanem kulcs-érték párokban. A kulcs minden esetben egy szöveg, de az érték többféle típus is lehet. Nyilván a legegyszerűbb, ha az érték maga is egy szöveg. Szöveg alatt bármilyen bináris adatot kell érteni. Ez önmagában még nem lenne túl érdekes, de ha az érték egy lista, akkor a hash of array struktúrának megfelelő adatbázis szerkezetet kapunk. A lista sorrendje kötött, az elemek beillesztésének sorrendje határozza meg.

Használhatunk hasítótáblát az értékek között is. Itt csak egy szint engedélyezett, ami annyit tesz, hogy nem tudunk "hash of hash of hash" struktúráknak megfelelő szerkezetet létrehozni a beépített eszközök segítségével. De ha nem írtózunk a barkács megoldásoktól, akkor bevezethetünk különböző prefixeket a kulcsok esetén és máris tetszőleges mélységig vihetjük a hasheket (és az átláthatatlanságot is).

Szerencsére további struktúrák is vannak a Redis tarsolyában. Az egyik a halmazok (set). Ha nem érdekel minket az értékek sorrendje, ez az ideális választás. Ennek egy speciális változata a rendezett halmaz (sorted set).

Telepítése roppant egyszerű. Ubuntu és Fedora alatt is gond nélkül telepítettem, de be kell vallani, a Fedorás telepítés nem hoz létre központi adatbázist, hanem a felhasználó könyvtárába elhelyez egy redis.db állományt. A kliens programját a redis-cli paranccsal indíthatjuk.

Ha saját alkalmazásból szeretnénk meghívni, különböző API-k állnak a rendelkezésünkre. Én eddig a C, R és Python API-kat próbáltam ki, komolyabb problémák nélkül. (Az R verzió kiforratlannak tűnik) Amennyire jó és részletes a parancsok dokumentációja, annyira hiányos az API-k leírása, ezért röviden ezekről is írnék.

C API

A hivatalos C API a hiredis, ami egy magas szintű API, gyakorlatilag a konzolos parancsokat írhatjuk be a redisCommand második paraméterébe szövegként. Az első parameter az adatbázis kapcsolatot leíró változó. Az utasítás visszatérési értéke egy redisReply struktúra, ami az összes lehetséges visszatérési típushoz tartalmaz mezőket. Ez feltételezi, hogy a programozó tudja, milyen típust kell visszakapni. A defenzív kódolást a type mező támogatja. Ha szöveg a visszatérési érték, akkor az str, egész esetén az integer mező tartalmazza az adatot. Több eredményt is várunk az adatbázisból, az elements tömböt kell bejárni.

Mint említettem, a dokumentáció hiányos, de bőséges mennyiségű példaprogramot mellékelnek, amit akár a dokumentáció helyett is olvashatunk.

R API

Az rredis a CRAN-on megtalálható, tehát telepítése probléma mentes. A C API-hoz képest itt minden egyes utasításnak egy parancs felel meg. A parancsok neve megegyezik a konzolos parancs nevével, redis prefixel ellátva.

Python API

Python esetén is több API létezik, én a redis-py-t használtam. Az adatbázis kapcsolat létrejötte után kapunk egy osztályt. Ennek az osztálynak a metódusai az egyes műveletek. A nyelv erősen típusos jellege miatt minden esetben pontosan tudnunk kell, milyen típusú értékeket kaphatunk vissza az adatbázisból. A hibakeresésnél érdemes ezt ellenőrizni.

Mire használható ez az adatbázis? Ezt is be fogom mutatni.

Szólj hozzá!

Címkék: programozás

Intézeti felhőcske

2013.10.22. 18:51 Travis.CG

Eddig elég sok negatív dolgot írtam a cégekről, pedig egy területen nagyon is az akadémiai szféra előtt járnak, ez pedig az információ rendszerezése. Gondolok itt arra, hogy a futó projektek hol tartanak, kinek, mi van vissza egy feladatból. Az újonan belépőknek dokumentációk állnak a rendelkezésére, amelyek segítségével felveheti a fonalat és rövid időn belül hatékonyan tud dolgozni.

Most sokan bizonyára felhördülnek, és sztorikat mesélnek arról, hogy bezzeg XY cégnél milyen trehány/hibás/elavult a dokumentáció vagy mennyi hiba is található bennük, de erre csak azt tudom mondani, még nem látták, hogyan megy ez a legtöbb kutatóintézetben. A jobb helyeken van egy könyvtár, amiben általában nincsenek további könyvtárak és oda van beömlesztve egymillió azonos nevű Excel/Word dokumentum. A rosszabb helyeken papírfecnikre írják a fontos dolgokat és rossz szemmel néznek rád, ha ki akarod nyitni az ablakot.

A munkatársaknak e-mailen küldik el a részeredményeket, amiket vagy megtalálnak, vagy elvesznek a "Call for paper" kezdetű levelek között. A dokumentum verziók kezelése felér egy elme-trükkel, mert először számozzák a verziókat, majd később áttérnek az abc betüire, esetleg mégis visszatérnek a számokra.

A gépek állapotáról pedig ne is beszéljünk. Az igényesebbek behozzák a rokonok levedlett "gamer" konfigurációit, amit a számítógép bontók is könnyes nevetés közepette vesznek át, a türelmesek pedig bekapcsolás után vagy megcsinálnak egy kísérlet sorozatot, vagy megisszák a reggeli kávéjukat.

A fent vázolt helyzeten igyekeztem javítani különböző szerver oldali megoldásokkal, amit egy kis nagyképűséggel még felhőnek is hívhatunk. A megoldások bárki számára elérhető eszközökből áll. (A jövöben posztokat fogok írni ezek alternatíváiról ), más részüket viszont én fejlesztettem. Ezek az oldalak bűn rondák funkció központúak.

A tudás összegyűjtése

Az egyes vizsgálatok eredményeit egy közönséges MediaWiki oldalon gyűjtjük. A telepítése rém egyszerű, karbantartást alig igényel. Képek, táblázatok és leíró szövegek tárolására és megosztására ideális. Többé nem jelent gondot, hogy többen is szerkesztenek valamit, nincs Excel kompatibilitási probléma. Beépített verzió kezelő is van, tehát látható, hogy ki szerkesztette az adott bejegyzést és mikor. Hátránya, hogy saját formázási kódokat kell használni, ami elriaszthat sok embert.

Fájlok tárolása

Az e-mail attachmentek, mint fájl tárolási és megosztási módszer szerintem rettenetes. Egy közönséges FTP szerverrel váltottuk ki. Az FTP eléréshez rengeteg eszköz áll rendelkezésre, erre még a legvénebb profot is meg lehet tanítani. Hátránya, hogy alapból nincs semmilyen védelem a felülírás ellen, a közel egyforma nevű fájlok ellen és a káosz egyéb formái elle, amire csak kutató képes lehet.

Szekvencia homológia

Néha szükség lehet saját Blast szerverre. Nálunk előfordulnak olyan szekvenciák, amelyeket még nem publikáltunk, de dolgozni kell velük. A parancssoros megoldások szóba sem jöhetnek, de egy webes megoldás még belefér. Nálunk kétféle Blast szerver van. Az egyik az NCBI-ról letöltött, ami mind funkciójában, mind küllemében arra hasonlít, de saját szekvenciák vannak benne. A másik egy saját klón, ahol egyedi igényeket is ki kellett szolgálni. Jelen esetben a cél az volt, hogy a találatokhoz tartozó short readeket is látni akarták.

Ezért egy egyszerű PHP oldalt készítettem, ami lefuttatja a Blastot. Az eredményt XML-ben kapom vissza, DOM segítségével kinyerem a lényeges információt és készítek belőle egy linket, amit a Blast kimenet végére odaillesztek. Mire mutat a link? Egy genom böngészőre. A hátránya, hogy mivel én állítom elő az eredményt, ezért az nagymértékben különbözik az NCBI-os Blastnál megszokott képtől.

A másik saját fejlesztésű eszköz egy egyszerű kisRNS kereső. Gyakorlatilag egy webes fuzznuc, annyira megbolondítva, hogy több mintában meg kellett jeleníteni a kisRNS abundanciáját. Először a PHP fuzznucot hívott volna, de annyira lassú volt, hogy inkább implementáltam egy rövid C kódot naív szöveg kereséssel a mismatchek miatt. Még ez is 3x gyorsabb volt, mint a fuzznuc.

Kevés PHP kódot akartam írni, és szerettem volna, ha egy szkriptben meg tudom oldani az eredmények szöveges megjelenítését és a grafikont az abundancia értékekkel, ezért a PHP HTML5-öt generál SVG-vel.

A genom vizualizálása

Az IGV remek eszköz, de egy eukarióta genom és a hozzá tartozó readek megjelenítéséhez komoly erőforrások kellenek, amik nem minden laborgépen érhetőek el. Ezért telepítettem egy JBrowsert. Ez egy rendkívül egyszerűen installálható eszköz, kliens oldalon csak egy böngészőre van szükség. Bár a telepítés egyszerű, a szerver oldalon hatalmas index könyvtárakat készít. Egy 10 ezer scaffoldból álló növényre 3 napig futott az indexelés. Hátránya, hogy bár leveszi a terhet a kliensről, szerveroldalon komoly erőforrásokra van szükség.

Kód verziókövetés

A legtöbb bioinformatikus nem használ verziókövető rendszert, mert a kódon csak egyedül dolgozik. De ha több szerveren is használja ugyan azt a kódbázist, és még mindegyiken valamit változtat, könnyen azon kaphatja magát, hogy ugyan olyan néven több szkript is van, és mindegyik mást csinál. Végül a kódban turkálva kell kitalálni, mit is csinál az adott program, mert ugye dokumentációt nem írunk. (Igen, én sem)

Ilyen esetben is hasznos lehet a verziókövető rendszer. Nálam ez kilóg a sorból, mert egészen egyszerűen a GitHub-ot használom, nem saját telepítésű repositoryt. Nincs tárhely probléma, nem igényel karbantartást, bárhonnan elérhető. Hátránya, hogy mindenki látja, milyen béna kódokat írok.

Jelen pillanatban ezekből az elemekből áll a felhőcske. Ami még hiányzik, egy jó projekt követő rendszer, amivel a jegyzőkönyveim is egy helyen lennének. Amint megtalálom a megfelelőt, arról is írni fogok.

4 komment

Címkék: cloud computing bioinformatika

Cinema 4D bővítmény fejlesztés (3. rész)

2013.10.01. 22:55 Travis.CG

Demoscene szempontból a legfontosabb bővítmény típus szerintem az export plugin. Ennek segítségével ültethetjük át munkánkat a demóba. A bővítmény regisztrálását a RegisterSceneSaverPlugin() függvény végzi. A negyedik paraméterrel kell átadni a SceneSaverData osztály egy leszármazottját.

A dokumentáció csak a Save() virtuális tagfüggvényt említi, de kell egy statikus gyártó metódus is konstruktor helyett. Ez a megoldás egyébként általános a Cinema4D-ben.

A Save() függvény egyik paramétere a mentés során megadott fájlnév, míg a BaseDocument osztályon keresztül az összes grafikus objektumot elérhetjük. Gyakorlatilag ez a Cinema 4D felhasználói felületén a jobb oldalon található fa struktúra. Az alábbi kód az egyszerűség kedvéért csak a legfelső szint objektumait járja végig:

BaseObject *obj = doc->GetFirstObject();
do{
  switch(obj->GetType()){
    case Opolygon:
    break;
    case Ocamera:
    break;
  }
}while(obj = obj->GetNext());

Az adatokat a BaseFile osztályon keresztül írhatjuk ki. A következő kódrészlet ezt demonstrálja:

BaseFile *file = BaseFile::AutoAlloc();
Filename *filename = new Filename("test.out");
file->Open(filename, FILEOPEN_WRITE, FILEDIALOG_ANY, BYTEORDER_INTEL, 0, 0);
file->WriteString("Data");
file->Close();

Gyakorlatilag az összes adattípushoz van egy metódus. Ha szöveges állományokat akarunk készíteni, akkor meglepődve tapasztalhatjuk, hogy bináris adatok is kiírásra kerülnek. Fórumokat bújva azt a megoldást találtam, hogy karakterenként kell kiírni a sztringet. Nevetséges, de tényleg ez tűnik az egyetlen járható útnak.

Fontos lehet hibakereső üzeneteket hagyni. A Cinema4D rendelkezik egy saját konzollal, ahová a bővítmények is írhatnak. Az ablak a Script -> Console menüponttal kapcsolható be. A kódban a GePrint() segítségével tudunk írni rá.

Sajnos a fejlesztés egyik hátulütője, hogy nem tudjuk közvetlenül tesztelni a megírt kódot. Lefordítjuk, elindítjuk a Cinema4D-t, lefagyasztjuk az egészet a bővítményünkkel, majd visszatérünk a Visual Studioba és átírunk valamit. Ez egy elég időigényes procedúra, különösen a tanulási fázisban, amikor még a metódusok útvesztőjében is keresgélni kell. Célszerű ezért  - ahogy a dokumentáció is javasolja - defenzíven programozni és a paraméterekhez grafikus felületet fejleszteni, ahol futás időben láthatjuk a hatásaikat. A következő részben erről fogunk beszélni.

Szólj hozzá!

Címkék: programozás demoscene

Beszéljünk párszaszóul

2013.10.01. 22:46 Travis.CG

Mint minden bioinformatikus, én is Perlel kezdtem megismerni a szkriptek világát. Sokáig ellenálltam a Python csábításának, de be kellett látnom, hogy ha továbbra is naprakész akarok lenni, nem hagyhatom figyelmen kívül a nyelvet.

Korábban is voltak időszakos fellángolásaim, amikor úgy döntöttem, megtanulom a nyelvet, de mindig találtam valami idegesítő tulajdonságot, ami eltántorított attól, hogy teljesen elsajátítsam. Először a megváltoztathatatlan típusok dühítettek fel. Nem értettem, hogy egy dinamikus nyelvben mi keresnivalója van ezeknek? Tuple? Még a név is röhejes. Mentem is vissza Perl alá, ahol nyugodtan összeszorozhattam akár a sztringeket is. Később beszéltek nekem a többszálúságról, ami más megvilágításba helyezte ezeket a típusokat.

Ahogy telt az idő, megint arra gondoltam, meg kéne tanulni Pythonban programozni. Második alkalommal már az osztályokig is eljutottam, ahol azt láttam, hogy a felhasználó moduljai valami eszetlen könyvtárstruktúrában vannak szétosztva. __init__.py Ez valami vicc? Mi ez a beteges vonzódás a kettős alulvonáshoz? Folytattam is a munkát Perlben, ahol írhattam az 1; minden modul végére.

Majd olvastam, hogy a 3-as verzió nem is kompatibilis a 2-essel. Most akkor melyiket tanuljam meg? Egyiket sem.

Bár én folyamatosan csak hibákat láttam a nyelvben, mégis egyre jobban terjedt. Először a telefonomhoz töltöttem le egy értelmezőt, ami végre visszaadta a C64-nél megtapasztalt érzést, milyen is, ha egy gép azonnal programozható (a hangulatot csak az rontotta, hogy a telefon gombjaival elég nehéz programozni). Később a Blenderben tűnt fel, mint szkript nyelv (amit még használtam is). Még az Amigás vonal sem menekült meg tőle, hiszen az OS4 is ezt választotta. De ha már említettük a 3D programokat, meg kell említeni, hogy ott van a Cinema4D-ben is.

Legutóbb egy weboldal karbantartásánál lettem figyelmes arra, hogy a kép galériát valami Djangoban hozták létre. Nem nehéz kitalálni, hogy ez is Pythonon alapszik.

Igazából napestig lehet keresni a kifogásokat, miért nem akarok Pythonban programozni. Ugyan ennyi ideig lehet sorolni azt is, milyen lehetőségektől esek el ezáltal. Ezért pár hete úgy döntöttem, Perl helyett Pythonban írom a munkahelyi szkripteket és megtanulom rendesen ezt a nyelvet.

6 komment

Címkék: programozás

Kompatibilitás

2013.09.21. 17:00 Travis.CG

Az üzletkötők mindig is a szívem csücskei voltak. Talán azért, mert ez egy nehéz szakma és rendkívül sokrétű tudást igényel. Akikkel eddig találkoztam, azoknál sem a sokrétűség, sem a tudás nem volt meg. Mindkettőt hihetetlen magabiztossággal pótolták.

Az intézet vett egy QPCR-t és elmentem meghallgatni, mire is jó ez. Az előadók nagyon felkészültek voltak, ezért kezdtem arra gondolni, hogy a rossz tapasztalataim alapján egy hibás kép alakult ki bennem az üzletkötőkről. Nem törvényszerű, hogy mindegyikük nyomulós tuskó legyen, aki behazudik mindent a potenciális megrendelőnek.

A készülék egyébként rendkívül fejlett, még kockás füzet opciós is van benne. Mi az a kockás füzet opció? Réges régen, mikor még egy laborban csak egy PCR jutott három kutatóra és négy PhD hallgatóra, akkor a készülék mellett a kockás füzet biztosította, hogy aki használni akarta, az előre tervezhessen, tudja, mikor lesz szabad a gép.

Manapság ezt a készülék tudja, és neten keresztül küldjük rá a programot. (Nincs az, mint régen, hogy 5 programot tudott tárolni a gép, és mindig a ranglétra alján lévő dolgozó programját törölték, ha helyre volt szükség. Arról nem is beszélve, hogy sok gép nem is tárolta a programot.)

Nyilván fel is merült a kérdés, hogy a géphez adott kezelő alkalmazás milyen platformon fut? A válasz:

- Az ajánlás Windows 7-et ír elő, de én kipróbáltam Windows XP-n is, ami nem támogatott platform, és ott is futott, úgyhogy biztos megy Mac-en és Linuxon is.

Szólj hozzá!

Címkék: életmód

Function2013

2013.09.20. 22:37 Travis.CG

Mivel egy ideje nincs hordozható gépem, ezért utólag küldök partiriportot. A kapukat pénteken nyitották meg, de mivel a release elég rosszul állt, ezért a pénteki nap nekem kódolásból állt. Akkor varázsoltam Windows alá a Linuxos kódot. Utólag visszatekintve: nem kellett volna csinálni semmit. Hagyni kellett volna az egészet a fenébe.

Mivel kódoltam, két érdekes felfedezést tettem: Ha Windows alatt ezt csináljuk: glBindTexture(GL_TEXTURE2D, 0) és ezt átadjuk a shadernek, akkor feketeség lesz a textúra helyén. Linux alatt nem lesz textúra. A másik felfedezésem, hogy Windows alatt a geometry shaderben a PointSize nem állítja át a pont méretét.

Másnap, miután kevesebbet aludtam a kelleténél, de volt egy összedobott releasünk, elindultam Functionre. Útközben észrevettem Vickey-t, aki nem ismert engem, mert én elég marginális szereplője vagyok a hazai demoscenének, de megkérdezte tőlem, hogy ez a tömegközlekedési eszköz megy-e XY térre. Azt válaszoltam neki: igen, ezzel kell Functionra menni. Ezzel meg is teremtettem az alapot egy kis beszélgetésre.

A party lagymatagon indult, amin az sem segített, hogy álmos voltam. Az Amigások egy asztalnál ültek, és csak őket ismertem, ezért odacsapódtam hozzájuk. Kölcsönkértem egy gépet, hogy feltöltsem a release-t, majd néztem, mások mit játszanak a géppel. Pista valami freeglut-os vackot akart fordítani Dev-C-vel, de a beépített csomagkezelő ellenére nem sikerült. Megpróbáltam segíteni neki, de nekem sem sikerült. Hiába, na én Linuxhoz szoktam.

Egy arc már teljesen kiütötte magát, pedig csak délután két óra volt. Az előadások előtt úgy gondolta, hogy felmegy a színpadra és ráül az egyik hangszóróra. Miután szépen levezették (és jól körbefényképezték), lefeküdt a székekre és szerintem átaludta a teljes partyt.

Az első előadás az ingyenes játékokról szólt, illetve arról, hogyan lehet mégis pénzt keresni velük. Az előadás minőségén nagyot dobott, hogy nem egy öltönyös-nyakkendős manager osztotta az észt, hanem egy designer, aki szemmel láthatóan közelebb állt a hallgatósághoz. Érdekesség, hogy ő is biológus volt. Szerencsére a pénzkeresést nem a játékos függővé tételével akarják elérni, hanem a hiúkra és lustákra hajtanak. Nevezetesen, akik a játékban másképp akarnak kinézni, illetve, akik nem tudják kivárni, hogy szintet lépjen a karakterük.

A második előadás a JavaScript világába kalaúzolt, ahol a szemünk láttára nőtt ki egy egyszerű demo. Ez nyilván egy kódernek szép, de másnak talán dögunalom.

A fotók néhol rájátszottak egymásra. Voltak a pocsolya-tükörképet-fotózok képek és a ködben-fát-fotózok képek. Ennek ellenére lehetett látni egyedi megnyilvánulásokat is.

A rajzok remekek voltak, még úgy is, hogy nem értek hozzájuk. A kézi rajzok és a Photoshop szerkesztések egyaránt. Nem tervezem, hogy lecserélem a háttérképemet, de ha egyszer rávetemedek, biztos, hogy a mostani felhozatal is benne lesz válogatásban. Grass remekül összefoglalta a rajzokat itt.

A zenékre nem emlékszem. Bocsi minden indulótól, de tényleg semmi nem maradt meg belőlük. Később le is írom, mi oltotta ki emléküket.

Elérkeztünk a 256 byte intróhoz. Megvallo, féltettem ezt a kategóriát, hiszen a modert operációs rendszerek egyre nagyobb erőforrás igénye egyszerűen nem teszi lehetővé, hogy kicsi kódot készítsünk. Már jó ideje csak FreeDosból vagy DosBoxból futtatták őket, ami szerintem mutatja, hogy már csak egy maradvány kategóriának lehet tekinteni. És ekkor fedezték fel a scenerek a JavaScriptet (na jó, eddig is ismerték). A JavaScript segítségével modern eszközökön is lehetővé vált a 256b intró kódolás, akár platformoktól függetlenül is. Ez pedig hatalmas lendületet fog adni ennek a kategóriának. Mi sem bizonyítja ezt jobban, mint a 17 indulóból 3 JavaScript volt.

Másfelől ez a kategória, valljuk be, elég egysíkú volt. Az új platformnak köszönhetően viszont kellően változatos is tud lenni.

Az animációk most gyengébbek voltak, de minden évben nem lehet minden kimagasló. Az introknál meglepetés számomra, hogy Ágoston visszatért. Láthatóan nem erőltette meg magát, de ez is elég volt a győzelméhez. Üdv újra köztünk!

A compók szünetében volt alkalmam megnézni az embereket. A friss házasok, pocakos anyukák és ugráló kisgyerekek száma megemelkedett. Ha a trend folytatódik, jövőre nem árt gyerekmegőrzőt is biztosítani a szervezőknek.

Egy zenét kidobtak az indulók közül, mégis ez lett a kedvence a magyar indulóknak. Mulatós demozene ugyanis tudtommal még nem volt. A szöveg inkább a benfenteseknek vicces, ezért mi nagyon jót szórakoztunk rajta. Ez persze azzal járt, hogy a többi indulóra nem is emlékszem.

Ebből következik, hogy a demókra fordítható idő is csökkenni fog. Néhányan már el is kezdtünk megoldás után kutatni. Spenot a JavaScriptben látja a kiutat, különösen a platformfüggetlenség miatt. Elmondta, hogy a legtöbb ember már csak YouTube-on nézi a releaseket, ezért szerinte a néző szívesebben fog böngésző demókat nézni.

A másik megoldás, ami felé én kacsingatok, a Unity. Beszéltem is egy emberrel, aki Unityben írt játékot. Megkértem, mutassa meg nekem a rendszert és készítsünk valamit, hogy lássam az alkotás folyamatát. Mi más lehetett volna az első dolog, mint egy forgó kocka. Az engine engem a régi Visual Basic-re emlékeztet.

Annak idején Borland Pascallal készítettem Windows 3.1 alkalmazásokat, csak úgy, a magam szórakoztatására. Minél összetettebb lett az alkalmazás, annál könnyebb volt elveszni a call back függvények sűrűjében, és a felület tervezése sem volt egy leányálom. Amikor megismerkedtem a Visual Basicel, mindez megváltozott. A felületet megrajzoltam, a call backeket pedig egyszerűen hozzáfűztem a grafikus objektumokhoz.

Valami hasonló a Unity is. Egy szerkesztő programmal megtervezzük a színteret, beállítjuk annak tulajdonságait, az objektumokhoz pedig kódot rendelünk, ami bizonyos események hatására fut le. Mivel demó készítésre használnám, nem is kell olyan sok eseményt megjegyezni. A kocka nagyjából 5 perc alatt elkészült, egyetlen sor kód megírásával.

Akartam egy kicsit bonyolultabbat példát is látni, ezért kb. 10 perc alatt készítettünk egy kocka falat, amit egy golyóval leromboltunk. Ezt kód megírása nélkül tettük, a beépített fizikai motor segítségével. Impresszív volt. Lehet, hogy a jövőben teszünk egy próbát Unityvel.

Szóbakerült az is, mivel foglalkozom. Megszoktam, hogy többnyire nem is hallottak a tudományterületről, amivel foglalkozom, ezért meglepődtem, mikor azt hallottam, hogy mennyire dinamikusan fejlődik. Gyanakodni is kezdtem, hátha csak azért mondja ezt, mert ezzel akar bevágódni nálam, ezért ártatlanul visszakérdeztem: mégis miért fejlődik olyan dinamikusan?

- A személyre szabott gyógyászat miatt.

Hihetetlen, mikkel találkozom. Közben ment a SIDRip Alliance koncert, amit a túlzott hangerő miatt a termen kívül élveztem. Láttam Vickey átvedlett koncert-szerkóba és úgy táncolt. Majd ha lesznek fotók, mások is megnézhetik.

Kicsit megbomlott az időrend a leírásban, de a drámát akartam a végére hagyni. A demo compot. A demónk elég lassan indult, hála a sebtében portolt kódnak. Egyébként nem tudom, mitől lassú a betöltés, ezt majd egyszer kinyomozom. A hosszú betöltés egyébként a nézőket is megviselte, el is kezdődtek a bekiabálások. Más probléma nem volt, a demó szépen lefutott.

Volt még egy SIDRip Alliance demó is. Készült még egy Experience inivtáció is, valamint a Hardread Ouya-ra készített egy rövid bemutatót. Betasector egy Blender mester, ezért a Blender Game Enginnel készített egy demót. Van benne kocka is. Nagyjából ezután szabadult el a pokol. A sorrendre már nem emlékszem pontosan, de jött egy Brainstorm, egy Nazareth és egy Dead Roman demó. Közben a semmiből TLM, aki állítólag 20 éve scenerkedik 0 alkotással, most hirtelen úgy döntött, demót is készít. Meg kell hagyni, igen impozánsra sikeredett.

Ez a kívülállóknak nem sokat mondhat, ezért megpróbálom érzékeltetni, mi is történt. Képzeljük el, hogy elmegyünk valami családi futóversenyre. Tudjátok, amikor a 60 éves mami is rajthoz áll a kinőtt melegítőben, a kisgyerekek a rajtpisztoly dördülése után visszafelé kezdenek szaladni, stb. Most képzeld el, hogy rajthoz állsz egy ilyen versenyen, óvatosan jobbra nézel, és egy kenyai futó van ott, NASA által fejlesztett futócipőben. Balra nézel, ott van az olimpiai győztes. Elindultok, ezek ketten az élre törnek, majd hátulról előkerül a világcsúcs tartó, és elhúz mellettetek.

Mert ez történt. Ugyanis itt volt a Fairlight is. Mikor megláttam a kiírást, hogy ki következik, felkiáltottam:

- Mi jön még, ASD?

ASD nem jött. Mi utolsó előttiek lettünk, ami teljesen megérdemelt pozíció. Nem is érdemes több szót vesztegetni rá. De ha ezt tudom, biztosan nem heggesztek releaset péntek este. Az eredményhírdetésre felkelt a részeg kolléga, megkérdezte a szervezőket, hogy leadták-e a fotóját, de mire megláthatta volna, milyen helyezést ért el, ismét elaludt.

Szólj hozzá!

Címkék: demoscene parti riport

Valahol két lépcsőfok között

2013.09.08. 23:47 Travis.CG

A demó változó sebességgel halad. Két hete még úgy láttam, hogy nem lesz különösebb akadálya annak, hogy befejezzem az alkotást, de valami közbeszólt. Úgy hívják valóság. Rengeteg olyasmit kellett csinálnom, aminek semmi köze számítógépekhez, ettől a demóra fordítható idő nagyon lecsökkent. Még továbbra is úgy gondolom, hogy el fogok készülni, de szűkös a határidő.

A másik probléma, hogy úgy tűnik nem Linuxon fog futni. Az egész úgy kezdődött, hogy biztosítottak egy gépet, amiben egy Ati Radeon HD4850 teljesít szolgálatot. A hivatalos papír szerint a kártya ismeri az OpenGL 3.2-t. Már jó ideje 4-es verzióval foglalkozom csak, ezért nagy morogva átírtam a shadereket és a kódot 3.2-re. Igazából a nagy munka a layout-ok kiszedése volt, amivel meghatároztam, melyik vertex buffer tartalmazza a poligonok csúcsait, melyek a normálokat, illetve a textúrát. Én ugyanis szeretek minél több irányítást átadni a shadereknek, hogy a kód egyszerűbb legyen.

Ráadásul 32 bites Debiánt akarnak használni, ezért az egyszerűség kedvéért én is telepítettem egyet és azon fordítottam. Küldtem is egy félig kész mintadarabot a szervezőknek, hogy lássák, megy-e a compó gépen. Természetesen nem ment. Újabb levélváltások után a program hibaüzeneteit is megkaptam: nincs renderbuffer, nincs geometry shader, nincs semmi, ami egy kicsit is emlékeztetne arra, hogy már 2.1-nél magasabb OpenGL verziószámmal van dolgunk. A lehetőségek: odaadom nekik az én videokártyámat, de akkor azt party végéig nem látom. Elviszem az egész gépet, vagy fordítok Windowsra. Nincs kedvem cipelni semmi feleslegeset, ezért fordítok Windowsra.

A másik meglepetés az volt, hogy Grass készített egy pár modellt, de a textúrák egyes helyeken rosszul álltak. Mivel OBJ formátumot használunk (szöveges állomány), egy grep segítségével azonnal láttam, hogy a gond az, hogy több textúra koordináta van, mint csúcspont. Az OBJ betöltőm viszont úgy működött, hogy betöltötte a csúcspontokat, ezeket tekintette alapnak, és a textúra koordináták számát úgy állította be, hogy megegyezzen a csúcspontok számával. Itt viszont pont ellentétes volt a helyzet. A csúcspontok számát kellett megnövelni. A kód kijavítása után minden szépen jelent meg.

Még egy fontos adalék: a demóban lesz fraktál is.

A munka halad, még rengeteg tennivaló van és a valóság minden mesterkedése ellenére be fogom fejezni. (Vagy nem)

Szólj hozzá!

Címkék: demoscene

Keresztplatformos fejlesztés Amigához

2013.08.26. 22:08 Travis.CG

Bármennyire is jó egy alternatív platform, a rá való fejlesztés gyakran könnyebb egy PC-n, amit az ember gyakran használ. Ha a PC teljesítménye esetleg sokszorosa a másik gépnek, akkor érdemes elgondolkodni a keresztplatformos fejlesztésen.

Az Efika nem egy teljesítmény bajnok, de nem is ezért szeretjük. A rajta futó MorphOS fejlesztőkörnyezete GCC-t tartalmaz, amit hibái ellenére azért is szeretünk, mert szabadon elérhető a forrása és így ideális eszköz egy keresztplatformos fejlesztéshez.

Sajnos a helyzet nem ilyen egyszerű, ezt mindenki megmondhatja, aki próbált már kézzel fordítani GCC-t, binutils-t és a többi hozzá tartozó eszközt. Szerencsére a MorphOS fejlesztőcsapat adott ki egy szkriptet, amivel ezek a lépések nagyban leegyszerűsíthetőek. Sajnos dokumentáció nincs hozzá, ezért leírom, mit kell tenni, hogy ez a szkript lefusson. A teszteket Debian Wheezy 32 bites verzióján végeztem.

Valószínű 64 bites Linuxon is meg lehet oldani a feladatot, de sokkal bonyolultabban, ezért én 32 bites rendszert javaslok. Lássuk a hozzávalókat:

1db szkript: http://bigfoot.morphos-team.net/files/setup-cross-sdk.sh

4db utility: flex, bison, texinfo, lhasa

1db fordító: gcc 4.6

1db könyvtár a PATHban: /gg/bin (a könyvtárat nem kell létrehozni, csak a bejegyzést)

1db könyvtár: /gg

1 db MorphOS SDK és annak forrása: http://morphos-team.net/files/sdk-20130129.lha és http://morphos-team.net/files/src/sdk/sdk-source-20130129.tar.xz

Hozzunk létre egy tetszőleges könyvtárat, másoljuk bele a setup-cross-sdk.sh szkriptet, az sdk-t és az sdk forrását. Készítsünk egy gg könyvtárat a gyökérben, a chmod-al legyünk mi a tulajdonosai. Ne felejtsünk el írási jogot adni a könyvtárra.

Adjunk futási jogokat a setup-cross-sdk.sh szkriptnek, és indítsuk el. Hagyjuk fordítani negyed órán keresztül és végül elkészül a friss, ropogós keresztplatformos fordító. Tálaljuk a saját kényelmünket megkönnyítő symlinkekkel.

Szólj hozzá!

Címkék: programozás amiga

Cseppet sem objektíven: Assembly 2013

2013.08.19. 23:47 Travis.CG

Idén is összegyűltek a számítógépek szerelmese, hogy összemérjék erejüket különböző viadalokon. Volt robot párbaj, számítógépes játékok és természetesen demoparti is. Jelen poszt erről az utolsó mérkőzésről fog szólni.

Nekem a legnagyobb öröm, hogy látom visszatérni Maxont a HBC-ből, aki korábbi tevékenységéhez képest csak egy képpel jelentkezett, de nem kell elégedetlennek lenni. Most egy kép, később egy egész wild. Az erős mezőny miatt 13-ik lett. Nem csoda, hiszen igen komoly ellenfelekkel kellett megkűzdenie.

A zenék eddig nagyon tetszettek. A lejátszási listámban is túlnyomó többségében Assemblyről származó zenék vannak. Idén gyengébb volt a felhozatal, nem is fog bővülni a gyűjteményem. Számítottam valami kellemesre Aikapallotól, de csalódnom kellett. Maga a zene nem volt rossz, de hiányzott belőle a tűz.

A Tekotuotanto csapatról két dolgot kell tudni. Ez az egyetlen csapat, akinek csak másolni tudom a nevét, leírni nem. Kimondani pedig soha nem is próbáltam. A másik, hogy szinte csak wildot készítenek. Idén megpróbáltak egy 4k-t is, ami olyan jól sikerült, hogy elvitték vele az első helyet. Filmük ismét poénos volt, még ha nem is nevettem magam könnyesre. A robotos film is érdekes volt, talán lehetett volna ez az első.

Demók terén már nem láttuk azt a színvonalat, amit az előző években megtapasztalhattunk. Néhány demó annyira gyenge volt, hogy akár én is programozhattam volna. A nyertes Return nem volt rossz alkotás, de hiányzott belőle az összhang. A jelenetek valahogy nem alkottak egészet számomra. Fórumokon kifogásolták a nagy fájlméretet, mások az árnyékok hiányát. Szerintem ezeken az apróságokon túl lehet jutni, ha a bemutatott történet egészet alkot.

Természetesen agyatlan hardverekre tervezett demókból sem volt hiány. Az Androidra írt releasek szóra sem érdemesek, hiszen van rá SDK, fejlesztőkörnyezet, meg oktatási anyagok netszerte. Egy metró kijelzőn viszont még nem láttunk demót. Eddig.

Összességében az idei Assembly nem volt eget rengető. Volt néhány érdekes produkció, de nem tartom valószínűnek, hogy bármelyiket is megnézem másodszor.

Az alkotások megtekinthetőek itt és itt.

Szólj hozzá!

Címkék: demoscene

A női lélek

2013.08.15. 22:06 Travis.CG

Mi, férfiak nem sírunk. Legfeljebb akkor engedhetünk meg magunknak könnyeket, ha a szellemchilis szendvicsünket véletlenül wasabival öblítjük le, de ilyenkor is inkább azt mondjuk, hogy homok ment a szemünkbe. Nők esetében ez teljesen másképp van.

Nemrég három síró nőt is vígasztalhattam egy nap. Az első a kislányom volt, ennek megfelelően ez ment a legkönnyebben. Felvettem, simiztem egy kicsit és már meg is nyugodott. A második a feleségem volt, aki azért sírt, mert a gyerek sírt. Ölelés, simizés. Megmutattam, hogy már nem sír a gyerek, nincs semmi problémája. Nem, én sem tudom, mi volt a baja, de most már jól van.

Bár szabadságon voltam, azért bementem a melóhelyre, nehogy újabb 10000x10000-es képeket hozzanak létre, vagy más módon omlasszák össze az infrastruktúrát. Észrevettem, hogy az asszisztens nagyon szótlan. Mikor végeztem az adminisztrációval, megkérdezte, tudnék-e neki segíteni. Azt válaszoltam: igen.

Megbízták egy egyszerű feladattal, az UEA Small RNA Workbench különböző táblázatos eredményeit kellett volna összefésülnie. A feladat annyiból nem volt triviális, hogy a két táblázat közös metszete a kisRNS-ek szekvenciái voltak.

Mondtam neki, hogy vannak patman futásból eredményeim, amiket felhasználhat. A patman produkálja a legprimitívebb illesztési eredményt, amit valaha láttam: kereső szekvencia azonosíója, találat, orientáció, illesztés kezdete, illesztés vége, eltérések száma. Mindezt tabulátorral elválasztva.

- Azokat nem tudom használni. Hogyan dolgozzam fel a fájlokat? - itt kezdtek folyni a könnyei.

- Írsz egy Perl szkriptet. A split paranccsal kinyered az oszlopokat...

- Én nem tudok Perl-ben programozni, csak Bash-ban.

- Semmi gond, awk-al kinyered az oszlopokat és grep-el megkeresed a másik táblázatban a hozzá tartozó értéket. Kicsit lassabb lesz, mintha Perl-ben csinálnád, de működni fog.

Ezután nagy sírás közepette elmondta, hogy úgysem lesz jó, mert őt mindig csak bántják, mert elront dolgokat. Ráadásul ideje sincs rá, mert még két másik dolgot kellene csinálnia.

Amennyire tőlem telt, elmondtam, hogy a hibák felderítése az akadémia világában nem személyes ügy, hanem a megismerést szolgálja. Mindannyian hibázunk, de ha mások rámutatnak erre, akkor igyekezzünk tanulni belőle, és ne személyeskedésnek vegyük.

Úgy tűnik, a mondandóm nem segített. Másnap írt a főnökének, hogy a feladatot nem tudja megcsinálni, és csinálja meg vagy ő, vagy valaki más.

Szólj hozzá!

Címkék: életmód

Lépcsőforduló ama magaslathoz...

2013.08.04. 09:36 Travis.CG

Gondos tervezés, precíz időbeosztás, megfeszített munka. Ezek szükségesek, hogy időben elkészüljön egy demo a kitűzött partira. Amennyiben bármelyik is hiányzik, jön a tartalék terv. Esetleg a tartalék terv B változata. Az ütemtervet figyelve és Grassal beszélve úgy láttuk, hogy nem fog Function-re elkészülni a várva várt produkció. Üres kézzel mégsem mehetünk, ezért nekiláttunk ötletelni, mi az, amit meg is tudunk valósítani és nem is tűnik összecsapottnak.

Első lépésben kiválasztottam a zenét Shamen DVD-jéről. Már korábban összeírtam azokat a zenéket, amelyek elindítottak bennem valamilyen képzettársítást, most csak meg kellett keresnem, mert a címére nem emlékeztem. Egyhuzamban meghallgattam 4-5 ször, hogy teljesen átérezzem és kialakuljanak valami homályos képek arról, mit is akarok látni.

Az új produkcióhoz az Antagonism motorját fogom felhasználni, mert jelenleg ez a legfejlettebb kódom. Továbbra is hiányzik belőle egy csomó funkció, de mi nem is vagyunk főállású játékengine fejlesztők. A kódból kipucoltam az ottmaradt teszt kódokat, majd áttekinthető formára hoztam. A GTK és egyéb könyvtárak fejlődtek egy keveset az elmúlt időszakban, ezért eltűntettem a sok fordítás során keletkező figyelmeztetést. Beépítettem a zenét, és élveztem, hogy a fekete képernyő ellenére van "valami".

Cinema4D-vel modelleztem egy hangyát, amit Grass feltextúrázott. Ő további modelleket is készített. A demómotor OBJ formátumot használ, így ebbe exportáltam a modelleket. Itt jött az első hidegzuhany. A teljes jelenet egyetlen modellbe került, a modelleket összemosta. Sajnos ez nem jó nekem, mert az egyes modellekre különböző effekteket akarok pakolni.

A kísérleti állapotban lévő és a nagyratörő Cybernetic Export Plugin nevet viselő bővítményt elkezdtem kiegészíteni egy olyan funcióval, hogy minden modellt külön fájlba írjon ki. Ez részben sikerült is, de egy számomra ismeretlen erő hatására bináris szutykot ír minden string elejére. Ezt majd meg kell oldani.

Közben rájöttem valamire. A demoscene 30-on túl már elsősorban nem is arról szól, hogy csináljunk valami eget rengetőt. Inkább arról, hogyan tudjuk úgy szervezni az életünket, hogy jusson idő erre a hobbira. Talán ez sokkal nagyobb művészet, mint megírni a világ legjobb demomotorját.

Szólj hozzá!

Címkék: demoscene

Woops

2013.08.04. 09:19 Travis.CG

Ajánlottak nekünk egy egyetemi hallgatót, akinek a "második nyelve a programozás", hogy a nyári gyakorlatát nálunk töltse. Segítene nekünk a mindennapi feladatok megoldásában. A beszélgetések során értelmes ember benyomását keltette, aki dolgozott többek között a Mol-nál is. Volt néhány megvalósítandó ötletem, ezért elvállaltam a felügyeletét és azt, hogy készítek neki egy munkatervet, de a mindennapi ügyek mellett ennek jó része elmaradt.

Még két hét volt vissza az érkezéséig, amikor szóltak nekem, hogy vegyem fel vele a kapcsolatot, mert ha mi nem csapunk le erre a zsenire, akkor máshova megy dolgozni és akkor mi egész életünkre sajnálhatjuk az elszalasztott lehetőséget. Ráaásul a bérezését is meg kell beszélni. Állj! Pénzt kap? Javasoltam, hogy ez esetben teszteljük le, mire is képes. Természetesen a napi robot mellett a tesztelés elmaradt. (Woops)

Levélben megkérdeztem tőle, hogy milyen programozási nyelven szeretne dolgozni, milyen statisztikákat és algoritmusokat ismer. Azt írta, hogy C-ben szeretne kódolni, statisztikát alig ismer és például a hashekről még nem is hallott. Ez már kicsit gyanús volt, de gondoltam, majd itt megtanulja, amit kell.

Mivel eddig Windows alatt ügyködött, kapott egy gyorstalpalót Linux fejlesztésből. Mikor láttam, hogy ez nehéz lesz neki, kapott Midnight Commandert, KDevelopot, hogy ne érezze annyira egyedül magát a "Déli Sarkon", a pingvinek között.

Az első meglepetés akkor ért, amikor nem tudta, micsodák azok az include részek a C program elején.

- De megkérdeztem tőled, miben akarsz programozni? Azt mondtad, hogy C-ben.

- Én azt úgy értettem, milyen programozási nyelvekről hallottam. Pascalban programoztam (Woops), meg PLC-ben.

- Mi az a PLC? Még nem hallottam róla.

- Folyamatábrákon keresztül lehet programot írni. Össze kell kötni négyzeteket és abból lesz a program.

- Mint a Lego Mindstore-ban?

Végül is gyorsan belerázódott, a végén már a pointereket is értette, de valami megmagyarázhatatlan okból kifolyólag csak és kizárólag hátul tesztelős ciklusokat írt. Azt gondoltam, talán nem ismeri a for ciklust, de nem erről volt szó. Tulajdonképpen a maga nyakatekert, függvények nélküli, beégetett sztingekkel operáló kódjaival minden rá bízott feladatot megoldott, csak rossz volt nézni (meg debuggolni, mert azt többnyire én csináltam).

Nyár lévén én is szabadságra akartam menni, és sokat gondolkodtam azon, milyen feladatot adjak neki, amit a jelenlétem nélkül is tud végezni. Vagy legalábbis meg tudja keresni a választ a felmerülő kérdésekre. Ekkor gondoltam először a Java-ra. Nincsenek furcsa pointerek, nem kell a memóriaszivárgás miatt aggódni, ráadásul a net tele van a legtipikusabb Java hibák megoldásával. Az Eclipse pedig olyan, mint egy pelenka. Bármi kerül bele, megbírkózik vele. És itt nem csak a kék tintára gondolok.

A másik ok, ami miatt a Java mellett döntöttem, hogy egy olyan alkalmazásra volt szükség, ami képet generál, lehetőleg keresztplatformos módon. Már volt Java kódom, ami png-t generált, ezért azt is odaadtam, amolyan súgónak.

Fél nap elteltével szólt, hogy nem jelenik meg semmi, pedig ő mindent leírt, amit a kódomban talált. A rutin ránézésre tényleg jól volt megírva.

- Meghívod ezt a metódust? - mutattam a az egész program lelkét képező rajzoló rutinra.

- Persze, itt van. - ott viszont egy másik osztály metódusa volt, ugyan ilyen névvel. Kiderült, mikor valami hibát talált az Eclipse, az első javítási opcióra klikkelt annak elolvasása nélkül, ami a hiányzó metódus elkészítése volt. Nemsokára üres metódusokkal volt tele minden osztálya. Miután kigyomláltam a szemetet, már futott a program, készített png fájlt. De mikor meg akartuk nézni a végeredményt, a gép váratlanul lelassult, nekiállt swappelni. A halálán volt.

- Mekkora ez a kép? - kérdeztem, miután az egérmutató ismét mozgott a képernyőn.

- 10000 x 10000. Az nagynak számít?

- Nem szoktál letölteni képeket a netről? A nyolc megapixeles képek 3264 x 2448 felbontásúak. A képernyő, amin dolgozol, 1024 x 768-as.

Rámnézett, mint akinek ezek a számok továbbra sem mondanak semmit és csak ennyit mondott:

- Woops.

2 komment

Címkék: programozás

Kalandok a magyar szuperszámítógépekkel

2013.07.24. 22:18 Travis.CG

Az egyik nagy előnye, hogy az ember akadémiai kutatócsoport tagja, hogy hozzáférhet a NIIF szuperszámítógépeihez. A papíron leírt impozáns teljesítmény mutatók azonnal megdobogtatják egy magamfajta felhasználó szívét. Sajnos az örömbe sok üröm is keveredik, ha a tényleges felhasználásra kerül sor.

Regisztráció

A regisztrációs procedúra sokat egyszerűsödött, de márciusban, mikor a saját kérvényemet intéztem, ez kétfordulós meccs volt. Először projektszámot kellett igényelnem. Kitöltöttem egy papírt, aláírattam minden főnökömmel, akik igazolták, hogy én tényleg létezem, és tényleg kutató vagyok. Ezután még egyszer kitöltöttem egy nagyon hasonló papírt, ahol témaszámot igényeltem. A procedura nagyon hasonló volt. Kellett generálni egy ssh kulcsot és már kész is voltam.

Programok

A szuperszámítógépek használata hasonlít egy batyus lakodalomra: Étel-ital lesz elég, ha hoztok magatokkal. Szoftver lesz elég, ha fordítasz magadnak. Ez nem olyan problémás, egészen addig, amíg nem a függőségek függőségeit kell fordítani. Utána kicsit unalmassá válik. Én a Mira-t akartam futtatni, ezert felmásoltam egy statikusan linkelt binárist és azt használtam. Illetve próbáltam használni.

Üzemidő

Memória gondjaim voltak, ezért akartam a pécsi szuperszámítógépen dolgozni, de csak a kínlódás volt vele, ugyanis lépten-nyomon elérhetetlen volt a gép és a futó programok pedig elszálltak. Visszanéztem az ezzel kapcsolatos e-mailjeimet és az alapján készítettem ezt a grafikont:

leallas.png
Egy hetet nem tudott folyamatosan menni a pécsi gép. Szerintem annak idején a Windows 95 jobban teljesített, nem? Áttértem a szegedire, ahol viszont nem jutottam sorra. (Illetve az egyik kiesés alkalmával csak a futó jobok szálltak el, a várakozási sor nem ürült, amitől az élre tudtam törni). A másik igencsak frusztráló dolog a jobütemező, ahol az idő folyamán egyre több korlátozást vezettek be. Egyik alkalommal nem voltam elég figyelmes és a job futásának hosszabb időt adtam meg, mint amennyi a felső határ volt. Nem kaptam hibaüzenetet, nem kaptam figyelmeztetést, semmit. Annyi tűnt fel, hogy van üres node, de én továbbra is a várakozási sorban dekkolok.

Mikor végre sorra kerültem, gyanúsan lassan futott a Mira. Rövid nyomozás után kiderítettem, hogy a félelmetes memória, CPU és sávszélesség mellett az IO műveletek röhejesen lassúak. (Emlékeztetőül: A bioinformatikai programok nagy fájlokat olvasnak és írnak). Álljon itt egy cseppet sem mélyreható, gyors tesz, mire is képesek a szuperszámítógépek:

számítógép olvasás írás
szeged 75,4 4,7
deb 204 8,8
munkaállomás 96,1 11
otthoni 66,1 15,1


A tesztet a jó öreg dd-vel csináltam:

dd if=/dev/urandom of=fajl # iras teszt
dd if=/dev/sda of=/dev/null # olvasas teszt

A teszt nem túl szofisztikált, de a célnak megfelel (meg nem ártott volna néhány ismétlés, de annyit nem ér az egész). A deb egy nagyteljesítményű számítógép, ami nem a NIIF tulajdonában van.

Végszó

Sajnos semmi hasznosat nem tudtam kezdeni a hazai szuperszámítógépekkel. Végül úgy végeztem el a munkát, hogy lecsökkentettem a readek számát, hogy beleférjen 70GB memóriába, majd lefuttattam egy erre alkalmas gépen.

3 komment

Címkék: rendszergazda bioinformatika

Prezentáció Efikán

2013.07.10. 22:39 Travis.CG

Amigát régen nem csak játékra használták, hanem munkára is. Annak ellenére, hogy mára ez a gép főleg hobbi célokat szolgál, akadnak fanatikusok, akik munkájukhoz is valamilyen Amigát, vagy újgenerációs leszármazottjainak egyikét használják.

Ilyen például LaySoft, aki PHP programozóként dolgozik, de a kódot MorphOS-en gépeli be, vagy Lázi, aki OS4 alatt Hollywooddal állít elő multimédiás tartalmakat. Ha nem is napi szinten, de nemrég én is munkára fogtam az Efikát.

Beszámolót kellett tartanom és a nagy nyári szabadságolás miatt nem tudtam szerezni laptopot. (Az igazsághoz hozzátartozik, hogy ha nagyon akartam volna, tudtam volna szerezni, de abból nem születik blogposzt.) Végül úgy döntöttem, az Efikára átmásolom az anyagot (néhány R-ben készült két volt az egész), majd bemutatom.

Az adatátvitel gond nélkül ment, mert MorphOS alatt van OpenSSH kliens, és bár van grafikus program hozzá, közönséges parancssorból is megy. A rendszergazda, aki a projektorért is felel, hitetlenkedve nézte, amint a VGA kábelt egy kis, fekete dobozhoz kötöm.

- Mi ez? - kérdezte. Csak egyet felelhettem rá.

- Számítógép.

efikaprezi.jpg

Szólj hozzá!

Címkék: amiga

Don Emeritus és a szívesség

2013.07.03. 20:47 Travis.CG

A csoportvezető belépett a gyéren megvilágított irodába. A bútoroknak pont olyan áporodott szaga volt, mint hallgató korában. El gondolkodott rajta, bizonyára az az anyag, ami ilyen szagot bocsát ki, egyben tartósítja Don Emeritust is. Ez teszi lehetővé, hogy míg lediplomázott, elvégezte a PhD-t, csoportvezető lett az intézetben, addig Don Emeritus ugyan úgy ül itt, túl a nyugdíj korhatáron és kíméletlenül ontja a cikkeket, dönt pályázatok és kutatócsoportok sorsáról.

- Beszélni szerettél volna velem! - kezdte Don Emeritus. Kevés ideje volt, nem vesztegette udvarias fecsegésre.

- Igen, Don Emeritus - kezdte a csoportvezető, olyan hangon, mintha kollokviumra készülne. Maga is észrevette ezt. Megköszörülte a torkát, és sokkal magabiztosabban folytatta. - Kihagytak a bíráló bizottságból, amelyik dönt az új szuperszámítógép beszerzéséről. Csupa matematikus és agrármérnök alkotja, akik nem tudják, mire van szüksége egy bioinformatikusnak.

- Agrármérnökök? Ismered őket? - Don Emeritus lenézte más tudományterületek képviselőit, de az agrármérnökök számára nem is voltak tudósok.

- Gáspár Tamás, Hornay Béla...

- Hallottam róluk. Gyalázatos, alacsony impaktfaktorú cikkeket közölnek genetika címen. Egyetlen modern metódust sem ismernek. Számukra a genetika kimerül a szatelliták elemzésében.

- Ahogy mondod! Ugyanígy le akarják zülleszteni a bioinformatikát is.

- Mit akarsz, mit tegyek?

- Nyomást kellene gyakorolni rájuk.

- Hmm, Gáspár Tamás közös pályázatban van az egyik volt tanítványommal, aki azóta volt kint Németországban. Béla intézetének meg Toldai Zsolt a vezetője. Ő szinte már családtag, a lányom sógorának az unokatestvére. De ha beszélek velük, tisztában kell lenniük minden részlettel. Tudsz valakit még rajtad kívül, aki ért annyira a témához, hogy a bizottság tagja lehetne?

- Senki más! - gondolta a csoportvezető, de idejében visszafogta magát. - Vannak még egy páran...

- Értem - jegyeztem meg sokat sejtetően Don Emeritus. - Kérlek írd össze pár szóban a javaslataidat. Tudod, sok hasonló szívességnek kell eleget tennem. Van egy külön mappám rá.

1 komment

Címkék: irodalom

OpenCV 3. rész

2013.06.30. 00:03 Travis.CG

Elérkeztünk OpenCV-t bemutató sorozatunk utolsó részéhez. Itt csak példákat szeretnék mutatni, mire is lehet használni ezt a programozói felületet. Sajnálatos módon az OpenCV C és C++-os felületei között jelentős különbségek vannak, ami abban is  megnyilvánul, hogy ha C++-ban programozunk, több algoritmust használhatunk. Ebben a fejezetben ezért csak C++-os példaprogramok lesznek.

Kontúr keresés

Első példánkban igyekszünk meghatározni egy képen a kontúrokat. A kontúr kereséshez a Canny metódust használjuk. Bemenetnek egycsatornás, 8 bites képet kell adnunk. A példaprogramban nem csak a képet jelenítjük meg, hanem két GUI elemet is, amivel az algoritmus paramétereit állítgatjuk. Az élkeresés hatékonyságát Gauss elmosással növeljük.

#include <opencv2/opencv.hpp>

using namespace cv;

int main(int argc, char **argv){
  Mat raw, gray;
  VideoCapture capture(0);
  bool run = true;
  int tb1 = 129, tb2 = 233;

  namedWindow("Edge", 0);
  createTrackbar("Tb1", "Edge", &tb1, 1000,0);
  createTrackbar("Tb2", "Edge", &tb2, 1000,0);

  while(run){
     capture >> raw;
     cvtColor(raw, gray, CV_BGR2GRAY);
     GaussianBlur(gray, gray, Size(7,7), 15, 15);
     Canny(gray, gray, tb1, tb2, 5, true);
     imshow("Edge", gray);
     if(waitKey(30) >= 0) run = 0;
  }

  return(0);
}

A GUI készítésénél vegyük észre, hogy minden elemet stringekkel azonosítunk és ugyancsak stringek segítségével határozzuk meg, melyik ablakon jelenjen meg. Ebben a példában csak egy ablakot hozunk létre "Edge" néven.

Háttér eltávolítás

Míg az előző példát akár C-ben is megírhattuk volna, ez a példa már olyan elemeket használ, amit csak C++-ban érhetünk el. A program megpróbálja a nyers képen elkülöníteni a hátteret az előtértől. Az előteret ezután elmentjük egy maszkba, amit felhasználunk arra, hogy a nyers képből az előteret átmásoljuk egy másik háttér elé. Ez a másik háttér egy időjárás térkép lesz. (Figyeljünk rá, hogy a webkamera képe és az új háttér ugyanolyan méretű legyen, mert a programban nincs méret korrekció.)

A háttér elválasztása nem működik teljesen pontosan, ez a program nem fog olyan minőséget produkálni, mint amit a TV csatornáknál megszokhattunk. Javaslom, hogy miután elindítottuk a programot, várjunk 5-10 másodpercet, mielőtt a kamera elé sétálunk, ennyi kell ugyanis, hogy "megtanulja", mi a háttér. A backgroundRatio mező segítségével állíthatjuk be, mennyire legyen az algoritmus precíz és gyors. Az árnyékok ugyancsak zavarhatják az algoritmust. Elméletileg az árnyékokat is felismeri, gyakorlatban nálam nem működött rendesen. A példaprogram paramétereivel játszunk nyugodtan.

#include <opencv2/opencv.hpp>

using namespace cv;

int main(int argc, char **argv){
  Mat raw, mask, background;
  VideoCapture capture(0);
  bool run = true;
  BackgroundSubtractorMOG2 subtract;

  subtract.nmixtures = 3;
  subtract.backgroundRatio = 0.01;
  namedWindow("Forecast", 0);
  // the image should be the same size as the cam image
  background = imread("magyarorszag.jpeg", CV_LOAD_IMAGE_COLOR);

  while(run){
     capture >> raw;

     // Create mask
     subtract.operator ()(raw, mask);
     erode(mask, mask, Mat());
     dilate(mask, mask, Mat());
     threshold(mask, mask, 40, 255, THRESH_BINARY);
     // use mask to substract foreground
     Mat tmp = background.clone();
     raw.copyTo(tmp, mask);
     imshow("Forecast", tmp);

     if(waitKey(30) > 0) run = 0;
  }

  return(0);
}


A példaprogramhoz felhasznált hátteret ide töltöttem:magyarorszag.jpegObjektum követés

Legvégére hagytam azt a programot, ami elindította ezt a sorozatot: Aha kiváltását. A feladat tehát az, hogy több képkockán keresztül követni kell két elemet, jelen esetünkben két kezet. Azért, hogy megkönnyítsük a dolgunkat, feltűnő színekkel jelöljük a követendő objektumokat. Ezután kiszűrjük csak ezt a színt és egy k-közép klaszterezéssel megállapítjuk a ponthalmaz közepét. Ha minden feltétel megfelelő, a klaszterek közepe a követni kívánt objektumokkal meg fog egyezni.

Mi ez a k-közép klaszterezés? Ez, mint a neve is mutatja, az adathalmazok csoportosítására használható. Az adathalmazoknak számszerű tulajdonságokkal kell rendelkezniük, ami a mi esetünkben a koordináták lesznek. Hátránya, hogy előre meg kell mondanunk, hány csoportra akarjuk bontani az adatainkat. A mi esetünkben ez nem probléma, mert tudjuk, hogy jó esetben két keze van az embernek. Az algoritmus ezután véletlenszerűen valamelyik csoportba osztja az adatokat, majd a kiszámolja a csoport középpontját (veszi a koordináták átlagát, innen a neve), majd megnézi, hogy más csoportból van-e közelebbi pont. Ha van, ez a pont is része lesz a csoportnak, és kezdődik egy új ciklus. Ha minden jól megy, ciklusról ciklusra egyre közelebbi pontok lesznek egy csoportban. Ha viszont zajos az adatunk, vagy rosszul választjuk meg a klaszterek számát, furcsa eredményeket kaphatunk. (Ahogy a bemutató videón is látni lehet majd)

Az algoritmus része az OpenCV-nek, ezért nem kell leprogramoznunk. Lássuk a kódot:

#include <opencv2/opencv.hpp>

#define CLUSTERNUM 8

using namespace cv;

int main(int argc, char **argv){
  Mat raw;
  Mat labels, centers(CLUSTERNUM, 2, CV_32FC2);
  VideoCapture capture(argv[1]);
  bool run = true;
  int lb1 = 0, lb2 = 100, lb3 = 100;
  int hb1 = 64, hb2 = 255, hb3 = 255;

  // Create windows
  namedWindow("Param", 0);
  namedWindow("Aha", 0);
  namedWindow("Filt", 0);
  createTrackbar("lb1", "Param", &lb1, 255, 0);
  createTrackbar("lb2", "Param", &lb2, 255, 0);
  createTrackbar("lb3", "Param", &lb3, 255, 0);

  createTrackbar("hb1", "Param", &hb1, 255, 0);
  createTrackbar("hb2", "Param", &hb2, 255, 0);
  createTrackbar("hb3", "Param", &hb3, 255, 0);

  while(run){
     capture >> raw;
     Mat filtered(raw.size(),CV_8U);
     inRange(raw, Scalar(lb1, lb2, lb3), Scalar(hb1, hb2, hb3), filtered);
     Mat dummy(filtered.rows * filtered.cols,2,CV_32F);
     int z = 0;
     for(int x = 0; x < filtered.rows; x++){
        for(int y = 0; y < filtered.cols; y++){
           if(filtered.at<uchar>(y,x) == 255){
              dummy.at<float>(z,0) = x;
              dummy.at<float>(z,1) = y;
              z++;
           }
        }
     }

     Mat points = dummy(Rect(0,0,2,z)); /* Reduce the image */

     // If the picture do not contains enough points, we can not make kmeans clustering
     if(z > CLUSTERNUM){
        kmeans(points, CLUSTERNUM, labels, TermCriteria(CV_TERMCRIT_EPS + CV_TERMCRIT_ITER, 10, 1.0), 3, KMEANS_PP_CENTERS, centers);
        for(int i = 0; i < CLUSTERNUM; i++){
           Point ipt = centers.at<Point2f>(i);
           circle(raw, ipt, 20, Scalar(0,0,255), CV_FILLED, CV_AA);
        }
     }

     imshow("Aha", raw);
     imshow("Filt", filtered);
     if(waitKey(30) >= 0) run = 0;
  }

  return(0);
}

A videóról beolvassuk a képkockákat, majd az inRange segítségével kiszűrjük azt a színtartományt, amire szükségünk van. A tartományok beállításához (minden színcsatornához egy tartományt lehet beállítani) a createTrackbar segítségével grafikus elemeket hozunk létre.

A kmeans parancs egy speciális mátrixot vár bemenetnek, ezért a szűrt képünket (filtered) ezekkel az ocsmány egymásba ágyazott ciklusokkal kell átalakítani. Ha erre valaki tud egy szebb módszert, az ne fogja vissza magát. De hogyan is néz ki ez a speciálist mátrix? Mindenképp CV_32F típusúnak kell lennie, és minden egyes sorban az adathalmaz egy elemének kell szerepelnie. (Tehát annyi sorunk lesz, ahány adatunk) Mivel a mi esetünkben két tulajdonsága van az adatoknak (X és Y koordináta), ezért a mátrixnak két oszlopa van.

A kmeans eredménye a centers változóban lesz. Utolsó lépésként megjelenítjük ezeket piros pöttyökkel. A lefordított program működés közben:

Remélem sok szép demó fog születni OpenCV felhasználásával.

Szólj hozzá!

Címkék: programozás opencv

Szadizzunk középiskolásokat, akik szeretik a biológiát

2013.06.20. 22:57 Travis.CG

Szerettem a tanulmányi versenyeket. A legtöbb meghírdetett versenyre elmentem, bár soha nem jutottam túl az iskolai fordulón. Nemrég megkért az egyik prof, hogy segítsek egy gimis srácnak felkészülni az IBO országos fordulójára.

Én csak az OKTV-ről hallottam, az IBO-ról soha, ezért elkezdtem némi információt gyűjteni róla. El is jutottam a régi feladatlapokhoz, és kíváncsian belelapoztam. A harmadik feladat után rá kellett jönnöm, hogy diploma, doktori ide vagy oda, ezen a versenyen bizony elvéreznék.

A gyakorlati résznél (mert ilyen is van) már határozottan ideges lettem. A versenyzőknek adnak mikroszkópot, tűt, szikét és egyéb kínzóeszközöket, felboncoltatnak velük valami bogarakat, majd papíron rajzolják fel a dögök törzsfáját UPGMA módszerrel. Ez még nem tűnik annyira vészesnek, de nem ártana némi ismétlés. Utána ugyan ezt el kell játszani néhány növénnyel, de a változatosság kedvéért Neighbor-joining módszerrel rajzoljanak törzsfát. Menjetek a fenébe - gondoltam. Mikor a végén valami koevolúciót kellett nézni a dögök és a gazok között, akkor döntöttem úgy, hogy ebből elég.

A felkészítés során a statisztikáról kellett beszélnem, amihez felhasználtam néhány Coursera-s kurzuson hallott példát, mert ott néha nagyon jól megvilágítják az okokat, míg a hazai oktatásban csak rálöncsölik a hallgatókra a képleteket, fogalmakat. Mint kiderült, ez jó ötlet volt.

Gondoltam faggatom kicsit a versenyről. Mint kiderült, ez egy elitista verseny, aki nem jutott tovább az OKTV második fordulóján, azt meghívást sem kap. A srác elmondta, hogy az a stratégiája, hogy olyan gyorsan végigmenni a teszteken, amennyire csak lehet, és csak arra válaszolni, amit gerincvelőből is tud. A gondolkodást a végére hagyja. Ha marad ideje, akkor alszik egy kicsit, de fél, hogy nem jut rá ideje, mert nagyon sok feladatot kapnak.

Kérdeztem tőle, miért kell aludni? Azt mondta, hogy a teszt után (ami három órás), este nyolc órakor lesz a gyakorlati rész, újabb két, két és fél óra hosszan. Este? Miért? Azért, hogy az állóképességet is igénybe vegyék.

Összegezzük: Van egy kegyetlenül nehéz feladatsor, amire egy átlagos középiskolásnak esélye sincs felkészülni. Ennek a srácnak is a fél kutatóintézet segített a felkészülésben. Ezekből a feladatokból adnak sokat, de azért nem kapnak annyi időt, hogy minden beleférjen. Az időpontot pedig úgy állítják be, hogy lehetőleg baromi fáradtak legyenek. Kérdem én, ennek mi értelme?

Az Olimpián sem látunk olyat, hogy az úszókat lovagpáncélba öltöztetik, mert ők már annyira profik. Kíváncsi lennék mit szólnának a 100 méteres síkfutás döntősei, ha rekortán helyett mondjuk folyós homokban küzdhetnének az aranyért.

De az is lehet, hogy én gondolom rosszul és ez a verseny kicsit másmilyen, ehhez hozzátartozik a "megperzselt föld".

Szólj hozzá!

Címkék: életmód

Cinema4D bővítmény fejlesztés (2. rész)

2013.06.16. 22:56 Travis.CG

Itt az ideje, hogy kicsit jobban nekiugorjunk és létrehozzuk első saját bővítményünket. Először egy kis elméleti tudnivaló következik, majd kódolhatunk is.

Könyvtárszerkezet

A bővítményünknek a Cinema 4D plugins könyvtárában kell lennie egy új alkönyvtárban. Itt fog majd elhelyezkedni a lefordított bővítmény. Rajta kívül egy res könyvtárra van még szükség, ami nevéből következően az erőforrásokat tartalmazza. Mik is ezek az erőforrások? Ikonok, többnyelvű szövegek, dialógus ablakok. Az ikonok, mint ahogy a példa kódnál is megfigyelhető, egyszerűen a res könyvtárban vannak. A fejléc állományok a descriptions alkönyvtárban vannak. A dialógus ablakok megjelenítéséhez a dialogs könyvtárba kell elhelyezni az erőforrásokat. A többnyelvű szövegek a strings_nyelv-ben kapnak helyet, ahol a nyelv a következő lehet: us, de, jp, fr, it, es.

Bővítmény típusok

A Cinema 4D bővítményei hurok típusúak, ami annyit tesz, hogy a kódunk a program futásának bizonyos eseményei során futnak le. Ilyen esemény lehet egy menüelem kiválasztása, egy jelenet renderelése vagy az exportálás. Lássuk, mik lehetnek ezek:

  • Parancs plugin: Egy menüelem kiválasztásakor aktiválódik.
  • Jelenet export: Új formátumba menthetjük a jelenetet
  • Jelenet import: Eddig ismeretlen fájlt építhetünk a jelenetbe
  • Kép export: Bitkép mentése
  • Két import: Bitkép betöltő
  • Tulajdonság plugin: Az objektumok új tulajdonságot kaphatnak segítségével
  • Eszköz plugin: Új eszközt adthatunk a Cinema 4D-hez
  • Modellező plugin: Új objektum módosító eszközt hozhatunk létre vele
  • Animációs plugin: Egyedi idősávot hozhatunk létre
  • Shader plugin: A megjelenítést módosíthatjuk vele
  • Jelenet plugin: A jelenet újrarajzolásánál aktiválódik
  • Video render plugin: A renderelésnél hozhatunk létre különböző effekteket
  • Üzenet plugin: Más bővítmények üzeneteit dolgozhatjuk fel vele
  • Csomópont plugin: Új csomópontot vehetünk fel vele
  • Egyedi GUI elem: Új grafikus elemet hozhatunk létre
  • Egyedi adattípus: A beépített adattípusokat egészíthetjük ki

Regisztráció

Minden bővítmény egy egyedi számmal rendelkezik. Egyedi számunkat a Maxontól kell igényelni. Az itt bemutatott bővítmények csak egy hasraütött számot tartalmaznak, tehát előfordulhat, hogy már regisztrálva vannak. Ha nem használunk más bővítményeket, akkor nem kell aggódnunk, hogy esetleg konfliktusba kerülünk más bővítményekkel, de ha az a tervünk, hogy kereskedelmi forgalomba értékesítjük, mindenképp egyedi azonosítóra lesz szükségünk.

Forráskód

Bizonyára ez a rész érdekel mindenkit. Minden bővítmény három függvényt tartalmaz: PluginStart, PluginEnd, PluginMessage.

#include "c4d.h"

Bool RegisterCGMenu();

Bool PluginStart(void){
        if(RegisterCGMenu() == FALSE) return FALSE;
        return TRUE;
}

void PluginEnd(){
}

Bool PluginMessage(LONG id, void *data){
        return FALSE;
}

A regisztrációt a PluginStart függvényben végezzük. Ha a regisztrációs sikeres, a bővítmény működni fog, ellenkező esetben kilép.

#include "c4d.h"

class CGMenu : public CommandData{
public:
        virtual Bool Execute(BaseDocument *doc);
};

Bool CGMenu::Execute(BaseDocument *doc){
        MessageDialog("My First Plugin");
        return true;
}

Bool RegisterCGMenu(){
        return RegisterCommandPlugin(1001999,"Hello World",0,AutoBitmap("cg.tiff"),String("hello"),gNew CGMenu);
}

Ez egy parancs plugin, amit a szülő osztály típusából állapíthatunk meg (CommandData). Egyetlen virtuális metódust tartalmaz, a parancs végrehatjását. Jelen pillanatban csupán egy üzenet ablakot jelenítünk meg egy egyszerű szöveggel. Végezetül a regisztráció mechanizmusát látjuk. Megadjuk az azonosítót, a menüben látható nevet, a bővítmény néhány tulajdonságát,  az ikont, a tooltip nevet, legvégül az osztályt, amit regisztrálni kívánunk.

Ha elkészítettük első bővítményünket, kísérletezzünk bátran a paraméterekkel. Nézzük meg a dokumentációban, mit jelentenek, majd tapasztaljuk ki hatásukat.

Szólj hozzá!

Címkék: programozás demoscene

Cinema 4D bővítmény fejlesztés (1.rész)

2013.06.04. 22:07 Travis.CG

Bármilyen gondosan is fejlesztenek egy eszközt, mindig lesznek olyan funkciók, amelyeket a program nem fog támogatni. Halmozottan igaz ez olyan igények esetén, amire csak kevés embernek van szüksége. A demoscene pont ilyen. Kevés ember mozog benne, és nagyon speciális igényeik vannak.

Szerencsére a komolyabb alkalmazások támogatják, hogy a programozástól nem idegenkedő emberek az igényeiknek megfelelő bővítményekkel lássák el azt. Mai célunk a Cinema 4D demofejlesztő eszközzé alakítása lesz. (Folytatásos teleregény formájában). Az itt leírtak a 13-as verzióval való ismerkedésem folyamán születtek.

A program telepítése során a plugins könyvtárban van egy példa könyvtár (cinema4dsdk). Ha nem akarunk órák hosszat konfigurálni, akkor ezt a könyvtárat használjuk alapnak és más néven hozzuk létre a másolatát ugyan ide. (Tehát a CINEMA 4D R13\plugins könyvtárba.) Ha nem így teszünk, akkor a számtalan relatív elérési út miatt órákon át konfigurálhatjuk a projektet. (És jó eséllyel kudarcot is vallunk. Én megpróbáltam)

A cinema4dsdk könyvtárban van egy Visual Studio (továbbiakban VS) solution fájl, 2005-ös verzióhoz. Valószínűleg nekünk újabb verziójú lesz (nekem 2010 van). Ha el akarjuk kerülni, hogy a fejlesztőeszközünk működését szabotálja a Windows jogosultságok címén, akkor indítsuk adminisztrátorként. A Visual Studio ezek után szépen át is konvertálja nekünk.

A neten olyan információkkal találkozni, hogy a 2008-as VS nem végzi tökéletesen a konvertálást. Ha valaki ilyet tapasztal, kövesse ezt a forrást.

A konvertált solution fájlt ezután szépen le tudjuk fordítani, eredményül kapunk egy dll-t. Ahhoz, hogy ezt a Cinema 4D elfogadja, .cdl vagy .cdl64 kiterjesztésre kell változtatni, attól függően, hogy 32 vagy 64 bites bővítményt készítünk-e. Ebben a leírásban a 32 bites rendszerrel foglalkozom csak. Ha idegenkedünk az átnevezéstől, akkor a projektünk Properties->Confoguration Properties->General->Target Extension résznél beállíthatjuk ezt a kiterjesztést.

Amint ezzel megvagyunk, a program Plugins->könyvtárnév alatt megtaláljuk a bővítményeket, amelyek most még csak a lefordított példákat tartalmazzák. Nézegessük őket!

Szólj hozzá!

Címkék: programozás demoscene

Második lépcső ama magaslathoz...

2013.05.21. 22:14 Travis.CG

Elkészült a textura beolvasó osztály is. Azt gondoltam, hogy ezt egyszerűen átmásolom és használom, de a rendszerek közötti különbség ismét közbeszólt. ( Egy életre megjegyeztem, hogy Windows alatt fopen(file, "rb")-vel olvasunk be bináris fájlokat. )

Először is le kellett fordítani a libpng-t Windows alá. Szerencsére csak a zlib az egyetlen függősége, és olyan jó minőségű Visual Studio projekt fájlt sikerült készíteniük, hogy a folyamat teljesen fájdalom mentes volt. Már így is eléggé elszaporodtak a release-hez csatolt DLL-ek, ezért statikusan linkeltem mindkettőt.

Ezzel a lépéssel a régi Linuxos keretrendszer teljes funkcionalitása rendelkezésemre áll C++-ban és Windows alatt. A teszteléshez a Biopunk című demónkból kivettem a patkányt és megjelenítettem. A textúra szépen feszült, a mátrixok megfelelő módon forgatták be a modellt.

Amiről nem írtam, hogy Grass is dolgozik. Elkészített két modellt. Az egyik egy környezeti elem lesz, a másik egy karakter. Nem közlök róluk képet, de higgyétek el, nagyon vagányan néznek ki. Most egy nagyobb jelenet környezetén dolgozik. Ez kicsit olyan, mintha valami mese díszlete lenne. Kiforratlan, de nekem jó lesz, hogy a következő projekten, a Cinema 4D exporteren dolgozzak vele.

Pihenni nincs idő, még rengeteg munka vár és az idő fogy.

Szólj hozzá!

Címkék: demoscene

De-novo utómunkálatok

2013.05.21. 21:59 Travis.CG

Egyik korábbi posztom kicsit félrevezető lehet. Ott azt sugalltam, hogy de-novo szekvencia összeszerelés esetén elég egyetlen programnak megadni a szekvencia darabokat, és az megcsinál mindent, végezetül megkapjuk az összes kromoszóma teljes nukleotid sorrendjét.

A helyzet az, hogy ilyen a legritkább esetben fordul elő. Úgy is mondhatnám, én még nem találkoztam ilyennel. A legtöbb esetben több ezer hosszabb-rövidebb szekvenciát kapunk, nem ritkán N-ekkel tarkítva. Szerencsére vannak programok, melyek segítenek a további feldolgozásban.

GAPFiller

A GAPFiller, mint neve is mutatja, nem csinál mást, mint a scaffoldokban található N-eket tünteti el. A program több lépésben readeket pakol a szekvenciákra és próbálja befoltozni a lyukakat. A párosított readek távolság információit felhasználva olyan lyukakat is be tud foltozni, amelyek a readeknél hosszabbak. Megadhatjuk neki, mennyi read illesztése esetén fogadjuk el a foltozást. A scaffoldok sorrendjét nem próbálja meg meghatározni.

SSPACE

A GAPFiller alkotóinak másik programja, ami a párosított readeket használja fel arra, hogy összekösse a scaffoldokat. Segítségével kevesebb szétdarabolt szekvenciánk lesz.

Mauve

Ha van egy rokon szekvenciánk, a Mauve segítségével megnézhetjük, a scaffoldok milyen sorrendben követik egymást. Arra is kiválóan alkalmas, hogy ellenőrizzük, mennyire jó az eddigi összeszerelés. Ha ugyanis azt tapasztaljuk, hogy a scaffoldok nagy része a genom különböző pontjairól származik, jó eséllyel valamit elszúrt a de-novo program. A Mauve Java-s fejlesztés, fut minden platformon.

 Blast

Ne feledkezzünk meg a jó öreg Blastról sem. Ha csak ellenőrizni kívánunjuk egy genomi struktúra jelenlétét nincs jobb és megbízhatóbb ennél a programnál.

Bambus 2

Ezt a programot nem tudtam használni. Már a telepítése is elég bonyolult volt. Az AMOS programcsomag része. A feladata elméletileg az SSPACE-ra hasonlít. Ha csak tehetjük használjuk inkább azt. És ha csak tehetjük, ne használjuk az AMOS-t sem.

Szólj hozzá!

Címkék: bioinformatika

A nagy művész és a DNS

2013.05.09. 22:31 Travis.CG

Startup cégeknél, mikor befektetőkre vadásznak, előfordul, hogy nagyobbat mondanak az emberek, mint amit kellene. Ez egyeseknek be is jön. De a művész világról nem gondoltam volna, hogy ilyen kicsinyes módszereket használna. (Bár, mint látni fogjuk, a művész megnevezése nem is állja meg a helyét.)

Miről is van szó? Adva van egy művész, aki összeszedi az utcáról az eldobott rágógumit és egyéb szemetet, amin feltételezhetően emberi DNS van, megszekvenálja, megállapítja a fenotípust, megalkotja az illető arcát, majd egy 3D nyomtatóval kinyomtatja azt. A nyomtatott maszkokból pedig kiállítást szervez.

Első olvasatra - mondjuk ki - baromság az egész. Már csak abból a tényből kiindulva, hogy nem tudjuk senki arcszerkezetét megállapítani a DNS-ének birtokában. Amire képesek vagyunk, néhány kitüntetett távolság meghatározása, vagy ha tudjuk, hogy egy genetikai betegség arcdeformációval is jár, akkor a betegségre utaló jelek esetén feltételezhetjük, hogy rendelkezik a rá jellemző arcszerkezettel.

Sajnos vagy nem, a DNS önmagában kevés a fenotípus kialakításához. Van valami, amit nagy általánosságban úgy hívnak, környezet, és ez hatással van ránk. Ha Einsteinnek pálinkás kenyeret adnak gyerekkorában minden vacsorára és mákos teával altatják, hogy ne kérdezzen annyit, akkor hülye lesz, függetlenül a génjeitől.

Azért, hogy ne legyek igazságtalan a "művésszel" szemben, elolvastam a blogján található információtöredékeket. Ezek alapján a következő kép alakult ki bennem:

1. Összeszedi a mintákat. Megjegyzem a DNS nem egy darab műanyag pohár, az bizony bomlik. Laboratóriumi munkám során volt olyan, hogy "elvesztettem" a DNS-t. (A témavezetőm nagyon örült ilyenkor.) Az történt, hogy a DNS lebomlott vagy széttöredezett.

2. Valami labormunkát végez a mintákkal. Erről nem sok mindent sikerült megtudnom. Vagy SNP chipet használ, mert egy posztban linkel egy SNP Wikit. Vagy satellitákat néz (utal rá, hogy úgy érzi magát, mint a CSI-ben). Mivel kevés a minta, a második eset a valószínűbb. Amit biztosan nem csinál: teljes genom szekvenálás. Tehát eddig nem sok értelme van a labormunkájának.

3. Futtat egy csodaprogramot. Azt állítja, hogy írt valami tanuló algoritmust MATLAB-ban (bár a program nevét következetesen kisbetűvel írja) és BioPythonban (ha nem használna valami bio vackot, el sem hinném, hogy szekvenciákkal dolgozik).

4. Kinyomtat egy arcot az ingyenesen elérhető arc adatbázisból. Persze azt állítja, hogy az adatbázist csak tréning adatnak használja, de miféle tréning adat az, ahol hiányzik a genotípus?

Már csak azt nem értem, hol a művészet? A BioPython kódban? A szabvány kitekkel végzett laboratóriumi munkában? Talán abban, hogy ezt a sok hülyeséget el tudja adni.

Szólj hozzá!

Címkék: filozofálás

Egy kis pihenő a magaslat felé vezető úton...

2013.05.07. 22:33 Travis.CG

Sajnos nem úgy haladok a produkcióval, mint terveztem. Elkészült a mátrix kezelő osztály és az OBJ betöltő. Nem hangzik soknak? Azért nem nem sok.

Mivel nem csak átmásoltam a C kódot, hanem felül is vizsgáltam, érdekes jelenségekre lettem figyelmes:

1. A Windows nem programozó barát

Gyakran hallani, hogy egyes alkalmazások felhasználó barátok, mások nem. De létezik a számítógép felhasználóknak egy másik faja, akik programokat alkotnak. Azt gondoltam, egy programozónak nem kell igényeket támasztania az operációs rendszer felé, csak adni neki egy szövegszerkesztőt, egy fordítót, és időt, hogy dolgozzon. De most, hogy Windows alatt szerencsétlenkedem, rájöttem, hogy igen is van igényem az operációs rendszer felé. Először is, legyenek a fejléc állományok egy helyen. Ahány SDK-t telepítek, az annyi helyre szórja szét a fejléc állományokat és könyvtárakat. Az elérési utak hosszúak, hülye karakterek vannak bennük, amiket más hülye karakterekkel semlegesítek. Hiányoznak a szkriptek és egyéb automatizáló eljárások.

Vicces, mert míg Linux alatt dolgoztam, soha nem gondoltam arra, hogy nekem szükségem lenne egy nagy IDE-re. Windows alatt Visual Studio nélkül halott lennék. Ennek a hatalmas böszme koloncnak nincs más dolga, minthogy az ellenséges operációs rendszer elé egy függönyt húzzon és megadjon nekem mindent, amire szükségem van.

2. A GNU lustává tesz

Ez az igazság. Annyi kóder nyalóka függvény van a glibc-ben, hogy teljesen a hatásuk alá kerültem. Azokra a függvényekre gondolok, amelyek egyáltalán nem bonyolultak, de valami unalmas, rutinjellegű feladatot megoldanak. Például getline, strsep. Windows alatt ezeknek írmagjuk sincs, mert nem részei semmilyen standardnak. De ahelyett, hogy fél óra alatt leprogramoznám őket, két órán keresztül a guglit nyúzom és olvasom a többi, hozzám hasonló lusta ember nyavajgását, hogy miért nincs ilyen Windows alatt.

3. A változatosság jótékony hatású

Itt arra gondolok, hogy akár mennyi szenvedéssel is jár most még a kódolás Windows alatt, jó, hogy látok mást is a parancssor mellett. Tágítja a látóteremet. Ez persze igaz az egész demoscenére. Hiszen egy cégnél a főnök megmondja, mit kell csinálni, a projekt vezető előírja, mikorra legyen kész. A vezető fejlesztő meghatározza, milyen eszközöket kell használni, végül a tesztelő rámutat, hogy mit kell kijavítani. Egy demó készítésénél viszont senki nem ír elő semmit. A cégnél akkor jó az ember, ha minél gyorsabban, minél kevesebb időráfordítással old meg valamit. A partikon ellenben értékelik, ha valaki egy nehéz kihívást vállal. (Ezzel nem akarom azt sugallni, hogy a Visual Studio kihívás. Egyáltalán nem az.)

4. Platform függetlenség nem létezik

A math.h-ból akartam az M_PI konstanst. Windows alatt még be kell írni, hogy #define _USE_MATH_DEFINES. Több szót nem is érdemes fecsérelni erre.

Szólj hozzá!

Címkék: demoscene

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