OCaml Setup Windows 10

[tajmone]

@alvisespano , dato che la questione di come impostare OCaml ed il suo ambiente di sviluppo su Win 10 continua a fare capolino da più parti, ho pensato di dedicargli un issue tutto suo, sperando che alla fine ne vengano fuori linee guide per risolvere i problemi.

Tristano, te lo chiedo esplicitamente perché mi sta facendo dannare l'anima: hai voglia di cimentarti un po' nel seguire questa guida per VSCode e OCaml? reasonml/reasonml.github.io#195

Io sono arrivato ad avere, come dicevo prima, VSCode che mi builda ocaml e tutto, ma il problem reporting non funziona bene; e neanche il go-to-definition. Nel branch dev trovi i file di configurazione di VSCode e di tutti i *** e *** che le plugin producono (scusa ma sono fuori di me, non ho mai visto un casino del genere in tutta la mia vita). Spero possano aiutarti a configurarlo: se riesci a riprodurre lo stesso ambiente che ho io (e che, per ora, non riesco nemmeno io a riprodurre sul mio secondo computer) magari in due riusciamo a venirne fuori. Se hai voglia eh :)

[tajmone]

VSCode che mi builda ocaml e tutto, ma il problem reporting non funziona bene; e neanche il go-to-definition

Le go-to-definition non sono ancora implementate nel pacchetto OCaml (per VSCode), lo menziona qui:

exception is go-to definition/error line in message panel doesn't work yet

Per problem reporting intendi i BuckleScript "bsb inline errors" o la diagnostica merlin?

Sto leggendo il mega articolo che hai linkato, e seguendo i link che esso stesso offre ... è un po' un casino perché il tutto ruota attorni a 3 prodotti molto giovani e ancora lacunosi e con bachi: WSL, VSCode e reasonml per VSCode.

Già solo la lista di potenziali intoppi e bachi che menziona per WSL è scoraggiante (parla di 4 riavvii del PC per riprendersi da un crash di Bash watch, di disintallare e reinstallare Ubuntu in WSL per via di bachi legati all'account root).

Il nocciolo della questione sembra avere a che fare con la configurazione di VSCode, ossia di fare in modo che invochi comandi bash su WSL anziché nell'ambiente nativo Windows. Non mi è possibile speriemntarlo senza installare WSL. Prima di installare WSL voglio leggere bene la documentazione ... non vorrei ritrovarmi col sistema instabile causa conflitti (ho parecchia roba installata su questo PC, tra cui molti linguaggi e ambienti di sviluppo, però finora sono riuscito a mantenere il sistema stabile e pulito).

[alvisespano]

Rispondo dal telefono quindi sarò breve. Si in effetti i gotodef c'è scritto da qualche parte che non vanno; l'avevo dimenticato. Ma non vanno i tooltip coi tipi inferiti in molti casi ed altri problemi diffusi di parsing dei problems. Comunque temo sia merlin il problema. La demoapp di test di quella guida funziona, ma fa un processo, l'ultimo npm, che resta su e compila sempre a mo di server o demone insomma. Io non ho capito se quella cosa va replicata per i sorgenti del floppybel oppure serve solo se programmi in Reason e non in ocaml liscio. Mi sono fatto i task per makefile inoltre e anche quelli non ho capito se è giusto che ci siano o no. Ho trovato pareri discordanti in rete.

WSL è super pulito: è una sandbox. Verifica se può dare problemi di shadowing nel path di sistema, ma per il resto è chiuso.

Il giorno mer 24 gen 2018 alle 17:29 Tristano Ajmone < notifications@github.com> ha scritto:

VSCode che mi builda ocaml e tutto, ma il problem reporting non funziona bene; e neanche il go-to-definition

Le go-to-definition non sono ancora implementate nel pacchetto OCaml (per VSCode), lo menziona qui https://github.com/reasonml/reasonml.github.io/issues/195#issuecomment-335008528 :

exception is go-to definition/error line in message panel doesn't work yet

Per problem reporting intendi i BuckleScript "bsb inline errors" o la diagnostica merlin?

Sto leggendo il mega articolo che hai linkato, e seguendo i link che esso stesso offre ... è un po' un casino perché il tutto ruota attorni a 3 prodotti molto giovani e ancora lacunosi e con bachi: WSL, VSCode e reasonml per VSCode.

Già solo la lista di potenziali intoppi e bachi che menziona per WSL è scoraggiante (parla di 4 riavvii del PC per riprendersi da un crash di Bash watch, di disintallare e reinstallare Ubuntu in WSL per via di bachi legati all'account root).

Il nocciolo della questione sembra avere a che fare con la configurazione di VSCode, ossia di fare in modo che invochi comandi bash su WSL anziché nell'ambiente nativo Windows. Non mi è possibile speriemntarlo senza installare WSL. Prima di installare WSL voglio leggere bene la documentazione ... non vorrei ritrovarmi col sistema instabile causa conflitti (ho parecchia roba installata su questo PC, tra cui molti linguaggi e ambienti di sviluppo, però finora sono riuscito a mantenere il sistema stabile e pulito).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alvisespano/Polygen/issues/16#issuecomment-360191263, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxprljq7EjdWa4MLJSqooZ5eDwwejks5tN1pQgaJpZM4RreTA .

[tajmone]

Ho installato WSL, ora sto per installare Ubuntu (solo che adesso ci sono più versioni di Linux tra cui scegliere nello MS Store!).

Se mi dai qualche dettaglio in più su cos'altro hai installato, sarebbe utile (es: quale versione di OCaml e dove l'hai presa, e altri pacchetti VSCode).

Le istruzioni per installare OCaml su WSL che ho trovato io, per esempio, indicano di scaricare i pacchetti OPAM non da Ubuntu Canonical, ma da altri ppa.

l'ultimo npm, che resta su e compila sempre a mo di server o demone insomma.

Dopo aver installato ocaml-reason-wsl via NPM (in Windows, non in WSL):

npm install -g ocaml-reason-wsl

è consigliato disinstallare il pacchetto:

npm uninstall -g ocaml-reason-wsl

per evitare appunto conflitti (nota: la disinstallazione cui sopra non va a toccare WSL, perché lo script è già stato eseguito, rimuove solo i collegamenti su Windows ad applicazini dentro WSL). Forse questo è uno dei problemi.

[tajmone]

È allucinante quanto tempo ci voglia per installare OCaml su Ubuntu WSL! Ancora non ha finito. Per fortuna ho trovato una guida (un PDF di 17 pagine!) sull'installazione. Incrocio le dita...

[tajmone]

Perdona il ritardo ma dopo aver installato tutto avevo bisogno di staccare un po'.

A me pare che l'installazione sia andata bene, ho eseguito tutte le verifiche indicate al link che mi avevi dato e tutti i test sono risultati positivi.

Temo che mi dovresti are qualche informazione in più sul tuo setup affinché riesca a capire quale sia il problema.

Comunque temo sia merlin il problema. La demoapp di test di quella guida funziona, ma fa un processo, l'ultimo npm, che resta su e compila sempre a mo di server o demone insomma.

Se ti riferisce alla demo app del link che mi hai dato, con le istruzioni di installazione, allora sì, si tratta di un daemon che fa da ponte tra WSL e Windows (VSCode), ma questo riguarda bucklescript.

Io non ho capito se quella cosa va replicata per i sorgenti del floppybel oppure serve solo se programmi in Reason e non in ocaml liscio.

Dipende se vuoi compilare OCaml in Javascript:

BuckleScript is a backend for the OCaml compiler which emits JavaScript. It works with both vanilla OCaml and Reason, the whole compiler is compiled into JS (and ASM) so that you can play with it in the browser.

Mi sono fatto i task per makefile inoltre e anche quelli non ho capito se è giusto che ci siano o no. Ho trovato pareri discordanti in rete.

Li ho visti, e a me funzionano su VSCode, ma il problema è che la compilazione fallisce per lo stesso errore che ti ho segnalato in #14 (lo stesso riferito da @iacopy su Mac OSX).

Questo è il log di errore che ricevo in VSCode lanciando il build di Polygen/dev:

> Executing task: make <

ocamlbuild -use-ocamlfind main.native
Finished, 1 target (0 cached) in 00:00:01.
+ /usr/bin/ocamlyacc parser.mly
4 rules never reduced
1 shift/reduce conflict, 16 reduce/reduce conflicts.
+ ocamlfind ocamlc -c -o check.cmo check.ml
File "check.ml", line 264, characters 30-43:
Error: This expression has type
         (Prelude.Prelude.symbol *
          ((Absyn.path * int) * A.bind_mode * A.prod))
         list
       but an expression was expected of type (Env.M.key * 'a) list
       Type Prelude.Prelude.symbol = string is not compatible with type
         Env.M.key = Absyn.path
Command exited with code 2.
Compilation unsuccessful after building 24 targets (0 cached) in 00:00:01.
makefile:9: recipe for target 'build' failed
make: *** [build] Error 10
The terminal process terminated with exit code: 2

Press any key to close the terminal.

Però, errore a parte, VSCode sta correttamente invocando il compilatore OCaml su WSL (senza daemon o altro, non ho neanche aperto la Bash di WSL), e non sta cercando di compilare in Javascript attraverso BuckleScript.

Quanto alla funzionalità dell'editor (autocompletamento, colorazione sintassi, ecc) non ho avuto modo di provarle (anche perché non conosco la sintassi di OCaml).

Ad ogni modo, ora mi è chiara la configurazione sia di WSL (e l'installazione di OCaml in Ubuntu WSL) che l'installazione e configurazione di Reason in VSCode.

Appena siamo entrambi online la risolviamo in tempo reale.

[tajmone]

Merlin

Ma non vanno i tooltip coi tipi inferiti in molti casi ed altri problemi diffusi di parsing dei problems. Comunque temo sia merlin il problema.

Merlin richiede un file di configurazione .merlin nella nella root del progetto (e il progetto VSCode va aperto dalla cartella che contiene questo file, nonche la cartella .vscode).

Ho provato ad aggiungere un file .merlin nella cartella src di Polygen/dev con delle impostazioni base, e ora nei suggerimenti dell'autocompletamento compaiono elementi definiti nei sorgenti (che prima non comparivano):

S **

B **

Mi baso su:

https://github.com/ocaml/merlin/wiki/project-configuration

[alvisespano]

Hai mai provato VSCode con la configurazione che ho committato? Cioè, dopo che hai installato WSL, ocaml-reason-wsl, VSCode, la sua plugin e tutto il resto sulla tua macchina, hai provato a lanciare VSCode ed a premere ctrl-shift-B per buildare? Se hai la mia versione dev dovrebbe darti esattamente lo stesso che dà a me: ovvero quell'errore che hai scritto prima. A parte l'errore, come dici tu appunto, sta funzionando. Sì - anche a me, ma solo apparentemente: in realtà dopo 2-3 volte che compili si sballa completamente il parser dei problem ed invece di mostrartene un paio, te ne mostra 300 o 400. Non sto scherzando: si inceppa il meccanismo di merlin (credo) e tutte le righe di codice improvvisamente danno un errore di compilazione, facendo impazzire il problem matcher (che sarebbe il termine generico con cui VSCode si riferisce ai parser degli output dei compilatori).

Discorso divreso invece se segui la sezione della guida che si chiama "Test it": quello è totalmente diverso dal setup di VSCode che ho committato. Sono MOLTO diversi: nel primo c'è un demone di mezzo, nel secondo no; nel primo c'è javascript di mezzo, nel secondo no; nel primo non c'è makefile, nel secondo sì (rifatto da me apposta per ocamlbuild; mentre il vecchio makefile, quello della 1.0.6a anche, builda con delle regole scritte da me); nel primo c'è un task di default che si chiama npm build, nel secondo ho scritto io i task a mano per i target 'clean' e 'build' del nuovo makefile.

Insomma, è questo che intendo dire quando dico che "non riesco a far funzoinare a dovere l'ambiente". Sembra che funzioni, ma in realtà è tutto sghembo perché diverso dalla demoapp che la guida consiglia di fare -- ma la demoapp è il modo giusto di programmare in Reason o anche in OCaml liscio? Non lo so, forse non riesco a spiegarmi bene: sento che qualcosa non va nel setup di VSCode che ho committato in dev, perché sento che è diverso dalla demoapp che consigliano di provare loro come test. E non capisco se questa diversità è perché la demoapp è pensata per js+ml (= Reason) oppure anche per ocaml liscio.

[alvisespano]

Se sei riuscito a far funzionare i tooltip col tipi inferiti (credo grazie al fatto che hai configurato merlin che ti ha creato una cartella .merlin ecc), per favore committa che provo anche io. Temporaneamente lasciamo in dev anche le cose di configurazione dell'ambiente, non git-ingnoriamole altrimenti non possiamo passarci il setup tra noi.

[tajmone]

Sì, i tooltip li vedo, ma il file .merlin l'ho creato manualmente, e non contiene null'altro se non quelle due righe che ho postato qui sopra.

S **

B **

E non capisco se questa diversità è perché la demoapp è pensata per js+ml (= Reason) oppure anche per ocaml liscio.

Sì, la demo app riguarda Javascript (Reason => Buclescript).

Stamattina facendo prove ho ciuccato Ubuntu WSL, quindi devo reinstallarlo da capo. Stavo cercando di installare un cross compilatore OCaml per Windows.

Il problema è che dopo tutta sta fiera per mettere su VSCode e OCaml in WSL, alla fine ci si ritrova con OCaml che compila per Linux, ma il progetto sorgente gestito in Windows tramite VSCode.

Non mi è chiaro il senso: Compilare Polygen per Linux su Windows, e poi cross compilare Polygen per Windows su Linux? Mi pare molto più comodo programmare e compilare Polygen direttamente su Linux — installare un ambiente di lavoro senza casini è molto più semplice. Le buone IDE sono tutte disponibili su Linux e senza intoppi, e cross-compilare è altresì molto più semplice.

A me sto ponte tra VSCode e WSL non è che faccia impazzire: i settaggi richiesti per fare funzionare Reason vanno ad intaccare globalmente VSCode; per esempio, imposta la shell predefinita su WSL, ma questo settaggio non è ideale per lavorare con altri linguaggi in VSCode.

Io avevo installato OCaml 4.04.0 su WSL, ma Reason ti obbliga a switchare a OCaml 4.02.3! Mi pare di capire che funzioni solo con quella versione. Questo è un grosso limite, specie per la cross compilazione — infatti ora ho inciuccato tutto perché ho tentato di fare un switch OPAM a un'altra versione di OCaml (superiore) per cross-compilare.

L'idea di dover restare fissi su una versione del linguaggio solo per soddisfare un plugin della IDE non è ragionevole (la IDE dovrebbe assecondarci, ampliarci le scelte, non tarparci le ali).

Inoltre, come hai fatto notare tu, all'inizio sta configurazione sembra funzionare bene, ma poi si imballa tutto. Seguendo i vari link che si diramano dalle istruzioni per Reason su Win10, si evince che qualcosa non va in questo sistema del ponte tra VSCode e WSL. Mi sembra tutto ancora troppo sperimentale ed instabile, laddove l'ideale sarebbe avere un ambiente di lavoro solido ed affidabile, e non dover lavorare con il timore che qualcosa si sia ingrippato da qualche parte.

E sta cosa che per ogni progetto bisogna crare un file di configurazione merlin la trovo poco pratica (a parte che VSC non ha il concetto di progetto, ma solo cartelle con file di configurazioni).

Comunque sì, direi che l'installazione di Reason su VSC funzionava, nei limiti di quello che è il suo stato attuale (con tutti i problemi annessi e connessi). Concordo, WSL è pulito, e anche ora che l'ho ciuccato posso tranquillamente distriggere Ubuntu senza lasciarmi sporcizia dietro, e ricrearlo da zero in pochi passaggi (pochi ma lentissimi). Ed è comodo che si possano avere più ambienti WSL.

Alla fine dei conti, virtualizzando un'instalalzione di XP sarebbe possibile installare OCaml per Windows senza tutti sti casini (i problemi sono legati a Windows 10, non alle versioni precedenti). Tanto alla fine Polygen lo si compilerà a 32 bit, quindi XP sarebbe un compromesso ragionevole dato che è chiaro che far funzionare OCaml su Windows 10 senza problemi è praticamente impossibile (questo è quello che leggo in rete).

Invece, la cross compilazione da Linux tramite MinGW-w64 dovrebbe produrre binari Windows senza intoppi.

[tajmone]

Sembra che sono riuscito a sistemare WSL, e che funziona ancora con VSC.

Merlin Autocomplete

Se creo un nuovo file nella cartella src di Polygen, dopo aver scritto:

open Absyn

nell'autocomplete mi compaiono i suggerimenti legati alle definizioni in absyn.ml; p.es. se digito Abs nei tooltip compaiono:

() Absyn
() Absyn0
() Absyn1
() Absyn2
() ArrayLabels

Questo lo ottengo con o senza la presenza del file .merlin, quindi non mi è chiaro dove finiscano le funzonalità native di VSCode e dove subentri invece merlin. Ma dalla documentazione di Merlin risulta chiaro che la crezione e settaggio di questo file sia importante per il suo funzionamento.

Tieni conto Alvise che non ho mai usato OCaml, quindi mi risulta molto difficile testare qualsiasi cosa per un linguaggio di cui non ho la più vaga idea riguardo la sintassi. Mi muovo un po' al buio in questo contesto.

[tajmone]

Non mi hai detto molto di come hai configurato VSCode; se merlin non funziona bene è possible che VSCode non sia settato bene (le istruzioni del sito erano un po' confuse su questo punto).

Assicurati solo che le tue User Preferences siano impostate come segue:

{
    "editor.multiCursorModifier": "ctrlCmd",
    "reason.path.bsb": "bash -ic bsb",
    "reason.path.ocamlfind": "bash -ic ocamlfind",
    "reason.path.ocamlmerlin": "bash -ic ocamlmerlin",
    "reason.path.opam": "bash -ic opam",
    "reason.path.rebuild": "bash -ic rebuild",
    "reason.path.refmt": "bash -ic refmt",
    "reason.path.refmterr": "bash -ic refmterr",
    "reason.path.rtop": "bash -ic rtop",
    "editor.formatOnSave": true,
    "reason.diagnostics.tools": [
        "merlin",
        "bsb"
    ],
    "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
    "window.zoomLevel": 0
}

[alvisespano]

Tutto il discorso che hai fatto su VSCode+Ocaml è perfettamente condivisibile: era quello che pensavo anche io, ma volevo provarci - sai com'è quando tenti sperando che tutto sommato ti vada bene :P E invece è un casino pazzesco. Ma c'è un però: io non uso Linux da alcuni anni - non per motivi filosofici, ma semplicemente perché mi sono abituato a Windows ed ho lì tutti i miei ambienti ecc. Non ho voglia di personalizzarmi un altro OS solamente per sviluppare il polygen, perché mi sembra overkill, quindi tentavo a tutti i costi di tirare su un ambiente di sviluppo confortevole su Windows. Certo: posso farmi una vm e usare VSC + OCaml che funziona a bomba su Linux e risolverei tutti i problemi.....in effetti ci penso seriamente, ma mi sto anche abituando all'idea di abbandonare VSCode + plugin ed usare VSCode liscio con la shell di fianco ed un sano makefile. Cioè continuare su Windows, ma praticamente senza IDE: mi arrendo e faccio così, altrimenti non finisco più. Già sono lento perché ci lavoro 10 minuti al giorno (facendo l'integrale delle sessioni da 1 minuto alla volta :D), e se perdo tempo per i casini dell'ide va a finire che non combino niente.

Domanda (forse ne abbiamo già parlato ma mi sono dimenticato): esiste un modo di gli eseguibili compilati su WSL? Faccio fatica a trovare info in merito, ma sono sempre un po' di fretta. Magari tu hai già letto qualcosa in merito.

Per quanto riguarda la mia config di VSCode, ho fatto un misto: prima ho applicato i settings consigliati in quella guida e in altre; dopodiché ho cominciato a capirci qualcosa e mi sono scritto io i tasks; ma il problema credo sia merlin. Non capisco come funziona: cos'è? Un demone? Una libreria? Che roba è? dove gira? come lo faccio partire?

[alvisespano]

Ah aggiungo un particolare: in giro per la rete ho letto che bisogna lanciare VSC da WSL con command line opportuna, affinché funzioni tutta la baracca. Ma trovo pareri discordanti.

[tajmone]

esiste un modo di gli eseguibili compilati su WSL?

manca un pezzo nella domanda! ma su WSL compili binari ELF, non PE. Io in WSL entro nella cartella progetto del disco Windows /mnt/d/percorso/progetto/ così posso avere il progetto sott'occhio da VSC e in contemporanea accessibile a WSL (e tutte le applicazioni installate da Reason, dovessero servire).

ma il problema credo sia merlin. Non capisco come funziona: cos'è? Un demone? Una libreria? Che roba è? dove gira? come lo faccio partire?

è definito un "servizio", ma non ho idea dell'esatta natura (daemon) anche perché nel sotro caso è gestito tramite Node.js che lo interfaccia per Reason.

Però i settaggi riportati dalle istruzioni di Re indicano che è VSC (Reason) a lanciare merlin, tramite bash -ci (che punta direttamente a WSL):

{
    "editor.multiCursorModifier": "ctrlCmd",
    "reason.path.bsb": "bash -ic bsb",
    "reason.path.ocamlfind": "bash -ic ocamlfind",
    "reason.path.ocamlmerlin": "bash -ic ocamlmerlin", <-------------- MERLIN!
    "reason.path.opam": "bash -ic opam",
    "reason.path.rebuild": "bash -ic rebuild",
    "reason.path.refmt": "bash -ic refmt",
    "reason.path.refmterr": "bash -ic refmterr",
    "reason.path.rtop": "bash -ic rtop",
    "editor.formatOnSave": true,
    "reason.diagnostics.tools": [
        "merlin",     <----------------------------------------------- MERLIN!
        "bsb" <-------------- ( BuckleScript / Javascript backend )
    ],
    "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
    "window.zoomLevel": 0
}

Se non usi Bubklescript o compili da Reason/OCaml a Javascript, non dovrebbero interessarti tutti qui pacchetti NPM legati a bsb. Per OCaml nativo serve solo merlin per l'autocompletamento.

ho letto che bisogna lanciare VSC da WSL con command line opportuna, affinché funzioni tutta la baracca. Ma trovo pareri discordanti.

Io non mi sono imbattuto in questo, non in merito a OCaml/Reason. L'unica avvertenza che ho trovato è di aprire con VSCode la cartella che contiene il file .merlin (oltre ai settaggi VSC). Il resto lo fa tramite le preferenze.

È davvero un peccato che la situazione per OCaml su Windows sia diventata così complicata. Tutti ne parlano benissimo di questo linguaggio, ma ormai tutti i riferimenti ufficiali sono incasinati: il sito originale francese di OCaml, e anche ocaml.org, ti indirizzano a file di installazione e guide che non funzionano più. Anche le più recenti contengono riferimenti a ppa ubuntu che non esistono più o che hanno problemi con i certificati. Sembra esserci stato un declino in tal senso, e se i siti ufficiali non offrono link e istruzioni sicure allora è un caos davvero, e finisce che ci si scoraggia.

Io comunque ho installato il cross compilatore OCaml su Ubuntu, già da un po', solo che sto girando in tondo con la documentazione dato che non conosco il linguaggio e devo adattare il makefile alla cross-compilazione (cos'ì com'è compila normalmente per Linux). C'è parecchia roba da leggere quindi vado lento, ma ci arriverò, ora chiederò aiuto all'autore del cross compilatore, su GitHub (le istruzioni che ho trovato funzionano solo con Oasis, non con make).

Installare OCaml e il cross-compilatore per Windows su Ubuntu è stato facile (su WSL non è possibile se si è installato Reason perché confliggono). Inoltre, il cross compilatore è in grado di compilare anche per Maco, Android e iOS.

[alvisespano]

Se ti serve aiuto per makefile, ci sono io.

Il giorno gio 25 gen 2018 alle 20:07 Tristano Ajmone < notifications@github.com> ha scritto:

esiste un modo di gli eseguibili compilati su WSL?

manca un pezzo nella domanda! ma su WSL compili binari ELF, non PE. Io in WSL entro nella cartella progetto del disco Windows /mnt/d/percorso/progetto/ così posso avere il progetto sott'occhio da VSC e in contemporanea accessibile a WSL (e tutte le applicazioni installate da Reason, dovessero servire).

ma il problema credo sia merlin. Non capisco come funziona: cos'è? Un demone? Una libreria? Che roba è? dove gira? come lo faccio partire?

è definito un "servizio", ma non ho idea dell'esatta natura (daemon) anche perché nel sotro caso è gestito tramite Node.js che lo interfaccia per Reason.

Però i settaggi riportati dalle istruzioni di Re indicano che è VSC (Reason) a lanciare merlin, tramite bash -ci (che punta direttamente a WSL):

{ "editor.multiCursorModifier": "ctrlCmd", "reason.path.bsb": "bash -ic bsb", "reason.path.ocamlfind": "bash -ic ocamlfind"

, "reason.path.ocamlmerlin": "bash -ic ocamlmerlin", <-------------- MERLIN!

"reason.path.opam": "bash -ic opam",
"reason.path.rebuild": "bash -ic rebuild",
"reason.path.refmt": "bash -ic refmt",
"reason.path.refmterr": "bash -ic refmterr",
"reason.path.rtop": "bash -ic rtop",
"editor.formatOnSave": true,
"reason.diagnostics.tools"

: [ "merlin", <----------------------------------------------- MERLIN! "bsb" <-------------- ( BuckleScript / Javascript backend )

],
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
"window.zoomLevel": 0

}

Se non usi Bubklescript o compili da Reason/OCaml a Javascript, non dovrebbero interessarti tutti qui pacchetti NPM legati a bsb. Per OCaml nativo serve solo merlin per l'autocompletamento.

ho letto che bisogna lanciare VSC da WSL con command line opportuna, affinché funzioni tutta la baracca. Ma trovo pareri discordanti.

Io non mi sono imbattuto in questo, non in merito a OCaml/Reason. L'unica avvertenza che ho trovato è di aprire con VSCode la cartella che contiene il file .merlin (oltre ai settaggi VSC). Il resto lo fa tramite le preferenze.

È davvero un peccato che la situazione per OCaml su Windows sia diventata così complicata. Tutti ne parlano benissimo di questo linguaggio, ma ormai tutti i riferimenti ufficiali sono incasinati: il sito originale francese di OCaml, e anche ocaml.org, ti indirizzano a file di installazione e guide che non funzionano più. Anche le più recenti contengono riferimenti a ppa ubuntu che non esistono più o che hanno problemi con i certificati. Sembra esserci stato un declino in tal senso, e se i siti ufficiali non offrono link e istruzioni sicure allora è un caos davvero, e finisce che ci si scoraggia.

Io comunque ho installato il cross compilatore OCaml su Ubuntu, già da un po', solo che sto girando in tondo con la documentazione dato che non conosco il linguaggio e devo adattare il makefile alla cross-compilazione (cos'ì com'è compila normalmente per Linux). C'è parecchia roba da leggere quindi vado lento, ma ci arriverò, ora chiederò aiuto all'autore del cross compilatore, su GitHub (le istruzioni che ho trovato funzionano solo con Oasis, non con make).

Installare OCaml e il cross-compilatore per Windows su Ubuntu è stato facile (su WSL non è possibile se si è installato Reason perché confliggono). Inoltre, il cross compilatore è in grado di compilare anche per Maco, Android e iOS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alvisespano/Polygen/issues/16#issuecomment-360567486, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxqgNCufFheHeGuLFZWHbeqzHxlJbks5tONDegaJpZM4RreTA .

[alvisespano]

Ah e la domanda era: esiste un modo per far girare exe wsl in windows liscio? Io non lo trovo in rete e non ci riesco da solo. Fai sta prova: compila polygen 1.0.6a dal master branch e prova ad invocare l'exe dalla cmd windows liscia: non parte. Tra l'altro per fare questo devi per forza buildare polygen in una dir in /mnt/c/... o comunque in un filesystem Windows visibile da wsl, altrimenti non riesci neanche a lanciarlo l'exe da cmd perche il file system di WSL è un virtual drive, credo.

Il giorno ven 26 gen 2018 alle 08:23 Alvise Spanò spano.alvise@gmail.com ha scritto:

Se ti serve aiuto per makefile, ci sono io.

Il giorno gio 25 gen 2018 alle 20:07 Tristano Ajmone < notifications@github.com> ha scritto:

esiste un modo di gli eseguibili compilati su WSL?

manca un pezzo nella domanda! ma su WSL compili binari ELF, non PE. Io in WSL entro nella cartella progetto del disco Windows /mnt/d/percorso/progetto/ così posso avere il progetto sott'occhio da VSC e in contemporanea accessibile a WSL (e tutte le applicazioni installate da Reason, dovessero servire).

ma il problema credo sia merlin. Non capisco come funziona: cos'è? Un demone? Una libreria? Che roba è? dove gira? come lo faccio partire?

è definito un "servizio", ma non ho idea dell'esatta natura (daemon) anche perché nel sotro caso è gestito tramite Node.js che lo interfaccia per Reason.

Però i settaggi riportati dalle istruzioni di Re indicano che è VSC (Reason) a lanciare merlin, tramite bash -ci (che punta direttamente a WSL):

{ "editor.multiCursorModifier": "ctrlCmd", "reason.path.bsb": "bash -ic bsb", "reason.path.ocamlfind": "bash -ic ocamlfind"

, "reason.path.ocamlmerlin": "bash -ic ocamlmerlin", <-------------- MERLIN!

"reason.path.opam": "bash -ic opam",
"reason.path.rebuild": "bash -ic rebuild",
"reason.path.refmt": "bash -ic refmt",
"reason.path.refmterr": "bash -ic refmterr",
"reason.path.rtop": "bash -ic rtop",
"editor.formatOnSave": true,
"reason.diagnostics.tools"

: [ "merlin", <----------------------------------------------- MERLIN! "bsb" <-------------- ( BuckleScript / Javascript backend )

],
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\bash.exe",
"window.zoomLevel": 0

}

Se non usi Bubklescript o compili da Reason/OCaml a Javascript, non dovrebbero interessarti tutti qui pacchetti NPM legati a bsb. Per OCaml nativo serve solo merlin per l'autocompletamento.

ho letto che bisogna lanciare VSC da WSL con command line opportuna, affinché funzioni tutta la baracca. Ma trovo pareri discordanti.

Io non mi sono imbattuto in questo, non in merito a OCaml/Reason. L'unica avvertenza che ho trovato è di aprire con VSCode la cartella che contiene il file .merlin (oltre ai settaggi VSC). Il resto lo fa tramite le preferenze.

È davvero un peccato che la situazione per OCaml su Windows sia diventata così complicata. Tutti ne parlano benissimo di questo linguaggio, ma ormai tutti i riferimenti ufficiali sono incasinati: il sito originale francese di OCaml, e anche ocaml.org, ti indirizzano a file di installazione e guide che non funzionano più. Anche le più recenti contengono riferimenti a ppa ubuntu che non esistono più o che hanno problemi con i certificati. Sembra esserci stato un declino in tal senso, e se i siti ufficiali non offrono link e istruzioni sicure allora è un caos davvero, e finisce che ci si scoraggia.

Io comunque ho installato il cross compilatore OCaml su Ubuntu, già da un po', solo che sto girando in tondo con la documentazione dato che non conosco il linguaggio e devo adattare il makefile alla cross-compilazione (cos'ì com'è compila normalmente per Linux). C'è parecchia roba da leggere quindi vado lento, ma ci arriverò, ora chiederò aiuto all'autore del cross compilatore, su GitHub (le istruzioni che ho trovato funzionano solo con Oasis, non con make).

Installare OCaml e il cross-compilatore per Windows su Ubuntu è stato facile (su WSL non è possibile se si è installato Reason perché confliggono). Inoltre, il cross compilatore è in grado di compilare anche per Maco, Android e iOS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alvisespano/Polygen/issues/16#issuecomment-360567486, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxqgNCufFheHeGuLFZWHbeqzHxlJbks5tONDegaJpZM4RreTA .

[tajmone]

Il problema è che WSL è Linux al 100%, per cui il compilatore crearà un file ELF, non un eseguibile PE (a meno che non usi un cross-compilatore come MinGW-w64).

Il filesystem di WSL è un po' complicato (mi pare di capire) e non conviene frugare nelle cartelle virtuali di sistema, ma la soluzione è quella che hai detto tu: lavorare in un path tipo /mnt/c/percorso/, di modo che tutti i file siano visibili in Windows tramite path normali (immagino che l'unica limitazione sia quella di dover usare nomi file e cartelle validi in Linux).

[alvisespano]

Ma davvero sono ELF? Cioè, se io li lancio da una macchina Linux con un Intel x64 l'eseguibile parte? E allora ci tocca cross-compilare come facevamo prima. Magari con MinGW stavolta, invece che cygwin. Non so, ci pensiamo.

[alvisespano]

Comunque, ho fatto il file .merlin con la conf di default ed in effetti ora mi funzionano i tooltip col type inference - grazie, era quello. Che dici, lo committo in dev? In teoria non dovrebbero esserci dettagli di IDE o configurazione, ma è più semplice se uno si replica l'ambiente di sviluppo. Magari facciamo un README in cui diciamo "se volete usare VSC potete farlo facilmente perché nel repo ci sono tutti i file di workspace, di merlin, i json con i tasks ecc.".

I task in tasks.json che avevo scritto mi pare funzionino correttamente. A questo punto mi pare che l'unico problema rimasto sia il parser dei problem, che dopo un po' scazza e mi segna centinaia di errori. Ma devo ancora provarlo per un lasso di tempo lungo con merlin funzionante - magari era quello che faceva casino, incrocio le dita :P E ti dirò di più: anche quando riporta gli errori correttamente, in ogni caso li riporta in righe diverse: quindi 1 singolo errore di compilazione in realtà produce molti errori - uno per ogni riga del messaggio d'errore.

[tajmone]

Che dici, lo committo in dev? In teoria non dovrebbero esserci dettagli di IDE o configurazione, ma è più semplice se uno si replica l'ambiente di sviluppo.

Il file .merlin lo metterei sicuramente, alla fine è l'unico standard per gestire la sintassi in OCaml ed è integrabile in tutti gli editor.

Quanto hai settaggi VSCode, non saprei. Da un lato non danno fastidio a chi usa altri editor (li ignora semplicemente), dall'altro oggi è consigliabile esportare i settaggi tramite EditorConfig, un nuovo standard supportato da moltissimi editor (e il numero cresce di continuo):

http://editorconfig.org/

in questo modo i settaggi dovrebbero poter essere importati in tutti gli ambienti IDE più usati, tramite un singolo file .editorconfig. (premetto che non l'ho mai usato, quindi non so come esportare/convertire i settaggi da un IDE al formato EditorConfig). Su GitHub vedo sempre più progetti che includono un .editorconfig, quindi è realmente popolare oggi.

Probabilmente ci sarà un plugin per VSCode che ti genera automaticamente il file .editorconfig, ma non mi sono documentato.

I task in tasks.json che avevo scritto mi pare funzionino correttamente.

anche a me hanno dato l'impressione di funzionare correttamente.

A questo punto mi pare che l'unico problema rimasto sia il parser dei problem, che dopo un po' scazza e mi segna centinaia di errori. Ma devo ancora provarlo per un lasso di tempo lungo con merlin funzionante - magari era quello che faceva casino, incrocio le dita :P

mi risulta che tende a ingripparsi, ma il problema pare essere dal lato WSL e non colpa di Reason. Però sembra anche che i nuovi aggiornamenti di Ubuntu per WSL abbiano risolto parte dei problemi.

Il problema è che se ti ingrippa la bash di WSL ti tocca fare ben 4 reboot di Windows.

E ti dirò di più: anche quando riporta gli errori correttamente, in ogni caso li riporta in righe diverse: quindi 1 singolo errore di compilazione in realtà produce molti errori - uno per ogni riga del messaggio d'errore.

già, ma al momento pare che le scelte sia molto limitate per quanto riguarda OCaml. So che con Vim reason e merlin funzionano alla grande. Vim editor per Windows (che è una GUI, non una console app) è caruccio e ultra veloce, ed ha il vantaggio che è piccolo e disponibile anche in standalone, per cui ci può creare un ambiente Vim-OCaml ad hoc.

[alvisespano]

Comunque, guarda, adesso che ho merlin che funziona mi accontento così - non è niente male! C'è qualche magagnuccia qua e là, ma grossomodo ho l'80% di quello che avrei in VS2017 programmando in F# (che considero la combo ambiente + linguaggio funzionale con la somma più alta al momento). Per aggiornare WSL fai apt-get upgrade/distupgrade/update ecc?

Il giorno 26 gennaio 2018 12:52, Tristano Ajmone notifications@github.com ha scritto:

Che dici, lo committo in dev? In teoria non dovrebbero esserci dettagli di IDE o configurazione, ma è più semplice se uno si replica l'ambiente di sviluppo.

Il file .merlin lo metterei sicuramente, alla fine è l'unico standard per gestire la sintassi in OCaml ed è integrabile in tutti gli editor.

Quanto hai settaggi VSCode, non saprei. Da un lato non danno fastidio a chi usa altri editor (li ignora semplicemente), dall'altro oggi è consigliabile esportare i settaggi tramite EditorConfig, un nuovo standard supportato da moltissimi editor (e il numero cresce di continuo):

http://editorconfig.org/

in questo modo i settaggi dovrebbero poter essere importati in tutti gli ambienti IDE più usati, tramite un singolo file .editorconfig. (premetto che non l'ho mai usato, quindi non so come esportare/convertire i settaggi da un IDE al formato EditorConfig). Su GitHub vedo sempre più progetti che includono un .editorconfig, quindi è realmente popolare oggi.

Probabilmente ci sarà un plugin per VSCode che ti genera automaticamente il file .editorconfig, ma non mi sono documentato.

I task in tasks.json che avevo scritto mi pare funzionino correttamente.

anche a me hanno dato l'impressione di funzionare correttamente.

A questo punto mi pare che l'unico problema rimasto sia il parser dei problem, che dopo un po' scazza e mi segna centinaia di errori. Ma devo ancora provarlo per un lasso di tempo lungo con merlin funzionante - magari era quello che faceva casino, incrocio le dita :P

mi risulta che tende a ingripparsi, ma il problema pare essere dal lato WSL e non colpa di Reason. Però sembra anche che i nuovi aggiornamenti di Ubuntu per WSL abbiano risolto parte dei problemi.

Il problema è che se ti ingrippa la bash di WSL ti tocca fare ben 4 reboot di Windows.

E ti dirò di più: anche quando riporta gli errori correttamente, in ogni caso li riporta in righe diverse: quindi 1 singolo errore di compilazione in realtà produce molti errori - uno per ogni riga del messaggio d'errore.

già, ma al momento pare che le scelte sia molto limitate per quanto riguarda OCaml. So che con Vim reason e merlin funzionano alla grande. Vim editor per Windows (che è una GUI, non una console app) è caruccio e ultra veloce, ed ha il vantaggio che è piccolo e disponibile anche in standalone, per cui ci può creare un ambiente Vim-OCaml ad hoc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alvisespano/Polygen/issues/16#issuecomment-360765912, or mute the thread https://github.com/notifications/unsubscribe-auth/ACcZxszoasGoT5CxJDGKX2uCosSRzbYyks5tObxugaJpZM4RreTA .

[tajmone]

Concordo, in fondo sia VSCode che Reason sono in piena fase di sviluppo, e credo che questi problemi saranno risolti a breve.

Per aggiornare WSL fai apt-get upgrade/distupgrade/update ecc?

Sì, tutto come su Ubuntu via shell.

Riguardo alle configurazioni VSCode del progetto, io credo che valga la pena lasciare la cartella .vscode come parte del progetto. In genere i progetti MSVC includono tutti i settaggi, e si tratta di pochi Kb che fanno risparmiare un sacco di tempo e rogne all'utente finale (che potrebbe non aver mai usato VSC prima). Inoltre, i task sono una parte fondamentale (e a mio avviso integrante) del progetto.

Per chi usasse altre IDE, quella cartella non darà alcun fastidio. Ma credo che VSCode sia de facto la IDE di riferimento moderna per OCaml (esclusi i vari fan di Emacs e Vim).