hocwp a écrit 331 commentaires

Peut-être DVTM : http://www.brain-dump.org/projects/dvtm/

sans nécessité de lignes de commande (dommage : c'est notre force selon moi)

Rien t'empêche de l'utiliser et tu peux remplacer les briques qui ne te conviennent pas de manière relativement simple.

Pareil, le Paradigms of Artificial Intelligence Programming (PAIP) est vraiment génial et effectivement une référence pour un Lisper.

Perso, un fauteuil profond avec les genoux légérement relevés et une petite tablette (2cm) pour avoir de la place pour poser tout le bazard à l'aise. Mais c'est vrai qu'il faut toujours un peu baisser la tête. (Cool un troll fauteuil :) )

Mauvais canapé/fauteuil/lit changer canapé/fauteuil/lit.

Et qui sait générer du javascript : parenscript

Je ne l'ai pas utilisé non plus et c'est pour ça que j'ai regardé le CVS. L'indication du CVS qui bouge permet quand même de savoir s'il y a quelqu'un derrière le code pour assurer la maintenance en cas de bugs/problèmes (au cas où).
Sinon l'anecdote est très bonne :)

> Le but de guile est de devenir le langage officiel de script de tous les logiciels GNU.
> Et c'est pas gagné...
Enfin, à la base, il était prévu de faire des convertisseurs de differents langages vers Scheme/Guile. Mais ça n'est pas encore effectif.

"One of the goals of Guile is to allow other languages to be translated into Scheme and thence into portable byte-code; thus Guile would effectively be a language-neutral runtime environment. This goal has not been fulfilled yet, though various attempts have been made: a dialect of Scheme essentially differing only in its C-like syntax; a translation of Emacs Lisp; a Tcl converter motivated by tkWWW; and something roughly resembling the Logo programming language."

Source : http://en.wikipedia.org/wiki/GNU_Guile

Il existe aussi js2scheme mais ça n'a vraiment pas l'air très actif (7 ans depuis la plupart des derniers commits) : http://sourceforge.net/projects/js2scheme/

Ce qui n'est pas facilité quand ils sont dans une fenêtre en 100x100 pixels qu'on ne peut pas redimensionner...

Il n'y a rien en effet dans l'Hyperspec et effectivement, chaque implémentation a fait sa propre API.
Par contre il existe des fines couches pour standardiser l'API à travers toutes les implémentations.
Une des plus utilisée étant les bordaux-threads : http://common-lisp.net/project/bordeaux-threads/

Ah, ok, merci pour la précision. Bon, alors la macro pour ne comparer que quelques champs ressemble à un truc comme ça :
(defmacro fields-equal (a b &rest fields)
  `(and ,@(loop for f in fields
                collect `(equal (,f ,a) (,f ,b)))))

(defstruct toto a b c x y z)

(defparameter objet1 (make-toto :a 10 :b 20 :c "plop" :x 'plop :y 10.5 :z 10))
(defparameter objet2 (make-toto :a 10 :b 50 :c "plop" :x 'plop :y 10.5 :z 1001))

(fields-equal objet1 objet2 toto-a toto-c toto-y) => T
(fields-equal objet1 objet2 toto-a toto-c toto-y toto-z) => NIL

(macroexpand-1 '(fields-equal objet1 objet2 toto-a toto-c toto-y toto-z))
=> (AND (EQUAL (TOTO-A OBJET1) (TOTO-A OBJET2))
        (EQUAL (TOTO-C OBJET1) (TOTO-C OBJET2))
        (EQUAL (TOTO-Y OBJET1) (TOTO-Y OBJET2))
        (EQUAL (TOTO-Z OBJET1) (TOTO-Z OBJET2)))

Évidement, on peut l'améliorer pour ne pas avoir à taper toto-*. On peut aussi imaginer faire la comparaison entre deux objets de structures différentes partageant des champs en commun (amis du type fort, bonjour :-) ).. Mais je ne suis pas sûr que ce soit vraiment judicieux.

En Common Lisp, si tu veux comparer l'égalité entre deux structures :
> (defstruct toto x y z)
> (defparameter a (make-toto :x 10 :y 20 :z 10))
> (defparameter b (make-toto :x 10 :y 20 :z 10))
> (equalp a b) => T

Si on ne veux comparer que quelques champs, on peut écrire une petite macro qui va générer l'arbre if/else à notre place à la compilation. Et on pourra écrire un truc du genre :
> (fields-equal a b :x :z) => T
Bon je sors, j'ai un petit tutoriel à lire http://lisperati.com/haskell/ :-)

Ben oui, il en faut bien un :)
Sinon, tu as un clone pour vim qui se prépare. Je ne sais pas ce que ça donne.

https://github.com/hsitz/VimOrganizer

emacs+orgmode peut-être. Il permet de classer et organiser des items. Par contre il te faudra plus de doigts et peut-être pas mal de temps pour le prendre en main.

http://orgmode.org

Au cas ou tu aurais envie d'aventure : conçu à la base pour avoir les applications en plein écran sans fioritures (c'est quoi un fond d'écran ?)

http://common-lisp.net/project/clfswm

> une option de X pour que clic droit+gauche en même temps simule le bouton du milieu.
On peut aussi associer une touche au clic du milieu en ajoutant 'keycode ... = Pointer_Button2' dans le ~/.xmodmap : c'est vachement pratique avec les touchpads.

- Emacs
- clfswm :-]
- uzbl

C'est sûr que ce n'est pas un mode de fonctionnement courent sous Windows/MaxOS.

Je ne sais pas si c'était ton intention, mais ce serait très intéressant d'avoir un retour sur ce que tu as fais et si tu es arrivé à corriger tas bourde.
Je n'ai pas encore eu de plantage avec gparted mais ça pourra donner des idées en cas de problème.

Je croyais quelle était pour le 12/12/1212...

De même, merci pour le site.

Ben oui, on test tout en même temps : affichage, temps de chargement, algorithme en lui même... C'est pour ça que ce test ne veux pas dire grand chose il donne juste une petite indication sur le langage.

> à noter qu'il y a un appel à sorted inutile dans mon code python, scorie pas nettoyée d'une version intermédiaire.
Oui. Sans le tri, on obtient 0.068s au lieu de 0.073s

Correction le Lisp n'est pas si perdant que ça à condition de lui compiler le code avant. Ce que j'ai fais avec les dernières mesures que j'ai donné au dessus.
En deux passes:
$ sbcl
Lisp> (compile-file "toto.lisp")
$ time sbcl --noinform --load toto.fasl
On obtient les temps donnés ici par exemple : http://linuxfr.org/comments/1142006.html#1142006

Merci beaucoup. Sur ma machine, j'obtiens

Pour 10000 éléments : 0.049s en Ocaml, 0.039s en Lisp, 0.058 en C et 0.017 en C(O3)
Pour 100000 éléments : 0.674s en Ocaml, 0.531s en Lisp, 0.799s en C et 0.412s en C(O3)
Pour 1000000 éléments : 41.512s en Ocaml, 41.483s en Lisp, 43.523s en C et 43.449s

Pour 10000000 éléments sans la boucle x100:
Fatal error en Ocaml, 5.480s en Lisp et segfault en C

Petite précision : ceci est fait sans la boucle fois 100. Le programme prend déjà assez de temps comme ça.