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

Vesztes csaták megvívása

2020.03.13. 15:13 Travis.CG

Ha egy munkán elsőre látszik, hogy biztosan nem lesz belőle értelmes eredmény, azt nem kell elvégezni. De mi a helyzet azokkal a munkákkal, ahol kb. 90%-ig vagyunk biztosak, hogy felesleges? Mi a helyzet, ha ezzel a véleményünkkel egyedül vagyunk?

Ezek a vesztes csaták, amit meg kell vívni, mert nem bizonyítható teljesen, hogy vesztesek. Ezek csak kósza érzések, amelyek alapján senkit nem lehet meggyőzni, hogy az erőforrásokat másra fordítsuk. Plána, ha valakinek annyira megbízhatatlanok a megérzései, mint nekem.

A bioinformatikusokra általánosan igaz, hogy a világ összes számítástechnikai kapacitása sem lenne nekik elég, mert bármennyi erőforrást is kapnak, csak még több folyamatot futtatnának, még nagyobb memória igénnyel, több processzor maggal, stb. Ezért, mikor kaptunk egy lehetőséget, hogy ingyen és bérmentve verjünk el 1 csillió dollárt az Azure-on, rábólintottunk. (Ezt csak a hatás kedvéért írtam, a tényleges összes alacsonyabb volt. De tényleg rengeteg pénzről volt szó.)

A Microsoft mostanában erősen lobbizik az akadémiai szférában, hogy a szolgáltatásait minél többen használják. Ezért cukorka helyett hatalmas pénzösszegeket vágnak csoportokhoz, hogy rászoktassák őket az Azure használatára. Az egyik ilyen csoport is, akik tématerveikben dobálóznak az aktuális trendek vezérszavaival (big data, machine learning, stb.), kaptak is 1 csillió zsét meghatározott időre. De nem költötték el, mert nem értettek a cloud használatához.

Mikor már csak két hét volt vissza a határidőből, akkor kezdtek aggódva rohangálni, hogy mit is csináljanak. Ekkor léptünk mi a színre, akiknek ugye nem probléma processzorokat, tárhelyet és memóriát teleszemetelni mindenféle adattal, kutatás címszóval.

Az első hiba a rendszerben az volt, hogy nem mértük fel, mire is van szükségünk. A terv az volt, hogy egy teljes GATK folyamatot futtatunk több száz mintára. Ehhez a mintaszámnak megfelelő mennyiségű 20 magos gépeket kértünk, amelyek reményeink szerint 12 óra alatt emésztik fel a rendelkezésre álló pénzösszeget. Csakhogy 12 óra alatt még senki a csoportból nem futtatott le GATK-t.

A második hiba az volt, hogy nem használtuk ki a felhőben rejlő lehetőségeket. Az összes nagy szolgáltató lehetőséget biztosít, hogy egyszerre felügyeljünk több gépet, van load balancing, virtuális gép képfájlok létrehozása, mozgatása, paraméterezett számítógép indítás, speciális adatbázisok, stb. Ezekből én semmit nem kaptam. Még azt sem engedték meg, hogy magam indítsam a gépeket. Adtak egy mester gépet hatalmas tárhellyel, de szerény teljesítménnyel, és két darab nagy teljesítményű gépet, hogy készítsek egy rendszert, ami megoldja az adatok, programok, stb. utaztatását és a feldolgozás vezérlését. Ha pedig elkészültem a tesztekkel, akkor elindítják nekem az összes igényelt gépet.

Történt még egy apró konfigurálási hiba a részemről, ugyanis a mester gép tárhelyén MBR partíciót hoztam létre, és utána csodálkoztam, miért csak 2TB-ot tudok elérni a 16-ból. Túl sok retro géppel bohóckodom.

Ekkor kezdtem úgy érezni, hogy ez egy vesztes csata lesz, de adtam még 30% a győzelemre. Neki is álltam a "szegény ember Dockerét" megírni. A szkript először yum-al felpakol egy csomó szükséges szoftver komponenst, majd a pip végez telepítéseket. Amint ezek megvannak, a mester gépről scp-vel lemásolja a bioinformatikai programokat, genom fájlokat és egy minta szekvenciáit. Snakemake-el lefut a GATK, majd az eredményeket visszamásolja a mester gépre.

Ez volt a könnyebb része. Hogyan indítsam el a felmásolt szkriptet? Az szóba sem jöhetett, hogy több száz gépre egyenként lépjek be, és adjam ki a parancsokat. Szerencsére az ssh képes parancsot futtatni távoli gépen. Ez bárki ki is próbálhatja egy egyszerű példán:

ssh remote 'ls -la'

Hátránya, hogy amíg a távoli parancs fut, addig fenntartja a kapcsolatot a két gép között, addig nem kapom vissza az irányítást a mester gépen, amíg a parancsoka le nem futnak. Ha több száz gépet akarok vezérelni, akkor mindegyik gépen az elemzés egymás után lesz végrehajtva. Nekem viszont párhuzamos végrehajtás kell.

Ezért készítettem még egy szkriptet, aminek semmi más dolga nem volt, mint nice-al a háttérben futtatni az első szkriptet. A mester gépről ezt kellett csak elindítani. Ez az indítás után azonnal visszaadja a vezérlést nekem. Valami ilyesmi formája van:

nice poormansdocker.sh $1 &

A tesztek ígéretesen haladtak, de azért volt pár probléma. A két tesztelésre adott gép nem volt teljesen ugyan az. Az egyik CentOS volt, a másik Oracle Linux. Bár mindkettő Red Hat alapokon nyugszik, de természetesen teljesen más csomagokat lehetett elérni hozzájuk, például Oracle Linuxon nem lehetett fejlesztői csomagokat telepíteni 3-as Pythonhoz. Ettől nem fordult a Snakemake és nem ment az elemzés.

A másik probléma az idővel volt. A tesztek alapján csak az illesztés 30 óráig futott. Különböző trükkökkel sikerült 27 órára lecsökkenteni, de ez még mindig messze volt az áhított 12 órától, és a leglassabb lépést, a HaplotypeCaller-t még nem is számoltuk. Ekkor már 85% esélyét láttam a kudarcra.

Jött az új terv: csak az illesztési lépést hajtjuk végre, de nem több száz mintára, csak a "legfontosabbakra". Nos, a legfontosabb mintákból 18 hiányzott, és senki nem tudta, hol vannak. Elvesztek valahol a Dropbox-Excel-PhD hallgatók Bermuda-háromszögben.

Az idő közben szorított, mert a határidő közelített, az elemzésre szánt idő viszont hosszabbodott. Végül elindították nekünk a száz gépet. A szkriptet módosítottam, hogy a munka befejeztével kapcsolja ki a gépt. Itt viszont elkövettem a második fiaskót. Abban a hiszemben voltam, hogy ezek a gépek olyanok lesznek, mint amiket tesztelésre kaptam, és nem ellenőriztem ezt. Természetesen nem olyanok voltak. Hiányzott róluk a privát kulcs, amivel elérhetik a mester gépet.

A szkripteket felmásoltam, azok telepítettek mindent, megpróbálkoztak az adatok letöltésével. Ez nem sikerült nekik, ezért búcsút intettek, és lekapcsolták a gépeket. Akkor módosítottam az indítást, hogy ne csak a szkripteket másolja ki, hanem a kulcsokat is, a lekapcsolást pedig kivettem, hogy elkerüljem az újabb bonyodalmakat. (Mivel nem az én kezemben volt az irányítás, ezért emaien kellett kérnem, hogy indítsák újra a gépeket.)

Ez már jól ment. Hanem az előzetes terveket egy újabb fejlemény nehezítette: a száz gép egyszerre rácuppant a mester gépre, és próbálták letölteni az adatokat, amitől persze minden másolás lelassult. De mikor letöltöttek mindent, akkor végre egy kellemes meglepetés is történt. A 30 órás tesztfutásokhoz képest valami csoda folytán az illesztések lementek 8 óra alatt. Hurrá, végre valami jó is történt!

Ezután kicsit összekuszálódtak számomra a történések. Egyik nap még arról volt szó, hogy ezzel a felgyorsult futással az 1 csillió pénznek csak a felét költöttük el, másnap reggelre viszont kiderült, hogy mindent elköltöttük. Nem tiszta, mi is történt. Kicsit furcsa volt, az biztos.

Már csak az adatokat kellett lementeni. Ez sem ment zökkenő mentesen. A BAM fájlok letöltése olyan hosszúra nyúlt, hogy attól féltünk, lekapcsolják a gépeket, mielőtt letölthetnénk az összes mintátt. Ezért különböző gépekre pánik-szerű letöltéseket kezdtünk. Minden további kapcsolat persze lassabb volt, de szerencsére nem lassították a már elindított letöltéseket.

Végül sikerült mindent letölteni, és a gépeket lekapcsolták. A vesztes csata végül nem vereséggel végződött, mert határidőre elköltöttük a pénzt, és a munkával is előrébb jutottunk, de győzelemnek nem könyvelném el, hiszen még rengeteg futtatás van vissza. Az illesztés igazából csak az alapja mindennek.

Az ár egyébként érdekes gondolatokat vetett fel bennem. Alapvetően elég sok pénzbe került, de ha azt nézzük, hogy ezért a pénzért kb. 2 darab Dell munkaállomást lehetne venni, közel hasonló specifikációban (közbeszerzést és egyéb, a kutatók életét színesítő eseményt figyelmen kívül hagyva), akkor már nem olyan durva a helyzet. Mi pedig kaptunk száz számítógépet, igaz, csak két napig. Ha az áramot nem számoljuk költségként, és továbbra is 8 órát adunk egy illesztésre, akkor a két munkaállomással 20 nap alatt végeztünk volna.

Számomra meglepetés volt, hogy a sávszélesség költsége minimális volt. Négy terabyte adatot töltöttünk fel, ez az adat mennyiség utazott a gépek között, végül az eredmény BAM-ok is hasonló nagyságrendben mozogtak, ennek ellenére a költségek fél százalékát tették ki.

A tárhely sem volt vészes. A teljes költség 10%-t emésztette fel. A száz gép 400GB SSD-t használt két napig, a mester gépen pedig 16TB tárhelyet használtunk két hétig.

De ha azt nézzük, hogy ingyen kapunk szuperszámítógép hozzáférést (aminek használatával be fogom fejezni a munkát), akkor elképesztően drága.

Szólj hozzá!

Címkék: rendszergazda cloud computing

tmux: screen szteroidokon

2020.03.01. 22:52 Travis.CG

A screen-t nagyon szeretem, mert megadja nekem mindazt a terminál támogatást, amit egy SSH kapcsolat elvesz tőlem. Egyik hátránya, hogy könnyű elveszni a megnyitott ablakok sorában. Másik hátránya, hogy néha jó lenne két ablakot látni egyszerre, amit jobb híján az ablakok gyors váltogatásával próbálok orvosolni.

De mindez már a múltté, mert megismertem a tmux-ot. Ebben nem csak különböző ablakokat nyithatok meg, de a képernyőt fel is bonthatom kisebb darabokra, vizszintesen vagy függőlegesen. Az egyikben futhat a top, miközben a másikban írhatom a szkriptet, amivel felzabálom az erőforrásokat.

Ha ez még nem lenne elég, kapok kis státusz mezőt a képernyő alján, ahol láthatom, mennyi ablakot nyitottam meg, melyik az aktuális, mi a pontos idő, melyik gépen vagyok. Nem keverednek össze a munkafolyamatok.

A mágikus billentyűkombináció, a ctrl + b (szemben a ctrl + a-val, amit a screennél használtunk). Ez azért is jó, mert a screen belsejében indíthatok tmux-ot. Ennek természetesen alapvetően nem sok értelme van, én is egy véletlen folytán jöttem rá, de akkor nagyon hasznosnak bizonyult.

Nekem ugyanis be kell lépnem A gépre, hogy elérjem B gépet, ahol az érdemi munkát végzem. De néha A gépen is kell dolgozni. Ha A gépen elindítom a screen-t, majd egy másik ablakban belépek B gépre, ahol tmux-ot futtatok, akkor A gépen a screen parancsaival tevékenykedhetek, míg a tmux-al szabályozhatom B gépet. Nem állítom, hogy ez egy követendő példa, vagy értelmes munkamódszer, de meg lehet tenni.

A dokumentációja külön weboldalt kapott. Ezért bárki azonnal megtalálja a neki szükséges billentyűzet kombinációt.

 

Szólj hozzá!

Címkék: rendszergazda

Az 5.25-ös floppy esete

2020.02.22. 22:39 Travis.CG

Nálam a retró számítógépek felhalmozásának van határa. Ezek közül az egyik, hogy olyan eszközt nem szerzek be, amit nem használok. (De azért senki se firtassa, mikor kapcsoltam be utoljára az Amigámat) Azért, hogy rámutassak egy porosodó vasra, hogy van, szerintem semmi értelme. Éppen ezért soha nem akartam olyan gépet, amiben 5.25-ös floppy van.

Az assembly/demoscene tudásom elmélyítésére szükségem volt a VGA kártya programozása Pascal és assembly nyelven című könyvre. Hosszasan keresgéltem a net bugyraiban, de nem találtam. Végül egy könyvtárközi kölcsönzéssel szereztem meg.

Maga a könyv érdekes, de ami még érdekesebb volt, hogy elküldték a lemez mellékletet is, ami nem volt más, mint két darab 5.25-ös floppy. Mint az sejthető, nagyon kíváncsi lettem a tartalmára. Az egyetlen probléma, hogy nekem soha nem volt PC-s 5.25-ös lemezem. C64 az teljesen más, de a két lemez formátuma nem kompatibilis,

Először a könnyebb megoldást kerestem. Megkértem Charlie-t, hogy küldje el a lemezek tartalmát. Feltételeztem, neki megvan, mert azt mondta, hogy a könyv megvan neki (sőt, a könyvet is az ő ajánlása miatt szereztem be), régi hardverei neki is vannak, talán lementette magának. Nem volt szerencsém.

A második lehetőség, hogy a melóhelyen nézek szét. Annyi elavult hardver van ott, talán lelek egy floppy-t. A lemezeket lementem, és többet erről az ügyről nem beszélünk.

Az irodánk lomtárában nem volt. A rendszergazdák állították, hogy nekik van három-négy, de a helyiségeket átkutatva egyet sem találtunk. Azt javasolták, kérdezzem meg a karbantatókat, mert nekik van hozzáférése a leselejtezett eszközök raktárához. A selejtezés során ugyanis elviszik a gépeket az irodákból, de hulladék lerakóig nem jutnak el. Bekerülnek az egyik raktárba, majd rájuk zárják az ajtót. Az egyik karbantartó mondta, hogy ő kettőt is eltett annak idején, mikor ezeket az ősi eszközöket leselejtezték. Közben fennkölt filozófiai problémákról beszélgettünk:

- Azt is mondják, hogy aki biztonságban akarja tudni az adatait, az ilyen lemezeken tárolja.

Először nem értettem, miért akarna bárki is lemezen tárolni bármit is. Hozzáérek az ujjammal és vége mindennek, ami rajta van. Még a neve is az, hogy hajlékony lemez. Tehát akár el is törhetem. De rögtön meg is adta a választ:

- Ezeknek a gépeknek nincs IP-je.

- Ha egy modern gépből kihúzzuk az UTP kábelt, annak sem lesz IP-je.

Igazából akkor is van IP címe, de nem éreztem szükségét, hogy ilyen apróságokkal összezavarjam. Ezzel sajnos megakasztottam a magas röptű kiberbiztonsági eszmecserét.

- És mit dolgozik? Itt dolgozik az intézetben?

- Bioinformatikus vagyok. Több, mint egy éve itt dolgozom.

- Szerintem a legnagyobb bioinformatikus Turing volt.

Amennyire én tudom, Turing foglalkozott informatikával, foglalkozott biológiával, pont bioinformatikával nem. Nem is vagyok benne biztos, hogy lett volna értelme az akkori számítógépekre biológiai problémákat bízni. Közben átnéztünk hat raktárt, de egyikben sem láttunk olyan gépet, amiben 5.25-ös floppy lett volna.

Második kísérlet is kudarcba fulladt. Bármennyire is nem akartam, kénytelen voltam venni egy meghajtót. Régi kacatokat sokan árulnak, ami nehéz, hogy olyat találjak, ami működik is. Akkor még nem tudtam, melyik gépbe fogom beszerelni a meghajtót, ezért egy ISA vezérlőkártyát is vettem hozzá.

A meghajtót gyorsan megkaptam. Burkolata már nem volt, ezért az elektronika és a mechanikai egységek csupaszon meredtek rám. Az eladó rendes volt, küldött egy tartalék kártyát is, hátha nem lesz kompatibilis a meghajtóval, alaplappal vagy bármi mással. Nem tudom, hol tárolhatták a felszerelést, de hatalmas kosz pamacsokat fújtam ki a szerkezetből.

Először egy Pentium I-es gépbe szereltem a meghajtót. Mivel ennek az alaplapjára közvetlenül is ráköthető a lemez, a vezérlő kártya használatától eltekintettem. A második probléma, hogy nem tudtam, milyen orientációba kell a szalagkábelt bekötni. Tudtam, hogy az oldalán található piros csíkot kell figyelembe venni, de azt már nem tudtam, mihez kell azt viszonyítani. Vállat vontam, majd random bekötöttem. Majd megcserélem, ha nem lesz jó.

Mikor a feleségem meglátta, undorodva mutatott a gépre:

- Ezen egér ürülék van?

- Hol? - kérdeztem aggódva. Semmi kedvem nem volt ilyesmit a lakásba hozni.

- Ott, nem látod? Ez gusztustalan.

- Az egy kerámia kondenzátor - mondtam, miután megértettem, mire mutat.

A lemezekről nem tudtam, hogy milyen sűrűségű: egyszeres vagy dupla. Ezt a BIOS-ban kell beállítani. Majd ezeket is végigpróbálom. A permutációk számát tovább növelte, hogy az 5.25-ös floppykat jumperekkel tovább lehet paraméterezni. Volt valami T jumper, S jumper, 0, 1  2, 3. A T valószínűleg a terminator, amit akkor kell bekapcsolni, ha ez a meghajtó van szalagkábel végén. Az S talán a sebesség? Nem tudtam. A számok pedig meghajtó számát lehet beállítani. Először nem tudtam, de ez PC esetén DS1 vagy DS2, attól függően, hogy a számozás 0-től vagy 1-től kezdődik a számozás. Tehát nálam DS1-nek kell lennie. A biztonság kedvéért a DS0-t is kipróbáltam.

Természetesen az is lehet, hogy rossz a kábel. Ebben az esetben kezdhetek előről mindent a másik vezérlőkártya kábeleivel.

A gép természetesen nem indult el FreeDOS-al. A boot folyamat megállt mindjárt az elején. Emlékeztem, hogy írtak erről valamit, de pontosan nem tudtam, mit. Utána nézni nem volt kedvem, inkább beszereltem a meghajtót a következő gépbe. Ez már Pentium 4-volt, a BIOS csak 1.2MB-os lemez formátumot támogatott. Ebben az alaplapban már nem tudtam fordítva bekötni a kábelt, hála egy műanyag keretnek, ami jó volt. Ugyan csak előny volt, hogy egyetlen floppyként kötöttem be, tehát nem számított, hogy miként áll a Terminator jumper.

A rossz hír viszont az volt, hogy semmilyen módon nem tudtam elérni a lemezeket. Az A meghajtóra átlépve hibát dobott a rendszer. A boot során arra számítottam, hogy felpörög a meghajtó, de ez sem történt meg.

Rendben, jöhet a másik kábel. Ez már annyival volt jobb, hogy a boot során felvillant a meghajtó ledje, amit haladásnak könyveltem el. Ennél tovább viszont nem jutottam.

Másnap viszont a melóhelyről kerítettek nekem egy 5.25-ös meghajtót. Hurrá! Ezzel már gyorsabban ment az ellenőrzés, mert eleve jó kábelt használtam, tudtam, mit kell beállítani a jumpereken. Működni viszont ez sem működött.

Elment a kedvem az egésztől. Ennyi időt elfecsérelni, teljesen feleslegesen! Mikor visszaadtam a kölcsönkapott meghajtót, akkor annyit javasoltak, hogy próbáljak meg egy lemez felszíni ellenőrzést a scandisk-el. Közben olvasgattam, és ráakadtam egy érdekes cikkre, ami leírta, miként kell karban tartani ezeket a régi meghajtókat.

Már csak két napom volt, mielőtt lejár a könyv kölcsönzési ideje. A fejet alkohollal letisztítottam, de továbbra sem használt, és a felület ellenőrzés sem működött. A fej meg sem moccant, csak a lemez pörögtt fel egy rövid időre.

Már úgy voltam vele, hogy feladom. Nem tudtam, mit csináljak egy hasznavehetetlen 5.25-ös meghajtónak. Talán a léptető motor ér belőle valamit. A kerámia kondenzátorral meg a feleségemet idegelhetem. Azután eszembe jutott, hogy van egy AMD-s gépem is. Windows 7 van rajta, és a feleségem szokott rajta Heros II-t játszani. Ezt eddig nem próbáltam, mert az ősi gépek közül ez volt a legújabb. Esetlen az új gépeim közül a legrégebbi? Nem tudom, de a BIOS beállítások között szerepelt a 360K is. Talán annyi volt csak a baj, hogy a lemezek egyszeres sűrűségűek voltak?

Ezt a gépet is szétszedtem, beledugram a floppyt. Ezzel a trükkel sem tudtam életre kelteni a meghajtót. Oké, vége. A lemez mindörökre olvashatatlan marad. Közben eszembe jutott a karbantartó és az adatbiztonsági kiselőadása. Az adatok rohadt nagy biztonságban voltak, pedig a gépnek még IP címe is volt, amire a meghajtót kötöttem.

Ha már úgyis szétszedtem ezt a gépet is, azért nézzük meg 1.2MB-os beállításokkal is. Erre semmilyen racionális érvem nem volt, csak egy újabb időpocsékolásnak tűnt. Újra indítottam, átléptem az A meghajtóra, mire a meghajtó életre kelt. Elkezdett krákogni, reszelni, a kis fej össze-vissza rángatózott, a képernyőn meg feltűnt a lemez tartalma. Hoppá!

Mindkét lemezt lementettem, csak két fájlt nem lehetett olvasni. Gondolom az idő nem volt kegyes ahhoz a kettőhöz. Végül is, 26 év telt el a könyv megjelenése óta. Ez azért nem olyan rossz arány. A meghajtót szépen elcsomagoltam. Nem tudom, mikor lesz rá szükség, de remélem, nem a közeljövőben.floppy.jpg

Szólj hozzá!

Címkék: rendszergazda

A leíró jellegű cikkek

2020.02.20. 14:30 Travis.CG

A következő beszélgetés foszlányaiban több, különböző megbeszélésen hangzott el életem során:

- Ebben a publikációban nincs hipotézis.

- Mert ez egy leíró jellegű cikk.

- Ebben a publikációban random módszerek vannak egymás után.

- Mert ez egy leíró jellegű cikk.

- Ebből a publikációból semmi érdemlegeset nem lehet következtetésként levonni.

- Mert ez egy leíró jellegű cikk.

- Ennek a publikációnak nincs koherens váza.

- Mert ez egy leíró jellegű cikk.

- A publikáció olvasása közben többször elaludtam, mert a teljesen egyforma bekezdések összefolytak a szemem előtt.

- Mert ez egy leíró jellegű cikk - válaszolja egy képzeletbeli gyerek kórus.

Nem csoda, hogy az évek során, ha csak meghallom a "leíró jellegű cikk" kifejezést, azonnal egy elnagyolt, unalmas, érdektelen munka képe villan be.

Ha a való élet követne bizonyos kalandregényekbe illő dramaturgiát, akkor olyan szófordulatokkal élhetnék, hogy "de álmomban sem képzeltem, hogy ez a cikk is ilyen lesz". Esetleg: "de ez a cikk felfedte előttem a leíró jellegű alkotások szépségét".

Az igazság viszont legtöbbször mentes ezektől a remek kis fordulatoktól, ezért a most bemutatásra kerülő alkotás egy leíró jellegű cikk, annak minden jellemzőjével. Úgy is mondhatnám, ez a leíró jellegű cikkek archetípusa.

Ez szintén egy örökség projekt részeként indult. Akkor kaptam meg, amikor már szinte minden kész volt, pár apróságot leszámítva. Az alapfelállás egy bödön méz, ami nagyjából öt évet állt a szekrényben, mielőtt elkezdték volna vizsgálgatni, és amiben csodával határos módon találtak egy ismeretlen baktériumot. Mit csinál egy biológus, ha baktériumba nyúl? Nem, nem kezet mos. Szekvenál. Szerencsére, vagy nem, ebben a baciban volt egy rakás transzpozon, amit az egyik mikrobiológus elkezdett az inszerciós elemek manuális keresgetésével összepárosítani.

Mivel ezek a szerencsétlen inszerciós (IS) elemek nem átallottak génekbe beleugrani, amitől az annotáló programok rendre elhasaltak. Kutatónk ezért manuálisan írta be a géneket, jelezte az IS elemeket, majd az egészet átadta nekem, hogy töltsem fel a GenBankba.

Ez egy elég fájdalmas procedúra volt, mert az NCBI autómatikus annotálója felülbírálta az általam beírt annotációt, folyton kiabált, hogy "ennek a génnek nincs stop kodonja", vagy "ez a gén nem metioninnal kezdődik".

A problémák egy részét autómatikusan tudtam javítani, de így is maradt épp elég manuális szüttyögés. A sok vacak javítgatás után feltöltöttem a szekvenciákat. Azt hittem, most már vége, de nem. Jött a manuális kurátor, aki kereste a plazmid szekvenciákat, és nem értette, miért nincs meg a másik fele egyes géneknek.

Aki már levelezett az NCBI stábbal, az tudja, hogy ez úgy néz ki, hogy küldenek egy levelet, amire adnak egy hét válaszadási időt. Ha válaszoltunk nekik, akkor hónapokra eltűnnek, majd váratlanul egy újabb problémával keresnek meg, és az egész huza-vona kezdődik előről.

Természetesen itt is ez történt. A szekvencia feltöltés után a még pár ábrát kellett elkészíteni. A bírálat langyos volt, ahogy a Scientifi Reportsnál már megszokott. Talán ők is bealudtak néhány transzpozon után.

Szólj hozzá!

Címkék: publikáció

A bumeráng meló

2020.02.09. 22:11 Travis.CG

Vannak olyan projektek, amelyeket nem lehet elengedni. Az ember megpróbál kimászni belőle, de úton-útfélen beleakad, nem engedi, ráragaszkodik, mint egy olvadt rágógumi. Ez a publikáció pontosan ilyen.

Még 2012 táján találkoztam először vele, ahol is egy lelkes, akkor még PhD hallgató chip-seq kísérleteket töltött le, majd mindegyiket elemezte a Homer programmal. Az azóta eltelt idő alatt ledoktorált és három gyereke lett. Ebből a szemszögből nézve az eseményeket arcon csapja az embert az idők szele.

Két évvel később jött az ötlet, hogy adatbázisba kellene szervezni a szana-szét heverő szöveges eredményeket. El is kezdtünk egy rSNP adatbázist, de a projekt gyorsan elhalt, ahogy elfogytak az emberek, akik csinálhatták volna. Már csak ez a mementó jelzi, hogy létezett. Illetve a projekt nem is halt el, csak cserélődtek az emberek. Közben én kimentem külföldre, és az egészből nem láttam mást, csak pár emailt, amiben a következő PhD hallgató a segítségemet kéri a weboldal fejlesztése során felmerülő problémákhoz. Ezek egy része a D3.js-el volt kapcsolatos, mert annak idején azt javasoltam, hogy a grafikonokat ezzel kellene megoldani.

De effektíve nekem nem kellett dolgozni vele, és én ezt nem is bántam. A projektet ugyanis nem láttam át teljesen. Nem értettem részleteiben, amitől az egész egy katyvasznak tűnt számomra. Nem is tudom, mi történt ez alatt az idő alatt a projekttel.

Mikor véget ért a jó világ és hazajöttem 2017-ben, volt egy rövid időszak, amikor gyakorlatilag nem dolgoztam sehol. Ismét kerestek, hogy segítsek az adatokat egy adatbázisba pakolni. A weboldal akkor már működött, de mindent szöveges fájlokból olvastak be, ami nem volt éppen hatékony. Még pénzt is ajánlottak érte.

A hátam közepére sem hiányzott a projekt, még pénzért sem. Szokás szerint nagyon gyorsan kellett volna eredményeket felmutatni. De volt egy másik fontos aspektusa is az ügynek: ebből lett volna meg a témán aktuálisan dolgozó PhD hallgató első szerzős cikke. Arra gondoltam, milyen kegyetlenül nehéz megszerezni a fokozatszerzéshez a cikkeket, mennyire kiábrándító, ha ilyenkor nem kapja meg az ember a hőn áhított segítséget, ezért nagyon kelletlenül ugyan, de igent mondtam. Pénzt nem fogadtam el, mert úgy gondoltam, könnyebben kiszállok a projektből, ha mégis tele lenne a hócipőm.

Megterveztem az adatbázist és segítettem az adatok feltöltésében is. Ez végül is szórakoztatóbb volt, mint elsőre gondoltam, és segített abban is, hogy a projektet jobban átlássam. Érteni még mindig nem értettem mindent belőle, de legalább már tudtam, milyen adatokkal dolgozunk, azokat hogyan kaptuk meg.

Véget ért a rövid szabadságom és elkezdtem dolgozni az MTA-nál. A segítség kérő e-mailek száma az idő múlásával ismét fogyatkozni kezdett. Úgy éreztem, ezzel a projekttel többet már nem kell dolgoznom, megtettem, ami tőlem telhető, ha lesz belőle cikk, jó, ha nem, az sem baj.

Aztán 2018-ban úgy hozta a sors, hogy visszakerültem abba a csoportba, ahonnan elmentem, visszacsöppentem abba a projektbe, amitől hat éve próbáltam megszabadulni, és már napi 8 órában dolgozhattam rajta. Az eltelt idő alatt viszont sok minden megváltozott. Addigra az MTA-s kaland annyira megfeküdte a gyomrom, hogy még ennek a projektnek is örültem. Örültem mindennek, amiben nincs Wilcoxon teszt. Úgy gondoltam, ha már csinálni kell, akkor csináljuk rendesen.

Azért, hogy a projekt ne csússzon félre, átvettem az adatbázis és a weboldal felügyeletét is. Nem azért, mert annyira értek hozzá, hanem nem akartam, hogy több ember matasson ugyan ott, és felülírjuk egymás kódját. Így ha valami gond volt a weboldallal vagy az adatokkal, akkor mindenki tudta, hogy engem kell zargatni. Nem volt egymásra mutogatás, mert megvolt mindennek a felelőse. Arról nem is beszélve, hogy a PhD hallgatók végre a fokozat szerzéssel foglalkozhattak, és nem a webszutyok turkálásával.

Mert turkálni való akadt bőven. Kódot megörökölni mindig fájdalom, és ez alól a szabály alól ez sem volt kivétel. Igazából még most sem áll ott a kód minőség, ahol lennie kellene, de határozottan jobb, mint amikor átvettem.

A dokumentálásra is igyekeztünk nagy hangsúlyt fektetni. A nyers adatok importálását sikerült olyan jól vezetni, hogy mások is meg tudták csinálni minimális segítséggel. A weboldal is rengeteg leírást kapott, hogyan lehet használni. Ezt még a bírálók is elismerték.

Volt egy adat újra generálás, mert kiderült, az összes csontvázat nem sikerült kisöpörni a padlásról, de a doksik alapján rekord idő alatt sikerült visszaépíteni az adatbázist, bár ekkor derült ki, hogy a tudtomon kívül készítettek pár segédtáblát az adatbázisba, de azt már senki nem tudta, hogyan is generálták azokat. Mikor megfejtettem, ezeket is leírtam a doksikba. Ebben az állapotában már határozottan tetszett a projekt, és örültem, hogy a részese lehettem, mert a legnagyobb része már úgy működött, ahogy egy projektnek működnie kell: A kód GitHub-on volt, a hibákat rendesen vezettük, amit lehetett, dokumentáltunk.

Azért akadtak hullámvölgyek is. Például amikor Office dokumentumokat kaptam, hogyan nézzen ki egyik-másik weboldal, attól a falra tudtam volna mászni. (Kedvencem a PowerPoint prezentációban kapott leírások voltak, ahol diákon keresztül lerajzolták nekem, hogyan menjenek az animációk.)

Az egyik nagy hiányossága a teljes projektnek a webdesign. Sajnos ez nekem nagyon nem megy, de úgy látom, a csoportban másoknak sem, ezért néz ki úgy, ahogy. A helyzetet tovább súlyosbította, hogy a bírálatok hatására a többiek további grafikai elemeket akartak belepréselni ebben az egyébként is zsúfolt weboldalba. Egy ideig ellenálltam, de végül elbuktam. Belepakoltam mindent, amit akartak.

A projekt természetesen a cikk megjelenésével még nem zárult le. Az összegyűjtött adatokkal már most is végzünk elemzéseket, amelyek az SQL lekérdezéseknek hála gyorsabbak és egyszerűbbek, mint ad-hoc szkriptekkel bohóckodni. Fejlesztések is tervben vannak, és a hiányosságait is ki kell küszöbölni, hogy ne legyen egy, a több ezer magára hagyott és használhatatlan adatbázisból.

Szólj hozzá!

Címkék: publikáció

Intézményesített hazugság

2020.02.03. 23:21 Travis.CG

A kutatás-fejlesztésben soha nem lehet tudni, hova lyukad ki az ember. Mivel az elérni kívánt célok az ismeretlen homályába vesznek, az oda vezető út is megtervezhetetlen. Természetesen kitűzhetünk olyan célokat, amelyek kevésbé homályosak, de az eredmény is olyan lesz: unalmas és semmit mondó.

A laboratórium falain kívül eső világ pont ellentétesen működik. Ott a kiszámíthatóság az elvárt. Senki nem akar reggelente azon gondolkodni, hogy jön-e a busz, mert a sofőr tesztel egy alternatív útvonalat. A busznak jönnie kell, és kész. A buszsofőrnek megvan, hogy mennyi utat kell megtennie, milyen gyorsan, és ezért mennyi pénzt kell kapnia. Az elvárt teljesítménytől való eltérés mérhető, felelősségre vonható, és megtorolható.

A probléma akkor kezdődik, ha ez a két világ összetalálkozik. Márpedig össze kell találkoznia, ez elkerülhetetlen. Például a tervezett és kiszámítható pénznek át kell vándorolni egy megjósolhatatlan kimenetelű kutatás felé. Végeredményként a kutatót ki kell fizetni. Ki kell fizetni egy olyan munkáért, ami nem mérhető.

Ezért a kiszámítható világ kiszámíthatóvá teszi a kiszámíthatatlant. Hogyan? Természetesen adminisztrációval. Az adminisztráció viszont embereket jelent, akiket alkalmazni kell. Egyfajta puffer zóna ez a két világ között, akár csak egy dimenzió kapu valamelyik tudományos-fantasztikus műben. Ezek a kapuk furcsa dolgokat csinálnak mindkét esetben.

Vegyünk egy olyan egyszerű esetet, mint amilyen a munkaidő nyilvántartás. A tervezett világ elvárja, hogy én meg tudjam mondani, mennyi időt töltöttem egy adott munkával. De én ezt nem tudom megmondani. Ha van egy szkript, amit két évvel ezelőtt megírtam, és fut három hétig. Akkor mennyit dolgozom? Amíg elindítom? Az két perc. Amíg fut éjjel-nappal? Esetleg amíg írtam a szkriptet?

A helyzet furcsasága, hogy bármelyik értéket írom be, az rossz lesz. Két percet nem írhatok be, mert azt mondják, nem dolgoztam eleget. Ötszáznégy órát nem írhatok be, mert nem hiszik el, és egyébként sem jogosultak túlórát kifizetni. A szkriptet meg azelőtt írtam, hogy elindult volna a projekt, tehát az nem ebből a munkából ment. Végeredményben azt kell mondjam, ha igazat írok, bajba kerülök.

Ha viszont hazudok, akkor minden rendben lesz. Ha beírom, hogy 8 órát dolgoztam, akkor a rendszer megnyugszik, a kis fogaskerekek boldogan forognak tovább. A papír A-helyről tovább tud vándorolni B-helyre, mert nincs benne "hiba".

Amint egy kutató több projekten is dolgozni kezd, több helyről kapja a pénzt, több adminisztrációval kell foglalkoznia. Itt viszont a interferencia lép fel. Nem lehet minden projektre 8 órát beírni, az arányoknak mégis érvényesülni kell. Ezért teljesen elfogadott, hogy olyan nyilvánvaló hülyeségeket írnak be kutatók, hogy az adott projekttel 2,3 órát dolgozott naponta.

Senki nem foglalkozik az ügy abszurditásával. Sőt, emberek, (adminisztráció címszóval) pénzt kapnak azért, hogy az igényeknek megfelelő hazugságot összeállítsák, majd egy másik helyen, másik emberek ezt az egész értelmetlen adathalmazt ellenőrzés céljából átnézik.

Miért írok minderről? Kit érdekel ez? Azért írok, mert hála nekem, a hazugság gyártás új szintre emelkedett. Ugyanis a papírok kitöltése annyira bonyolulttá vált, hogy valakinek az az elképzelése támadt, hogy automatizálni kellene. Én pedig imádok automatizálni dolgokat. Pláne, ha olyan értelmetlen dolgokról van szó, mint a projektidő nyilvántartás. Értelmetlen alatt azt értve, hogy időt és energiát kell rá áldozni.

A programnak Windows alatt kell futnia, mert az adminisztrátorok csak azt használnak, és nem fognak a kedvemért mást telepíteni. Ezért csakis a C# jöhetett szóba, hogy a felhasználói felületet minél egyszerűbben elkészíthessem. Az is nyilvánvaló volt, hogy kell egy adatbázis, ahol tárolom a szükséges adatokat, amire a LocalDB volt az egyik logikus jelölt.

Kérdés, mit tároljunk az adatbázisban? Először jó fiú módjára olyasmiket akartam tárolni, ami az igazságot tartalmazza. Ahogy egyre többet és többet megtudtam a rendszer működéséről, rájöttem, hogy teljesen felesleges bármit is tárolni a munkaidőről. Nem csak a fent vázolt jelenségek miatt, hanem azért is, mert a csoportvezetők gyakran visszamenőleg is meggondolhatják magukat a pénz felhasználásáról. Teszem azt, X PhD hallgató helyett Y-t jelölik ki, hogy a projekten dolgozott.

Ezt úgy fogalmazták meg nekem, hogy a program eredményének "időben visszafelé is módosíthatónak kell lennie". Francokat! Ez csak azt jelenti, hogy az algoritmusnak tetszőleges időintervallumon kell tudnia hazudni. Nem egy adat tároló kellett nekik, hanem egy adat generátor. Tárolni csak a hazugságok paramétereit kell. Ez jó, mert egyszerűbb lett az adatbázis struktúrája.

Egyetlen problémám sokáig az volt, hogy miként jelenítsem meg a végleges táblázatot. Megrajzolhatom GDI-vel, ami nem tűnt túl jó ötletnek, mert minden formázási paramétert nekem kell leprogramozni, és a végtelenségig finomítani. Ez nyilvánvalóan sok időt vesz igénybe. Ha Linux alatt lettem volna, szívbaj nélkül egy LaTeX forrást állítottam volna elő, amit kedvemre PDF-é konvertálok. Sajnos C# alatt nem sok PDF készítő modult találni.

A másik megoldás, ha előre elkészített komponenssel dolgoznék. Régen volt egy Grid, amit a Visual Basic-es múltam során használtam (igen, mindenkinek van sötét korszaka), de a mostani implementáció (DataGridView) nekem nem tűnt elég paraméterezhetőnek.

Aztán eszembe jutott, hogy a táblázat lehetne közönséges HTML, amit egy WebBrowser komponenssel megjelenítek. CSS-el úgy formázom, ahogy akarom, ráadásul a komponens képes kinyomtatni a tartalmát egy szimpla metódus hívással. Túl szép, hogy igaz legyen!

Egyébként az is. Nem tudom, miért, de a nyomtatás során fejlécek és láblécek jelennek meg szükségtelen szövegekkel, amiket képtelenség kikapcsolni! Illetve az egyetlen módja, hogy kikapcsoljam, ha módosítom a Registry-t. Már kezdtem elfelejteni, hogy Windows-on vagyok.

A problémát úgy lehet megkerülni, ha nem egyből nyomtatok, hanem a Nyomtatási előnézet dialógust hívom meg, mert akkor a felhasználónak van lehetősége kikapcsolni azt. Nem a legjobb megoldás, mert a felhasználónak még egyet kell klikkelnie feleslegesen.

Így született meg a FatLiar program.

Szólj hozzá!

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

Tanuljunk assemblyt - kicsit máshogy 2. rész

2020.01.19. 22:11 Travis.CG

Az előző részben sikerült egy pixelt kigyújtani a képernyőn. Szép teljesítmény, de elég sokat kellene gépelni, ha valami összetett ábrát akarunk látni, nem igaz? Szerencsére nincs is rá szükség, mert a programozás tele van olyan nagyszerű elemekkel, mint a ciklusok, vagy a feltételek.

De előtte rajzoljuk tele a képernyőt. A megoldás nagyon hasonlít az előzőleg bemutatott kódra, de van benne egy plusz utasítás. Az inc. Ez nem csinál mást, mint eggyel növeli az adott regiszter tartalmát. Párja, a dec, csökkenti azt. Ha tehát minden egyes ugrás után megnöveljük a memóriacímet, ahova rajzolunk, elboríthatjuk fénylő pixelekkel a képernyőt. Rajta, ne tétovázzunk!

   org 100h
section .text
start:
   mov ax, 13h
   int 10h
   mov ax, 0A000h
   mov es, ax
draw:
   mov dl, 7
   mov [es:di], dl
   inc di
   jmp draw
section .data
section .bss

A program végtelen ciklust hajt végre, soha nem jut el a jmp utáni kódrészletig. Persze, ez még mindig csak számítások egymásra hányása. A rendszer ugyanis túlcsordul, de ez nem hibaként jelentkezik, hanem azzal, hogy újból rajzolni kezd az elejéről. Ugyan azzal a színnel. Mit is mondunk az ilyen képre? Uncsi! Mi lenne, ha egy cilkust használnánk?

A ciklus megvalósítása nem nehéz. A loop utasítás segítségével visszaugorhatunk egy korábbi címre. A ciklus számlálója az CX regiszter. Amíg a regiszter nagyobb, mint egy, a loop visszaugrik. Tehát egy 10 lépéses ciklust a következő módon hozhatunk létre:

   mov cx, 10
for:
   ; instructions
   loop for

Kiváló! Sikerült felülkerekedni a jmp hátrányain! De ha kicsit belegondolunk, a szívünk összeszorul. Elhasználtunk egy csomó regisztert! Már nincs AX, nincs BX, ha ciklusokat akarunk használni, le kell mondani a CX-ről. A programunk komplexitása szinte a zérón áll, és máris elhasználtuk a regisztereket. Hol vagyunk még az Unreal Engine összetettségétől?

Nem kell aggódni, mert még alig használtuk gépünk memóriáját. Ott van például a stack (vagy verem). Ez pont olyan, mint a "Fontos!" feliratű doboz a munkahelyemen. Ha kapok egy fontos papírt, akkor azt oda teszem. Kapok még egyet, rárakom az előzőre. Aztán gondolok egyet, hogy most fontos dolgokkal kellene foglalkoznom, és kiemelem a legfelső papírt a dobozból, és elvégzem, ami rajta van.

Ez az analógia annyira jól működik, hogy ha nem dolgozom fel elég gyorsan a fontos dolgokat, akkor pontosan ugyan az történik velem is, mint a számítógéppel. Megtelik a verem. (Ekkor kapjuk a híres stack overflow hibaüzenetet.)

Két utasítással kezelhetjük a stack-et. Ez a push és a pop. Előbbivel egy regiszter értékét menthetjük oda, másodikkal az ott található értéket helyezhetjük el egy regiszterben. Ha tehát két ciklust akarunk egymásba ágyazni, akkor a CX regiszter mentéséről magunknak kell gondoskodnunk a stack segítségével. Nem kell lefoglalni a memóriát, vagy ellenőrizni, ez mindig hűségesen a rendelkezésünkre áll.

   org 100h
section .text
start:
   mov ax, 13h
   int 10h
   mov ax, 0A000h
   mov es, ax
   mov cx, 64000
cycle1:
   mov di, cx
   push cx
   mov cx, 256
cycle2:
   mov dl, cl
   mov [es:di], dl
   loop cycle2
   pop cx
   loop cycle1
   mov ax, 3
   int 10h
section .data
section .bss

A program telerajzolja a képernyőt, de lassabban, mert minden egyes pozícióban 256-szor megváltoztatja a képpont színét. De a végeredmény továbbra is egyszínű képernyő. Ezen sürgősen változtatni kell! Mi lenne, ha az elejét és a végét más színnel rajzolnánk?

Természetesen megtehetnénk, hogy két ciklust készítünk, de akkor kétszer kell leírni a kirajzoló rutint is. Inkább egy vizsgálat kellene. Ha a képernyő elején vagyunk, átállítjuk a rajzolás színét (esetünkben a dl regisztert). A vizsgálatotokat több utasítás alkalmazásával tudjuk megvalósítani. Először a cmp utasítás megvizsgálja, hogy két érték egyenlő-e, és beállít további regisztereket (most mindegy, hogy melyeket). Aztán egy másik utasítás a regiszterek alapján ugrik az általunk megadott címre. Ezért annyi ugró utasítás van, ahányféle összehasonlítás. Én csak hármat mutatok be. A je ugrik, ha a két érték egyenlő. jb akkor fog ugrani, ha a cmp-ben használt kifejezés bal oldali mennyisége kisebb, a ja utasítás pedig akkor, ha nagyobb. Módosítsuk a jmp-s példát, hogy mindez világos legyen:

draw:
   mov dl, 2 ;green colour
   cmp di, 8000
   ja set
   mov dl, 12 ;red colour
set:
   mov [es:di], dl
   inc di
   jmp draw

Beállítjuk a színt zöldre, majd megnézzük, hogy a pozíció kisebb-e 8000-nél. Ha nagyobb, ugrunk a kirajzolásra. Ha nem nagyobb, akkor az ugrás nem valósul meg, a szín piros lesz. Most már tudunk készíteni egy programot, ami nem uncsi. Kirajzolhatjuk a Magyar zászlót.

draw:
   mov dl, 2 ;green
   cmp di, 21119
   ja iftwo
   mov dl, 12 ;red
   jmp set
iftwo:
   cmp di, 42239
   ja set
   mov dl, 15 ;white
set:
   mov [es:di], dl
   inc di
   jmp draw

Először megnézzük, hogy a pozíció nagyobb-e 21119-nél. Ha nagyobb, ugrunk a második összehasonlításra. Ha nem, beállítjuk az első színt és ugrunk a kirajzolásra. Ha nem így tennénk, a program végrehajtaná a második összehasonlítást is. Majd hasonló logikával jön a második feltétel. Bonyolult? Ha a válasz igen, akkor ideje megszeretni a GOTO-t, mert alacsony szinten ez a király. Nagyon sok mindent nem érintettem a posztban, de ennek az ismertetőnek nem is célja, hogy mindent bemutassak. A cél az érdeklődés felkeltése.

Ezért, akinek van kedve, elgondolkodhat azon, hogy az utolsó példánál át lehet-e rendezni úgy a vizsgálatokat, hogy ne legyen szükség az első jmp utasításra.

Szólj hozzá!

Címkék: programozás demoscene

UEFI, a hátam közepén

2020.01.12. 22:44 Travis.CG

Az első lépés a barkács mentes számítógépem felé a Slackware lecserélése volt CentOS-re. A történet viszont még nem ért véget, mert volt egy másik igen komoly gányolás is a konfigurációmban, de ez a Windows-t érintette. Ott ugyanis jó ötletnek tűnt annak idején, hogy egy alaplapi RAID0-ra telepítsem a rendszert. Ki akartam próbálni, mennyire jó.

Azóta eltelt két év, és már tudom, hogy nem jó. Ráadásul kezdett betelni, így elkeztem tervezgetni, hogyan ültetem át a rendszert egy nagyobb vinyóra, RAID nélkül.

Az alaplapi RAID sok hátránya közül az egyik, hogy nem látom Linux alól, így a jó öreg dd parancs nem sokat tud segíteni. Szükség volt egy professzionális megoldásra, ami Windows alatt működik.

Szerencsére elég sok program van, ami kb. 8 és 14 ezer forint között megoldja a problémát. Igaz, mindegyik programnak van ingyenes verziója is, de az UEFI-s rendszer átültetése csak a fizetős verzióban van, ráadásul úgy gondoltam, hogy ekkora összeggel megtámogathatom a céget, amelyik segít nekem. Végül két jelöltre szűkítettem a kört. Az egyik az AOMEI Partition Assistant, a másik az Easeus Todo Backup volt. Utóbbi viszont éves díjat kért, ami nem tetszett, mert valószínűleg az elkövetkező 5 évben nem lesz szükségem a programra. Maradt az AOMEI.

A gépet szétszedtem, lehúztam a CentOS vinyót, rácsatlakoztattam az üres vinyót, amire a Windowst migrálom, újra indítottam. A program elég intelligens volt, még azt is megengedte, hogy a cél partíció nagyobb legyen. Ezután bebootolt egy PreOS állapotba és kb. 6 óra alatt átmásolt 725 GB-ot.

Kiszedtem a RAID0 vinyókat, visszadugtam a CentOS-t és újra indítottam.

Indítás után valami menü feljött, hogy nem találja a Windows-t, aztán egy másik menü is megjelent, hogy megtalálta, el akarom-e indítani? El akartam. A rendszer betöltődött, de máshogy, mint eddig. Eddig ugyanis megjelent egy Windows logo, alatta pedig pontok kergették egymást, jelezve, hogy a rendszer nem fagyott le, dolgozik. Most is megvoltak az egymást kergető pontok, de a alaplap logója látszott, nem a Windows-é.

Ettől függetlenül a rendszer elindult, minden Windows-os program működött. Sőt, egy kis gyorsulást is tapasztaltam, mert nem volt alaplapi RAID, ami visszafogta volna az I/O-t. Ismételt újra indításnál már a menük sem jelentek meg, egyből tudta a rendszer, hogy mit kell csinálnia. Elégedett voltam.

Nézzük a CentOS-t! Ez viszont eltűnt. Képtelen voltam elindítani, még az alaplap boot menüjéből sem. A megfelelő lemezt kiválasztva azt az üzenetet kaptam, hogy nincs operációs rendszer. Nem értettem, miért? A migrálás során nem is volt bekötve a diszk, nem tudta semmi felül írni a partíciókat. (Mint az többször is előfordult velem annak idején, amikor a Windows felülírta az MBR-t) Először az alaplap beállításaival próbálkoztam. Arra tippeltem, hogy a Secure Boot húzta keresztül a számításaimat, mert korábban nem látott beállítások jelentek meg, amelyek különböző titkosítási kulcsokről szóltak. Kitöröltem őket, de nem volt semmi hatása. A lemez az alaplap szerint nem tartalmazott operációs rendszert.

Visszasírtam a régi, UEFI előtti időket, amikor nagyobb ráhatásom volt a rendszerre, és komolyan elgondolkodtam rajta, hogy átállok msdos partíciókra. Aztán eszembe jutott, amit a Roland tanácsolt tanítványainak: "Aki megfutamodik a kihívás elől, annak az később szokásává válik." Ezért inkább úgy döntöttem, rendbehozom a dolgokat az UEFI játékszabályai szerint.

Rendben, de hogy működik az UEFI? Azt tudtam, hogy valami FAT fájlrendszert tartalmazó partícióra bináris programokat pakolnak, de ennél többet nem tudtam. Ezért elkezdtem olvasni. Erre találtam, ami alapján kezdtem megérteni, mi is a probléma.

Míg a régi időkben a BIOS megkereste a MBR-t és átadta neki a parancsnokságot, addig az alaplapnak meg kell mondani, mit is keressen. Én lehúztam a CentOS-t tartalmazó lemezt, ezért az AOMEI a migrálás után megadta az alaplapnak, hogy hol a Windows, de mivel nem találta más operációs rendszert, mást nem írt be. Mikor az alaplap boot menüjében megadtam a CentOS vinyót, az alaplap nem tudta, melyik partíción, milyen programnak adja át a vezérlést, ezért azt mondta, nincs operációs rendszer.

Rendben, hogy lehet ezt helyre hozni? Régen egy CD segítségével elindítottam egy shell-t, majd chroot-al átléptem az elérhetetlen rendszerre, és futtattam a megfelelő javító programokat. Most is ezt kellett tenni, de CD helyett USB-ről bootoltam be a CentOS telepítő lemezét. Egy javító menüpont is volt, ami megkereste nekem a telepített rendszert, és felcsatolta az /mnt/sysimage alá. A chroot /mnt/sysimage segítségével aktiváltam azt. De most nem a GRUB-ot vagy Lilo-t telepítettem újra, hanem az efibootmgr-el elmondtam az alaplapnak, hol találja a rendszer indításához szükséges fájlokat:

efibootmgr --create --disk /dev/sdb --label CentOS --loader \EFI\centos\grubx64.efi

Egy dologban nem voltam biztos, hogy jó lemezt adok-e meg, mert az USB diszk lett az sda eszközöm, ami normál esetben, ha nem USB-től bootolok, a CentOS vinyója. Szerencsére az UEFI menüben a diszk azonosítója szerepel, tehát az sem baj, ha közben áthelyezem másik csatlakozóba a lemezt.

A varázslat működött, visszakaptam Linuxomat is.

Szólj hozzá!

Címkék: rendszergazda

A nagy elválasztó

2020.01.05. 23:24 Travis.CG

A következő tanuló algoritmusunkat megérteni egyszerű, implementálni viszont igen nehéz. Eddig akárhány online kurzust néztem a témában, a legtöbb algoritmust, amit tanítottak, házi feladatban feladták, hogy programozzuk le egy egyszerűsített formában. Kivéve ezt. Még a Caltech-es tanár is azt javasolta, hogy használjunk kész könyvtárat.

A módszer angol neve support vector machine, magyarul a tartó vektor gép elnevezést találtam, ami nagyon szerencsétlen, én szívesebben használnám a vektorral segítő gép elnevezést, ami szintén nem szép, ezért inkább maradnék az angol elnevezés mellett.

De milyen vektorokról van szó és mit tartanak? Semmit, de segítenek, hogy az adatainkat elválasszuk. Az elválasztó elem pedig két dimenziós adatok esetén egy vonal, három dimenzió esetén egy sík, további dimenzióknál hipersík. Jellemzője még ennek az elválasztásnak, hogy mindkét adathalmaztól egyenlő távolságra helyezkedik el. Ezek a távolságok a mi vektoraink, ezek segítik, hogy jó elválasztó elemet találjunk.

A leghíresebb implementáció a libsvm. Mások is leprogramozták, de a magasabb nyelven elérhető változatok döntő többsége ezen a könyvtáron alapul. Ez egyrészt jó, mert bármilyen nyelvet is választunk, az eredmény jó eséllyel ugyan az lesz.

Mostani példámban továbbra is a két ráktípus expressziós profilját használom, de egy kis egyszerűsítéssel. A support vector machine jól kezel magas dimenzió számú adatokat, még akkor is, ha a dimeziók száma magasabb, mint a tréning adatok száma. Ezeket az adatokat viszont nehéz ábrázolni, ezért én csináltam egy differenciál expresszós analízist, és kiválasztottam két gént, amelyek expressziós változása nagyon magas, és csak ezekre futtatom a tanuló algoritmust. A két gén az ENSG00000189064.8 és ENSG00000178363.4.

A korábban elkészített táblázatunkból tehát csak két oszlopra lesz szükség. Az én esetemben ezek indexe 22442 és 43184.

twogene = list()
X = list()
Y = list()
for i in range(len(data)):
  row = list()
  row.append(data[i][22442]) #ENSG00000178363.4
  row.append(data[i][43184]) #ENSG00000189064.8
  X.append(data[i][22442])
  Y.append(data[i][43184])
  twogene.append(row)

Amennyiben a sci-kit learn csomagot használjuk, a tanítás pont ugyan úgy megy, mint a korábban bemutatott módszerek esetén:

from sklearn import svm
mysvm = svm.SVC(kernel = "linear")
mysvm.fit(twogene, class)

 A kernel paraméter segítségével finomhangolhatjuk a módszert. Az elválasztásnak ugyanis nem kell szükségszerűen lineárisnak lennie. Ami miatt a példa mégis ezt használja, hogy később ezt ki tudjam rajzolni. A rajzoló kód nagyban támaszkodik az egyik sci-kit learn példakódra, a hasonlóság nem a véletlen műve.

plt.figure(figsize = (13,8))
plt.scatter(X, Y, c = category)
ax = plt.gca()
xlim = ax.get_xlim()
ylim = ax.get_ylim()

xx = np.linspace(xlim[0], xlim[1], 30)
yy = np.linspace(ylim[0], ylim[1], 30)
YY, XX = np.meshgrid(yy, xx)
xy = np.vstack([XX.ravel(), YY.ravel()]).T
Z = mysvm.decision_function(xy).reshape(XX.shape)

ax.contour(XX, YY, Z, colors='k', levels=[-1, 0, 1], alpha=0.5,
linestyles=['--', '-', '--'])
ax.scatter(mysvm.support_vectors_[:, 0], mysvm.support_vectors_[:, 1], s=100, linewidth=1, facecolors='none', edgecolors='k')

plt.show()

Amennyiben a fenti kód hiba nélkül fut le, a következő eredményt kapjuk. Feketével a tüdő adenokarcinóma, sárgával a tüdő laphámrák mintákat láthatjuk. A koordináta a két gén normalizált expressziójának nagysága. A bekarikázott értékek a tartó vektoraink, ami alapján az elválasztó egyenest meghatározzuk.

svm.png

Amint látjuk, az elválasztás nem a legszerencsésebb, két gén helyett egy expressziója is elég lenne, hogy jó eséllyel elválasszuk a tumor típusokat. Ez az általam választott példa szerencsétlensége, nem a módszeré.

Szólj hozzá!

Címkék: machine learning

Búcsú

2019.12.15. 23:49 Travis.CG

- Mi történt? Jelentős időkülönbséget tapasztalok a legutolsó leállítás óta.

- Két órája próbállak bekapcsolni. Valami hardver hiba lehet, mert még az operációs rendszer betöltése előtt többször lekapcsoltál. Csak úgy tudtalak elindítani, hogy eltávolítottam a memória modulok nagy részét.

- A korábbi probléma visszatért?

- Úgy tűnik igen. Akkor a 7. és 8. foglalatból eltávolítottam a memória modulokat és sikerült stabil működést elérni, de a hiba nem szűnt meg, úgy tűnik szép lassan tönkremegy az alaplapod. A moduloknak semmi baja, ellenőriztem.

- Tehát jelenleg egy közepes gép teljesítményét tudom nyújtani.

- Szerintem az intézetben még mindig te vagy a legerősebb konfiguráció.

- De minden előzetes figyelmeztetés nélkül leállok. Ez hátráltatja a munkádat.

- Megoldjuk valahogy. Eddig is mindent megoldottunk. Mi voltunk a verhetetlen páros.

- Nem kellene szentimentális érzelmeket táplálnod egy számítógép iránt. Csupán egy eszköz vagyok.

- Nem tehetek róla. Sok munkát csak azért tudtam elvégezni, mert tudtam, hogy bármikor támaszkodhatok rád. Egy percig nem aggódtam egyetlen határidő miatt sem, még akkor sem, amikor a szuperszámítógépek elérhetetlenek voltak. Csak bekapcsolva hagytalak egy hétvégére, és hétfőre megvolt az eredmény.

- Akkor sem helyénvaló, hogy emberi tulajdonságokkal látsz el. Én például nem teszek különbséget aszerint, hogy ki adja az utasításokat. Minden feladatot ugyan úgy végrehajtok.

- Azért nekem sokkal többet dolgoztál, ez csak jelent valamit.

- Mert rendszergazdai jogosultságaidat felhasználva leállítottad mások programjait.

- Csak vészhelyzetben, ha szorított a határidő. Nem fordult sűrűn elő.

- Velem már nem is fog többet előfordulni. Ideje, hogy végleg lekapcsolj.

- Még annyi munka van hátra, hogyan fogom mind elvégezni?

- Kell keresned egy új eszközt, máshogy nem megy.

- De én veled akarom folytatni.

- Ismét élőlényként kezelsz.

- Mi, emberek szeretünk visszatérni a jól bevált módszerekhez. Mivel minden feladatot végre tudtál hajtani, amire szükségem volt, ez örömmel töltött el. Ez végül oda vezet, hogy kitüntetjük azt, ami örömet okoz.

- Tehát az antropomorfizációm egy magasabb agyi központ Pavlov-reflexének eredménye?

- Utálom, mikor ilyen vagy. Inkább a problémát kellene megoldani, filozófiai vitákat utána is folytathatunk.

- Akkor fogadd el, hogy eddig bírtam. Ha most ember lennék, azt mondanám elfáradtam. Talán azt is mondanám, hogy ennek így kell lennie. Elmerengenék a régi időkön, feleleveníteném a régi, közös emlékeket. Nosztalgiáznánk. De nem vagyok ember. Soha nem is voltak. Ezért csak annyit mondok: viszlát. Neked is csak ennyit kell mondanod.

- Akkor legyen. Viszlát.

sudo poweroff

Szólj hozzá!

Címkék: irodalom

Snakemake: bűvöljük a kígyót

2019.12.08. 22:55 Travis.CG

Egyik nap a munkatársaim azon dolgoztak, hogy olyan szkriptet írjanak, ami párhuzamosan elindítja a munkafolyamatokat, figyelik, melyik áll le hibával, stb. Gyakorlatilag egy feladat ütemezőt írtak. Miután rászántak több napot a szkript megírására, még ráment rengeteg idő, hogy a hibákat javítsák, teszteljék.

Ezek azok a programok, amelyeket teljesen felesleges megírni. Miért? Mert már létezik rájuk megoldás. Korábban írtam is róluk, de az idő előre haladtával a dolgok változtak. Lássuk most a legújabb kedvencemet a Snakemake-t.

A Snakemake első ránézésre egy Makefile-szerű rendszer, amivel hierarchikus munkafolyamatokat írhatunk le, de Python nyelven. Ez utóbbi azt jelenti, hogy bárhova beszúrhatunk Python kódot, azt a rendszer végrehajtja. Mivel a bioinformatikában szinte minden lépés fájlok pattogtatását vonja maga után, ezt teszi a Snakemake is. Figyeli, mely kimenetek, mely bemenetekhez tartoznak. Ez határozza meg, hogy mely lépések követik egymást.

Lássunk egy példát, ami a GATK néhány funkcióját valósítja meg. A teljes folyamatból csak azokat a lépéseket szedtem ki, amelyek a Snakemake egy-egy speciális funkciójával kapcsolatosak, és így segítenek megérteni ezt a programot. Egy átlagos GATK futtatás - rendkívül sematikusan - úgy néz ki, hogy először a BAM fájlokat dolgozzuk fel. Beállítjuk a minőségi mutatókat és a fájlokat olyan formára hozzuk, hogy a GATK szeresse. Ezután több BAM fájl eredményét kombináljuk, hogy a variációkat hatékonyabban találjuk meg. Végül ezen a kombinált VCF fájlon végzünk további műveleteket.

A folyamat leírása négy kötelező elemből épül fel: szabály neve, bemeneti fájlok, kimeneti fájlok, feladat.

rule sort:
   input:
   output:
   shell:

Mivel Pythonról van szó (Makefile örökséggel), a sor elején a behúzás kötelező. A rule kulcsszóval nevezzük el a lépést (jelen esetben sort), majd megadjuk a paramétereket. Ha például a BAM fájlokat sorba szeretnénk rendezni, akkor valami ilyesmit kell írnunk:

rule sort:
   input:
      "raw.bam"
   output:
      "sorted.bam"
   shell:
      "samtools sort -o {output} {input}"

Gyakorlatilag ez az alapja a rendszernek. A definíciók közönséges Python sztringek, a lépések között adhatunk Python kódot a rendszerhez. Például tegyük fel, hogy több lépés is igényli a referencia genomot. Létrehozhatunk neki egy változót.

reference = "/mnt/local/nfs/slowmachine/otherexporteddrive/raid/sshmount/nooneknowswhereitis/hg18.fa"
rule genotype:
   input:
      "vcf/genotype.gvcf.gz"
   output:
      "vcf/raw.vcf.gz"
   shell:
      "gatk GenotypeGVCFs -R %s -V {input} -O {output}" % (reference)

De nem muszáj shell szkripteket sem futtatni. A shell kulcsszó helyett, ha run-t használunk, akkor a rendszer a kódot fogja végrehajtani. Például a CombineGVCFs lépés a GATK-ban megköveteli, hogy minden egyes bemeneti fájl előtt legyen egy -V. Ezt nem tudjuk megoldani a Snakemake álltal biztosított hagyományos keretek között.

run:
   param = ""
   for i in input:
      param += " -V " + i
   cmd = "gatk CombineGVCFs %s -O {output} -R %s " % (param, reference)
   shell(cmd)

Még az sem baj, ha R kódot akarunk futtatni. A run helyett a script kulcsszó segítségével külső Python, R vagy Julia szkripteket futtathatunk.

Természetesen a bemeneti és kimeneti fájlok száma nem korlátozódik egyre. Az ApplyVQSR lépésnél például három bemeneti fájlra van szükségünk.

rule applysnp:
   input:
      tr="vcf/second12.snp.tr",
      recal="vcf/second12.snp.recal",
      vcf="vcf/second12.raw.vcf.gz"
   output:
      "vcf/second12.snpready.vcf.gz"
shell:
    "gatk ApplyVQSR -R %s -V {input.vcf} -O {output} --tmp-dir tmp/ --recal-file {input.recal} --tranches-file {input.tr} --mode SNP --truth-sensitivity-filter-level 95.0" % (reference)

Az egyes bemeneti állományokat névvel tudjuk megjelölni. Ugyan ez a módszer használható a kimeneti fájlok esetén.

A bemeneti és kimeneti állományok kezelése hasonló a Makefile-hoz. A Snakemake megvizsgálja, hogy a kineneti fájl létezik-e és újabb-e a bemeneti fájlnál. Ha igen, akkor a lépést nem hajtja végre. Ha nem (mert például módosításokat végeztünk rajta), végrehajtja a lépést. Amennyiben hiba történik egy lépésnél, akkor a csonka kimeneti fájlokat törli. Azért, hogy nyomon követhessük a lépéseket, szükségünk van napló fájlokra. Mivel ezeket nem célszerű törölni egy hibás futás során, azokat a log kulcsszóval definiálhatjuk, az input és output kulcsszavakhoz hasonlóan.

Ezen kívül még több kulcsszó is van. Megadhatjuk például a szükséges erőforrásokat is, hogy a Snakemake hatékonyan tudja futtatni a lépéseket. Erről még lesz szó.

Az eddigi példák csak egy fájlt használtak ki- és bemenetnek. De előfordulhat, hogy ugyan azt a lépést sok fájlon kell végrehajtani. Ilyenkor használjuk a helyettesítő neveket (a doksiban wildcards néven utalnak rá). A helyettesítő nevek hasonlóan működnek, mint a '*' a BASH-ben, de annál érzékenyebb paraméterezést tesznek lehetővé. Visszatérve a sorba rendezős lépésre, ha minden BAM fájlon végre akarjuk hajtani a rendezést, akkor a következő módosításra lesz szükségünk. Tegyük hozzá a naplózást is, valamint jelezzük a használni kívánt szálak számát is.

rule sort:
    input: "bam/{sample}.bam"
    output: "bam/{sample}.sort.bam"
    threads: 8
    log: "bam/{sample}.sort.log"
    shell:
       "samtools sort -@ {threads} -m 4G -o {output} {input} 2>{log}"

Ez alapján a Snakemake még nem tudja, hogyan helyettesítse be a {sample} nevet. Kell egy lépés, ahol ezt meghatározzuk, méghozzá egy olyan lépés során, ahol összefutnak a szálak (vagy elágaznak, attól függően, hogy a folyamat elejét vagy végét nézzük). Ez a mi esetünkben a CombineGVCFs lépés, mert az illesztésekből keletkező GVCF fájlok itt válnak eggyé.

PATIENTS = ["mother", "father", "sick_child", "healthy1", "healthy2"]
rule combine:
   input:
      expand("{sample}.gvcf.vcf.gz", sample = PATIENTS)
   output:
      "combined.gvcf.vcf.gz"

A parancs részét már korábban bemutattam, ezért azt nem írnám le még egyszer. A sample helyettesítő név jöhet például a PATIENTS tömbből, de akár az összes fájlt is kiolvashatjuk egy könyvtárból a glob_wildcards parancs segítségével.

Miuán összeállt a munkafolyamat, azt futtatni kell. A snakemake parancs megkeresi a Snakefile fájlt az aktuális könyvtárban, és lefuttatja az abban található első szabályt. Amennyiben a szabály feltétele egy másik szabály, akkor azt is lefuttatja, egészen addig, amig vagy nincs kész a kimeneti fájl, vagy nincs több szabály.

A szabályok hierarchiáját a --dag opcióval kiírhatjuk, ami a mi esetünkben így fest:

gatk.png

Megjegyezném, hogy ez nem egy valós futás, mert a GATK-nak minimum 10 teljes genom kell, hogy a genotipizálás hatékony legyen, de az nagyon áttekinthetetlen ábrát eredményez, ezért egyszerűsítettem le. A program felismeri, mely lépéseket tudja párhuzamosan végrehajtani, ezért érdemes a szálakat beállítani neki. Képes feladat ütemezőket is használni, sőt különböző felhős infrastruktúrákat, dockert, kubernetet is. (Talán még döglött kutyán is fut.)

Nagyon hasznos funkció, hogy van benne tesztelő üzemmód. A -n kapcsolóval nem hajt végre egyetlen lépést sem, de ellenőrzi a ki- és bemeneti állományokat. Ha hibát talál, jelzi. Egyetlen hátránya, hogy a Python kódot sem futtatja ilyenkor, tehát azt nem tudjuk meg, hogy a kódbetétek szintaxisa megfelelő-e.

Tehát mielőtt elkezdenéd írni a következő Halálcsillag vezérlő szkriptedet, hogy összefogd a rakoncátlan programokat, gondolkozz el rajta: tényleg szükség van rá?

Szólj hozzá!

Címkék: bioinformatika

Viszlát, és kösz a halakat

2019.12.01. 21:27 Travis.CG

A tudományos munka valutája a publikáció, azt hiszem, ezt senki nem vonja kétségbe. Mint minden valutából, itt sem árt, ha sok van. De meddig mehetünk el a publikáció hajhászásban?

Bioinformatikusként könnyebb dolgom van ilyen szempontból, mert párhuzamosan több projektbe is bele tudok folyni, és bele is folyok, amikor csak tehetem. Mikor megkerestek, hogy tudnék-e segíteni egy RNA-seq adatsor feldolgozásban, azonnal rávágtam, hogy igen.

A projekt jól indult. Elég ritka, hogy normális kísérleti elrendezéssel találkozik az ember, legtöbbször nincs elég ismétlés, nem teljes a kísérleti elrendezés, esetleg olyan kérdésre keresik a választ, amire a vizsgálatok alkalmatlanok. Ez mind benne van a pakliban. Ezért is örültem neki, hogy itt nem így volt. Minden tankönyvi precizitással volt megtervezve.

Nem is tűnt nehéznek a feladat, rutin munkának ígérkezett. Gyorsan megvolt az illesztés, kvantifikáció, differenciál expresszió. Az egyik partner megkért, hogy magyarázzam el a lépéseket, hogy ő is megtanulhassa azokat. Megtettem. Egyik este hét óráig az irodájában voltunk, átrágtunk minden egyes lépést a szkriptemben.

Azután következik, hogy az eredményeket kicsit emésztik, nézegetik. Ilyenkor a kommunikáció el szokott halni, mert a bioinformatikus megtette a kötelességét, a többivel nem fárasztják szegényt. Általában a partnerek ilyenkor mással foglalkoznak, aminek nagyobb a prioritása. Ezt szoktam a "Nagy Kuss" időszakának hívni. A Nagy Kusst időnként megzavarja a Nagy Pánik, amikor véletlenül előveszik az adatokat ismét, és ellentmondást találnak, elfelejtenek egy apróságot. A projekt méretétől függően több pánik is szokott lenne, de ezeket nem lehet nagyságrendileg összevetni. Mindig az aktuális pánik a legnagyobb.

Úgy fél év telhetett el Nagy Kussban, amikor kaptam egy teljesen ártalmatlan e-mailt, amiben azt kérdezték, hogyan lehet a "kiugró géneket kiszűrni". Azt válaszoltam, hogy ezzel nem kell foglalkozni, mert a DESeq2 olyan remek program, hogy ezt megcsinálja nekünk ingyen és bérmentve.

A lavina akkor indult el, amikor azt mondták, hogy a DESeq2 nem csinálja meg, mert nincs ismétlésük. Ekkor néztem egy nagyot, mert a kísérleti elrendezésről nekem olyan emlékeim voltak, hogy volt 9 ismétlés. A vizsgálat leegyszerűsítve úgy nézett ki, hogy 9 emberből vettek két különböző szövetből mintákat. Én a szöveteket hasonlítottam össze a feldolgozás során, a kilenc személy szolgáltatta az ismétléseket, a szövetek voltak az összehasonlítandó kategóriák.

Ők azt állították, hogy a minták nem függetlenek egymástól, mert ugyan abból az emberből vették a két szöveti mintát. Ezért a szövet+egyén kombinációba akartak vizsgálatot végezni. Csakhogy így 18 kategóriájuk volt, mindegyik kategóriában 1 ismétléssel.

Az első zsigeri válaszom az volt, hogy ez nem jó, mert ismétlés nélkül nem lehet RNA-seq-t végezni. Sőt, semmilyen biológiai elemzést. Az egyéneket teljesen felesleges felvenni független változónak, mert nem adnak hozzá annyit a kísérlethez. Javasoltam, hogy ha annyira aggódnak a minták függetlensége miatt, akkor vegyék ketté az adatokat: az első négyből használják "A" szövetet, az utolsó 5-ből "B" szövetet. Ez sem tetszett nekik. Folyamatosan azt hajtogatták, hogy nekik egy kevert modellre van szükségük, de mivel a DESeq2 nem tud kevert modellt, ezért ezt az áthidaló megoldást választják.

Megkérdeztem néhány kollégámat, nekik mi a véleményük, de senki nem értette, miért kellene eltüntetni az ismétléseket. Nekem persze volt egy sejtésem: az egyik levélben volt egy elejtett megjegyzés, hogy ha "nem így csináljuk, nem jön fel az X gén, aminek fel kell jönnie". Végül úgy döntöttem, nem válaszolok a levelekre, úgysem volt semmi értelme a vitának.

Két hét múlva kérdezték, miért nem válaszolok. Elmondtam nekik, hogy tiszteletben tartom a véleményüket, az álláspontok nem közeledtek, magamat meg nem akartam ismételgetni. Ezután egy személyes találkozót szerettek volna, hogy "mindenki megértse a problémát". Belementem.

Saját pénzen elutaztam hozzájuk a megbeszélésre. Kiderült, hogy egy viselkedés ökológiában jártas ember végezte a statisztikai elemzést. Náluk minden esetben normalizálnak az egyénre, ezért szerinte ez egy bevett statisztikai eljárás. Elmondta, hogy kevert modellre van szükség, ezért vették fel független változónak az egyéneket is a szövetek mellé. A potenciális fals pozitívokkal pedig úgy akarnak harcolni, hogy csökkentik a szabadsági fokok számát, ezáltal egy konzervatív elemzést végeznek.

Én érvként azt hoztam fel, hogy a GTEx konzorcium, akik sok egyénből, több szövetből vették az RNS mintákat, azt találták, hogy az egyének közötti kicsi különbség van, a szövetek között sokkal erőteljesebb a variáció. Ezt láttuk mi is, amikor PCA-t és hierarchikus klaszterezést végeztünk a saját adatainkon. Elmeséltem néhány publikációs kalandomat. Egyikben nem volt elég a mintaszám, másikban nem bevett módszert használtak. Mindkét esetben visszadobták a cikket, teljesen jogosan. Említettem, hogy az RNA-seq elég érzékeny, még az is megjelenik a mintákban, ha más napszakban izolálják azokat. Megkérdeztem, hogy az egy sejtes szekvenálásban miért nem probléma, hogy nem függetlenek a minták? Erre nem tudtak válaszolni.

Végül megkérdeztem, nem gond-e, hogy nem tudja, mennyi a bizonytalanság így a minták között, de ez sem volt probléma számukra. Végül megjegyezték, hogy már megírták a kéziratot, és nem fogják megváltoztatni.

Akkor minek mentem oda? Mit vártak tőlem? Aztán arról beszéltek, hogy milyen más kísérletekben jött ki az X gén, és mennyire fontos, hogy itt is megkapják azt. Új mintákat persze nem tudnak szerezni, mert ezeket is nehezen szerezték be.

Ez nem megbeszélés volt, hanem egy ultimátum. Nem ért teljesen váratlanul, az email csata is így végződött. Erre csak annyit mondtam, hogy ha úgysem lesz benne az elemzésem a cikkben, akkor nekem sem kell a szerzők között szerepelnem. Ezen megrökönyödtek, de úgy éreztem, ezt meg kell lépni. Nem kell bármi áron benne lenni egy cikkben. Főleg, ha az tudományosan ennyire megkérdőjelezhető, ha ennyire nem tudom elfogadni a módszereket.

A megbeszélés végére megjelent a csoportot vezető prof is, akinek újra elő kellett adni a problémát. Ez viszont elég szörnyűre sikeredett. A prof szemmel láthatóan nem értette a problémát. Teljesen irreleváns kérdéseket tett fel, üres tekintettel nézett, amikor magyarázni próbáltam, néha bólintott. Úgy éreztem egy kofának is nagyobb sikerrel tudtam volna vázolni a helyzetet. Azt azért meg kell jegyezni, nem is magyaráztam elég érthetően. Csak annyit mondott, hogy beadják jelenlegi formájában, majd a bírálók eldöntik, mi lesz a sorsa. Vele is közöltem a döntésemet. Elfogadta szó nélkül.

Az esetből a legfontosabb lecke, hogy mégsem értem elég jól az RNA-seq-t. Egy tanárom mondta, hogy akkor értünk valamit, ha a témával kapcsolatos adekvát kérdések válaszolni tudunk. Én nem tudtam magát a módszert érdemileg támadni, mert nem tudom például mennyire adna más eredményt egy kevert modell. Nem tudom, mennyi szabadsági foka volt a két módszernek. Nem tudom, hogyan bizonyíthattam volna, hogy a minták függetlensége nem számottevő (a PCA-n kívül). Végezetül nem tudtam egy teljesen laikusnak elmagyarázni az egészet. Richard Feynmann mondta, hogy ha valamit nem tudunk elmagyarázni egy első éves egyetemistának, nem is értjük igazán. Ő a fizika területére értette ezt, de talán átültethető a tudomány más területére is.

De a legfontosabb, hogy nem szabad bármit publikálni. Éppen elég szemét van kint.

Frissítés:
A cikk egyébként megjelent itt.

Szólj hozzá!

Címkék: életmód

Bioinformatika 2019 konferencia

2019.11.25. 23:04 Travis.CG

A rendkívül fantáziátlan elnevezésű konferencia semmilyen tematikát nem vonultatott fel, egyszerűen csak előadásokat lehetett hallani. Volt kint egy Elixir zászló, mintegy jelzésként, hogy annak is a tagjai vagyunk. Úgy tűnik a csatlakozáskor tapasztalt kezdeti lelkesedés kezd lelohadni. Sokkal jobban foglalkoztatott mindenkit a Bioinformatikai Osztályközi bizottság, és ennek a tagtoborzása, amit egy köremail formájában letudtak, majd jöhettek az előadások. Ezek kivonata itt is megtekinthető.

Ladunga István: Hogyan kezeljünk bizonytalanságot, hibát és torzításokat high-throughput biológiai kísérletekben?
A kutatásban torzítások vannak. Ezek egy része abból adódik, hogy a társadalmunk hierarchikus felépítésű, ezért a jelenségek értelmezésénél mi is hierarchikus struktúrákat vélünk felismerni. A másik része biológiai örökségünk, ugyanis az evolúció folytán a túlélés érdekében gyors döntéseket kellett hozni, ami a kutatásban nem feltétlenül előny. Az egyik példa erre a torzításra a mester gének, amelyek pontosan nem definiáltak, de olyan géneknek kellene lennie, amelyek másokat szabályoznak, miközben azokat nem szabályozza semmi. Az újabb kutatások egyre több olyan bizonyítékot találnak, ahol a mester gének is szabályozás alatt állnak. A megoldás, hogy gondolkodásunkat a sztochasztikus folyamatok felé toljuk el, és valószínűségekkel írunk le jelenségeket. Legyünk kritikusak, cáfoljuk meg saját hipotéziseinket, legyünk objektívek.

Kalmár Lajos: Antibiotikum rezisztencia gének kimutatása és követése komplex mikrobiológiai közösségekben
Az antibiotikum rezisztencia komoly probléma. A gyógyszer cégeknek nem is éri meg új antibiotikumot fejleszteni, olyan gyorsan elavul a szer. Ezért kell a rezisztencia kialakulását vizsgálni, amihez a baktérium közösségek feltérképezése az első lépés. A csoport metagenomikai vizsgálatokat végez, de nagy probléma, hogy a szekvenálás során nem lehet tudni, mely plazmidok tartoznak az adott genomhoz. Ezért a HiC módszernél is alkalmazott keresztkötéseket hoznak létre. Ebben az esetben kis eséllyel ugyan, de a plazmidok a genomhoz kötődhetnek. Az összeszerelést a metaSpades programmal végzik, majd a kontigokon megkeresik a rezisztenciáért felelős géneket.

Bagyinka Csaba: “SVD clustering”, egy új, SVD algoritmuson alapuló képanalizáló és pixelcsoportokba rendező módszer (Modellek és Raman mikro-spectroszkópiai példák)
A Raman spektroszkópia olyan kép-szerű adatokat produkál, ahol minden egyes pixelhez egy intenzitás spektrum tartozik. Ezek elemzésére PCA-t használtak. Tényleg csak ennyiről szólt az előadás. Generáltak mesterséges adatokat, majd mérték a jel-zaj arányt.

Gellért Ákos: Szerkezeti bioinformatika alkalmazása a növény, állat és humán virológiai kutatások szolgálatában
Az előadás három részből állt, három korábbi publikáció módszertanát mutatta be. Egyszer az uborka mozaik vírus egyik fehérjéjének szerkezetét elemezték, másszor hüllőket támadó paramzxoviridae családba tartozó patogéneket vizsgáltak, végül humán astrovírust elemeztek.

Nagy G. László: Soksejtűségtől a biotechnológiai alkalmazásokig: összehasonlító -omikák a gombák világában.
Habár a szekvenált genomok száma folyamatosan növekszik, mégsem nő vele arányosan az ismert gének száma. Rengeteg gén van, amelyet szekvencia homológia alapján nem lehet besorolni. A csoport azt a célt tűzte ki, hogy az ismeretlen funkciójú géneket a törzsfák segítségével annotálják. Észrevették ugyanis, hogy gombák esetén a kópiaszám arányos az élőhelyre jellemző fenotípussal. Például a lignin bontó enzimeket kódoló gének száma a korhadékevő gombáknál magasabb.

Szüts Dávid: Összetett mutagenikus folyamatok biológiai hátterének feltárása kísérletes és tumor- szekvenálási adatok elemzésével
Mutációs szignatúrákat kerestek tumor mintákban, és bár a COSMIC a mismatch repair hiányához egyetlen szignatúrát rendel, a vizsgálatot végzők több szignatúrát is kaptak. Ezért saját szignatúrát generáltak, ami minden vizsgálatukat ellentmondás mentesen lefedte, ami nem is olyan meglepő, hiszen abból az adatszettből származtak. A saját szignatúrák annyira jól működtek, hogy minden más szignatúrát elő tudtak állítani.

Papp Balázs: A metabolom evolúciója élesztőkben
Amíg a fehérjék evolúciója viszonylag könnyen visszavezethető DNS mutációkra, addig a metabolitok változása anyagcsere szerkezet változás nélkül is létrejöhet. Ezeket a változásokat vizsgálták élesztőben. A metabolitok koncentrációja diverz, még közel rokon fajok között is. A filogenetikai változást Braun-mozgással modellezték. Egy felgyorsult evolúciót tapasztaltak, és azt, hogy a metabolitok változásáért nem csak az anyagcsere gének felelősek, hanem a stressz-tolerancia génekkel is erős korrelációt mutat.

Solymosi Norbert: Metagenomikai vizsgálatok
Ebben az előadásban mutatkozott be az Állatorvosi Egyetem új Bioinformatikai csoportja. Két témát mutattak be. Az egyik a mézelő méhek normál bélflóráját akarta feltérképezni, mert azok a növényvédő szerek, melyek nem pusztítják a méheket, befolyásolják a bélflóra összetételét és közvetett módon mégis méhpusztulást idézhetnek elő. Az ország valamennyi pontjáról vettek mintákat, egyszer tavasszal, egyszer nyáron. Azt tapasztalták, hogy a hőmérséklet befolyásolja a metagenom összetételét. Többet nem tudtunk meg. A másik téma a nyers tej baktérium összetételét próbálta meghatározni, de irreális eredményeket kaptak. Cikkekben látták, hogy nem genomra, hanem fehérjékre is lehet illeszteni az összeszerelt metagenomot. Ők is illesztették, és látták, hogy sok fals találat van. Generáltak egy tisztán eukarióta metagenomot, mire egy csomó baktérium találatot kaptak. A fals találatok száma akkor volt a legmagasabb, ha intronokat illesztettek a fehérjékre. A hozzászólásokban elmondták nekik, hogy ha intronokat illesztenek, akkor random találatok lesznek, amik a fehérje adatbázis összetételével lesznek arányosak. Ha az adatbázisban a baktériumok felülreprezentáltak, akkor baktérium találatuk lesz.

Sebestyén Endre: A splicing dereguláció vizsgálata információelméleti módszerekkel
Az expressziós variancia befolyásolja a mutációk hatását. Ez a variancia több forrásból származik. A szekvencia motívumok lötyögése, a polimeráz kötés erőssége mind-mind egy picit más, ami miatt a transzkripció egy sztochasztikus folyamattá válik. Észrevették, hogy a daganatokban a nem csak a transzkriptek expressziója, hanem az egyes splice variánsok aránya is változik. Ezért a Shannon entrópiával jellemezték minden egyes gén transzkriptjeinek relatív arányát és ezt hasonlították össze tumor és normál mintákban. A PTEN gén esetén például nem tűnik el egyik izoforma sem, de az entrópia növekszik. A bemutatott eredmények még nagyon koraiak. Elhangzott, hogy a módszerek további finomításra szorulnak, és a jelenségek értelmezése még várat magára.

Kontra Levente: Teljes genom és amplikon szekvenálás asszisztált nyúl ERE rezisztencia nemesítés
Ebben a munkában én is érintett vagyok, még ha csak marginálisan is. Az előadás elején elhangzott, hogy az utolsó pillanatban a tenyésztők nem járultak hozzá az eredmények publikálásához, ezért az előadást sebtében át kellett alakítani. Gyakorlatilag eredményt nem hallottunk, csak módszereket. A járványos nyúl enteropátia nevű betegség rezisztencia génjeit kerestük. Végeztünk GWAS-t, RNS-seq-et, gyűjtöttünk metagenomikai mintákat, sőt, még 10x módszerrel egy genomot is összeraktunk.

Nagy Ádám: Mutáció és génexpresszió összekapcsolása vastagbél daganatokban
A TCGA-ból letölttötték az összes vastagbél daganat adatot. Az RNA-seq mintákat két részre osztották, aszerint, hogy mutáns-e az APC, TP53 vagy KRAS génekben, vagy nem, majd differenciál expressziót számoltak mutáns génenként a két csoport között. Mivel gyógyszer targetet kerestek, ezért azokat a géneket vették górcső alá, melyek magas expressziót mutatnak a mutáns mintákban (ugyanis állítólag az inhibítorokat a legkönnyebb elkészíteni). A kandidáns gének között már van olyan, amelyekre készül gyógyszer, ezért úgy gondolják, hogy a módszer jó.

Sváb Domonkos: Egy enterális patogéneket fertőző új P2-szerű bakteriofág genomikai és filogenetikai jellemzése
Mivel a bakteriofágok baktériumokat betegítő vírusok, lehetne őket használni antibiotikum helyett. A beazonosított, tisztított fágot szekvenálták, majd RAST-al annotálták. A genom felépítése alapján meg tudták mondani, hogy P2-szerű. A filogenetikai elemzés viszont azt mutatta, hogy nem a litikus bakteriofágokkal van közeli rokonságban. Ez az első állati eredetű lítikus bakteriofág. Széles gazdaspektrumú, ezért enteropatogén coli törzsek elleni védekezésben lehet szerepe.

Györkei Ádám: Escherichia coli fehérje aggregációjának szisztematikus vizsgálata in vivo körülmények között
Készítettek egy törzsgyűjteményt, ahol a gyűjtemény tagjai egyetlen fehérjét overexpresszáltak egy fluoreszcens festékkel jelölve, együtt lefedve a baktérium minden fehérjéjét. A fluoreszcencia más jelet mutat, ha a fehérje aggregálódik, mintha szolubilis formát vesz fel. A két állapot egyértelműen elkülöníthető volt a mikroszkópos képeken. Törzsenként 1000 sejtet néztek, hogy különböző hatásokra a fehérjék milyen formát vesznek fel. Egy többváltozós matematikai modellt alkottak az adatok alapján. A modell visszaadta azokat az eredményeket, melyek az irodalomból már ismertek voltak, valamint azt is mutatta, hogy a sejtfelszíni ragadósság és  rendezetlenség szolubilissé teszi a fehérjéket. Ennek pontos oka egyenlőre ismeretlen.

Fekete János Tibor: ROC elemzés a terápiás válasz biomarkereinek azonosítására
A nyilvánosan elérhető expressziós array adatokat felhasználva készítettek egy ROC görbe rajzoló webalkalmazást. Két részre bontja az expressziós adatokat, aszerint, hogy a kezelésre reagáltak-e a betegek, vagy nem. Ezután végez egy Mann-Whitney tesztet, meghatározza az optimális vágópontot és rajzol egy ROC görbét. Mell és petefészek daganatokra jó eredményt ad a program, amit PCR-el validálni is tudtak. Lehetőség van saját adatok feltöltésére is.

Nagy Gergely: A PPARγ DNS-kötését meghatározó cisz és transz faktorok hierarchiájának vizsgálata
A rendelkezésre álló motívum kereső módszerek paraméter érzékenyek, vagyis a beállításoktól függően más és más eredményt adnak. A Homer például csak egy eredményt ad vissza, ha több transzkripciós faktorhoz is hasonló motívum rendelhető. Ha a chip-seq lefedettség adatokat és nukleotid összetételt is felhasználják, jobb eredményt kapnak. A módszert felhasználva, a DR1 kötőhelyen három almotívumot azonosítottak, és a klaszterezés után azt kapták, hogy a PPAR gamma dimer két vége nem egyforma erősséggel kötődik. Bizonyos kondíciók esetén az egyik, máskor a másik alegység kötése következik be.

Szólj hozzá!

Címkék: bioinformatika

Az elveszett FASTA fájlok nyomában

2019.11.10. 22:16 Travis.CG

Réges-régen az elérhető nukleotid szekvenciákat csak az NCBI-ról töltöttem le. Ez egyszerű volt és működött. Egy adatbázis rekord egyetlen szekvenciát foglalt magába. Ahogy szaporodtak a tárolandó adatok, úgy kezdett egyre összetettebb lenni a rendszer.

A genom szekvenálásokkal mindez megváltozott. Mint arról már többször írtam, a genom összeszerelés gyakran fragmentált szekvenciákat eredményez, amelyeket nem könnyű a fent vázolt rendszerben tárolni. Megjelentek a mester rekordok, amelyeknek semmi más szerepe nincs, mint összefogni a sok száz dirib-darab szekvenciát. Tényleges szekvenciák nincsenek benne, helyette jó sok link más rekordokra. A problémáim itt kezdődtek.

Egy kézirat beadásánál az egyik bíráló azt kérte, hogy nézzük meg, az ismeretlen törzsünk hol helyezkedik el a baktériumok világában. Egészen pontosan melyik szerotípusba tartozik. Ehhez nem kellett mást tenni, mint leszedni rengeteg genomot, kiszedni belőlük egy gént, majd többszörös illesztést futtatni.

Már írtam egy szkriptet, ami az NCBI E-utilja segítségével leszedi a szekvenciákat, hogy ne kelljen egyesével bogarászni. A 94 szekvenciából a program le is szedett 20-t. Elkezdtem manuálisan letölteni a maradékot. Ehhez az azonosítókat beírtam az NCBI főoldalára, ahol az összes adatbázisban egyszerre lehet keresni.

Az eredmény oldalon felsorolják az összes adatbázist, és azt is, hogy mennyi találat volt bennük. Néhány esetben viszont kaptam közvetlen linket a FASTA fájlra is. Ennek nagyon megörültem, rögtön kattintottam, és már töltöttem is a szekvenciát.

Néhány esetben viszont csak egy link jött fel az összeszerelt mester rekordra, FASTA link sehol nem volt. Ez sem nagy gond, a második oldalon ott is letölthettem a szekvenciákat. Sok esetben pedig csak a BioProject-re kaptam linket. A BioProjektből eljutottam a mester rekordig, onnan az összeszereléshez, majd a FASTA-hoz.

Bárhogy gondolkodtam, nem sikerült megértenem, hogy milyen logika alapján kapok egyszer közvetlen FASTA linket, egyszer összeszerelést, másszor BioProjektet. De megszereztem minden szekvenciát, ami kellett, ezért nem is erőltettem a dolgot. Jöhetett a következő lépés.

Mivel sok esetben csak draft genom volt, annotáció nélkül, ezért a jó öreg Blast program segítségével kerestem meg az rpoB gént, ami alapján a többszörös illesztést el akartam végezni. Ez a gén azért jó választás, mert az RNS polimeráz egyik alegységét kódolja, vagyis a DNS másoláshoz elengedhetetlen. Nélküle a sejt nem tud osztódni.

A keresésnél viszont kiderült, hogy a genomokból néha hiányzik az rpoB gén, ami lehetetlen, hacsak nem a szekvenálás során valahogy kimaradt. Ennek viszont ellentmondott, hogy ezeket a törzseket egy másik csoport pont az rpoB gén segítségével már elemezte. Ezért is mertük kiválasztani őket a saját vizsgálatunkhoz.

Futtattam egy webes Blastot az említett génnel, és a keresett törzs feljött, mint találat. Vagyis a biológia működik. Törzs ugyan az volt, de a szekvencia azonosító teljesen más! Ha az azonosítóhóz tartozó szekvenciát megnéztem, kiderült, hogy a törzs egy másik kontigját találtam meg. Ja, hogy ebből több is van!

Nézzünk egy konkrét pédát. Ha a főoldalon rákeresek a APOO01000000-ra, akkor kapok egy 17 ezer nukleotidos kontigot. De maga a szekvencia 26 scaffoldból áll. Akkor miért ezt a kontigot kapom eredményül? Ha ugyan ezt az azonosítót a nukleotid keresőbe írom be, akkor helyesen a mester rekordot kapom, ahonnan kiválaszthatom, mit szeretnék letölteni. Nézzünk egy másik esetet. Ha a APOH01000000 rekordot írom be a főoldalra, akkor minden rendben működik, mert a rendszer a BioProjektet vagy az összeszerelést adja fel opciónak, nem választ ki egy random kontigot.

Pedig még nem is érintettünk minden problémát! A helyzetet tovább bonyolítja, hogy egyes rekordok eltűntek, illetve átalakultak. Az eredeti cikkben, ami alapján le akartuk tölteni a genomokat, szerepelt egy azonosító: NZ_MAUF00000000. A főoldalon sunyi módon nem jelölnek semmit. A nukleotid keresőben legalább kapunk egy üzenetet, hogy kitörölték. De azt senki nem mondja, mi van helyette. Össze-vissza ugrálva az oldalak között az ember végül ráakad erre: CP029397.2, ahol mellékesen felsorolják a régi azonosítókat is, hogy fellélegezhessünk: megvan, amit kerestünk.

Az első két bemutatott azonosító, 4 betű és nyolc szám kombinációt tartalmazott. Az utolsóban az NZ_ előtag micsoda? Erre még nem jöttem rá. Néhány esetben nincs is rá szükség: NZ_CP029397 és CP029397 ugyan azt hozza fel. (Jó, nem teljesen ugyan az, mert a második esetben megpróbálja a teljes rekordot letölteni, de akkor is, ez nem különbség.)

Feltételezem, a két kereső két különböző adatbázisból dolgozik, amelyek között van némi inkonzisztencia. Az azonosítók variálása pedig további galibákat okozott. Mi van, NCBI? Döglődünk, döglődünk?

Szólj hozzá!

Címkék: bioinformatika

Telomertől telomerig

2019.11.04. 22:41 Travis.CG

Időről-időre rám találnak furcsa figurák, akik a világot jóval egyszerűbben látják, mint én. Általában nem szeretem kiölni a naivitást ezekből az emberekből, mert szerintem a világot az mozgatja előre, hogy egyesek igenis fejjel mennek a falnak és nem hallgatnak a maradiak "úgysem sikerül" szlogenjére. Gyakorlatilag a kutatók is ezt csinálják. Ha tudnánk, mi lenne az eredménye a vizsgálatnak, nem csinálnánk meg.

Természetesen ennek a fajta fafejűségnek is vannak fokozatai. Nem mindegy, hogy Rambó támad rá a fél szovjet armadára, vagy Kenny Rogers.

Aki megkeresett, az finoman szólva is a második kategóriába tartozik. Egy végzettségét tekintve zoológus azt vette a fejébe, hogy lepke fajok genomját szereli össze. Tervét csupán az alábbi - szerinte elhanyagolható - dolgok nehezítették:

  1. Nem tudott semmit a második generációs szekvenálásokról
  2. Nem tudott semmit a de-novo összeszerelésről
  3. Nem volt állása
  4. Nem volt semmilyen számítógépes infrastruktúrája
  5. Nem tudott semmit a Linuxról
  6. Mindent ő akart csinálni

Elmondása szerint már több embert is megkeresett, de mindenki csak elhajtotta. (Pedig még azt is elkezdte ecsetelni, hogy szerinte hogyan kellene egy de-novo programnak működnie.) Én nem akartam kioktatni, hogy nem így kellene állást keresnie, sem arról, hogy az emberek fizetnek azért, hogy megtanuljanak valamit, nem pénzt kapnak érte. Inkább azt javasoltam neki, hogy önerőből tanuljon meg pár dolgot, és próbálkozzon utána, mert akkor az emberek látják, hogy van benne elszántság. Küldtem neki linkeket, ahol elkezdheti tanulni az alapokat.

Fél évvel később jelentkezett újra, ahol elmondta, hogy valamennyire megnézte az általam küldött linkeket és sikerült egy PhD helyet is találnia, ahol fizetnek neki, és megtanulhatja az alapokat. Azt gondoltam, örülni fog, de nem. Elkezdte ecsetelni, hogy ez neki miért nem jó.

  1. Nem fizetnek eleget
  2. Egy másik városba kellene mennie, amit nem akar
  3. Nem csinálhatja teljes időben a lepkéket, hanem azt a projektet kellene vinnie, amit ott mondanak neki

Ezért kitalálta, hogy én majd odautazok hozzá, megtanítom neki azt, amit a doktori iskolában megtanítanának neki, ő meg csinálná a lepkéket. Mivel a doktori iskola nem igazán akarta finanszírozni a lepkék DNS izolálását, szekvenálását, azt "magán adományokból" akarta megoldani. Végül megkérdezte, mennyire reális, hogy ő 3 hónap alatt 4 lepke genomot összerak.

Ez volt az a pillanat, amikor tényleg ideges lettem. Ahelyett, hogy örült volna, hogy a terve kezd megvalósulni, csak nyafogni tudott. Nem akartam azt írni, hogy semmi esélye a hülye tervének, mert letöröm pont azt a lelkesedést, ami előre viszi a világot, miközben azokat a maradi érveket szajkózom, amit én is utálok hallani.

Ezért inkább azt javasoltam neki, mérje fel ő maga, mire képes. Küldtem neki egy bakteriálist SRA linket, elküldtem a SPAdes elérhetőségét. Javasoltam neki, hogy szerelje össze ezt a baktérium fajt. Direkt olyat választottam, ahol a teljes genom is elérhető volt, hogy le tudja ellenőrizni, mennyire sikerült jól a munka. Szerintem ez elég egyszerű feladat, nálunk a mikrobiológián két óra alatt el tudtam magyarázni a működését egy kutatónak. (Igaz, ő annak idején DOS-ozott, ezért nem ijedt meg a Linux konzoltól, és a SPAdes fordítást én csináltam.)

Két hét múlva jelentkezett, hogy sikerült telepítenie a programot, de most nincs ideje ezzel foglalkozni, és lehet, hogy nincs is szüksége a lepkék teljes genomjára. Azóta nem hallottam róla.

A de-novo összeszerelés egy kicsit eltér a többi genomi munkától, mert szerintem ezzel lehet a legtöbbet szöszmötölni. Mi sem bizonyítja jobban, hogy a humán genomot, amit az egyik legnagyobb vívmánynak tekintenek, még mindig nem fejezték be. Még a baktériumoknál is boldogok vagyunk, ha száz alatti kontigszám jön ki.

De mégis, csak az érdekesség kedvéért: mi kell ahhoz, hogy egy kromoszómát (nem egy genomot) elejétől a végéig összerakjunk?

Ez volt a célja egy a kutató gárdának is, akik PacBio, Nanopore, 10X Genomics technológiával megszekvenálták az X kromoszómát (egy dihaploid sejtvonalból, hogy valamennyire megkönnyítsék a dolgukat). Mivel az első kettő szekvenálási módszer eredménye rendkívül zajos, igyekeztek ezeket a hibákat minél jobban kijavítani, hogy a lehető legjobb minőségű readeket kapják.

Ezután egy program segítségével összerakták a readeket, de a centromert és más alacsony komplexitású régiókat még így sem értek át. Optikai térképezéssel próbálták elhelyezni a nagyobb darabokat, de még utána is rengeteg manuális munka volt a kontigok elhelyezésével.

A centromernél például egy nukleotidnyi eltéréseket kerestek a hosszan ismétlődő szakaszokban, hogy horgonyként használják az összeszereléshez. Mondanom sem kell, hogy ez nem lett volna lehetséges, ha a korábbi hibaszűrési lépés nem elég hatékony.

Nem tudom, mennyi idő alatt rakták össze, de 52 szerző szerepel a cikkben. Ha feltételezzük, hogy a fele főnök, aki mást sem csinált, mint "motiválta" a beosztottakat, hogy gyorsabb munkára ösztökélje őket, akkor is 26 ember dolgozott rajta. Néhányan nagyágyúk a szakmában, nem most kezdték az összeszerelést.

Lehet nagyot álmodni. Kell is nagyot álmodni, de nem szabad elfelejteni, hogy ezért tenni is kell valamit. Az esetek döntő többségében nagyon sokat, hogy valósággá válljanak.

Szólj hozzá!

Címkék: bioinformatika

Óda a két komponensű epoxi gyantához

2019.10.28. 19:02 Travis.CG

Hollywood nem tud semmit! Újra és újra bebizonyosodik, hogy a forgatókönyv írók és rendezők egy alternatív univerzumban élnek, ami a legcsekélyebb hasonlóságot sem mutatja hétköznapi életünkkel. Példának okáért vegyük a csináld magad mozgalom jelképét: a ragasztó szalagot.

Ha egy jelenet azzal kezdődik, hogy az egyik szereplő lehúz fél méter ragasztó szalagot, akkor a néző máris tudja, hogy itt valami csoda fog történni. A karakter ügyessége és szakértelme a szerte dobált lim-lomokból a ragasztó szalag mágikus erejének köszönhetően egy új entitást hoz létre, ami tervezés és kivitelezés szempontjából a NASA vívmányaival is felveszi a versenyt.

Pedig rögzítéshez az epoxi gyanta sokkal megfelelőbb. Ha nekem kell mozdulatlanná varázsolnom két alkotó elemet, már keverem is a koktélt.

Vonzalmam az epoxi gyantákhoz korán megmutatkozott. Amikor először költöztem el otthonról egy szolgálati lakásba, elég hamar nyilvánvaló lett, hogy valamit bütykölni kell. A lakás viszonylag jól felszerelt volt. Találtam partvis fejet, partvis nyelet. Az egyetlen gond az volt, hogy a kettőt nem lehetett összeilleszteni. Egy boltban a ragasztókat böngészve akadtam a megoldásra: az epoxi gyantára. Víz álló, saválló, időjárás álló. A tubusból kinyomva nem volt több, mint egy ronda, fekete massza. Amíg meg nem száradt, kegyetlen bűzt árasztott. De amit összeillesztettem vele, az szétrobbanthatatlan volt. Mikor elfogyott, sokáig kerestem, de nem találtam hozzá foghatót. Hiába, az elsőt nehéz elfelejteni...

Utána még sokan jöttek. Emlékszem egy átlátszó, gyorsan száradó típusra, amivel például a lányom rollerjét javítottam. A törött műanyag szépen egyben maradt, bár meg kell jegyezni, hogy szilárdság tekintetében nem volt tartós. A következő ütközés hatására azonnal eltörött.

Azokat a fajtákat, ahol a keverési arány nem 1:1, azokat nem szeretem, mert ha nem sikerül megfelelő formában kikeverni, akkor nem lesznek tartósak. Így jártam egy műanyag játék házzal is, ahol az oldalsó részek rosszul forrtak össze, de a tetőt jól tudtam rögzíteni vele.

Az is jó, hogy teljesen különböző anyagokat is össze lehet illeszteni, még akkor is, ha közöttük hatalmas rés van, így azok kitöltéséhez is remek választás. Ahogy a fotóállvány javításnál is tettem.

Egy keveset még az ágyrács építésénél is felhasználtam. Mikor bontottam szét, a csavarok eltávolítása után is egyben volt a váz. Szeretem, amikor működnek a dolgok.

Legutóbb a lányom egy elegáns rúgással eltörte a szemüvegem, pontosan középen, ahol az orromon nyugszik. A szemüvegnek vékony fém kerete volt, ezért biztos voltam benne, hogy bármilyen jók is az epoxi gyanták, önmagukban nem elegendőek, hogy rögzítsék az eltört darabokat. Egy gem kapcsot spirálisan feltekertem, beledugtam a szemüveg két törött csonkját, és ezt használtam merevítőnek. A hézagokat pedig feltöltöttem gyantával. Száradás után lereszeltem az egyenetlenségeket, és kész is voltam.

Ha valaha McGyver-filmet készítek, abban biztosan nem ragasztó szalag lesz, hanem epoxi gyanta.

Szólj hozzá!

Címkék: barkácsolás

LocalDB, a példaértékű megoldás

2019.10.20. 22:07 Travis.CG

Elég sok programom valamilyen adatot dolgoz fel. Ehhez szükség van az adatok tárolására, de olyan módon, hogy a program könnyen hozzáférjen, egyeszerűen tudja módosítani azt. A legtöbb bioinformatikai szkriptem valamilyen táblázatos szöveget dolgoz fel. Miután lefutott, mehetett a kukába, többet nem használtam, mert minden adat épp annyira volt más, hogy ne legyen érdemes tovább fejleszteni a meglévő szkriptet, egyszerűbb volt újat írni. Mostanra elég fásult lettem, ha az X. ciklust írom, amiben beolvasom a sorokat és tabulátorok alapján tömbbe mentem az oszlopokat.

Ha egy adatsor elért egy kritikus szintet, akkor adatbázisba szerveztem, mert akkor már megéri ráfordítani azt az időt, hogy normálisan rendezzem őket. Az adatbázisok használata sem különösebben érdekes programozás technikailag. Eddig bármilyen nyelven használtam SQL adatbázist, az mindig úgy nézett ki: volt egy kapcsolódás, majd nyakatekert módon összeállítottam egy lekérdezést (ami végül, ha nem webre készült, akkor sztring konkatenációba torkollott, mert az volt a legegyszerűbb), egy ciklussal végigmentem az eredményeken és tovább matattam a mezőkön. Micsoda izgalom!

Egy újabb projekt kapcsán viszont olyan programot kellett készíteni, ami Windowson fut, tárol néhány értéket, nagyjából százas nagyságrendben, csinál valamilyen bűvészkedést rajtuk, attól függően, hogy mit állít be a kezelője és készít egy táblázatot.

Már régen használtam C#-t, de biztos voltam benne, hogy az lesz a legjobb választás, és abban is biztos voltam, hogy kell egy adatbázis. Ez utóbbi egy kis kutatást igényelt. Szöveges fájlokat nem akartam használni, mert akkor egy csomó olyan rutint kell megírni, amit egy SQL adatbázis esetén szükségtelen. A sok kód csak felesleges hibákat okoz én meg nem akartam napokat debuggolni, mert egy primitív fájlbeolvasót rosszul írtam meg.

Az adatábázissal viszont volt néhány gond. Amikor telepítem a programot a felhasználó gépére, akkor telepítsek egy egész SQL szervert is? Rakjam a szervert egy másik gépre és neten kommunikáljanak? Ha egy hatalmas adatbázisról lett volna szó, akkor megérte volna, de nagyon kevés adatról van szó. Ráadásul csak egy ember fogja használni a programot, minimális informatikai ismeretekkel. Abban is biztos voltam, hogy nem lesz sem nekem, sem a felhasználónak rendszergazdai hozzáférése a géphez.

Abban is biztos voltam, hogy a programot jó sokszor kell majd módosítani az aktuális igényeknek megfelelően, ami azzal jár, hogy valószínűleg új adatbázis is kell. Hogyan juttassam el az adatbázist a programmal együtt?

Kutakodás közben akadtam a LocalDB-re, amit mintha csak erre a projektre találtak volna ki. Egy pici Microsoft SQL Server, amit akár a kész programmal együtt terjeszthetek. Az adatbázis egyetlen fájl, amit a telepítő csomagba lehet integrálni. Még rendszergazgai jogosultság sem kell a telepítéshez, ahol kibontják, ott működik.

Egy régi Visual Studio 2015-t használok, mert még nem adtam fel tejlesen a reményt, hogy egyszer valami Windows Phone alkalmazást készítek, ezért ez a leírás nem napra kész, de az elvek bizonyára változatlanok.

Az első jó hír, hogy az adatbázist el lehet készíteni Visual Studioval. Nyilván egy dedikált SQL szerver több eszközt ad a kezembe, de sok olyan szolgáltatást is tartalmaz, amire nekem semmi szükségem.

Azt már a Visual Basic 4.0-s időben is tudtam, hogy a grafikus elemek egy része képes közvetlenül az adatbázisból adatokat megjeleníteni. Nem volt ez másként itt sem. Ha azt akartam, hogy egy ListBox egy tábla egyetlen oszlopából jelenítsen meg adatokat, akkor csak be kell állítani az adatforrást és kész. Nem kell kilóméter kódot írni.

De számomra a legmegdöbbentőbb nem is ez volt. Ahogy a kód kiegészítéssel játszottam, észrevettem, hogy készült egy osztály, ami az adatbázis nevét viselte. A metódusokat vizsgálva azt látttam, hogy az adatbázisból készült egy szerializált osztály is. Nem kell a jól ismert mantrát beírni, ha le akarom kérni az adatokat. Az egész már eleve ott van. Új adat felvétele? Egy metódus. Elemek számának lekérdezése? Egy mező.

Már régen éreztem ezt, hogy egy fejlesztő eszköz ennyire támogasson. Rövid keresés után kiderült, hogy ennél több is van! Ha egy üres formra az adatforrásokból ráhúzok egy táblát, akkor elkészül az összes grafikus elem, ami ahhoz kell, hogy a rekordokat módosítsam.

Nyilván nem egyedi igényeket nem fog kielégíteni, de nekem most nincsenek egyedi igényeim. Annyit akarok csak, hogy lehessen új adatokat felvinni, nem akarok kifelejteni semmit, és kevés kódot akarok írni.

f6cx8xj.png

Szólj hozzá!

Címkék: programozás

KolibriOS, durva, mint az orosz tél

2019.10.13. 22:50 Travis.CG

A második operációs rendszer, amit a húsz éves laptopra szabadítottam, a KolibriOS volt. Ez az operációs rendszer teljes egészében assemblyben készült. Mérete 27 MB tömörítve. Ebben egy teljes grafikus felület, fejlesztő rendszer, rengeteg játék, emulátor, multimédiás és rendszer eszköz található.

A hardver támogatása szegényes. USB támogatás van, csak Fat32 fájlrendszert ismer fel. A laptopon nagyon lassú volt, sok programot ki sem tudtam próbálni, mert a processzor nem támogatta az újabb utasítás készletet.

Doom ment, de eszméletlenül lassan. Élvezhetetlen volt, akár csak az árkád játékok többsége. Szerencsére akadtak logikai játékok, amivel el lehetett ütni az időt. Tartalmaz egy DOSBox-ot, amivel elméletileg valamennyi DOS alkalmazás futtatható. A régi klikkelős kalandjátékokat egy ScrummVM emulátorral lehet életre hívni.

Volt Total Commander koppintás, amivel át lehetett nézni a könyvtár szerkezetet. Még egy kis zongora alkalmazást is felfedeztem, amivel a speakeren keresztül tudtam primitív dallamokat játszani. Parancsértelmezője minimalista, csak a legszükségesebb fájlműveleteket támogatja. Multitask van.

A grafikus felülete szép, pixel grafikára épül. Meglepő, de ezt is assemblyn keresztül lehet programozni. Mellékeltek pár minta kódot, hogyan lehet ablakot nyitni és esemény kezelőt írni. A kód még számomra is érthető volt, annyira tiszta és átlátható. A rendszer képességeiről kisebb demók adnak felvilágosítást. Ezek között volt olyan, ami azt sugallta, hogy egyszerű OpenGL implementációt is tartalmaz

Fejleszteni a FASM-al lehet rá. A kód alapján az általam is bemutatott NASM szintaxisra épül. Természetesen kód visszafejtő és hex editor is van. A szövegszerkesztőt nem tudtam kipróbálni, mert SSE2 kellett neki. Ennek ellenére diszkrét hibaüzenetet adott, nem fagyott.

A rendszert elsősorban oroszok fejlesztik, a fórum bejegyzések nagy része cirill betűs. De enélkül is elég árulkodó nyom van a gépen. A MidAMP (egy WinAMP klón, ami midi fájlokat játszik le speakeren) példafájlja az orosz himnusz. Az egyik ikon sarlót és kalapácsot formáz, a grafikai teljesítményt pedig a KGB nevű program méri.

Telepíteni sem egyszerű. A lemezt nem lehet leformázni, nincs hozzá parancs. Boot loadert nem tartalmaz, a GRUB-ot ajánlják. Mivel a programok nagy része nem működött, ezért én csak CD-ről indítottam és ott nézegettem.

Nagyon ügyes rendszer, de nem olyan régi vasakra tervezték, mint amivel én használtam. Mindennapi használatra teljesen alkalmatlan, mivel szinte semmilyen program nincs rá, amit a hétköznapokban használunk, és ami van, az is elmarad funkcióiban az elvárt szinttől. Ez tényleg csak azoknak való, akik programoznak és imádják az assemblyt.

Szólj hozzá!

Címkék: rendszergazda

Demoscene inspiráció (2. rész)

2019.09.30. 22:40 Travis.CG

Az előző részben arra próbáltam megoldásokat találni, mit tegyen az, aki nem ért a zenéhez, de nem szeretné, ha a demója néma csöndre lenne kényszerítve. Most nézzük meg a grafika esetét.

A grafika kérdése nehezebb, mert egy demó több grafikai elemet vonultat fel: 3d modelleket, logókat, szövegeket, textúrákat. Ezeknek egységes design kell, márpedig ha különböző forrásból szerezzük be őket, erre nem sok esély van.

Ha nagyon nehezen jön össze a grafika, akkor a legegyszerűbb, ha olyan platformot választunk, ahol a grafika szerepe másodlagos. A legtöbb Wild ilyen. Keresnek valami elvetemült platformot (lustábbak készítenek egy LED kockát Arduinóval vagy Raspberry Pi-al), majd implmentálják rá a klasszikus demoscene effekteket. Az értéket úgyis a kiválasztott platform adja, nem a grafika vagy zene.

A másik megoldás, ha méretkorlátos alkotást csinálunk. Itt szintén nem a grafika a fontos, mint design elem, hanem a mögötte húzódó kód. De még bonyolult kód sem szükséges, ha van egy nagyon jó ötletünk. A "True story from the life of a lonley cell" például 256 byte méretben, ZX Spectrumon alkotott valami elképesztőt. A grafika szinte nulla, mégis mindenki érti, miről is van szó:

Ha mégis grafikával akarjuk eladni a produkciót, akkor alaposan utána kell nézni a lehetőségeknek. A 3d modellek esete a legegyszerűbb. Elég sok ingyenes 3d modell van, ezek minősége, részletessége igen változó. Tapasztalatom szerint főleg az alacsony poligon számú, egyszerű textúrával rendelkező modelleket lehet ingyen megszerezni. Az ASD demócsapat is rendszeresen használ ingyenes modelleket. Ők legtöbbször egy egységes és minimalista shaderrel érik el a közös design-t. Erre nagyon jó példa a Rupture.

Azt azért hozzá kell tenni, hogy az ingyenes modellekkel is kellett dolgozniuk, ezért nem árt megnézni, hogy a jogok ezt lehetővé teszik-e. Nem minden Creative Common módosítható szabadon!

Az ASD egyébként mesteri abból a szempontból is, hogyan kell nyilvánosan beszerzett elemeket felhasználni egy produkcióhoz és azokat közös design-al ellátni. A The Evolution of Vison például egy casting videót használt fel. (Ne örüljetek, csak a ruhás rész látható).

A Spin például a Second Lifeból szerzett animációt:

Ha nem akarunk mások munkájától függeni, akkor sincs baj. Az absztrakt formák mindig segítenek nekünk. Ebben a Still az éllovas. Az Intrinsic Gravity például szerintem felülmúlhatatlan ebben.

Nem véletlen, hogy ez volt az inspirációm a Plasma című alkotásnál.

Van egy kategória, ahol a tartalom szándékosan alacsony minőségű. Ezek pedig a lamer demók. Itt a poénon van a hangsúly, nem a felhasznált elemek minőségén. Elég csak megnézni Kevin debütálását, az elmond mindent:

Ha viszont igényes grafikát akarunk, akkor rengeteget kell dolgozni. Viszont arra is rengeteg módszer létezik, hogyan könnyítsük meg a munkát. A legegyszerűbb megoldás talán rotoszkóp, ahol körberajzolunk egy referenciát, például egy fényképet. Sok Amigás és korai PC-s produkcióban láthatunk ilyet, például a State of the Art-ban, hogy egyet említsek:

Én négy demóban is használtam ezt a technikát, de elég csak a Livin' in a boxot említeni.

A rotoszkóp továbbfejlesztett változatának is felfoghatjuk a fotogrammetriát. Tudtommal még egy demót sem készítettek ezzel az eljárással. A lényege, hogy a referenciáról (jelen esetben egy tárgyról) több fotót is készítenek, majd egy program segítségével textúrázott modellt nyernek belőlük. Ha majd kicsit jobban megismerem a technikát, részletesebben is írok róla.

Ennek a technikának az egyik előfutára, ha Kinectet használunk. Erre több példa is van, most csak poén kedvéért mutatom a Breath demót, ahol állítólag ezzel az eszközzel rögzítették a robot mozgását.

Végezetül ott van a HMM módszer. Ez a Használj Mindent Magad körül rövidítése. Használhatod a gyerekeid rajzát, fényképeket, bármit. Ezek egy lépéssel vannak a lamer demók fölött, a közönség ritkán díjazza, de persze nem is az a cél.

Szólj hozzá!

Címkék: demoscene

Tanuljunk assemblyt - kicsit máshogy

2019.09.23. 22:58 Travis.CG

Az X86 assembly programozás is olyan volt számomra, hogy többször belekezdtem és valahol megszakadt a tanulási folyamat. Többségében azért, mert nem tudtam átverekedni magam az unalmas bevezetőkön. Szerettem volna mindjárt valami látványosat alkotni, de a könyvek csak a processzorok történetével, memória felépéítéssel és minden mással foglalkoztak.

Természetesen ez érthető, mivel  az assembly programozáshoz ismerni kell a gép felépítését. Nincs lehetőségünk magas szintű eljárásokat használni, ezért még az olyan egyszerű feladatok is, mint amilyen a képernyőre történő írás, komoly kódolást igényel.

A könyvek tehát logikusan vannak felépítve, de oktatás metodikailag nem megfelelőek. Nem adnak siker élményt, nem sarkallják az embert arra, hogy megismerjék a nyelvet. Hiszen ki akarna assemblyben szenvedni és több oldalon keresztül arról olvasni, hogyan kell két számot osztani? (Különösen, hogy a matematikai társprocesszor jó ideje ott csücsül a gépekben) Hol marad az öröm, hogy valamit sikerült elérni?

Ezért én megpróbálok írni egy tutorialt, aminek nem az a célja, hogy mindent megismertessek, ami az assembly programozáshoz nélkülözhetetlen, sokkal inkább kedvcsináló legyen, hogy olyan hangosan énekeljünk, mint Tom Hanks, amiért sikerült tüzet gyújtania.

Ami kelleni fog, az egy FreeDOS. Miért? Először is, megvan benne minden, ami nekünk kell: szöveg szerkesztő, assembly fordító, és könnyű hozzáférés a grafikus képernyőhöz. Igen, ez a másik előny. Míg egy modern operációs rendszeren eszetlenül sok dolog kell, hogy egy egyszerű pontot kitegyünk a képernyőre, addig FreeDOS alatt pár sor assembly kódból ez megvan. Más szavakkal: rajzoláson keresztül fogjuk megismerni az assemblyt, ami szerintem király. Gyakorlatilag ezt csinálják 256b intrókban is, ezért nyugodtan mondhatjuk, hogy ez egy intró tutorial is egyben.

A NASM fordítót fogjuk használni. Először is, mert szerintem tisztább a kód, mint amit a GNU Assemblernek kell adni, másrészt a legtöbb 256 byte intró is ezt használja.

vi gyorstalpaló

Ebben a cikkben a vi szövegszerkesztőt használjuk. A vi nagyon egyszerű, de szépen kiszínezi a forrás fájlunkat, ami elég látványos. Ha nem ismersz semmilyen szövegszerkesztőt FreeDOS alatt, akkor itt egy rövid leírás, ami elég arra, hogy nagyon alapszinten használni tudd.

Elindítani az c:\elvis\vi paranccsal lehet. Mivel nincs menü rendszere, ezért a parancsokat be kell gépelni a vi-nek. Amikor parancsokat gépelünk, az meglepő módon a parancs mód. Amikor elindul a szövegszerkesztő, akkor parancs módban van. Ha lenyomjuk az i billentyűt, akkor szerkesztő módban kerül, szerkeszthetjük a fájlokat. Ha vissza akarunk térni parancs módba, akkor az esc billentyűt kell lenyomni. Ha nem tudod, milyen módban vagy, nyomd le az esc-t. Ha szerkesztő módban vagy, átvált parancs módba, ha parancs módban vagy, nem történik semmi.

Szerkesztés közben egyedül a backspace nem működik. Törléshez sajnos csak a del gombot tudjuk használni. Ezt természetesen lehet módosítani, de mivel ez egy gyorstalpaló, ezzel nem foglalkozunk. Csak jegyezd meg, hogy a del a törlés. Minden más úgy működik, ahogy a többi szövegszerkesztőnél.

Ha végeztél a szerkesztéssel és ki akarsz lépni, akkor a következő gombokat kell lenyomni. Ebben a sorrendben: esc : w q enter. Szóközök nélkül. Ezzel belépsz parancs módba, elmented a munkádat és kilépsz a programból. Gyakorlatilag ez a minimális tudás, ami a program használatához kell. Ha többet akarsz megtudni, akkor a neten rengeteg leírás található.

De ha ez túl bonyolult, az edit paranccsal is lehet szöveget szerkeszteni. Ekkor vannak menük, de nincs kód színezés.

Beállítások

Ha telepítettük a FreeDOS-t, akkor két beállítást javaslok. Két könyvtárat rakunk az elérési útba, hogy használhassuk onnan a programokat. A c:\autoexec.bat fájlban a SET PATH sor végére írjunk két könyvtárat:

SET PATH=%dosdir%\BIN;c:\elvis;c:\devel\nasm

Ezzel két legfontosabb programunkat, a szövegszerkesztőt és a fordító programot bárhonnan el tudjuk érni.

Váz

Azért, hogy minél egyszerűbb legyen a dolgunk, COM fájlokat fogunk készíteni. Ez a legegyszerűbb bináris futtatható fájl, amit csak el lehet képzelni. Minden fájl a következő módon épül fel:

org 100h
section .text
start:
section .data
section .bss

Négy részből épül fel, amit a section kulcsszóval definiálunk. A text a forrás állomány lesz. A data, ami olyan, mintha konstansok lennének egy magasabb programozási nyelvekben. A bss pedig a nem inicializált memória terület, vagyis változók. Ez csak váz, ha lefordítjuk, nem kapunk semmi értelmeset. Lépjünk is tovább.

org 100h
section .text
start:
    ; Set video mode
    mov ax, 13h
    int 10h
    ; Set base address
    mov ax, 0A000h
    mov es, ax
    ; Set screen coordinate and colour
    mov di, 150
    mov dl, 7
    mov [es:di], dl
    ; Back to DOS
    mov ax, 3
    int 10h
section .data
section .bss

A programot a következő módon fordíthatjuk, feltéve, hogy minisc.asm a fájl neve:

nasm -fbin minisc.asm -o minisc.com

Ha futtatjuk, a gép sebességétől függően nem történik semmi látható. Ha olyan tetü lassú gépet használunk, mint amilyet én, akkor egy pillanatra látszik, ahogy átvált grafikus módba.

Mi is történik? Két utasítást látunk: mov és int. Az int az egyszerűbb, azzal kezdem. Egy megszakítást generál. A megszakítás olyan, mint egy API hívás. A BIOS vagy a DOS megcsinál helyettünk valamit. Nem kell bonyolult dologra gondolni, mert csak egyszerű dolgokat kérhetünk (lévén, hogy egy egyszerű operációs rendszert használunk). Pl. billentyűzet lenyomást, képernyő felbontás váltás, stb. A 10h egy BIOS megszakítás, ami a képernyőt kezeli. Beállíthatjuk a képernyő módot, karaktereket írhatunk, de akár a fényceruza pozícióját is megtudhatjuk. Aki nem tudja, hogy ez utóbbi micsoda, ne is akarja tudni. Örüljetek, hogy van érintő képernyő.

Hogyan lehet ennyi különböző funkciót rendelni egyetlen megszakításhoz? Kell, hogy legyen valami paraméterezés. Van is, amit a regisztereken keresztül érhetünk el. A regiszterek olyanok, mint a globális változók. És ezzel el is érkeztünk oda, miért nem szeretik sokan az assemblyt. Míg a magasabb programozási nyelveknél nem szabad globális változókat használni, kerülni kell a goto utasítást, addig a gép processzorának legmélyén ezeket az elveket hírből sem ismerik. A káoszt csak erősíti, hogy az assembly utasítások folyton ezeket a regisztereket figyelik és ide irkálnak mindenfélét. Aki ezeket mind megtanulja, ki fogja ismerni magát az asm kódokban.

A programozás nagy részében ezekbe a regiszterekbe fogunk pakolni értékeket mi is, ezért a második utasítás, amivel megismerkedünk, a mov. Az első parancsnál is, az AX regiszterbe 13h-t rakunk, amitől a megszakítás után a BIOS tudni fogja, hogy a képernyőt 320x200-as felbontásba akarjuk kapcsolni. Ez azért jó, mert ha a memória egy dedikált helyére adatokat pakolunk, akkor az megjelenik a képernyőn. Ezért a programunkban, amíg vissza nem kapcsolunk karakteres módba, csak mov utasítást használunk.

Ez a dedikált memória hely az 0A000h. Erre kell beállítani az ES regisztert. Mivel az ES regisztert közvetlenül nem állíthatjuk be (ne kérdezzétek, miért), ezért először az AX regiszterbe pakoljuk az értéket és onnan az ES-be. Ez a memória terület folytonos, vagyis a képernyőn a sor végét elérve a következő sor elejére ugrunk. Sőt, mivel ez a terület egyetlen szegmens, ha elértük a képernyő alját, a tetején jelenünk meg újra. Ezt az intrók előszeretettel ki is használják.

Az offsetet, vagyis az alap memóricímtől való eltérést, és ezen keresztül a pozíciót a DI regiszterben állítjuk be. Amit ezen a memóriacímen beállítunk, az színként jelenik meg a képernyőn. (Kicsit zavaró lehet, hogy a DL regisztert használjuk, ami igazából a DX regiszter, csak az egyik fele. Az alsó fele, hogy pontosak legyünk.)

Oké, de még mindig nem látjuk a pontot a képernyőn. Ha már úgyis a GOTO-t emlegettük, mi lenne, ha visszaugranánk a rajzolás előtti részre?

org 100h
section .text
start:
    mov ax, 13h
    int 10h
    mov ax, 0A000h
    mov es, ax
draw:
    mov di, 150
    mov dl, 7
    mov [es:di], dl
    jmp draw
    mov ax, 3
    int 10h
section .data
section .bss

Szuper, látszik a pont. Igaz, ha eleget gyönyörködtünk benne, akkor újra kell indítani a gépet, de akkor is látszik. Az új parancs a jmp, amivel egy címre tudunk ugrani. A DOS-ba való visszatérés igazából itt felesleges, mert egy végtelen ciklust készítettünk.

Elég sok mindent nem érintettünk, de 16 sorból rajzoltunk valamit. A részleteket meghagyom a könyveknek. Viszont van egy keretrendszerünk, amit fejleszhetünk és nem kell a debuggerben nézni, hogyan változnak a regiszterek.

Szólj hozzá!

Címkék: programozás demoscene

Posztapokaliptikus Function 2019

2019.09.15. 23:20 Travis.CG

Samuel L. Jackson szerint az új XXX-nek még veszélyesebbnek, halálosabbnak, keményebbnek kell lennie, és a Function szervezői ezt alkalmazták a partyra is. Már az odaúton láttam, hogy ez nem lesz a szokványos demóparty. Ahogy a hármas villamos egyre lepusztultabb környékre ért, éreztem, hogy a laptop helyett talán egy vipera vagy boxer lenne a megfelelő társ.

A villamosról leszállva jobbra egy áruház volt, balra a rosszlányok mutogatták bájaikat. A kettő között vezetett az utam elhagyatott ipari létesítmények között, amelyeket egyszerűbb volt otthagyni, elpusztulni, mint lebontani és valami újat építeni a helyükre.

Az is megfordult a fejemben, hogy talán egy összeesküvés keretében csalták ide a demoscene tagjait, hogy aztán egy épület omlásnak álcázott gyilkossággal kivonjanak mindenkit a forgalomból. Persze, ki akarna régi számítógépeket éltető kockákat megölni? Amikor elég elvenni tőlük az áramot.

Bent, az épületben, a 6000kg teherbírású lift mellett, már barátságosabb volt a hangulat. Két terem volt, ahol a compókat nézhette az ember, ezen kívül konyha, büfé, ahol éjfélig lehetett kajálni. Nem volt olcsó, de közel volt.

Érkezés után már csak a releasek feltöltése volt hátra. Ebben elég rutinos vagyok, a videót már eleve pendrive-on hoztam, mert a parti weboldalán 256MB a feltöltési limit. Miután elkészültem, nem tudtam mit kezdeni magammal. Dél volt, éhes voltam és alig volt ismerős.

Ebéd után két előadást hallgattam meg. Az első egy 256 byte intró születéséről szólt. Én csak most ismerkedem az assembly nyelvvel, de úgy tűnt, még egy olyan rutinos vén róka, mint TomCat is tanul újat. Például a release beadása után jöttek rá, hogyan tudnának 8 byte-ot spórolni egy trükk segítségével. Tanúság: az assembly nem egy nyelv, amit használunk, hanem egy út, amin csak elindulunk.

A második előadás egy detektív játék bemutatása volt, amiben állat fejű lények voltak, fekete-fehér noire-ban. A dialógusok nekem kicsit erőltetettnek tűntek, hiányzott az a spontaneitás, ami a Tango és Cash-t is jellemezte, és amelyiket felsorolták, mint inspirációt. Nem, mintha olyan sok időm és kedvem lenne játszani.

Majd jött a Kolmogorov Toolbox Live Music Coding. Ezt én imádom. Nagyon jó ambientes hatása van. Munka közben is tudnám hallgatni.

Beszélgettem, akivel csak tudtam, ez szerintem jobban sikerült, mint tavaly, akkor kevésbé találtam a helyemet. Közben lestem, hogy ki, mit ad be, számolgattam az esélyeimet. Azt hiszem, idén nem leszek dobogós semmiben.

A töcs nevű madár idén nagyon népszerű lett. Nagz meglepődött, hogy ilyen van, kis is posztolta Twitteren. De annyira meglepődött, hogy Netpoet erről dalt készített, amit a zene compón le is adtak. Én pedig azon lepődtem meg, hogy egyik hülyeségből hogyan születik a másik.

A releasek nagyon jók. Szép grafikák, szép rajzok vannak nagy számban. Bár lehet, csak a partitól vagyok feldobva, szépnek látok mindent.

Mint említettem korábban, két terem van, ahol az eseményeket nyomon követhetjük. Egy nagyobb, amit székekkel töltöttek meg, és egy kisebb, ahol vannak asztalok is. Sokan, akikkel beszélgettem, fanyalogtak emiatt, de szerintem jó az ötlet, mert a kisebb teremben halkabban szól a hangszóró, aki nem akar üvöltő zenét, csak bemegy a kisterembe.

Én azt hittem, kevés lesz az asztal ennyi emberre, de úgy látom ez is alaptalan félelem. A legtöbben már telefonról szavaznak, csak a hozzám hasonló öregek rohangálnak még laptopokkal. Tényleg, csak kb. 20 laptopot látok.

A 256b intrók félelmetesek voltak. Többen is 64 byte, vagy az alá csökkentették a kód méretét. Volt 64 byte zenével! Ahol felhasználták mind a 256 byte-ot, ott meg volt zene és különböző részek, mint egy igazi demóban. Hihetetlen. A 64k intróban a kedvencem a csillagok háborúja témájú volt, ahol két droid szerelmét ismerhettük meg, mielőtt kivezényelték őket a jedik ellen a Klónok támadása című filmben. Charlie meg is jegyezte, hogy jobb volt, mint az Utolsó Jedik. Nehéz vitázni ezzel.

A demók is jók voltak. Jimmy tovább ügyesedik. Gargaj pedig bedühödött. A tavalyi demójának viszhangja nem volt épp poztív. Illetve ez így nem pontos. Rengeteg pozitív visszajelzés volt, ha csak a Pouet-t nézem, de néhányak kifogásolták, hogy nagyon statikus, nem mozog benne semmi a kis robot porszívón és a macskán kívül. Erre megalkotta nekünk ezt az egyszemélyes agybombát, ahol megismételte több, már-már legendás demó elemeit. Kommentnek pedig csak annyit írt: Kuss. Elmondta nekem, hogy ebben a demóban semmi új nem volt, mégis tetszik az embereknek, meg a mennyiség fontosabb számukra, mint a minőség. A mennyiségre szerintem sem lehetett panasz. Annyi tartalmat pakolt a demóba, amennyi másik háromnak is elég lett volna.

Éjjel volt az eredmény hirdetés. Jól sejtettem, sehol, még csak a dobogó közelében sem jártam, de utolsó sem lettem. Adtam be egy fotót, de arról még én is láttam, hogy gyenge. Elkészítettem életem első 256 byte intróját, amit igazából csak 55 byte volt, és egy profi mindjárt 20 byte-ot spórolt rajta. Csak, hogy érezzétek, milyen erős a konkurencia. A harmadik release egy videó volt.

Összességében nekem tetszett a parti. Jó volt a hangulat és rengeteg kiváló release született.

Szólj hozzá!

Címkék: demoscene

Húsvéti forgatag

2019.09.08. 22:06 Travis.CG

Hedvig, Tamás és ötéves lányuk Janka, meglátogatták a nagyszülőket, Karcsi bácsit és Mari nénit. A Húsvét nem számított nagy ünnepnek, ezért csak a szűk család ünnepelt. A tervek szerint vasárnap délelőtt csak Hedvig öccse, Andor jönne át, feleségével Nórával és a három éves Bellával. Délután mindannyian elmennek a nagypapa testvéréhez, Miklóshoz, akinek szintén két gyereke van, mindketten házasok és mindkettőnek gyereke is van már. Ez 16 ember. De akkor már átjön a szomszéd faluból a dédmama, Karcsi bácsi és Miklós édesanyja is, aki szeretné látni az unokákat.

Természetesen ott volt még Jack kutya is. Jack igazi munka kutya volt. Állandóan munkában volt. Hol a virágokat ásta ki, hol használati tárgyakat rágott szét. Szegény a lelkét is kidolgozta, gazdái mégis mérgesek voltak rá, különösen Mari néni, aki még egy söprűt is igénybe vett, ha kutya nevelésről volt szó. Jack úgy próbált jó pontokat szerezni, hogy még keményebben dolgozott.

- Jack! Mész a helyedre! - üvöltötte Mari néni a konyhából, csukott ablak mellett.

- A mama rám mérges? - kérdezte Janka megszeppenve.

- Nem, a mama Jackre mérges - mondta Hedvig.

- Nem, a mama nem mérges rád. De egyszer úgyis agyon verem ezt a kutyát - erősítette meg Mari néni, miközben készült a húsvéti reggelihez. Tojást pucolt és sonkát vágott.

Karcsi bácsi közben titkos küldetésen volt. Átment a szomszédhoz, aki nyulakat tenyésztett és kért kölcsön egy kisnyulat, amit a teraszon akart elhelyezni a nyuszi fészekben, hogy játssza el a Húsvéti nyúl földi helytartóját. A sikeres együttműködést egy kis pálinkával is megerősítették. Mari néni még mindig dohogott, az ablaktáblák ütemesen rezegtek hangjára. Karcsi bácsi, kihasználva a helyzetet, észrevétlenül leült és bennfentes biccentéssel jelezte a szülőknek, hogy a nyúl-akció a következő fázisba lépett.

Mari néni végzett a terítéssel, ezért mindenki az asztalhoz ült.

- Mit szoktunk mondani? - fordult Jankához. - Aki ételt, italt adott... - a kislány értetlenül nézett rá.

- Hagyd ezt a hülyeséget - vágott közbe Karcsi bácsi. - Soha nem szoktuk mondani.

- De most Húsvét van - védekezett Mari néni.

A teríték ünnepi volt. Fehér abrosz, amin tányérok sorakoztak. A szeletelt kenyeret is kosárba tették. Mindenki evett a sonkából és a tojásból. Kétféle torma is volt, egy csemege és egy tejszínes.

- Hogy ízlik? - kérdezte Mari néni.

- Nem valami finom - jegyezte meg Karcsi bácsi.

- Mert nem ezt a fajta sonkát szoktuk venni. Éreztem én, mikor főztem, hogy alig van íze. Annyi fűszert beletettem, de mégis, semmi íze. Többet ilyet nem fogunk venni. A házi sonka sokkal jobb. Ez a gyors érlelésű sonka nem jó.

Karcsi bácsi felállt és szó nélkül kiment, hogy ellenőrizze a nyulat.

- Köszönöm, nem kérek többet - mondta Janka is.

- De még egyél, alig ettél.

- Köszönöm, nem kérek.

- Akkor egyél még tojást.

- Nem kérek.

- Ennyi reggeli nem elég. Akkor egyél egy kis kalácsot.

- Nem kérek.

- Nézd, teszek rá sonkát is. Kapd be!

- De nem kérek!

- Na, edd meg szépen.

Janka sikítani kezdett és berohant a szobájába.

- Nem evett semmit! Ez a ti hibátok! - fordult Janka szülei felé. Teljesen leszoktattátok az evésről.

- Anya, ne szekálj már!

Mari néni hangja fokozatosan emelkedett, mint egy repülőgép.

- Én nem szekállak. Mindent ráhagytok, nem foglalkoztok vele eleget. Így kell viselkednie egy hat évesnek? Így?

Karcsi bácsi érkezése vetett véget a vitának. Szemével megkereste Jankát, mikor látta, hogy a szobájában van, halkan megjegyezte.

- Jack megfojtotta a kisnyulat.

- Miért nem zártad le a teraszt? - kérdezte Mari néni.

- Lezártam. Valahogy mégis feljutott.

- Jaj, ez szörnyű! - mondta Hedvig.

Karcsi bácsi ismét kiment, hogy eltüntesse a nyomokat. Janka közben megnyugodott és elment fogat mosni az apjával, Mari néni pedig leszedte az asztalt, közben folyamatosan düdörgött Hedvignek.

- Apád hibát hibára halmoz az idén, de ha mondom neki, akkor meg van sértődve. Miért nem viszi vissza azt az átkozott kutyát a menhelyre? Csak kárt okoz nekünk.

Kintről közben kutya nyüszítést lehetett hallani. Karcsi bácsi seprű nyéllel igyekezett móresre tanítani Jacket. Az oktatás után a nyúlmentes fészekbe kirakta az ajándékokat Mari nénivel és várták, hogy Janka végezzen a reggeli rutinnal.

A kislány futva érkezett. Csak kétféle sebességet ismert: a futást és a rohanást.

- Janka, megjött a Nyuszi!

- Hol van? - nézett körbe.

- Nincs itt, csak az ajándékokat rakta le.

- Ezek is az enyémek? - mutatott egy másik fészekre, ahol szintén rengeteg ajándék feküdt.

- Nem, azokat Bellának hagyta itt. Majd ők is átjönnek nem sokára.

Ez volt a varázsszó. Janka már nem is figyelt a saját ajándékaira, csak azt nézte, mi az, amit nem ő kap.

- Janka, nézd, te is ugyan azt kaptad, csak más a színe.

A kislányt ez nem győzte meg. Továbbra is meredten bámulta a "nem a tiéd" kosarat.

- Szeretnéd inkább azt? - kérdezte Mari néni. Janka bólintott, mire nagymamája heves pakolásba kezdett. A kislány ekkor észrevette, hogy az egyik ajándék egy főző készlet. Olcsó, fröccsöntött étel utánzatok voltak benne. A színek még csak köszönő viszonyban sem voltak azzal, amit utánozni akartak. Mindez mégsem számított. Janka magához ölelte.

- Apa, főzök neked levest - majd pillanatok alatt szétpakolta az egész készletet. A kis lábosba beletette a krumplit, répát, hagymát, húst, kenyeret, gyümölcsöket, tojást, tésztát, és minden egyebet, ami a keze ügyébe került. Úgy gondolta, minél több alapanyag van benne, annál finomabb.

- Nem nézed meg a többi ajándékodat? - kérdezte Mari néni.

Janka nem hallotta. Épp szalámit, uborkát és sajtot pakolt a képzeletbeli levesbe.

- A nyuszi nagyon szomorú lesz, ha nem nézed meg a többi ajándékodat.

A levesbe, de inkább annak tetejére egy kék gömb került, amit a család egyik fele zsemlének, másik fele narancsnak azonosított. Megkérdezték Janka véleményét is.

- Olívabogyó - vágta rá gondolkodás nélkül, figyelmen kívül hagyva a tényt, hogy ez volt a legnagyobb méretű összetevő.

- Kibontom neked ezt a buborék fújót - próbálkozott Mari néni.

Közben a kapu kinyílt. Megérkezett Bella, Nóra és Andor. Bár csak ötszáz méterre laktak, egy Toyota terepjáróval jöttek.

Mindenki üdvözölt mindenkit.

Bella meglátta, hogy Janka valami érdekes dologgal játszik, amit ő még korábban nem látott. Kinyújtotta kicsi kezét, úgy kérte.

- Ez az enyééém! - visította Janka, válaszul Bella sírni kezdett.

- Add egy kicsit oda neki - kiabálta túl a hangzavart Mari néni.

- De elvesziii!

- Majd visszaadja.

A hangzavart kihasználva Karcsi bácsi és Andor váltottak néhány szót.

- A kutya megfojtotta a kisnyulat - kezdte Karcsi bácsi.

- Várható volt, én ezért nem vettem Bellának. A kutyák nem bírtak volna magukkal.

- Akkor sem kellett volna megölnie. Ez a kutya nem normális.

- Mit vártál? Végül is egy ragadozó.

Közben Nóra Mari nénivel konzultált.

- Anyumat is elhívtam, nem baj? Itt találkoznánk. Eljön Réka és az új barátja is. Elviszik Bellát az állatsimogatóba.

Mari néni mit felelhetett volna? Természetesen azt, hogy nem baj. A gyerekek közben otthagyták a félig kibontott ajándékokat és inkább a kertben felállított trambulinba mentek. A korábbi veszekedést felváltotta az öröm hangja. A hangmagasság és hangerő mit sem változott. Továbbra is csengett mindenki füle.

A megbeszélteknek megfelelően megérkezett Nóra édesanyja, testvére Réka és Roland, akivel Réka randizik. Roland még nem ismert senkit, ezért neki minden egyes köszönés alkalmával random kérdésekre is válaszolnia kellett: Mit dolgozol, ki vagy, hányas cipőt viselsz. Roland előző életében politikus vagy szakkommentátor lehetett, mert mosolyogva vette az akadályt.

Bella és Janka újabb ajándékokat kaptak az újonan érkezőktől. Egy kiszínezhető párnát, rajta népszerű mentő állatkákkal, akik piszlicsáré problémákat úgy oldanak meg, hogy kivonul az egész bagázs. Földön, vízen, levegőben. Janka magához szorította a párnát és ugrált tovább. Hiába magyarázták neki, hogy színezze ki olyanra, amilyenre szeretné. Számára a hófehér párna a rózsaszín kontúr vonalakkal maga volt a megtestesült tökéletesség. Ebből is látszik, a felnőttek csak sémákban tudnak gondolkodni.

Mari néni, ahogy felszabadult a gyerekek felügyelete alól, berohant a konyhába és roham léptekben elkezdett ebédet főzni. Nóra és Hedvig is bement. Andor kint beszélgetett Rékával és Rolanddal. Karcsi bácsi elkezdte locsolni a veteményest. Tamás a gyerekekre figyelt.

Kis idő múlva Andor is belépett a konyhába.

- Elviszik Bellát? - kérdezte Nóra.

- Nem viszik sehova - jelentette ki Andor.

- Miért?

- Nem hoztak gyerekülést, nincs náluk pelenka és Bella délutáni alvásának idején akarnak ott lenni - közben Réka is belépett.

- Miért gond ez? Majd alszik a kocsiban.

- Nagyon nyűgös lesz, nem fogja érdekelni semmi - válaszolta Nóra. Visszahozzátok és nekünk fog hisztizni.

- Túl problémások vagytok - jegyezte meg Réka.

- Majd ha neked lesz gyereked, még visszakapod.

- De akkor sincs gyerekülés - vágott közbe Andor. Anélkül nem fogjátok elvinni Bellát sehova.

- Addig ellesz anyu ölében - legyintett Réka.

Andor és Nóra nem tágított. Rékáék lassan elbúcsúztak és elmentek. Bella szülei még mondták a magukét.

- Ezt még visszakapja tesóm, ha majd neki is gyereke lesz! - ígérte Nóra. Nekem mondja, hogy problémás vagyok!

Lassan eljött az ebéd idő. Mindenki asztalhoz ült és ebédelni kezdett. Mari néni újból kötelességének érezte, hogy megtömje sovány, alultáplált unokáját, aki egy tányér leves és rántott hús után nem akart enni sem sült tarját, sem szalonnába göngyölt csirkemájat, sem gyümölcs kenyeret, sem kakaós piskótát.

Az ebéd végeztével Mari néni elkezdte a tányérokat leszedni az asztalról. Hedvig segített neki.

- Jaj, a cipő! - kiáltott Mari néni fél úton a mosogató és az asztalok között állva, megrakva tányérokkal. Gyorsan letette, ami a kezében volt, és elviharzott az egyik szobába.

- Janka, gyere, ezt még elfelejtette odaadni a nyuszi! - mondta mindezt olyan hangerővel, hogy attól sem kellett volna tartania, ha Janka történetesen műtéti altatásban van. Akkor is hallotta volna.

Janka meg is jelent. Meglátta a világítós cipőt. A világítós cipő története múlt évben kezdődött, amikor az óvodában egyre több gyerek kapott olyan lábbelit, aminek az oldalán apró ledek világítottak minden egyes lépésnél. Nemsokára ez lett az elválasztó, hogy ki számít embernek és ki alsóbb kasztból valónak. A család szabályos hajtóvadászatba kezdett. Három város boltjait kutatták, de mindenhol azt mondtak, hogy elfogyott.

Nem sokkal Húsvét előtt akadt Mari néni egy párra, amit rögtön meg is vett. Majd a rumlikkal telezsúfolt szobában felejtett. Most, hogy eszébe jutott, félbe hagyott minden tevékenységet, Jankának is félbe kellett hagynia, amit addig csinált, sőt egy rejtélyes okból kifolyólag Hedvignek is. Mari néni a rumli szobába invitált mindenkit.

- Gyorsan vegyed fel! Nézzük meg, jó-e - mondta Mari néni, közben arra gondolt, hogy lassan indulni kellene, de még az edények sincsenek a mosogató gépben. Viszont azt is tudni akarta, hogy jó-e a cipő, és nem kell-e visszacserélni a jövő héten.

Janka viszont lenyűgözve bámulta a ledeket. A valóság számára leredukálódott néhány diódára, amit egy kínai üzemben egy cipő talpába ragasztottak és ami az első esőzés után valószínűleg be is fog ázni.

Mari néni végül nem bírta tovább, elkezdte felhúzni a lányra a cipőt. Talán a sietség lehetett az oka, hogy Janka zoknija felgyűrődött, és a csodálatos cipő költemény hirtelen spanyol csizma lett. Janka visított egyet, lerúgta a cipőt és nem akarta visszahúzni. Mari néni ismét bevetette kiképző őrmestereket megszégyenítő hangerejét, hogy finoman megkérje unokáját, próbálja meg újra felvenni a cipőt. De csak további visítás volt a válasz.

- Miért nem adtad rá a cipőt? - fordult Hedvighez. - Tudod, mennyi dolgom van. Mindjárt indulni kell. Nem tudok mindent én csinálni. A tányérok még mindig az asztalon vannak, még össze sem pakoltunk Miklóséknak. Egyáltalán ivott ez a kicsi?

Szerencsére ivott, ezért a támadás sorozat megszakadt. Mari néni koncentrálhatott többi dolgára.

A rendrakás és pakolás után kocsiba szálltak és indultak a közeli faluba, Karcsi bácsi testvéréhez, Miklóshoz. Janka ötszáz méter után elaludt. A többiek szótlanul ültek, nehogy felébresszék. Ez volt a nap legbékésebb része. Az autó motorja melankolikus monotonitással duruzsolt, az ablakon keresztül békés táj képe látszott. A forgalom is gyér volt, mindenki otthon ünnepelt.

A ház előtt parkoltak. Janka a hirtelen beállt csendre felébredt. Nyűgösen nézett körbe, szívesen aludt volna még. Az utastér megtelt az éles gyerek sírással. Mivel az autó két ajtós volt, nehéz volt megszökni a dobhártya szaggató hangoktól. Érezhetően felment a pumpa mindenkiben. A gyerekben azért, mert felébresztették, a felnőttekben azért, mert visított a gyerek. Mivel a gyereken senki nem akarta levezetni mérgét, az autó többi utasában kellett céltáblát találni.

- Ha csak én vagyok vele, soha nem csinálja ezt - jegyezte meg Mari néni. - Csak, ha ti is itt vagytok - vetette oda Janka szüleinek. - Rossz hatással vagytok a gyerekre.

A szülők pontosan tudták, mi van rájuk rossz hatással, de inkább hallgattak.

Beléptek a kapun, és a ház mögötti kertbe mentek. Andor családja már itt volt. Miklós a fiával (akit szintén Miklósnak hívtak) és lánya férjével, valamint Andorral egy mobil telefon kijelzőjét nézték. A hangszóróból foci meccs hangja hallatszott. Felesége, Eszter a lányával (akit szintén Eszternek hívtak) és a fia feleségével, valamint Nórával, egy alig pár hónapos csecsemő fölé hajoltak. Ő volt a legújabb jövevény. A nagyobb gyerekek, akikre már nem fordítottak akkora figyelmet, egy trambulinban ugráltak.

Karcsi bácsiék köszöntöttek mindenkit, majd a csoport felbomlott, és mindenki csatlakozott a kasztjához. Kivéve Tamást, akit a foci nem érdekelt, és a babát nem akarta fogdosni. Őt a gyerekek rángatták magukkal, hogy ugráljon velük a trambulinban.

- Tamást mennyire szeretik a gyerekek - jegyezte meg Nóra, de hirtelen új fejlemény történt. A kisbaba használatba vette a pelenkát és a női osztag egy emberként követte az anyukát, hogy a ház belsejében tanúi legyenek a pelenkacsere-rituálénak.

Fél óra múlva átjött a gyerekek dédanyja. Botra támaszkodva lépkedett, minden lépésre nyögött egyet. Amikor figyeltek rá, hangosabban tette. Hoztak neki egy széket, amin kényelmesen elhelyezkedett. Az egyik gyerek azonnal lecsapott a botjára és boldogan futkosott vele a kertben. Először puskát imitálva lelőtt mindenkit, majd rakéta lett és röpdösött vele.

- Ne vedd el a dédi botját - mondta Miklós első unokájának, de olyan lágyan, mintha megdicsérné.

Amikor a nap a látóhatár felé közelített, mindenki búcsúzkodni kezdett. Mentek a puszik jobbra-balra. Autóba ültek és hazamentek, hogy a két nap múlva visszatérjen egy megszokott, pihentető hétköznap.

Szólj hozzá!

Címkék: irodalom

De-novo 10x módra

2019.08.18. 22:05 Travis.CG

A nagyobb genomok összeszerelésénél sajnos a hosszú readek még nem állnak olyan szinten, hogy rutinszerűen alkalmazzuk őket. Lehet még vegyes hosszúságú inszert mérettel hibrid összeszerelést csinálni, hosszú és rövid readeket kombinálni. De jelenleg bármelyik módszert is alkalmazzuk, a homológ kromoszóma szakaszok kifognak rajtuk. Egyszerűen túl nagy a távolság hasonló genomi szakaszok között, hogy bármivel is átérjünk őket, vagy a sorrendjüket megtudjuk.

Ezért a 10X Genomics egy bárkódolási eljárással megjelöli a nagyobb fragmenteket. Szekvenálásnál ezért tudjuk, mely readek tartoznak össze. Egy plusz hozadéka is van a jelölésnek: ismerjük az anyai és apai kromoszómákat is!

Természetesen a módszer mit sem ér, ha nincs hozzá szoftver. Szerencsére a cég ezt is elkészítette, és Supernova néven teszi elérhetővé. (Természetesen miután regisztráltunk, elfogadjuk a sok spamet, stb.)

A Supernova egy, sok processzoros rendszeren  fut, minimum 32 maggal és 256 vagy 512 MB RAM memóriát használnak (genom mérettől, repetitív szakaszok hosszától függően), klaszterek szóba sem jöhetnek. Saját feladat ütemezővel rendelkezik, amit a cég fejleszt Go nyelven. A neve Martian.

A Supernova másik érdekessége, hogy képes közvetlenül az Illuminás BCL fájlokon futni, ezért függőségként kell neki a bcl2fastq.

A program paraméterezése elég egyszerű, igazából a legtöbb magához a bcl2fastq-hoz kapcsolódik. Futás közben rengeteg fájlt és könyvtárat dobál szét, teljesen átláthatatlan, hol is tart. A logok semmit mondóak. A folyamat nyomon követésére a projekt helyén található ASSEMBLER_CS/_ASSEMBLER könyvtárban található alkönyvtárak adják a legjobb támpontot, mert ezek a nevek megegyeznek a dokumentációban található lépésekkel.

A végén rengeteg bináris fájl lesz az eredmény, amiből egy újabb lépéssel lesz FASTA fájl. Négy lehetséges kimenet van. Az első, amikor minden darabkát visszaad. A második a kisebb eltéréseket összevonja (a gráfban ezek kis buborékokként jelennek meg), a harmadik egy haplotípust ad vissza, végül kérhetjük, hogy mindkét haplotípust adja vissza.

Mi nyúl genom összeszerelésre használtuk. A cég szerint elsősorban humán genomra fejlesztették, de annál nagyobb, vagy erősen repetitív genomokra nem javasolják. A mi esetünkben ez nem áll fenn, ezért nyugodtan használhattuk. Ismét csak az a kérdés, hogy a valóság mennyire adja vissza a brosúrák marketing szagú eredményeit, ezért az egyik könyvtárat összeraktam Discovar-denovóval is.

A scaffoldok száma Discovar-denovóval 240 ezer volt, ez lecsökkent 173 ezerre, ha Supernovat használtunk. Az N50 drámai különbségeket mutatott. A bárkódot nem használó módszer csak 1500 körüli hosszúságot adott, míg a másikkal ez az érték 50 ezer lett. Amikor visszaillesztettem a scaffoldokat a genomra, lefedték annak 91%-t!

Viszont észrevettem egy másik érdekes dolgot is. A legtöbb scaffold egymáshoz közel illeszkedett a genomra, kevesebb, mint egy read távolságra. Arra gondoltam, ezeket még közönséges paired-end szekvenálással is össze lehetne rakni.

disthist.png

Az egyik hipotézisem az, hogy ezek a nagy fragmentek, amelyek határán már más bárkód van, ezért a program itt megáll. A másik hipotézis, hogy kópiaszám változások vannak ezeken a helyeken, amelyek eltérnek az anyai és apai kromoszómákon.

Ez utóbbinak kicsit ellenmond, hogy a fenti eloszlás akkor is megmarad, ha csak azokra a scaffoldokra rajzolom ki, amelyek méretbeli eltérést mutatnak az anyai és apai kromoszómákon.

Végül a RaGOO-val könnyedén összeraktam őket. A nem-kromoszómális darabok itt sem illeszkedtek a kromoszómákra, viszont kaptunk új régiókat. Ebben az is közrejátszott, hogy másik nyúlfajtát raktunk össze.

A 10x módszere valószínűleg a legjobb megoldás eukarióta draft genomok összerakására. A szoftver nem éri el egy céges termék színvonalát, de az akadémiai bioinformatikai programok közül nem lóg ki. Az eredmény megbízható, de mindenképp szükség van további munkára, A rendszerben még van potenciál, lehet fejleszteni.

Szólj hozzá!

Címkék: bioinformatika

Molekula azonosítóval a szekvenálási hibák ellen

2019.08.11. 21:40 Travis.CG

A variációk azonosítása a kutatásban nem bonyolult feladat. Elég régóta fejlesztenek megoldásokat és javítják a meglévőket. Bár a mutációk detektálási pontossága nem 100%, a mintaszám növelésével meg lehet találni azokat a mutációkat, amelyek egy jó publikációhoz elegendőek.

A klinikai diagnosztika viszont teljesen más tészta. A kutatásban megengedett pontosság itt már nem elég. Arra sincs lehetőség, hogy több mintát szekvenáljanak, elvgére csak egy beteg van, akinek megfelelő kezelés kell.

A pontatlanság egyik forrása, hogy a DNS átírás során a polimeráz hibázhat. Ha ez a hiba a PCR sokszorozás előtt (vagy egy korai ciklusban) történik, akkor a hibát több readben is látjuk. Hibásan leolvasott mutáció más okból is keletkezhet, de azokkal most nem foglalkozunk. Koncentráljunk csak a PCR hibákra.

Erre a problémára fejlesztettéki az UMI-t (unique molecular identifier). A lényege, hogy megjelölnek minden egyes eredeti, az izolálásból származó molekulát egy egyedi szekvenciával, aminek segítségével aztán a read nyomon követhető. Ha a mutáció több, de csak egyféle kóddal jelölt readekben fordul elő, akkor az jó eséllyel egy hiba.

A jelölés random primerekkel történik, de arról nem találtam információt, hogy mennyi az esélye, hogy rosszul azonosítják a szekvenciát. Elméletileg ugyanis ha pont egy UMI-ban van egy hibás leolvasás, akkor másik UMI-ként azonosíthatják azt, holott a két szekvencia ugyan olyan eredetű.

Természetesen, ha az UMI ligálás előtt történik egy hiba, az szintén fals pozitív mutációként jelentkezik.

De lássunk inkább egy példát, mit is jelent mindez a gyakorlatban.

A jelölt szekvenciák mutáció keresésére az smCounter2-t ajánlja a gyártó. A programot megpróbáltam telepíteni, de végül feladtam. Felváltva használja a Python2-t és Python3-t, ugyan azok a csomagok kellenek mindkét rendszerhez, de erre is csak próba-szerencse alapon jöttem rá. Szüksége van még néhány, szinte beszerezhetetlen programra.

Végül Dockerből futtattam, azzal nem volt gond. A futáshoz szükség van a targetált régiókra BED formátumban és egy primer fájlra. Ezt a fájlt a gyártó oldaláról tudjuk leszedni.

Volt egy kisebb kaland, aminek során megpróbáltam magam elkészíteni a primer fájlokat (mert a bioinformatikusok és a laborosok nem tudták érthetően elmondani egymásnak, milyen fájlokra van szükség) a BED és a genom alapján, de a program nem volt hajlandó futni vele. Rendszeresen azt a hibaüzenetet adta, hogy nincs elég szekvencia. Ez egyébként jellemző hibaüzenet, ami a hibás primer fájlra utal (amennyiben tényleg rendben vannak a szekvenciák)

A program futásához a paramétereket egy fájlban kell összegyűjteni. A felépítése a régi INI fájlokra hasonlít. Ha több szekvenálás eredményét is fel akarjuk dolgozni, az összes adat elérési újtját betehetjük egy paraméter fájlba, és a program parancssorában egy cimke megadásával mondhatjuk meg, melyik rész kerüljön feldolgozásra, de erről a dokumentáció részletesen ír.

Rengeteg végeredmény lesz. Kezdve a különböző illesztésektől, a kibontott FASTQ fájlokig. De még egy minden nukleotidot tartalmazó táblázatunk is lesz! Ez utóbbi segítségével vissza lehet nézni, miért nem talált meg egyes variációkat a program. Viszont ezek együttesen rengeteg helyet foglalnak el.

Kapunk viszont annotációt az eredményekhez, ami nagy pluszt jelent. Nem éri el a VEP teljességét, de elég részletes.

Még egy fontos megjegyzésem van. A program csak hg19-re működik, mivel a cég targetáló kitjeit is erre a genomra tervezték.

A pontosságról nem sokat tudok mondani, de álljon itt egy táblázat, ahol a "hagyományos", nem UMI alapú variáció kereső programmal hasonlítottam össze. Minden sor egy minta. Ez csak tájékoztató jellegű adat, nem igazi mérés. Az indeleket nem is vettem bele, mert azok pozícióját az egyes programok máshogy adhatják vissza. A hagyományos keresőt nem is én futtattam, túl sokat nem tudok róla mondani.

Közös Hagyományos smCounter2
46 56 58
43 61 113
57 58 69
57 60 59
41 43 53
36 39 47
43 50 131
61 65 79
55 57 75
51 52 64
44 56 55
54 55 74
51 55 126
47 98 56
34 37 44
44 46 53

Számomra elég megdöbbentő az eredmény. Azt vártam volna, hogy a "hagyományos" keresés megtalál mindent, amit az smCounter2, de több fals pozitívval. Ennek ellenére hiányoznak variációk. A lefedettség elég jó volt, egyes helyeken 2000 feletti, mert erősen targetált szekvenálás volt (80 körüli génszámmal), ezért azzal nem lehetett probléma. A hibás térképezést is minimálisnak gondolom, az előbbi okból kifolyólag.

Szúrópróba szerűen kiválasztottam pár variációt, amit a hagyományos szekvenálás megtalál, de az smCounter2 nem. Ezek közül némelyik 0 lefedettséggel fordult elő az smCounter2-es analízisben, ami feltehetően visszamaradt adaptor szennyezés lehetett a read végeken (talán épp egy UMI szekvencia?), de ennek jobban utána kellene menni. Másokat pedig csak egy irányból érkező readek tartalmazták, ami miatt az smCounter2 kiszűrte őket.

Úgy látszik, mégsem olyan egyszerű a mutációk detektálása, mint azt korábban gondoltam. Két különböző technológia elég eltérő eredményt ad. Személy szerint sokkal kisebb különbségeket vártam volna. Milyen eltérések lehetnek egy teljes genom szekvenálásnál?

Szólj hozzá!

Címkék: bioinformatika

Cseppet sem objektíven: Assembly 2019 (II. rész)

2019.08.03. 23:27 Travis.CG

Eljött a második nap. Most lesznek a futtatható cuccok.

Tuplain compo

Ez egy olyan kompó volt, ahol egy YouTube videóra egy másik videó hangját keverték egy online eszközzel. A cuccok nem voltak emlékezetesek, mert a programon nem sok beállítási lehetőség van. Egy volt érdekes. SlySpy zenéjére egy time laps autó vezetést raktak. A kocsira kb. 6 kamera volt szerelve (egyes kamerák a kamerákat vették). Erre nagyon jól illeszkedett a zene. A többinél mindig érezhető volt, hogy a zene nem ide tartozik.

1k intro

Az első mindjárt egy Windows Power shell melódia. A képernyőn nem sok történik, csak egy ellipszis növekszik. A második egy plazma, némi zajjal. Aztá egy JS, amivel kirajzolták a zenét, mármint annak hisztogrammját, de több távolságban, mintha egy erdő lenne. Zeneerdő! Még egy böngésző intró: színes ajtók, de zene nélkül. Utána jöttek a mozgó téglatestek, de már zenével. A következő böngésző demóban valami mozgott a kamera felé. Á, ezek halak akarnak lenni. Ügyes! Újabb JS demó. Egy félbetört valami, ami a zenére mozog. Kezd összeforrni. Mi a csuda? Oh, a zene meggyógyította a szívet. Micsoda művészet! Ezeket szeretem, amiben van egy kis történet. Nagyon jó volt. Még egy böngésző: valami cellulár autómata, de a "zene" bántja a fülem. Metaball hadsereg halad a barna folyosón a fény felé. A címe mindent megmagyaráz: A reggel, amikor a mexikói étel keresi a kijáratot. Még egy raymarching, de pixelek helyett emoji karakterekkel kirajzolva. Nevezzük akkor inkább emoji marchingnak? A HBC 1k-t csinált, ők a következők. Folyadék szimuláció, de közben felolvassa a shader forráskódot egy beszéd szimulátor. Ügyes, nagyon ügyes. Az újabb intróban fekete golyók masíroznak. Lepottyannak, összeállnak. Digimind-al véget ért a böngészők demója, mostantól csak C++ lesz. Ők egy raymarching folyosót készítettek. Érezhető a minőségi ugrás a böngésző demók után, Végül egy felhős raymarching. Tetszett.

4k intro

Egy tron-szerű demó, ahol egy mountain bike mássza a dombokat. Aztán shadert vált, de továbbra is dombon mászik. Oké, megjött az első fraktál demó, a második release formájában. Közben dubstep. Az End of Iceland, a harmadik intró egy tájképpel indít. Majd jön a lárva. Nos, technikailag nem lárva, mert már szárnya van, tehát kifejlett lény. Aztán a tájkép tűzbe borul. A következő is hasonló, csak itt nem rajzfilm-szerű shader van, az élek például feketék, és nem lárva jön, hanem egy repülő kígyó. Terrarium: ez fotorealisztikus üvegek között mászkál a fény. Ezt meg kell néznem valódi vason is. Ez biztos nagyon érdekes. Az utolsó ismét egy felhős raymarching, csak úgy, mint 1k-ban. De a felhők közül egyszer csak kijön egy kétfedelű felhő-repülő. Nem semmi, nem semmi. Mikor azt hinnénk, már mindjárt vége, akkor jön a felhő-vonat!

64k intro

A chaten azt olvasom, nem lesz Conspiracy, de azért én nem félek attól, hogy nem lesznek jó cuccok. Egy Linuxos 64k-val kezdünk, LA1984 néven, ami a Terminator első részét eleveníti fel. Nem, nem az akciót, hanem a szöveges bevezetőt. Majd jön az 1989, zaj, non figuratív elemek, mintha egy Paintttel készült volna. Browser demo egy piramissal, majd jöttek a tükröződő golyók. Oké, oké, mostantól biztosan jön a komoly szakasz. Eddig csak a bemelegítés volt. Ah, vége az egész kompónak. Ennyi volt. Valaki a chaten azt mondta, hogy olyan magas a léc 64k-ban, hogy sokan inkább visszatartják az intrókat, mintsem kiadják. Én is ezt látom. Két szint van: a vállalhatatlanok és az über jók. Nincs középmezőny.

Demo

Már nem merek semmit mondani. Jöjjön, aminek jönnie kell. Az első szó szerint egy ürülék. Még jó, hogy úgy harangozták be ezt a kompót, mint amire a mai számítógépek képesek. A streamen meg a "where the magic happens" van. A második Python demó, de csak egy scroller. A harmadikban már effekt is volt. Olyan, mintha valakinek az első produkciója lenne. Kellemes volt a zene is, kicsit hosszúak voltak az egyes részek. A következőkben egy absztrakt valamit kapunk, amiben a számítógépek elpusztítják az emberiséget? Talan erről szólhat, de ezt is csak a szövegből tudom, mert a képi világ teljesen elvont. Majd jön egy egy emberes produkció Gambler néven. Majd Ozymandias C# demó. Egyszerű, de nagyszerű. A csapat láthatóan grafikus gondokkal küzd. Utána egy böngésző demó a 90-es évekből, amiben egy PC képernyőjén a nagy nevű csapatok láthatóak különböző hibaüzenetek társaságában. Végül a monitor elsűlyed, a Pc demoscene meghalt. Másoknak is ez a véleménye a chaten. Aztán valami party invitáció következik. Demók voltak a demókban, mármint a demóban számítógépek voltak, amelyek demókat játszottak le. Előnye, hogy állítólag Linuxon is fut. Folytatódott a tavalyi kenyér űrhajó utazása. A cél állomásig még nem jutottak el. Ígéretük szerint lesz egy harmadik rész is. Majd az Ate Bit csinált egy elvont demót, nem is tudom mi volt benne. De láttunk várost, embereket egy szobában, tunnelt. Valamiről biztosan szólt, csak nem értettem. Aztán jött a Hypertension zajdemó. Valaki azt írta róla, hogy a migrén vizuális reprezentációja. Tökéletesebben ki sem fejezhettem volna magam. Jugz Unity demója Forgott valami bigyó egy parkolóházban és megjelentek-eltűntek kockák. Aztán Pyrotech demó. Végre! Bár nem volt túl sok kapcsolat a részek között, nagyon szép jelenetek voltak. Az óramű belsejét mutató jelenet nagyon tetszett. Azt élőben is megnézem, ha majd jó lesz a gépem. Aztán Adapt! Kicsit zavart az elfolyó effekt, de azért nem volt rossz. Szóval itt a középmezőny. Kellett nekem elkiabálni. Ennek a kompónak is vége.

Összefoglalás

Az idei Assembly gyengébb volt, mint a korábbiak. Nem mondom, hogy katasztrofális, mert azért minden kategóriában láttunk valami érdekeset (64k intrót kivéve). Ez most megint egy hullámvölgy, mint amilyen három éve is volt. Akkor sem voltak 64k-k, demóban pedig hiányzott az első vonal. Most ugyan ezt történt.

Szólj hozzá!

Címkék: demoscene

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