Newsgroup: it.comp.lang.javascript
Titolo: RegExp too complex

Salve,
ricevo più o meno questo messaggio di errore (col try/catch) quando 
tendo di effettuare un controllo tramite espressioni regolari molto 
grandi. Non mi era mai capitato. E' un limite delle espressioni regolari 
oppure si tratta di un 'errore di scrittura? Ho verificato ma non mi 
sembra...
Max

 oppure si tratta di un 'errore di scrittura?
Senza aver modo di vedere la regexp in questione, č difficile dirlo.
Potrebbe essere un po' di tutto. Ad esempio potresti aver scritto la
regexp in modo tale da mandare in "loop" o cmq in "crisi" il parser;
quindi č sintatticamente corretta, ma ha un errore logico.
Oppure, piů semplicemente, č davvero troppo complessa per il parser.
A questo punto, perň, mi chiedo che genere di compito debba svolgere
una regexp cosě.
-- 
~ Se i sintomi persistono, insultare il medico.

L'errore è ottenuto con Firefox e sinceramente proverò con IE domani.
La regexp è effettivamente mooolto grande e questo tipo di errore è 
contemplato in tutti i parser. Se fai una ricerca "regular expression 
too complex" trovi molti codici scritti in c con i vari errori di parsing.
Devo fare una prova a testare dove da l'errore. Peccato che javascript 
in Firefox non contempli la locazione dell'errore :-/ Mi farebbe 
risparmiare tempo...
Si tratta di un parser DOM.
Ti terrò informato ;)
Max

 Ti terrò informato ;)
Se hai modo metti online da qualche parte il codice incriminato
che magari qualcuno riesce a buttarci un occhio.


 "piattaforma di sviluppo" per il debugging?
Esattamente Firefox come piattaforma di sviluppo. Spidermonkey, l'engine
  in C per Javascript, è utilizzato da molte altre applicazioni...
Ora devo capire effettivamente cos'é che da l'errore, dato che ho
individuato il punto, e se è risolvibile. Speriamo!
Max

   in C per Javascript, è utilizzato da molte altre applicazioni...
Quindi la supposizione era corretta..?
-- 
~ "Io rispetto molto la stupidità umana.
E' la sola cosa che mi dia un'idea dell'eternità."
(Voltaire)

 Quindi la supposizione era corretta..?
Si serve per tutt'altro e sicuramente più compliant di ogni altra 
interpretazione delle specifiche DOM (che sono, nel level 3 soprattutto, 
poco chiare :[)
Max

 poco chiare :[)
Va beh, non avendo sottomano il quadro generale, non mi sembra il
caso di commentare ulteriormente. :) Spero che sia effettivamente
l'unica strada percorribile per il tuo progetto, perché so quanto
possa essere insidiosa una cosa del genere, avendo fatto qualcosa
di simile lo scorso anno (DOM API XML, con regexp, ma non in JS).


 di simile lo scorso anno (DOM API XML, con regexp, ma non in JS).
E' tutto a buon punto: DOM 2 + DOM 3 a parte... Quelle cose che frenano 
sono veramente antipatiche però :(
Con che cosa ci hai lavorato? Java?
Max

 Con che cosa ci hai lavorato? Java?
No, PHP 4.
-- 
~ Un computer e'  fondamentalmente stupido. Non fa cio'  che vuoi che
faccia,  ma cio' che gli  dici di fare.

 No, PHP 4.
PHP 4? Bella sfida. DOM 3?
A me č nato l'errore dopo che ho aggiornato la regexp di basechar alla 
versione completa (i18n) :-/
Perň, come ti ho precedentemente detto, l'errore lo da solo al 
processing della dichiarazione del doctype...
Max

 processing della dichiarazione del doctype...
Andrebbe visto il perché. :) Beh, buon lavoro allora.. Si attenderanno
i risultati. :)
-- 
~ "Non sono solitamente un uomo che prega,
ma se sei lassù, per favore salvami,Superman."
(Homer Simpsons)

 i risultati. :)
Allora sembra che il problema era dato da una sequenza di RegExp 
successivi (come in parte ho già detto) che ancora devo completare (in 
pratica l'internal DTD)...
Ho problema al momento con la definizione di CDATA, o meglio la sua 
conversione in RegExp di JS:
CData ::= (Char* - (Char* ']]>' Char*))
In pratica un CDATA Section può contenere più markup di fine ']]>' e 
quindi ulteriormente splittato se voluto dal config del DOM3 (default è 
true).
Al momento mi capita che per implementare questa funzionalità se 
affianco poi 2 o più CDATA Section:
<![CDATA[...]]>
<![CDATA[...]]>
<![CDATA[...]]>
...
l'espressione regolare mi cattura tutto fino alla fine :/
Come fare?
Max

 Come fare?
Senza avere la più pallida idea di cosa hai fatto fin'ora a livello di
codice, mi risulta un tantinello difficile aiutarti "nella pratica" :)
P.S.
Poni attenzione alle performance, per questo genere di cose. Al giorno
d'oggi molti "sviluppatori" odierni non lo fanno; e talvolta, eseguono
i benchmark solo su PC "ninja" (è il caso di jQuery ad esempio, che mi
ha piantato IE durante un pattern un minimo complesso).
-- 
~ Confondi il mondo, sorridi tutti i lunedì!

 ha piantato IE durante un pattern un minimo complesso).
Si lo so e lo sto facendo. Infatti effettuo un monitoraggio continuo il 
tutto e ho notato che attualmente la velocità del parsing con l'i18n è 
quadruplicata!

 ha piantato IE durante un pattern un minimo complesso).
Si lo so e lo sto facendo. Infatti effettuo un monitoraggio continuo il 
tutto e ho notato che attualmente la velocità del parsing con l'i18n è 
quadruplicata!
Ho delle pagine per effettuare test L2 e L1. Esiste qualche pagina e 
esempi per costruire suite di test per il L3?
P.S. Non sono un programmatore :)

 P.S. Non sono un programmatore :)
E cosa sei? :)
-- 
~ Tutti quelli che credono nella psicocinesi,
per favore alzino la mia mano.

 [CUT]
In pratica ho detto la stessa cosa in maniera molto sintetica.
Se split-cdata-sections non è true allora viene generato un DOMError, 
altrimenti il CDSECT viene tagliato in base a tutti i mark-up di fine 
interni. Il problema è che la RegExp è difficile perché rischi (e lo 
fa)nel riconoscere i mark-up interni di catturare tutti i CDSECT 
consequenziali... Viceversa di fermarsi al primo ']]>' che trova :-/
Max

 consequenziali... Viceversa di fermarsi al primo ']]>' che trova :-/
Scusa, evidentemente sono stato poco chiaro io. Il fatto è che tu
questo lavoro devi comunque farlo a monte, prima di processare il
il documento effettivamente. Quindi, ti catturi comunque tutto il
blocco "CDATA", non devi riconoscere i markup interni, non ne hai
bisogno. Una volta preso, lo "splitti" in base ai caratteri "]]>"
che trovi.
A quel punto agisci in base alle impostazioni. Ricordandoti che i
markup di inizio e fine devono essere "pari", se non lo sono e la
configurazione non ha settato lo "split-cdata-sections" generi un
errore. Altrimenti li gestisci come blocchi CDATA separati. Ergo,
se hai blocchi sequenziali o meno l'approccio è identico.
Così facendo puoi anche trappare le casistiche di CDATA "nested",
che non sono ammesse.
-- 
~ "It may be that the old astrologers had the truth exactly reversed,
when they believed that the stars controlled the destinies of men.
The time may come when men control the destinies of stars."
(Arthur C. Clarke)

 Scusa, evidentemente sono stato poco chiaro io. 
[CUT]
Guarda, che io sappia per arrivare al punto di trattare i CDATA singoli 
con più mark-up di fine, a prescindere dalla generazione dell'errore o 
no, devi stare nel processo di parsing...
Tu l'hai trattato come hai detto?
Mi informo meglio cmq, mi hai fatto venire il dubbio...

 Mi informo meglio cmq, mi hai fatto venire il dubbio...
Mhm. Non capisco cosa ci sia da informarsi.. O sfugge qualcosa a
me, circa il come stai sviluppando il tutto.. Oppure confondi le
"specifiche" con "l'implementazione".
Ma visto l'andamento del thread, presumo che sia la prima :) tra
l'altro il suddetto thread sta assumendo dimensioni notevoli.. E
se non c'è qualcuno particolarmente interessato a seguirlo, dato
che non stiamo parlando molto di Javascript, né scrivendo codice
"utilizzabile", direi di spostarci altrove, se hai bisogno.


 "utilizzabile", direi di spostarci altrove, se hai bisogno.
Ok, hai ragione. Ti contatto in privato.
Max