[FR] [EN]
  [INFO] [COMPRA] [MAPPA] [RISORSE]

Compilatore


Dall'altra parte dell'Atlantico

Le novità sembrano languire dall'inizio di questo anno... Cosa sta succedendo?

Non è verosimile che la ciurma di Staz Software stia spendendo un po' del suo tempo libero sulla costa francese. In effetti, quando la Versione 7 è stata rilascitata, la Versione 8 era già in preparazione.

La prossima Versione vedrà un notevole cambiamento dato che l'intero IDE sarà carbonizzato. In altre parole, quando lavorerete in OS X, non dovrete più lanciare l'ambiente di sviluppo in Classic. Di certo, come programmatori, vorrete verificare la vostra applicazione sotto Mac OS 9, ecco perché troverete un nuovo elemento nel menu Comandi dell'Editor che vi permetterà di forzare l'esecuzione in modo Classic della vostra applicazione Carbonizzata.

Abbiamo poche altre informazioni da rilasciare a riguardo della prossima versione. Sospettiamo che non ci saranno molte altre nuove caratteristiche, dato che tutti gli sforzi sono inanzitutto concentrati per far sì che l'IDE funzioni al meglio sotto OS X. Alcune imprecisioni sono state corrette nei file header di FB3 della Versione 7; molte poche a dire il vero, semplicemente perché molto poche sono state segnalate. La Versione 7, che è stata una vera pietra miliare, per la prima volta ci permette di creare applicazioni carbonizzate. Pensate che poco tempo fa abbiamo dovuto aspettare cinque anni prima di essere in grado di compilare per il PPC!

Fino a qui tutto bene, ma non hai qualche pettegolezzo da dirci? potreste domandarvi...

Bene, bene, bene... Attualmente i beta tester stanno sperimentando una versione preliminare che presenta il Compilatore carbonizzato. È stato detto che compila più velocemente sotto OS X; i tempi di compilazione sembrano radicalmente accorciati, specialmente su macchine con doppio processore. Molto bene!
Il Debugger è funzionante anch'esso in Carbon, ma al momento l'Editor carbonizzato e il Project Manager non sono ancora in fase di test. Questo è comprensibile: l'Editor è un notevole programma scritto in FutureBASICII che ha iniziato la sua vita probabilmente una decina di anni fa. È un'applicazione 68K particolarmente ottimizzata, e scommetto che non ve ne siate mai accorti. Potete ora capire la quantità di lavoro che deve essere fatta. Il programma deve fare il suo percorso attraverso almeno due transizioni, PPC e Carbon, senza contare che verrà probabilmente scritto nel nuovo Ambiente Appearance. Questo è sicuramente un aggiornamento importante, e quindi dobbiamo essere tutti un po' pazienti.

Il silenzio degli innocenti

D'altra parte, la Versione 7 è stata talmente innovativa e con così tanto materiale, che abbiamo notato una riduzione negli annunci che generalmente arrivana dalla comunità, FB. La conversione a Carbon non è sempre un processo immediato, in particolare per i programmatori che vogliono convertire applicazioni complesse pazientemente migliorate e aggiustate negli anni. Ancor di più se si decide di portate le proprie applicazioni al nuovo e raccomandato Ambiente di esecuzione Appearance. Secondo il nostro supporto tecnico sembra che alcune problematiche siano, nell'ordine:

Documentazione Carbon

Inanzitutto dovete sapere che molte delle tecniche di programmazione sono diventate obsolete con l'arrivo di Carbon: non potete pretendere che il vostro complesso programma funzioni perfettamente in OS X non appena selezionate il comando di esecuzione. Di questo non possiamo incolpare FB e la cosa migliore da fare per tutti è leggere la documentazione Carbon provveniente da Apple. In ogni caso, se siete ansiosi di vedere la vostra appicazione in esecuzione, dovete leggere, prima di qualsiasi altra cosa, il manuale FB3 chiamato "Conversione a Carbon", disponibile nel menu Aiuto dell'Editor. L'elenco delle più comuni difficoltà che potrete incontrare nel cammino.
Questo piccolo manuale è stato scritto seguendo l'aggiornamento a Carbon delle migliaia di esempi abbondantemente commentati che popolano il CD. A proposito, rivisitare tutti questi file è la cosa migliore che possiate fare se volete vedere come alcune delle difficoltà possono essere risolte. Potete vedere questo insieme di file come un gigantesco manuale che viene frequentemente aggiornato, spesso ad ogni nuova versione. Inoltre, con la Versione 7, molti dei file di esempio sono stati riscritti per àshowcase le modifiche necessarie per funzionare in Carbon e il vecchio codice è stato lasciato inalterato in strutture condizionali di compilazione. Questo potrebbe aver àcluttered il codice ma ha permesso allo stesso pezzo di codice di funzionare su PPC e su 68K.

Toolbox drama
Molte delle procedure e funzioni Toolbox a cui eravamo abituati sono cambiate con Carbon. Alcune sono completamente sparite. Altre sono cambiate leggermente o solo rinominate. Moltissime altre sono comparse. C'è ancora un sacco da imparare qui. Avrete moltissime cose da leggere dato che non potrete saltare per intero la documentazione di Apple su tali soggetti.
Potete anche scaricare i file header Apple dal sito Web di Apple, o installare il Developer CD che viene fornito con OS X e fare un'edificante visita a questi file header che ora costituiscono il Carbon Toolbox. Come già sapete, un sacco dei file di esempio dipendono da chiamate Toolbox, e questa è un'altra ragione per eaminarli una volta di più.

Potetete anche consultare i file header FB3 dato che, in definitiva, l'ambiente di esecuzione (Runtime) richiama il Toolbox per fare il suo lavoro. Di certo, se il vostro programma usa puro codice BASIC avete meno da temere dato che il grosso del lavoro viene fatto dietro le quinte dallo stesso FutureBASIC.

Occorre anche notre che non tutte le nuove chiamate Toolbox che sono comparse con Carbon sono implementate nei file header di FB3. Nella già citata documentazione "Conversione a Carbon" troverete centinaia di dichiarazioni pronte per esswere copiate e incollate nel vostro codice qualora fossero assenti dagli header. E se vi servissero, ovviamente.

Non c'è nessuna cura per gli sconforti da Ambiente di esecuzione?
Con il nuovo potenziato Ambiente di esecuzione (Runtime) Appearance arriva un'importante decisione da prendere. L'Ambiente Appearance è promosso come la via da seguire, questo è chiaramente il futuro for FutureBASIC. Tuttavia, questo è un nuovo elemento in gioco, anzi un insieme di elementi tutti nuovi, con un'ingente quantità di cose da imparare, specialmente per tutto quello che riguarda l'Appearance Manager. Acquistare padronanza con tale bestia richiede un po' di tempo. Quindi, sono propenso a pensare che per grandi programmi sia meglio carbonizzarli in primo luogo con l'Ambiente di esecuzione Standard fino a che funzionino correttamente. Aggiornare le vostre applicazioni per Carbon e per l'Ambiente Appearance contemporaneamente potrebbe in breve diventare un incubo. Questo non riguarda tutte le applicazioni scritte con il Program Generator daro che questo non è compatibile con Appearance. Aggiornarli al contrario potrebbe essere molto pi˜ difficile.

Per documentarvi sull'Ambiente di esecuzione Appearance dovete leggere il Manuale di Riferimento (il quale è aggiornato con ogni nuovva versione) e/o il libro chiamato "Switching to FutureBASIC" che viene spedito con la Versione 7.

La lettura della documentazione Appearance Manager di Apple, devo proprio dirlo, è indispensabile.

Infine, l'analisi dei file di esempio e più particolarmente quelli di Robert Purves, l'autore dell'Ambiente Appearance, è necessario. Notare, vi è anche il freeware "FB3 Code Styler" con il suo codice sorgente su CD; questo è un progetto completo scritto per l'Ambiente Appearance -- potere imparare molto anche da qui.

Una cosa di cui dovete tenere in conto per i vostri cari vecchi programmi è il supporto 68K. Non stò scherzando, abbiamo sentito parlare di qualcuno che fa una vita decente usando FutureBASIC quasi esclusivamentge per macchine 68K. Questo non ci ha sorpreso perché il codice 68K generato da FB è eccellente, veloce e compatto come il codice generato da un buon compilatore C. Molto probabilmente, la vostra scelta sarà dettata dalla vostra base di utente, ma dovete sapere che l'Ambiente Runtime non supporta e non supperterà mai la CPU 68K. Infatti solo l'Ambiente Standard vi permetterà di gestire un singolo progetto indirizzato non solo alle CPU 68K e PPC, ma anche a Carbon. Se dovete supportare la CPU 68K e volete comunque passare all' Ambiente Appearance, dovrete gestire due diversi programmi per la stessa applicazione.

D'altra parte, una volta che la vostra applicazione è carbonizzata con l' Ambiente Standard noterete immediatamente il suo aspetto antiquato, per non dire impacciato, quando gira sotto OS X e non ho dubbi che desidererete cambiare anche quello. È ceramente possibile giocare con l'Appearance Manager nell'Ambiente Standard, ammesso che usiate le chiamate al Toolbox in modo estensivo e lavoriate intorno ad alcuni dei meccanismi incorporati nell'ambiente di esecuzione, ma questo è senza dubbio pesante e non posso certo raccomandarvelo. Infatti, al giorno d'oggi la domanda gira di più intorno al supporto di PPC; noterete che il codice tende ad essere complicato solo per rendere mantenere le cose funzionanti allo stesso modo lì.

Ora che sapete che l'Ambiente Standard sarà lentamente ma certamente destinato a "miglior posto" e che le vostre applicazioni carbonizzate gireranno allo stesso modo in OS X come in Classic, è tempo di prevedere la conversione all'Ambiente Appearance.

Anche se c'è un sostegno limitato al cosiddetto codice legacy, ereditato dall'Ambiente Standard, alcune cose sono gestite abbastanza diversamente; altri sono completamente nuovi e potreste notare il comportamento inatteso dalla vostra applicazione da poco convertita. Dovrete passare un certo tempo aggiustando il vostro codice. A quel proposito non c'è soluzione tranne la lettura dei manuali ed esaminare i file di esempio.

Se avete seguito le tecniche di programmazione raccommandate da Staz Software per così tanti anni, la conversione dovrebbe essere facile. Anche più facile se avete seguito la buona tecnica di isolare il codice che ha a che fare con l'interfaccia utente dal codice che esegue il vero codice della vostra applicazione. Quindi, magari, è ora di aggiornare le sezioni del vostro programma dedicato alla gestione dei file e abbandonare il dead (ma ancora funzionante grazia a Andy G.) Numero di riferimento alla directory di lavoro e passare alla struttura FSSpec che è anche supportato da FB al livello di codice di Ambiente di esecuziione. Notare che tale struttura è già quasi obsoleta a causa della fondazione Unix di OS X. Gasp!

Infine, io spero che siate preparati a confrontarvi con un sa di discrepanze:

  • differente comportamento e aspetto della vostra applicazione fra PPC e Carbon
  • differente aspetto (ovviamente) e comportamento della vostra applicazione tra ambiente Standard e Appearance Runtimes
  • differente comportamento delle applicazioni carbonizzate tra OS X e Mac OS 9
  • differente comportamenti della vostra applicazione tra Mac OS 9 e Classic
  • differente comportamenti della vostra applicazione tra due consecutive versioni di OS X
  • problemi in chiamate Toolbox PPC che non si mostrano in Carbon
  • problemi in Carbon che non si mostrano in PPC
  • problemi in OS X
  • possibili errori nell'Ambiente Appearance (speriamo di no).


Questa lista può impressionare a prima vista, ma tenete a mente che questi piccoli fastidi non si verificano ad ogni linea di codice. In ogni casoi, niente di questo si associa al modo in cui eseguite la conversione della vostre applicazioni a Carbon e OS X.

Buona programmazione.



Aprile 2003
  © 2000
INFO  |  ACQUISIRE  |  MAPPA  |  RISORSE
Tutela della privacy  
Notizie legali  
  FutureBASIC è un marchio registrato di
Staz Software, Inc ed è usato previa autorizzazione.