Compilation
Jogo
Il y a-t-il quelqu'un ici...
Bon, je dￜcouvre Lisp et je suis en particulier intￜressￜ par le fait
qu'il s'agit d'un language compilable. Malheureusement je n'ai rￜussi ￜ
installer que sbcl, et il me gï¿œnï¿œre un exï¿œcutable de 26 Mo pour un
"Hello World !". N'est-ce pas un peu excessif alors que sbcl lui-mï¿œme
ne fait que 476 ko ?
--
Si les procï¿œdures de crï¿œation,
de gestion, ï¿œtaient plus simple,
plus transparente, et non pas
la chasse gardï¿œe de petit potentats,
il n'aurait jamais fait cela.
-- Benoit 4x4 dans fufe --
Pascal J. Bourguignon
> Il y a-t-il quelqu'un ici...
Oui.
> Bon, je d�couvre Lisp et je suis en particulier int�ress� par le fait
> qu'il s'agit d'un language compilable. Malheureusement je n'ai r�ussi �
> installer que sbcl, et il me g�n�re un ex�cutable de 26 Mo pour un
> "Hello World !". N'est-ce pas un peu excessif alors que sbcl lui-m�me
> ne fait que 476 ko ?
Cet executable contient tout l'environnement Lisp, y inclus un
compilateur optimisant, un interpreteur, un d�bogueur, ainsi que toute
la biblioth�que "run-time" de Common Lisp.
Si tu pense d�velopper une application (qui sera donc d�ploy�e), le
plus probable est que ces 26 Mo ne repr�senteront qu'une d�perdition
n�gligeable par rapport � la taille du code et de resources de ton
application.
Je remarque que tu ne te plainds pas de la taille de Firefox,
OpenOffice, ou de n'importe quelle autre application. Donc les
utilisateurs de tes programmes lisp ne se plaindront pas non plus de
leurs tailles.
/usr/bin/sbcl n'est pas SBCL lui-m�me. C'est ce qu'on appelle en
terminologie unix, un "driver". C'est � dire un petit programme
utilis� pour lancer un gros programme. Par exemple, gcc n'est qu'un
driver de 90 Ko. En fait, le compilateur gcc fait 387 Mo sur ma
machine. (En passant, les 24 Mo de SBCL doivent soudain semble assez
insignifiant � c�t� de ces 387 Mo, sachant que ces 24 Mo contiennent
tout le compilateur, un interpr�teur, un d�bogueur, etc, et ton petit
programme "hello world").
Ceci dit, on peut trouver que pour certains types de programmes �a
soit beaucoup. Par exemple, si on �crit plein de petit �scripts�, �a
fait un peu �g�chi�. Heureusement, il y a d'autres options:
1- on peut, comme pour les scripts bash et autres, ne garder dans
l'ex�cutable que le source lisp du script.
(Voir http://www.sbcl.org/manual/Shebang-Scripts.html)
2- on peut utiliser une impl�mentation qui g�n�re des ex�cutables plus
petits, comme CLISP. CLISP lui m�me ne fait que 4 Mo environ, donc
une image ex�cutable qui contient CLISP entier ne fera que 4 Mo
environ. http://clisp.cons.org/
3- on peut utiliser une impl�mentation qui r�side dans une
biblioth�que, comme libc pour le cas du C. Par exemple ECL.
http://ecls.sourceforge.net/
Dans ce cas, on aura un petit ex�cutable, semblable � un "hello
word" �crit en C, mais comme un programme C a besoin de grosses
biblioth�ques (8 Mo juste pour libc), ce petit programme �crit en
Lisp aura besoin de /usr/lib/ecl/libecl.so. L'avantage restant que
cette biblioth�que peut �tre partag�e par tout les ex�cutables
impl�ment�s en ECL, comme pour libc.
Mon conseil � cette �tape, c'est de ne pas trop s'inqui�ter pour ce
probl�me de deployment. Si tu prends soin de programmer en Common
Lisp portable (sans utiliser directement les extensions des diverses
impl�mentations, mais en passant par des biblioth�ques de portabilit�
(par exemple, utiliser bordeaux-threads au lieu de #+sbcl sb-thread ou
#+clisp mp, etc)), alors tu pourras facilement compiler ton programme
avec diverses impl�mentations, et donc choisir au final celle qui
convient le mieux pour un d�ployement, selon les crit�res de
d�ployement (taille de l'ex�cutable, ou rapidit� d'ex�cution). Note
bien que ces crit�res sont diff�rents de ceux que tu vas avoir pendant
l'apprentissage de Common Lisp, ou pendant le d�veloppement d'une
application, o� tu pr�f�reras une impl�mentation ayant un bon
d�bogueur et des messages d'erreurs clairs.
Mon opinion est qu'il est donc avantageux d'utiliser plusieurs
impl�mentations diff�rentes, et de programmer le plus possible en
Common Lisp strictement portable.
Donc essayes plusieurs impl�mentations, et vois laquelle te convient
le mieux dans la phase d'apprentissage, sachant que les autres te
serviront dans les phases suivantes du projet.
(Personnellement, j'utilse CLISP pour d�velopper et d�boguer, et quand
j'ai besoin d'un ex�cutable un peu plus rapide (clisp compile un
bytecode pour une machine virtuelle, comme Java pour la JVM), je
compile avec SBCL ou ECL. Mais si tu utilises emacs+slime comme IDE,
les d�ficiences du d�bogueur de SBCL (au niveau de son �interface
utilisateur�) son pali�es, et on peut aussi consid�rer l'ensemble
emacs+slime+SBCL pour le d�veloppement.)
http://cliki.net Le wiki lisp
http://paste.lisp.org Le presse papier lisp
irc://irc.freenode.org/#lisp Le clavardage lisp
news:comp.lang.lisp On manque de traffic francophone
ici parce que tout le monde est
sur comp.lang.lisp en anglais....
--
__Pascal Bourguignon__
Jogo
> Cet executable contient tout l'environnement Lisp, y inclus un
> compilateur optimisant, un interpreteur, un dï¿œbogueur, ainsi que toute
> la bibliothï¿œque "run-time" de Common Lisp.
J'avais bien compris. Je cherche justement ￜ ne pas inclure dans
l'executable l'interprï¿œteur et le dï¿œbogueur (par exemple).
> Si tu pense dï¿œvelopper une application (qui sera donc dï¿œployï¿œe), le
> plus probable est que ces 26 Mo ne reprï¿œsenteront qu'une dï¿œperdition
> nￜgligeable par rapport ￜ la taille du code et de resources de ton
> application.
Non. Mon objectif est d'implï¿œmenter un langage spï¿œcifique. Il y aura
plein de petits programmes partageant un environnement commun. Ces
programmes ne doivent pas ï¿œtre "dï¿œcompilables" trivialement.
Je me tourne vers Lisp pour cela car :
- Un "parse tree" n'est finalement qu'un ensemble de listes imbriquï¿œes.
- Les fonctions et macro de Lisp en font quasiment un mï¿œta-langage.
- Lisp est compilable.
> Je remarque que tu ne te plainds pas de la taille de Firefox,
> OpenOffice, ou de n'importe quelle autre application.
Si, je m'en plaind. Mais c'est HS ici.
> Heureusement, il y a d'autres options:
>
> 1- on peut, comme pour les scripts bash et autres, ne garder dans
> l'exï¿œcutable que le source lisp du script.
Dans ce cas-lￜ le programme n'est pas compilￜ et il est donc trop
facilement lisible (je ne suis pas fan de l'obfuscation).
> 2- on peut utiliser une implï¿œmentation qui gï¿œnï¿œre des exï¿œcutables plus
> petits, comme CLISP. CLISP lui mï¿œme ne fait que 4 Mo environ, donc
> une image exï¿œcutable qui contient CLISP entier ne fera que 4 Mo
> environ.
Quelle est la portabilitￜ du bytecode gￜnￜrￜ par CLisp ?
> 3- on peut utiliser une implï¿œmentation qui rï¿œside dans une
> bibliothï¿œque, comme libc pour le cas du C. Par exemple ECL.
> http://ecls.sourceforge.net/
> Dans ce cas, on aura un petit exￜcutable, semblable ￜ un "hello
> word" ï¿œcrit en C, mais comme un programme C a besoin de grosses
> bibliothï¿œques (8 Mo juste pour libc), ce petit programme ï¿œcrit en
> Lisp aura besoin de /usr/lib/ecl/libecl.so.
Je parie qu'il aura aussi besoin de la "grosse" libc (comme mon
helloworld de 26 Mo d'ailleur). Mais je vais explorer cette solution
aussi.
> Mon conseil ￜ cette ￜtape, c'est de ne pas trop s'inquiￜter pour ce
> problï¿œme de deployment. Si tu prends soin de programmer en Common
> Lisp portable (sans utiliser directement les extensions des diverses
> implￜmentations, mais en passant par des bibliothￜques de portabilitￜ
> (par exemple, utiliser bordeaux-threads au lieu de #+sbcl sb-thread ou
> #+clisp mp, etc)),
ￜ ce propos je me perd un peu dans les histoires de bibliothￜque.
J'aimerais par exemple utiliser Cairo...
--
Pour possￜder vraiment un bien, il faut l'avoir perdu et retrouvￜ.
- Simone de Beauvoir - La force des choses -
Pascal J. Bourguignon
> Salut et merci pour ta r�ponse rapide.
>
>> Cet executable contient tout l'environnement Lisp, y inclus un
>> compilateur optimisant, un interpreteur, un d�bogueur, ainsi que toute
>> la biblioth�que "run-time" de Common Lisp.
>
> J'avais bien compris. Je cherche justement � ne pas inclure dans
> l'executable l'interpr�teur et le d�bogueur (par exemple).
> [...]
>> Heureusement, il y a d'autres options:
>>
>> 1- on peut, comme pour les scripts bash et autres, ne garder dans
>> l'ex�cutable que le source lisp du script.
>
> Dans ce cas-l� le programme n'est pas compil� et il est donc trop
> facilement lisible (je ne suis pas fan de l'obfuscation).
Si, on peut aussi compiler les sources � deux moments:
- au moment du lancement du script avec l'option -C de clisp, mais ce
n'est pas ce que tu veux.
- au pr�alable, on peut compiler le fichier du script, obtenir un
.fas, et utiliser ce dernier fichier comme script, en ajoutant
#!/usr/bin/clisp -norc sur la premi�re ligne. Les fichiers 'objet'
de clisp, les .fas, sont en fait des fichiers texte.
----(hw.lisp)-----------------------------------------------------------
(defun hw (arguments)
(declare (ignore arguments))
(format t "~%Bonjour le monde !~%")
(values))
(hw ext:*args*)
------------------------------------------------------------------------
Tu peux le compiler avec:
----(compile.lisp)------------------------------------------------------
(defparameter *clisp* "/opt/local/bin/clisp"
"The path to the clisp implementation to use for the scripts.")
(defun compile-script (source)
(let ((cmdname (namestring
(make-pathname :host (pathname-host source)
:device (pathname-device source)
:directory (pathname-directory source)
:name (pathname-name source)
:type nil
:version nil
; :defaults nil
:case :local))))
(multiple-value-bind (fasfile warningp failurep) (compile-file source)
(unless failurep
(with-open-file (script cmdname
:direction :output
:if-does-not-exist :create
:if-exists :supersede)
(format script "#!~A -norc -E iso-8859-1 -Kfull~%" *clisp*)
(with-open-file (fasl fasfile)
(loop
:for line = (read-line fasl nil nil)
:while line
:do (write-line line script))))
(ext:shell (format nil "chmod 755 ~S" cmdname))
(format *trace-output* "~&;; Created script ~S~%" cmdname)))))
------------------------------------------------------------------------
C/USER[4]> (load"compile.lisp")
;; Loading file compile.lisp ...
;; Loaded file compile.lisp
T
C/USER[5]> (compile-script #P"hw.lisp")
;; Compiling file /Users/pjb/src/lisp/encours/clisp/script-example/hw.lisp ...
;; Wrote file /Users/pjb/src/lisp/encours/clisp/script-example/hw.fas
0 errors, 0 warnings
;; Created script "hw"
NIL
C/USER[6]> (ext:shell "ls -l")
total 17
-rw-r--r-- 1 pjb staff 1414 Nov 28 12:27 compile.lisp
-rwxr-xr-x 1 pjb staff 1044 Nov 28 12:28 hw
-rw-r--r-- 1 pjb staff 994 Nov 28 12:28 hw.fas
-rw-r--r-- 1 pjb staff 151 Nov 28 12:28 hw.lib
-rw-r--r-- 1 pjb staff 120 Nov 28 12:27 hw.lisp
NIL
C/USER[7]> (ext:shell "hw")
Bonjour le monde !
NIL
C/USER[8]>
>> 2- on peut utiliser une impl�mentation qui g�n�re des ex�cutables plus
>> petits, comme CLISP. CLISP lui m�me ne fait que 4 Mo environ, donc
>> une image ex�cutable qui contient CLISP entier ne fera que 4 Mo
>> environ.
>
> Quelle est la portabilit� du bytecode g�n�r� par CLisp ?
Elle est sp�cifique � clisp, et m�me � chaque version de clisp. Et je
ne suis pas sur qu'il soit possible d'ex�cuter sur MS-Windows un
byte-code compil� sur Linux. Le mieux est vraiment de distribuer des
sources.
>> Mon conseil � cette �tape, c'est de ne pas trop s'inqui�ter pour ce
>> probl�me de deployment. Si tu prends soin de programmer en Common
>> Lisp portable (sans utiliser directement les extensions des diverses
>> impl�mentations, mais en passant par des biblioth�ques de portabilit�
>> (par exemple, utiliser bordeaux-threads au lieu de #+sbcl sb-thread ou
>> #+clisp mp, etc)),
>
> � ce propos je me perd un peu dans les histoires de biblioth�que.
> J'aimerais par exemple utiliser Cairo...
Pas de probl�me. Il suffit, comme en C, d'avoir des "fichier ent�tes"
d�finissant l'interface avec la biblioth�que.
Bon, les programmeurs C l'ont un peu plus facile, car en g�n�ral ces
fichiers ent�tes sont fournis en C avec la biblioth�que. Dans le cas
de lisp, on a une biblioth�que d'interfaces de biblioth�ques
pr�d�finis, (http://cliki.net/Library), et si tu veux utiliser une
biblioth�que qui n'a pas encore d'interface lisp d�fini, tu peux le
faire avec CFFI (http://cliki.net/CFFI).
Dans le cas de Cairo, un interface CFFI pour Cairo a d�j� �t� d�fini:
http://cliki.net/cffi-cairo
--
__Pascal Bourguignon__
Christian Jullien
Tu peux aussi utiliser d'autres Lisp ou Scheme qui compilent des .exe
standalone nettement plus petits.
OpenLisp (www.eligis.com le mien qui est 100% compatible avec la norme
ISLISP 13816) compile par exemple tous les tests de Gabriel (fameux
benchmarcks Lisp) en un vrai ex�cutable (pas de bytecode) qui fait moins
d'1Mo. Comme en C/C++, il produit un ex�cutable et rien d'autre � charger.
C:\usr\jullien\openlisp\cbench>dir *.exe
Directory of C:\usr\jullien\openlisp\cbench
21/11/2009 16:18 888 832 ntgabrielmta32.exe
Mais ISLISP n'est pas Common Lisp et la version gratuite d'OpenLisp n'a pas
le compilateur.
A ma connaissance, tu ne trouveras pas de versions de Lisp id�ale, chacune a
des avantages et des inconv�nients. A toi de te faire une religion et de
choisir la version qui te convient le mieux entre vitesse, environnement,
prix, production d'ex�cutables portabilit�, code source, support,...
Christian
"Jogo" <jo...@matabio.net> wrote in message
news:20091125003757...@matabio.net...
> Bonjour,
>
> Il y a-t-il quelqu'un ici...
>
> Bon, je d�couvre Lisp et je suis en particulier int�ress� par le fait
> qu'il s'agit d'un language compilable. Malheureusement je n'ai r�ussi �
> installer que sbcl, et il me g�n�re un ex�cutable de 26 Mo pour un
> "Hello World !". N'est-ce pas un peu excessif alors que sbcl lui-m�me
> ne fait que 476 ko ?
>
> --
> Si les proc�dures de cr�ation,
> de gestion, �taient plus simple,
> plus transparente, et non pas
> la chasse gard�e de petit potentats,