Autore Topic: Idea su una libreria comune e condivisa  (Letto 61174 volte)

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #60 il: 07 Agosto 2013, 20:51:34 »
1) vabbè...
2) se la libreria è per gambas, non vedo il motivo di gestire un multilinguaggio, in quanto non sarebbero comunque compatibili. Dato che sono ancora in piedi sia G2 che G3, forse sarà anche utile suffissare, ma allora credo sia meglio indicare la versione di gambas (es. gambas3 o gambas2), oppure ancora separare le due versioni in die cartelle principali, anche se anche qui la vedo alquanto dispersiva, in quanto è la G3 l'ultima e ben presto la G2 diverrà veramente obsoleta.
3) certo!!!
4) ok
5) bisogna prima decidere la struttura prima di metterla in piedi, in quanto, come spiegato in privato, svn mantiene tutto, anche se si cancella (la cancellazione è solo apparente). occupando spazio e nomenclature inutili.
6) se dobbiamo rilasciare una versione del progetto stabile, occorre congelarla in una versione ben precisa, in particolare se a seguito di incompatibilità o errori causati dalla precedente. Tieni conto che gli aggiornamenti si susseguono in continuazione, e non è detto che gli aggiornamenti siano stabili. Il congelamento dell'intera libreria è necessario, una volta che ne viene deciso il rilascio e dopo che tutti i vari componenti siano resi stabili. Lo scaricamento di una libreria con anomalie porterebbe grossi problemi a chi poi le và ad usare, non credi?
7) ok
8) ok
9) questo è da decidere. Il commentare internamente il codice è cosa senz'altro necessaria e utile, anche per far capire agli sviluppatori stessi cosa stà o vuole fare una determinata funzione/metodo. Tieni presente che qui si parla di programmazione in multiutenza e quindi con la collaborazione di più sviluppatori, ognuno con il suo metodo di lavorare. Documentare un determinato algoritmo è quindi reso necessario, particolarmente se complicato. Se dai uno sguardo ai sorgenti pubblicati dei programmi/librerie in rete, puoi notare che hanno tutti i file commentati, e con una testata con la descrizione del modulo e altri riferimenti, così come ti ho indicato nella precedente...
10) come sopra, la testata deve essere interna la codice, primo per evitare il prolificare di file inutili, secondo per semplificare la vita a chi ci lavora, in quanto ha immediatamente tutto sott'occhio. Terzo, se perdiamo il file descrittivo, non abbiamo altro che descriva il codice...
11) credo non si possa fare con gli strumenti a disposizione, ma può essermi sfuggito... Il nome non viene assegnato dal repository ma da chi crea il file, e quindi deve deciderlo il programmatore. La stessa cosa accade anche in tutti gli altri ambienti di lavoro, in cui abbiamo più persone che contribuiscono allo sviluppo del progetto.

Citazione
per il resto va bene....
ambè...  :D

Consideriamo il fatto che siamo in periodo di ferie e molti non si collegano al sito. Io pesno sia corretto attendere un pochino, per permettere ad altri di aggiungere i propri suggerimenti e  idee...

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #61 il: 07 Agosto 2013, 22:36:44 »
2) io avevo pensato ad un multilinguaggio....
5) ci accordiamo discutiamo un pò....
6) ogni revisione deve essere stabile....
oppure un sistema di versioni alpha e beta un pò complesso...
9) il file era per sapere in anticipo cosa contiene il determinato file...
11) vedremo.....

grande ;D ;D ;D
;D

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #62 il: 08 Agosto 2013, 00:58:55 »
2) come detto, pensare ad un multilinguaggio porta a delle difficoltà non indifferenti, molto di più che nella 6)
5) ovviamente...  :D
6) non si può prevedere revisioni stabili in un ambiente cui tutti vanno a metterci dentro qualcosa. Tu pensa ad una situazione come questa: ci lavoro la sera, metto le modifiche nel repository per non rischiare di perdere il lavoro o perchè altri devono continuare a metterci le mani, perchè le modifiche non sono ancora terminate. In questa semplice e comune situazione hai uno stato inconsistente della libreria, o di un set di moduli (magari quella modificata è legata ad altre...), che porta il progetto ad una versione incompleta, quindi non completamente utilizzabile. In casi come questo, ci si riunisce e si prende una decisione, si testa lo stato corrente del progetto, si verifica se sia completo, dopodiche si congela e si trasforma in una nuova release. Quest viene semplicemente fatto, creando una istantanea del trunk, e l si deposita nel branches, dentro una cartella identificata dalla versione (es. clib-0.0.1).
9) che sia presente un file con l'elenco delle funzionalità di ogni singola libreria è chiaro, ed è pure utile come documentazione a corredo. Quello che indendevo io era di documentare il codice sorgente, commentando la classe/modulo, le sue funzioni e metodi, le proprietà e le variabili statiche o globali, ma anche descrivere in qualche modo particolari pezzi di codice che hanno specifiche particolaritaà, e di documentare anche cosa fà una funzione/metodo, cosa riceve in input e cosa ritorna invece in output. Anche per il discorso di come và scritto il codice, cercando di ridurre il più possibile ridondanze, codice inutile o scritto troppo male o caotico. Questo per dare la possibilità ad altri di poterlo leggere con poche difficoltà, e poterlo manutenere in modo semplice.
11) dando un'occhiata al sito, non ho notato alcuna funzionalità utile allo scopo. Pensandoci meglio, la cosa sarebbe alquanto deleteria se fatta in modo automatico. La nomenclatura delle librerie e delle classi deve essere fatta a mano, cercando di non pestare i piedi alle altre, ma deve anche essere fatta con un certo criterio, nel senso che una classe che magari gestisce la produzione di stampe pdf non può chiamarsi MD9327, che non farrebe capire nulla di quello che è che cosa faccia, e sarebbe pure difficilmente memorizzabile (non è parlante!)... Continuando con l'esempio sopra, io posso creare una classe PdfWriter, in quanto è una classe che tratta il formato PDF ed ha la funzione di scrivere pdf; nel caso di voglia scrivere una classe di lettura, è ovvio che non posso utilizzare il nome Writer, bensì può andare bene il Reader, sempre prefissato da Pdf. Se creo una classe che utilizza PdfWriter, che abbia la funzionalità di gestire la creazione di file Pdf, posso pensare di chiamarla PdfFileWriter (o similari). Allo stesso tempo se creo una classe che gestisce flussi di rete, non credo si possa nominare anch'essa PdfWriter, in quanto non c'entra nulla con le sue caratteristiche. E via dicendo...

In +:
a) se possibile, le classi dovrebbero essere il più elementari possibili, in modo da facilitarne il riutilizzo in altre librerie. Il costruire classi troppo corpose e complesse, ad eccezione di casi speciali in cui non se ne può fare a meno, non fà parte di una buona programmazione. Io stesso ho costruito alcuni oggetti molto complessi, ma ho cercato, nei limiti del possibile, di spacchettare le funzionallità in elementi adattabili e utilizzabile per situazioni diverse. La cosa è resa molto complicata con gambas, e questo l'ho riscontrato sulla mia pelle, ma mi ha anche permesso di sviscerare molte delle possibilità fornite con questo linguaggio. Ha dei limiti, ma ha anche molte possibilità. Molti qui nel forum hanno sudato più di sette camicie per risolvere i problemi che incontravano, mano mano che acquisivano esperienza con questo linguaggio. ALcuni risolvendolo con logiche alquanto discutibili, altri non conoscendo certe peculiaritaà hanno percorso strade contorte, altri hanno risolto brillantemente. Alla fine, lo scambio di informazioni ha permesso a molti di correggere alcune delle lacune.
b) questa non è una critica, ma riporta al discorso precedente: ho letto molto del codice scritto e postato qui nel forum, e ho notato che il programmatore inesperto tende facilmente a evitare o prendere sottogamba il discorso di documentare il proprio codice, pensando che sicuramente nessun'altro ci vada a dare un'occhiata. Sò bene che la cosa è fastidiosa, noiosa, e a volte pure fuorviante, in quanto ritarda la parte che più ci piace fare, ovvero scrivere codice. Poi, però, ci piace far vedere il nostro lavoro, in particolare perchè siamo in ambiente a sorgente aperto, far sapere che e come abbiamo risolto le cose e che soluzioni abbiamo intrapreso. Ma una volta pubblicato il codice viene letto, e qui ci si scontra con la visione di altre persone, che spesso discorda con la nostra (è normale, altrimenti non avremmo partiti politici o religioni...). Far capire cosa abbiamo scritto, solo leggendo il codice, spesso e volentieri è veramente complicato, e spesso anche spiegandolo a voce non si riesce a far capire... funziona! ma come? ma perchè hai usato quella variabile, da dove è chiamata quella funzione, e cosa fà quell'oggetto, cosa contiene quella costante? Spesso il codice non è chiaro e non spiega a colpo d'occhio cosa deve fare. In questi casi già una riga di spiegazione dà una piccola indicazione, il nome di una variabile dà un'idea di cosa contiene, una piccola nota di riferimento a lato o sopra la riga dà un'indicazione migliore di cosa deve fare...

Insomma, io sono un programmatore da svariato numero di anni, e di codice ne ho visto e scritto molto, e di situazioni come quelle sopra descritte me ne capitano ancora, anzi specialmente, oggi. E sò bene le difficoltà che poi devo superare. In particolare quando si lavora in ambienti eterogenei e con molte persone con cui scambiare informazioni, e spesso, anzi quasi sempre, con logiche completamente diverse dalle mie. Nonostante questo continuo anche io a sbagliare, ma sono sempre tendente al miglioramento, e sò bene che chi parte bene è già avvantaggiato, per questo motivo ho fatto tutti quei discorsi sul pianificare bene le cose prima di intraprendere qualsiasi attività.

Domanda: perchè l'hai chiamata "Clib" e non "GLib" (con la G di Genova) ?

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #63 il: 08 Agosto 2013, 13:51:18 »
2) fa niente... per ora va con gambas
5) skipe?
6) ogni revisione va testata percontollare se da sola funziona e soprattutto nell'inzieme
comunque il fatto di congelarla potrebbe essere una soluzione rapida e indolore....
9)dicevamo la stessa cosa in modi leggermente diversi... :D
11) io intendevo con un programma esterno....per avere l'elenco sia in cima all'albero (cartella madre) sia in tutte le varie sottocartelle, argomenti, funzioni specifice....
cioè
abbiamo 10 librerie
in /gb.clib: 4 cartelle + l'elenco (solo nomi, indirizzo e cosa serve +-)
in /gb.clib/audio: 2 cartelle + l'elenco un pò più dettagliato
in /gb.clib/audio/convertitori: 1 cartella etc...
in /gb.clib/audio/convertitori/da_waw_a_mp3.tar.gz: la libreria in se
in /gb.clib/audio/convertitori/da_waw_a_mp3.txt: la spiegazione della libreria
oppure
in /gb.clib/audio/convertitori/da_waw_a_mp3/da_waw_a_mp3.tar.gz: la libreria in se
in /gb.clib/audio/convertitori/da_waw_a_mp3/da_waw_a_mp3.txt: la spiegazione della libreria
ancora meglio....

per i nomi ci si deve accordare un pò....

a) certamente però... (non so se si può fare)
se un modulo(lib1) usa una classe(lib2) di dovrebbe fare un sistema di puntamento che invece dei soliti messaggi di errore dia "la libreria lib2 non è stata trovata vuoi scaricarla quì?" o cose del genere che però contengano tutte il link diretto alla libreria

oppure che aprono il broser nella cartella dove sta la libreria lasciando all'utente la possibilità di metterla dove vuole

oppure ancora un sistema che cekka se c'è sul computer e la inserisce in automatico dove serve (copia incolla) e se non è presente la scarica

risposta... suona malaccio gb.glib....
bhò si può anche cambiare...

poi un pò lo scheletro....

/branches: versioni stabili?? ogni 10 librerie inserite??
/tags: a cosa serve??
/trunk: lavoro in corso d'opera?

detto questo si potrebbe fare un piccola guida con la varie regole per chi ci capita per caso...

l'icona di clib?
descrizione?
senza farli passare per il forum inseriscili direttamente tra i metadata....
;D

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #64 il: 08 Agosto 2013, 18:16:15 »
ok ok
Citazione


    *

      Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bugfixes, and so on.

      Sviluppatori fanno commit di tutto lavoro nuovo nel tronco. Giorno dopo giorno modifiche sono pubblicate nel /trunk: nuove capacità, fix dei bug e così via.
    *

      The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), then /trunk might be copied to /branches/1.0.

      Il tronco è copiato nel ramo «rilascio». Quando il team pensa che il software è pronto per rilascio (diciamo, una vers. 1.0), il /trunk può essere copiato su /branches/1.0.
    *

      Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is “frozen” for final testing right before a release.

      I team continuarono lavorare in parallelo. Un team comincia rigorosi test del ramo rilascio, mentre altro team continua nuovo lavoro (diciamo per la versione 2.0) su /trunk. Quando si scoprono i bug in entrambi locazioni, correzioni sono portate avanti e dietro secondo la necessità. Ad un certo punto, comunque, anche questo processo si ferma. Il ramo è «congelato» per test finale subito prima del rilascio.
    *

      The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers.

      Il ramo è targato e rilasciato. Quando i test sono completati, /branches/1.0 è copiato su /tags/1.0.0 come instantanea di riferimento. Ramo targato è impachettato e rilasciato ai clienti.
    *

      The branch is maintained over time. While work continues on /trunk for version 2.0, bugfixes continue to be ported from /trunk to /branches/1.0. When enough bugfixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.

      Il ramo è mantenuto durante il tempo. Mentre lavoro continua su /trunk per la versione 2.0, i bugfix continuano ad essere portati da /trunk a /branches/1.0. Quando si accumulano abbastanza correzioni, i capi possono decidere di rilasciare vers. 1.0.1: /branches/1.0 è copiato su /tags/1.0.1, la targa è impachettata e rilasciata.

funziona cosi vero....
;D

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #65 il: 09 Agosto 2013, 22:46:33 »
mi sto leggendo svnbook...
ora sto vedendo il capitolo degli admin (in inglese) ma credo che per le impostazioni di base mi servirà una manina.... (da mdxxxx (9327...?) o qualcuno che comunque sappia quello che fa....)
 ;D
ci si rivede domani pomeriggio!
 ;D
;D

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #66 il: 12 Agosto 2013, 17:29:42 »
mi sto leggendo svnbook...
ora sto vedendo il capitolo degli admin (in inglese) ma credo che per le impostazioni di base mi servirà una manina.... (da mdxxxx (9327...?) o qualcuno che comunque sappia quello che fa....)
 ;D
ci si rivede domani pomeriggio!
 ;D
Dato che il repository è gestito da un ISP esterno, per la parte admin c'è tutto l'occorrente per controllare il repository, più altre cosucce simpatiche.
Se invece vuoi studiarti quella parte per svn, allora penso ti convenga provarlo sul campo, installando il pacchetto svn e provare...  :D

Per quanto riguarda invece le normali operazioni di inserimento e aggiornamento, i comandi, come detto, sono semplici e molto pochi. Questo, a meno che non vi sia la necessità di effettuare operazioni più articolate...
Il tutto, su sf.net si può fare sia attraverso il browser e la sua interfaccia dedicata, sia a riga di comando. Le spiegazioni di come si usa sono già indicate sul sito.

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #67 il: 12 Agosto 2013, 22:34:33 »
bene allora....

si può procedere con qualche prova di inserimento e standardizzazione
 :ciao:
;D

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #68 il: 13 Agosto 2013, 17:06:47 »
Per "standardizzazione" intendo mettere nero su bianco alcune regole, almeno qui sul forum, così possono contribuire tutti alla stesura...

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #69 il: 13 Agosto 2013, 17:09:51 »
si anche....
;D

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #70 il: 13 Agosto 2013, 17:18:44 »
Soprattutto, penso...

Credo sia il caso di fare una sorta di documento comune, che si depositerà anche nel repository a disposizione di tutti.
Chiunque voglia partecipare, deve eseguire le cose secondo lo standard definito nel documento.

O sbaglio?

Se non facciamo così, credo che il progetto diverrà presto un guazzabuglio di codice, difficilmente manutenibile...

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #71 il: 13 Agosto 2013, 17:26:59 »
si si non sbagli per nulla...
comunque le basi sono già +- stese sul forum da me e da te....
ci sarebbe da riprendere il tutto e inserirlo in un file....
;D

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #72 il: 22 Agosto 2013, 22:28:08 »
Si, infatti, altrimenti si perde il filo.

Ad ogni modo ho spostato questa discussione in testa, così da evidenziarla.

Inoltre, sul repository su sourceforge, oltre a creare le tre cartelle di cui avevo parlato nella discussione, ho aggiunto una branch, identificata dal nome "1.0", che conterrà i sorgenti dello sviluppo per le tutte le versioni dalla 1.0.0 fino alla 1.0.999 e via dicendo. Quando si deciderà di passare ad una release superiore, ad esempio la 1.1.0, si creerà un'altra branch targata "1.1", e così via.

In parole povere, l'idea è questa:

1) la cartella branches, conterrà i sorgenti dello sviluppo continuo di un range di sotto versioni
2) una volta deciso che si è raggiunto l'ok dei sorgenti, si decide di crearne una release definitiva pubblicabile (es. 1.0.0, 1.0.1 e così via). Lo stesso vale sulle versioni successive (es. 1.1.0, 1.1.1, ...) (es. 2.0.0, 2.0.1, ...).
3) la release definitiva viene congelata, facendo una copia nella cartella trunk, e soto un'ulteriore cartella nominata come la versione (es. trunk/1.0.0).
4) per utilizzare una release specifica, quindi facendo un download per i nostri programmi, basta accedere al repository, posizionandosi nella cartella trunk/<release> che ci serve. Questo permette a chiunque di usare la release desiderata, cosa auspicabile se si dispone di versioni di gambas diverse, che potrebbero portare ad alcune incompatibilità.
5) lo sviluppo comunque continua sempre, tocca solo stare attenti su quale branch andiamo ad operare.
6) per il momento la cartella trunk non verrà usata.
7) nella rispettiva cartella branch andremo a creare un'ulteriore cartella, che identificherà la singola libreria. In questo modo, chi opera su quella libreria non và ad interferire sulle altre. Oltre a questo, la logica ci permette di separare in gruppi le varie librerie in base alle loro funzionalità (es. clib.network, clib.xml, clib.database, clib.desktop, ...)

Se vai sul repository, vedrai che per ogni cartella viene riportato il comando utile per crearsi la propria copia locale:
Codice: [Seleziona]
svn checkout --username=<utente> svn+ssh://<utente>@svn.code.sf.net/p/the-big-clib/code-0/ the-big-clib-code-0
E' ovvio che il comando indicato serve solo a chi è registrato al repository della libreria clib, e perchè deve scaricarsi i sorgenti per poterli modificare e aggiornare a sua volta il repository.

Tanto per spiegare cosa significa la riga di comando:
svn: il comando per gestire subversion
checkout: il parametro che indorma svn di fare lo scaricamento dei sorgenti in una cartella locale (nel proprio pc)
--username: identifica l'utente che accede al repository. In questo caso è necessario solo perchè come amministratore, o utente registrato alla libreria clib, ho i diritti di lettura/scrittura.
protocollo://utente@url: accede alla cartella virtuale del repository (così come la vedi su sf.net. E' sottinteso che il comando è impostato per scaricare completamente tutta la struttura della libreria clib. Nel caso non sia necessario, si può delimitare il download solo a una certa branch/versione, magari perchè si vuole lavorare esclusivamente su quella. La cosa non è auspicabile, in quanto è possibile che il nostro codice vada ad agganciarsi ad altre funzioni contenute in altre librerie.
ultimo parametro: in realtà questo è facoltativo, e indica a svn di creare la copia locale nella cartella indicata (the-big-clib-code-0), che verrà creata automaticamente sotto la directory cui si correntemente posizionati (es. se si è in /home/utente, la nuova cartella verrà creata sotto questa: /home/utente/the-big-clib-code-0).

Una volta scaricata la nostra copia locale, possiamo aprire il nostro gambas e andare ad operare sul codice. Terminate le modifiche, o anche fatte solo in parte, si può decidere di aggiornare il repository con le nostre modifiche. In pratica, da ora in poi, i comandi che verranno utilizzati sono pochissimi:
Codice: [Seleziona]
svn update
verifica le differenze tra la nostra copia e il repository e, nel caso, aggiorna la nostra copia con le nuove modifiche effettuate da altri programmatori.

Codice: [Seleziona]
svn status
visualizza lo stato dei file, se aggiunti, modificati, o altro

Codice: [Seleziona]
svn commit -m "sommario delle modifiche"
il parametro -m è facoltativo, ma è utilissimo per commentare gli aggiornamenti effettuati, e quindi facilità il compito anche agli altri programmatori.

Per chi, invece, vorrà scaricarsi una delle versioni pubblicate e congelate, potrà accedere direttamente nella cartella trunk/<release>, scaricandosi i sorgenti (che nessuno poi toccherà in quanto congelati).

Un'altra possibilità è quella di fornire le versioni in pacchetti, anche solo contenuti in file compressi. In questo caso è necessario che un amministratore costruisca il pacchetto e lo scarichi sempre su sf.net (ci sono apposite procedure per farlo, anche piuttosto semplici). Questo ci permette di pubblicare direttamente i sorgenti in un unico file (può anche essere un rpm, ad esempio). Questo file verrà visualizzato nel sommario di sourceforge, e chiunque potrà scaricarlo direttamente dal sito con un semplice click.


Spero che quello che ho scritto sia esauriente, ad ogni modo se qualcuno ha dei dubbi o quesiti da porgere, sono qui, nel limite delle mie possibilità e conoscenze.

Offline simo97

  • Gran Maestro dei Gamberi
  • *****
  • Post: 501
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #73 il: 26 Agosto 2013, 12:09:24 »
bene bene!!!!

si potrebbe già cominciare....

oggi pom comincio a riassumere tutto in un file.txt chiamato..... :-\

e se finisco si rivede quello che ho scritto e si basano le regole principali
poi il file verrà piano piano adattato.....


Ad ogni modo ho spostato questa discussione in testa, così da evidenziarla.
8)
;D

Offline md9327

  • Moderatore
  • Senatore Gambero
  • *****
  • Post: 2.840
    • Mostra profilo
Re: Idea su una libreria comune e condivisa
« Risposta #74 il: 26 Agosto 2013, 12:42:34 »
 :ok: