Posts tagged ‘linux’

27 agosto 2011

Calise 0.0.5

Dopo una lunga parentesi pseudo-vacanziera a Jesolo lido intrisa di studio e attività in genere (molto diversa dalla classica vacanza marina sotto l’ombrellone per capirci), scrivo qualche riga sulla nuova versione di Calise (0.0.5) che porta con se qualche cambiamento soprattutto in termini di stabilità.
Per spiegazioni squisitamente tecniche rimando al blog di Calise in inglese all’indirizzo: http://sourceforge.net/apps/wordpress/calise/.

In generale ho eccettato degli errori (in particolare un blocco che si imponeva arbitrariamente qualche volta ad opera della libreria camera di pygame) e stabilizzato/pulito il codice con cambiamenti a volte anche radicali.

Procederò ora verso la versione 0.0.6 dove faciliterò e migliorerò la velocità con cui si calibra nel caso in cui la videocamera usata sia già presente in uno dei profili utente.

L’obiettivo più in là poi è sempre quello: un ambiente GUI confortevole, da cui accedere a tutte le opzioni del programma (calibrazione compresa).
Tuttora sono indeciso fra una gui in Qt ed una in Wx…

Nel frattempo mi concentro per bene nello studio.

Annunci
18 luglio 2011

Calise 0.0.4

Non ancora pubblicato su Sourceforge per motivi che spiegherò fra poco, è ora disponibile la versione 0.0.4 di Calise.
Lo potete reperire temporaneamente qui: http://smilzoboboz.altervista.org/tmp/calise-0.0.4.tar.gz
Per la verifica del checksum:

MD5: 267a33b907ed433a4d9c267849c415c0
SHA1: a45a3f0769da945d6d752eec141b05a5b3fb295a
SHA256: b701cd852120c3ccd42a611a136daefb75e54296017e4145eda5625ae65c57d9

Il cambiamento di nome da Camsensor a Calise sta occupando più tempo del previsto e al momento il sito “ufficiale” su Sourceforge è da considerarsi down (come d’altro canto il blog ufficiale). Devo dire che questo mi ha creato e peraltro mi sta ancora creando qualche problema nella pubblicazione del pacchetto AUR per archlinux, ma ora la situazione è stabile.

Ho già fatto dei cambiamenti disponibili su svn (tarball disponibile qui: http://calise.svn.sourceforge.net/viewvc/calise/?view=tar) di tipo qualitativo e visuale.

La GUI attualmente copre solo la parte di esecuzione, ed è per questo che ho deciso di non avanzare alla serie 0.1.x. Molto probabilmente, in questo periodo di vacanza che mi aspetta mi concentrerò su una versione GUI per la calibrazione ed eventuali bug che mi vengano segnalati. Fatto questo e diversi test su varie distribuzioni, rilascerò la versione 0.1.0 con annessi pacchetti AUR, DEB, RPM (se ci riesco).

5 luglio 2011

Camsensor 0.0.3 beta

Poche ore fa mi sono reso conto di aver soddisfatto i punti che volevo per la nuova versione e quindi eccoci qua: camsensor 0.0.3 beta è ora disponibile.
Questa versione corrisponde alla r81 su svn. link: camsensor

I cambiamenti in questa versione sono:

  • esecuzione in un processo (thread) separato, tuttavia non demone; dopo una attenta analisi delle problematiche legate al fatto di tenere occupata una videocamera, ho deciso che un demone non poteva essere la soluzione più corretta, quanto lo era invece un programma non invasivo da poter facilmente “mettere in pausa”;
  • aggiunta di una interfaccia interattiva in stile mplayer per mettere in pausa, riprendere, terminare ed esportare i dati del programma. Sempre a livello grafico, ho aggiunto qualche info sui parametri in uso e ridotto ad una riga che si autoaggiorna l’output del programma. NON ho usato curses per vari motivi non del tutto condivisibili (avrei dovuto ma preferivo un metodo di output più lineare dal punto di vista visivo);
  • come già accennato, per integrare le due modifiche precedenti, ho riordinato il programma e spostato anche la parte di calcolo dello step e quanto ad esso collegato in libreria, per info su eventuali implementazione fate riferimento alla libreria stessa che è ampliamente commentata; inoltre ho messo sotto classe processata separatamente (threaded) la parte esecutiva del programma, in pratica tutto ciò che viene dopo l’inizializzatione di argomenti e parametri;
  • ho pulito il codice – in diversi casi anche intensamente e non senza difficoltà – e l’ho adeguato, a meno di sviste, alle direttive opzionali PEP-8;
  • infine, anche se non era programmata, ho fatto una piccola ma fantastica modifica/aggiunta per cui, dando l’opzione “–logdata”, il programma tiene in memoria ogni dato ottenuto dall’avvio, per cui, durante l’esecuzione, con il tasto “e” viene esportato l’intero parco dati in formato universale csv (comma separeted values). L’unica pecca di questo è che l’intero ammontare di dati viene mantenuto in RAM, per cui dopo diverse ore (direi più di un giorno) il consumo di risorse risulta considerevole. Questo risulta di grande utilità in ambito sperimentale, ad esempio per monitorare l’intensità di luce durante l’arco della giornata, o gli sbalzi della stessa o in generale qualsiasi genere di analisi fattibile con il livello di luce esterna (o del monitor). Se “–logdata” non è presente, il programma esporterà solo i dati mantenuti per fare la media dei valori.

Qui potete vedere un esempio di grafico ottenuto dopo qualche ora di utilizzo (dalle 17.45 alle 21.00):

Graph

Un bel grafico… La linea rossa rappresenta gli step di retroilluminazione (10 nel mio caso, da 0 a 9) e invece i punti blu sono TUTTE le catture da webcam normalizzate rispetto alla luminosità dello schermo. Si vedono due punti di discontinuità poco prima delle 18.00 e poco dopo le 18.30 (probabilmente sono andato via per mezz’oretta e il programma ha reagito al cambiamento drastico), ma soprattutto la precisione non invasiva per cui, da solo ha regolato gradualmente la retroilluminazione soprattutto nel periodo 20.00/21.00.
Da notare come la cattura della luminosità dalla webcam frontale sia veramente difficile da gestire per la sua variabilità (giustamente, voi davanti allo schermo vi muovete e d’altro canto la webcam prova in continuazione a bilanciare il bianco), da qui il tempo che ci ho messo per elaborare un algoritmo che eliminasse il più possibile, senza spendere troppo in termini di cpu, il disturbo ambientale.
Non ho registrato in questo grafico, il sistema di bloccaggio che evita che succedano cambiamenti di retroilluminazione consecutivi entro i 30 secondi (in più punti di questo grafico, ad esempio, sarebbe entrato in funzione).
In questo grafico ho usato due dei dati a disposizione, ma ci sono infinite possibilità di utilizzo per questo strumento.

Gli obiettivi per il futuro rilascio – la fantomatica versione 0.1.0 – in realtà al momento si riducono ad uno solo (che oltre tutto è in uno stato piuttosto avanzato), ovvero, una GUI (interfaccia grafica) attraverso la quale interagire col programma al pari, se non meglio che con l’interfaccia testuale. In realtà, l’interfaccia c’è già, e in qualche modo anche funzionante, ma ci sono delle barriere strutturali (del mio programma così com’è ora) che mi impediscono di sviluppare al meglio le sue potenzialità.
La mia intenzione originale era di inserire nella GUI, oltre ai bottoni per il controllo remoto (fatto), la possibilità di lanciare un terminale grafico con lo storico entro la media dell’output (fatto) e/o un grafico sempre con lo storico entro la media di una o più caratteristiche a scelta (da studiare, e parecchio)
In pratica, sarà “un solo cambiamento”, ma comunque valido per decidere addirittura di passare dalla versione 0.0 alla 0.1 (non mi aspetto di venirne fuori prima di settembre).

Piccola nota purtroppo, una regressione di performance in termini di tempo del processore dell’8~10% (in realtà attesa, viste le aggiunte), quindi sulla mia macchina è passato da poco più dello 0.8% a poco meno dell’1.0%.

10 giugno 2011

I giorni di pioggia non fanno poi così male

Questi ultimi giorni di pioggia mi hanno portato a scoprire un serio bug (o quasi) su camsensor che non impediva il cambio continuo del valore di retroilluminazione in caso di valori di luce esterna “stabili” nell’intorno di un salto (15%, 25%, 35%, …).

La scala percentuale della luminosità ambientale infatti non è lineare – in realtà è quasi logaritmica – e quindi le normali oscillazioni del valore di luminosità che si hanno a causa dei limiti materiali (la webcam e i normali movimenti dell’utente) provocano delta sulle misure notevoli. Se per disgrazia il cielo temporalesco, ovvero 50-60% di luminosità (con la pendenza della funzione che comincia a farsi sentire), diventa più/meno annuvolato rapidamente, ci si trova nella brutta situazione di avere la retroilluminazione che passa da passo precedente a successivo e vice-versa ad ogni cattura (ogni 0.5 secondi… disturbante)

Poiché, come dicevo uno o due articoli fa, ormai sono totalmente dipendente da questa mia applicazione, il doverla escludere anche solo per brevi periodi di tempo (altra grossa feature da implementare in futuro) non mi dava pace. Ho pensato un pochetto e alla fine ho adottato questa banale soluzione:
appena cambia la retroilluminazione parte un conteggio a 60 secondi, prima dello scadere del conteggio viene inibita l’azione di scrittura dei valori di retroilluminazione, a meno che non si tratti di un cambio repentino (classica luce accesa/spenta) che è ininfluente all’atto del conteggio. Ci tengo a precisare che i valori mostrati nei log non risentono dell’inibizione e quindi sono “reali”, non falsati.

Poiché queste modifiche potrebbero ledere in maniera consistente la risposta del programma nel primo minuto di avvio (per ora i test che ho effettuato non hanno presentato anomalie), come le altre dalla revisione 19 in poi per ora rimangono solo su subversion.
Ormai pensavo di pulire qualcosina sul codice, ottimizzare questa nuova feature e quindi rilasciare una nuova alpha. Il tutto, tra esami e resto penso mi occuperà un mesetto.

Per tutti quelli che non hanno pazienza (io consiglio CALDAMENTE di usare la versione sperimentale su subversion…) il link è il solito: camsensor/code

19 maggio 2011

Camsensor 0.0.1-alpha11

Ieri sera ho finalmente terminato la completa riscrittura del codice in forma ad oggetti. Mentre analizzavo e scrivevo codice mi sono accorto di quanti bug e funzioni ridondanti si possano ottenere rattoppando/aggiungendo senza pianificare prima il risultato finale.

schermata camsensor con opzione debug

Per i curiosi o per chi volesse collaborare alla scrittura, attualmente il codice è caricato e continuamente aggiornato via subversion su Sourceforge, per scaricarlo e analizzarlo/modificarlo voi stessi (dopo in caso scrivetemi o addirittura inviatemi patch per le cose che vorreste cambiare/aggiungere) basta che installiate subversion e lanciate:
svn co https://camsensor.svn.sourceforge.net/svnroot/camsensor camsensor

Dapprima il codice può sembrare complicato, ma in realtà il vero lavoro viene delegato a una o due classi specilizzate.
Ora i primi obbiettivi in vista sono: la gestione di profili personalizzati e la totale indipendenza da input dell’utente esterni alla calibrazione (mediante l’uso di profili), così da poter girare in background come demone di sistema.

Devo dire che il progetto mi sta sempre più prendendo e, nonostante fosse partito così per mettere un’idea in piazza, sta prendendo una sua forma.
Ultima nota, ho aggiornato appena prima la licenza del programma, ora è ufficialmente rilasciato sotto GPLv3.

Nota: io ora uso il programma all-day-long e non riuscirei a farne a meno, oltre al tramonto e annuvolamenti vari, lo trovo utilissimo anche quando di notte accendo o spengo la luce. La vita non sarebbe più la stessa senza

5 maggio 2011

Alla fin fine il mondo non cambia

XFCE logoEccitato come non mai aspettavo di poter usare il nuovo e rivoluzionario gnome 3.0.0 che è più facile, più veloce, più carino, etc, etc. Col risultato che, dopo una giornata a provarlo e ad aver scoperto tutte le magiche funzioni della nuova interfaccia e la potenza dell’accelerazione opengl, ho tolto tutto e ho installato xfce – nella sua splendida ultima versione 4.8 – che tanto mi aveva fatto voglia il qualche mesetto fa.

Non serve chiederlo, ora sono felice come una Pasqua. Per quanto mi riguarda è meglio anche di gnome 2.x, infatti usa le gtk2 ma l’ambiente, sul sistema, ha un carico che non è neanche da paragonare a quello di gnome2, l’utilizzo di RAM praticamente dimezzato se non di più e la CPU che balla fra l’1% e il 3%. Certo, magari sono io che uso poche funzioni, o che mi accontento, o che… ma che cosa volete farci con un computer, la pastasciutta? Sul serio, da ormai una settimana uso xfce senza rimpiangere minimamente gnome3, ma anche gnome2, ma anche… rimpiango di non aver usato da subito xfce, visto che ha tutto quello che cerco in un ambiente operativo.

Devo dire però che non uso la configurazione “default”, infatti l’interfaccia stile CDE la trovo vagamente poco funzionale (anche se poi in queste cose la fa da padrone l’abitudine), quindi ho modificato i pannelli in stile gnome2 (più o meno); poi siccome trovo la navigazione a schede molto più immediata di quella a finestre uso PCManFM invece di Thunar – ma che cos’è il nuovo Nautilus? imbarazzo assoluto per cercare il tasto che uso di più in un file-manager, “livello superiore” che non è la stessa cosa dell’andare a cercare la cartella precedente sulla barra degli indirizzi. Ma ero l’unico a cui Nautilus andava benissimo così com’era? – infine mi sono divertito (e mi sto divertendo) a spulciare le configurazioni di questo gioiellino di xfce visto che praticamente tutto si può cambiare, smontare, riassemblare, stravolgere, etc…

Ovviamente, poiché il logo di xfce è un topolino simpaticissimo, ho cambiato di conseguenza lo sfondo della scrivania: http://wallpaperswide.com/cat_and_mice-wallpapers.html

Tag: , ,
20 aprile 2011

Camsensor alpha

Annuncio con immenso piacere di aver cominciato un progetto che avevo intenzione di fare da parecchio tempo, o meglio, che come le altre decine di piccole idee avevo abbozzato e poi abbandonato per quasi un anno.

camsensor logoIl progetto in questione è camsensor (http://sourceforge.net/projects/camsensor), un programma, ridotto ad un singolo script in python, che permette di usare la normale webcam del laptop, o una dedicata (con piccoli aggiustamenti alla scala di riferimento) come sensore di luce.
Il progetto dipende solo da python e dai moduli opencv (o cv) di python.
Attualmente, la versione è appena passata da pre-alpha ad alpha ed ha queste caratteristiche:
– Cattura di un immagine dalla webcam
– Calcolo della luminosità media sulla base di una versione scalata 8×6 px dell’immagine catturata
– Confronto fra la retroilluminazione dello schermo attuale e quella consigliata per l’ambiente (per sistemi congruenti al mio laptop)
Giusto stamattina ho velocizzato le operazioni di calcolo (non che ce ne fosse troppo bisogno) eliminando due passaggi ridondanti.

Inizialmente pensavo di tenere per me lo script (come ho quasi sempre fatto finora), ma data la bellezza/pulizia del risultato finale ho pensato di renderlo pubblico, così – spero – avrò modo di imparare a scrivere sempre meglio grazie ai consigli di chi ne sa più di me e dà un occhiata al codice.

20 febbraio 2011

Quod Libet

Piccolo articolo per promuovere un player multimediale / audio tagger che ho scoperto da poco, nonostante il progetto fosse abbastanza conosciuto e sia già alla versione 2.2.1.

Quod Libet è nato dal team che ha progettato il tagger exfalso, tra i più conosciuti nel campo. Il progetto, del tutto riuscito era quello di creare un confortevole back-end con tutte le specifiche di un player audio completo.

Io che sono un precisino ho sempre fatto fatica ad avere / vedere tag completi sulla musica che ascolto, e ho provato almeno 5 media player diversi per un discreto quantitativo di tempo fino a capire che erano buoni, e validissimi, ma non facevano quello che volevo. A dire il vero avevo addirittura pensato di modificare i sorgenti per aggiungere delle caratteristiche, ma dopo uno sguardo alla struttura del codice mi ero accorto che avrei dovuto non solo aggiungere linee, ma anche riscrivere varie parti e quindi ho abbandonato.

Le cose che mi ha affaascinato di questo player sono principalmente due: il fatto che sia praticamente un front-end per forse il miglior tagger in circolazione (e ne semplifica addirittura l’utilizzo); la possibilità di visualizzare le informazioni che si vogliono in ogni parte del programma (canzone corrente, lista album/canzoni, tray icon).

In particolare quest’ultima caratteristica lo rende unico e per ora inimitabile, perché non ci sono valori predefiniti da scegliere, si scrivono proprio a mano! C’è da dire poi che è possibile anche visualizzare dei valori solo se uno o più sono presenti, scegliere fra formato lungo o numerico (e.g. le date) e simili.

Ultimo ma non banale il supporto a plugin in linguaggio python che risultano di facile scrittura (a differenza di altri player)

A qualcuno potrebbe non piacere molto l’interfaccia leggermente più spartana di altri player che però per me risulta più efficace visto che la musica più di ascoltarla non si fa…

Schermata Quod Libet

Dopo poco più di un mesetto di utilizzo, penso di essere sicuro nel dire che al momento è il player che soddisfa al meglio le mie necessità.

5 febbraio 2011

Come non chiedersi “perché”?

A tempo perso ho fatto qualche test su virtualbox per confrontare un installazione di windows7 con una di linux-KDE (ed in particolare Archlinux)

Ovviamente non sarò così sciocco da dire che evidentemente windows7 consuma più RAM, usa di più la CPU, o altre baggianate simili che su una macchina virtuale contano fino a là (e alle volte molto fino a là).
Una cosa però è innegabile ed evidente: al termine di un installazione BASE di windows7 – OS, aggiornamenti e OpenOffice – il disco registrava un utilizzo di 7,6 GiB.
Archlinux con DesktopEnviroment KDE, al termine di un installazione comprensiva di tutta la suite KDE con l’aggiunta di qualche programma come GIMP e OpenOffice (e altri sul genere “prima necessità”), registrava un utilizzo di 4,9 GiB. Siamo in pratica al 50% in più di spazio su disco occupato (o il 33% in meno, come preferite).
1GiB di differenza è comprensibile (file temporanei e via dicendo) ma 2,7 sono a mio avviso troppi.

Basti pensare che la mia installazione principale, Archlinux con DE GNOME, ovvero quella che uso sul laptop (e dove faccio girare VirtualBox), esclusi i dischi virtuali e musica/video/foto pesa 7,5 GiB.
Da notare che:
– una gran quantità di programmi installati del genere più vario (compresi programmi per la progettazione 2D/3D relativamente dispendiosi in termini di spazio)
– tutto il necessario per compilare e/o eseguire un programma in C, Python, Ruby, Perl, …
– un installazione completa di wine (con .NET nonostante mono funzioni bene)
– file di cache accumulati in più di un anno di glorioso servizio
equivalgono ad un utilizzo base da parte di un sistema windows7.

Ora, questo in effetti non vuol dire niente visto che un normale disco rigido in vendita oggi difficilmente ha una capienza minore di 250 GiB, però è sempre una nota di demerito per windows7 in un certo qual modo.
Se a questo ci aggiungiamo che linux con la suite KDE è l’emblema della gratuità assoluta del software, penso che alla Microsoft potrebbero pensare di darsi da fare per bene – che già dopo il “presunto” flop di windows Vista per me i loro dipendenti li facevano pensare/scrivere con le frustate 24/24 7/7 – .

Certo che computer del 1997 (aka 14 anni fa) con xfce-archlinux è proprio godimento assoluto, considerato che windows XP viene caricato a fatica – e comunque ha un kernel ormai molto vecchio – .

PS: Windows7 consuma di più RAM e più CPU, va meglio (moooolto meglio) solo sulle applicazioni che usano le DirectX (al momento non eguagliate dalle OpenGl su linux)