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.
<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.
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 :
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.
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 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.
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 !
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
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, 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.
(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.
Oui exactement, je crois que s'ils ne poussaient pas à la consomation, avec un systeme plus souple, je me servirai encore de mon portable et donc je leur rapporterai encore quelque chose alors que pour l'instant c'est niet !
J'ai eu une mobi carte pendant un temps parce que je ne me servais pas regulierement de mon portable.
Au debut c'etait pas trop mal, puis les tarifs ont augmentés : 10¤ à utiliser dans les 15 jours ou 20¤ dans les deux mois.
Dans le bureau de tabac où j'ai acheté ma derniere mobi carte, ils n'avaient plus que des cartes à 20¤. J'en ai acheté une (j'avais besoin de telephoner) mais je ne me suis servis que de 2¤ dans les deux mois => 18¤ donnés à FT... Depuis mon portable est gentilment rangé dans un tiroir et il n'a plus de numero attribué : le coup de fil est _beaucoup_ trop cher et leur politique commerciale ma dégouté !
[^] # Re: ligne de commande
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de K3b 1.0. Évalué à -2.
[^] # Re: ligne de commande
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de K3b 1.0. Évalué à 1.
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.
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 3.
Pour le rapprochement XML/lisp, j'utilise souvent la fonction suivante :
Ce qui permet de faire :
qui produit :
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 :)
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 0.
> 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...).
[^] # Re: pourquoi le lisp
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 1.
[^] # Re: long a apprendre ?
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 2.
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
[^] # Re: Elle est en partie dans le domaine publique et sous licence BSD.
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 2.
[^] # Re: Clos ?
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 2.
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...).
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 2.
http://www.ocf.berkeley.edu/~tfb/misc/lp90.pdf
http://common-lisp.net/project/mcclim/
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 1.
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
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 3.
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 6.
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
[^] # Re: Quelques commentaires
Posté par hocwp (site web personnel) . En réponse au journal Python 2.5 beta 2. Évalué à 3.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 1.
(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.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
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(...)
Oui, je crois que ça resume bien la situation.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
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.
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par hocwp (site web personnel) . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 4.
(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 --> [ ][^] # Re: pc-selection-mode
Posté par hocwp (site web personnel) . En réponse au message Copier coller emacs. Évalué à 1.
Après tu selectionnes avec les flèches de direction et Control/Shift Inser pour copier-coller.
# pc-selection-mode
Posté par hocwp (site web personnel) . En réponse au message Copier coller emacs. Évalué à 1.
M-x pc-selection-mode
=> Control - Inser : copier
Shift - inser : coller
[^] # Re: Ce que tu cherches ...
Posté par hocwp (site web personnel) . En réponse au journal Choisir un environnement de dev pour y écrire un plugin. Évalué à 2.
[^] # Re: Troll
Posté par hocwp (site web personnel) . En réponse à la dépêche Chasse aux bugs ouverte pour Vim 7.0. Évalué à 3.
http://www.sunsite.ualberta.ca/Documentation/Gnu/emacs-20.7/(...)
[^] # Re: Gentoo/FreeBSD-6.0
Posté par hocwp (site web personnel) . En réponse à la dépêche Gentoo 2006.0 est disponible. Évalué à 5.
http://hurd.rustedhalo.net/about.php
[^] # Re: bêêêê....
Posté par hocwp (site web personnel) . En réponse au journal FT, les portables et moi. Évalué à 4.
[^] # Re: bêêêê....
Posté par hocwp (site web personnel) . En réponse au journal FT, les portables et moi. Évalué à 8.
Au debut c'etait pas trop mal, puis les tarifs ont augmentés : 10¤ à utiliser dans les 15 jours ou 20¤ dans les deux mois.
Dans le bureau de tabac où j'ai acheté ma derniere mobi carte, ils n'avaient plus que des cartes à 20¤. J'en ai acheté une (j'avais besoin de telephoner) mais je ne me suis servis que de 2¤ dans les deux mois => 18¤ donnés à FT... Depuis mon portable est gentilment rangé dans un tiroir et il n'a plus de numero attribué : le coup de fil est _beaucoup_ trop cher et leur politique commerciale ma dégouté !