Polygen senza cygwin1.dll

[tajmone]

Come compilare Polygen per Windows senza la dipendenza da cygwin1.dll.

Cygwin vs MinGW

Sul Wiki di MinGW leggiamo (grassetto mio):

Cygwin in contrast to MinGW

Cygwin applications by principle are not considered a "Native Win32 application" because it relies on the Cygwin® POSIX Emulation DLL or cygwin1.dll for Posix functions and does not use win32 functions directly. MinGW on the other hand, provides functions supplied by the Win32 API. While porting applications under MinGW, functions not native to Win32 such as fork(), mmap() or ioctl() will need to be reimplemented into Win32 equivalents for the application to function properly.

Lo stesso principio vale per MinGW-w64.

Questo thread su stackoverflow esamina i dettagli della questione:

https://stackoverflow.com/questions/187990/why-does-gcc-windows-depend-on-cygwin

In sintesi, se si compilasse Polygen usando MinGW-64 (GCC a 32 o 64 bit), l'exe finale non dipenderebbe da alcuna DLL (le librerie di MinGW-64 possono essere linkate staticamente).

Il problema è che sul sito MinGW-w64 non sono disponibili versioni per Windows che includano il supporto per OCaml. Però OCaml è disponibile in MSYS2:

https://github.com/Alexpux/MINGW-packages

• mingw-w64-ocaml
• mingw-w64-ocaml-camlp4
• mingw-w64-ocaml-findlib
• mingw-w64-ocaml-lablgtk

MSYS2 vs Cygwin

Dal Wiki di MSYS2 (grassetto mio):

How does MSYS2 differ from Cygwin

Cygwin and MSYS2 -- as projects -- have significantly different goals.

Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development.

MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin.

MSYS2 provies a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them. The shell and core tools exist mainly to allow porting Unix programs to run natively on Windows (i.e. without requiring a POSIX emulation layer). MSYS2 doesn't try to duplicate Cygwin's efforts more than necessary, so the number of provided POSIX-emulated software is very small.

Questo a conferma del fatto che MSYS2 consente la creazione di eseguibili che non necessitano di DLL per emulare il layer POSIX.

MSYS2 + MinGW-w64

Da quello che ho capito leggendo la documentazione di MSYS2, per creare eseguibili che non abbiano dipendenze da DLL, è necessario compilare con MinGW-64.

Praticamente MSYS2 offre diversi ambienti di sviluppo, alcuni dei quali legati al progetto MSYS2 stesso (e compilando in quell'ambiente si producono eseguibili che necessitano di DLL per il layer POSIX, come avviene con Cygwin), e infine vi sono gli ambienti MinGW-64 (a 32 o a 64 bit) che consentono invece di compilare eseguibili standalone che implementano il layer POSIX tramite Win API (e dipendono dalle varie DLL di MSVS, ormai presenti di default in tutte le versioni di Windows moderne).

Conclusioni

Concludendo, sarebbe utile a mio avviso considerare di appoaggiarsi a MSYS2 per future compilazioni di Polygen per Windows, e liberarsi della dipendenza da cygwin1.dll. Quando la versione di cygwin1.dll del sito Polygen.org ha semsso di funzionare con Win 7, non sono più stato in grado di usare Polygen per qualche anno; una seccatura.

Stato compilabile dei sorgenti?

Io non ho avuto modo di testare quanto sopra. Sto valutando la possibilità di installare MSYS2 e fare un tentativo (sto solo verificando che non vi siano potenziali conflitti con altre applicazioni sulla mia macchina, ma sembra che MSYS operi in un ambiente completamente isolato).

Tu hai modo di confermarmi se il sorgente di Polygen è compilabile con la versione di OCaml che verrebbe installata da MSYS2? La v1.0.6 ha oltre 10, magari OCaml è cambiato nel frattempo. Vorrei evitare di installare MSYS2 (che mi pare di capire richiederà mezza giornata, tra settaggi, librerie e dipendenze, e cercare di capire come muovercisi dentro) solo per poi scoprire che i sorgenti attuali (quelli del repo, o quelli della v1.0.6) non possono compilare senza modifiche.

Che differenza c'è tra i sorgenti del repo (segnalati come v1.0.7) e quelli invece disponibili dal sito (1.0.6 del 2005)?

Mi sarebbe piaciuto testarlo in altri modi, ma come ti dissi il mio tentativo di installare OCaml (versione OCPWin, che contiene MinGW-w64) su Windows è stato disastroso: l'antivirus mi ha ranzato via 60% dei binari di OCaml. Le altre distribuzioni di OCaml per Win disponibili sono tutte basate su Cygwin, allora tanto vale installare MSYS2 e poi scaricare OCaml col suo package manager.

Purtroppo, anche i tentativi di cross compilare Polygen da Ubuntu tramite MinGW-w64 sono falliti — credo per via del fatto che il makefile andrebbe modificato per specificare di usare il crosscompilatore MinGW-w64 anziché il compilatore OCaml.

Link di Approfondimento

MinGW-w64

• https://mingw-w64.org

MSYS2

• http://www.msys2.org/
• MSYS2 WIki

[alvisespano]

Devi sapere che i ho provato dozzine di modi per usare mingw al posto di cygwin, e perfino la nuova ubuntu per windows che funziona solo con la falls update. È stato un bagno di sangue, molto peggiore di qualche anno fa. Sono anni che uso sia cugwin che mingw, alternatamente, per certi periodi, magari per progetti di lavoro ecc, ma da un paio d'anni mi ero allontanato. Sono tornato e non funziona più un cazzo: conflitti tra i due, versioni degli stessi comandi sovrascritte, path di ambiente devastato - tutto così. Ho risolto rinunciando sia a cygwin che a mingw: sto provando solamente WSL (il linux nativo in w10 che dicevo prima) e ho una piacevole sensazione di ordine - tutti i pacchetti debian si possono installare tranquilla in una sandbox ubuntu, non mi sembra vero che l'abbia fatto Microsoft! 😂 Dopodiché ho osato cinentarmi nella configurazione di VSCode per OCaml, cross-referendomi a WSL. Non l'avessi mai fatto! Non ne vengo fuori!!! Ci sono guide frammentarie, poco frequentate e soprattutto già obsolete, come sempre accade in queste cose desuete. Il mio obiettivo era avere un ambiente di lavoro confortevole per il polygen, modernizzato ad un ide, come ormai sono abituato a lavorare da anni, ma Windows è un portatore di complicazioni assurde in questi casi. È che onestamente mi secca programmare a editor e shell: sento che sono lento e legnoso, ed ho paura a fare interventi grossi perché è tutto scomodo. Insomma, provo ancora un po' e al massimo mi arrendo 😢 Per quanti riguarda msys: stanne alla larga. Anche quello è un mostro che ti ci vogliono 2 giorni per sistemare. Io ti invito a provare WSL: lo so che non tutti ce l'hanno e che non risolve il problema della distribuzione, ma magari risolve temporaneamente, per noi, il problema dell'ambiente di sviluppo. Il giorno ven 19 gen 2018 alle 17:24 Tristano Ajmone < notifications@github.com> ha scritto:

…

Come compilare Polygen per Windows senza la dipendenza da cygwin1.dll. Cygwin vs MinGW Sul Wiki di MinGW <http://www.mingw.org/node/21> leggiamo (grassetto mio): Cygwin in contrast to MinGW Cygwin applications by principle are not considered a "Native Win32 application" because it *relies on the Cygwin® POSIX Emulation DLL or cygwin1.dll for Posix functions* and does not use win32 functions directly. *MinGW on the other hand, provides functions supplied by the Win32 API*. While porting applications under MinGW, functions not native to Win32 such as fork(), mmap() or ioctl() will need to be reimplemented into Win32 equivalents for the application to function properly. Lo stesso principio vale per MinGW-w64. Questo thread su stackoverflow esamina i dettagli della questione: https://stackoverflow.com/questions/187990/why-does-gcc-windows-depend-on-cygwin In sintesi, se si compilasse Polygen usando MinGW-64 (GCC a 32 o 64 bit), l'exe finale non dipenderebbe da alcuna DLL (le librerie di MinGW-64 possono essere linkate staticamente). Il problema è che sul sito MinGW-w64 non sono disponibili versioni per Windows che includano il supporto per OCaml. Però OCaml è disponibile in MSYS2: https://github.com/Alexpux/MINGW-packages - mingw-w64-ocaml - mingw-w64-ocaml-camlp4 - mingw-w64-ocaml-findlib - mingw-w64-ocaml-lablgtk MSYS2 vs Cygwin Dal Wiki di MSYS2 <https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin> (grassetto mio): How does MSYS2 differ from Cygwin Cygwin and MSYS2 -- as projects -- have significantly different goals. Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development. MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin. MSYS2 provies a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them. *The shell and core tools exist mainly to allow porting Unix programs to run natively on Windows (i.e. without requiring a POSIX emulation layer)*. MSYS2 doesn't try to duplicate Cygwin's efforts more than necessary, so the number of provided POSIX-emulated software is very small. Questo a conferma del fatto che MSYS2 consente la creazione di eseguibili che non necessitano di DLL per emulare il layer POSIX. MSYS2 + MinGW-w64 Da quello che ho capito leggendo la documentazione di MSYS2, per creare eseguibili che non abbiano dipendenze da DLL, è necessario compilare con MinGW-64. Praticamente MSYS2 offre diversi ambienti di sviluppo, alcuni dei quali legati al progetto MSYS2 stesso (e compilando in quell'ambiente si producono eseguibili che necessitano di DLL per il layer POSIX, come avviene con Cygwin), e infine vi sono gli ambienti MinGW-64 (a 32 o a 64 bit) che consentono invece di compilare eseguibili standalone che implementano il layer POSIX tramite Win API (e dipendono dalle varie DLL di MSVS, ormai presenti di default in tutte le versioni di Windows moderne). Conclusioni Io non ho avuto modo di testare quanto sopra. Sto valutando la possibilità di installare MSYS2 e fare un tentativo (sto solo verificando che non vi siano potenziali conflitti con altre applicazioni sulla mia macchina, ma sembra che MSYS operi in un ambiente completamente isolato). Tu hai modo di confermarmi se il sorgente di Polygen è compilabile con la versione di OCaml che verrebbe installata da MSYS2? La v1.0.6 ha oltre 10, magari OCaml è cambiato nel frattempo. Vorrei evitare di installare MSYS2 (che mi pare di capire richiederà mezza giornata, tra settaggi, librerie e dipendenze, e cercare di capire come muovercisi dentro) solo per poi scoprire che i sorgenti attuali (quelli del repo, o quelli della v1.0.6) non possono compilare senza modifiche. Che differenza c'è tra i sorgenti del repo (segnalati come v1.0.7) e quelli invece disponibili dal sito (1.0.6 del 2005)? Mi sarebbe piaciuto testarlo in altri modi, ma come ti dissi il mio tentativo di installare OCaml (versione *OCPWin*, che contiene MinGW-w64) su Windows è stato disastroso: l'antivirus mi ha ranzato via 60% dei binari di OCaml. Le altre distribuzioni di OCaml per Win disponibili sono tutte basate su Cygwin, allora tanto vale installare MSYS2 e poi scaricare OCaml col suo package manager. Purtroppo, anche i tentativi di cross compilare Polygen da Ubuntu tramite MinGW-w64 sono falliti — credo per via del fatto che il makefile andrebbe modificato per specificare di usare il crosscompilatore MinGW-w64 anziché il compilatore OCaml. Ad ogni modo, sarebbe utile a mio avviso considerare di appoaggiarsi a MSYS2 per future compilazioni di Polygen per Windows, e liberarsi della dipendenza da cygwin1.dll. Quando la versione di cygwin1.dll del sito Polygen.org ha semsso di funzionare con Win 7, non sono più stato in grado di usare Polygen per qualche anno; una seccatura. Link di Approfondimento MinGW-w64 - https://mingw-w64.org MSYS2 - http://www.msys2.org/ - MSYS2 WIki <https://github.com/msys2/msys2/wiki> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACcZxlNati24R9PAaTLwBFqhEnbyiHLOks5tMMFPgaJpZM4Rktse> .

[tajmone]

Ho risolto rinunciando sia a cygwin che a mingw: ... un bagno di sangue ... versioni degli stessi comandi sovrascritte, path di ambiente devastato -
tutto così

temevo problemi del genere, ed è per questo ero (e sono) riluttante a tentare e volevo un tuo feedback.

Inoltre, trovo che la documentazione di MinGw-64 sia un po' caotica, ed è difficile farsi strada (a meno che non si è già utenti esperti di GCC), e anche solo capire cosa scaricare richiede ore di ricerche.

Per quanti riguarda msys: stanne alla larga. Anche quello è un mostro che ti ci vogliono 2 giorni per sistemare.

grazie per avermi messo in guardia. Stavo spilucchiando la documentazione, e anche se assicura che il tutto è in un ambiente isolato e virtuale, avevo la sensazione che fosse un po' macchinoso (daltronde non mancano le avvertenze circa i problemi a installare pacchetti)

sto provando solamente WSL (il linux nativo in w10 che dicevo prima) e ho una piacevole sensazione di ordine

Ottimo a sapersi. Avevo accolto il suo annuncio con un po' di scettismo, temevo avrebbe appesantito il sistema. E volevo evitare di ritrovarmi con un'ulteriore Bash e versione di Git — sembra che ogni pacchetto voglia installarne una, senza porsi il problema se ne hai già una sul sistema. Per forza di cosa, mi ritrovo già tre versioni di Git e un paio di Bash diverse. E che cavolo!

Io ti invito a provare WSL: lo so che non tutti ce l'hanno e che non risolve il problema della distribuzione, ma magari risolve temporaneamente, per noi, il problema dell'ambiente di sviluppo.

Lo prendo in seria considerazione. Mi documento meglio e cerco di pianificare la cosa.

Resto dell'idea che cross-compilare da Linux sia più semplice. A volte mi ritrovo a dover compilare PP da Haskell, per Windows, ma lo faccio su Ubuntu direttamente che è molto più semplice.

Se no, per il resto preferisco usare una virtual machine (come VMWare), almeno posso fare tutto dentro Windows (inclusi altri OS) ma senza sporcare il sistema di lavoro — almeno per fare le prove, tanto a distruggere un OS virtualizzato basta un click.

Dopodiché ho osato cinentarmi nella configurazione di VSCode per OCaml,
cross-referendomi a WSL. Non l'avessi mai fatto! Non ne vengo fuori!!!

Bello VSCode, l'ho scaricato versione standalone e ci sto sperimentando. Prima di abbandonare Sublime Text vorrei aspettare un po' e vedere che piega prende, per ora mi sembra ancora un' applicazione un po' giovane, ma promette bene. Credo che potrebbe anche rubare il titolo a Sublime Text (anche solo per il fatto che è open source), anche se con grossi progetti tende ad essere meno performante (per via di Electron e Javascript).

Il mio obiettivo era avere un ambiente di lavoro confortevole per il polygen, modernizzato ad un ide, come ormai sono abituato a lavorare da anni, ma Windows è un portatore di complicazioni assurde in questi casi.

È che onestamente mi secca programmare a editor e shell: sento che sono lento e legnoso, ed ho paura a fare interventi grossi perché è tutto scomodo. Insomma, provo ancora un po' e al massimo mi arrendo

Sì, ho avuto l'impressione che OCaml sia diventato un po' trascurato da questo punto di vista. Non ci sono IDE storiche dedicate ad OCaml?

Io sto spulciando in rete, e per ora ho individuato queste (così, a muzzo, senza troppi approfondimenti per ora):

• OCamlEditor
• OCaml-Top (non per produzione)
• Camelia (del 2005!)

Le prime due IDE sembrano belle, e anche mantenute attivamente. La terza è vecchiotta, ma questo non vuol dire che non funzioni.

ERRATA — OCaml-Top è un IDE per imparare e fare esercizi, non finalizzata alla produzione. Inoltre, è prodotta dagli stessi autori della distro OCaml OCPWin (quella che il mio antivirus ha bloccato).

Io uso principalmente Sublime Text 3, che viene distribuito con supporto nativo per OCaml (non l'ho testato), ma esistono anche plugin aggiuntivi (pochi) per gestire meglio lo sviluppo in OCaml:

• https://packagecontrol.io/search/ocaml

Però ST è un prodotto commerciale, ma la licenza non è cara e alla fine l'ho acquistato. Comunque lo si può provare gratuitamente (senza limiti di funzionalità, e neanche di tempo, ti vien solo ricordato che devi comprare la licenza). Quindi (se già non l'hai fatto) puoi scaricare la versione standalone e provare come se la cava con OCaml.

[alvisespano]

Ottimo a sapersi. Avevo accolto il suo annuncio con un po' di scettismo, temevo avrebbe appesantito il sistema. E volevo evitare di ritrovarmi con un'ulteriore Bash e versione di Git — sembra che ogni pacchetto voglia installarne una, senza porsi il problema se ne hai già una sul sistema. Per forza di cosa, mi ritrovo già tre versioni di Git e un paio di Bash diverse. E che cavolo!

E' esattamente quello che ha mandato fuori di testa me: cominciavo ad avere 4 ocaml (uno windows nativo, uno cygwin, uno mingw e uno wsl), più 23000 shell, dozzine di comandi replicati in tutte le piattaforme -- e la cosa che più mi faceva prurito alla schiena era che tutte queste schifezze mettevano la loro cazzo di directory /bin nel PATH di sistema. Potevo percepire lo stress della mia CPU che ogni 10 millisecondi doveva scartabellare dozzine di cartelle alla ricerca di un cazzo di comando, e così ho pulito tutto a mano e tenuto solo un ambiente minimale, riproducibile, sperabilmente self-contained, cioè WSL.

Io ti invito a provare WSL: lo so che non tutti ce l'hanno e che non risolve il problema della distribuzione, ma magari risolve temporaneamente, per noi, il problema dell'ambiente di sviluppo. Lo prendo in seria considerazione. Mi documento meglio e cerco di pianificare la cosa. Resto dell'idea che cross-compilare da Linux sia più semplice. A volte mi ritrovo a dover compilare PP da Haskell, per Windows, ma lo faccio su Ubuntu direttamente che è molto più semplice.

Non uso linux in questo periodo (anche se l'ho usato per molti anni ed, anzi, ho perfino contribuito alla sua diffusione su Amiga facendo un porting di XFree86 per i chipset AGA nel '98) ma ho sempre la tentazione di installarmi VMware e fare tutto da lì: sarebbe anche più semplice VSCode e tutte queste minchiate. Tra l'altro, Polygen l'ho scritto proprio su Linux - non su Amiga purtroppo, perché nel 2002 l'avevo da poco abbandonata per un volgare PC dell'epoca - quindi sarebbe un ritorno a casa per lui :) Ci penserò. Io non ho nulla contro Linux, anzi lo trovo il miglior kernel tra i 3 più diffusi ad oggi, però quello che detesto è avere 2 sistemi operativi.

Se no, per il resto preferisco usare una virtual machine (come VMWare), almeno posso fare tutto dentro Windows (inclusi altri OS) ma senza sporcare il sistema di lavoro — almeno per fare le prove, tanto a distruggere un OS virtualizzato basta un click.

Infatti è la mia prossima strada se quella di WSL non funziona.

Dopodiché ho osato cinentarmi nella configurazione di VSCode per OCaml, cross-referendomi a WSL. Non l'avessi mai fatto! Non ne vengo fuori!!! Bello VSCode, l'ho scaricato versione standalone e ci sto sperimentando. Prima di abbandonare Sublime Text vorrei aspettare un po' e vedere che piega prende, per ora mi sembra ancora un' applicazione un po' giovane, ma promette bene. Credo che potrebbe anche rubare il titolo a Sublime Text (anche solo per il fatto che è open source), anche se con grossi progetti tende ad essere meno performante (per via di Electron e Javascript).

Sublime l'ho usato superficialmente perché da quando è famoso non ho mai avuto occasione di lavorare ad un progetto in cui fosse necessario (ho sempre usato altri IDE più integrati, come i vari IntelliJ o VS). Com'è programmare in OCaml su Sublime? Ho letto che non è molto meglio di Atom o VSCode, quindi a parità di condizioni ho preferito quello che sembrava avere la plugin migliore (VSCode appunto), ma devo ancora riuscire a farlo funzionare correttamente :(

Il mio obiettivo era avere un ambiente di lavoro confortevole per il polygen, modernizzato ad un ide, come ormai sono abituato a lavorare da anni, ma Windows è un portatore di complicazioni assurde in questi casi. È che onestamente mi secca programmare a editor e shell: sento che sono lento e legnoso, ed ho paura a fare interventi grossi perché è tutto scomodo. Insomma, provo ancora un po' e al massimo mi arrendo Sì, ho avuto l'impressione che OCaml sia diventato un po' trascurato da questo punto di vista. Non ci sono IDE storiche dedicate ad OCaml?

Incredibilmente no. C'erano 13-15 anni fa degli esperimenti e sembrava fossero al punto di farne, ma alla fin fine non è mai andato oltre la "plugin buggata per Eclipse" o, al giorno d'oggi, la "plugin buggata per VSCode". E' incredibile come anni fa si faceva tutto con un editor di merda ed una shell - ed eri felicissimo se avevi anche solo il syntax highlightening (che ti configuravi rigorosamente a mano). Adesso non ci riesco più a lavorare senza IDE! Mi vergogno di me :)

Io sto spulciando in rete, e per ora ho individuato queste (così, a muzzo, senza troppi approfondimenti per ora): - OCamlEditor <http://ocamleditor.forge.ocamlcore.org/> - OCaml-Top <https://www.typerex.org/ocaml-top.html> - Camelia <http://camelia.sourceforge.net> (del 2005!) Camelia è esattamente il progetto che ricordava: mai stato bello, neanche

all'epoca. E' sempre stato meglio Eclipse con la sua plugin, piuttosto. Fai tu :P Le prima due le ho sentite nominare ma ho notato che la gente parlava meglio di VSCode oggigiorno, quindi non mi sono neanche addentrato. Magari avrei dovuto farlo?

[tajmone]

Sembra che VSCode sia l'IDE del momento. Era da qualche annetto che il mondo open source implorava un editor ispirato a Sublime Text, ma che fosse gratuito e open, e Atom è stata la risposta che più gli si avvicinava, però è lento rispetto a ST (troppo lento per grossi progetti).

E poi è arrivato VSCode! Non capisco bene come, ma nonostante usi anch'esso Electron (Chromium + Node.js/Javascript), proprio come Atom, al contrario di Atom è molto veloce e regge bene grossi progetti. In realtà ho dato una sbirciatina e mi pare di capire che il motivo risieda in una migliore architettura interna.

Molti utenti di Sublime Text stanno passando a VSCode, e sembra che l'unico impedimento attuale sia la mancanza di questo o quell'latro plugin da cui uno può dipendere nel suo flusso di lavoro. VScode ha una GUI migliore, ed il vantaggio dell'essere completamente open source è punto fortissimo.

Non ho provato a usare OCaml con ST, ma da quel poco che ho letto il supporto nativo è scarsino, ed esistono due packages per mettere le toppe a quei limiti. Ma non ho avuto l'impressione che siano stati investiti molti sforzi in quella direzione.

Però ST è facilmente estensibile e personalizzabile. Al momento sto creando una sintassi Polygen. Non è ancora finita ma mi consente già di editare grammatiche con più agio che non in PolyGUI — nella sitnassi manca ancora l'implementazione delle Etichette ed i loro Selettori con punto, poi dovrò personalizzare un tema ad hoc, ed infine aggiungere funzionalità smart (shortcut per convertire selezioni in blocchi commento, snippet con i template base per una grammatica nuova, qualche funzione che converta caratteri illegali in Ascii escapes o entità XML, ecc.) e assicurarmi che la gestione dei simboli nell'autocompletamento funzioni bene.