Just another blog

Tag: python

  • Project Euler, la nuova droga

    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:

    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

    [tags]projecteuler, python, ottimizzaizone, algoritmi[/tags]

  • Quando Subversion incontra lo sviluppo web

    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).

    (altro…)

  • Python 2.5

    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)

    Icona sorgente 2.4 Icona binario 2.4

    Mie icone (sorgente/binario)

    Mia icona sorgente Mia Icona binario

    Icone 2.5 (sorgente/binario)

    Icona sorgente 2.5 Icona binario 2.5

    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

    [tags]python, python2.5, icone[/tags]

  • Giocando con Subversion

    Ieri sera ho giocato un po’ con Subversion, cercavo la possibilita’ di effettuare un post sul blog in seguito ad un commit. Conoscevo la presenza dei famosi post-commit hooks, ma quelli presenti erano relativi all’invio di una mail. Ho rispolverato il mio Python, e ho scritto questo script che, tramite l’uso della libreria xmlrpclib, contatta il servizio XML-RPC interno a WordPress, e provvede alla creazione di un nuovo post contenente i dati relativi al messaggio del commit, e l’elenco dei files modificati (questi ultimi due dati mi arrivano tramite l’invocazione del comando svnlook).
    Lo script e’ veramente semplice, e molto customizzabile, spero possa essere un buono spunto per qualcuno.

    Ah, ne ho parlato anche nell’ user group del Google Project Hosting, spero che mi ascoltino…

    Ecco il codice

    #!/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))

    Alla prox

    [tags]subversion, python, XML-RPC, post-commit hooks, wordpress[/tags]

  • Debug di uno script con due led…

    … 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