Accedere alla libreria luasql da lualatex

Durante la giornata ho scambiato alcune mail con Luigi Scarso sul problema incontrato.
Il problema non era dovuto a particolari policy di sicurezza di LuaTeX, come ero stato indotto a credere per via di alcuni esperimenti che avevo già condotto con la libreria lfs, ma semplicemente che l’applicazione non trovava i percorsi.

Ho quindi fatto nel seguente modo:
ho aperto con i diritti di admin il file di configurazione /usr/local/texlive/2010/texmf/web2c/texmf.cnf , aggiungendo alla variabile CLUAINPUTS il percorso /usr/lib/lua

da così:
`% Lua needs to look for binary lua libraries distributed with packages.
CLUAINPUTS = .;$SELFAUTOLOC/lib/{$progname,$engine,}/lua//`

a così:
`
% Lua needs to look for binary lua libraries distributed with packages.
CLUAINPUTS = .;/usr/lib/lua//;$SELFAUTOLOC/lib/{$progname,$engine,}/lua//`

Notare che il doppio slash significa l’accesso a tutte le subdirectory del percorso.

Ho anche scoperto che in realtà la libreria lua file system è in realtà già distribuita con TeX Live (MiKTeX non so), e che quindi per usarla non serve installare niente (per esempio per leggere la directory di lavoro in cui si trova il sorgente).

Una modifica in pochissimo tempo è bastata per la connessione al database e l’esecuzione della query.
Sono impressionato, come forse vi sarete già accorti, della potenza del concetto: il mondo TeX è oggi in grado di accedere direttamente a database del calibro di PostgreSQL.
A breve (spero) pubblicherò un articoletto completo dall’installazione di PostgreSQL alla compilazione finale del sorgente con lualatex.
Un saluto
Grazie

Vi riporto alcune ulteriori informazioni sulla questione LuaTeX / librerie scritte da Luigi che ha acconsentito che le pubblicassi sul forum:
Come potete leggere, la questione tecnica non è così rosa e fiori…

> Incredibile.
…che funzioni ?
Beh ….si.
Il nocciolo è questo: sotto linux si usa dlopen
e le shared object libraries (*.so) hanno un complesso meccanismo per
la risoluzione dei simboli (le funzioni, le costanti etc che la libreria esporta).
Cfr man ld.so
Ora, la gestione dei conflitti dei simboli è … non gestita.
Se due simboli vanno in conflitto allora seg.fault e buona notte al secchio.
Ad esempio: metti che luatex carichi luasql il quale a sua volta chiami save_png pensando che sia di libpng1
A sua volta luatex ha al suo interno libpng, ma è libpng1.1 in cui esiste sempre save_png
ma evolve in modo doverso da libpng1.
ld.so allora dice a luasql di usare save_png di libpng1.1 e voilà, al
99% dei casi corruzione della pagina di memoria del processo luatex (segmentation fault) e aborto. Se avevi una transazione in corso nel db, saluti e baci (beh no, postgres è robusto: ma se usi sqlite c’è il rischio di corrompere il database).
Per complicare le cose, *non* è detto il lua usato come riferimento (gli header) da luasql
sia lo stesso lua di luatex (fino ad oggi si, lo è) per cui in teoria se le cose con la 0.65 funzionano magari con la 0.70 no, e con la 0.71 si ancora, e così via.
Insomma per certe cose è meglio valutare se ricorrere ad un processo
esterno tramite \write18 (che funziona sempre).

Ora sotto Windows le cose cambiano e sotto Mac cambiano ancora.
Quindi vedi bene il guazzabuglio.

> Spero che alla fine LuaTeX sia abbastanza stabile sulle maggiori
> distribuzioni, proprio perché eseguire query dirette da database apre
> le porte ad applicazioni molto potenti ed utili.
purtroppo no. alla fine è una questione di sistema operativo: prima o
poi le librerie devono essere aggiornate.

È tutto,
evidentemente non è così semplice far impallidire la stampa unione di Word…