Closed tajmone closed 6 years ago
Ho provato a installare OCPWin (non con il setup, ma la version zippata) su Win 10, ma l'antivirus mi blocca la maggior parte degli exe di questo pacchetto.
Allora ho installato MinGW-w64 su Ubuntu, e il pacchetto OCaml per MinGW-w64, ma non sono riuscito a cross-compilare Polygen con MinGW. Mi pare di capire che il progetto non disponga di opzioni di compilazione alternative.
Non riesco a venirne a capo e far funzionare Polygen. La versione precedente scaricata da polygen.org entra in loop (come descritto sopra), mentre l'exe contenuto in questo repository non entra in loop ma non funziona con la DLL cygwin1.dll
del sito — ho scaricato l'ultima DLL gi cygwin dal sito ufficiale, senza installare tutto il pacchetto ma estrando soltanto cygwin1.dll
nella cartella di Polygen, ma quando faccio partire Polygen mi dà errore riguardo questa DLL.
Prima di tentare di installare tutto il paccheto cygwin, o tentare il setup di altre versioni di OCaml per Windows, volevo sapere da te se Polygen è effettivamente compatibile con Win 10.
L'ideale, a mio avviso, sarebbe se tu potessi:
Inoltre, mi chiedevo se potessi aggiungere al progetto delle configurazioni al makefile che consentano di eseguire facilmente la cross-compilazione su Linux tramite MinGW-w64 — se non sbaglio, l'eseguibile così creato non dipenderebbe dalle DLL di Cygwin e sarebbe completamente standalone.
Premetto che non conosco OCaml, e quindi sono impacciato quando si tratta di compilare un progetto OCaml, né ho molto esperienza di cross-compilazione. Ad ogni modo, immagino di non essere l'unico ad avere problemi a usare Polygen su Win 10, sarebbe quindi utile documentare la situazione di Polygen allo stato attuale riguardo la sua compatibilità.
Mi manca molto Polygen, e mi dispiacerebbe non poterlo più utilizzare su Windows.
PS: Oggi ho notato che il sito http://www.polygen.org/ non è più raggiungibile. Viene visualizzato l'errore:
Error 503 Backend fetch failed
Backend fetch failed
Guru Meditation:
XID: 45232691
Varnish cache server
Spulciando sul gruppo Facebook di Polygen ho trovato la soluzione di Vittorio Ramponi su come far funzionare Polygen su Win 10 (usando l'exe scaricato dal sito):
https://www.facebook.com/groups/35567209510/permalink/10155675705689511/
Ho scaricato la versione giusta di cygwin1.dll
suggerita, e impostato le opzioni di compatiblità e la variabile d'ambiente, come da istruzioni. Ora funziona tutto come prima! Meno male.
Credi che ricompilare una nuova versione Windows di Polygen, con un compilatore OCaml aggiornato, ovvierebbe a questi inconvenienti di compatiblità (e alla necessità della DLL)?
PS: Il sito polygen.org è tornato online ora.
Grande! Scusa se mi faccio vivo ora, ma non ricevo mai notifiche su Github e non mi ero accorto! Quindi ricapitolami la situazione: sei riuscito a far funzionare il Folpygel su W10 e sistemato la cosa con la dll di cygwin, giusto? Hai committato? Riguardo OCaml nuovo: sicuramente ricompilarlo gli farebbe bene, perché sono passati anni ed anni e sicuramente il compilatore OCaml oggi è molto migliore di un tempo. Tuttavia temo non sia possibile ovviare alla necessità di avere la ddl di cygwin, a meno di qualche grossa novità di cui non sono a conoscenza.
Ciao Alvise,
Scusa se mi faccio vivo ora, ma non ricevo mai notifiche su Github e non mi ero accorto!
... nessun problema, intolre ci sono state le feste di mezzo.
Quindi ricapitolami la situazione: sei riuscito a far funzionare il Folpygel su W10 e sistemato la cosa con la dll di cygwin, giusto?
Sì, inizialmente ho seguito le istruzioni di Vittorio Ramponi:
ma poi sono riuscito a trovare una versione di cygwin1.dll
(la v2.9.0-3) che funziona ancora meglio:
... con questa DLL non serve impostare l'esecuzione in modalità compatiblità né per polygen.exe
né per PolyGUI, e dispensa anche dall'impostare la variabile d'ambiente CYGWIN=nodosfilewarning
. Ora PolyGen funziona sia da PolyGUI che da CDM e anche Bash (nessun errore riportato, neanche il WARNING: Couldn't compute FAST_CWD pointer
). Testato su Win 10 x64.
La soluzione di Vittorio impediva l'uso da CMD e Bash, per via della modalità compatibilità (oltre al fastidioso messaggio di autorizazzione ad apportare modifiche).
Volevo postare la soluzione su Facebook, ma era necessario iscriversi al gruppo (e sto attendendo la conferma d'iscrizione).
Hai committato?
No, volevo appunto aspettare di entrare in contatto con te. Come hai visto dalla mia pull request (PR #2), proponevo di eleminare i file binary dal repository (soprattutto in un ottica cross platform). Ma credo che sarebbe una buona idea mettere nella root uno zippato con PolyGen, PolyGUI e la DLL giusta per farlo funzionare su Win 10 — in fondo si tratterebbe di un file di piccole dimensioni. In alternativa, potresti fare una release per questo codice, ed allegare il binario lì; però questo codice è alla v1.0.7, mentre l'exe che uso è ancora la v1.0.6.
Se per te va bene, me ne occupo io e poi ti faccio una PR. L'unico dubbio che ho riguarda PolyGUI, non trovo alcuna menzione circa la sua licenza; so che l'autore ne ha concesso la distribuzione gratuita su polygen.org, ma non so se questa autorizzazione sia estesa ad altri siti. Invece, per PolyGen e cygwin1.dll
, mi basta allegare la licenza di PolyGen e la GPLv3.
Riguardo OCaml nuovo: sicuramente ricompilarlo gli farebbe bene, perché sono passati anni ed anni e sicuramente il compilatore OCaml oggi è molto migliore di un tempo.
Le versioni per Windows sembrano un po' vecchie, e alcune non girano su Windows 10; nel mio caso, l'antivirus mi ha bloccato quasi tutti i binari di OCaml per Windows. Però non ho provato tutte le versioni disponibili, solo una. Credo comunque sia meglio cross-compilare da Linux, usando MinGW.
Tuttavia temo non sia possibile ovviare alla necessità di avere la ddl di cygwin, a meno di qualche grossa novità di cui non sono a conoscenza.
Credo che usando MinGW-w64 (anche per compilare a 32 bit) sia possible ovviare alla necessità della DLL. Pare che ora molte librerie siano in grado di girare nativamente, ma ci sono eccezioni alla regola.
Nella mia versione locale sto creando varie branch che contavo di sottoporrti come pull-request da qui a breve. Per esempio, sto lavorando alla documentazione per la stesura delle gramamtiche (documento HTML italiano e inglese), e sto riconvertendo il documento da HTML a markdown, per poterlo poi convertire in vari formati. Contavo anche di rivedere la traduzione inglese, che mi pare riferirsi a una versione precedente di PolyGen, la cui sintassi era molto ridotta.
Allo scopo ho creato una sintassi delle grammatiche PolyGen per Highlight, di modo da poter colorare per bene la sintassi nel documento finale:
la sintassi sarà disponibile con la prossima release di Highlight.
Ho anche creato un repository dedicato alle grammatiche PolyGen che ho trovato in giro:
Però ho filtrato i contenuti tramite .gitignore
, perché qui su GitHub è meglio filtrare le grammatiche che usano troppe parolacce, o hanno riferimenti sessuali, ecc. In locale ho creato una branch di questo repo in cui ho aggiunto come submodule quest'altro progetto delle grammatiche, così è facile aggiornarlo automaticamente quando il puntatore si sposta a monte.
Ti ho appena sottoposto un pull request (PR #4) per includere le grammatiche in questo progetto.
Guarda, il fatto che ci siano tutti i binari sul repo è perché avevo cominciato qualche mese fa (o forse anno :P) a rilavorarci, ma poi non sono più andato avanti ed ho lasciato tutto là. Se hai voglia di ripulire tu, volentieri! In realtà ogni tanto mi riappassiono, ma per anni non l'ho toccato perché mi ero messo a fare altre cose. Ma mi fa piacere avere un contributor attivo! Magari mi fai tornare la voglia anche a me! :)
Metterei nel repo le seguenti cose:
1) sorgenti dell'ultima versione stabile e sorgenti dell'ultima versione in sviluppo - ne ho una ferma da anni in cui ho rivoluzionato il label-system, ma non l'ho mai finito :P Ma magari appunto o mi torna voglia o qualcuno ha voglia di aiutarmi.
2) una cartella con tutte le grm esistenti, organizzate per lingua. Io possiedo il pacchetto completo ovviamente, che conservo sul mio computer.
3) pacchetto eseguibile per le maggiori piattaforme, in modo che non sia necessario compilarsi l'aggeggio con ocaml che non ha nessuno
4) documentazione (che esiste sul sito polygen.org, ma forse la versione inglese è allineata alle feature più avanzate, quella forse era quella in italiano a non esserlo, non ricordo più), anche in markdown se hai voglia
5) cartella "goodies" con dentro syntax highlightening ed altre diavolerie
Toglierei naturalmente gli artefatti di compilazione di ocaml, come dicevo sopra (sono lì per sbaglio, perché ho mollato tutto là).
Il giorno 8 gennaio 2018 15:16, Tristano Ajmone notifications@github.com ha scritto:
Ciao Alvise,
Scusa se mi faccio vivo ora, ma non ricevo mai notifiche su Github e non mi ero accorto!
... nessun problema, intolre ci sono state le feste di mezzo.
Quindi ricapitolami la situazione: sei riuscito a far funzionare il Folpygel su W10 e sistemato la cosa con la dll di cygwin, giusto?
Sì, inizialmente ho seguito le istruzioni di Vittorio Ramponi:
- https://www.facebook.com/groups/35567209510/permalink/ 10155675705689511/
ma poi sono riuscito a trovare una versione di cygwin1.dll (la v2.9.0-3) che funziona ancora meglio:
- http://mirrors.kernel.org/sourceware/cygwin/x86/release/ cygwin/cygwin-2.9.0-3.tar.xz
... con questa DLL non serve impostare l'esecuzione in modalità compatiblità né per polygen.exe né per PolyGUI, e dispensa anche dall'impostare la variabile d'ambiente CYGWIN=nodosfilewarning. Ora PolyGen funziona sia da PolyGUI che da CDM e anche Bash (nessun errore riportato, neanche il WARNING: Couldn't compute FAST_CWD pointer). Testato su Win 10 x64.
La soluzione di Vittorio impediva l'uso da CMD e Bash, per via della modalità compatibilità (oltre al fastidioso messaggio di autorizazzione ad apportare modifiche).
Volevo postare la soluzione su Facebook, ma era necessario iscriversi al gruppo (e sto attendendo la conferma d'iscrizione).
Hai committato?
No, volevo appunto aspettare di entrare in contatto con te. Come hai visto dalla mia pull request (#1 https://github.com/alvisespano/Polygen/issues/1), proponevo di eleminare i file binary dal repository (soprattutto in un ottica cross platform). Ma credo che sarebbe una buona idea mettere nella root uno zippato con PolyGen, PolyGUI e la DLL giusta per farlo funzionare su Win 10 — in fondo si tratterebbe di un file di piccole dimensioni. In alternativa, potresti fare una release per questo codice, ed allegare il binario lì; però questo codice è alla v1.0.7, mentre l'exe che uso è ancora la v1.0.6.
Se per te va bene, me ne occupo io e poi ti faccio una PR. L'unico dubbio che ho riguarda PolyGUI, non trovo alcuna menzione circa la sua licenza; so che l'autore ne ha concesso la distribuzione gratuita su polygen.org, ma non so se questa autorizzazione sia estesa ad altri siti. Invece, per PolyGen e cygwin1.dll, mi basta allegare la licenza di PolyGen e la GPLv3.
Riguardo OCaml nuovo: sicuramente ricompilarlo gli farebbe bene, perché sono passati anni ed anni e sicuramente il compilatore OCaml oggi è molto migliore di un tempo.
Le versioni per Windows sembrano un po' vecchie, e alcune non girano su Windows 10; nel mio caso, l'antivirus mi ha bloccato quasi tutti i binari di OCaml per Windows. Però non ho provato tutte le versioni disponibili, solo una. Credo comunque sia meglio cross-compilare da Linux, usando MinGW.
Tuttavia temo non sia possibile ovviare alla necessità di avere la ddl di cygwin, a meno di qualche grossa novità di cui non sono a conoscenza.
Credo che usando MinGW-w64 https://mingw-w64.org (anche per compilare a 32 bit) sia possible ovviare alla necessità della DLL. Pare che ora molte librerie siano in grado di girare nativamente, ma ci sono eccezioni alla regola.
Nella mia versione locale sto creando varie branch che contavo di sottoporrti come pull-request da qui a breve. Per esempio, sto lavorando alla documentazione per la stesura delle gramamtiche (documento HTML italiano e inglese), e sto riconvertendo il documento da HTML a markdown, per poterlo poi convertire in vari formati. Contavo anche di rivedere la traduzione inglese, che mi pare riferirsi a una versione precedente di PolyGen, la cui sintassi era molto ridotta.
Ho anche creato una sintassi delle grammatiche PolyGen per Highlight http://www.andre-simon.de/doku/highlight/en/highlight.php, di modo da poter colorare per bene la sintassi nel documento finale:
- https://github.com/andre-simon/highlight/blob/master/ langDefs/polygen.lang
la sintassi sarà disponibile con la prossima release di Highlight.
Ho anche creato un repository dedicato alle grammatiche PolyGen che ho trovato in giro:
Però ho filtrato i contenuti tramite .gitignore, perché qui su GitHub è meglio filtrare le grammatiche che usano troppe parolacce, o hanno riferimenti sessuali, ecc. In locale ho creato una branch di questo repo in cui ho aggiunto come submodule quest'altro progetto delle grammatiche, così è facile aggiornarlo automaticamente quando il puntatore si sposta a monte.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alvisespano/Polygen/issues/1#issuecomment-355977774, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxhYdAHA-l8lfBLsenNGotjoI0EYUks5tIiMkgaJpZM4RPvDI .
Sono d'accordo. Se inizi a fare il merging di #2 e #4, risolviamo il problema della pulizia dei sorgenti, ed anche il punto 2 (in parte solo, dato che le mia lista di grammatiche è incompleta). E io posso cancellare tutte ste branch diverse e reintegrare le modifiche dal tuo upstream (finche non mergi i file .gitignore
e .gitattributes
di #2, in tutte le altre branch di lavoro mi ritrovo un sacco di file che non risultano ignorati, e intasano un po' l'area di lavoro)
In realtà ogni tanto mi riappassiono
questo non sarà un problema dato che nel PR #2 aggiungo un file .gitignore
che ti consentirà di compilare liberamente nella cartella senza che i file binari risultino come nuovi file da committare — il problema è che siccome questi file sono già in tracking, prima vanno cancellati, di modo che il .gitignore
possa ignorarli in futuro. Con il merge di #2 risolvi questo problema, e poi puoi anche ributtare nella cartella tutti i file che c'erano prima, tanto verrano ignorati da lì in poi.
Ma mi fa piacere avere un contributor attivo! Magari mi fai tornare la voglia anche a me! :)
Volentieri. Come ti ho detto, sto lavorando ad uno zippato con la versione funzionante per Win 10 (PolyGen + PolyGUI, + Cygwin DLL + licenze varie, etc). Per la documentazione mi ci vorrà un po' di più temo, ma ci sto lavorando.
Comunque, quando qualcosa è pronto faccio una PR, e se la proposta di piace devi solo fare il merging. Anche se non svilupperai più il codice sorgente di PolyGen, è sempre bene avere un repository ufficiale che lo rendo disponibile. Concordo, OCaml non è più tanto usato oggi, ed è anche un po' complicato farlo girare sui sistemi Windows più recenti. Però i codici sorgenti tornano sempre utile, e sperimentare non guasta.
PS: nello zippato che sto preparando ho scritto che PolyGUI è un programma freeware di ^anakin^. Non trovo alcuna licenza, neanche nell'"About" — ma neanche il Copyright, quindi desumo sia liberamente distribuibile (visto che così è stato per oltre 20 anni). Concordi?
Ok, ho aggiunto lo zippato con i file binari per Win 10 (commit 52983fe).
Per stare sul sicuro, ho aggiunto anche i sorgenti di Cygwin DLL zippati — bastava un link a dove scaricarli, ma se poi quel link fosse morto e si continuava a distribuire questo zippato si sarebbe finito per violare i termini della GPLv3. Dato che si tratta di uno zippato di c.ca 15Kb, ho fato che metterlo, e già che c'ero anche lo zippato dei sorgenti di PolyGen.
Ho incluso PolyGUI, citandone l'autore e il link di provenienza, e spiegando che da due decenni vieni condiviso liberamenta (freeware).
Ho ritoccato il README principale, per menzionare la disponibilità dei binari compatibli Win 10.
Ho visto che hai mergiato tutto, bene. Tra l'altro avevo un gitignore che ovviamente addava .cmx e tutte le minchiate di ocaml, ancora da committare da tipo 2 anni :D Domani dal computer del lavoro vedo che ho grm che non hai committato tu - forse le hai già trovate tutte. Riguardo lo zip con gli eseguibili, va benissimo e ti ringrazio per l'ordine. Tuttavia non includere lo zip con i src, perché ci sono già nel repo e sarebbe una replicazione un po' error-prone, nel senso che andrebbe mantenuta aggiornata con ogni aggiornamento dei sorgenti. A meno che non intendi che quello zip di sorgenti rappresenta una specie di "i vecchi sorgenti storici del polygen". In tal caso potrebbe avere senso.
Tuttavia non includere lo zip con i src, perché ci sono già nel repo e sarebbe una replicazione un po' error-prone, nel senso che andrebbe mantenuta aggiornata con ogni aggiornamento dei sorgenti. A meno che non intendi che quello zip di sorgenti rappresenta una specie di "i vecchi sorgenti storici del polygen". In tal caso potrebbe avere senso.
Sì, sono i source della 1.0.6, ossia dell'exe che c'è nello zippato (nel repo vedo solo il codice della 1.0.7). L'unica ragione per cui li ho inclusi (soprattutto per quanto riguarda Cygwin DLL) è di natura legale: la GPL pretende l'inclusione dei sorgenti, ma concede anche di fornire un link ad sito (proprio o di terzi parti) che consenta il download di tali sorgenti.
Il problema è che se fornisco il link da cui ho scaricato la DLL, e poi quel sito dovesse chiudere i battenti (cosa probabile, dato che è un sito già un po' datato), ci ritroveremmo in violazione della GPL (su questo punto la GPL è chiara), con conseguente perdita dei diritti a usare la DLL! La questione sarebbe oltremodo complessa, dato che in teoria le conseguenze si estenderebbero a chi ha fatto il commit, a chi gestice il repository, ecc. In teoria, si perderebbe anche il diritto a ogni progetto che include la DLL.
Ho ritenuto che includere due zippati da 15Kb (ulteriormente compressi nell'archivio che li ospita) non valeva le potenziali complicazioni. Probabilmente la maggior parte degli utenti cancellerà gli zippati col sorgente, ma il nostro dovere nei confronti della licenza si limita averli forniti.
E, no, non intendevo aggiornare i sorgenti di PolyGen, a meno che non cambia il binario compilato.
Ciao,
mi sono accorto che Polygen (
polygen.exe
) non funziona più su Windows 10 (x64). Se ricordo bene, con Win 7 funzionava ancora, ma dopo l'aggiornamento a Win 10 non ho più avuto occasione di usarlo. Ho la versione v1.0.6 scaricata dal sito ufficiale, con la GUI e le DLL richieste.Ho provato a farlo eseguire in modalità compatibilità, ma il processo
polygen.exe
sembra avviare sottoprocessi di sé stesso all'infinito, intasando tutte le risorse di sistema.Ho visto che il codice pubblicato qui è alla versione 1.0.7, e quindi più aggiornato. Mi chiedevo se potevi pubblicare i file binari per Windows, qui (creando una release per il tag
1.0.7
) o sul sito ufficiale, compilata con una versione più recente di OCaml.Io putroppo non ho installato OCaml, e ho visto che ne esistono varie versioni per Windows. La versione OCPWin, distribuita da TypeRex include MinGW, è probabilmente sarebbe in grado di compilare Polygen senza che il binario finale richieda DLL aggiuntive di Cygwin:
Il mio timore è che, avendo io già una versione di MinGW (più vecchiotta) possano sorgere conflitti con l'installazione di OCPWin.