Tre progetti:
1 – un linguaggio per comporre tabelle numeriche (attualmente il pacchetto LaTeX che lo implementa è fermo alla versione 0.6.1 perché la 1.0 è molto più complessa da scrivere sulla base del progetto linguistico che non ho ancora completamente definito, puoi cercarlo su CTAN con il nome di calctab);
hmm ho qualche idea e qualche critica — già dall’anno scorso — ma preferisco farla in privato — hai il mio indirizzo email ?
2 – creare un linguaggio per sfornare etichette in LaTeX (problema pratico per me che stampo per certi fini circa 3600 etichette all’anno utilizzando un software gestionale). Pensa che il primo abbozzo risale ad agosto 2008;
io circa qualche milione in un anno — per un solo cliente, ed ho più clienti.
Non so se esiste uno qualche standard xml per etichette , mi piacerebbe saperlo però, sono quasi 5 anni che sforno etichette e
la cosa è collaudata e quindi .. si può cambiarla con qualcosa di nuovo 🙂
In genere le stickers sono così personalizzate che il miglior linguaggio
è.. TeX .
3 – un progetto allucinante: creare un linguaggio per lavorare con database relazionali dall’interno di luatex a scopi di reporting o data processing od anche come sistema di input dati (che potrebbe assorbire il progetto 2).
Le idee sono queste:
Supponiamo un tuo dbms già esistente, dopo vedremo il problema
di costruirne uno in luatex.
Ti serve uno adapter per il tuo dbms, ie uno strato sw che permette a luatex (scrito in C) di comunicare con il dbms .In generale gli adapter sono sotto forma di libreria C,C++ , Java C#.
Spesso trovi uno strato sw con un linguaggio dinamico (ie python ruby php vbasic lua ma anche java C# IronPython etc) sopra la libreria che ti facilita la programmazione.
Ora puoi gestire la cosa con \write18:
cioè per il job crei un processo luatex
che a sua volta crea un processo con \write18 ogni volta che deve interagire con il dbms, utilizzando il linguaggio dinamico.Esempio (che spero *non* funzioni)
\def\DoWork#1#2#3{%
\immediate\write18{python myscript.py “#1” “#2” “#3”}}
myscript.py fa qualcosa in base all’ingresso che specifichi con #1 #2 #3
tipo
python myscript.py in01 cmd01 out01
(di solito bastano 2 switch , 3 perchè non siamo avari)
elabora il file in01 (magari precedentemente creato proprio da luatex)
in base alle direttive contenute in cmd01 scritte secondo un linguaggio preciso (python ha già una serie di linguaggi per questo come configParser e json),
direttive magari scritte al volo da luatex in relazione all’input *tex
e butta fuori il risultato in out01
che successivamente elaborerai/presenterai con \Typeset#1, ie
\DoWork{in01}{cmd01}{out01}
:
:
\Typeset{out01}
Ora con lua di luatex hai un sacco di facilità nello scrivere e leggere i dati
rispetto a pdftex,
ma la parte di comunicazione rimane la stessa e la puoi vedere cosi
t = t_start_process + t_comm_dbms + t_shudown_process
Ora se t_comm_dbms ~ t_start_process + t_comm_dbms + t_shudown_process
(ie t_start_process + t_shudown_process << t_comm_dbms )
devi attuare dei meccanismi di caching dei risultati , altrimenti,
data che in genere in *TeX hai 2~3 lanci per lo stesso job (sistemare gli indici e così via) aumenti il tempo del 200% ~ 300%
Dato che normalmente il job si svolge su una sua directory separata,
la cache può essere proprio una serie di files dei risultati delle query scritti
da luatex dopo il primo lancio:
allora devi scrivere del codice luatex che ti distingua i lanci
e che dal secondo in poi usi i dati scritti nella cache piuttosto che interrogare il dbms
Una soluzione più raffinata è questa
http://en.wikipedia.org/wiki/Memcached
in cui la cache è trasferita ad un server
Quindi un job (sempre nella sua dir. separata) ad ogni lancio interroga
il server memcache senza necessità di memorizzare i risultati come prima
per cui ti semplifica il codice luatex
I risultati intermedi poi sono disponibili a tutti i jobs, aumentando la
l’efficienza della concorrenza. Ovvio che la cache deve essere dimensionata,
altrimenti ricadi al collo di bottiglia del dbms
I definitiva questo approccio non è male: se un processo \write18
fallisce (/bug di libreria, errore di programmazione etc) al 99% riesci a gestirlo bene
L’inefficienza nasce quando
t_start_process ~ t_comm_dbms ~ t_shudown_process
per cui sei efficiente al 33% e questo può accadere con la cache
(normalmente non è mai t_comm_dbms < t_*_process)
Con luatex+lunatic si estende luatex con python
in modo tale che
\write18{python myscript.py "#1" "#2" "#3"}}
non è più necessaria,
ed è sostituita in definitiva da una chiamata ad una funzione luatex
ovvero da una macro
In questo modo guadagni di colpo tutti gli adapter esistenti,
ed in
t_start_process + t_comm_dbms + t_shudown_process
ha t_start_process = t_shudown_process = 0
Ma esiste un lato negativo:
se comm_dbms abortisce per quache bug, puoi avere un seg. fault
e *tutto* il job abortisce, lasciando il sistema eventualmente in stato inconsistente.
In luatex lunatic ho trattato questa cose con dbxml e sqlite.
Come vedi, non esattamente una passeggiata.
creare un gestionale in luatex.
hmm..creare un gestionale in luatex non ha senso (dal punto di vista ingegneristico) — non ti basta il casino di cui sopra ? 🙂
Meglio usare quelli che già ci sono ed usare luatex com linguaggio di presentazione dei dati.
Per sistemi piccoli ed agili ad esempio sqlite è molto in voga
(ma come tutte le cose binarie, se corrompi un byte
perdi *tutto* il db, per cui…)