[EN] [IT]
  [INFO] [ACQUÉRIR] [PLAN] [RESSOURCES]

Compilateur


De l'autre côté de l'Atlantique

Les nouvelles semblent si calmes depuis le début de l'année... Alors, que se passe-t-il ?

Ce n'est pas que l'équipe de Staz Software est partie se dorer la pilule sur la Riviera. En réalité, aussitôt que la Release 7 est sortie, la Release 8 était déjà en route.

La prochaine Release connaîtra un changement de taille puisque l'environnement de programmation sera carbonisé. En d'autres termes, il ne sera plus nécessaire de lancer le logiciel dans Classic lorsque vous travaillerez sous OS X. Bien entendu, en tant que programmeur, vous voudrez sans doute tôt ou tard vérifier comment votre propre application se comporte dans cet environnement, c'est pourquoi un nouvel article fera son apparition dans le menu Commande de l'Éditeur, pour vous permettre de forcer votre application à s'exécuter dans Classic, votre programmei exploitera alors la librairie Carbon de Mac OS 9.

Nous n'avons que très peu d'informations à offrir concernant la prochaine release. Nous supposons qu'il n'y aura pas beaucoup de nouvelles fonctionnalités, parce que tous les efforts se sont concentrés sur la carbonisation de l'environnement de développement pour OS X en premier lieu. Quelques petits détails dans les headers de FB^3 ont été corrigés depuis la sortie de la Release 7; très peu pour dire la vérité, du fait que très peu de problèmes ont été rapportés par les utilisateurs. La Release 7 s'avère être une mouture essentielle et fiable qui, pour la première fois, nous a permis de produire des applications pour Carbon avec FutureBASIC. Pensez-y, il y a quelque temps, nous avons dû attendre cinq ans avant de pouvoir compiler pour le PPC !

Tout cela est parfait, direz-vous, mais pas la moindre rumeur à se mettre sous la dent ?

Eh bien... En ce moment des beta testeurs sont en train de jouer avec une pré-release qui dispose d'un compilateur carbonisé. On s'est laissé dire qu'il compile plus rapidement sous OS X; les temps de compilation semblent particulièrement écourtés sur les machines bi-processeurs. Très cool !

Le Débogueur est paraît-il déjà opérationnel avec Carbon, mais pour le moment, il n'y a pas d'Editeur, ni de Gestionnaire de Projets à tester. C'est compréhensible. L'Editeur est en soi, un fantastique travail réalisé avec FutureBASICII qui a probablement été entamé il y a une dizaine d'années. L'application 68K a été sérieusement optimisée, et je parie que vous n'auriez pas remarqué ce "détail" s'il n'était mentionné de temps en temps ici ou là.

Vous avez peut-être maintenant une idée du travail à accomplir. Le programme doit passer au travers d'au moins deux transitions, c'est-à-dire PowerPC et Carbon, sans compter qu'il doit être plus vraisemblablement écrit pour le nouveau Runtime Appearance. C'est très clairement, une mise à jour énorme, et il nous faut être patients.

Le silence des agneaux
D'un autre côté, la Release 7, dès sa sortie, nous a proposé tant de grains à moudre que nous avons tous remarqué le ralentissement dans les annonces de programmes qui émanent généralement de la communauté des programmeurs FutureBASIC. La conversion pour Carbon, n'est pas toujours un processus évident, particulièrement pour ceux qui veulent convertir de grosses applications patiemment maintenues et améliorées au fil des années. Encore moins évident, si l'intention est d'utiliser le tout nouveau et recommandé Runtime Appearance.

Bref, à en juger par les requêtes faites au support technique, il nous semble que l'ordre du jour se doit d'être aux conseils avisés :

La documentation Carbon
Tout d'abord, vous devez savoir que beaucoup de techniques de programmation sont tombées en désuétude avec l'arrivée de Carbon. Vous ne pouvez donc pas vous attendre à voir fonctionner un gros programme sous OS X en lançant son exécution d'un clic de souris empressé. On ne peut rien reprocher à FutureBASIC ici et le mieux que vous puissiez faire est de lire la documentation Carbon rédigée par Apple. Toutefois, si vous êtes impatient de voir votre application tourner, vous devriez, avant toute chose, lire le manuel "Portage vers Carbon" qui est disponible dans le menu Aide de l'Editeur. Il liste les difficultés les plus courantes que vous serez amené à rencontrer dans le processus de conversion.

Ce petit manuel a été écrit à la suite de la mise à jour pour Carbon des centaines d'exemples abondamment commentés qui peuplent le CD. À propos, revoir ces exemples est la meilleure chose à faire, si vous voulez découvrir comment certaines difficultés peuvent être réglées. Vous devriez d'ailleurs voir cet ensemble de fichiers comme un manuel gigantesque qui est fréquemment mis à jour, le plus souvent avec chaque release. En l'occurrence, pour la Release 7, la plupart des exemples ont été réécrits afin d'illustrer les adapatations nécessaires pour la carbonisation du code. L'ancien code a même été laissé intact dans des structures de compilation conditionnelle au risque d'en alourdir la lecture mais avec l'avantage de pouvoir le faire tourner quel que soit le CPU choisi, y compris 68K.

Le drame de la Toolbox
Beaucoup de fonctions et procédures de la Toolbox, depuis longtemps éprouvées, ont changé avec Carbon. D'autres ont totalement disparu. Quelques unes ont légèrement été modifiées ou bien ont été renommées. Une pléthore de nouvelles fonctions a aussi vu le jour. Il y a ici aussi une bonne quantité de choses à assimiler. Vous aurez donc beaucoup de lectures en perspective puisqu'en la matière vous ne pourrez pas éviter la documentation d'Apple sur ces sujets.

Vous pouvez télécharger les fichiers headers d'Apple depuis leur site Web, ou bien installer le "Developer CD" qui est fourni avec OS X et visiter pour votre édification tous ces fichiers headers qui constituent maintenant la Toolbox Carbon.

Comme vous le savez déjà, une grande quantité de fichiers exemples font appel à la Toolbox, aussi voilà une autre raison pour les examiner une fois de plus.

Vous pouvez aussi consulter les fichiers headers de FB^3, parce qu'en bout de course le Runtime appelle la Toolbox pour faire son travail. Naturellement, si votre programme utilise du code BASIC pur, vous aurez beaucoup moins de soucis à vous faire puisque le travail est effectué par FutureBASIC lui-même dans ses rouages internes.

Vous devez noter aussi que tous les nouveaux appels à la Toolbox qui ont vu le jour avec Carbon ne sont pas implémentés dans les fichiers headers de FB^3. Dans la documentation "Portage vers Carbon", mentionnée ci-avant, vous trouverez des centaines de déclarations prêtes à être copiées et collées dans votre code source pour le cas où elles viendraient à manquer dans les headers officiels de FutureBASIC. Et pour le cas où vous en auriez besoin, bien sûr.

Le blues du Runtime
Avec le tout récent Runtime Appearance et son lot d'améliorations, vient le temps d'une décision importante. Le Runtime Appearance est présenté comme la voie à suivre, et c'est clairement le futur de FutureBASIC. Toutefois, on pénètre ici dans une tout autre cour, avec encore une fois, beaucoup de choses à apprendre, et plus particulièrement pour tout ce qui concerne l'Appearance Manager. Domestiquer la bête demande du temps. C'est la raison pour laquelle je suis enclin à penser que pour les gros programmes il vaut mieux les carboniser dans un premier temps avec le Runtime Standard jusqu'à ce qu'ils fonctionnent correctement. Mettre à jour votre application pour Carbon et le Runtime Appearance en même temps peut devenir rapidement un cauchemar. Ceci exclut les applications écrites avec Programme Generator, puisque ce dernier ne génère pas de code pour le Runtime Appearance. À prodéder autrement, vous aurez à faire face à beaucoup plus de difficultés.

Pour apprendre le Runtime Appearance vous devrez lire le Manuel de Référence (lequel, faut-il le rappeler, est aussi mis à jour pour chaque nouvelle release) ou/et le livre "Switching to FutureBASIC" qui est livré avec la Release 7.

Lire la documentation d'Apple sur l'Appearance Manager, on ne le répétera jamais assez, est un must.

Finalement, l'examen des fichiers exemples et plus particulièrement ceux de Robert Purves, l'auteur du Runtime Appearance, devrait être une obligation. Notez que vous trouverez aussi sur le CD, le freeware "FB^3 Code Styler" avec son code source écrit pour le Runtime Appearance -- Il y a là aussi pas mal de choses à glaner.

Pour d'anciens programmes, l'une des choses dont il vous faudra tenir compte est le support 68K. Non, je ne plaisante pas, nous avons appris qu'un programmeur FutureBASIC gagnait correctement sa vie en ciblant presqu'exclusivement les machines 68K. Ce n'est pas vraiment une surprise pour nous, car, on le sait, le code généré par FB est excellent, aussi rapide et compact que celui produit par un bon compilateur C. Cela dit, il est vraisemblable que le choix du CPU cible sera dicté par votre base utilisateurs, mais vous devez garder en mémoire que le Runtime Appearance ne supporte et ne supportera jamais le CPU 68K. En fait, seul le Runtime Standard vous permet de gérer un unique projet qui peut être destiné non seulement pour le 68K et le PPC, mais aussi pour Carbon. Si vous avez besoin de cibler les processeurs 68K et que vous optez néanmoins pour le Runtime Appearance, vous aurez à maintenir deux programmes sources pour une seule application. Bon courage !

En revanche, une fois que votre application sera carbonisée avec le Runtime Standard, vous remarquerez immédiatement son look démodé, pour ne pas dire ringard, lorsqu'elle s'exécutera sous OS X, et il ne fait pas de doute que vous voudrez changer cela. Il est très certainement possible de jouer avec l'Appearance Manager dans le Runtime Standard, à condition que vous utilisiez de manière intensive les appels à la Toolbox et que vous contourniez certains des mécanismes internes du runtime, mais cela reste une tâche très lourde et je ne la recommanderais pas.

En réalité, de nos jours la question tourne plus autour du support PPC par opposition à Carbon; vous remarquerez d'ailleurs que votre code aura tendance à s'alourdir pour faire fonctionner votre application aussi bien en PPC qu'avec Carbon.

Bon, maintenant que vous savez que le Runtime Standard va sûrement mais lentement prendre une retraite bien méritée, et que votre application se comporte décemment dans OS X et dans Classic, il est temps d'envisager la conversion vers le Runtime Appearance.

Bien qu'il offre un support plus ou moins limité de l'ancien code du Runtime Standard, le Runtime Appearance gère un certain nombre de choses différemment, et il recèle des nouveautés qui lui sont propres. Vous risquez de constater des comportements inattendus de votre application fraîchement convertie. Vous allez devoir passer du temps à peaufiner votre code. À cet égard, il n'y a pas d'autre solution que de lire les manuels et d'examiner les fichiers exemples, cela dit il n'y a hélas pas de manuel spécifique expliquant les problèmes de conversion du Runtime Standard au Runtime Appearance.

Si vous avez suivi les techniques de programmation recommandées par Staz Software depuis des années, la conversion devrait en être facilitée. Encore plus, si vous avez adopté la bonne pratique d'isoler dans votre programme le code qui gère l'interface utilisateur de celui qui exécute le véritable travail de votre application. Alors, peut-être, sera-t-il temps d'envisager de réviser les sections de votre code dédiées à la gestion des fichiers et d'abandonner le défunt (mais toujours miraculeusement opérationnel grâce à Andy G.) Numéro de Référence de Répertoire de Travail et d'opter pour la stucture FSSpec qui est également supportée par FB au niveau du runtime. Notez au passage que cette structure est presque déjà obsolète à cause des fondations Unix de OS X. Gasp !

Pour finir, j'espère que je vous ai bien préparé à la confrontation qui vous attend, vous pouvez avoir à faire face à une quantité de petits détails irritants :

  • Différences d' apparence et de comportement de votre application entre PPC et Carbon
  • Différences d'apparence (bien sûr) et de comportement de votre application entre les runtimes Standard et Appearance
  • Différences de comportement de votre application carbonisée entre OS X et Mac OS 9
  • Différences de comportement de votre application entre Mac OS 9 et Classic
  • Différences de comportement de votre application entre deux versions consécutives de OS X
  • Bugs dans la Toolbox PPC qui n'apparaissent pas dans Carbon
  • Bugs dans Carbon qui n'apparaissent pas en PPC
  • Bugs dans OS X
  • Bugs éventuels dans le Runtime Appearance (on ne l'espère pas)

A première vue, cette liste pourrait paraître impressionnante, mais n'oubliez pas que ces dysfonctionnements ne surgissent pas à chaque ligne de code et tout bien pesé, rien de quoi vous empêcher de porter votre application vers Carbon et OS X.

Bonne programmation.


 


Publié :
Avril 2003
  © 2000 Pix&Mix  
  Tous droits réservés
INFO  |  ACQUÉRIR |  PLAN  |  RESSOURCES

  FutureBASIC est une marque déposée appartenant à Staz Software, Inc et utilisée avec permission.