Archive for the ‘Tutorial’ Category
Proseguiamo il nostro tour attraverso il sistema Macintosh incominciando a parlare del primo set di API (un insieme di funzioni, variabili e di strutture dati) utilizzabile dai programmatori.
La Macintosh Toolbox nasce come un insieme di risorse, driver, routine e API memorizzate nella “Old World ROM” dei Mac. Il termine toolbox includeva originariamente soltanto le funzioni e le variabili globali per implementare l’interfaccia utente (a sottolineare la cosa 9la stessa Apple si riferiva alla toolbox come User Interface Toolbox) tralasciando quindi la parte dedicata al sistema operativo.
L’articolo continua qui (domani proseguiremo il viaggio introducendo Carbon).
Buona lettura!
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
Con questo articolo inizierò una serie di post articolati sullo sviluppo del Mac OS da quel gennaio ‘84 fino ai giorni di Mac OS X.
Vista la vastità e la complessità del tema ristringeremo il campo d’azione a una delle parti essenziali del sistema, le API per lo sviluppo software. L’idea mi è venuta parlando un pò sul canale mela dove ho visto che le idee sono un pò confuse (chi è meglio, carbon cocoa?! bla bla). Quindi ho deciso di fare piano piano chiarezza.
Possiamo distinguere tre grandi famiglie (una distinzione che come vedremo più avanti risulta a volte troppo forzata o troppo labile, ma che ci aiuterà a capire meglio gli argomenti trattati): Mac OS ToolBox, Carbon e Cocoa.
Il primo articolo parla del Macintosh Memory Managment ovvero la gestione della memoria del Mac fino all’avvento di Mac OS X. Lo trovate cliccando qui, ma anche nell’indice generale degli articolo che invece sta qua. Indispensabile prima di passare a parlare del vero tema dei post.
Spero possa essere una interessante lettura; il linguaggio a volte è un pò tecnico ma è davvero difficile eliminare questo genere di riferimenti in informatica.
Nei prossimi articoli parleremo della Mac OS X Toolbox, di Carbon (e lib di OS X) e quindi Cocoa. Se volete chiedere qualcosa, avete dubbi o semplicemente commentare fatelo pure in questo post.
Buona lettura!
Macintosh Memory Managment
[tags]Gestione Memoria Macintosh, Mac OS ToolBox, Carbon, Cocoa, Macintosh, Programmazione Apple, Memoria Mac[/tags]
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
Dopo svariati rinvii dovuti alle più disparate cause inizio la stesura di quella che probabilmente diventerà la prima guida in italiano di Objective-C (dando per scontato che verrà mai completata). L’idea è quella di creare una serie di guide, alcune free, altre previo un piccolo fee (giusto per ripagarmi l’eventuale fatica e il tempo perso). Spero che la cosa possa interessare molte persone.
Intanto ho inziato a buttar giù qualcosa. Potete iniziare da qui (vi aggiornerò all’uscita di nuovi capitoli; se trovate imprecisioni ed errori fatemelo sapere).
[tags]Guida Objective-C, Manuale Objective-C, ObjC, Programmare Cocoa[/tags]
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
A volte l’ottimizzazione…
Capita spesso che durante lo sviluppo di una applicazione si tenda ad estremizzare l’ottimizzazione del codice. Nella maggior parte dei casi tuttavia i risultati riguardano un guadagno insignificante al pari di un codice talmente criptico ed ingestibile che sarebbe degno di un messaggio di guerra.
In questo post facciamo qualche benchmark sugli array e vediamo che succede, mettiamo quindi a cronfronto tre linguaggi/frameworks: C, C++ e il nostro Objective-C (o meglio le Foundation Classes di Cocoa).
C++ mette a disposizione del programmatore 17 classi per la gestione delle liste (niente di sorprendente, rispetto a Java che va oltre le 22). La cosa interessante è che spesso e volentieri i nomi delle classi descrivono, in qualche modo, come lavora l’implementazione: vector, list hash_multiset e così via per il C++ e LinkedBlockingQueue,IdentityHashMap etc per Java.
Al contrario in Core Foundation i nomi descrivono soltanto il tipo di classe (ed è questo in effetti lo spirito del messaging dinamico di Objective-C; il messagio dice cosa fà ma non come lo fà).
Prendiamo ad esempio una delle 7 classi (ripeto 7!) più utilizzate di Core Foundation, NSArray (o meglio CFArray) e diamo un’occhiata ad uno dei commenti apparsi sulla mailing list di Darwin (se ve lo state domandando, Core Foundation è opensource).
In poche parole:
Il tempo (e quindi il costo) di accesso a un valore all’interno della lista è al peggio O(lg N) per ogni implementazione, presente e futura (ovvero cresce in maniera logaritmica in base all’indice della chiave richiesta). Tuttavia nella maggior parte dei casi sarà O(1) (ovvero un tempo costante per ogni chiave in ogni posizione). Le operazioni di ricerca lineare, inserimento e cancellamento di oggetti avranno similarmente un grado di complessità pari a O(N*lg N) ma in generale sarà molto minore. In pratica non c’è nessun bisogno di portare in posizioni “strategiche” le chiavi più importanti.
La cosa curiosa è che in generale gli array non hanno tempi di lettura logaritmici quanto piuttosto risultano essere a tempo costante. Ma non questi array. Array? Chi ha parlato di veri e propri array? Sembrano più dei dizionari o degli alberi binari…
…In effetti facendo qualche prova si hanno dei risultati quasi ’stravaganti’. Diamo un’occhiata ai grafici sotto. I risultati sono espressi come multipli degli originali e il crescere delle linee indica un maggior costo di esecuzione al pari della dimensione dell’array. Questo significa che, ad esempio, se la ricerca punta come una retta in alto, il costo sarà proporzionale alla crescita degli elementi dell’array.
Ecco qui cosa si ottiene con degli array in C.
Ok allora? Beh possiamo notare che un inserimento in posizioni casuali è circa 50 volte più lento se la dimensione dell’array è 100,000 anzichè 1,000,000. La cosa in realtà non ci sorprende, i dati non fanno altro che dirci che non c’è molta differenza tra inserimento in posizioni casuali anzichè all’inizio della lista.
In C++ la differenza di costi tra le operazioni risulta essere più lieve (c’è soltanto da far notare una leggera differenza tra cancellazione lineare e in posizioni casuali).
Al contrario con CFArray… il grafico risulta essere totalmente diverso dai due precedenti!. A partire da un certo punto (intorno ai 300,000 valori) l’inserimento o la cancellazione all’inizio o alla fine non comporta nessun aumento di costo al variare della dimensione degli array.
Cancellazione e inserimento in posizioni casuali inizia con un consumo lineare per poi ridursi fino a diventare costante. In soldoni stiamo dicendo che non c’è differenza tra inserire 1,000,000 elementi o 100,000 ma sicuramente inserirne 200,000 è più dispendioso del resto (a vederla così sembra assurdo…sembra).
Scorrere avanti/indietro l’array invece comporta un costo costante sopra i 300,000 elementi. Questo ci porta a pensare che in effeti ci sia una sorta di cache per l’accesso al CFArray (cosa che tra l’altro è rafforzata da una ulteriore classe chiamata CFStorage).
Cosa abbiamo imparato?
Non abbiamo sicuramente testato a fondo la cosa, tuttavia questi piccoli esperimenti ci portano a dire che CFArray (e quindi NSArray) sono una ottima soluzione in caso di dimensioni medie e medio-alte, senza doverci per forza sobbarcare l’onere di creare classi apposite o lavorare di ottimizzazione. Apple ha già lavorato per noi e sembra averlo fatto ottimamente!
Nella prossima puntata daremo uno sguardo ad array di dimensione basse.
(Questo articolo è stato realizzato grazie alla collaborazione di alcuni utenti su #macdev e grazie a RFish).
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
Uno dei più grandi crucci dei programmatori è senz’altro la gestione della memoria. Se da una parte la gestione della memoria può essere un compito pesante per i problemi che può comportarne un approccio sbagliato, questa offre un fantastico modo per ottimizzare la propria applicazione liberando risorse non più utili.
Il concetto principale sta infatti nel lasciare al sistema la porzione occupata da un particolare oggetto quando il suo utilizzo non è più necessario. Oggetti che rimangono appesi al programma in compenso possono comportare una diminuzione delle risorse libere e un frequente accesso al disco come memoria virtuale, ovvero un rallentamento generale delle prestazioni del sistema.
D’altro canto puntare ad oggetti prematuramente rilasciati non farà altro che aumentare le probabilità di crash.
Insomma per farla breve, imparare a padroneggiare questo argomento vi aiuterà a realizzare del buon codice, cosa generalmente rara al giorno d’oggi.
Differenti linguaggi di programmazione hanno diversi approcci a questa tecnica. Java ad esempio fa uso del cosidetto Garbage Collector, ovvero un cestino dell’immondizia dove il runtime java butta tutte le variabili ormai in disuso. In questo caso il compito del programmatore è alleggerito notevolmente. D’altro canto l’applicazione invece non risulta poi così ottimizzata e perde in prestazioni ed efficenza. L’altra tecnica è il cosidetto Reference Counting. Questo sistema viene usato da Objective-C e consiste nell’associare ad ogni oggetto un contatore di vite. L’idea è che quando il contatore arriva a 0, nessun altro oggetto fa più riferimento ad esso ed è possibile rilasciarlo in sicurezza.
Ogni classe in Cocoa deriva dalla root NSObject. NSObject contiene quattro metodi di gestione della memoria:
+alloc: crea un nuovo oggetto (allocando la memoria necessaria) e imposta il reference counter a 1.
-release: decrementa di una unità il reference counting
-autorelease: aggiunge l’oggetto all’autorelease pool che si occuperà automaticamente di decrementare di 1 il contatore quando sarà necessario (una sorta di Garbage Collector)
-retain: aumenta il contatore di una unità
Diamo un’occhiata meglio.
Creiamo ad esempio un nuovo progetto con un pulsante che esegue:
MyClass *oggetto;
oggetto = [MyClass alloc];
Non abbiamo fatto altro che dichiarare una variable di tipo MyClass ad assegnargli un nuovo oggetto creato tramite alloc. Ad ogni nuovo click sul pulsante il sistema creerà una nuova istanza MyClass. Tuttavia la memoria non viene mai rilasciata e continuando a cliccare verranno allocate sempre più risorse sebbene il loro utilizzo non sia necessario (memory leak). Quello che più è sbagliato tuttavia è che non potremmo più accedere ad ogni istanza di MyClass e questa sarà irrimediabilmente persa nello spazio di memoria dedicato all’applicazione.
Se proviamo a dichiarare MyClass *oggetto in modo globale (inserendola quindi all’interno del blocco interface di una classe) le cose non miglioreranno poi di molto. Infatti mentre potremmo accedere all’ultima istanza assegnata a oggetto non ci sarà più verso di recuperare le altre allocate.
Quindi la prima cosa da ricordare è che allocando un oggetto tramite +alloc saremo responsabili del suo rilascio.
Per rilasciare un oggetto creato tramite alloc è necessario eseguire su di esso il un release o autorelease. Entrambi i metodi decrementeranno il contatore di vita dell’oggetto di ‘1′ e visto che oggetto ha come reference counter iniziale ‘1′ esso verrà deallocato dalla memoria del programma.
Vediamo meglio come utilizzare questi metodi.
L’ideale è quello di distruggere ogni nuova istanza create prima di perdere il contatto con essa. Nel codice appena visto significa spedire un messaggio di rilascio alla classe dopo averla utilizzata:
MyClass *oggetto;
oggetto = [MyClass alloc];
// azioni e metodi vari sulla classe
[oggetto release];
oggetto = nil;
Del release abbiamo già parlato. Sull’ultima linea invece vale spenderci due parole. Innanzitutto assegnando nil (ovvero un ‘non-valore’) alla classe si avrà la certezza futura sulla sua utilità o meno. Inoltre si avrà la certezza che messaggi ad essa spediti non vengano invece recapitati ad oggetto non più esistenti (i cosidetti zombie).
Chiamare un metodo (e quindi in buona sostanza spedire un messaggio) di una classe che non esiste più ha come effetto il crash dell’applicazione con un segnale 10 (SIGBUS) o 11 (SIGEGV), cosa che invece non accade se al messaggio viene passato a nil (generalmente l’operazione di scrittura su un oggetto zombie dà come messaggio un SIGBUS, mentre il SIGEGV viene mandato soltanto quando si accede ad essa in lettura).
Parliamo ora dell’autorelease.
Spedire un autorelease ad un oggetto non equivale a decrementarne immediatamente il reference counter. Esso invece verrà modificato soltanto più avanti a discrezione dell’autorelease pool. Alla fine del ciclo pool (come già detto una sorta di spazzino della memoria) la variable verrà interrogata e se necessario decrementata.
Se proviamo a sostituire il release del metodo precedente con:
MyClass *oggetto;
oggetto = [MyClass alloc];
// azioni e metodi vari sulla classe
[oggetto autorelease];
scopriremo che il risultato è identico a quello della prova precente. Questo perchè il “garbage collector” di objC ha controllato che oggetto non fosse in uso da qualche altra parte prima di decrementarne il contatore (e quindi, in questo caso, di deallocarlo dalla memoria).
L’autorelease risulta particolarmente utile nel caso in cui gli oggetti debbano passare da un metodo all’altro del codice.
Prendiamo ad esempio questo codice:
- (NSString)autoreleasedString
{
NSString *string = [[NSString alloc] initWithString:@”ciao!”];
[string autorelease];
return string;
}
Grazie all’autorelease saremo sicuri che la stringa string non sarà soggetta ad errori di memory leaks. Ma le sorprese non finiscono qui. Cocoa mette infatti a disposizione un set di metodi del tipo +nomeMetodo, chiamati “costruttori temporanei” (se mi passate la traduzione barbarizzata di convenience constructors) che permettono la creazione di oggetti temporanei, ovvero oggetti che sono di tipo autorelease (e quindi non richiedono release diretti).
Ad esempio consideriamo il codice seguente:
http://www.blogger.com/img/gl.quote.gif
NSString *string = [[NSString alloc] initWithCString:”Ciao”];
// utilizzo della stringa nel codice
[string release];
-initWithCString: potrà essere sostituito con il relativo costruttore temporaneo
+stringWithCString: in questo modo:
NSString *string = [NSString stringWithCString:"Ciao"];
// utilizzo della stringa
senza bisogno di rilasciare manualmente l’oggetto.
I costruttori temporanei possono essere usati anche durante l’istanziamento di variabili globali (o comunque che hanno un maggiore utilizzo durante l’esecuzione del programma) applicandovi sopra un retain. Da questo momento in poi saremo responsabili del loro rilascio.
Che dire… spero di essere stato abbastanza chiaro.A questo punto vale la pena consigliare un paio di link utili a chi mastica l’inglese, entrambi scritti dall’ottimo mmalcolm crawford di StepWise (una delle più ‘longeve’ software house sin dai tempi di NeXT).
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
Esistono due metodi per ‘congelare’ lo stato del computer. Mentre OS X entra nella modalità a basso consumo alimentando soltanto la RAM di sistema (in modo da mantenere attive tutte le risorse allocate), i computer con Windows utilizzano la cosidettà modalità di ibernazione.
In questo caso il sistema operativo si occupa di salvare il contenuto della RAM all’interno del disco di sistema staccando quindi l’alimentazione ai componenti del computer. In questo modo ovviamente si risparmia più energia (circa 1% ogni ora e mezza) ma il riavvio non sarà comunque istantaneo (è necessario infatti che il computer faccia l’operazione inversa, ovvero copiare il contenuto del file di cache sulla RAM. Questo in genere richiede una manciata di secondi dipendentemente dalla macchina e dell’hard disk).
A volte comunque può essere una cosa utile ed è proprio dal 10.4.3 che l’Hibernation Mode è entrato sul Mac (che poi in realtà esisteva già ai tempi di Mac OS 9). Sebbene il suo utilizzo, a meno di hack sotto descritti, sia limitato a macchine recenti c’è qualcuno che ha trovato il modo di hackerare la situazione.
Per stringere i nuovi PowerBook hanno un’opzione chiamata “has-safe-sleep” all’interno delle proprietà dell’Open Firmware (una specie di BIOS più evoluto…’dio’ non voglia che sparisca con l’arrivo degli Intel). Per modificarla occorre scrivere sul terminale (ogni riga seguita da un a-capo):
sudo nvram nvramrc=’” /” select-dev
” msh” encode-string ” has-safe-sleep” property
unselect
‘
sudo nvram “use-nvramrc?”=true
Riavviate quindi il computer e assicuratevi di avere circa 700mb libere di spazio sul disco. Tornate quindi sul terminale e scrivete:
sudo pmset -a hibernatemode 3
in modo da creare il file di immagine dove verrà salvata la RAM (/var/vm/sleepimage).
Nel caso in cui utilizzate la modalità Memoria Virtuale Sicura di File Vault sostituite 3 con 7 in modo da disabilitare l’ibernazione criptata (non ancora supportata).
Il vostro Mac ora andrà in ibernazione (safe sleep) soltanto nel caso in cui decidiate di stopparlo e l’energia della batteria è quasi esaurita. Ecco uno screenshot. In realtà è possibile utilizzare Safe Sleep sempre (ma questa operazione non sarà istantanea ma, come già detto, richiederà qualche secondo) scrivete questo comando sul terminale:
sudo pmset -a hibernatemode 1
(5 nel caso di utilizzo di memoria virutale sicura, 0 per disabilitarla successivamente).
Nel caso in cui eventuali file corrotti di memoria non vi permettano di riavviare il computer tenete premuti all’avvio Command-Option-O-F ed entrando nell’OpenFirmware scrivete:
setenv boot-image
boot
Per disabilitare Safe Sleep dal vostro computer usate invece:
sudo pmset -a hibernatemode 0
Jackoverfull ha creato un set di script che automatizzano l’entrata in Safe Sleep. Vale la pena di darci un’occhiata.
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
Sull’onda della patch per AMRollOverButton segnalata un paio di giorni fa volevo segnalarvi una nuova modifica al codice (che tra l’altro viene utilizzata già da Nemo). La patch aggiunge la possibilità di avere tre tipi di pulsanti basati sulla classe di Andreas:
1) Multititled button (è un pulsante che cliccato passa ciclicamente sui vari nomi impostati)
2) OnOff Button (è il solito pulsante già reso disponibile qualche giorno fa)
3) MultiTogglesButton (permette di avere un set di n-pulsanti AMRollOverButton di cui è possibile selezionarne solo uno alla volta).
Uno screenshot della classe è disponibile qui. L’utilizzo del codice è mostrato nel progetto di esempio e l’implementazione all’interno di programmi è davvero ridicola. Trovate il pacchetto qui.
Non c’è nessuna licenza a corredo ma sarei felice se nella vostr app ci fosse una piccola menzione!
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
Come faccio a mantenere il mio Mac in buona forma? E’ una delle domande che mi viene spesso fatta da amici e conoscenti switchati da poco sotto la mela morsicata. Ho deciso quindi di snocciolare qualche linea guida senza la pretesa di essere esaustivo e completo (non nego che probabilmente ci sarà un nuovo articolo a riguardo).
Ovviamente stiamo parlando di Mac OS X quindi sono esclusi tutti coloro che per forza o per voglia sono rimasti al Classic (e ragazzi, sarebbe anche ora che vi aggiornaste… sono passati ormai 4 anni…).
Spesso e volentieri mi capita di vedere utenti Mac che tengono file e cartelle all’interno della root dell’hard disk (per intenderci è quella cartella che si apre quando si seleziona l’icona del vostro disco rigido, dove trovate Sistema, Libreria, Utenti etc.) o sparsi in giro per il sistema.
Sbagliato. Cercate di essere il più organizzati e ordinati possibile. Tenete i documenti all’interno della *vostra* cartella utenti cercando di dare una struttura organizzativa logica (in questo senso un minimo di catalogazione ve la offre il sistema con le varie cartelle Immagini, Musica etc.).
Installate tutte le applicazioni all’interno della cartella Applicazioni. Se è la prima volta che utilizzate Mac OS X eseguite gli aggiornamenti di sistema e quindi iniziate a catalogare le applicazioni per cartelle (Grafica, Editor di Testo, Multimedia etc.). In ogni caso prima di incastrare tutto in cartelle eseguite comunque gli aggiornamenti (ahimè Mac OS X ha ancora il brutto vizio di cercare soltanto in /Applicazioni i software da aggiornare, ignorando quindi le sottocartelle).
Tenete sul Dock soltanto le applicazioni indispensabili o meglio ancora iniziate ad usare LaunchBar o simili per accedere alle applicazioni (in questo modo il Dock conterrà soltanto le applicazioni attive).
LaunchBar è una vera manna dal cielo e non finirò mai di dire che è indispensabile su ogni Mac (potreste usare anche Spotlight ma sinceramente reputo l’idea di dover cercare in tutto il vostro hard disk per un’applicazione che sapete già dov’è).
If ain’t broken don’t fix it! Contrariamente a quanto molti utenti pensano, il fatto di avere tanta roba sul disco non rallenta il computer. Teneteci tutto quello che volete purchè rimanga almeno un 20% del disco libero (questo aiuterà il sistema ad organizzare i file e utilizzare al meglio la cache).
Quando dovete dare un blocco di file ad un amico o comunque spostarli in un altro computer (sia in rete che attraverso supporti vari) create delle immagini disco utilizzando Disco Utility. Questo vi permetterà di copiare i file più velocemente, vi salverà il culo se utilizzate documenti con data+resource fork (tipicamente di Classic), e diminuirà (non sempre) lo spazio occupato dagli stessi.
Perchè? Semplicemente perchè è più facile copiare un file da 2gb piuttosto che miliardi di file in cartelle dal peso totale di 2gb.
Sfatiamo un altro mito comune. La frammentazione non serve su OS X (la frammentazione tipicamente è dovuta ad un file diviso in più parti dentro il vostro disco rigido). Il file system di OS X (dal 10.3 in poi) ha le ottimizzazioni di salvataggio alla radice evitando e frammentando automaticamente i file. Per quanto riguarda le librerie di sistema l’ottimizzazione viene fatta ad ogni nuovo processo di installazione di applicazioni (o comunque può essere fatta manualmente una volta al mese utilizzando tools freeware come Onyx).
Rimuovete i componenti che vengono aperti all’avvio del computer. Tenete soltano quelli strettamente utili.
Disinstallare applicazioni su Mac è semplicissimo. Di solito basta rimuovere il file eseguibile. Tuttavia se vogliamo essere pignoli possiamo anche rimuovere eventuali cartelle che lo riguardano e che di solito sono scritte in Libreria/Application Support o file di preferenze con nome com...plist. Non è strettamente necessario ma è un buon esercizio d’ordine!
La gestione dei font, benchè sia migliorata dalle prime beta di OS X rimane ancora un cruccio niente male. Quando si devono gestire parecchie font utilizzare Libro Font diventa una tortura. E perchè è lento e perchè è l’applicazione più schifosamente prodotta… ancora prima del Finder. Utilizzate l’ottimo Font Explorer di Linotype.
Cercate in ogni caso di installare font di qualità. Capita spesso che problemi di lentezza siano dati da font corrotte. L’applicazione sopra citata, come anche Font Doctor vi permettono di testare la qualità dei vostri caratteri.
Abilitate il journaling del vostro sistema in modo da salvarvi in caso di cadute di tensione o blocchi di sistema. Se avete appena formattato e installato il sistema da capo tenete in considerazione l’idea di utilizzare Carbon Copy Cloner o simili per creare un’immagine del disco da ripristinare in caso di casini (dedicato agli smanettoni).
Fate un pò di manutenzione del sistema a seconda dell’utilizzo del computer, da una volta a settimana a un paio di mesi. La verifica del sistema è di nuovo automatizzata all’avvio dal sistema.
VN:F [1.0.6_327]
Rating: 0.0/5 (0 votes cast)
