Collaborate allo sviluppo FidoCadJ!

[IsidoroKZ]

Pensiero peregrino fuori thread, solo un rappel a DarwinNE.

Nei file su sourceforge metti nell'"about" diFidocadJ il puntatore al nuovo sito per scaricare aggiornameti e nuove versioni.

[DarwinNE]

Nei file su sourceforge metti nell'"about" diFidocadJ il puntatore al nuovo sito per scaricare aggiornameti e nuove versioni.

Buona idea Apro una Issue, sto lavorando alla versione 0.24.6 ma mi sa che se ne parlerà ad aprile 2016, se non mi annoto quelle cose da qualche parte, finirò per dimenticarmene.

Per quanto riguarda l'idea di Stemby, io mi sono limitato a rendere FidoCadJ abbastanza flessibile da fare le esportazioni da terminale via linea di comando, il resto l'ha fatto webmaster.
Per vedere com'è venuto fuori il tutto, guarda questo (le prime pagine, almeno): viewtopic.php?t=18347

C'è anche gente in gamba su Matematicamente che ha lavorato sulla questione. Io sono assorbito dal lavoro sul programma, ci vorrebbe qualcuno che prenda a cuore la faccenda e si attivi (per esempio mettendo in piedi un progetto su GitHub)

[Stemby]

Alcune cosucce:

1) Riguardo la revisione del manuale, mi sa che mi butterò in qualcosa di un pelo più radicale (ci sono alcune cose che non mi piacciono); ci vorrà però qualche giorno, probabilmente. Pull request in arrivo, in ogni caso.

2) Sto leggendo con attenzione tutta l'immensa discussione linkata nel messaggio qui sopra: interessantissima. Credo che l'integrazione con MediaWiki non sia niente di particolarmente difficile; proverò a fare un tentativo (vi tengo aggiornati).

3) Notavo nei sorgenti che i permessi sono impostati apparentemente a caso. Ad esempio nella directory icons tutti i file tranne 3 hanno permessi 755 (esecuzione per tutti), mentre 2 immagini e un file di testo (a mio avviso correttamente) hanno permessi 644 (lettura per tutti e scrittura per il proprietario). C'è una logica dietro?

[DarwinNE]

1) Riguardo la revisione del manuale, mi sa che mi butterò in qualcosa di un pelo più radicale (ci sono alcune cose che non mi piacciono); ci vorrà però qualche giorno, probabilmente. Pull request in arrivo, in ogni caso.

2) Sto leggendo con attenzione tutta l'immensa discussione linkata nel messaggio qui sopra: interessantissima. Credo che l'integrazione con MediaWiki non sia niente di particolarmente difficile; proverò a fare un tentativo (vi tengo aggiornati).

3) Notavo nei sorgenti che i permessi sono impostati apparentemente a caso. Ad esempio nella directory icons tutti i file tranne 3 hanno permessi 755 (esecuzione per tutti), mentre 2 immagini e un file di testo (a mio avviso correttamente) hanno permessi 644 (lettura per tutti e scrittura per il proprietario). C'è una logica dietro?

No, non c'è una logica dietro. Io non sono su Linux, ma lavoro su un sistema in cui i permessi esistono e sono presi in considerazione. Non mi sono mai messo a studiare la questione, probabilmente è il risultato di un po' di manipolazioni qua e là nell'arco di tanti anni, forse anche qualche passaggio in sistemi Windows (ma per quello non è colpa mia ).

Nelle scorse settimane ho intrapreso una campagna abbastanza radicale di revisione del codice, ogni contributo per renderlo ancora più chiaro e corretto è quanto mai benvenuto. Per i file generici, mi pare che i permessi 644 siano quelli più indicati. Puoi aprire una nuova Issue e se hai tempo e voglia magari lavorare sul problema?

Ah, nel caso tu voglia fare pull request, tieni conto che in questo momento sono di sviluppo e faccio alcuni commit al giorno: non dimenticare di ripartire su una versione ragionevolmente recente del repository ogni volta che vuoi fare una modifica, soprattutto sui sorgenti in Java.

[Stemby]

Per vedere com'è venuto fuori il tutto, guarda questo (le prime pagine, almeno): viewtopic.php?t=18347

Finito di leggere tutto or ora. Bestiale.



Bon, mi manca ancora un po' di roba da leggermi attentamente (README e manuale, tanto per iniziare) e poi posso dire di saperne abbastanza per non fare troppi danni.

A presto!

[DarwinNE]

Finito di leggere tutto or ora. Bestiale.

Che coraggio!!!

Per contribuire al codice, una parte importante del README è il paragrafo 3.4:

Codice: Seleziona tutto

3.4 Coding conventions
----------------------

The following coding conventions have been applied for the FidoCadJ source
code:

- the code should be compatible with Java 1.7
* indent properly, using 4 spaces
* no tabulation character allowed in sources
* no trailing spaces
- blocks delimited by curly braces are indented as follows:
~~~~~~~~~
    for(i=0; i<10; ++i) {   // Curly brace here
        // indented code (4 spaces)
        System.out.println("I counted up to "+i);
    }   // close brace here at the same level of the 'for'
~~~~~~~~~
* methods are indented as follows:
~~~~~~~~~
    void dummy(int i, int j)
    {   // put the starting brace here
        System.out.println("Indent code");
    }   // put the closing brace here
~~~~~~~~~
* classes and interfaces are indented as follows:
~~~~~~~~~
   class Dummy
   {            // Curly brace here.
      // the rest of the class.
   }
~~~~~~~~~
* switches are indented as follows:
~~~~~~~~~
    int dummy(int i)
    {
        int j;
        switch(i) {
            case 1:
                j=3;
                break;
            case 2:
                j=2;
                break;
            default:
                j=0
        }
        return j;
    }
~~~~~~~~~
* if an "if" condition spans over multiple lines, put the brace on the
  following line
* the class names always start with a capital letter
* variables never start with a capital letter
* methods never start with a capital letter
* public classes must be documented with Javadoc syntax
* public methods must be documented with Javadoc syntax
* no lines longer than 80 characters
- employing "_" in names of types or variables is deprecated
- commits should not break the build
- each commit *MUST* include a log
- predilect simplicity to unnecessary complication
- predilect quality to quantity
- discuss what you want to do BEFORE start coding
- documentation is important. Try to improve it and keep it up-to-date

A checkstyle rule sets (called rules.xml) is being progressively employed so
that those rules will be automatically checked. Points for which a rule has
been activated have been marked with a "*" instead of a "-" in the previous
list.

Be sure to run checklist with rules.xml before sending a pull request!


Un punto importante è "discuss what you want to do BEFORE start coding"

A presto e complimenti ancora

[Stemby]

Un punto importante è "discuss what you want to do BEFORE start coding"

Sì, effettivamente sono arrivato a leggere quel punto ormai troppo tardi...

Mi ero già messo a lavorare proprio sul README; si tratta di un lavoro di pulizia abbastanza profondo e per il quale credo non troverai niente da obiettare. L'unica cosa "grossa" che ho cambiato è il fatto di aver adeguato la sintassi a Markdown (era già molto simile, comunque), in modo tale da far visualizzare il file al meglio su GitHub. Se questa scelta ti disturbasse per qualsiasi ragione, fammelo sapere, che evito così di buttarci ulteriore tempo.

Grazie!

[DarwinNE]

Ciao,
sì il README merita una rilettura generale, il problema è che io mi ritrovo ormai a modificarlo "a pezzi" perdendo un po' la visione d'insieme. Ortografia e grammatica sono sicuramente da migliorare, come hai visto sicuramente ci sono delle informazioni obsolete in certi punti etc.
Sono molto contento che tu lo stia rileggendo ed abbia dei contributi da proporre

Per quanto riguarda il passaggio a Markdown, mi sono posto effettivamente il problema qualche tempo fa.
Il vantaggio sarebbe l'avere una resa nettamente migliore rispetto al solo testo, lo svantaggio è che si aggiunge uno straterello in più rispetto al solo testo. Mi pare che nel 2015 lo straterello con i 4 comandi di markdown in più sia ampiamente sopportabile, quindi direi che è una buona idea (ma resta su cose semplici, per quanto possibile).

Per quanto riguarda le pull request, ti consiglierei di seguire la procedura seguente:
- apri una issue su GitHub descrivendo in breve cosa desideri fare e cosa desideri cambiare
- ne discutiamo lì sopra per raggiungere un consenso, fra noi e magari con altri sviluppatori che si possono eventualmente aggiungere
- se ti va di occuparti di un problema, lo dici (di modo che altri non lavorino sulla stessa cosa nello stesso momento)
- modifichi il codice
- vai di pull request
- se tutto va bene, si chiude la pull request

Per il momento, fai pull request abbastanza piccole, di modo che possa fare in fretta una review dei cambiamenti (GitHub è spettacolare in quello!!!).

P.S. per esempio, di questa https://github.com/DarwinNE/FidoCadJ/issues/54 te ne occupi tu o vuoi che lo faccia io? Se lo faccio io, ci vorranno ancora un giorno o due, quindi fammi sapere in tempo per evitare conflitti.

[Stemby]

Ok, tutto chiaro e assolutamente condivisibile.

Ciao,
P.S. per esempio, di questa https://github.com/DarwinNE/FidoCadJ/issues/54 te ne occupi tu o vuoi che lo faccia io?

Meglio se lo fai tu, ma solo dopo che abbia finito di lavorare sul README.

Grazie!

[DarwinNE]

Ok, quindi aspetto

Se sei sempre in vena di leggere, ci sarebbero anche le vecchie discussioni sul forum di Sourceforge.
Certe sono molto tecniche, come questa:

https://sourceforge.net/p/fidocadj/disc ... /9ed02ccb/

Kohta ha scovato e corretto un bug gravissimo in una vecchia versione, credo la 0.24.2, che in certi casi tendeva a riempire il disco di file temporanei impedendo la partenza del programma. Poi la discussione è partita sul refactoring di codice (scritto fra l'altro da phylum) e su miglioramenti in generale del tutto.

Oppure questa, relativa al porting verso Android, con i nostri DanteCpp e cronos80:

https://sourceforge.net/p/fidocadj/disc ... fb/?page=0

Anche qui su EY si è discusso di cose che poi non ho avuto più occasione di mantenere, come Java web start:

viewtopic.php?f=4&t=38048