cgic 2.05: an ANSI C library for CGI Programming

   
 Published on O'Reilly (http://oreilly.com/)
 See this if you're having trouble printing code examples

What Is Web 2.0

Design Patterns and Business Models for the Next Generation of Software

The bursting of the dot-com bubble in the fall of 2001 marked a turning point for the web. Many people concluded that the web was overhyped, when in fact bubbles and consequent shakeouts appear to be a common feature of all technological revolutions. Shakeouts typically mark the point at which an ascendant technology is ready to take its place at center stage. The pretenders are given the bum's rush, the real success stories show their strength, and there begins to be an understanding of what separates one from the other.

The concept of "Web 2.0" began with a conference brainstorming session between O'Reilly and MediaLive International. Dale Dougherty, web pioneer and O'Reilly VP, noted that far from having "crashed", the web was more important than ever, with exciting new applications and sites popping up with surprising regularity. What's more, the companies that had survived the collapse seemed to have some things in common. Could it be that the dot-com collapse marked some kind of turning point for the web, such that a call to action such as "Web 2.0" might make sense? We agreed that it did, and so the Web 2.0 Conference was born.

In the year and a half since, the term "Web 2.0" has clearly taken hold, with more than 9.5 million citations in Google. But there's still a huge amount of disagreement about just what Web 2.0 means, with some people decrying it as a meaningless marketing buzzword, and others accepting it as the new conventional wisdom.

This article is an attempt to clarify just what we mean by Web 2.0.

Ajax: A New Approach to Web Applications

by Jesse James Garrett
February 18, 2005

If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.

Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.

That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways.

Ajax incorporates:

• standards-based presentation using XHTML and CSS;

• dynamic display and interaction using the Document Object Model;

• data interchange and manipulation using XML and XSLT;

• asynchronous data retrieval using XMLHttpRequest;

and JavaScript binding everything together.

CVS: HowTo

di Lorenzo Bettini e Antonio Gallo

Quando si lavora ad un progetto di dimensioni medio-grandi si ha la necessità di tenere traccia di tutte le modifiche, apportate durante la fase di sviluppo, al codice sorgente. Mantenere un archivio delle modifiche effettuate non è una soluzione accettabile in questi casi. Inoltre, è spesso necessario modificare i sorgenti di una versione antecedente a quella attualmente in sviluppo, per rilasciare, ad esempio, un hot fix o un workaround.

Il discorso si complica ulteriormente quando si lavora in un team di sviluppo dove l’esigenza primaria è quella di evitare l’insorgere di conflitti tra i vari sviluppatori durante la modifica del codice sorgente.

In questo articolo vedremo come il CVS aiuta a risolvere queste problematiche. L’articolo vuole essere una sorta di tutorial, e si consiglia quindi di provare ad effettuare le varie operazioni dell’esempio che tratteremo.

Cosa è il CVS

Il CVS (Control Version System) è un sistema per il controllo delle versioni di un progetto software. Molto utilizzato in ambiente GNU/Unix, ed ovviamente in ambiente Linux, sta acquistando molta popolarità tra gli sviluppatori di tutto il mondo in quanto utilizzato da tutti i maggiori team di sviluppo dei progetti GNU. CVS permette di creare una history di tutti i sorgenti, registrando ogni modifica, ed associando ad ogni sorgente un numero di revisione comprensivo di un breve commento sulle modifiche apportate. Con CVS, è inoltre possibile recuperare, in ogni momento, qualsiasi versione precedente del progetto per poterla modificare, ed è stato disegnato per essere utilizzato da un team di sviluppo, garantendo che i sorgenti restino sempre consistenti, impedendo che le modifiche apportate da uno sviluppatore vengano soprascritte da altri. Infine, permette di esportare le differenze fra due release diverse dello stesso progetto, creando i famosi file di patch.

L’architettura del CVS

L’architettura del CVS è basata su alcuni semplici concetti: tutte le directory ed i file sorgente vengono memorizzati all’interno di un repository. Al suo interno, per ogni file del progetto, sono memorizzati dei file con l’aggiunta dell’estensione ,v. Questi file contengono l’ultima revisione del sorgente e tutte le modifiche apportate (le varie parti del file per le quali le varie versioni differiscono). Più directory, all’interno di un repository possono essere raggruppate in modo da costituire un modulo.

Gli sviluppatori non modificano direttamente il codice sorgente contenuto all’interno del repository ma ognuno di loro lavora su una copia locale dei file. Una volta effettuare le modifiche necessarie (di solito ci si assicura che il codice venga compilato correttamente), il codice modificato viene inviato al CVS che si preoccupa di memorizzare solo le differenze dalla versione precedente a quella del repository e quindi di aggiornare la versione corrente del progetto. E’ buona regola specificare, durante quest’ultima operazione, anche un commento che spieghi le modifiche effettuate.

L’operazione tramite la quale si recupera i file contenuti nel repository viene detta check out, mentre quella che consiste nell’inviare le modifiche apportate si chiama commit.

Come se tutto questo non bastasse, CVS consente anche l’accesso ai sorgent i tramite rete; quindi mantenendo i sorgenti su un computer remoto è possibile accedervi anche tramite Internet. Attualmente tutti i maggiori progetti GNU sono disponibili attraverso CVS, è quindi possibile scaricare dalla rete, giorno dopo giorno, i file che sono stati modificati. Un esempio è il sito dello GNOME [GNU].

Iniziare col CVS

Prima di iniziare a vedere in dettaglio i vari modi di utilizzo del CVS, occorre sapere che ad ogni comando (il CVS funziona a linea di comando), deve essere specificata la posizione del repository. Questo può essere fatto:

1. esplicitamente, tramite l’opzione –d (es. –d /usr/local/cvsroot)

2. implicitamente, tramite la variabile di ambiente CVSROOT.

Il secondo metodo è migliore: conviene inizializzare tale variabile nel proprio script di login.

Creare un il repository

La prima volta è necessario creare il repository, e per far questo, supponendo che la precedente variabile di ambiente sia impostata al valore /usr/local/cvsroot, basta impartire il comando

cvs init

oppure, specificando esplicitament e il path:

cvs –d /usr/local/cvsroot init

Tale comando si limita ad inizializzare le strutture dati interne del CVS senza sovrascrivere o cancellare eventuali file memorizzati all’interno del repository. Attenzione, la scrittura nella directory /usr/local, non è necessariamente concessa a tutti gli utenti, quindi tale comando dovrà essere impartito come root; dopo, per rendere tale repository effettivamente utilizzabile da tutti gli utenti di un certo gruppo (supponiamo users) si dovrà impartire il comando

chmod –R root:users /usr/local/cvsroot

Popolare il repository

Abbiamo quindi creato un repository vuoto, ed occorre popolarlo con i file del progetto, se questo è già esistente, oppure con la struttura di un nuovo progetto. Poiché Siccome rinominare o spostare i file è un’operazione scomoda col CVS, è opportuno pianificare in anticipo quale sarà la struttura di un nuovo progetto prima di passare alla fase di creazione. Vediamo adesso un esempio pratico: supponiamo che ci siano due programmatori, Lorenzo e Antonio, che devono lavorare al programma hello (si tratta, tanto per cambiare, del classico hello world, la versione iniziale è riportata nel Listato 1).

Supponiamo che Lorenzo abbia già due file iniziali del programma (un sorgente, il classico hello world, e relativo Makefile), e che abbia la variabile CVSROOT impostata al valore /usr/local/cvsroot, dopo essersi posizionato sulla directory in cui sono memorizzati i sorgenti (supponiamo ~/progetto/hello), lancerà il comando cvs import:

lorenzo> cvs import -m "Hello Program" hello Lorenzo start

N hello/Makefile

N hello/hello.c

No conflicts created by this import

L’opzione –m serve specificare un commento (sarà utilizzata anche in fase di commit) e se si omettesse, verrebbe aperto l'editor predefinito per aggiungere tale commento (questa alternativa è utile se il commento deve occupare più righe), hello è il nome del programma, Lorenzo il nome del creatore, e start è il tag iniziale (parleremo più avanti dei tag). A questo punto i file possono essere cancellati: sono memorizzati nel repository, e si può utilizzare il comando cvs checkout per recuperare una copia, su cui lavorare, di tali sorgenti dal repository:

lorenzo> cd ..

lorenzo> rm -rf hello

lorenzo> cvs checkout hello

cvs checkout: Updating hello

U hello/Makefile

U hello/hello.c

le varie directory CVS sono create automaticamente e non devono essere cancellate; grazie a queste non è nemmeno più necessario specificare il path del repository.

Modificare i sorgenti

Adesso si modifica il file hello.c, aggiungendo l'istruzione return 0, ed il tipo int a main per eliminare il messaggio di warning in fase di compilazione (se utilizzate Emacs come editor, noterete che riconosce se si tratta di un file contenuto in un repository).

Per effettuare il commit si esegue il seguente comando:

lorenzo> cvs commit -m "aggiunto return 0 e int main per evitare warning" hello.c

Checking in hello.c;

/usr/local/cvsroot/hello/hello.c,v <-- hello.c

new revision: 1.2; previous revision: 1.1

done

Si è specificato il file di cui si vuole fare il commit; se non viene specificato, si effettua automaticamente il commit di tutti i file modificati nella directory corrente e ricorsivamente nelle sottodirectory. Noterete che il numero di revisione del file è stato incrementato automaticamente.

Modifichiamo ulteriormente il file hello.c aggiungendo un commento all'inizio del programma.

Visualizzare lo stato dei sorgenti

Il comando cvs status permette di vedere lo stato di un particolare file o di tutti i file nella directory corrente

lorenzo> cvs status

cvs status: Examining .

File: Makefile Status: Up-to-date

Working revision: 1.1.1.1 Mon Mar 1 08:56:36 1999

======================

File: hello.c Status: Locally Modified

Working revision: 1.2 Mon Mar 1 09:05:31 1999

Come si può vedere (l’output è stato tagliato per comodità) lo status di hello.c indica che la nostra copia del file è stata modificata e non è ancora stato fatto il commit del file. Effettuiamo nuovamente il commit (specificando un commento opportuno).

Antonio effettuerà il checkout del repository sulla propria directory lavoro (per chi non avesse la possibilità di creare un ulteriore utente, si può simulare la situazione effettuando il checkout in un’altra directory).

antonio> cvs checkout hello

cvs checkout: Updating hello

U hello/Makefile

U hello/hello.c

Aggiungere dei file sorgente

Supponiamo che Antonio faccia alcune modifiche al programma, ad esempio aggiunga un altro file al progetto saluti.c (con relativo file .h) con una funzione saluta che effettua il printf.

Il comando cvs update specifica quali file il programmatore ha aggiunto modificato o cancellato; in questo caso se Antonio digita tale comando, avrà in output:

antonio> cvs update

cvs update: Updating .

M Makefile

M hello.c

? saluti.c

? saluti.h

? hello

La M indica che quei file sono stati modificati, ma ancora non è stato fatto il commit, mentre il ? indica che tali file non sono presenti nel repository; tralasciando hello, che è l’eseguibile (notare che il CVS ignora di default i .o e i file che terminano con ~), è necessario aggiungere i due file saluti.c e saluti.h; quindi dopo aver effettuato un make clean, si impartisce il comando cvs add:

antonio> make clean

rm -f *~

rm -f *.o

antonio> cvs add saluti.*

cvs add: scheduling file 'saluti.c' for addition

cvs add: scheduling file 'saluti.h' for addition

cvs add: use 'cvs commit' to add these files permanently

il CVS fa notare che al momento i file non sono stati fisicamente aggiunti al repository (effettuando cvs update, i due file saranno indicati con una A), e per far questo si deve fare il commit (cvs commit -m "aggiunto il sorgente saluti").

Log delle modifiche

A questo punto, supponiamo che Lorenzo torni a lavorare ai sorgenti; la prima cosa da fare è controllare di avere la copia più recente dei sorgenti; anche in questo caso si utilizza il comando update (se si lanciasse adesso il comando cvs status, sarebbe visualizzato per entrambi i due file “Needs patch”, per indicare appunto che è necessario aggiornare la propria copia dei sorgenti):

lorenzo> cvs update

cvs update: Updating .

U Makefile

U hello.c

U saluti.c

U saluti.h

? hello

come si vede adesso la nostra copia dei sorgenti è stata aggiornata per riflettere le modifiche presenti nel repository.

Il comando cvs log permette di vedere i vari log (cioè i commenti aggiunti in fase di commit), per visualizzare la storia delle modifiche occorse al file sorgente specificato. In questo modo Lorenzo ha la possibilità di visualizzare i commenti sulle modifiche apportate da Antonio, in quanto ogni log riporta anche il nome dell’utente che ha apportato le modifiche.

Ad ogni modifica di cui viene fatto il commit viene assegnato un numero di versione o revisione; ogni file avrà un numero diverso, che non seguirà quello degli altri file (ad esempio nel nostro caso hello.c ha versione 1.4, mentre Makefile ha solo 1.2, in quanto quest’ultimo ha subito meno modifiche). E’ possibile recuperare in ogni momento qualsiasi versione di un file; ad esempio se si volesse recuperare la versione 1.3 di hello.c si potrebbe specificare esplicitamente tale numero con l'opzione -r (si consiglia di non eseguire adesso questo comando):

cvs update -r 1.3 hello.c

Tuttavia a volte può essere utile dare dei nomi simbolici ad una certa versione: non è facile tenere a mente dei numeri; nel caso si debba recuperare un solo file, questo può non essere un problema, basandosi sull'output del comando cvs log. Il problema però peggiora quando si vuole recuperare un intero modulo (o comunque un insieme di file): si dovrebbe specificare per ogni file il numero di versione appropriato, e questo potrebbe non essere banale.

Fortunatamente è possibile assegnare dei tag sia a singoli file che a gruppi di file. Ad esempio possiamo assegnare il tag prima_prova (non si possono utilizzare i punti nei nomi di tag) a tutti i nostri sorgenti attuali.

lorenzo> cvs tag prima_prova

cvs tag: Tagging .

T Makefile

T hello.c

T saluti.c

T saluti.h

in questo modo, se dopo qualche modifica si volesse riavere la stessa situazione attuale, basterebbe effettuare il check out specificando tale tag

cvs checkout -r prima_prova hello

Risolvere i conflitti

Un altro problema che ci eravamo posti all’inizio era anche quello di evitare che le modifiche di un programmatore sovrascrivessero quelle di un altro. Del resto si è visto che lanciando il comando cvs update i file modificati nel repository sovrascrivono automaticamente quelli nella directory attuale. Anche in questo caso il CVS ci viene in aiuto col meccanismo del merging. Supponiamo che entrambi i due nostri programmatori modifichino, contemporaneamente e indipendentemente, il programma principale in modo che venga stampato i nomi degli autori (Listato 2).

Poiché i due programmatori non sanno che stanno agendo sullo stesso programma, può darsi che Antonio effettui subito il commit. A questo punto anche Lorenzo potrebbe effettuare il commit, tuttavia è buona norma, prima di effettuare tale operazione, effettuare prima un cvs update, infatti in questo caso Lorenzo otterrebbe questo output:

lorenzo> cvs update hello.c

RCS file: /usr/local/cvsroot/hello/hello.c,v

retrieving revision 1.4

retrieving revision 1.5

Merging differences between 1.4 and 1.5 into hello.c

rcsmerge: warning: conflicts during merge

cvs update: conflicts found in hello.c

C hello.c

Ecco la cosa davvero interessante: CVS si è accorto che entrambi hanno effettuato delle modifiche sullo stesso file “contemporaneamente”, ed ha effettuato il merging dei due file segnalando le eventuali parti in conflitto (come in questo caso) nel seguente modo (vedere il file hello.c in Listato 3 dopo l’operazione del merging): la parte fra i è quella effettuata dall’altro programmatore. Si può notare che Lorenzo aveva anche aggiunto un commento all’inizio del file, mentre Antonio no, e quindi in questo caso il merging non ha provocato conflitti, mentre entrambi hanno agito sulla riga dopo la chiamata di saluti(), e questo provoca un conflitto.

Un conflitto deve essere risolto manualmente dal programmatore (il CVS non può decidere); è da notare che il file al momento non è nemmeno compilabile, a causa dei caratteri superflui, comunque una versione di backup è presente nel file .#hello.c.1.4, creato automaticamente dal CVS. A questo punto il programmatore può scegliere come risolvere il conflitto: ad esempio in questo caso può decidere che è meglio la soluzione di Antonio e quindi può ripulire il file dai caratteri superflui e dall’altra soluzione. E’ importante notare che il merging è un’operazione puramente lessicale, e quindi dopo un merging (anche senza conflitti) non è detto che la compilazione vada a buon fine. Una volta effettuato il merging si può effettuare il commit. E' quindi fondamentale fare sempre un cvs update prima di un commit!

Al momento che Antonio effettuerà nuovamente un update avrà l’ultima versione del sorgente (notare che in questo caso non avviene il merging, a meno che nel frattempo Antonio non abbia fatto ulteriori modifiche).

Branches e patches

A questo punto i due programmatori potrebbero decidere (di comune accordo) che il programma è pronto per la prima release. In questo caso è fondamentale "taggare" tutti i file ad esempio col tag prima_release.

cvs tag prima_release

Supponiamo di trovarci nel seguente scenario: lo sviluppo di tale programma prosegue, tuttavia, dopo diverso tempo che si sta lavorando alla versione 2 del prodotto, ci viene segnalato un bug nella prima versione; ovviamente non si può aspettare di rilasciare la seconda versione col bug corretto (tra l’altro non è nemmeno detto che nella seconda versione il bug sia presente). Del resto se si recuperasse la prima versione e si effettuasse le modifiche ed il commit si andrebbe a sovrascrivere la versione attuale. Fortunatamente in CVS esiste la possibilità di creare dei rami (branch) indipendenti; quando si recupera i sorgenti da un certo ramo, le operazioni di commit riguardano solo quel ramo.

A questo punto, ci possiamo spostare in una directory differente (ad esempio progetto/patch1) e lanciare il seguente comando

lorenzo> cvs rtag -b -r prima_release patch_prima_release hello

cvs rtag: Tagging hello

in questo modo si crea un branch, a partire dalla versione prima_release, chiamato patch_prima_release. Si può adesso effettuare il check out specificando il nome di tale ramo:

lorenzo> cvs checkout -r patch_prima_release hello

Si può correggere il bug (in questo esempio scriveremo solo un commento), e col commit salviamo le modifiche solo su questo branch (nel caso di branch i numeri di versioni contengono più parti, ad esempio nel caso di questa modifica il file hello.c viene salvato con numero 1.6.2.1 indicando che si tratta di un ramo partito dalla versione 1.6 del file).

Se si pensa che sia giusto si può anche fare il merge (il merge può essere richiesto esplicitamente con l’opzione -j) di questa versione corretta con la versione attuale: si deve tornare nella directory dove abbiamo l’ultima versione dei file (spesso denominata main trunk) e lanciare il comando

lorenzo> cvs update -j patch_prima_release

Una volta risolti eventuali conflitti, si potrà effettuare il commit nella versione 2 in fase di sviluppo.

Inoltre possiamo crearci un file diff di patch applicabile col comando patch, classico in ambiente Unix (chi non ha mai applicato una patch al kernel di Linux?):

lorenzo> cvs diff -c -r prima_release -r patch_prima_release hello > patch_rel1

con questo comando chiediamo di creare un file diff (patch_rel1) che contenga i cambiamenti necessari per portare i file della versione prima_release ad essere uguali a quelli della versione patch_prima_release.

Login ed utilizzo di CVS in rete

Vediamo adesso come è possibile utilizzare il CVS in rete, in particolare vedremo come accedere al repository CVS di GNOME [GNU]. Per accedere ad un server CVS remoto è possibile utilizzare tutti i comandi visti finora, con l’unica differenza che è necessario effettuare prima il login. Per far questo è necessario cambiare prima il valore della variabile CVSROOT tramite il comando:

export CVSROOT=:pserver: This e-mail address is being protected from spambots. You need JavaScript enabled to view it :/cvs/gnome”

Il primo campo pserver indica al CVS che si vuole accedere ad un repository situato su un server remoto. anonymous è il nome dell’utente con quale si vuole fare il login, in questo caso si usa un accesso pubblico. anoncvs.gnome.org è il nome della macchina che in questo caso fa da server. Infine, /cvs/gnome è il percorso del repository sulla macchina remota.

A questo punto è possibile effettuare il login con il comando:

cvs login

(Logging in to This e-mail address is being protected from spambots. You need JavaScript enabled to view it )

CVS password:

digitata la password ( in questo caso basta premere invio) sarà possibile recuperare i file con il comando check out.

Quando si opera in questa modalità il server CVS può anche restituire una copia compressa di un intero modulo, ad esempio per prendere il modulo del WindowManager Enlightenment del cvs del progetto Gnome è possibile utilizzare il comando:

cvs -z3 get enlightenment

che effettua un download del codice sorgente ma in forma compressa (opzione –z3), riducendo il tempo di trasferimento.

Il giorno successivo, se si vuole aggiornare la propria copia dei sorgenti, basta utilizzare, dopo aver effettuato il login, il comando:

cvs update -d -P

Installare un server CVS

Per creare un server CVS il metodo più veloce è quello di modificare il file /etc/inetd.conf aggiungendo la riga:

cvspserver stream tcp nowait root /usr/ bin/cvs cvs -b /usr/ bin pserver

Quindi controllare che sia presente in /etc/services la riga:

cvspserver 2401/tcp

Infine occorre riavviare il demone inetd. In tale modo il vostro server CVS risponderà solo quando ci sarà effettiva richiesta da parte di qualche client.

Per controllare gli accessi bisogna gestire il file /CVSROOT/passwd all’interno del repository che contiene delle password codificate in modo simile ad /etc/passwd ed assegnare i permessi desiderati alle directory che compongono i vari moduli del repository

Conclusioni

CVS dimostra di essere quindi un sistema molto potente e versatile. Un altro sistema di controllo di versione: l’RCS. L’RCS, sempre distribuito dalla GNU, non è però disegnato per lavorare in rete, dovrete sempre essere collegati via terminale sulla macchina dove risiede il sistema RCS. CVS slega da questi vincoli e permette l’effettiva implementazione del telelavoro via Internet.

Presso il sito ftp dell’Infomedia potrete scaricare un archivio .tgz contenente il repository; una volta scompattato nella directory /usr/local/cvsroot, potrete avere a disposizione tutte le varie versioni dei listati di cui abbiamo parlato.

Molte risorse sul CVS si possono trovare su [CVS1] e [CVS2].

Riferimenti

[GNU] http://download.cyclic.com/pub/cvs-1.10/www.gnome.org

[CVS1] http://www.loria.fr/~molli/cvs-index.html

[CVS2] http://www.cyclic.com

http://www.badpenguin.org/press/infomedia/cvs.html

Di seguito verrà illustrato come installare le wxWidgets in un Mac e come configurare XCode in modo tale da avere l’auto completamento per le wx e la possibilità di compilare programmi scritti con questa libreria.
Prima di tutto bisogna scaricare i sorgenti dal sito: http://www.wxwidgets.org/downloads/ e scaricare i sorgenti wxMAC. Una volta scaricati, decomprimeteli in una directory a piacere, andate nelle cartella src e troverete un progetto XCode, apritelo e compilatelo, in pochi minuti avete installato le librerie wxWidgets. Per fare una verifica basta aprire un terminale e digitare wx-config --version che restituirà la versione delle wx installate.
Bene ora siamo pronti per scrivere il nostro primo programma.
Aprire XCode:

• creare un nuovo progetto vuoto “Empty Project”, digitare nome e specificare la cartella e premere “finish”.

• dal menu scegliere “Project” e poi “New Target...”dalla sezione in grassetto “Carbon” selezionare “Application” e premere “next”, specificare il nome e premere “Finish”

• chiudere la finestra che si è appena aperta per editare il Target, dal menu “File” scegliere “New File...” e dal menu in grassetto “C and C++” selezionare “C++ File” e premere “Next”, inserire il nome e premere “Finish”

• dal menu premere “Project” e “Edit Active Target “nome target”, spostarsi nella linguetta “build”

• aprire una console e digitare wx-config --cxxflags, copiare uno a uno tutti i path che iniziano per -I senza il -I e incollarli nella voce “Header Search Paths” nell'editor del target

• dalla console selezionare tutte le voci precedute da -D con -D compreso questa volta e copiarle nella sezione “Other C Flags”

• tornare alla console e digitarre “wx-config --libs”, copiare tutto il contenuto e incollarlo nella sezione “Other Linker Flags”

• infine ricercare la voce “ZeroLink” e togliere del tutto la selezione

Fatto questo dovremmo essere pronti per scrivere un programma con la comodità dell’auto completamento e le funzionalità specifiche di XCode per scrivere programmi per il Mac.
Per essere sicuri che tutto funzioni scriviamo l’Hello Word, nel file .h:

http://sickdevelopers.blogspot.com/2008/09/wxwidget-e-xcode.html

CGI Programming With Apache and Perl on Mac OS X

Since Mac OS X already has Apache and Perl installed, all you need to do is configure the Apache server to allow CGI programs.

You're going to need a text editor, both for editing the config files and for writing your CGI programs. You can get by with using TextEdit, Apple's free text editor. Or you may want to check out BBEdit, a powerful text editor from Bare Bones Software. (This is a commercial product, but they do have a free 30-day demo you can use to try it out.) BBEdit offers syntax-coloring, Perl syntax checking, a "run" command (allowing you to run your programs), and lots more. It's primarily an HTML editor, so you also get the full suite of HTML tools as well.

• Who can see your website?
• Programming Locally, then Uploading to the ISP
• Configuring Apache on Mac OS X
• Viewing Your Site
• Writing Your CGI Programs
• Accessing the Unix Shell

Who can see your website?

If you have a permanent, fixed IP address for your computer (e.g. your computer is in an office, or you have your own T1 line), your Apache server will be able to serve pages to anyone in the world*. If you have a transient IP address (e.g. you use a dialup modem, DSL modem or cable modem to connect to the internet), you can give people your temporary IP address and they can access your page using the IP address instead of a host name (e.g, http://209.189.198.102/)*. But when you logout, your server will obviously not be connected, and when you dial in again you'll probably have a different IP address.

Obviously for permanent web hosting, you should either get a fixed IP address (and your own domain name), or sign up with an ISP that can host your pages for you.

* Unless you're behind a firewall, and the firewall is not configured to allow web traffic through.

Programming Locally, then Uploading to the ISP

You may want to develop and debug your programs on your own computer, then upload the final working versions to your ISP for permanent hosting. Since OS X is Unix, all of the programs shown in CGI Programming 101 should work seamlessly both on your Mac and on a remote Unix host/ISP.

---

Configuring Apache on Mac OS X

You need to modify the Apache configuration file to tell it where your pages are, and enable CGI programs. The config file is located in /etc/httpd/httpd.conf. If you have BBEdit, use "Open File By Name" from the File menu to specify the path to the file to edit:

 

BBEdit "open file by name"

 

(If you don't have BBEdit, you'll have to edit the file the hard way - in the Unix shell. Open the Terminal application, then type sudo pico /etc/httpd/httpd.conf to edit the file. You'll be moved to a text editor inside of Terminal. Use the arrow keys to move around. Help and instructions on the pico editor will appear along the bottom of the window. When you're done editing, use control-X to quit out of pico (you'll be asked if you want to save the file or not).)

Once you have the httpd.conf file in your editor, scroll down (or use Find) until you get to the line that says "# Control access to UserDir directories". Scroll down just past that and you'll come to a commented section for Directory:

 

        #<Directory /home/*/Sites>         #  AllowOverride FileInfo AuthConfig Limit         #  Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec         #  <Limit GET POST OPTIONS PROPFIND>         #     Order allow,deny         #     Allow from all         #  </Limit>         #  <LimitExcept GET POST OPTIONS PROPFIND>         #     Order deny,allow         #     Deny from all         #  </LimitExcept>         #</Directory> 

 

Uncomment this entire section (by removing the pound signs at the beginning of each line), and change the Options line to this:

 

        Options MultiViews Indexes SymLinksIfOwnerMatch Includes ExecCGI 

 

Options specifies what options are available in this directory. The important ones here are Indexes, which enables server-side includes, and ExecCGI, which enables CGI programs in this directory.

After the Options line, add the following DirectoryIndex line:

 

        DirectoryIndex index.html index.cgi 

 

Now scroll down several pages (or use Find) to the AddHandler section. Uncomment the CGI line:

 

        AddHandler cgi-script .cgi 

 

This causes any file with a .cgi extension to be processed as a CGI program. If you want to also have files with a .pl extension be processed as CGI programs, add the .pl extension on that same line:

 

        AddHandler cgi-script .cgi .pl 

 

Also uncomment the AddHandler line for server-parsed, and change the extension from .shtml to .html:

        AddHandler server-parsed .html 

 

This causes all .html files to be searched for server-side include tags.

Now save the configuration file. (If you're using BBEdit, you'll be prompted for your system administrator password; this is required since the config file is owned by the root user.)

To restart Apache, go to the System Preferences panel and select the "Sharing" icon:

Check "Personal Web Sharing" to start Apache. (You may have to click the lock in the lower left-hand corner to unlock the sharing panel and allow you to make changes.)

Once web sharing is on, look at http://localhost/ (or http://10.0.1.2) in your browser to ensure that the server restarted successfully.

Viewing Your Site

http://localhost/ is the homepage for your site; it shows the index.html (or more specifically index.html.en) page located in the /Library/WebServer/Documents folder. You can change the location for the server-wide files by changing the DocumentRoot directive in the httpd.conf file.

The site-wide test page

A better solution is to use the Sites folder in your home directory. You can view pages in the Sites folder by looking at http://localhost/~yourusername/ in your browser. For example, my short username is "kira", so the URL to my pages is http://localhost/~kira/. This displays the index.html file located in /Users/yourusername/Sites/. The "Sites" folder in your home directory is where you can put all of your HTML and CGI programs.

Your new personal web page

---

Writing Your CGI Programs

Now you're ready to write some CGI programs! Here's a simple one you can use to get started. You can write this in your choice of text or Perl editor:

        #!/usr/bin/perl -wT         print "Content-type: text/html\n\n";         print "<h2>Hello, World!</h2>\n"; 

Save the file in your Sites folder as "first.cgi", then go to http://localhost/~yourusername/first.cgi to view it.

Now you're ready to go to Chapter 1 and start learning CGI programming.

---

Accessing the Unix Shell

Your Mac is built on Unix, so you can access the Unix Shell by launching the Terminal application (in Applications/Utilities). A new terminal window will appear and you'll be connected in your home directory. Type ls -l to see the contents of your home directory as it looks in Unix.

Consult the Unix tutorial to learn more about working in the shell.

---

Additional Resources

• Apache Web-Serving with Mac OS X
• Apache Web Serving With Jaguar, part 1. How to start and stop Apache on your mac; where to put your HTML pages.
• Apache Web Serving With Jaguar, part 2. Editing the config file to enable CGI programs. (For the impatient, the config file is typically located in /etc/httpd/httpd.conf)

Take a look here:

http://www.cgi101.com/learn/connect/mac.html

Lo standard su wikipedia: http://it.wikipedia.org/wiki/IEEE_754

Lo standard:

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=30711&isnumber=1316

<meta name="verify-v1" content="YBYKRWeHiVTmWdilmOgWipInl7EGyPBICBFLUptoUrg=" >