Új TeXlipse – új lehetőségek

Még októberben írtam arról, mire való a [[LaTeX szerkesztés OSX-en|synctex]], és ezt hogyan lehet felhasználni a Skim és a Texlipse környezet összekötésére. Illetve arról is, hogy helyenként problémás.

Most, hogy megjelent egy újabb Texlipse változat (1.3), és újabb, rövid határidejű LaTeX dokumentumokat kell előállítanom, ezért megnéztem, hogy mi a helyzet most.

Még októberben írtam arról, mire való a synctex, és ezt hogyan lehet felhasználni a Skim és a Texlipse környezet összekötésére. Illetve arról is, hogy helyenként problémás.

Most, hogy megjelent egy újabb Texlipse változat (1.3), és újabb, rövid határidejű LaTeX dokumentumokat kell előállítanom, ezért megnéztem, hogy mi a helyzet most.

Természetesen a helyzet rossz és reménytelen :D, de kicsit konkrétabban (és kevésbé pesszimistán szemlélve rá lehet jönni), hogy egészen pontosan mi/hogyan változott, és ezt hogyan lehet exploitolni.

A Texlipse 1.3-as változatának számomra legfontosabb újdonsága, hogy együtt működik a Skim auto reload funkciójával, azaz nem kell kézzel frissítgetnem a pdf kimenetet.

Ugyanakkor a synctex (vagy a hasonló célú pdfsync) továbbra sem az igazi. A pdfsync segítségével gyorsan tudok lépdelni a pdf illetve a tex-fájl egyes helyei között, ami roppant hasznos dolog, ha pl. aki proofreadel, az oldalszámmal tudja jelölni a hibát, amit kicsit nehézkes visszakonvertálni latex source-ra.

De ahhoz, hogy ez működjön, fontos, hogy a generált synctex.gz (pdfsync esetén most nem mondom meg a generált kiterjesztést) ugyanabban a könyvtárban legyen, mint a tex fájl, ugyanis a LaTeX környezet ebben a mappában keresi; ugyanakkor az is fontos, hogy ugyanabban a mappában legyen, mint a pdf fájl, mert a pdf néző meg ott keresi… Szóval a kiforrott, több-könyvtáros megközelítések problémásak tudnak lenni. De legalább így működik.

És még egy fontos dolog: amit a múltkor mutattam scriptet a Texlipse megszólítására, frissíteni kell, ugyanis direkt meg lett szólítva a texlipse.jar fájl, és a frissítés után az elérhetősége ennek megváltozott. Eltartott egy darabig, amíg erre a gondra rájöttem, ugyanis semmilyen hibaüzenetet nem kaptam a visszafele kereséskor. De azért csak meglett.

Az új, módosított scriptem:

java -classpath "/Applications/eclipse/dropins/texlipse/plugins/net.sourceforge.texlipse_1.3.0/texlipse.jar" net.sourceforge.texlipse.viewer.util.FileLocationClient -p 55000 -f $2 -l $1

És most a végére néhány apróság, amire érdemes lehet odafigyelni:

  • Ha még nem frissítettél az 1.3.0-s változatra, akkor várj pár napot, ugyanis felbukkant egy elég idegesítő bibtex parsing hiba. A hétvégére ígértek új kiadást.
  • Amikor frissíteni próbáltam, akkor a P2 valami miatt nem akarta letölteni a cuccot, de a dropins mappába könnyen tudtam telepíteni. Emiatt is változott az elérési útja a texlipse.jar-nak. Nem tudom, mi volt az oka, de majd egyszer esetleg ezzel is elszórakozom.

Alapvetően azért szeretem az új kiadást, de vannak gyenge pontok. Mindenesetre a váltást nem bántam meg, de jöhetne már az 1.3.1.:D

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...
}
}