Generating LPG 1.0 parsers on OSX using Eclipse

In fall I began maintaining the parser of the VIATRA2 framework. Funny.

Mostly because it uses the LPG parser generator framework, and to make things worse, a very old version (v1.1) of it. Today it is available a new 2.0 version (since 2008), but they are not compatible at all, e.g. they define define packages in the LPG runtime. As the release was near, there was no chance of upgrading the parser, so we were stuck with version 1.0.

The problem with the old version is, that although it is written in C++, even its makefile uses explicitely the Visual C++ compiler, so simply compiling it for OSX is not possible. That means, every time I have to change the grammar file, I have to start a Windows binary. And I like to do it from Eclipse.

My two chances were Wine and VMware (not Parallels, because I don’t have a licence for it 🙂 ). The latter is too hard on resources and is so much harder to integrate with my Eclipse in OSX, so the first choice was Wine. Luckily the Wine developers did quality work, so the LPG generator binary can be run with wine.

The Eclipse integration is not too hard (at least in a basic way, that would work for a while), as there is support for running External tools using the appropriate icon from the toolbar (or from the Run menü).

Such an External tool can be parameterized using various variables of Eclipse, of which two are needed:

  • [cci]$resource_loc[/cci]: the file system path (not workspace-relative path) of the selected resource
  • [cci]$container_loc[/cci]: the the container folder’s (or directory) location, that holds the selected resource (also in the file system)

The tool will be the wine installation, as it will execute the lpg.exe binary, that will receive it as a runtime parameter. This way both the location of the lpg.exe binary and the lpg parameters have to be written to the tools parameters section. It is important to note, that the location of the lpg binary can be given using OSX paths, there is no need to translate them into Wine paths, Wine can handle native OSX paths.

LPG uses a working folder, where it puts the generated parser and AST classes. This will be defined using the [cci]$container_loc[/cci] variable.

LPG needs three types of information: the grammar file (that can be given as a parameter to LPG, we will use the [cci]$resource_loc[/cci] variable), an includes directory (for grammar snippets) and a templates directory (for parser and lexer templates).

The directories can either be found in the working directory (this is needed for local templates), given as parameters or set as environment variables. I choose the third one, as it seemed the most maintainable solution.

For this reason the [cci]LPG_INCLUDE[/cci] and the [cci]LPG_TEMPLATE[/cci] environment variables have to be set on the Environment variables tab respectively.

The described settings (except the environment variables) are shown on the following screenshot:

Running LPG with Wine on the current selection

After these settings are done, by selecting the parser.g file, it becomes possible to run this new tool, that will generate the various parser-related Java classes.

After running the tool, the console output of the lpg generator is shown, where all paths are listed beginning with [cci]Y:\[/cci], although the selected files appear in the folder structure of the Eclipse workspace.

There are some minor shortcomings of this integration: first I cannot use the pop-up menu to execute this tool, as the external tools are not listed. Another annoyance is, that the file has to be selected in Navigator view, the open editor is not enough.

This means, I have to select first the file in the Project Navigator (or Package Explorer, etc.), then run the tool manually from the Run configuration menu. Quite disturbing, but the grammar does not need to be changed too often.

Another problem is, that the error output of the generator is not back-annotated as Eclipse errors (problem markers), only a console output is available. For a brand new grammar this would be not the best solution, but for maintenance it is enough.

The LPG IDE of the IMP (IDE Metatooling Platform) project overcomes this challange by using a newer version of LPG, that is written in cross-platform C (or C++), and uses a builder (that automatically calls the LPG binary if the grammar files are changed), and the builder results are showed as proper error messages.

This means, the future for LPG development in Eclipse is the LPG IDE, but for legacy projects it cannot be used. In these cases my solution can become a good alternative.

Packaging Eclipse in OSX

Recently I experimented a bit with Eclipse packaging. At first it seems not very important, given that the folks at Eclipse work hard to produce executable packages. On the other hand, the Mac OSX packaging is not the best possible one.

The default folder structure of Eclipse applications on Mac OSX is something like follows:
[cc]eclipse
–configuration/
–dropins/
–features/
–p2/
–plugins/
–Eclipse.app/
–artifacts.xml[/cc]

In this structure Eclipse.app is a special folder, that acts as an executable item for OSX.

This structure is easy to produce, very similar to the ones of Windows or Linux, but there are some drawbacks. First, in the /Applications folder the folder icon is a generic folder, instead of an Eclipse icon (okay, this one is easy to resolve, as every folder can have a custom icon). More importantly, all indexer try identifies the executables by name. If there are multiple Eclipse instances installed, then every instance will have the same name displayed. If the path is also displayed, it is possible to distinguish between the instances.
Multiple Eclipse instances shown by the same name

Some time ago (~1 year) I tried simply renaming the Application bundle did not work, as there is seems to be some kind of configuration that won’t work after that. But this was quite a time ago.

Now I found another possible solution: there is an Eclipse repackager script shared in GitHub I could give a try.

The script is a simple bash script, with simple parametering:

[cc_bash]./EclipseOSXRepackager «eclipse source folder» «target.app»[/cc_bash]

A quick testing showed it does not handle dropins, so I hacked and shared a new version (and meanwhile I was able to test Git for the first time – btw. thanks for the fine tutorials, GitHub team 🙂 ).

My updated solution is available also from GitHub: http://github.com/ujhelyiz/yoursway-eclipse-osx-repackager

To tell the truth, even the updated script has some serious issues: I could break the app two ways: the smallest issue was, that P2 could not install or remove anything, or in the worse case the bundle couldn’t even start.

So I have a quick question: does anyone has a working solution for creating proper, working app bundles for OSX from Eclipse? Or simply could help fixing the repackager script?

Mi a hiba a kódban? #2

A [intlink id=”1249″ type=”post”]múltkori, nagy sikerű írásom[/intlink] hatására Tompika küldött nekem egy hasonlóan izgalmas problémát.

[cc_java]while (true) {
Process p = Runtime.getRuntime().exec(“macska”);
p.waitFor();
}[/cc_java]

A kód eredeti, Tompika kedvenc állatait, a macskákat felemlegetve. A kód elméletben a következőt kellene, hogy csinálja: az első sor a [cci_java]p[/cci_java] referenciával elérhető módon indít egy processzt; míg a második sor vár, amíg a processz fut.

Ha megnézzük a kapcsolódó JavaDoc kommenteket, ez így működőképes is lehet. Ezzel szemben futásidőben problémák léptek fel, amiket feltehetőleg a következő kódrészletre való kicserélés javított:

[cc_java]while (true)
{
Process p = Runtime.getRuntime().exec(“macska”);
p.waitFor();
p.getErrorStream().close();
p.getOutputStream().close();
p.getInputStream().close();
p.destroy();
}
[/cc_java]

A kódrészlet utolsó sora vicces. Idézném a Javadoc kommentet:

[cci_java]public abstract void destroy()[/cci_java]

Kills the subprocess. The subprocess represented by this [cci_java]Process[/cci_java] object is forcibly terminated.

Amit én úgy értelmeznék, hogy a függvényt meghívva explicite lezárom a Processt. Viszont állítólag nem így történik. Valaki tudja a magyarázatot? Kíváncsi lennék rá.

PS.: ha valaki hozzájut hasonló gyöngyszemekhez, és eljuttatja hozzám, szívesen közzéteszem.

És mégis leng az inga…

A sok elborult, kocka téma után most egy kicsit könnyedebb vizekre eveznék. Ez nagyjából azt jelenti, hogy a következő írást úgy tervezem, hogy ne csak informatikusok számára legyen érthető (noha ők meglehetősen furcsa okokból nem hemzsegnek az oldal olvasói között).

Kicsit nehezen kezdek hozzá, ugyanis még könyvet nem ajánlottam ezeken a hasábokon – pedig olvastam párat, köztük olyat is, amit tényleg érdemesnek tartok arra, hogy többen olvassák. Ami mondjuk hasznos lenne, hiszen egyre kevesebbet olvasunk.

Viszont a mostani könyvajánlatom nem fog ezen segíteni, ugyanis Umberto Eco Foucault-inga című műve kifejezetten ijesztő: csaknem 800 oldal, nem nagy betűkkel szedve, kemény táblával. De szemben a múltkor emlegetett Ügyféllel itt tartalom is van mellé: Eco professzor úr igen hosszadalmas kutatómunkáját (is) tartalmazza ez a könyv, benne a templomosokról, rózsakeresztesekről és hatalmas rejtett titkokról.

Ha van Terv, akkor minden mindennel összefügg. Ha van Terv, akkor nem kétséges, mi közük a templomos lovagoknak a hasszaszinokhoz, az alkimistáknak a párizsi metróhoz, a titokzatos Saint-Germain grófnak Shakespeare-hez, a rózsakereszteseknek Arsène Lupinhez, a druidáknak az Eiffel-toronyhoz, a Föld forgását bizonyító Foucault-féle ingának… Kihez-mihez is?

Ha van Terv, minden kiderül.

Mi is ez a Terv? Sokat nem mondanék róla, valamit a könyvnek is érdemes meghagyni, de röviden annyit tehetnék hozzá még, hogy negyvenkettő. Azaz a Terv mindent leír, ami a történelmünkben az elmúlt néhány száz évben történt. És a lehetőségekhez képest mégkonzisztens módon is.

Az értékelésem szükségképpen szubjektív, részrehajló vagyok. Én kedvelem a történelmi regényeket, szintúgy azokat a könyveket, amiben a természetfeletti erők is előkerülnek, de azért emberközpontúak maradnak. Ha ehhez még titkok is társulnak, és a főszereplőkkel még azonosulni is tudok, akkor borítékolható, hogy jól érzem magam olvasás közben.

  • Nem rossz – mondta Belbo. – Engem viszont ez a piramisokról szóló ötszáz oldal, ez nem hagy nyugodni.Tudták-e, hogy a Kheopsz-piramis pont a harmincadik szélességi fokon áll, és hogy az a szélességi kör szeli át a legtöbb szárazföldet? És hogy a Kheopsz-piramisnak ugyanazok  a geometriai arányai, mint az amazóniai Pedra Pintadának? És azt, hogy Egyiptomban két tollas kígyó is volt: az egyik Tutankamon trónján, a másik pedig a szakkarai piramison, és ez Quetzalcoatlra utal?
  • Quetzalcoatl a mexikói pantheon tagja. Mi köze neki Amazóniához? – kérdeztem.
  • Mit tudom én, valamit biztos kihagytam. […]

Érdemes lehet megfigyelni, hogy noha összeesküvéselméletekből van bőven a könyvben, a szerző megmarad a tudományos elfogadott módszerek mellett, azaz lehetőség szerint mindent támasszunk alá tényekkel, de legalábbis más művekkel. Jó ez?

Egy biztos: olyan mennyiségű forrásra hivatkozik menet közben, hogy a végén levő függelék kicsit kevés – csak kilenc oldal. Kevésszer fordult eddig elő, hogy egy könyv olvasása közben totál műveletlennek éreztem magam, de itt szinte folyamatosan ez az érzésem volt. Kevés olyan könyv van, ahol egyszerre kap szerepet a Rózsakeresztes kiáltvány, a Gergely-féle naptárreform, kombinatorika (némi programozással együtt) és a Föld forgását kísérleti úton kimutató Foucault-inga.

Szerencsére mindenhol elég pontosan megnevezi a forrásokat – még az elborult, “ördöngös” könyveket is. Így viszont eléri azt, amit nagyon sok könyvnek nem sikerül: hitelesség.

Mindezek mellett a könyv részletesen meg van tervezve: a fejezeteket tíz szakaszra osztotta, amelyeket a szefirák mentén oszt be. Azok kedvéért, akik nem tudnák, mik azok a szefirák (közétek tartoztam a könyv olvasása, illetve az értékelés írása előtt), a héber kabbalisztika tíz állomása a megvilágosodás felé. Emellett a fejezeteket rövid, kapcsolódó idézetek vezetik be.

Ugyanakkor fontosnak tartom megemlíteni, hogy a könyv nem kalandregény, semmilyen formában. Leginkább fejlődésregény: megmutatja, hogyan érti meg Doktor Casaubon a világ legfőbb titkait.

És itt jön az a pont, ahol találkozik a könyv a szakmai érdeklődésemmel is: megmutatja, hogyan lehet leírni a világot egy jól definiált rendszerben. Gondolom, informatikusok/szoftverfejlesztők ismerik ezt a feladatot – ezt rendszeresen kell csinálnunk. Jó tudatosítani az ilyesmit.

És mi különbözteti meg a regény összeesküvéselméleteit a tényleges igazságoktól? Ne akarjuk a hibákat is tökéletesen modellezni. Ha van két, az összes adatunkkal konzisztens hipotézisünk, válasszuk az egyszerűbbet. Meglepően sokszor használható.

Lassan lezárva gondolataimat azzal fejezném be ezt az írást, hogy mindenkinek sok szeretettel ajánlom Eco professzor úr könyvét elolvasásra, a könyv elejéről Raymond Smullyen mottóját idézve:

A babona bajt hoz.

Az idézetek az Európa Kiadó 1992-es magyar nyelvű kiadásából származnak.

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.