WIF - La Community Italiana di The Battle for Wesnoth

Wesnoth Italian Forum
La Community Italiana di The Battle for Wesnoth uno dei migliori giochi multiplayer online gratis open source, a turni di ambientazione fantasy. Iscriviti a wifper partecipare ai tornei online, allo sviluppo di nuove estensioni (campagne, mappe, ere, scenari, fazioni) e a tutte le iniziative di w.i.f. per questo meraviglioso gioco strategia . Giocare gratis on line non è mai stato più facile.

Se stai cercando giochi multiplayer online, giochi di strategia, giochi a turni, giochi open source, giochi gratuiti o giochi fantasy, vieni a giocare online in multiplayer con noi! Questo è il forum che cercavi.
19 Agosto 2017, 16:02:50 *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
 Notizia
VENITE A TROVARCI NELLA CHAT DI W.I.F.
- per organizzare partite ed incontri Ghigno  -
Ti aspettiamo!
Ricerca avanzata  
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: Wesnoth ha bisogno di te!  (Letto 2593 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« inserita:: 25 Luglio 2015, 10:31:41 »

Salve, membri della comunità di Wesnoth.

Dodici anni fa, David White un fine settimana si mise a creare un piccolo progetto che oggi conosciamo come The Battle For Wesnoth. All'epoca, Dave era l'unico programmatore del gioco, e lavorava assieme ad un'altra persona, Francisco Muñoz, il quale produsse le prime grafiche del gioco. Con l'aumentare delle persone che contribuivano negli anni successivi, il gioco crebbe da un piccolo progetto personale a quello estensivo che conosciamo oggi. Se leggete i crediti, vi troverete centinaia e centinaia di nomi che hanno dedicato decine di migliaia di ore a contribuire allo sviluppo di Wesnoth. A tutte le persone in questa lista, specialmente a quelle che sono ancora attive a tutt'oggi, va il nostro sincero ringraziamento.

Purtroppo, una dura verità deve essere affrontata: lo staff di Wesnoth è sottodimensionato. Attualmente, ci sono meno di una mezza dozzina di sviluppatori che lavorano su ogni nuova versione del gioco, e ancora meno sono quelli in grado di lavorare sul motore stesso. Collettivamente non abbiamo il tempo o le capacità per risolvere i bug velocemente come dovremmo, o implementare nuove funzionalità rapidamente come vorremmo. Il gioco stesso risente dell'uso di vecchio codice e vecchi software. Mentre l'industria dei videogiochi avanza e pure i giochi più semplici diventano sempre più complessi, Wesnoth ha cominciato a sembrare vetusto. La nostra organizzazione interna ha bisogno di essere migliorata. Il lungo tempo richiesto dal ciclo di sviluppo 1.11.x è stato dovuto, più che al nostro lavorare su bugfix e funzionalità, alla nostra inabilità a fare queste cose in modo tempestivo.

Per farla breve, questa nave sta affondando.

Wesnoth ha sempre avuto una comunità di fan incredibilmente dedicata e creativa. I vostri bug report e test ci sono stati incredibilmente d'aiuto per smussare gli spigoli vivi; senza di voi il gioco sarebbe morto silenziosamente svariati anni fa. Ma adesso abbiamo bisogno del vostro aiuto per qualcosa di più.

Questa è una richiesta d'aiuto ufficiale a chiunque, sia dentro che fuori la nostra comunità, voglia assisterci nello sviluppo di The Battle for Wesnoth. Particolarmente richiesti sono:

  • Programmatori C++ con una conoscenza del linguaggio da intermedia ad avanzata, preferibilmente con precedenti esperienze nella manutenzione di grossi progetti. Avere esperienza nel lavorare su giochi complessi come Wesnoth sarebbe utile. Siamo in particolare necessità di gente in grado di aiutarci nello sviluppo su Microsoft Windows e Apple OS X, entrambe piattaforme su cui Wesnoth soffre di bug di lungo corso che hanno un pesante impatto sull'usabilità del gioco.
  • Programmatori Python in grado di mantenere, e possibilmente di migliorare, i nostri strumenti di manutenzione, inclusi wmllint, wmlindent, and wmlscope.
  • Programmatori WML in grado di mantenere le campagne attualmente non mantenute: L'Erede al Trono, Acque Morte, Le Memorie di Delfador, Libertà, La Leggenda di Wesmere, Lo Scettro di Fuoco, L'Alba di Wesnoth, La Guardia del Sud, L'Invasione dell'Est, e Il Figlio di Occhio Nero.
    In particolare, La Leggenda di Wesmere ha disperato bisogno di gente che voglia investire tempo nel testare e risolvere i problemi del porting multiplayer in entrambe le versioni 1.12.x e 1.13.x, altrimenti questo rischierà di venire rimosso nelle future versioni stabili.
  • Si prega di notare che i volontari dovrebbero avere buone capacità di comunicazione e possibilmente avere esperienza nel lavorare assieme ad altri colleghi in un grosso progetto. Il nostro obiettivo è di mantenere una relazione aperta ed amichevole tra il team di sviluppo e la comunità.

Speriamo, col tuo aiuto, di riuscire a portare Wesnoth sempre più in alto e ad avere sempre più entusiasti. Abbiamo già pianificato di rilasciare Wesnoth gratuitamente su Steam una volta che avremo abbastanza membri attivi per poter risolvere velocemente i problemi quando questi vengono segnalati. Speriamo di renderlo una realtà, e anche di andare oltre. Ma ancora una volta, abbiamo bisogno del tuo aiuto per farlo accadere.

Chiunque sia interessato può entrare nel canale IRC #wesnoth-dev su irc.freenode.net (sia tramite il proprio client IRC preferito o con la webchat di freenode) e partecipare alla discussione degli sviluppatori, che contiene anche consigli utili su come iniziare. In tutti i casi, la lingua da utilizzare è l'Inglese.

Grazie!



Questo messaggio è postato in nome e per conto del team di sviluppo di The Battle for Wesnoth. Il post originale in Inglese può essere letto qui: http://forums.wesnoth.org/viewtopic.php?f=62&p=587671#p587671.
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Nobun
Moderatore Globale e Vincitore Torneo di Singolare 2011
*
Scollegato Scollegato

Messaggi: 691


Negromante elementale del Vento


« Risposta #1 inserita:: 25 Luglio 2015, 12:24:23 »

Intervengo in commento per segnalare una cosa da far presente allo staff Wesnoth, se cerca collaborazione attiva, e mi riferisco soprattutto per la richiesta di programmatori c++.

Faccio un intervento Al di là del dato personale (non rientrerei comunque nei profili richiesti... non sono un programmatore, se non per hobby... non ho mai lavorato in gruppo e soprattutto il mio livello di programmazione non so se arrivi nemmeno ad "intermedio"... conosco il c++ abbastanza decentemente, ma non so quanto....

Però, dicevo, al di là della mia situazione personale intravedo una criticità che rende difficile al momento ad un programmatore (anche esperto) di inserirsi e collaborare col progetto... la mancanza di una struttura chiara e organizzata del codice sorgente e soprattutto una grossa carenza nella documentazione sul funzionamento di ogni componente e di come è diviso il codice, spesso diventa difficoltoso intervenire perché non è ben chiaro come i vari file sorgenti .cpp dividono il lavoro tra di loro... questo impone al programmatore esperto di dover impiegare diverso tempo per capire come intervenire nel codice, perché spesso non è chiaro dove una funzionalità sia collocata... ed in un codice sorgente vasto come quello di wesnoth, diventa prioritario fare in modo che l'individuazione del punto (o dei punti) da modificare sia il più possibile immediata.

Al programmatore intermedio (se per intermedio si intende il mio livello, ma non credo che il livello intermedio sia così basso) la difficoltà si trasforma in impossibilità, nel senso che personalmente non capisco come ci si possa districare in quel sorgente.

Sarebbe quindi necessario razionalizzare ancora di più la nomenclatura dei file sorgenti, cercando di fare una nomenclatura ed una collocazione degli stessi che sia ancora più precisa di come è ora, più strutturale, e soprattutto più documentata, dando più spazio ai commenti ma anche valutando di potenziare la documentazione attraverso un uso più consistente di doxygen.

Insomma è prioritario rendere il codice, per quanto possibile, più fruibile di come appare ora (o comunque di come appariva l'ultima volta che provai a dare una occhiata analitica ai sorgenti.... nello specifico mi riferisco ai sorgenti nella versione 1.10.x)
Registrato



A VOLTE ATTIVO, A VOLTE NO
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #2 inserita:: 26 Luglio 2015, 09:51:38 »

Però, dicevo, al di là della mia situazione personale intravedo una criticità che rende difficile al momento ad un programmatore (anche esperto) di inserirsi e collaborare col progetto... la mancanza di una struttura chiara e organizzata del codice sorgente e soprattutto una grossa carenza nella documentazione sul funzionamento di ogni componente e di come è diviso il codice, spesso diventa difficoltoso intervenire perché non è ben chiaro come i vari file sorgenti .cpp dividono il lavoro tra di loro... questo impone al programmatore esperto di dover impiegare diverso tempo per capire come intervenire nel codice, perché spesso non è chiaro dove una funzionalità sia collocata... ed in un codice sorgente vasto come quello di wesnoth, diventa prioritario fare in modo che l'individuazione del punto (o dei punti) da modificare sia il più possibile immediata.
È inutile nascondersi dietro a un dito: hai ragione. Il problema è che alcuni sviluppatori del passato inserivano il loro codice (inutilmente complicato e incomprensibile in alcuni frangenti), non lo commentavano o documentavano in alcun modo e poi sparivano nel nulla. Proprio per questo siamo arrivati alla situazione attuale.
Sarebbe quindi necessario razionalizzare ancora di più la nomenclatura dei file sorgenti, cercando di fare una nomenclatura ed una collocazione degli stessi che sia ancora più precisa di come è ora, più strutturale, e soprattutto più documentata, dando più spazio ai commenti ma anche valutando di potenziare la documentazione attraverso un uso più consistente di doxygen.
Certamente. Nel mio caso, ogni volta che introduco una nuova funzionalità, non faccio mai mancare i miei commenti. Ad esempio, questa pull request che ho preparato è carica di commenti che spiegano il perché il codice è strutturato in quel modo. Certo, non è C++, ma un misto di WML e Lua, ma il punto rimane.
Nel caso volessi nuovamente provare a contribuire, le nostre porte sono aperte Sorriso
« Ultima modifica: 26 Luglio 2015, 09:57:29 da Elvish_Hunter » Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Nobun
Moderatore Globale e Vincitore Torneo di Singolare 2011
*
Scollegato Scollegato

Messaggi: 691


Negromante elementale del Vento


« Risposta #3 inserita:: 26 Luglio 2015, 10:43:23 »

Come dicevo mi sono limitato ad osservazioni generali, anche perché non credo di avere sufficienti conoscenze per collaborare davvero, e sicuramente avrei problemi di tempo a dir poco grossi (nella vita reale non sono un programmatore, quindi programmare funzionalità a ritmi prestabiliti può risultarmi impossibile).

Per farti un esempio stupido... Quando si tratta di casting sono abituato a fare il c casting e non usare le funzioni template tipo static_cast o simili... non ho mai imparato ad usarle e questo può essere un problema, visto le coding policy di wesnoth (per carità, hanno pienamente ragione a dare quell'indicazione... questo è un esempio di carenza personale).

Delle domande preliminari sulla conoscenza del C++ per stabilire se ne conosco abbastanza per collaborare devo confessare che non sono sicuro di saper rispondere a tutte le domande...

Mi riferisco al "c++ quiz" di http://wiki.wesnoth.org/HackingWesnoth

Tanto per dartene una idea:
    What is a virtual destructor? Why is it needed?

A dire la verità ho usato il polimorfismo una sola volta in tutta la mia vita (nel mio progetto Nomen dove avevo bisogno di una sorta di "polimorfismo inverso" in cui ho creato un sistema più o meno mio)... solo che i distruttori tendenzialmente li uso in casi estremamente rari, e cioè quando è necessario distruggere esplicitamente un puntatore allocato all'interno di un oggetto della classe e che deve essere distrutto alla distruzione dell'oggetto stesso per non rimanere inutilmente in memoria. Negli altri casi i distruttori non li uso mai esplicitamente. Non sarei sicurissimo di saper rispondere alla domanda.... diciamo che risponderei "uso il distruttore virtuale nel caso in cui devo creare una classe base che deve essere ereditata e che può  aver necessità di dover ridefinire, nella classe figlia, un proprio distruttore che interagisca con il distruttore della classe madre con distruttore virtuale"... anche se non ho ben chiaro come e quando utilizzare la cosa... il polimorfismo l'ho utilizzato una sola volta, come ti ho detto... ed in tal caso non usai i distruttori virtuali

    What does the class template shared_ptr do? What is its purpose?
Qui non saprei rispondere... Gli smart pointer non li ho mai capiti... La mia concezione di puntatori è molto più "c-style"... quindi static_ptr e shared_ptr non li ho mai capiti (ricordo che sono autoditatta Felice)   

What is a vector, and why would you use it?
Ok questa è facile... non rispondo nemmeno... Sono abituato ad usare QList e QVector che hanno una logica simile rispetto a std::vector che è un po' più limitato come funzionalità... ma al bisogno, almeno per le cose base lo so usare

    What is a map, and why would you use it?
Qui credo di saper rispondere... però qui siamo in un capitolo avanzato, che è l'ottimizzazione di codice. Quando si parla di tempi di ricerca si va su un livello di conoscenza che va oltre a quella di matematica del Liceo Classico... Quando vedo espressioni di calcolo di tempo come O(n) non credo di essere sicuro di capire.
So solo che le map servono tendenzialmente a strutturare una lista di informazioni usando un criterio ad albero che serve ad individuare il singolo elemento più velocemente, ecco il perché dell'associazione ad un valore "indice" che serve come criterio di posizionamento interno del singolo elemento (se ho capito bene)

    What are the differences between a reference and a pointer? When should each be used?
Ok questa la so, quanto meno da un punto di vista pratico (anche se non teorico). So che un reference non può mai essere NULL ed è già automaticamente dereferenziato.
I reference li uso quando devo passare un valore che è già deferenziato ad una funzione o a una classe. I puntatori invece li uso in casi più peculiari (tipo in wespo i puntatori li ho usati per creare quella sorta di sistema di "nodi ad albero" per leggere ed interpretare il WML ed estrarre le informazioni utili da utilizzare poi nella fase di creazione del file .po)

    What is an iterator, and when is it used?
Più o meno lo so, anche se ammetto che uso pochissimo gli iterator e preferisco l'approccio di ricerca dell'elemento dereferenziando il singolo elemento con l'operatore [n]. Mea culpa

    What are the memory areas in a C++ program, and what is the purpose of each?
Questa domanda non credo proprio di averla capita -.-

    When should a member function be const? What effect does this have?
Qui non saprei rispondere, paradossalmente.
Potrei dire: in alcuni casi di overload degli operatori è necessario che il valore passato sia di tipo const
ma una regola generale non la conosco... tendenzialmente uso const solo in casi di estrema necessità quando proprio non posso farne a meno o (a volte) quando devo passare un valore per reference quando voglio evitare il rischio di modificare per errore il valore in questione. Anche se in questo secondo caso preferisco stare attento io a non modificare il valore piuttosto che usare const

    What is a copy constructor, and what is an assignment operator? When must you define them in a class?
Questa domanda è stronza. Non credo di saper rispondere, perché le regole per overloadare l'operatore = è spesso sfuggente. Tendenzialmente evito l'uso oppure uso un metodo molto empirico... cerco su internet esempi, provo diverse soluzioni, fino a che non trovo una soluzione che funziona Linguaccia

Ecco... questo è il mio livello di C++ Felice
Registrato



A VOLTE ATTIVO, A VOLTE NO
Yomar
Eroe del Reame
*****
Scollegato Scollegato

Messaggi: 419



WWW
« Risposta #4 inserita:: 26 Luglio 2015, 19:48:56 »

Non posso che concordare, nonostante la mia conoscenza piutosto superficiale in fatto di programmazione, perfino io ho notato quanto sia intricata la cosa e la mancanza di commenti non fa che aggravare la situazione, indubbiamente una loro maggiore presenza sarebbe stata molto utile.
Registrato
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #5 inserita:: 28 Luglio 2015, 11:42:34 »

Citazione di: Nobun
non credo di avere sufficienti conoscenze per collaborare davvero, e sicuramente avrei problemi di tempo a dir poco grossi (nella vita reale non sono un programmatore, quindi programmare funzionalità a ritmi prestabiliti può risultarmi impossibile)
Hai appena descritto la mia precisa situazione. Che ci crediate o meno, anch'io sono un autodidatta.
Citazione
i distruttori tendenzialmente li uso in casi estremamente rari, e cioè quando è necessario distruggere esplicitamente un puntatore allocato all'interno di un oggetto della classe e che deve essere distrutto alla distruzione dell'oggetto stesso per non rimanere inutilmente in memoria. Negli altri casi i distruttori non li uso mai esplicitamente. Non sarei sicurissimo di saper rispondere alla domanda.... diciamo che risponderei "uso il distruttore virtuale nel caso in cui devo creare una classe base che deve essere ereditata e che può  aver necessità di dover ridefinire, nella classe figlia, un proprio distruttore che interagisca con il distruttore della classe madre con distruttore virtuale"... anche se non ho ben chiaro come e quando utilizzare la cosa... il polimorfismo l'ho utilizzato una sola volta, come ti ho detto... ed in tal caso non usai i distruttori virtuali
Io risponderei: userei un distruttore virtuale in una classe virtuale che non deve mai essere usata tal quale, in caso contrario le classi derivate (laddove mi dimenticassi di creare i loro distruttori) erediterebbero quello della superclasse, che non andrebbe a ripulire i membri aggiuntivi e creerebbe un memory leak.
Citazione
quindi static_ptr e shared_ptr non li ho mai capiti
Neanch'io (dovrei leggermi un po' di documentazione).
A proposito di vector e map non rispondo nemmeno, visto che sono due tipi di dato estremamente basilari e con equivalenti in quasi ogni altro linguaggio (in Python sono le liste e i dizionari, mentre in Lua le tabelle sono usate per entrambi gli scopi, ad esempio).
Citazione
Ok questa la so, quanto meno da un punto di vista pratico (anche se non teorico). So che un reference non può mai essere NULL ed è già automaticamente dereferenziato.
Ma l'importante differenza (oltre al supporto a NULL) è che, usando un riferimento, non devi preoccuparti di distruggere il puntatore: niente memory leak Fico
Citazione
Più o meno lo so, anche se ammetto che uso pochissimo gli iterator e preferisco l'approccio di ricerca dell'elemento dereferenziando il singolo elemento con l'operatore [n]. Mea culpa
In mainline usiamo gli iteratori praticamente ogni volta che c'è bisogno di traversare un vettore. Talvolta invece usiamo la macro BOOST_FOREACH (che in C++11 è probabilmente inutile, visto che quella versione include il comando foreach).
Citazione
    What are the memory areas in a C++ program, and what is the purpose of each?
Questa domanda non credo proprio di averla capita -.-
Benissimo, allora siamo in due. Mal comune mezzo gaudio Linguaccia A meno che non si riferisca a dove vengono create le variabili, allora la risposta dovrebbe essere lo stack (dove sono create le variabili statiche, e viene ripulito automaticamente se queste vanno fuori dallo scope) e l'heap (dove vengono creati i puntatori, e va ripulito a suon di distruttori e comandi delete, altrimenti si generano i memory leak). Spero di non aver invertito i termini.
Citazione
    When should a member function be const? What effect does this have?
Qui non saprei rispondere, paradossalmente.
Io direi che una funzione deve essere dichiarata const se questa non deve modificare nessuno dei riferimenti passati come argomento, in modo che il compilatore possa ottimizzarla ed emettere gli opportuni errori.
Citazione
    What is a copy constructor, and what is an assignment operator? When must you define them in a class?
Questa domanda è stronza. Non credo di saper rispondere, perché le regole per overloadare l'operatore = è spesso sfuggente.
Sull'overloading dell'operatore di assegnazione concordo. Sul copy constructor, ipotizziamo di avere una classe Color, e di creare un oggetto chiamato Red. Poi scriviamo Color Magenta = Red. Come si deve comportare il programma in questa operazione di copia? Generalmente viene creato un copy constructor standard, ma alle volte è meglio crearne uno che potrebbe, ad esempio, copiare i valori red, green e blue, ma non il valore alpha (se la classe Color avesse questi quattro membri).
Citazione
Ecco... questo è il mio livello di C++
Va bene, penso che potrebbe bastare. Fico
Non posso che concordare, nonostante la mia conoscenza piutosto superficiale in fatto di programmazione, perfino io ho notato quanto sia intricata la cosa e la mancanza di commenti non fa che aggravare la situazione, indubbiamente una loro maggiore presenza sarebbe stata molto utile.
Ma come, non lo sai?
Citazione di: Anonimo
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Ghigno Linguaccia
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Klemvor
Viandante
*
Scollegato Scollegato

Messaggi: 35


For the king for the land for the mountains


« Risposta #6 inserita:: 20 Agosto 2015, 22:04:23 »

Ciao a tutti nella mia presentazione avevo detto che ero disposto a dare una mano! Di Python sapete dirmi che librerie e' necessario conoscere per fare la manutenzione dei programmi di utilita' di BfW?
Registrato
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #7 inserita:: 21 Agosto 2015, 20:43:36 »

Di Python sapete dirmi che librerie e' necessario conoscere per fare la manutenzione dei programmi di utilita' di BfW?
Gli strumenti si trovano nella cartella data/tools (e data/tools/wesnoth per alcuni moduli) di una normale installazione di Wesnoth. Generalmente, gli script usano soltanto i moduli presenti nella libreria standard. Ad esempio, nel caso di wmllint:
Codice:
import sys, os, re, getopt, string, copy, difflib, time, gzip, codecs
wmlscope:
Codice:
import sys, os, time, re, getopt, hashlib, glob, codecs
wmlindent:
Codice:
import sys, os, getopt, filecmp, re, codecs
Inoltre, GUI.pyw usa la libreria grafica Tkinter con l'estensione ttk, wmlscope usa Pillow (uno dei due casi, che io sappia, di utilizzo di un modulo al di fuori della libreria standard) per alcuni controlli sulle immagini, e in un futuro (spero prossimo) trackplacer dovrebbe abbandonare la libreria PyGTK (incompatibile con Python 3) per passare a Tkinter/ttk e Pillow.
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Klemvor
Viandante
*
Scollegato Scollegato

Messaggi: 35


For the king for the land for the mountains


« Risposta #8 inserita:: 23 Agosto 2015, 09:44:21 »

Ok tutte cose abbastanza standard, appena riesco entro in chat dei developers per chiedere la lista dei problemi/migliorie di queste applicazioni, che magari riesco un poco a dedicarmici.
Registrato
Elvish_Hunter
Moderatore globale
*****
Scollegato Scollegato

Messaggi: 673


Lo sviluppator cortese


« Risposta #9 inserita:: 23 Agosto 2015, 16:03:48 »

Ok tutte cose abbastanza standard, appena riesco entro in chat dei developers per chiedere la lista dei problemi/migliorie di queste applicazioni, che magari riesco un poco a dedicarmici.
Va bene. Visto che sono io il dev incaricato di gestire le pull request relative a Python, posso già darti alcune informazioni.
Innanzi tutto, il mio obiettivo è cercare di portare i vari script a Python 3. Per ora sto seguendo un approccio il più soft possibile, importando i vari comandi dai moduli __future__ e future_builtins, in modo da mantenere le modifiche piccole e gestibili.
Poi, un'altra cosa importante è cercare di rendere il codice comprensibile. Attualmente wmllint è composto da circa 3000 righe, che potrebbero essere divise in più file e commentate meglio - ad esempio, il solo elenco delle sostituzioni globali all'inizio del file si prende circa mille righe.
C'è comunque tanto da fare: per esempio, ora sto lavorando sul wmllint-1.4, dopo aver fatto le modifiche più urgenti ai tre tool principali, e sembra che ogni volta che sistemo un bug ne salti fuori un'altro...
Registrato

Manutentore corrente di The Sojournings of Grog, Children of Dragons, A Rough Life e Wesnoth Lua Pack.
The White Troll - topic ufficiale
Klemvor
Viandante
*
Scollegato Scollegato

Messaggi: 35


For the king for the land for the mountains


« Risposta #10 inserita:: 24 Agosto 2015, 10:51:59 »

ok per fortuna da quando sono passato ad Arch Linux che ha come versione di sistema di Python la 3 mi son dovuto fare un po' di mazzo anche io per convertire i miei programmi alla versione 3, quindi penso si possa fare. Ghigno
Registrato
Pagine: [1]   Vai su
  Stampa  
 
Vai a: