Ganymede fejlesztés Java 6-tal OSX-en

Elég sok időt töltöttem már azzal, hogy Java 6 alapú fejlesztést lehessen végezni [intlink id=”570″ type=”post”]Eclipse-szel és OSX-szel[/intlink].

Az alapprobléma az volt, hogy egyszerre kellett 32 (az SWT Carbon API-ja kötelezően 32 bites) és 64 biten dolgozni (mert a Java 6 kötelezően 64 bites). Szerencsére ezt a fejlesztők is belátták, és elkészítették az SWT Cocoa portját (ami mellesleg nem lett rossz, de ez nem ennek az írásnak a témája).

Eredmény: némi varázslás után 3.5-ös Eclipse-szel lehetett Java6-ra fejleszteni (a varázslás nem ártott, de erről szintén nem most írok). De ez bizonyos esetekben nem elég. Például, ha az ember kénytelen 3.4-es Eclipse-szel is kompatibilis maradni, és ezt még ellenőrizni is szeretné.

Ez, és az apróbb problémák a 64 bites Java 6-tal győztek meg végül arról, hogy kb. egy hónappal a megjelenés után frissítsek Snow Leopardra. Elvégre abban van 32 bites Java 6 is, ezért elvileg mennie kellene a dolognak. Sőt, csak Java 6 van a rendszerben, szóval ez még jobb.

Na, Ganymede indul, szépen megy is. Összegyűjtöm a tesztelendő projekteket, és indítanám a runtime workbenchet, mire közli velem, hogy a Carbon SWT nem működik a 64 bites JVM-en. No comment.

A szokásos trükkjeimet ilyen esetekre végigpróbáltam, eredmény teljes kudarc, mígnem  az ESE konferenciáról beszámoló blogbejegyzés kommentjében Kevin Barnes leírja a megoldást: a VM-nek a -d32 paramétert átadva 32 bites JVM-et indít.

És ez tökéletesen működött. Szuper.

PS.: jellemző Eclipse probléma, hogy a megoldás triviális, csak megtalálni nehézkes. De legalább most már tudom, hogyan lehet 32 bitre force-olni a JVM-et.

Hibakeresés: LaTeX ábrafelirat probléma

Nemrég volt szerencsém egy idegesítő LaTeX feature-höz (ugye nem bug, hanem feature). Miután visszafejteni a hiba okát elég macerás volt, ezért gondoltam, megosztom itt is.

Megkérdezték tőlem, van-e ötletem, mitől lehet az, hogy egy ábra hivatkozásánál a számot miért jeleníti meg teljesen más stílusban, mint a többi ábrahivatkozást, ill. mint az ábra feliratát. A probléma úgy jelentkezett, hogy Figure 9. számú ábra (ez az elvárt formátum), míg a hivatkozása Figure 4.4 formátumban jelent meg.

A hivatkozásokat a LaTeX vissza tudta fejteni, semmiféle hibaüzenet nem jelent meg, csak rosszul jelent meg a sorszám. Nagyon látványos hiba sem volt a kódban, többszöri átolvasás után (lényegében hasonlóan nézett ki, mint a többi ábrabeillesztés).

Megpróbálgatva kihagyni elemeket, áthelyezni a kritikus ábrát, illetve hivatkozást sikerült rájönni, hogy a LaTeX valami miatt a fejezet/szakasz-számot jeleníti meg az ábra sorszáma helyett.

Innen már egy gyors Google megadta a megoldást: http://www.leancrew.com/all-this/2008/09/latex-figure-captions/ , ill. az oldalon keresztül a következő lap: http://en.wikibooks.org/wiki/LaTeX/Labels_and_Cross-referencing#Fixing_wrong_labels

A megoldás lényege a következő: semmilyen körülmények között ne legyen a [cci_latex]\label[/cci_latex] címkeparancs a [cci_latex]\caption[/cci_latex] feliratparancs elé. A feliratparancs belsejébe vagy a feliratparancs utánra nyugodtan kerülhet.

A végére beszúrok egy javasolt mintát kép beillesztésére, ami ezt a hibát elkerüli (a forrás a TeXlipse plug-in sablon gyűjteménye:

[cc_latex]\begin{figure}[htp]
\begin{center}
\includegraphics[width=${figureWidth}]{${filename}}
\caption[${labelInTOC}]{${figureCaption}}
\label{${figureLabel}}
\end{center}
\end{figure}[/cc_latex]

A TeXlipse editor ezt a mintát automatikusan beilleszti, ezért nekem nehéz ezt a hibát elkövetnem, de másnak még hasznos lehet. Remélem, van, akinek a megoldás megosztásával

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

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