Newsgroup: it.comp.lang.c
Titolo: [FAQ] Giusta osservazione...

tua versione?
Allora, la mia versione e' costruita in modo automatico da un piccolo
programma scritto per questo scopo.
Utilizzate un formato del genere :
<numero sezione>
<titolo sezione>
<numero domanda>
<numero righe domanda>
<corpo domanda>
<corpo domanda>
...
<numero righe risposta>
<corpo risposta>
<corpo risposta>
...
<numero domanda>
<numero righe domanda>
<corpo domanda>
<corpo domanda>
...
<numero righe risposta>
<corpo risposta>
<corpo risposta>
...
Per farvi un esempio :
34
Domande varie
34.1
1
Che cos'e' il C ?
2
Un linguaggio di programmazione general-purpose.
(Da non prendere troppo sul serio).
34.2
2
Mi e' stato detto di non prendere il C sul serio.
E' vero ?
1
Certo, te l'ho detto io !
Speditemi il file sorgente scritto a questo modo.
BADATE DI PORRE OGNI INTERO PERIODO SU UNA SOLA RIGA !
Dando in pasto al mio programma l'esempio precedente e' venuto fuori :
Sezione 34 - Domande varie.
34.1
----
D:	Che cos'e' il C ?
R:	Un linguaggio di programmazione general-purpose.
  	(Da non prendere troppo sul serio).
34.2
----
D:	Mi e' stato detto di non prendere il C sul serio.
  	E' vero ?
R:	Certo, te l'ho detto io ! 

 Utilizzate un formato del genere :
No, mi rifiuto! Io li mando come mi vengono. Poi magari li aggiusti tu,
ok?
Sto aspettando la lista completa con l'indicazione delle sezioni già
fatte, prenotate e libere.
EMG

fatte, prenotate e libere.
 1. Declarations and Initializations
 2. Structures, Unions, and Enumerations
 3. Expressions                       (A.Laforgia)      OK
 4. Pointers                          (M. Sarti)
 5. Null Pointers                     (M. Sarti)
 6. Arrays and Pointers               (A. Laforgia)     OK
 7. Memory Allocation                 (EMG)             OK
 8. Characters and Strings            (A. Laforgia)     OK
 9. Boolean Expressions and Variables (A. Laforgia)     OK
10. C Preprocessor
11. ANSI/ISO Standard C
12. Stdio
13. Library Functions                 (A. Laforgia)
14. Floating Point                    (A. Trianti)
15. Variable-Length Argument Lists    (A. Trianti)
16. Strange Problems
17. Style
18. Tools and Resources
19. System Dependencies               (A. Trianti)
20. Miscellaneous

  1. Declarations and Initializations
Ok, la prenoto io.
EMG

Ok, la prenoto io.
Va bene.
Volevo chiedere ad Aldo Trianti e Marco Sarti come vanno avanti le
loro traduzioni.

 appartenenti ad un unico periodo.
Si, capisco. Ma ti prego: fammelo tu.
EMG


ICQ #34602650

sera.
Ok, vi ripropongo la situzione :
 1. Declarations and Initializations		(EMG)OK
 2. Structures, Unions, and Enumerations        (A.Laforgia)
 3. Expressions                    		(A.Laforgia)OK
 4. Pointers			                (M. Sarti)
 5. Null Pointers               		(M. Sarti)
 6. Arrays and Pointers			        (A. Laforgia)OK
 7. Memory Allocation              		(EMG)OK
 8. Characters and Strings         		(A. Laforgia)OK
 9. Boolean Expressions and Variables 		(A. Laforgia)OK
10. C Preprocessor
11. ANSI/ISO Standard C
12. Stdio
13. Library Functions			        (A. Laforgia)OK
14. Floating Point      	         	(A. Trianti)
15. Variable-Length Argument Lists    		(A. Trianti)
16. Strange Problems                            (A. Laforgia)OK
17. Style
18. Tools and Resources                         (A. Laforgia) 
19. System Dependencies        			(A. Trianti)
20. Miscellaneous                               (A. Laforgia)
Come vedete le sezioni che rimangono da tradurre sono 10, 11, 12 e 17.
Invito A. Trianti a farsi sentire...
Nel caso non fosse possibile tradurre le sezioni prenotate, avvisate
ovviamente...

<numero righe domanda>
Scusate se m'intrometto, ma i consigli gratuiti non richiesti sono la mia
specialita`...
Che ne direste di un formato un po' più libero ispirato all'sgml?
<Q>
	Domanda?
</Q>
<A>
	<P>Risposta: primo paragrafo.</P>
	<P>Risposta: secondo paragrafo!</P>
</A>
Sarebbe più semplice da scrivere (e non tanto più complicato da leggere),
inoltre con un css è già /quasi/ in html e con poco diventerebbe un documento
latex (e quindi postscript) perfettamente formattato.
Oppure direttamente nell'sgml delle FAQ di linux e poi post-processare con gli
sgml tools.
(Andrea, forse fai prima a scrivere un programma apposito per questo formato che
a convincere EMG a scrivere con il tuo :)
_mirko_
--
Knowledge is power.
"ciucciati.il.calzino" is antispam.

a convincere EMG a scrivere con il tuo :)
Ho gia' scritto il programma e lo applico regolarmente...
Forse, pero', andrebbe ottimizzato... ;)
Chissa', col tempo vedremo...
In effetti il formato che hai suggerito e' molto piu' semplice e
funzionale...

 a convincere EMG a scrivere con il tuo :)
No, non sono così testardo. Il fatto è che, sarà la stanchezza, sarà il
caldo, ma in questo periodo non riesco a fare niente (oltre a quelle
quisquilie che già faccio come il lavoro autonomo di programmatore e
tirare su una bambina...). E se mi chiedete, oltre a tradurre, anche di
seguire un qualunque formato che non sia quello che sto già seguendo mi
passa completamente la fantasia. Scusate...
EMG

passa completamente la fantasia. Scusate...
Be', in effetti mi rendo conto che il formato da me suggerito e' molto
fastidioso, forse anche perche' (un po' vigliaccamente) facilito la
vita al mio programma ;)
E mi sono reso conto che la formattazione del testo generata non e'
proprio delle migliori.
Quindi credo che per la versione definitiva delle faq possiamo
studiarne uno migliore.
Per esempio, mi rendo conto che non e' strettamente necessario che il
testo sia ben giustificato tra due colonne, basta semplicemente che si
vada a capo dopo una certa lunghezza della riga, cosi' come fa EMG con
il suo formato.
E' piu' facile da controllare e mantenere anche da parte di chi
scrive.
Secondo me il formato suggerito, ovvero di porre la domanda tra due
direttive <Q> e </Q> e la risposta tra <A> e </A> e' ottima.
Resta solo il problema della numerazione delle domande.
Magari si puo' impostare che la prima riga dopo <Q> contenga il numero
della domanda, ma non e' proprio il massimo...
Voi che suggerite ?

Resta solo il problema della numerazione delle domande.
Io pensavo potesse numerarle l'impaginatore (il programma) in modo da poter
inserire domande e sezioni senza dover cambiare tutti i numeri a mano.
Se vuoi alcuni spezzoni di codice ho realizzato un parser simile
(HTML->WIN-Help) tempo fa (purtroppo, come tutto cio` che scrivo, sara`
strabuggato :). Appena saro` piu` libero potrei sistemarlo e inviarlo al NG (se
richiesto).


 Resta solo il problema della numerazione delle domande.
Secondo me non è così facile come sembra. Se cambia il numero di una
domanda devono anche cambiare tutti i riferimenti ad essa. E questi non
sono in un formato adatto ad essere rintracciati, credo.
EMG

richiesto).
Credo che per ragioni di portabilita' non sia implementabile una
trasformazione del genere.

trasformazione del genere.
In che senso? Di che trasformazione parli?
Il parser è abbastanza generico e va bene per qualsiasi formato
<tag{[ proprietà[=[numero | stringa | enumerato]]}> [</tag>]
ridefinendo solo la sua base di conoscenza (in pratica una lista NOME_TAG, TIPO,
PROPRIETA`). 
Il codice che si occupa di interpretare il file in ingresso e` ben separato da
quello che produce l'output. Basta riscrivere le 3 funzioni (di poche righe tra
le altre cose) che si occupano di formattare l'output (openTag, closeTag,
textOut) a seconda delle /tag/ incontrate ed e` tutto risolto. Non sarebbe
neanche difficile creare una /cross-reference/ automatica (per numerare le
domande).
Un divertente impegno di programmazione di massimo 1 oretta o 2.


Un divertente impegno di programmazione di massimo 1 oretta o 2.
1 ora ?? Ma in un ora si puo' scrivere un sistema operativo ! ;))

1 ora ?? Ma in un ora si puo' scrivere un sistema operativo ! ;))
Se usi le funzioni del BIOS! Se invece programmi tutto a basso livello ti ci
vogliono diversi anni (come ce ne sono voluti a Linus :)) :).
Fate voi, io il codice l'ho gia` scritto e funzia, ha solo bisogno di una
rispolverata e di un'oretta di lavoro per scrivere una classe "formatter"
specifica per le esigenze della FAQ. 


tirata giu` dal sito Netscape (senza neanche scrivere il codice apposta).
Non sto sottovalutando le capacita' del tuo programma.
Sto solo dicendo che trasformare da HTML a WinHelp e' poco portabile,
per il fatto che il formato WinHelp verrebbe gestito solo sulle
macchine con s.o. Windows.

macchine con s.o. Windows.
Non mi sono spiegato bene. Non volevo convertire la FAQ in WinHelp (anche se
_anche_ in winhelp sarebbe una comodita` in piu`). Il programma di cui parlo e`
un parser _generico_, il parser interpreta l'ingresso indipendentemente
dall'output generato. (A me serviva in winhelp e mi sono implementato una classe
formatter all'uopo, ma il parser resta generico)
Con quel che offro basta scrivere (pseudocodice)
formatter::openParser() { 
  print("FAQ di comp.prog.c\n\n"); 
  return 0; 
}
formatter::openTag(TAG *tag) { 
  if(tag->name = "Q")
      print("* Domanda %d:", contatore); 
  elseif(tag->name = "A") 
      print("\n* Risposta %d:\n", contatore); 
  elseif(tag->name), "P") 
    print("\n    "); 
  return 0; 
}
formatter::closetag(TAG *tag) { 
  if (tag->name = "Q") 
    print("\n--------------------------------", contatore); 
  elseif(tag->name = "A") 
    print("--pagina--"); 
  return 0; 
}
formatter::closeParser() { puts("#FINE#"); return 0; }
formatter:textOut(stringa) { scrivi stringa carattere per carattere e vai a capo
quando serve (funzione che hai gia` da quel che mi e` parso di capire)}
main() { formatter *FAQ = new formatter; fill(); parse(FAQ); delete FAQ; }
per ottenere 
da un file a formato libero:
<----INPUT---->
<Q> Come funziona un parser? </Q>
<A>
  paragrafo1 
  testo
  del paragrafo
  in cui vado a capo quando 
  voglio.
  <p>paragrafo2 lungo lungo lungo lungo lungo lungo lungo lungo lungo 
  lungo   lungo.
  <p>
  paragrafo3.
</a>
</----INPUT---->
Qualcosa come:
<----OUTPUT---->
 FAQ di comp.prog.c
 * Domanda 1: Come funziona un parser? 
 -------------------------------------
 * Risposta 1: 
     paragrafo1 testo del  paragrafo in 
 cui vado  a capo quando voglio.
     paragrafo2 lungo lungo lungo lungo  
 lungo  lungo lungo lungo  lungo  lungo 
 lungo.
     paragrafo3.
 --pagina--
 #FINE#
</----OUTPUT---->
E' facile immaginare come in poco tempo (un'oretta o 2) si possa adattare a
qualsiasi formato di uscita desiderabile (Testo, WinHelp, HTML e
LaTeX/PostScript compresi).
** Se c'e` qualcosa di non chiaro date un'occhiata allo pseudocodice e tutto
dovrebbe chiarirsi. **


dall'output generato.
Ma, quello su cui vorrei insistere e' che sviluppare il parser non e'
problematico.
Il problema e' intendersi sulle convenzioni da adottare nel codice
sorgente.
I tag sono una buona soluzione.
Ritengo che <Q> </Q> va bene per la domanda, mentre <A> </A> per la
risposta.
In quanto ai paragrafi lascerei stare.
Difatti la loro disposizione viene data dal chi scrive, mentre
introdurrei un tag <C> </C> per segnalare il codice sorgente scritto,
in modo da rappresentarlo con un altro colore nella trasformazione ad
HTML e dei tag <VA> </VA> per i "vedi anche".
Resta il problema della numerazione delle domande.

Resta il problema della numerazione delle domande.
[...]
Io proporrei:
---
<SEZIONE>
<Q NAME="Riferimento">Domanda?</q>
<A>
vedi domanda <RIF NAME="Riferimento">.
</A>
</SEZIONE>
---
che si tradurrebbe in 
---
Q: 1.1 Domanda
A: vedi domanda 1.1
---
La scelta della <P> per segnare i paragrafi non era un caso, visto che ritengo
piu` flessibile la formattazione libera. In tal modo chi scrive puo` andare a
capo quando vuole, con il solo obbligo di dividere i paragrafi esplicitamente,
si introduce in tal modo una *separazione* netta tra *documento* e sua
*struttura* che costituisce l'unico modo di scrivere un documento portabile. Se
in un formato di documento desideri far andare chi scrive a capo quando vuole
(per separare le righe) devi introdurre comunque un modo di separare i paragrafi
(o con un doppio invio o in qualsiasi altro modo) altrimenti introdurresti
ambiguita` semantiche non risolvibili dal parser. Ma e` inutile che io spieghi
queste cose a te.
L'esempiuccio di cui sopra introduce anche le sezioni (e magari si potrebbero
introdurre anche le sotto-sezioni).
fine.
_mirko_