Compilation : Utilisation de Scala
Pour ceux qui ne le savent pas encore, Scala est un langage de programmation développé par le LAMP (le laboratoire du Prof. Odersky et des assistants du cours de compilation).
Scala est disponible sur les machines de la salle
INF 3. Chaque fois qu'une nouvelle version est disponible, nous
l'installons sur le compte iclamp dans le répertoire
/home/iclamp/local/packages
. Le répertoire ci-dessous
contient des liens vers les différents exécutables dont vous aurez
besoin.
/home/iclamp/soft/bin
Afin de pouvoir lancer ces exécutables sans devoir chaque fois
entrer le chemin complet, ajoutez le répertoire ci-dessus à votre
variable d'environement PATH
.
Si vous désirez utiliser Scala à la maison, vous pouvez
télécharger la dernière distribution ici. Les versions
.tar.gz
sont pour les systèmes UNIX (Linux, MacOS X,
Cygwin, Solaris, ... ) et les versions .zip
pour les
systèmes Windows. Les versions normales de la distribution requièrent
un jdk 1.4.x. Les versions marquées jdk-1.3
devraient
fonctionner avec un jdk 1.3.x. Si vous avez un jdk 1.2.x ou antérieur,
il vous faudra le mettre à jour.
Pour installer la distribution UNIX, décompressez l'archive et
ajoutez le répertoire bin
à votre PATH
. Avec
la distribution Windows, la procédure est la même, mais il faut en
plus définir une variable SCALA_HOME
de façon à ce
qu'elle pointe sur le répertoire racine de la distribution. Pour plus
d'informations, lisez le README
Comme Scala est encore en plein développement, nous sortons assez
régulièrement de nouvelles distributions, parfois plus d'une par
semaine. Souvent, il s'agit de corrections de bugs. Si vous voulez
profiter de toutes ces corrections, il vous faudra souvent réinstaller
Scala. Afin de ne pas devoir à chaque fois redéfinir votre
PATH
(et votre SCALA_PATH
si vous êtes sous
Windows) nous vous conseillons donc de renommer le répertoire
scala-YYYYMMDD-hhmmss
en scala
(ou, si c'est
possible, de créer un lien symbolique de scala
vers le
répertoire de la dernière distribution) et de rajouter
scala/bin
au lieu de
scala-YYYYMMDD-hhmmss/bin
à votre PATH
.
Durant les vacances, un compilateur (générant du bytecode Java) a
été ajouté à la distribution Scala. Son nom est socos
.
Pour écrire un programme en Scala qui puisse être compilé, il vous
faut déclarer un module contenant une méthode main
prenant en argument un tableau de String
et retournant
Unit
. Ci-dessous, le programme HelloWorld
écrit en Scala.
module HelloWorld with { def main(args: Array[String]): Unit = { System.out.println("HelloWorld"); } }
Pour compiler ce programme, utilisez la commande suivante :
socos -d ./classes HelloWorld.scala
Cette commande compile le fichier HelloWorld.scala
et
place les classes générées dans le répertoire classes
.
L'option -d classes
n'est pas obligatoire, si vous
l'omettez, les classes générées seront placées dans le répertoire
courant. Pour exécuter le programme, il faut utiliser la commande
java
, mais il faut ajouter au classpath les classes du
runtime Scala. Celles-ci se trouvent dans l'archive
scala.jar
. Cette archive se trouvent dans le répertoire
lib
de la distribution. Sur les machines de la salle
INF 3, elle se trouve ici :
/home/iclamp/local/packages/scala/lib/scala.jar
Pour exécuter le programme HelloWorld
il faudrait
donc utiliser la commande suivante :
java -classpath ./classes:/home/iclamp/local/packages/scala/lib/scala.jar HelloWorld
Le compilateur Scala est actuellement encore en plein développement et nous trouvons régulièrement des bugs et vous tomberez très probablement aussi sur certains bugs. Dans ce cas, n'hésitez pas à nous les signaler.
Un bug peut se manifester de différentes manières, en voici quelques exemples :
ClassFormatError
, AbstractMethodError
,
etc), mais parfois aussi simplement par un résultat erroné. Il peut
aussi arriver que l'erreur ne se manifeste que dans certaines
circonstances particulières. Ces bugs sont particulièrement
difficiles à trouver, car souvent, lorsque le résultat est erroné,
on va vérifier et revérifier l'algorithme du programme sans penser à
un bug du compilateur. Donc, si vous êtes intimement convaincu que
votre code est correct mais que le programme s'obstine à donner le
mauvais résultat, pensez à l'éventualité d'un bug dans le
compilateur. Les bugs les plus durs à détecter sont aussi ceux qui devraient être signalés à tous prix, mais tout bug devrait être signalé, même ceux qui vous paraissent les plus anodins. En effet, même si un bug vous paraît anodin, vous êtes peut-être la première personne à l'avoir détecté. Parfois, certains bugs passent longtemps inaperçus parce qu'ils ne se manifestent qu'avec certains styles de programmation ou lorsque l'on utilise certains concepts en même temps. Ainsi si vous avez un style de programmation très personnel ou que vous êtes la première personnes à combiner certains concepts, vous pouvez parfois faire apparaître de nouveaux bugs avec des programmes très simples et/ou très courts. N'hésitez donc pas à nous signaler tous les bugs que vous rencontrez.
Pour signaler un bug, envoyez un mail à l'un des assistants du cours. Pas besoin de faire de grands discours, vous pouvez simplement inclure votre code source et la ou les lignes de commandes qui déclenchent le bug. Si votre programme se compose de plusieurs fichiers sources, envoyer-nous les tous afin que nous puissions reproduire le bug.
Si vous avez un peu de temps, et que vous avez des informations supplémentaires comme par exemple des moyens de contourner le bug ou les circonstances exactes qui provoquent le bug, n'hésitez pas à nous les indiquer. Cela est parfois très utile pour localiser l'origine du bug.
Si vous avez beaucoup de temps, vous pouvez faire encore mieux en essayant de réduire au maximum la taille du programme qui provoque l'erreur. Pour cela, faite une copie de votre code source, puis essayez d'y supprimer un maximum de méthodes et de classes et de simplifier au maximum le code restant. Il faut souvent procéder par essais successifs; supprimer une ou plusieurs méthodes, vérifier que le bug est toujours là, supprimer ou simplifier d'autres méthodes, vérifier à nouveau que le bug est encore là, etc. Souvent on arrive à réduire le programme à une dizaine de lignes. Cela est évidemment une très grande aide pour ceux qui doivent ensuite corriger le bug, mais il faut souvent beaucoup de temps pour réduire ainsi son programme.