Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
common_lisp [Le 11/01/2024, 11:56] 90.65.241.102 [Les éditeurs] |
common_lisp [Le 10/08/2025, 00:43] (Version actuelle) 93.8.28.16 [Logiciels liés à Common Lisp] lien vers Lem, pas son wiki |
||
---|---|---|---|
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. | ||
Ligne 151: | Ligne 151: | ||
* [[https://sourceforge.net/projects/maxima/files/|Maxima]] (et son [[https://wxmaxima-developers.github.io/wxmaxima/|interface graphique Wxmaxima]]) est un "Computer Algebra System". | * [[https://sourceforge.net/projects/maxima/files/|Maxima]] (et son [[https://wxmaxima-developers.github.io/wxmaxima/|interface graphique Wxmaxima]]) est un "Computer Algebra System". | ||
* [[https://kandria.com/|Kandria]] est un jeu de plateforme publié sur Steam. | * [[https://kandria.com/|Kandria]] est un jeu de plateforme publié sur Steam. | ||
- | * [[https://github.com/lem-project/lem/wiki|Lem]] est un éditeur de texte écrit in Common Lisp, qui fonctionne avec un grand choix de langages grâce à son client LSP (Language Server Protocol). Il est prêt à l'emploi pour Common Lisp. | + | * [[https://github.com/lem-project/lem/|Lem]] est un éditeur de texte écrit in Common Lisp, qui fonctionne avec un grand choix de langages grâce à son client LSP (Language Server Protocol). Il est prêt à l'emploi pour Common Lisp. |
Pour plus, voir les liens ci-dessous. | Pour plus, voir les liens ci-dessous. |