hocwp a écrit 331 commentaires

Ça me rappelle les joies des premiers programmes en basic. Les programmes tapés tels quels depuis un bouquin sans trop comprendre tous les détails. Le lecteur de cassettes où le chargement foirait une fois sur deux parce qu'on avait bougé la bécane. Mais après que de parties de Monster
( http://enfr.explicatus.org/wiki/3D_Monster_Maze ).
Et il ne fallait surtout pas toucher à la RAM sous peine de faire planter le tout. Il est toujours dans le garage de mon père dans sa jolie boite en bois. Je ne sais pas s'il marche encore.

Pour ceux qui voudraient voir à quoi ça ressemblait :

http://rus.members.beeb.net/z81.html

avec la rom qui va bien :
ftp://ftp.nvg.ntnu.no/pub/sinclair/roms/zx81.rom

> Bref, si on veux un Linux Desktop, il est peut être temps de remettre en question certaines pratiques de temps à autres...

Boh, de toute façon je ne suis pas prêt pour le Desktop :)

Oh, non ce genre de script n'a rien à faire dans une distrib parce que
(1) je l'ai fais dans un but très precis pour un besoin très précis qui a très peu de chance d'être le même pour quelqu'un d'autre (mais il me convient parfaitement).
(2) Je ne l'ai pas polissé pour quelqu'un d'autre (c'est moi qui l'ai fait pour moi : je sais comment il marche et comment m'en servir, ce ne sera pas forcement le cas de quelqu'un d'autre et il faudra qu'il lise le script).
(3) Il est tout petit et pas du tout générique pour un autre usage et je n'ai pas l'intention d'ajouter des options pour d'autres besoins.
D'ailleurs d'autres l'ont déjà fait (cf burn, mp3burn, mp3cd entre autres) mais il me faudra de toutes façons scripter ces scripts pour arrivé au même resultat que mon vieux petit script.

Il s'agit effectivement de CD différents dont je planifie la gravure. Il suffit d'indiquer où ce trouve les répertoires à graver et la seule interaction par la suite est d'appuyer sur entrée après avoir changé le CD.
Et pour la jaquette ? C'est une vraie question, à l'époque où j'ai fait ces scripts je n'avais pas trouvé d'interface graphique qui permettaient de tout faire de maniere simple (c'est à dire avec le minimum d'interactions avec le logiciel) pour graver plusieurs CD d'affilé.

Et bien je fais de la place ou je deplace les fichiers ou je fais des liens ou je vais chercher un autre outil (K3b par exemple).
Et toi tu fais comment quand tu as 10 cd à graver d'affilé et que tu veux éditer la jaquette du cd en même temps ? Je n'est juste qu'à appuyer sur entrée entre 2 cds (celui-ci étant automatiquement éjecté/refermé et la jaquette imprimée).

Je ne cherche pas à me faire mousser, je dis juste que pour mon usage courant un script est suffisant et plus simple que toutes les interfaces graphiques que j'ai essayé. Je ne parle pas de ma soeur ou du copain, ils choisissent les outils qui leur conviennent (et c'est surement le cas de k3b).

Je crée un nouveau repertoire, je copie avec un gestionnaire de fichier par glisser/déposer ce que je veux dedans et je demande de graver le repertoire.

Je trouve aussi que la ligne de commande est plus pratique.
J'ai 3 petits scripts:
burn_dir -> converti tout les fichiers audio (mp3, ogg...) en wav et grave un CD audio et au passage produit la playlist avec cdlabelgen.
burn_dir_data -> grave les données du repertoire telles quelles
burn_iso -> grave l'image iso

Ils n'ont qu'une seule option chacun qui permet de blanchir le CD avant de le graver.

Pour mon usage je trouve ça très simple et je n'est pas reussi a me faire aux interfaces graphiques ou il faut fouiller dans les options ou les menus à chaque fois. Enfin c'est une question de gouts.

Bien par exemple sur les deux exemples suivants il n'y a pas beaucoup de différences entre la version lisp et la version python

def   test   (x):                     (defun   test   (x)
        y   =   "toto"                       (let   ((y   "toto"))
        print   x                                 (print   x)
        print   y                                 (print   y)))

test   (10)                             (test   10)

Pour le rapprochement XML/lisp, j'utilise souvent la fonction suivante :

(defun produce-html (tree &optional (level 0) (stream *standard-output*))
  (cond ((listp tree)
    (print-space level stream)
    (format stream "~(<~A>~)~%" (first tree))
    (dolist (subtree (rest tree))
      (produce-html subtree (+ 2 level) stream))
    (print-space level stream)
    (format stream "~(</~A>~)~%"
            (if (stringp (first tree))
                (subseq (first tree) 0 (position #\Space (first tree)))
                (first tree))))
   (t
    (print-space level stream)
    (format stream (if (stringp tree) "~A~%" "~(~A~)~%") tree))))

Ce qui permet de faire :

(produce-html
 '(html
   (head
    (title "Un titre"))
   (body (h1 "Le titre")
    (p "plop plop" "Bla bla"
     ("a href=\"http://toto.org\"" "mon url")))))

qui produit :

<html>
  <head>
    <title>
      Un titre
    </title>
  </head>
  <body>
    <h1>
      Le titre
    </h1>
    <p>
      plop plop
      Bla bla
      <a href="http://toto.org">
        mon url
      </a>
    </p>
  </body>
</html>

Je m'en suis servi pour générer automatiquement la doc de clfswm à partir des tables de hashage des touches et de la documentation des fonctions ( http://hocwp.free.fr/clfswm/keys.html ). En lisp ce n'est pas la peine d'aller chercher des outils extérieur comme doxygen ou autre. Tout est déjà dans le langage.

Pour le reste, c'est effectivement tout sauf objectif. Chacun ses goûts :)

> > Demandez donc l'avis d'un programmeur Lisp sur la syntaxe de Ruby, Java, C#, Python, etc..

> Pas facile: je n'en connais pas!

De ce que j'ai testé, les parenthèses sont en général plus accessibles que les { } [ ] # @.
Ensuite chaque groupe de parenthèses délimite un bloc qui est très facilement manipulable.

exemple: (ma-fonction (prend "toto") (donne "titi"))

tu peux manipuler et déplacer facilement les blocs que sont les fonctions ma-fonction, prend et donne. Il suffit de prendre les parenthèses.

D'autre part, on indente en général le code. Ce qui fait dire à certain qu'on se retrouve à écrire en python si on enlève les parenthèses.
Donc on fait assez vite abstraction des parenthèses et on se fie à l'indentation. Les parenthèses étant là pour vérifier le groupement s'il y a lieu. D'ailleurs certains éditeurs permettent de mettre les parenthèses dans une couleur très discrète comme le gris clair sur du blanc.

Par contre si on enlève les parenthèses on perd la correspondance code<->donnée et la flexibilité des macros.
Comme exemple, un fichier de configuration en lisp est aussi simple que :

Écriture : (print '(defparameter ma-variable 10) fichier-de-conf)

Le fichier de configuration contient : (defparameter ma-variable 10)

Lecture : (load fichier-de-conf)

Le (defparameter ma-variable 10) est une donnée en écriture mais est un bout de code qui est exécuté en lecture .
(ma-variable prend la valeur 10 quand le fichier de conf est chargé).

Donc j'ai du mal à recoder en C ou dans un autre langage parce qu'il me manque toujours des facilités apportées par la syntaxe du Lisp (et je ne parle que de la syntaxe...).

En géneral qu'en tu écris une fonction/macro comme le while en lisp tu test cette fonction depuis la boucle d'évaluation jusqu'à ce quelle fasse exactement ce que tu veux. Et ensuite tu peux utliser le while comme toute autre fonction sans différence et t'appuyer dessus parce qu'elle aura était testée (quitte à le restester avec d'autres arguments plus tard). Mine de rien ce mode de développement reduit pas mal le risque de bug.

En fait le noyau du Common Lisp ne doit pas être beaucoup plus gros que celui du scheme.

Par contre pour être qualifié d'implémentation du Common Lisp, il faut gérer en standard les objets (CLOS), les structures, les conditions (error, assert, throw/catch...), les packages, les nombres, les sequences, les tableaux, les tables de hachage, les nom de fichiers portables sur plusieur systemes, les flux...

Tout ceci est dans le standard et doit fonctionner de la même manière quelque soit l'implémentation. Ce qui fait que la référence est beaucoup plus grosse que celle du scheme. Par contre tu peux ainsi passer d'un systeme et d'une implémentation à une autre et ton programme _doit_ fonctionner de la même manière.

Donc ce n'est pas long à apprendre. Quand tu as besoin de quelque chose, tu vas le chercher d'abord dans la réference avant de le réinventer. Il ne faut pas chercher à tout ingurgiter d'un seul coup.

http://www.lisp.org/HyperSpec/FrontMatter/Chapter-Index.html

Je me suis relu et fais relire. Celle-ci est passée au travers des mailles du fillet. Désolé de t'avoir énervé...

Si tu parles de l'implémentation clisp du Common Lisp, oui il y a eu des avancées depuis un certain temps dans la gestion du Meta-Object Protocol (MOP) qui respecte plus le standard.
Sinon, toutes les implémentation tendent vers un support du CLOS/MOP et à part GCL qui est en retard, toutes les autres le supporte correctement (CMUCL, CLISP, SBCL, ECL, OpenMCL...).

J'ai utilisé le guided tour qui est dans la doc et les exemples qui viennent avec McCLIM. Et bien sur la reference et pas mal de google.

http://www.ocf.berkeley.edu/~tfb/misc/lp90.pdf
http://common-lisp.net/project/mcclim/

J'ai beaucoup aimé les livres de Paul Graham ANSI Common Lisp pour débuter puis On Lisp qui est plus ardu mais très impressionnant.
Le Paradigms of Artificial Intelligence Programming (PAIP) de Peter Norvig qui est tout aussi impressionnant même si on ne veut pas faire de l'IA.

Et un point d'entrée cité habituellement est le très bon livre de Peter Siebel.

http://www.gigamonkeys.com/
http://www.paulgraham.com/acl.html
http://www.paulgraham.com/onlisp.html
http://norvig.com/paip.html

Moui, enfin entre se tordre les doigts pour faire des { } [ ] # , ; et manipuler des parenthèses (que tout bon éditeur indente et repère très bien) et ainsi manipuler des blocs de code extrêmement facilement, il y a un choix à faire :-)

Pourquoi le lisp ? Pour moi parce que c'est souple, simple, efficace et ça me permet de faire tout ce que je veux de mon ordinateur.
Certaines implémentations du Lisp supportent l'utf8 (1). ll supporte le XML (2), la programmation par contrats (3) (je n'est pas testé). Et les expressions régulières. Par exemple les regexps du perl sont compilées en code natif (assembleur) donc elles sont extrêmement rapides.

Pour ce qui est de l'entreprise, je ne suis pas informaticien, donc je ne sais pas...

Par contre j'ai pu faire mon propre gestionnaire de fenêtres (4) en un mois en lisant le code de plusieurs autres projets. L'argument qu'un code en Lisp est illisible est pour moi completement faux.
Ca m'a permis de faire un éditeur de sons (5) exactement comme je le voulais. Un lecteur de mail avec filtre anti spam (6), de la 3D (7), un jeu de tarot distribué (client/serveur) (8)...

Sinon, j'avais déjà parlé de ce sujet auparavent (9).

Et je suis tout à fait satisfait de ce langage pour ce que je veux faire !

(1) http://clisp.cons.org/propaganda.html
(2) http://www.cliki.net/CL-XML
(3) http://www.gauss.muc.de/tools/dbc/dbc-intro.html
(4) http://hocwp.free.fr/clfswm/
(5) http://common-lisp.net/project/cl-wav-synth/
(6) http://hocwp.free.fr/glmf/article_clmail/clmail-v2/
(7) http://hocwp.free.fr/ah2cl/ (à la fin)
(8) http://www.nongnu.org/maitretarot/ (dans le cvs)
(9) https://linuxfr.org/~Montaigne/20315.html#661910

Ca ressemble très fortement au with du Common Lisp :

(with-open-file (f "/etc/fstab" :direction :ouput)
  (write-line "..." f))

Le fichier est ouvert et automatiquement fermé à la sortie de la macro avec la garantie qu'il soit fermé même si une erreur survient (open/close entouré d'un unwind-protect). http://www.lisp.org/HyperSpec/Body/mac_with-open-file.html

Comme quoi le choix de l'algorithme est parfois (beaucoup) plus important que le langage. :)

Bien la première chose que je vois c'est qu'avec la version memoïzée pour calculer fib(1001), il suffit d'ajouter fib(1000) et fib(999) qui ne sont pas des appels recursifs et qui sont déjà stockés dans la table de hachage si on a calculer fib(1000) auparavant.

(Pour le code indenté: texte avec du html sans retour chariot + balise <pre>code</pre>).

Sinon, effectivement, désolé pour le bruit : on s'éloigne du sujet.

Ce qui est fou, c'est qu'apparement l'interpreteur LISP a déjà compris lors du premier appel que c'est un appel "tail recursive" au vu de tes temps d'execution. Si c'est le cas et sans directives, je suis vraiment épaté.

En fait, tu commences par calculer fib(999), puis pour calculer fib(999) tu calcules fib(998), etc, etc -> tu ne descends qu'un fois pour calculer chaque valeur de fib jusqu'à 1 et ensuite tout ce que tu calcules est déjà stocké dans la table de hachage => gain de temps là où normalement tu devrais calculer chaque valeur à chaque fois en remontant.

Sinon, niveau optimisation, je n'ai rien rajouté (juste compilé chaque fonction).
Par contre, sans la mémoization, fib(44) met environ 80 secondes sur ma machine avec la version recursive de base (je n'ai pas encore eu le temps de tester la version avec une boucle) et j'ai arrété fib(1000) ;-)

Pour la notation infix, j'en ai déjà parlé ici, mais tu as des macros qui te permettent de faire tes calculs dans cette notation, et c'est le compilateur qui se charge de les transformer en notation prefix avec de les évaluer.
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/l(...)

A chaque cas sa solution, et je crois que c'est un peu l'esprit qui se dégage sur cette news.

Oui, je crois que ça resume bien la situation.

Oui, tout à fait : c'est joli mais ça ne sert pas tout les jours :)
Par contre, je pense que ça peut servir de savoir qu'on a ce genre d'outil à portée de main sans rien changer au code de base (enfin, en Lisp en tout cas et à condition qu'il soit purement fonctionnel).

Sinon, du point de vue mémoire, entre stocker 1000 entiers dans une hash table et refaire un très grand nombre de fois le même calcul, le choix est vite fait à mon avis.

Tiens, pour s'amuser, en Lisp :

(defun fib (n)
  (if (<= n 1) 1
      (+ (fib (- n 1)) (fib (- n 2)))))

(defun memo (fn)
  (let ((table (make-hash-table)))
    #'(lambda (x)
	(multiple-value-bind (val found-p)
	    (gethash x table)
	  (if found-p
	      val
	      (setf (gethash x table) (funcall fn x)))))))

(defun memoize (fn-name)
  (setf (symbol-function fn-name) (memo (symbol-function fn-name))))

CL-USER> (memoize 'fib)
#<CLOSURE (LAMBDA (X)) {A748FC5}>

CL-USER> (time (fib 1000))
Evaluation took:
  0.002 seconds of real time
  0.001999 seconds of user run time
  0.0 seconds of system run time
  0 page faults and
  135,064 bytes consed.
7033036771142281582183525487718...

CL-USER> (time (fib 1000))    ; 2eme appel -> instantané
Evaluation took:
  0.0 seconds of real time
  0.0 seconds of user run time
  0.0 seconds of system run time
  0 page faults and
  0 bytes consed.
7033036771142281582183525487718...

Comme quoi le choix de l'algorithme est parfois (beaucoup) plus important que le langage. /me range sont PAIP, enfonce des portes ouvertes et --> [ ]

La notation standard d'emacs est M-x pour : touche Alt et x appuyées en même temps. Puis après tu tapes pc-selection-mode (ou pc- et touche TAB pour l'autocompletion) .

Après tu selectionnes avec les flèches de direction et Control/Shift Inser pour copier-coller.