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."
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)))))
É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/ :-)
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.
> 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.
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.
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
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
Bon voila en poussant un peu plus loin le nombre d'éléments.
Avec le 2eme algorithme :
Pour 100000: Lisp = 0.005s C = 0.009s C(O3) = 0.006s
Pour 1000000: Lisp = 0.409s C = 0.432s C(O3) = 0.407s
Pour 10000000: Lisp = 5.469s C = Segmentation fault (normal à cause des indices du tableau)
Pour 100000000: Lisp = 68.193s C = Segmentation fault
Pour 1000000000: Lisp = Plein de warning à la compilation : on atteint la limite de l'implémentation actuelle et des fixnum qui est à 536870911.
Je n'ai rien changer au code en Lisp (juste incrémenté nb-entries). Pour le code en C, je pense qu'il faut passer au malloc à la main et changer le type des indices.
Sinon, voila les derniers nombres amis trouvé avec 100000000 éléments testés :
C'est ça qui est rigolo : on s'extasie sur le premier algo avec le javascript plus rapide que le python, puis le Lisp plus rapide que les 2. Et tout le monde est mis d'accord avec un changement d'algo qui place le python en 1er loin devant les autres. Et enfin le Lisp et le C qui se tire la bourre laissant le python derrière.
Tout ça pour dire que l'algo est vraiment le point central !
Bon ben avec O3, j'ai la même chose que sans pour la première version de l'algo.
Par contre pour le deuxième algo je passe de 0.058 à 0.017. La version en Lisp reste à 0.038 donc elle se place entre le C sans optimisation et le C avec optimisation.
J'ai rajouté une boucle dans l'algo parce que j'était curieux de voir la vitesse du langage et non la vitesse à laquelle il se lance. D'ailleurs sur ce terrain là le Lisp est clairement perdant. Mais bon, la REPL permet de compenser ce temps de démarrage.
[^] # Re: À quand
Posté par hocwp (site web personnel) . En réponse à la dépêche Agrémentez votre JavaScript avec CoffeeScript 1.0. Évalué à 1.
Sinon l'anecdote est très bonne :)
[^] # Re: À quand
Posté par hocwp (site web personnel) . En réponse à la dépêche Agrémentez votre JavaScript avec CoffeeScript 1.0. Évalué à 1.
> 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/
[^] # Re: Les chinois du FBI...
Posté par hocwp (site web personnel) . En réponse au journal Backdoor dans OpenBSD ?. Évalué à 5.
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par hocwp (site web personnel) . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 1.
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/
[^] # Re: typage mou
Posté par hocwp (site web personnel) . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 1.
(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.
[^] # Re: typage mou
Posté par hocwp (site web personnel) . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 1.
> (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/ :-)
[^] # Re: Emacs + orgmode
Posté par hocwp (site web personnel) . En réponse au message Comment classer ses idées efficacement?. Évalué à 1.
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
Posté par hocwp (site web personnel) . En réponse au message Comment classer ses idées efficacement?. Évalué à 6.
http://orgmode.org
# clfswm
Posté par hocwp (site web personnel) . En réponse au message WM sans bureau et sans barre de tâche. Évalué à 1.
http://common-lisp.net/project/clfswm
[^] # Re: Professionels
Posté par hocwp (site web personnel) . En réponse au journal Le HP Mini 1103 est bientôt de sortie. Évalué à 2.
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.
# Moi moi moi
Posté par hocwp (site web personnel) . En réponse au journal Softs qui déchiraizent \o/. Évalué à 1.
- clfswm :-]
- uzbl
C'est sûr que ce n'est pas un mode de fonctionnement courent sous Windows/MaxOS.
# Retour et conclusion
Posté par hocwp (site web personnel) . En réponse au message plantage pendant redimentionnement NTFS. Évalué à 1.
Je n'ai pas encore eu de plantage avec gparted mais ça pourra donner des idées en cas de problème.
[^] # Re: La fin du monde n'est pas pour le 12 décembre 2012
Posté par hocwp (site web personnel) . En réponse à la dépêche La pénurie d'adresse IPv4 sera-t-elle pour le 12/12/2012 ?. Évalué à -1.
[^] # Re: Un bench vaut ce qu'il vaut
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 2.
[^] # Re: Un bench vaut ce qu'il vaut
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 2.
[^] # Re: Code lua toto2
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 2.
Oui. Sans le tri, on obtient 0.068s au lieu de 0.073s
[^] # Re: "x100 pour y voir clair"
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 2.
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
[^] # Re: Un bench vaut ce qu'il vaut
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 3.
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
[^] # Re: "x100 pour y voir clair"
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 1.
[^] # Re: "x100 pour y voir clair"
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 1.
Avec le 2eme algorithme :
Pour 100000: Lisp = 0.005s C = 0.009s C(O3) = 0.006s
Pour 1000000: Lisp = 0.409s C = 0.432s C(O3) = 0.407s
Pour 10000000: Lisp = 5.469s C = Segmentation fault (normal à cause des indices du tableau)
Pour 100000000: Lisp = 68.193s C = Segmentation fault
Pour 1000000000: Lisp = Plein de warning à la compilation : on atteint la limite de l'implémentation actuelle et des fixnum qui est à 536870911.
Je n'ai rien changer au code en Lisp (juste incrémenté nb-entries). Pour le code en C, je pense qu'il faut passer au malloc à la main et changer le type des indices.
Sinon, voila les derniers nombres amis trouvé avec 100000000 éléments testés :
(89477984 92143456)
(90437150 94372450)
(91996816 93259184)
(93837808 99899792)
(95629904 97580944)
(96304845 96747315)
(97041735 97945785)
[^] # Re: "x100 pour y voir clair"
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 4.
Python : 48m7.524s
Lisp : 46.021s
C : 46.012s
[^] # Re: Code lua toto2
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 2.
Tout ça pour dire que l'algo est vraiment le point central !
[^] # Re: Plus d’infos !
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 1.
Par contre pour le deuxième algo je passe de 0.058 à 0.017. La version en Lisp reste à 0.038 donc elle se place entre le C sans optimisation et le C avec optimisation.
[^] # Re: "x100 pour y voir clair"
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 3.
[^] # Re: Plus d’infos !
Posté par hocwp (site web personnel) . En réponse au journal Javascript plus rapide que python ! (une suite possible). Évalué à 3.