<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-07 6:45 GMT+01:00 germano carella <span dir="ltr"><<a href="mailto:germano.carella@gmail.com" target="_blank">germano.carella@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>Il 07/07/2015 00:27, enrico franchi ha
scritto:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-07-06 20:09 GMT+01:00 germano
carella <span dir="ltr"><<a href="mailto:germano.carella@gmail.com" target="_blank">germano.carella@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="overflow:hidden">Per
scrivere un editor a questo punto è semplicissimo,
perché basta sapere dove si trova il cursore... yeah!<br>
</div>
</blockquote>
</div>
<br>
Vedrai che ci saranno ancora parecchi punti spinosi; in
generale l'auto-completamento in Python e' molto limitato
(anche con Jedi) e per farlo funzionare a modo si cerca di
incrociare tutto l'incrociabile. Per intenderci, spesso si
cerca anche di inferire roba dalla documentazione oltre che
dai call sites e perfino dagli unittest (quando l'utente li
esegue, ovviamente, non prima).</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">In effetti *anche* con Jedi scrivere un
editor non e' semplicissimo. Prova ne e' che la maggior parte
degli editor ed ide la fuori fanno pena; principalmente
perche' arrivare al 70% e' "facile", ma per avere un buon
editor non basta. Insomma, fidati che ce ne e' ancora tanto di
divertimento prima di arrivare in fondo.</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote></span>
Sì sì, ho già visto, per esempio, che se importi il modulo clr,
(package pythonnet), jedi non riconosce i componenti dotnet tipo
System.Windows.Forms, però inspect.getmembers ci riesce... <br></div></blockquote><div><br></div><div>Eh, bella forza! Uno esegue il modulo e poi chiede direttamente agli oggetti oh, ma tu che metodi hai?</div><div>L'altro fa analisi statica. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">In generale ci sono tanti aspetti...
per dire, che fare con virtualenv? Etc etc etc.</div>
</div>
</blockquote></span>
Giusto... virtualenv non lo avevo considerato... arg! comunque, se
qualcuno volesse aiutarmi io ne sarei felicissimo!!!</div></blockquote><div><br></div><div>Guarda, scusa ma passo. Non ho una macchina windows in 2 case e non so manco che faccia abbia.</div><div>E trovo, sinceramente, il problema delle UI desktop poco interessante. Su tutto, *per me* il problema editor e' risolto dal '91; capisco che per te non lo sia e fai benissimo a proseguire, ma io mi troverei a lavorare su un progetto che non uso. </div><div><br></div><div>Come nota a margine, non sono sicuro che per te la cosa "vincente" sarebbe scrivere da 0 un editor (accessibile) dovendo risolvere tutta una serie di problematiche su cui sei poco familiare invece di lavorare con gli sviluppatori di qualcosa di esistente per renderlo accessibile (e da quello che capisco, sei molto forte sul campo). Poi magari mi dici che i candidati non esistono perche' di fatto si tratterebbe di riscriverli e fine della fiera... pero' non so... Chrome e' accessibile? E Atom?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">Ah, solo una cosa... magari intendevi
altro: abbandona l'idea di un editor che *esegue* codice in
background. La gente non ti vorra' bene se lo fai. Perche'
prima o poi qualcuno digitera' un programma (senza aspettarsi
che venga eseguito -- ancora -- ) e questa cosa potrebbe
cancellargli dei file, mandare la proverbiale email di prova
con titolo "CACCA" al proprio capo, andare in fork bomb, etc
etc etc. Jedi e' ok proprio perche' non *esegue* il codice. Lo
guarda e basta (il che e' safe).</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote></span>
Grazie Enrico, l'ho subito tolta, anche perché non serve piu', come
giustamente dici tu. La mia idea iniziale era quella di poter
segnalare all'utente anche gli errori in fase di scrittura, ecco
perché avevo pensato alla console in background. </div></blockquote><div><br></div><div>Eh... ma puoi farlo (in tanti modi). Solo non eseguire il codice. Ovviamente e' ok passarlo ad un parser e andare ad acchiappare i syntax error, quello si. </div><div>Poi ci sono vari tool per altre classi di errori (PEP8, flake8, pylint) </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div dir="ltr"><span class="">
<div class="gmail_extra">Nota che quello che dicevo sugli
unittest e' diverso: ovvero quando l'utente *sceglie* di
lanciare gli unit-test, l'editor semplicemente raccoglie dati
per fare migliore inferenza sui tipi (ma solo su comando
dell'utente). </div>
<div class="gmail_extra"><br>
</div>
</span><div class="gmail_extra">Ecco... Sugli unit test ho bisogno di
un'infarinatura, perché non ne so molto; anzi, sono proprio
ignorante in materia... :D<br></div></div></blockquote></div></blockquote><div><br></div><div>Ecco, io direi di lavorarci un pochetto. Lavorare ad un'applicazione complessa senza unit-test e' semplicemente tafaziano. Possibile che ci arrivi in fondo, ma se avessi seguito una procedura piu' robusta nello stesso tempo ne avresti scritte 3 di applicazioni complesse. E sarebbero state tutte di qualita' piu' elevata.</div><div> </div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>