utpKabel blogja

Ráütötték a pecsétet, megvan az új szabvány.

http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

28:40

Ez most komoly?

Jó néhány dolog történt mostanában a Lisp interpreterem (előzmények: 1, 2, 3, 4) háza táján. Nagyobb fejlesztések: végre vannak számok a Lisp rendszeremben, valamint a

quasiquote

implementálása makrók segítségével. A makrókról és a jövőbeli tervekről szeretnék még részletesebben írni, valamint említést teszek még néhány apró fejlesztésről.

Minimális Lisp interpreter készítő sorozatom újabb részét részét olvashatjátok (előzmények: 1, 2, 3). Először néhány kiegészítés lesz a tail-call optimizationről, majd következik a read-eval-print loop és makrók tárgyalása.

Eddig még nem említettem, de egyébként az interpretált Lisp nyelvvel kapcsolatos tervezési döntéseimmel alapvetően a Scheme R5RS változatát követem, de nem szigorúan, szóval ha valamilyen okból praktikusabb, akkor egyszerűen eltérek tőle.

Minimális Lisp interpretert készítő sorozatom előző részében arról számoltam be, hogy az értelmezőnek már lehetséges rekurzív procedúrákat megadni, amiket helyesen futtatni képes. Ma sikerült egy végtelen ciklust ábrázoló végtelen rekurzív függvényt úgy futtatni, hogy az "soha" nem ér véget, azaz a végtelen rekurzió nem szakad meg memóriaelfogyás, veremtúlcsordulás vagy egyéb probléma miatt, hanem stabil memóriafogyasztás mellett szépen pörgeti a processzort, amíg le nem lövöm a processt.

Ehhez alapvetően két összetevő volt szükséges: garbage collector és tail-call optimization. Garbage collector azért, hogy az "iterációk" során létrehozott, de később már fölösleges objektumok felszabaduljanak. Ellenkező esetben folyamatos memóriaszivárgás miatt utóbb elfogyna a memória, ami a program összeomlását okozná. Tail-call optimization pedig azért kell, hogy "visszacsinálja" azt, hogy egy ciklust rekurzióval írunk le, mivel (egy egyszerű) funkcionális nyelven csak így lehet. Ellenkező esetben, a rekurzió naív függvényhívásos implementációjával a stack folyamatosan növekedne új frame-ekkel, ami nem mehet a végtelenségig.

A korábbi fejlemények után végre megcsináltam a

set!

és az

if

formákat. A set! felülírja a változók (= environment elemek) értékét, if az elágazáshoz kell.

Ezzel lehetővé vált, hogy végre rekurzív függvényeket fogalmazzak meg.

Mivel számok nincsenek, listák és logikai típus viszont van, vegyünk egy nagyon egyszerű függvényt: a függvény állapítsa meg, hogy a kapott lista elemeinek száma páros-e.

Egy csomó embernek megfordult már a fejében, hogy minimális Lisp interpretert írjon otthon csak úgy hobbiból [1, 2, 3, 4]. Hát nekem is ez a hóbortom támadt, ezért beállok (n+1)-ediknek.

Ez a blogbejegyzés azt a győzedelmes pillanatot hivatott megörökíteni, midőn először futott az általam írt eval-apply ciklus.

Időről időre újra és újra felmerül bennem a gondolat, hogy talán Slackware-re kellene váltani. Vonzó az egyszerűsége, ahogyan egyszerre friss és stabil a rendszer, mert bár új csomagverziókat használ, technológiaválasztásban mégis konzervatív, a hivatalos csomagok pedig jó minőségűek.

Chrome-ról Firefoxra.

Röviden: a Chrome kezdeti előnyeit (gyorsaság, kényelmes tabkezelés, vékony fejléc) a többi böngésző sikeresen lemásolta, míg - egyéni érzésem szerint - a Firefox közben megőrizte előnyét az extensionök területén.

Épp az extensionök miatt a Firefoxtól soha nem szabadultam meg teljesen, noha jelenleg Windowsön inkább Chrome-ot használtam, miközben Linuxon már csak Firefoxot, mert Linuxon a Chrome valahogy problémásabb volt, mint Windowson. Jelenleg a Chrome egyetlen erős pontjának a beépített PDF olvasót érzem, illetve azt, ahogyan az a Google szolgáltatásaival együttműködik.

A monád fogalom megértésének útján eljutottam ahhoz az állomáshoz, amikor megírtam életem első monádját. Ez a monád álvéletlen számoktól függő eredményt reprezentál. Lehetséges, hogy ekvivalens valamelyik "gyári" monáddal, nem ismerem még mindegyiket.

A teszteléshez Monte Carlo elven működő pí-számolót csináltam. Íme a kód:

Egykoron elégedett KDE3 felhasználó voltam. Jó volt, szép volt, tudott mindent, ami akkor kellett. Aztán jött a KDE4, ami noha még nem a KDE4 volt, de a disztribúciók mégis azt kezdték el szállítani a KDE3 helyett, és ezzel a KDE3 oda lett...

Vizsgálgattam kicsit a "még nem KDE4" KDE4-et, de mivel funkciószegény, bugos és kevéssé esztétikus megjelenésű volt, így mégsem nyerte el a szívemet. Nem emlékszem már milyen próbálkozásokkal, de végül a GNOME2-nél kötöttem ki.

Amíg a KDE egykori önmagát sem tudta utolérni, a GNOME szépen fejlődött tovább. Egyszerű volt, de kiforrott és jól használható. Aztán őket is elkapta valami őrület, és jött a GNOME3.

A kódot frissítettem. Most még egyszerűbb, és hozzáadtam néhány sort kommentet.

-- Összes prímszám listája
primes = 2 : filter prime [3,5..]

-- x prím-e?
prime x = check primes x

-- (p:ps) prímszámok listája növekvő sorrendben
-- x      tetszőleges szám
-- eredmény: x prím-e?
check (p:ps) x
    | p*p <= x  = (x `mod` p /= 0) && check ps x
    | otherwise = True

Ez a blog az Építsünk saját GNU/Linux rendszert! (#1, #2, különkiadás, #3, újraélesztés) című blogsorozatom folytatása. Ez a rész gyakorlatilag a második rész ismétlése, az előző részben említett felülvizsgált célkitűzések és frissített szoftverek mellett. Javaslom a második rész (ismételt) elolvasását, mert az ott leírt összefoglalót nem ismétlem meg, csak az újdonságokat és a változásokat tárgyalom részletesen.

Tavaly ilyenkor kezdtem el nagy sikerű Építsünk saját GNU/Linux rendszert! blogsorozatomat (#1, #2, #3, valamint lazán kötődik a csomagkezelésről általában írt összefogalóm). Ha átnézitek a belinkelt részeket, láthatjátok, hogy írtam a célkitűzésről, ledokumentáltam az ideiglenes /tools rendszer építését, és leírtam, hogy hogyan lesz majd pacmannel a csomagkezelés a végleges alaprendszerben. Viszont arról már nem esik szó, hogy elkezdem építeni magát a rendszert. Valójában addig jutottam el, hogy felépítettem az alaprendszer csomagkezeléssel, be is lehet bootolni, és utána azzal küzdöttem, hogy valami upstart alapú párhuzamosított rendszerindítást faragjak, de ez kemény fának bizonyult.

Tud-e valaki olyan telefon(szoftver)t, amelyik csipog, ha e-mail érkezik, ugyanúgy, ahogyan SMS esetében ez szokás? Secure IMAP-on keresztül kellene a kicsikének ellenőrizni, hogy mikor jön e-mail.

Ötlet? Vagy ilyen csak akkor lehet, ha barkácsolok magamnak valamelyik open telefonplatformból?

Szerkesztés. Hogy még egyértelműbb legyen a dolog: Gmail fiókról lenne szó.

Eldöntöttem, hogy megtanulok valamilyen szinten Qt-ben programozni. Felraktam a disztribúció által szállított Qt 4.5-t development csomagokkal együtt, és letöltöttem a Qt Software (egykori Trolltech) által ajánlott C++ GUI Programming with Qt 4, Second Edition könyvet. Szerintem jó könyv, most eszerint haladok.

Tud valaki GRUB 2-t telepíteni közönséges partíció boot sectorába?

# grub-install /dev/hda11
grub-setup: warn: Attempting to install GRUB to a partition instead of the MBR.  This is a BAD idea.
grub-setup: warn: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and its use is discouraged.
grub-setup: error: If you really want blocklists, use --force.

Ezt kapom, és nem tudok vele mit kezdeni.

A ma reggeli

sudo aptitude -u

egy jelentős frissítést hozott: bekerült a Debian Squeeze-be (testing) a KDE 4.2.2.

A Debian ezeket a lépéseket akkor szokta megtenni, amikor tényleg eljött az ideje, de most úgy érzem, hogy backupolnom kellene a jól működő KDE 3.5.10-essel ellátott rendszeremet, mielőtt nekivágnák az ismeretlennek.

Itt az elején felhívnám a visszatérő olvasók figyelmét is, hogy bővítettem az első részt, valamint apró javításokat eszközöltem a másodikban.

Miért épp pacman?

Bevezetésképpen érdemes elolvasni a csomagkezelés feladatáról és eszközeiről általában írt cikkemet.

A saját rendszerem építése során a pacman csomagkezelőt használtam. Elsősorban a következő képességek miatt választottam:

... disztribúció, amely képes elfeledtetni velem azt a szomorú tényt, hogy GNU/Linuxot használok, csak a Debian.

Sokféle disztribúciót kipróbáltam már.

Ez a cikk egy gyengén kötődő kitérő az „Építsünk saját GNU/Linux rendszert!” című blogsorozatomhoz.

Egy saját GNU/Linux rendszer telepítése jó alkalom arra, hogy szembesüljünk a csomagkezelés hasznával és céljaival. A csomagkezelés elsőként felmerülő feladata a telepített csomagok törlése. Bár ritkán van szükség egy program eltávolítására, a csomag törlésének képessége szükséges ahhoz, hogy a frissítések folyamán megszabaduljunk a régebbi változat fölöslegessé vált részeitől. Tehát a rendszer korrekt karbantartásának alapfeltétele a törlés és frissítés megoldása.

Ha még nem olvastad, akkor most az 1. részt elolvashatod.

Amint a hivatkozási kézikönyv tárgyalja, először létrehozunk egy ideiglenes rendszert a /tools könyvtárban, amely tartalmazza a szükséges eszközöket az alaprendszer buildeléséhez. Mivel ez a tools könyvtár egy üres partíción foglal helyet, amelybe bele fogunk chrootolni, ezért ennek önmagában konzisztensnek kell lennie. Hiszen a chroot leszigeteli a host rendszer csomagjait, így a chrootban nem fognak működni azok a parancsok, amelyek 1) a host rendszer library-jaihoz linkelődnek; 2) olyan parancsokat hívnak meg, amelyek hiányoznak a tools-ból.

Az LFS könyv egy kitaposott utat mutat erre. Létrehozunk egy lfs nevű felhasználót, melynek csinálunk egy tiszta environmentet (úgy értve mint shell environment variables), ez csökkenti a host rendszer hatását a tools-ra. Másfelől, mivel az lfs egy mezei felhasználó, így ez véd a host rendszer szétcseszése és teleszemetelése ellen, amelyek igencsak nem kívánatos dolgok. A linker hackelése és a GCC specs fájlnának módosításával pedig elérjük, hogy amit csak lehet, a /tools library-jaihoz linkeljen.

Persz ha valami nem található meg a tools-ban, de megtalálható a host rendszerben, akkor azt a host rendszerhez fogja linkelni, ez pedig nem kívánatos, mivel ezek akkor nem fognak majd a chrootban működni. Emiatt figyelni kell a ./configure kapcsolókra, hogy a fölösleges függőségeket kikapcsoljuk, valamint arra, hogy a fontos függőségek pedig telepítésre kerüljenek a tools-ban. Persze, amint már fenn írtam, a könyv egy kitaposott út; a problémákkal akkor találkozunk, amikor úgy döntünk, hogy letérünk erről a kitaposott útról, és mondjuk GNU tar helyett bsdtar-t teszünk a rendszerbe, meg adunk hozzá csomagkezelést.

Elhatároztam, hogy építek egy saját GNU/Linux rendszert. (Nem új disztribúciót csinálok, mert nem célom, hogy másokkal megosszam, csak a saját szórakozásomra építem.) Akik kicsit otthonosan mozognak a témában, azok tudják, hogy az Linux From Scratch jó kiindulópont egy ilyen feladathoz. Én már egyszer végigcsináltam az LFS könyvet, és végül sikerült korrektül bebootolnom a rendszerbe. Akkor itt abba is hagytam. Most tovább megyek.

Jelentem, a CS 1.6 szépen fut a legújabb Wine-on, ráadásul gyorsabban cache-eli az adatokat, mint azt Windowson szokta.

Nem hivatalos ígéretek, hanem tudományos módszerek alapján állíthatom, hogy a Debian Lenny február közepén érkezik. A mélyfagyasztástól a jelen pillanatig tartó intervallumon vett differeciahányadossal számolva, Taylor polinommal közelítve az RC bugok számát, a módszer azt jósolja, hogy február közepe körül kerül sor a kiadásra.