Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
common_lisp [Le 20/02/2023, 21:45]
88.166.188.193 correctif dokuwiki grace à wiki-corrector https://forum.ubuntu-fr.org/viewtopic.php?id=2067892
common_lisp [Le 11/01/2024, 11:56] (Version actuelle)
90.65.241.102 [Développement interactif basé sur une image]
Ligne 122: Ligne 122:
 ===== Les éditeurs ===== ===== Les éditeurs =====
  
-Pendant longtemps, les seuls *bons* éditeurs disponibles étaient [[emacs|Emacs]] et son plugin Slime ainsi que l'IDE LispWorks, qui vient avec l'​implémentation du même nom, mais qui est propriétaire. Aujourd'​hui,​ il existe de bons modules pour des éditeurs populaires. ​Nous vous référons ​à: https://​lispcookbook.github.io/​cl-cookbook/​editor-support.html+Pendant longtemps, les seuls *bons* éditeurs disponibles étaient [[emacs|Emacs]] et son plugin Slime ainsi que l'IDE LispWorks, qui vient avec l'​implémentation du même nom, mais qui est propriétaire. Aujourd'​hui,​ il existe de bons modules pour des éditeurs populaires. ​Référez-vous à: https://​lispcookbook.github.io/​cl-cookbook/​editor-support.html
  
 ===== Développement interactif basé sur une image ===== ===== Développement interactif basé sur une image =====
Ligne 130: Ligne 130:
 Avec un bon IDE pour CL (typiquement Emacs et Slime, mais aussi SLIMA pour Atom et d'​autres),​ on peut développer son programme interactivement de A à Z, sans avoir besoin de redémarrer le processus Lisp sous-jacent. Toutes les modifications sont ajoutées au fil de l'eau, les tests peuvent être lancés depuis la même image au fil de l'eau. Un cas d'​usage classique est:  Avec un bon IDE pour CL (typiquement Emacs et Slime, mais aussi SLIMA pour Atom et d'​autres),​ on peut développer son programme interactivement de A à Z, sans avoir besoin de redémarrer le processus Lisp sous-jacent. Toutes les modifications sont ajoutées au fil de l'eau, les tests peuvent être lancés depuis la même image au fil de l'eau. Un cas d'​usage classique est: 
  
-   * on écrit du code dans fichier, on démarre le plugin Lisp et on connecte un REPL à son éditeur. Lorsqu'​on a écrit une fonction, on compile cette fonction avec un raccourci clavier (C-c C-c). **On a compilé dans ce cas UNE fonction**. Le compilateur Lisp nous donne s'il le faut des messages de warning: incompatibilités de types, une variable n'est pas utilisée… Si la compilation a réussi (j'​insiste:​ la fonction a été compilée, dans le cas de SBCL c'est en code machine efficient. Dans le cas de l'​implémentation CLISP ce serait du "​bytecode"​ intermédiaire) on peut utiliser notre fonction depuis le REPL. Cela permet de la tester, ou de continuer à travailler. Souvent, un développeur Lisp garde son éditeur et son REPL ouvert pendant plusieurs jours, puisqu'​il y a rarement besoin de le redémarrer.+   * on écrit du code dans un fichier, on démarre le plugin Lisp et on connecte un REPL à son éditeur. Lorsqu'​on a écrit une fonction, on compile cette fonction avec un raccourci clavier (C-c C-c). **On a compilé dans ce cas UNE fonction**. Le compilateur Lisp nous donne s'il le faut des messages de warning: incompatibilités de types, une variable n'est pas utilisée… Si la compilation a réussi (j'​insiste:​ la fonction a été compilée, dans le cas de SBCL c'est en code machine efficient. Dans le cas de l'​implémentation CLISP ce serait du "​bytecode"​ intermédiaire) on peut utiliser notre fonction depuis le REPL. Cela permet de la tester, ou de continuer à travailler. Souvent, un développeur Lisp garde son éditeur et son REPL ouvert pendant plusieurs jours, puisqu'​il y a rarement besoin de le redémarrer.
    * si notre appel de la fonction dans le REPL échoue, nous obtenons une fenêtre de **débogueur interactif**. Dans le cas de LispWorks, c'est une fenêtre graphique facile avec des boutons. Dans le cas d'​Emacs et Slime, c'est une fenêtre en mode texte, avec un menu pour effectuer des actions. Dans ce débogueur, nous voyons le message d'​erreur,​ la pile des appels de fonction avec leurs arguments. Nous pouvons évaluer du code dans le contexte de cette erreur. Nous pouvons aller à la ligne d'où provient l'​erreur,​ la corriger, compiler le nouveau code (avec le raccourci clavier), retourner dans le débogueur, redémarrer le programme du début ou bien le redémarrer depuis un appel de fonction que l'on choisit. Le programme reprend son exécution de là où on le demande, et on peut observer son exécution finir avec succès.    * si notre appel de la fonction dans le REPL échoue, nous obtenons une fenêtre de **débogueur interactif**. Dans le cas de LispWorks, c'est une fenêtre graphique facile avec des boutons. Dans le cas d'​Emacs et Slime, c'est une fenêtre en mode texte, avec un menu pour effectuer des actions. Dans ce débogueur, nous voyons le message d'​erreur,​ la pile des appels de fonction avec leurs arguments. Nous pouvons évaluer du code dans le contexte de cette erreur. Nous pouvons aller à la ligne d'où provient l'​erreur,​ la corriger, compiler le nouveau code (avec le raccourci clavier), retourner dans le débogueur, redémarrer le programme du début ou bien le redémarrer depuis un appel de fonction que l'on choisit. Le programme reprend son exécution de là où on le demande, et on peut observer son exécution finir avec succès.
  
  • common_lisp.1676925928.txt.gz
  • Dernière modification: Le 20/02/2023, 21:45
  • par 88.166.188.193