Spotlight és Fuse = Kernel Panic?

Volt szerencsém egy-két kernel pánikhoz OSX-en. Szépen néz ki, ahogy elszürkül a háttér, és közli, hogy gáz van, indítsam újra a gépet, de viccesnek nem vicces. Viszont újraindítás után lehetőséget ad, hogy elküldjem a crash reportot, és nem mellesleg megnézzem az utolsó logokat.

Volt szerencsém egy-két kernel pánikhoz OSX-en. Szépen néz ki, ahogy elszürkül a háttér, és közli, hogy gáz van, indítsam újra a gépet, de viccesnek nem vicces. Viszont újraindítás után lehetőséget ad, hogy elküldjem a crash reportot, és nem mellesleg megnézzem az utolsó logokat.

Az első alkalommal nem sokat foglalkoztam vele, de amikor legközelebb előjött, akkor rájöttem, hogy akkor történt, amikor a külső merevlemezem csatlakoztatva van. A log tanulmányozása, illetve némi előismeret segítségével egy gyors googlizás kihozta, hogy nem én vagyok az egyetlen, aki a problémával szembesült, és volt rögtön workaround is.

A külső merevlemez NTFS-ként volt megformázva, amit a MacFuse és az NTFS-3G kombinálásával csatoltam fel. Ez a kernel panicot különösen súlyossá tette, mert az NTFS-3G nagyon érzékeny az érvénytelen adatokra – pl. abban az esetben, ha nem volt rendesen leválasztva Windows-os gépeken, akkor egyszerűen nem csatolja fel, stb. Szóval a kernel panicot követő meghibásodás után lehetett szórakozni vele, hogy újra csatolni lehessen. Szerencsére a VMware sokat segít azzal, hogy a külső USB portot átadhatom egy virtuális gépnek, így relatíve kis szívással átcsatoltam Windowsra.

Visszatérve az eredeti problémára a log alapján a bug akkor lép elő, ha a Spotlight próbálja indexelni a felcsatolt lemezt. A megoldás egyszerűen az volt, hogy ki kell kapcsolni az indexelést a Fuse-os lemezekre. A beállítás megtehető: System Preferences/Spotlight/Privacy

Természetesen ez bug, később még javíthatják. Ha ez megtörténik, akkor jelezni fogom.

További információ található a következő levelezőlista threadben: http://groups.google.com/group/macfuse/browse_thread/thread/cd7df99cb5d9cd7f/40bbbd3d13ece42c#40bbbd3d13ece42c

Margók a LaTeXben – grafikusan

A LaTeX egyik legbonyolultabb része a margók kezelése. Pláne, hogy a beállításait relatív módon kell megadni.

Ahhoz, hogy ezt kényelmesebben lehessen csinálni, hasznos tudni, hogy mik az aktuális beállítások. Ebben próbálok segíteni azzal, hogy röviden leírom a [[http://www.mackichan.com/index.html?techtalk/501.htm~mainFrame|MacKichan Software Inc.]] honlapján látható gondolatot röviden összegzem itt is.

A LaTeX egyik legbonyolultabb része a margók kezelése. Pláne, hogy a beállításait relatív módon kell megadni.

Ahhoz, hogy ezt kényelmesebben lehessen csinálni, hasznos tudni, hogy mik az aktuális beállítások. Ebben próbálok segíteni azzal, hogy röviden leírom a MacKichan Software Inc. honlapján látható gondolatot röviden összegzem itt is.

Nehéz pontosan meghatározni, hogy mekkora méreteket használ a LaTeX a kimenet generálásához, ugyanis az függ a dokumentum típusától, a lapmérettől, attól, hogy egy- vagy kétoldalas és még ki tudja, mi mindentől.

Éppen emiatt a bonyolult függések miatt egy táblázatba összeszedni sem feltétlen használható megoldás.

Viszont erre is van automatikus megoldás, ami a fordítótól kérdezi meg. Egészen pontosan ez a [cci_latex]layout[/cci_latex] csomag. A működés egyszerű: felvesszük a csomagot a [cci_latex]\usepackage{layout}[/cci_latex] preambulumba felvételével, majd a szövegbe beírjuk a [cci_latex]\layout[/cci_latex] parancsot.

Ennek hatására a LaTeX legenerál egy oldalt, amin felsorolja a paraméterek aktuális értékeit, valamint egy ábrát, hogy könnyebben át lehessen látni, hogy pontosan mi mit jelent. Egyszerű, nagyszerű.

Azért a végleges dokumentumból szedjük ki.:D

Hogyan írjunk diplomát?

Belefutottam egy blogbejegyzésbe, és úgy gondolom, megosztom, elvégre van egy-két ember az ismerősi körömben, akinek hasznos lehet. Egy kanadai egyetemista gyűjtött össze követelményeket, ötletek diploma- illetve disszertációírásra.

Pontosan emiatt némelyik meglehetősen nem mérvadó – pl. egy diplomamunkánál nem követelmény, hogy abszolút tudományosak legyünk, és csak a tudós objektív szemüvegén keresztül vizsgáljuk a dolgokat. De azért vannak hasznos tippek (már amit elolvastam belőlük – sok van, csak belenézegettem a dologba).

Belefutottam egy blogbejegyzésbe, és úgy gondolom, megosztom, elvégre van egy-két ember az ismerősi körömben, akinek hasznos lehet. Egy kanadai egyetemista gyűjtött össze követelményeket, ötletek diploma- illetve disszertációírásra.

Pontosan emiatt némelyik meglehetősen nem mérvadó – pl. egy diplomamunkánál nem követelmény, hogy abszolút tudományosak legyünk, és csak a tudós objektív szemüvegén keresztül vizsgáljuk a dolgokat. De azért vannak hasznos tippek (már amit elolvastam belőlük – sok van, csak belenézegettem a dologba).

Na jó, beszéljen most már helyettem az URL: http://compscigail.blogspot.com/2009/04/how-to-write-thesis.html

Remélem, valakinek segítettem ezzel.

Resource fájlok eclipse plugin extension-ben

Aki fejlesztett már Eclipse PDE felett, az talán találkozott a lehetőséggel, hogy egy extension point tulajdonság típusa lehet “resource” is. Ez annyit tesz, hogy a kiterjesztésben megadhatunk egy, a plugin-nel csomagolt fájlt. De a másik oldalon, az extension point beolvasásakor hogyan is olvassuk ezt be? Hiszen fogalmunk sincs honnan jött, melyik plugin adja az extension-t, és hol keressük a fájlt. A megoldás nem triviális, és kell egy kis kutatást végezni, hogy rájöjjünk. Én ezt megtettem, és igyekszem közérthető formában továbbadni.

Aki fejlesztett már Eclipse PDE felett, az talán találkozott a lehetőséggel, hogy egy extension point tulajdonság típusa lehet “resource” is. Ez annyit tesz, hogy a kiterjesztésben megadhatunk egy, a plugin-nel csomagolt fájlt. De a másik oldalon, az extension point beolvasásakor hogyan is olvassuk ezt be? Hiszen fogalmunk sincs honnan jött, melyik plugin adja az extension-t, és hol keressük a fájlt. A megoldás nem triviális, és kell egy kis kutatást végezni, hogy rájöjjünk. Én ezt megtettem, és igyekszem közérthető formában továbbadni.

A probléma, kicsit formálisabban: adott egy extension point, melyen egyik attributúma resource típusú. Mikor egy plugin extension-t csatol ehhez a ponthoz, az adott attríbutúmnak úgy ad értéket, hogy a programozó kiválaszt egy fájlt, amit a pluginnel együtt csomagolva ad. Az extension point-ot adó plugin pedig az ilyen módon regisztrált fájlokat szeretné beolvasni.

Amikor beolvassuk ezt az értéket az extension-ből, a fájl relatív elérési útvonalát kapjuk meg a plugin csomagjában. Első feladatunk tehát, megtalálni a plugin csomagot ([[http://www.osgi.org/javadoc/r4v41/org/osgi/framework/Bundle.html|Bundle]]), ahonnan az extension jött, hiszen abban kell keresni a fájlt is. Ha megvan a csomag, kérhetünk tőle egy URL-t a fájlhoz. A kapott URL azonban nem szokványos, “bundleresource:” előtaggal rendelkezik. Korábban létezett egy asLocalUrl() függvény, ami az ilyen jellegű URL-t hivatott átalakítani abszolút “file:” URL-é. Azonban ez a függvény a 3.2-es verzióban @Deprecated megjegyzést kapott, tehát ez nem a megfelelő mód a megnyitásra. Szerencsére azonban az ilyen URL-ekhez implementálták az URL.openStream() metódust, ami nyit egy megfelelő adatfolyamot a számunkra. Kicsit egyszerűsítve a kód valahogy így néz ki:


//Listázzuk az extension point-hoz csatolt extension-öket:
IExtensionRegistry registry = Platform.getExtensionRegistry();
IExtensionPoint point = registry.getExtensionPoint("ExtensionPointID");
for (IExtension extension : point.getExtensions()){
//Így kell lekérni az extension-t adó plugin csomagot:
Bundle bundle = Platform.getBundle(extension.getNamespaceIdentifier());
for (IConfigurationElement element : extension.getConfigurationElements()){
//A csomagon belüli relatív elérési út:
String path = element.getAtribute("resourceAttrib");
URL url = bundle.getResource(path);
InputStream is = url.openStream();
//...Olvasás...
}
}

PdfLatex – eps fájlok kezelése 2. felvonás

Lassan be kell adni a diplomatervet, szóval ideje megírni a hiányzó részeket. Ok, kicsit csalok a dolog kapcsán, hogy én az őszi TDK-mat bővítem ki/írom át diplomatervvé. Ezért még olyan nagyon nem vagyok elkésve.

A korábbi tapasztalatok alapján nekiálltam, hogy először is frissítsek egy keveset a munkakörnyezetemen. Komoly probléma volt a TDK beadás környékén, hogy egy-egy fordítás egy-két percig tartott. Amikor trial and error módon próbálja az ember a hibákat javítani, akkor hasznos, ha ennél gyorsabb.

Némi kutatás, illetve intelligencia után előkerült a probléma: régebben már itt is leírtam, akkor az eps fájlokból generált fájlokat átmásoltam a temp mappába, mondván, ott jó helyük van. A helyzet az, hogy hála ennek a sornak, a későbbi fordításokkor is mindig újra kellett generálni a pdf fájlokat, nem vette észre, hogy megvannak, és nem változtak.

Most kihagytam ezt a kimeneti mappa beállítást, és így már nincs szükség erre az újrafordításra.

Sőt, sikerült még tovább egyszerűsítenem a képbeillesztési folyamatot: nincs szükség a .eps kiterjesztés megadására a \includegraphics{csp} hívásnál – a program megfelelően kitalálja. Az epstopdf csomagra attól még szükség van!

És ami még szebb: lehet definiálni egy alapértelmezett mappát a képek kereséséhez, hogy ne kelljen a „../img/csp” jellegű módon hivatkozni minden egyes képre:

\graphicspath{{../img/}}

Fontos! Az itt megadott útvonal végére kell a “/” jel, ugyanis egyszerű stringkonkatenáció történik a háttérben. El lehet kezdeni keresni a hibát, ha az ember ezt nem tudja.

Hogy muzsikál ez az új rendszer SVNnel párosítva? Majd az idő eldönti. De a gyorsított fordítás sokat ér a trial and error fázisban. 😀