Newsgroup: it.comp.programmare
Titolo: riconoscitore sintattico!

Ciao a tutti, ho la necessita' di sviluppare un qualcosa che credo si possa
definire "riconoscitore sintattico"!
Avendo un file (un log di un programma) di cui non conosco inizialmente la
sintassi (i tag per cosi' dire!) mi piacerebbe poter configurare un software
in modo da poterne riconoscere la struttura costruendone una struttura in
memoria per poi fare magari una rappresentazione grafica o altro (non ho
ancora deciso :-P)
Lo scopo sarebbe alla fine ottenere un programma che aiuti a leggere o
meglio a schematizzare meglio i risultati ottenuti da vari log , di
programmi pre esistenti e quindi di forma sintattica differente, senza
dovermi vincolare a priori ad un determinato formato di input!
Si accettano nell'ordine : suggerimenti, segnalazioni di risorse in rete,
commenti, racconti di esperienze simili, idee, stralci di algoritmi, il
programma già fatto, assegni in bianco e appuntamenti da belle ragazze :-P
PS: se può servire, conosco bene Java e C++, benino  il C.
PPS: conoscete un buon psicanalista? ;)
--
"...Tutti sanno che una cosa è impossibile da realizzare, finché arriva uno
sprovveduto che non lo sa e la inventa...".
             Albert Einstein

 definire "riconoscitore sintattico"!
[CUT]
Ciao.
L'idea č piuttosto interessante, anche se la soluzione mi sembra piuttosto
complicata (per lo meno ad un decente livello di efficienza e correttezza,
visto che si richiede lo sviluppo di strutture di analisi
euristica/inferenziale).
Potresti magari postare alcuni esempi di input/elaborazione/output, in modo
da definire meglio il tuo target ?
Saluti,
   NinjaCross

 dovermi vincolare a priori ad un determinato formato di input!
Vedi analog.
Davide

ascoltando il vento dell'est udii NinjaCross che diceva queste parole

eccoti un esempio di log, sperando che il tuo news reader non lo renda
incomprensibile ;-P
Nota : si tratta in sostanza di sequenze di set e di get verso un
dispositivo hardware (non e' comunque questa la cosa importante!) in cui
ogni operazione  ha come "tag" di inizio quel :(3): e per "tag" di chiusura
":(2):" ma che in generale possono variare;
Ogni flusso e' identificato da un numero tipo quel (334) che vedi nella
prima riga del log, inizialmente potrei accontentarmi di rappresentare in
una tabellina i vari flussi.
Ovviamente, come e' facile notare, il problema non e' il parsing in se e per
se, ma trovaer il modo di poter adattare (magari definendo la grammatica in
un file separato) gli algoritmi di parsing a diversi tipi di sintassi!
PS: lo sviluppo mi sa che lo faro' in java, ma ogni idea, anche generica e'
bene accetta.
PPS: ho sentito parlare di javacc, qualcuno ha esperienze in merito?
2002/09/06 16:03:11:emlim_2:comm:(3):INTEG:COMM: sent ACTION request (334):
{  -- SEQUENCE --
    baseManagedObjectClass globalForm { testActionPerformer },
    baseManagedObjectInstance localDistinguishedName { -- SEQUENCE OF --
        { -- SET OF --
            {  -- SEQUENCE --
                attributeType { testActionPerformerId },
                attributeValue 1
            }
        }
    }
,
    synchronization bestEffort (0),
    scope asnScopeInt baseObject (0),
    filter and { -- SET OF --
    }
,
    actionInfo {  -- SEQUENCE --
        actionTypeId { testRequestControlledAction },
        actionInfoArg {  -- SEQUENCE --
            controlledTestRequestType independent (0),
            associatedObjects { -- SET OF --
                {  -- SEQUENCE --
                    associatedObject localDistinguishedName { -- SEQUENCE
OF --
                        { -- SET OF --
                            {  -- SEQUENCE --
                                attributeType { protectedTTPId },
                                attributeValue numericName 11310101
                            }
                        }
,
                        { -- SET OF --
                            {  -- SEQUENCE --
                                attributeType { augId },
                                attributeValue numericName 1
                            }
                        }
,
                        { -- SET OF --
                            {  -- SEQUENCE --
                                attributeType { au4CTPId },
                                attributeValue numericName 1
                            }
                        }
                    }
                }
            }
,
            testObjectList { -- SEQUENCE OF --
                {  -- SEQUENCE --
                    tOClass { loopbackTestObject },
                    initialAttributeList { -- SET OF --
                        {  -- SEQUENCE --
                            attributeId { associatedObjects },
                            attributeValue { -- SET OF --
                                {  -- SEQUENCE --
                                    associatedObject localDistinguishedName
{ -- SEQUENCE OF --
                                        { -- SET OF --
                                            {  -- SEQUENCE --
                                                attributeType {
protectedTTPId },
                                                attributeValue numericName
11310101
                                            }
                                        }
,
                                        { -- SET OF --
                                            {  -- SEQUENCE --
                                                attributeType { augId },
                                                attributeValue numericName 1
                                            }
                                        }
,
                                        { -- SET OF --
                                            {  -- SEQUENCE --
                                                attributeType { au4CTPId },
                                                attributeValue numericName 1
                                            }
                                        }
                                    }
                                }
                            }
                        },
                        {  -- SEQUENCE --
                            attributeId { loopbackDirectionality },
                            attributeValue internal (1)
                        },
                        {  -- SEQUENCE --
                            attributeId { loopAndContinue },
                            attributeValue asn_false
                        }
                    }
                }
            }
        }
    }
}
2002/09/06 16:03:12:emlim_2:comm:(2):INTEG:COMM: sent ACTION request (334)
2002/09/06 16:03:12:emlim_2:comm:(3):INTEG:COMM: received SERVICE error
(334):
Processing failure
2002/09/06 16:03:12:emlim_2:comm:(2):INTEG:COMM: received SERVICE error
(334)
2002/09/06 16:03:12:emlim_2:comm:(3):INTEG:COMM: sent CMIS Action error
(133):
Processing failure
2002/09/06 16:03:12:emlim_2:comm:(2):INTEG:COMM: sent CMIS Action error
(133):
Processing failure
| Saluti,
|    NinjaCross
Tx ^I^cato

 || definire "riconoscitore sintattico"!
[CUT]
Beh, leggendo l'esempio che hai riportato effettivamente si comprende la
difficoltà dell'obbiettivo che ti sei posto :)
Effettivamente come accenni, la difficoltà non sta tanto nel parser, quanto
nel sotto sistema che va a rappresentare in memoria le informazioni che il
parser ricava dallo script.
Da quel che vedo, la struttura sintattica si basa su una sequenza di tag e
tag annidati, il che rende piuttosto difficoltoso la realizzzione di un
algoritmo auto-apprendente.
Vista cmq la tipologia dello script credo che un passo iniziale potrebbe
essere convertire lo script stesso tramite le regole di XML.
In questo modo la struttura diventerebbe molto + comprensibile sia all'uomo
che alla macchina, che potrebbe utilizzare parser XML standard.
La costruzione della struttura XML si può benissimo basare sulla
sostituzione ponderata e parametrizzata di frammenti dello script con
corrispondenti frammenti immagazzinati in un dizionario (o meglio, una
collection 1->1).
In seguito, con l'XML alla mano, è possibile effettuare una seconda analisi,
che prevedere la suddivisione in blocchi dello script in base al livello di
nidificazione e ai cirteri di successione dei tag.
Tali criteri ovviamente devono essere scritti a mano, in una collection
apposita.
Hoi già fatto alcune cose di questo tipo nella strutturazione di database
dinamici, e funziona :)
Spero di essere stato esauriente :)
Saluti
   NinjaCross

ascoltando il vento dell'est udii NinjaCross che diceva queste parole
| Beh, leggendo l'esempio che hai riportato effettivamente si comprende la
| difficoltà dell'obbiettivo che ti sei posto :)
:-) ... anzi :,-(
| Effettivamente come accenni, la difficoltà non sta tanto nel parser,
quanto
| nel sotto sistema che va a rappresentare in memoria le informazioni che il
| parser ricava dallo script.
e ovviamente nel dover permettere una "sintassi" non prevedibile a priori!
preciso che in realta' non e' uno script, ma proprio un log di
operazioni...moolto articolato!
Ti faccio un altro esempio (questo log e' un pochino meno articolato, ma
+tosto diverso dal precedente!)
per rendere magari + chiaro lo scenario! (chiaro a te, xke' io quasi quasi
rinuncio! ..scherzo! :-P)
06/05/02 01:58:03:213:atmusm:ALL:(3):Reply in Callback for asynchronous
methods:
          Oid  : 1.3.6.1.2.1.37.1.6.1.9
          Val  : 1
          Type : 0
          Instance: 1.1
-------------------------------------------------------
06/05/02 01:58:03:294:atmusm:ALL:(3):Reply in Callback for asynchronous
methods:
          Oid  : 1.3.6.1.4.1.353.5.5.1.1.3.1.2
          Val  : 45:11:22:33:44:55:66:77:a0:1:a1:a1:a2:0:0:0:0:0:1:0
          Type : 1
          Instance: 1.1.1
          Oid  : 1.3.6.1.4.1.353.5.5.1.1.3.1.15
          Val  : 0
          Type : 0
          Instance: 1.1.1
          Oid  : 1.3.6.1.4.1.353.5.5.1.1.3.1.7
          Val  : 1
          Type : 0
          Instance: 1.1.1
          Oid  : 1.3.6.1.4.1.353.5.5.1.1.3.1.11
          Val  : 1
          Type : 0
          Instance: 1.1.1
          Oid  : 1.3.6.1.4.1.353.5.5.1.1.3.1.13
          Val  : 0
          Type : 0
          Instance: 1.1.1
-------------------------------------------------------
06/05/02 01:58:13:068:atmusm:ALL:(3):GetMultiObjAsynch on:
          Oid: 1.3.6.1.2.1.37.1.6.1.9
          Instance: 1.1
-------------------------------------------------------
| Da quel che vedo, la struttura sintattica si basa su una sequenza di tag e
| tag annidati, il che rende piuttosto difficoltoso la realizzzione di un
| algoritmo auto-apprendente.
mi sa che a me verra' fuori un algoritmo auto-ignorante ^___-
| Vista cmq la tipologia dello script credo che un passo iniziale potrebbe
| essere convertire lo script stesso tramite le regole di XML.
Ti devo confessare, che la prima cosa che ho chiesto era se questi log erano
in XML....la risposta l'hai vista dagli esempi!
Pero' non avevo pensato ad una soluzione come quella da te
proposta...interessante!
| In questo modo la struttura diventerebbe molto + comprensibile sia
all'uomo
| che alla macchina, che potrebbe utilizzare parser XML standard.
Certo che sarebbe un indubbio vantaggio poter lavorare con XML, dato il buon
supporto offerto da java e la mia (seppur piccola ma comunque interessante)
esperienza in merito!
| La costruzione della struttura XML si può benissimo basare sulla
| sostituzione ponderata e parametrizzata di frammenti dello script con
| corrispondenti frammenti immagazzinati in un dizionario (o meglio, una
| collection 1->1).
Ecco, credo che il nocciolo della questione, volendo adottare il tuo
suggerimento, si sopsti tutto qui...un nocciolo bello tosto da scardinare a
prima vista!
Se ho ben capito, la tua idea, sarebbe quella di avere un formato standard
di output immagazzinato diciamo in qualche struttura
tipo questa? :
<Log name ="logname" >
    <flusso id=334>
        <SETS>
            <set data = "2002/09/06" ora= "16:03:11" oid> valore o
chchhesia! </set>
                ....        ...    ...
        </SETS>
        <GETS>
            ...    ...    ...    ...
        </GETS>
     </flusso>
     <flusso id =>
        ....    ....    ...
      <flusso>
<Log>
o qualcosa del genere....
Il problema mi sa che in questo caso resterebbe il mappaggio <parte del log>
con <parte del file XML>!
Per fare una cosa del genere (supponendo di riuscirla a fare), sarei
costretto credo a mantenere una struttura "semplice" dell'XML, altrimenti
avrei un casino di problemi a mappare log molto differenti(Considera che non
e' detto che tutti i log abbiano quell' dato elemento o quel dato
riferimento, ovvero che non abbiano solo sintassi diverse, ma strutture
diverse!!)!
Ma cosi' potrei rischiare di perdere contenuto informativo...la vedo nera!
| In seguito, con l'XML alla mano, è possibile effettuare una seconda
analisi,
| che prevedere la suddivisione in blocchi dello script in base al livello
di
| nidificazione e ai cirteri di successione dei tag.
Questo credo sia gia' piu' fattibile...
| Tali criteri ovviamente devono essere scritti a mano, in una collection
| apposita.
cosa intendi di preciso?
| Hoi già fatto alcune cose di questo tipo nella strutturazione di database
| dinamici, e funziona :)
Mi parevi uno che la sapeva lunga ;)
E visto che ci sei, hai mica qualche link da suggerirmi?
Hai mai usato quel javacc di cui ti ho parlato nel precedente post? A me
sembra interessante, e sai, se potessi usare qualche bel applicativo free
sarebbe un bel sollievo ...
Conosci altre risorse in giro x la rete?
E gli altri? su su, non siate timidi, intervenite liberamente! ^__^
| Spero di essere stato esauriente :)
Sei stato molto gentile, e spero che la discussione non stia annoiando gli
altri dell'NG e che anzi magari ne possano trarre qualche spunto..non si sa
mai!
| Saluti
|    NinjaCross
^I^caro chetra15minuticorreafarelapappa! :)

 Sei stato molto gentile,
De nada.
 Saluti
    NinjaCross

ascoltando il vento dell'est udii NinjaCross che diceva queste parole
Ciao, scusami se tardo a rispondere, ma imegni improrogabili mi hanno tenuto
lontano dal pc (raffreddore! :-P)
||| Tali criteri ovviamente devono essere scritti a mano, in una collection
||| apposita.
||
|| cosa intendi di preciso?
|
| Eccoci, qui' è proprio dove volevo arrivare.
| Dunque, la mia idea coem ti indicavo priam, è dovuta a precedenti
esperienze
| nella modellazione di database dinamici.
| Non mi dilungo in dettagli, ma in poche parole, ciò che ti serve non è una
| metodologia di strutturazione "ampia" che possa essere adatta a tutte le
| casistiche prevedibili,
Mi trovi concorde, anche perche' non sono prevedibili al momento le
casistiche possibili...
| ma bensi' un insieme di "descrittori" che indichino
| al motore di parsing ed al motore inferenziale (sistema esperto istruito
dai
| descrittori) *come* interpretare il contenuto.
Hem...inizi a parlare difficile? :)
Io purtroppo non ho dimestichezza con quelli che tu chiami motori
inferenziali...ma credo di aver afferrato il concetto...qualcosa che capisce
quello che deve fare in base a quello che gli viene detto di fare di volta
in volta...ho sparato una Ca##ta?
| I "descrittori"  possono essere semplici script XML che indicano ognuno
una
| "regola" sintattica e strutturale.
Ecco un punto poco chiaro x me! cosa intendi per "script XML" ? potersti
farmi un esempio anche banale di come dovrebbe essere fatto un descrittore
secondo te?
| Il motore inferenziale, dopo avere formalizzato il log iniziale tramite la
| sostituzione dei tag "grezzi" con tag XML o semplicemente identificatori +
| compatti (del tipo: sostituisci "06/05/02
01:58:03:213:atmusm:ALL:(3):Reply
| in Callback for asynchronous" con <ATMSUM tipo=ALL Reply=callback
| data=06/05/02>), deve applicare le regole descritte nei "descrittori"
(scusa
| la ripetizione) per raggruppare i blocchi funzionali in una collection
| lineare.
Cioe', stai prospettando una doppia fase di decodfica?
1) da log a XML grezzo (o qualcosa di simile)
2) applicazione dei descrittori a quanto ottenuto dal punto uno x ottenere
l' XML specifico
ho capito bene? Quale sarebbe il vantaggio di questa doppia operazione?
| In poche parole, i "descrittori" XML, strutturano l'XML formalizzato a
| partire dal log.
toppe poche parole per me! :-P
Non riesco a capire come poter rendere generici queste regole (gli script)
...a me viene solo in mente l'adozione di un file id properties in cui
descrivere il match tra tag di log e tag  xml ma come farei a rendere il
tutto dinamico? adattabile anche a cambiamenti sostanziali dei log di
partenza? sarebbe troppo statico e molto meno inteligente della tua
proposta...ma la tua proposta non riesco bene a focalizzarla!
| Non so se sono stato chiaro, spero di si :)
Si, tu sei stato chiarissimo , solo che come ti ho detto non avendo
dimestichezza con questi concetti avrei bisogno di un piccolo esempio
esplicativo x afferrare la tua idea...hem...se non era chiaro voleva essere
una richiesta di un esempio :-P
|| Conosci altre risorse in giro x la rete?
|
| Mah, io cercherei innanzitutto delle documentazioni sul pattern matching e
| sull'implementazione di sistemi esperti.
Hai perfettamente ragione, ma purtroppo non credo di avere il tempo
necessario da dedicare a questi argomenti (x me, ti confesso, un opchino
ostici)
ma gradirei comunque qualche suggerimento da cui partire... qualche buon
libro o link, se ne conosci sarebbero ben accetti!
Ancora mille grazie per l'impegno e per l'attenzione con cui ti sei dedicato
a questo "caso umano" :)
^I^

 a questo "caso umano" :)
Quando vuoi :)
Saluti
  NinjaCross