Egy beteg srác naplója

programozás

A kiterjeszthető szövegeditor felépítéséről

Az Emacs erőssége abban rejlik, hogy programozható editor. Persze bármelyik editor programozható, akár a Gedithez (neked Vim) is írhatsz Pythonban bővítményeket, és még meg sem kell tanulnod egy új nyelvet, pláne nem egy Lispet (sic!). Az Emacs erőssége és bonyolultsága viszont tényleg abban rejlik, hogy magát az editort programozhatod. Másképp fogalmazva – fejlesztői szempontból – az Emacs egy hatalmas kódtár; ha úgy tessék, egy Elisp API. Ez persze nem teljesen igaz. Nem igaz abban a formában, hogy az API az alkalmazás fölé emelt, jól definiált réteg, amin keresztül külső bővítmények (pluginok) az API alatt meghúzódó alkalmazással kommunikálhatnak, annak szolgáltatásait használhatják, és azokra épülve egészíthetik ki annak tudását. (Az ábrák Benjamin Ferrari: Emacs is different értekezése nyomán.)

Ábra: átlagos szövegeditorok felépítése Plugin API-val

Az Emacsban az API maga az Emacs. Emacsban – amikor API-ról beszélek – magát az Emacsot értem, nem egy mezsgyéjét a kódoknak, hanem az editor teljes forráskódját, amelynek bármelyik része elérhető, módosítható, kiterjeszthető. A te kódod (bővítményed) ugyanabban a szegmensben lesz, mint a mag fejlesztőinek kódja, nincs egy éles határ (ld. API) húzva a kettő közé.

Ábra: az Emacs szövegeditor felépítése Plugin API nélkül

Tényleg nyílt forrású, és abban az értelemben is, hogy nem csak tanulmányozhatod a kódot, hanem tetszés szerint, futás időben is változtathatod annak működését. (Nem forkolod az alkalmazást, hanem testreszabod.) Gedithez is írható Last.fm plugin, sőt, meg merem kockáztatni, hogy talán még triviálisabb is: import LastFm. Az Emacs előnye akkor jelentkezik, amikor olyan funkcionalitást vagy úgy szeretnél, amire nem vagy nem úgy kínál megoldást a (plugin) API, és ez a gondolat elvezethető egészen olyan szélsőséges esetekig, mint amikor a CVS Emacsban megjelent bugot átmenetileg egy advise-zal (neked decorator) orvoslod.

Éppen ezért emacsos kiegészítő (terminussal élve: mode) fejlesztésekor külön azzal foglalkozni nem szükséges, hogy rögzítsük az alkalmazás program-interfészét. A lispes alulról felfele építkezés és az a tény, hogy bármelyik függvényünk vagy változónk mások fejlesztése során felhasználásra kerülhet, kikényszeríti, hogy a teljes kiegészítő rugalmas és biztonságos legyen, és szükség szerint API-ként funkcionáljon egyéb komponensek felé.

‘That’s not a bug—it’s a feature’

Én azért örülnék nekik, ha a zéeshás fiúk a tengernyi hasznos fejlesztés mellett azért megmaradnának a Bash-kompatibilis ösvényen, már csak azért is mondom, hogy egy triviális lépésen ne hasaljon már el a skript, és ne kelljen flash42 hozzá, akinek meg a freedone-on redondos mondta meg, hogy t.i. a $lol-nak a $~lol a megfelelője zéháesben, ha

lol="*"
echo $lol // és itt asszinnéd hogy, közben dehogy,

mert zéeshá meg persze mit ír ki, egy nyamvadt csillagot, nem könyvtárlistát. Nem raj, baszki. Viszont interaktív kommunikációhoz egyszerűen annyival jobb a zéeshá a bashhoz képest, hogy azt már úgy is leírtam.

flash42
Note that these patterns, along with the replacement text of any substitutions, are themselves subject to parameter expansion, command substitution, and arithmetic expansion – vagyis a paraméter helyettesítés után csak ezek történnek meg.

Azt néztem amúgy, az `eval echo $lol` keresztplatformos megoldás lenne, de flash42 megdorgolt, hogy ninja ilyet nem csinál. Lól.

How to import functions from a bash script?

Consider the following in your shell script ~/bin/libary:

#!/bin/bash
lol() {
      echo LOL
}
export -f lol

Now in ~/bin/the_hard_stuff, you can use your previously defined library function lol like:

#!/bin/bash
. ~/bin/library # "import module"
lol             # simply refer to the exported function

Now you know how to write reusable scripts, go and hack.

$perl6 → ‘lispy

Az őrültet a zsenitől. Larry Wall még sohasem hallott a Lispről és nyelvjárásairól, ezért a Perl 6-ból Lispet csinál serényen (lisper := Lisp Perl, ha-ha).

„No computer language has ever taken extensibility seriously. All languages fall into the one true syntax syndrome, and we want to escape that [...] Perl 6 has no core, no keywords, no built-in operators. Everything that looks like an operator is actually defined by some grammatical rule or by a macro or by something that is added in.”

Minderről az idei OSCON-on szólt. Wall úr gondolatai Joab Jackson Perl vision gets sharper cikkében. Említésre méltó, hogy Larry Wall gondosan a nyelvtani kiterjeszthetőséget emeli ki, amelyet ha úgy vesszük, valóban még nem produkált egyik nyelv sem. De vajon a legegyszerűbb szintaktikai formula nyújtotta tetszőleges szemantikai bővítésben rejlő lehetőség mennyivel rugalmatlanabb? Egyiknél a lexer–parser (M-expression), másiknál a reader (S-expressions) fejti ki az evaluator (meg ne nézze, mit ír erre asztaki!) számára értelmezhető objektumokat. A programozó szemszögéből a tetszőleges szintaktika bevezetése egyenértékű a legegyszerűbb nyelvtannal leírható tetszőleges jelentéstartammal. Ha lefölözzük Wall úr előadásának gondos mázát, türelmetlenül várjuk, hogy a medvét lássuk. Addig olvassák a tőlünk okosabbak okfejtéseit Lies, Damned Lies, and Perl 6 íráshoz érkezett hozzászólások során.

Arc: a kísérleti programozás új iskolája

Noha már mindenki lehozta, szerkesztőségünk mégis várt addig a pillanatig, amikor igazán elemében mutathatja meg az Arcot. Scott Hanselman A Web Framework for Every Language írásában felvonultat egy tucat tálalást annak az egyszerű kívánalomnak az implementálására, hogy a felhasználó által megadott inputot (i) funkciógombra (ii) kattintást követően megjelenítsük (iii). Scott legnagyobb örömünkre egy arcos példával nyitja a repertoárt, és a megoldás puszta léte olyan szűzies örömet sugároz, amelyet feltétlenül meg akartunk osztani szemérmes Olvasóinkkal. Így hát.

(defop said req
  (aform [w/link (pr "you said: " (arg _ "foo"))
                 (pr "click here")]
         (input "foo")
         (submit)))

Hogy ne várjon, töltse az interpretert, hozzá a módot, és boldogan, amit róla mások.

Hibajavítás a Claroline távoktatási rendszerben

D-val azt a feladatot kaptuk, hogy a Claroline nyílt forrású PHP/MySQL alapokra támaszkodó távoktatás keretrendszerben az ügyfél által észlelt problémát orvosoljuk. A hiba tárgya, hogy egy adott funkció elérésre (gyak. oldal betöltődése) az éles környezetben az adatbázis- és webkiszolgáló leállását, jobb esetben is 10–15 másodperces reakció időt produkált, amely az egyidejűleg a rendszerben tevékenykedő felhasználók számával csak romlott.

Az alábbiakban kronológiai sorrendben, időnk függvényében közöljük a nyomkövetés egyes fázisait, sejtéseinket, tapasztalatainkat, folyamatosan frissülő formában, míg el nem érjük a végső megoldást. A felhalmozódott tudást patch formájában az ügyfél kérésére a Claroline felé is visszajuttatjuk. A hibafelderítés, -javítás során visszajelzéseket szívesen veszünk, twit us. A Hibajavítás a Claroline távoktatási rendszerben című írás tovább is van »

One goes Emacs, never goes back

Azon felületen, amelyen akciókat egy grafikus mutató eszközzel lehet kiváltani, a támogatásával elvégzett feladatok hatékonyságukban sohasem mérhetők össze egy parancsszakkal vezényelt környezettel. Míg a pointeres környezetben tetszőleges tág időintervallumban indukálhatók olyan események, amelyek nem visznek közelebb a megoldáshoz, addig egy utasításokat fogadó bemenet késztetést ébreszt arra, hogy értelmes parancsot tápláljunk bele. Az One goes Emacs, never goes back című írás tovább is van »

Forráskód szellőztetése glasses-mode-dal

Az EmacsLife múltkori száma hívta fel a figyelmet az EmacsWiki NiftyTricks szócikkére. A tucatnyi hatékonyságot növelő tipp között bukkantam rá a glasses-mode-ra, amely a StudlyCaps kifejezéseket teszi olvashatóbbá azzal, hogy a váltó karakterek elé alsóvonást szúr – természetesen a forráskód tartalmi megváltoztatásának mellőzésével. Szintén a bővítmény viselkedése a függvények argumentumait, a vezérlési szerkezetek kifejezéseit határoló zárójelek előtti nem törhető szóköz szerepeltetése, amely a közkedvelt tagolási konvencióval igazán kívánatos eszköz egy programozó kezében.

Java forráskód glasses-mode-dal és anélkül

Köszöntjük Önt a nap Emacs tippje rovatunk olvasói között!

A piacot nagyon szeretem, mindig elfogyasztok egy lángost meg hosszúlépést, van hogy konyakot

De hogy stringet mivel konkatenál, az egy dolog, na de hogy VB terminológiában a frame a panel, az nálam kiveri a biztosítékot, öregem. Mert ha már Emacson (neked Vim) át Swingen keresztül mindenhol egységesen frame jelenti az ablakkezelő szempontjából önálló ablak komponenst (vagy legalább hasonlót), akkor az MS fityiszt mutat, és a bevett gyakorlattal szemben a frame-en (ráadásul itt form-on!) belül az általános célú konténer elemnek definiálja a keretet. Azt már meg sem merem említeni (zárójelben mindinkább), hogy a rádiógombok csoportosítására javallja a szakirodalom, de azokat még group-olhatjuk amúgy a PictureBox controlba is. Kérdem én szerényen, WTF? Persze köcsög dolog a VB6-ot nyársra húzni, amikor már itt a .NET, meg minden. (De hát ez az örökös kattintás, meg kell dögleni, á!)

Nekem nincs meg a új Radiohead album, lúzer, mi?

Ha tudnám ezt a Visual Basic-et mihez hasonlítani, felhoznám, hogy Lisp után olyan VB kódot ütni, mintha valami szűk repedésbe akarnád betuszkolni a falon. (És mindenhez klikkelni kell, á!) Láttam már egy–néhány programozási nyelvet, végig is futtattam a fejemben pár ismert jelölést, de hogy a string konkatenátor operátorra az & karaktert tartja fent, hát csókolom! (Látom ám, hogy az Adától lopta, de hát – á!)