Just another blog » python

Project Euler, la nuova droga

mcalamelli — Thu, 28 May 2009 22:42:26 +0000

Ecco cosa accade quando alla passione per la programmazione si unisce la sfida per trovare una soluzione elettronica a quesiti di matematica.
Accade che non si riesce più a smettere, e si entra nel tunnel del Progetto Eulero, liberamente tradotto in italiano.

Project Euler è un sito, nato nel 2001, il cui obiettivo è quello di proporre questiti matematici (più di 200, 246 per l’esattezza, e il 247imo è schedulato per venerdì 29 maggio 2009 alle 9.00 PM [GMT]) di diversa complessità, da quelli risolvibili con un foglio e una matita a quelli richiedenti un buon linguaggio di programmazione, un programmatore attento e una forte dose di ottimizzazione.

Già, perchè pur non essendoci un limite di tempo per la scrittura del programma, questo ultimo deve essere in grado di trovare la soluzione al problema nel tempo massimo di 60 secondi! Questo vincolo richiede una particolare attenzione nella scrittura dell’algoritmo risolutivo, e spesso ci si rende conto che un approccio brute-force non è quello più efficace.

Ho cominciato a risolvere i quesiti da poco più di una settimana partendo dall’inizio, e ora sono alle prese con il dodicesimo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

The sequence of triangle numbers is generated by adding the natural numbers. So the 7^(th) triangle number would be 1 + 2 + 3 + 4 + 5 + 6 + 7 = 28. The first ten terms would be:

1, 3, 6, 10, 15, 21, 28, 36, 45, 55, ...

Let us list the factors of the first seven triangle numbers:

1: 1
3: 1,3
6: 1,2,3,6
10: 1,2,5,10
15: 1,3,5,15
21: 1,3,7,21
28: 1,2,4,7,14,28

We can see that 28 is the first triangle number to have over five divisors.

What is the value of the first triangle number to have over five hundred divisors?

Come previsto e predetto, l’approccio a forza bruta non sta funzionando bene; considerando i numeri primi, e non i numeri triangolari come richiesto, il calcolo del numero di divisori di 70000000 (settanta milioni), il quale risulta averne 128, di divisori, richiede 56,5″.
Sono troppo vicino ai 60″, e troppo lontano dai 500 divisori richiesti.

A parte il piacere della programmazione e la soddisfazione per la scrittura di un algoritmo particolarmente efficiente, la risoluzione di alcuni problemi mi ha portato a qualche considerazione:

* il linguaggio Python è estremamente facile da utilizzare, e piuttosto efficiente;
* il linguaggio C è stramaledettamente veloce;
* purtroppo è passato troppo tempo dall’ultima volta che ho scritto del codice Assembler (dalle superiori) per paragonarlo al C;
* il decorator memoize è una figata unica, trovo questo approccio semplicemente geniale;

Una ottima fonte di riferimento al progetto è Stacktrace: qui e qui due post molto belli.

Che dire? Se c’è dell’interesse verso la programmazione e la matematica, il progetto è veramente interessante. Una unica annotazione, come tutte le droghe, CREA DIPENDENZA! Programmatore avvisato…

Alla prox

Technorati Tags: projecteuler, python, ottimizzaizone, algoritmi

Quando Subversion incontra lo sviluppo web

mcalamelli — Thu, 29 Nov 2007 17:15:31 +0000

Dopo un lungo periodo di gestazione, finalmente e’ venuto alla luce questo post, che personalmente reputo molto interessante (ma va??).
Come introdotto dal titolo, espongo uno scenario di uso che mostra come poter integrare Subversion con lo sviluppo e il mantenimento della nostra web application. Nel dettaglio, con web application intendo un applicativo PHP installato in diversi server di produzione: quindi, un punto di sviluppo, tanti punti di utilizzo.
Bene, ipotizziamo ora il workflow per l’installazione per un nuovo cliente: connessione remota verso il server, quindi decompressione (se abbiamo una tarball o un archivio compresso) oppure copia (nel caso di singoli files), niente di trascendentale, quindi; il discorso si complica nel caso in cui ci accorgiamo che il nostro prodotto contiene un bug, oppure se abbiamo apportato modifiche interessanti allo stesso, e in questo caso dobbiamo operare a mano nelle n installazioni, con il rischio di sbagliare/dimenticarsi qualcosa.
E’ qui che Subversion viene in nostro aiuto per realizzare una specie di sistema di installazione/aggiornamento automatizzata di tipo “push” (spero che il termine sia giusto).

Prerequisiti:
0) un server con il client Subversion installato ed utilizzabile dall’utente di Apache, nel mio caso www-data;
1) un repository Subversion raggiungibile dal server;
2) un linguaggio di scripting presente nel repository, utilizzabile per scrivere il post-commit hook, nel mio esempio Python;

Semplificazioni:
0) il repository risiede nel mio PC, e ci accedo tramite il protocollo file://;
1) i server remoti, nel dettaglio tre, sono rappresentati da tre diverse directory nella DocumentRoot di Apache;

Ecco una piccola descrizione di cio’ che ho realizzato e di quello che vedrete negli snippets successivi.
Io ho sviluppato una web application general purpose, molto flessibile e adattabile a molti clienti, ed essendo un bravo programmatore utilizzo gia’ subversion per mantenere i miei sorgenti. Aggiungo quindi una specie di installer per l’applicazione, in pratica una pagina PHP che invoca il checkout del progetto dal repository principale.

Ecco il codice dell’installer.

Redirect...

Che cosa succede quando invochiamo l’esecuzione dell’installer (preventivamente copiato nel server)?
Il client svn sl server preleva il progetto dal repository e crea, con i giusti permessi (quelli del webserver), la copia locale dei files.

Cominciamo con gli snippets!

Ecco il contenuto della directory che ospita il progetto iniziale della web application

massi@aspire:~$ cd Projects/svnwebapp/
massi@aspire:~/Projects/svnwebapp$ ls -l
totale 8
-rw-r--r-- 1 massi massi 104 2007-11-11 22:35 index.php
-rw-r--r-- 1 massi massi  30 2007-11-02 06:48 updater.php
massi@aspire:~/Projects/svnwebapp$

Creiamo ora il repository svn

massi@aspire:~$ svnadmin create /home/massi/svn/svnwebapp
massi@aspire:~$

Effettuiamo ora l’import della web application nel repository appena creato

massi@aspire:~$ cd Projects/
massi@aspire:~/Projects$ svn import -m "Import iniziale" svnwebapp file:///home/massi/svn/svnwebapp
Aggiungo       svnwebapp/updater.php
Aggiungo       svnwebapp/index.php
Commit della Revisione 1 eseguito.
massi@aspire:~/Projects$

Ora ci spostiamo nella root del nostro webserver locale, ed eseguiamo il checkout del progetto per continuare a svilupparlo, sotto svn.

massi@aspire:~$ cd /var/www/
massi@aspire:/var/www$ sudo svn co file:///home/massi/svn/svnwebapp
A    svnwebapp/updater.php
A    svnwebapp/index.php
Estratta revisione 1.
massi@aspire:/var/www$

Guardiamo cosa e’ successo in /var/www

massi@aspire:~$ ls /var/www/svnwebapp/
index.php  updater.php
massi@aspire:~$

Bene, la directory e’ stata creata, cosi’ come i files della web application.
Ora eseguiamola!

massi@aspire:~$ lynx --source http://localhost/svnwebapp




Versione PHP installata: 5.2.3-1ubuntu6


massi@aspire:~$

Per curiosita’ diamo una occhiata a questo complicatissimo script (index.php).

Redirect...

Ora che abbiamo testato le funzionalita’ di svn per la gestione “locale” della web application, creiamo i nostri tre server simulati (con gli opportuni permessi), copiamo in ognuno di essi l’installer e lanciamo quest’ultimo per creare le applicazioni.

massi@aspire:~$ cd /var/www
massi@aspire:/var/www$ sudo mkdir fakesrv{1,2,3}
massi@aspire:/var/www$ sudo chown www-data:www-data fakesrv{1,2,3}
massi@aspire:/var/www$ ls
fakesrv1  fakesrv2  fakesrv3  index.html  svnwebapp
massi@aspire:/var/www$ cd
massi@aspire:~$ sudo cp svnwebapp_installer.php /var/www/fakesrv1/
massi@aspire:~$ sudo cp svnwebapp_installer.php /var/www/fakesrv2/
massi@aspire:~$ sudo cp svnwebapp_installer.php /var/www/fakesrv3/
massi@aspire:~$ lynx --source http://localhost/fakesrv1/svnwebapp_installer.php
massi@aspire:~$ lynx --source http://localhost/fakesrv2/svnwebapp_installer.php
massi@aspire:~$ lynx --source http://localhost/fakesrv3/svnwebapp_installer.php

Giusto per scrupolo vediamo cosa e’ successo dentro a fakesrv1.

massi@aspire:/var/www$ ls -lR fakesrv1
fakesrv1:
totale 4
drwxr-xr-x 3 www-data www-data 136 2007-11-26 13:34 svnwebapp
-rw-r--r-- 1 root     root      59 2007-11-26 13:34 svnwebapp_installer.php
fakesrv1/svnwebapp:
totale 8
-rw-r--r-- 1 www-data www-data 169 2007-11-26 13:34 index.php
-rw-r--r-- 1 www-data www-data  30 2007-11-26 13:34 updater.php
massi@aspire:/var/www$

Tramite lynx verifichiamo che tutto funzioni.

massi@aspire:~$ lynx --source http://localhost/fakesrv1/svnwebapp




Versione PHP installata: 5.2.3-1ubuntu6


massi@aspire:~$

Tralascio gli snipper delle verifiche per gli altri due “server”, tutto funziona ovviamente allo stesso modo.
Riassumiamo quello che e’ successo finora: tramite l’installer ho potuto replicare la mia web application nei server dei miei ipotetici tre clienti, attingendo il codice direttamente dal repository SVN, che contiene l’ultima release del progetto.
Ora pero’ mi sono accorto che la mia web application manca di un requisito fondamentale, e cioe’ una stringa di testo con il mio indirizzo email, percio’ sono costretto ad aggiornare le varie installazioni!
Vediamo quindi in che modo il mio sistema di installer diventa comodissimo in caso di aggiornamenti: aggiungiamo un post-commit hook al repository.
Ecco il contenuto della directory del repository.

massi@aspire:~$ ls -l svn/svnwebapp
totale 8
drwxr-xr-x 2 massi massi 128 2007-11-11 23:20 conf
drwxr-xr-x 2 massi massi  48 2007-11-11 23:20 dav
drwxr-sr-x 5 massi massi 256 2007-11-12 00:12 db
-r--r--r-- 1 massi massi   2 2007-11-11 23:20 format
drwxr-xr-x 2 massi massi 392 2007-11-11 23:58 hooks
drwxr-xr-x 2 massi massi 104 2007-11-11 23:20 locks
-rw-r--r-- 1 massi massi 229 2007-11-11 23:20 README.txt

La directory che ci interessa e’, ovviamente, hooks.

massi@aspire:~$ ls -l svn/svnwebapp/hooks/
totale 40
-rwxr-xr-x 1 massi massi  290 2007-11-11 23:58 post-commit
-rw-r--r-- 1 massi massi 1996 2007-11-11 23:20 post-commit.tmpl
-rw-r--r-- 1 massi massi 1673 2007-11-11 23:20 post-lock.tmpl
-rw-r--r-- 1 massi massi 2290 2007-11-11 23:20 post-revprop-change.tmpl
-rw-r--r-- 1 massi massi 1602 2007-11-11 23:20 post-unlock.tmpl
-rw-r--r-- 1 massi massi 2969 2007-11-11 23:20 pre-commit.tmpl
-rw-r--r-- 1 massi massi 2038 2007-11-11 23:20 pre-lock.tmpl
-rw-r--r-- 1 massi massi 2764 2007-11-11 23:20 pre-revprop-change.tmpl
-rw-r--r-- 1 massi massi 1979 2007-11-11 23:20 pre-unlock.tmpl
-rw-r--r-- 1 massi massi 2137 2007-11-11 23:20 start-commit.tmpl
massi@aspire:~$

Come si vede, e’ presente il mio file post-commit , al quale ho dato di permessi di esecuzione.
Vediamone il contenuto.

Redirect...

Come si puo’ vedere, e’ un semplicissimo script Python che viene eseguito ad ogni commit (da qui’ il nome post-commit): il codice mi sembra piuttosto chiaro, data una lista di URL, quelli relativi alle varie installazioni della web application, un ciclo sulla lista effettua il collegamento alla pagina updater.php di ogni installazione.
Il codice dell’updater e’ molto simile a quello dell’installer, addirittura piu’ semplice.

Redirect...

Ok, direi che siamo pronti a testare il tutto. Apriamo il file index.php con il nostro editor preferito, apportiamo la modifica di cui sopra e effettuiamo il commit.

massi@aspire:/var/www/svnwebapp$ sudo vi index.php
massi@aspire:/var/www/svnwebapp$ sudo svn commit -m 'Aggiunto autore'
Trasmetto      index.php
Trasmissione dati .
Commit della Revisione 2 eseguito.
massi@aspire:/var/www/svnwebapp$

Ora la prova del 9, verifichiamo i tre server.

massi@aspire:~$ lynx --source http://localhost/fakesrv1/svnwebapp




Versione PHP installata: 5.2.3-1ubuntu6

---

Autore: Massimiliano Calamelli

Email: mcalamelli@gmail.com

massi@aspire:~$ lynx --source http://localhost/fakesrv2/svnwebapp




Versione PHP installata: 5.2.3-1ubuntu6

---

Autore: Massimiliano Calamelli

Email: mcalamelli@gmail.com

massi@aspire:~$ lynx --source http://localhost/fakesrv3/svnwebapp




Versione PHP installata: 5.2.3-1ubuntu6

---

Autore: Massimiliano Calamelli

Email: mcalamelli@gmail.com

Perfetto, tutto mi sembra ok, direi che il sistema ha funzionato!
Ovviamente sono conscio del fatto che il tutto e’ realizzato in un ambiente molto differente dalla realta’, ma mi sento di poter affermare che con poche modifiche il tutto possa funzionare anche nel mondo reale; alcuni perfezionamenti che mi vengono in mente sono questi:

post-commit hook : l’elenco degli host da aggiornare potrebbe essere letto da un file, e non hard-coded all’interno dello script, in modo da poter escludere piu’ facilmente host che per svariati motivi non devono essere aggiornati. Inoltre un controllo sul risultato della connessione tramite urllib2 sarebbe auspicabile, magari con una notifica via mail dell’insuccesso dell’operazione per il/i determinati hosts;

updater.php : la pagina in questione andrebbe in qualche modo protetta, cosi’ da impedire eventuali chiamate non autorizzate.

Che dire, e’ stato veramente interessante realizzare un sistema del genere, anche se molto semplificato rispetto ad un uso reale, un motivo in piu’ per studiarsi i sistemi di controllo versione: io ho usato SVN come RCS e Python per il post-commit hook, ma nulla vieta di realizzare un sistema simile con CVS e un qualsiasi altro file eseguiibile che si chiami post-commit.
Ogni bravo programmatore dovrebbe SEMPRE usare un sistema di controllo versione.

Grazie a Fullo e Jaures per le preziose verifiche.

Alla prox

Technorati Tags: subversion, php, python, post-commit hooks, web development

Python 2.5

mcalamelli — Tue, 18 Sep 2007 11:54:01 +0000

Dopo aver mosso i primi passi con Maya e 3D Studio, mi e’ tornata la voglia di perdere un po’ di tempo con la grafica 3D.
Essendo il mio tempo libero gia’ ridotto agli sgoccioli, ho preferito lasciare da parte affannose ricerche su Astalavista e eterni download con Emule per utilizzare qualche strumento piu’ open/free, e la mia scelta non poteva che cascare su Blender. Comunque questo non e’ un post su Blender, magari ne faro’ uno se i miei esperimenti porteranno a qualcosa di buono, percio’ passo a Python.
Ho scaricato l’ultima release di Blender, la 2.44, l’installer per Windows (per ora ci smanetto al lavoro nella pausa pranzo, e qui ho Xp), poi l’ho installato ed eseguito; il programma apre una finestra a console, dove finiscono i vari messaggi di esecuzione, e leggendo le varie righe mi accorgo di due cose: 0) e’ stato compilato per usare Python2.5, 1) non trova un interprete Python esterno da usare.
La prima non mi stupisce, indica che Blender e’ bello aggiornato, mentre la seconda mi stupisce un po’, visto che Python ce l’ho bello installato… poi ci penso un attimo e mi rendo conto che 2.5 != 2.4, quindi tutto ok. Il programma parte comunque, visto che ha il motore Python interno, ma potrei avere problemi con script che estendono il core, percio’ provvedo tosto tosto all’installazione della nuova versione.
Tutto procede liscio, alla fine mi ritrovo le due versioni installate, c:\Python2.4 e c:\python2.5, e Blender, ma va!, dice che ha trovato un Python engine. Bene, chiudo Blender e aspetto di trovare un buon tutorial per partire.
Visto che mi rimane un po’ di tempo prima delle 14, ne approfitto per vedere cosa e’ cambiato nel mio sistema, e quindi provo a lanciare un paio dei programmi che ho scritto… e qui’ la prima piacevole sorpresa: finalmente hanno sostituito quelle orrende icone con il serpentello sorridente con qualcosa di piu’ bello, wow! Io da parte mia avevo gia’ provveduto a cio’ con un po’ di lavoro grafico.

Qualche immagine per spiegarmi meglio.

Icone 2.4 (sorgente/binario)

Mie icone (sorgente/binario)

Icone 2.5 (sorgente/binario)

Direi che ora le icone sono guardabili, anche se le mie continuano a piacermi parecchio…
Comunque, venendo al sodo, ho provato ad eseguire alcuni miei script, quelli console-based hanno continuato a funzionare senza problemi, mentre quelli GUI-based (GTK e WX) hanno avuto bisogno della reinstallazione delle librerie per Python2.5
Per ora non ho ancora nessuna linea di codice che utilizzi le nuove features di Python, non appena effettuero’ qualche test anche su questo verrete prontamente aggiornati!

Python rulez!

Alla prox

Technorati Tags: python, python2.5, icone

Giocando con SubversionPlaying with Subversion

mcalamelli — Thu, 26 Jul 2007 14:19:41 +0000

On yesterday evening i played a little with Subversion, I was looking for a way to do a post in my blog after a commit.
I knew that there’s post-commit hooks, but only email-related. So i’ve taken my Python, and i wrote this script that connects to XML-RPC service built-in in WordPress (using xmlrpclib), and provide to create a new post that contains the commit’s message, and a list of affected files (by a call to svnlook).
The script is very easy and customizable, I hope it will be a launch for everyone.

Ah, i talked about it also in Google Project hosting user group, I hope that someone listen to me…

Here’s the code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#!/usr/bin/python

import sys
import xmlrpclib
import os

xmlrpc_url = "http://localhost/wp/xmlrpc.php"
xmlrpc_username = "admin"
xmlrpc_password = "admin"
post_title = "Commit log"

repos = sys.argv[1]
rev = sys.argv[2]

log_message = os.popen('svnlook log ' + repos).read()
affected_files = os.popen('svnlook changed ' + repos).read()

server = xmlrpclib.Server(xmlrpc_url)
server.metaWeblog.newPost(1,xmlrpc_username,xmlrpc_password,{"title":post_title, "description":"Message: " + log_message + "Affetcted files: \n" + affected_files},bool(1))

Stay tuned

Technorati Tags: subversion, python, XML-RPC, post-commit hooks, wordpress

Debug di uno script con due led…

mcalamelli — Fri, 10 Nov 2006 15:10:11 +0000

… ovvero la mia esperienza con il modulo GSM/GPRS EZ10 Terminal QUAD-PY della Telit.
Il modulo e’ un bell’oggetto da un centinaio di Euro, con una porta RS232, 4 linee GPIO configurabili via software e, in questa versione, l’interprete Python (versione 1.5.2+) all’interno.
Il contesto di utilizzo e’ il seguente: una scheda elettronica, preposta all’attivazione o meno di uscite in base all’iterazione con l’utente, ha due ingressi di allarme, ai quali e’ possibile collegare degli attuatori che si attivano in caso di situazioni ritenute di emergenza. Il firmware di gestione della scheda controlla lo stato degli ingressi (ovviamente optoisolati) di allarme, e lo riporta su due delle quattro linee GPIO del modulo Telit.
All’interno del modulo gira il mio script Python, script che viene eseguito ad ogni avvio del modulo stesso. Lo scopo dello script e’ il controllo delle linee GPIO di allarme, in modo da notificare via SMS a due numeri di cellulare gli eventi su queste linee con i messaggi di testo relativi.
La comunicazione tra l’interprete Python e parser dei comandi AT avviene internamente tramite una linea seriale virtuale utilizzabile all’interno dello script tramite le funzioni del modulo MDM, quindi ,tempistiche a parte, e’ come se si parlasse direttamente sulla linea seriale fisica del modulo inviando direttamente i comandi AT. L’interprete mette a disponizione altri due moduli, oltre al builtin, e cioe’ SER per la gestione della seriale fisica e MOD con un paio di funzioni per la gestione dei tempi.
La procedura di inserimento dello script e’ piuttosto macchinosa: bisogna collegarsi via seriale al modulo (ho utilizzato Hyperterminal, e fa veramente pieta’…) impostando il baudrate a 115200, N81 per parita’ e stopbit, e controllo di flusso hardware, poi digitare AT#WSCRIPT=”[nomefile.py]“,[dimensioni in byte del file] , attendere il prompt “>>>”, selezionare il menu “Invia file di testo”, selezionare il file da inviare e attendere la risposta di “OK”, poi abilitare il file .py “uploadato” con il comando AT#ESCRIPT=”[nomefile.py]“, e attendere “OK” per la conferma. Per eseguire lo script sul modulo basta chiudere la comunicazione da Hyperterminal e spegnere e riaccendere il modulo.
E ora cominciano i problemi, almeno nel mio caso…
Ho provato il classico “Hello world!”, e cioe’ in questo caso la stampa della stringa sulla seriale fisica del modulo (ovviamente connessa al pc), ma non ho visto arrivare niente, e mi sono chiesto “Ma lo script e’ partito? Ma ho forse fatto qualche errore di digitazione? COME FACCIO IL DEBUG?”. E il punto e’ proprio questo, il debug dello script. Certo, errori di sintassi li posso escludere facendo leggere lo script da un qualche tool di controllo, ma se per caso (come mi e’ successo…) scrivo MDM.sleep(10), che non esiste, al posto di MOD.sleep(10), come me la sbrigo??
La soluzione che ho utilizzato e’ stata quella di collegare esternamente due led alle porte GPIO rimaste libere per avere un piccolo feedback dallo script, ma vi assicuro che e’ stata veramente dura arrivare alla fine, un minimo di informazioni le potevano mettere, almeno per i traceback generati dal Python!
Comunque alla fine ci sono arrivato, lo script si comporta bene, e i messaggi arrivano che e’ una meraviglia.
Nonostante cio’ pero’ non posso esprimere un parere positivo al 100%, ritengo che questo oggetto possa andare bene per un eventuale sistema di dimostrazione, ma la macchinosita’ di programmazione (del modulo, non del Python) non lo rende l’ideale in produzione: una scheda di gestione con una seriale libera e un microcontrollore adeguato avrebbe compiuto meglio il lavoro.

Alla prox

Nuova patch per Phasis: modulo di configurazione

mcalamelli — Fri, 06 Oct 2006 15:09:48 +0000

Come da oggetto, ecco una nuova patch per Phasis relativa al (mio) modulo di configurazione.
Rispetto alle altre volte ho deciso di scrivere qualche cosa perche’, pur avendo un impatto minimo su una installazione gia’ funzionante, richiede comunque delle modifiche al file di configurazione default.cfg.
Modifiche che comunque si riassumo in una aggiunta di diverse linee di commenti opportunamente formattate, e da qui’ la scarsita’ dell’impatto sul sistema.
Piccola annotazione: la patch sovrascrivera’ il vecchio file di configurazione, percio’ consiglio un backup prima di applicarla.
Il sistema di creazione dei controlli relativi alle opzioni e’ intelligente e completamente realizzato a runtime, a meno dei controlli fondamentali come i panel, i sizer e la struttura base del notebook.
Di seguito un piccolo help per capire come e cosa ho modificato nel file di configurazione.

Vecchio file:

# ------ Impostazioni di rete
[Server]
#Address=0.0.0.0
Port = 0
# ------ Impostazioni di linguaggio
[Language]
# Italiano = IT  ; English = EN ; Spanish = SP
spk = IT

Nuovo file:

# ------ Impostazioni di rete
[Server]
#sectAlias@@Rete
#sectDesc@@Impostazioni relative alla rete
#opt__Port@@Porta@@int@@tc
#Address=0.0.0.0
Port = 0
# ------ Impostazioni di linguaggio
[Language]
#sectAlias@@Lingua
#sectDesc@@Impostazioni relative alla lingua
#opt__spk@@Lingua@@str@@cb@@Italiano:IT%Inglese:EN%Spagnolo:SP
# Italiano = IT  ; English = EN ; Spanish = SP
spk = IT

Le modifiche sono piuttosto chiare, ed effettivamente si limitano a dei commenti (particolari).
I miei commenti sono di due tipi, uno relativo alla sezione (Server e Language nell’esempio) e uno relativo alle opzioni (Port e spk).
I commenti di sezione cominciano con “sect”, e proseguono o con “Alias” per una stringa piu’ user-friendly rispetto al nome della sezione, oppure con “Desc” per una descrizione stringata di cio’ che riguarda la sezione. Il separatore, chiaramente, e’ una doppia @.
I commenti di opzione sono un po’ piu’ complessi, dovendo contenere informazioni differenti: vediamo un po’ di spiegare la formattazione.
Un template di struttura puo’ essere il seguente:

opt__nomeopzione@@alias@@dato@@controllo[@@key:val%key:val]

Il campo opt__nomeopzione si spiega da se, come del resto il campo alias, mentre un discorso a parte va fatto per gli altri campi.
Il campo “dato” indica il tipo di dato che l’opzione puo’ contenere e che viene validato in fase di modifica del campo stesso, e puo’ essere “int” per un intero, “str” per una stringa o “bool” per uno 0 o un 1.
Il campo “controllo” indica il tipo di controllo che rappresenta l’opzione, e puo’ essere “tc” per un TextControl, “ml” per un TextControl multilinea, “rb” per un RadioBox e “cb” per un ComboBox.
I campi indicati fino a qui (opt__nomeopzione, alias, dato, controllo) sono necessari, mentre l’ultimo campo, indicato tra parentesi quadre nell’esempio di struttura e’ richiesto solo se il tipo di controllo e’ “cb”, e contiene una serie di coppie chiave/valore separate da il carattere %, che andranno a riempire in ComboBox.

E questo e’ quanto, in caso di altre delucidazioni contattatemi pure. Per chiudere, ribadisco che il modulo, per funzionare, ha bisogno di un file di configurazione di nuovo tipo, e che applicando la patch il vecchio file verra’ sovrascritto, percio’ fate un backup del vecchio prima di applicare la patch, se avete apportato modifiche.

Alla prox