|
ATTENZIONE
ATTENZIONE
Il Forum si è trasferito al nuovo indirizzo: www.guitex.org. Le vecchie discussioni rimarranno visibili per consultazione. Gli utenti registrati potranno continuare a usare le proprie credenziali d'accesso sul nuovo Forum.
ATTENZIONE
ATTENZIONE
| Precedente :: Successivo |
| Autore |
Messaggio |
luigi.scarso
Avanzato
Registrato: 28/04/05 09:13
Messaggi: 268
Località: padova
|
 Inviato: Mer Nov 04, 2009 10:39 am Oggetto: bibman |
 |
|
Io sono completamente a digiuno del problema bibliografia
quindi non so dare un giudizio
http://modules.contextgarden.net/bibman
Voi che ne pensate ?
(credo occorri mkiv ) |
|
| Torna in cima |
|
 |
robitex
Avanzato
Registrato: 23/11/07 11:48
Messaggi: 965
Località: Carrara (MS)
|
| Inviato: Mar Nov 10, 2009 12:56 pm Oggetto: Re: bibman |
|
|
| luigi.scarso ha scritto: | Io sono completamente a digiuno del problema bibliografia
quindi non so dare un giudizio
http://modules.contextgarden.net/bibman
Voi che ne pensate ?
(credo occorri mkiv ) |
Direi che è molto interessante. Mi sto avvicinando a ConTeXt e spero a breve di aver l'occasione di comporre i primi documenti, per cui non posso darti un giudizio sul risultato del modulo.
Penso però che il risultato bibliografico raggiungibile con questo modulo sia più che sufficiente nella maggior parte dei casi, a giudicare dalla documentazione.
Ti dirò che la sintassi di questo modulo è coerente con il formato di base ed è particolarmente interessante. Noto infatti una certa somiglianza tra i template di LaTeX3 e il linguaggio standard di ConTeXt.
Anche nel mio micro (nel "mio piccolo" ridotto), sto portando il linguaggio del pacchetto calctab verso gli stessi concetti per rilasciarne una nuova versione. Tuttavia sono fermo perché il codice TeX è spesso difficile e complesso da scrivere (come ti accennavo al GuITmeeting 2009).
Non è escluso in futuro che la mkiv possa offrirmi un ambiente di programmazione più efficace e semplice per metter in pratica le mie idee (leggi sogni nel cassetto).
Ciao a presto. |
|
| Torna in cima |
|
|
luigi.scarso
Avanzato
Registrato: 28/04/05 09:13
Messaggi: 268
Località: padova
|
| Inviato: Mar Nov 10, 2009 5:07 pm Oggetto: Re: bibman |
|
|
| robitex ha scritto: |
Anche nel mio micro (nel "mio piccolo" ridotto), sto portando il linguaggio del pacchetto calctab verso gli stessi concetti per rilasciarne una nuova versione. Tuttavia sono fermo perché il codice TeX è spesso difficile e complesso da scrivere (come ti accennavo al GuITmeeting 2009).
Non è escluso in futuro che la mkiv possa offrirmi un ambiente di programmazione più efficace e semplice per metter in pratica le mie idee (leggi sogni nel cassetto).
Ciao a presto. |
hmm dimmi di più.... |
|
| Torna in cima |
|
|
robitex
Avanzato
Registrato: 23/11/07 11:48
Messaggi: 965
Località: Carrara (MS)
|
| Inviato: Mar Nov 10, 2009 7:11 pm Oggetto: Re: bibman |
|
|
| luigi.scarso ha scritto: | | hmm dimmi di più.... |
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);
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;
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).
Mentre il progetto 1 è avviato su una strada già abbastanza definita anche se TeX non vuole collaborare, il secondo è ancora allo stato di idea, mentre il terzo, creare un gestionale in luatex, è decisamente sulla luna  (ma ho perfino messo a punto una prima ipotesi di schema db per certi scopi).
Ecco, in ordine di pazzia, i miei tre progetti.
Ciao ed alla prossima! |
|
| Torna in cima |
|
|
luigi.scarso
Avanzato
Registrato: 28/04/05 09:13
Messaggi: 268
Località: padova
|
| Inviato: Mer Nov 11, 2009 7:25 am Oggetto: Re: bibman |
|
|
| robitex ha scritto: |
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 ?
| robitex ha scritto: |
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 .
| robitex ha scritto: |
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.
| robitex ha scritto: |
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...) |
|
| Torna in cima |
|
|
robitex
Avanzato
Registrato: 23/11/07 11:48
Messaggi: 965
Località: Carrara (MS)
|
| Inviato: Mer Nov 11, 2009 8:29 am Oggetto: |
|
|
D'accordo. Un gestionale in luatex è uno sproposito ed anche una provocazione.
Dovremo però approfondire le questioni sollevate ma in questo periodo per me è quasi impossibile trovare il tempo di mettere il materiale al pulito per ragionarci e di effettuare i test in ConTeXt (...mi è venuta l'idea di sperimentare ConTeXt per redarre i documento relativi al sistema di qualità aziendale (cosa c'è di meglio del documentare la qualità con documentazione di qualità?).
Il mio indirizzo e-mail è questo: [informazione rimossa] che spero possa diventare un nostro fruttuoso riferimento.
Ciao e grazie.
Ps. Ok come numero di etichette vinci tu.
Ultima modifica di robitex il Mer Nov 11, 2009 1:23 pm, modificato 1 volta in totale |
|
| Torna in cima |
|
|
luigi.scarso
Avanzato
Registrato: 28/04/05 09:13
Messaggi: 268
Località: padova
|
| Inviato: Mer Nov 11, 2009 11:03 am Oggetto: |
|
|
| robitex ha scritto: | D'accordo. Un gestionale in luatex è uno sproposito ed anche una provocazione.
|
puff ...
non proprio, se pensi ad un db x la bibliografia
che ha come struttura dati una tabella lua
che è gestito con luatex .
Solo che non è generale,ma molto focalizzato al mondo TeX
| robitex ha scritto: |
Ps. Ok come numero di etichette vinci tu |
Ah no, era per dire che *TeX è ottimo per fare queste cose
-- avro' fatto poco meno 10milioni di etichette fino adesso
Solo che normalmente non lo si vede da questo punto di vista...
ma tant'è, siamo ingegneri no ? |
|
| Torna in cima |
|
|
|
 |
Non puoi inserire nuovi Topic in questo forum
Non puoi rispondere ai Topic in questo forum
Non puoi modificare i tuoi messaggi in questo forum
Non puoi cancellare i tuoi messaggi in questo forum
Non puoi votare nei sondaggi in questo forum
|
|
Homepage di GuIT
Introduzione all'arte della composizione tipografica
