Cela serait top de pouvoir faire sa propre IA, cela a été le but de maitretarot.
Dans un concours d'IA, le système utilisait simplement stdin stdout pour dialoguer avec chaque programme d'ia. Cela permet de faire des IA plus ou moins complexe.
J'espère qu'après autant de retour il va y avoir des updates :)
* passer de bc à sh
* gérer l'absence de batterie
* tester la présence du binaire acpi lors du source ?
Les performances moyennes que l'on peut obtenir d'un langage n'est pas une caractéristique comme les autres. Il est souvent question de savoir si cela va passer ou pas, pour l'application finale avant même de commencer à coder. C'est l'inverse du processus habituel qui consiste à optimiser en phase finale de développement, après mesure des performances.
Je reste persuader que si un langage de plus haut niveau que le C, qui permet donc de développer plus vite un produit final et qui dans le même temps garantie une performance (en temps et en espace mémoire) supérieur la plus part du temps, aura un grand succès, quel que soit les outils de développement disponibles. Il existe un tas d'application demandeuse de performance (jeux, multimedia, temps réel, voir application serveur.) pour faire décoller le langage.
Ou comme en Grêce ou les personnes gagnant 800€/mois qui doivent s'acquitter de plus de 400€ d'IR. 1/2 mois de salaire pour des salaires aussi bas, c'est un peu abusif…
La différence est énorme avec les CD : les pc ou les disques sont "online". Cela veut dire qu'ils peuvent signaler une panne prochaine. Leur contenu peut être copier rapidement. Essayes de faire la copie de 100 CD, tu ne le fais qu'une fois !
Utiliser LLVM doit revenir à réécrire le compilateur, ce n'est pas une priorité à mon avis.
De plus, l'utilisation d'un GC oblige a avoir une gestion très fine de tous les pointeurs. C'est pour cela que c'est très difficile de faire un langage avec GC qui passe par l'intermédiaire du C.
Le paradigme à changer avec les clefs usb et les disques dures. Il n'y a plus vraiment de support physique. A chaque nouveau PC, les données sont intégralement copié sur le nouveau. Il n'y a plus de support physique à faire vivre.
Il n'y a quand même rien de plus complexe que la programmation par thread. Ce genre de programme sont souvent truffé de bugs complexes. Cela n'est pas pour rien que des logiciels comme Chrome font marche arrière et utilise des processus.
Rien n'empêche l'utilisation de thread au lieu de processus, juste pour une implémentation de passage de message sans copie.
Je ne suis pas sûr que cela soit bête. Les pthreads linux ont fait le choix de faire un thread pour thread noyau. Cela évite d'avoir 2 schedulers qui se battent pour gérer les ressources et cela permet d'avoir le soutien du système mémoire, qui gère le "false sharing" et autre subtilité.
Il me semble que Linux peut gérer 100 000 threads sans soucis autre que l'allocation de la mémoire pour la pile (en 32 bits).
Comme pour un pool de thread, il est possible de faire un pre-fork.
La parallélisation de petite zone de code en thread est également inutile en pratique à cause de la gestion des caches.
Erlang ne supporte pas le multicore, ces thread sont des threads léger comme lwp. (Et je ne parle pas de performance.) Je ne sais toujours pas si il supporte le mutli-coeur actuellement.
Je crois que tu devrais relire le pavé :) Je n'ai jamais parler d'exception et gérer correctement toutes les erreurs avec le bon messages en C te pourris ton code correctement. Souvent tu préfères tester un truc qui marche avant de toute faire proprement. Si tu fais propre dés le début, il est évidement que tu ira bien plus vite en ocaml.
Dans l'article en question, il parle de différence de vitesse selon l'ordre de link et la taille des variables d'environnement avec des écart de + ou 5 % et + ou - 10%. Cela reste pas énorme.
C'est pour cela que je parlais de savoir de quoi on mesure. Un bench ne peut être qu'une application réelle. J'ai déjà mesuré des bouts d'application. Le problème est qu'entre le temps d'exécution en cache "froid" et le temps en cache chaud,il peut y avoir une différence de 10x ! La mesure n'a de sens que dans le cas d'usage de l'application complète.
Ocaml ne propose pas de "vrai" contrat, mais tu peux faire des choses avec les assertions et ajouter des vérifications "runtime". C'est n'est pas statique comme le typeur, mais cela diminue le besoin d'écrire les tests eux-même, puisque le code (en mode debug) s'autovérifie.
Pour les bug de type 5, j'utilise les assertion autant que possible. Mais ce n'est pas toujours facile.
Ocaml affiche la pile d'appel qui déclenche les assertions fausses, cela localise l'assertion fausse mais aussi le chemin pour y arrivé. Le problème restant est qu'en cas d'inlining, certaines fonctionnes disparaissent de la trace.
Integer et int qui sont différent. Les comportement bizarre des tests sur les strings selon qu'elles sont canonisé ou pas.
En ocaml, tu peux écrire :
type plop = Entier of int | Chaine of string
let print (a:plop) =
match a with
| Entier i -> print_endline (string_of_int i)
| Chaine s -> print_endline s
Cette gestion des "types somme" peut te faire gagner un temps de malade sachant que le typeur vérifie que les matchs sont complets.
Pour rajouter une couche,un code qui marche en ocaml est très proche d'un code fini, pas besoin de rajouter une grosse couche de gestion d'erreur. En C, une fois qu'une maquette marche, il faut rajouter toutes la gestion d'erreur pour éviter les "core dump", il faut revoir toutes les allocations mémoire pour éviter les buffer overflowx, etc…
Les gens qui se battent contre le typeur sont simplement des gens qui se battent contre leur programme faux.
Ocaml a d'autres limitations : pas d'interface graphique "native", un compilo qui renvoit des message d'erreur pas toujours d'une grande limpidité (même si on apprend à les déchiffrer avec le temps), outils de développement loin d'eclipse ou l'équivalent, ceux qui existe étant très proche de linux et loin de windows.
J'ai le même genre d'étage pour les passwords, mais uniquement en fonction de la supposé fuite des mots des passes. En gros, j'ai confiance dans mes machines perso, un peu moins sur les machines que je loues, encore un peu moins les services comme Facebook et google, et encore moins les autres (sony…). Le but est d'être "étanche" entre ces sites : ne pas utiliser de mots de passe identiques pour des sites de catégories différentes.
Le problème est posé avec les sites ou l'on va peu souvent, comme certain site de vente, et j'essaye souvent qq mots de passe que j'utilise couramment. Je me suis toujours demandé si un de ces sites enregistraient les essais de mots de passe infructueux. Je considère cela comme une faute professionnel mais on ne sait jamais avec certain prestataire.
Imagines que la page d'acceuil de linuxfr soit gérer par un truc dynamique, à chaque connexion le moteur doit être exécuter. Si la page html est généré uniquement en cas de modification, 99% du temps, le serveur sert une page statique.
Dans le cas de reverse proxy, il me semble qu'il y a un problème pour prévenir le truc de devant par un "ça a bougé". Il faut fonctionner avec des timeout court si on veut de la réactivité, c'est pas forcément top, car le moteur sera appelé pour rien.
C'est pour cela que je parle de performance à l'époque du passage à templeet, les perf avait exploser avec cette technique (même si il y a avait du php dessous).
Ce n'est pas parce que le code est compilé qu'il ne peut pas avoir d'énorme faiblesse dans l'architecture, vu la complexité du web. Cela serait bête qu'une seul personne puisse faire un DOS sur un site web.
[^] # Re: Chez moi ça marche
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Tiny 'Nux Tarot, version 0.2. Évalué à 4.
Cela serait top de pouvoir faire sa propre IA, cela a été le but de maitretarot.
Dans un concours d'IA, le système utilisait simplement stdin stdout pour dialoguer avec chaque programme d'ia. Cela permet de faire des IA plus ou moins complexe.
"La première sécurité est la liberté"
[^] # Re: Une population qui vieillit
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 0.
Sur le forum du partie pirate, une personne propose d'utilisé le moteur de linuxfr pour faire leur site communautaire pour des raisons pratiques.
Les premiers commentaires ne relèvent qu'une chose : "Qu'est-ce que c'est moche" !
Je n'irais pas jusque là, mais c'est vrai que cela manque d'images :)
"La première sécurité est la liberté"
# mise à jour ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 7.
J'espère qu'après autant de retour il va y avoir des updates :)
* passer de bc à sh
* gérer l'absence de batterie
* tester la présence du binaire acpi lors du source ?
Super idée en tout cas.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Les performances moyennes que l'on peut obtenir d'un langage n'est pas une caractéristique comme les autres. Il est souvent question de savoir si cela va passer ou pas, pour l'application finale avant même de commencer à coder. C'est l'inverse du processus habituel qui consiste à optimiser en phase finale de développement, après mesure des performances.
Je reste persuader que si un langage de plus haut niveau que le C, qui permet donc de développer plus vite un produit final et qui dans le même temps garantie une performance (en temps et en espace mémoire) supérieur la plus part du temps, aura un grand succès, quel que soit les outils de développement disponibles. Il existe un tas d'application demandeuse de performance (jeux, multimedia, temps réel, voir application serveur.) pour faire décoller le langage.
"La première sécurité est la liberté"
[^] # Re: Répercussions
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Licences privatives abusives : un éditeur ne peut pas s'opposer à la revente d'une licence. Évalué à 3.
Ou comme en Grêce ou les personnes gagnant 800€/mois qui doivent s'acquitter de plus de 400€ d'IR. 1/2 mois de salaire pour des salaires aussi bas, c'est un peu abusif…
"La première sécurité est la liberté"
[^] # Re: oui mais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal [Prix des ebooks] coup de gueule. Évalué à 2.
La différence est énorme avec les CD : les pc ou les disques sont "online". Cela veut dire qu'ils peuvent signaler une panne prochaine. Leur contenu peut être copier rapidement. Essayes de faire la copie de 100 CD, tu ne le fais qu'une fois !
"La première sécurité est la liberté"
[^] # Re: C'est une blague ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 3.
avec un seul mot de passe, c'est complexe. Mais si les personnes en ont plusieurs, cela devient beaucoup plus facile.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Utiliser LLVM doit revenir à réécrire le compilateur, ce n'est pas une priorité à mon avis.
De plus, l'utilisation d'un GC oblige a avoir une gestion très fine de tous les pointeurs. C'est pour cela que c'est très difficile de faire un langage avec GC qui passe par l'intermédiaire du C.
"La première sécurité est la liberté"
[^] # Re: oui mais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal [Prix des ebooks] coup de gueule. Évalué à 2.
Le paradigme à changer avec les clefs usb et les disques dures. Il n'y a plus vraiment de support physique. A chaque nouveau PC, les données sont intégralement copié sur le nouveau. Il n'y a plus de support physique à faire vivre.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Il n'y a quand même rien de plus complexe que la programmation par thread. Ce genre de programme sont souvent truffé de bugs complexes. Cela n'est pas pour rien que des logiciels comme Chrome font marche arrière et utilise des processus.
Rien n'empêche l'utilisation de thread au lieu de processus, juste pour une implémentation de passage de message sans copie.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Je ne suis pas sûr que cela soit bête. Les pthreads linux ont fait le choix de faire un thread pour thread noyau. Cela évite d'avoir 2 schedulers qui se battent pour gérer les ressources et cela permet d'avoir le soutien du système mémoire, qui gère le "false sharing" et autre subtilité.
Il me semble que Linux peut gérer 100 000 threads sans soucis autre que l'allocation de la mémoire pour la pile (en 32 bits).
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Comme pour un pool de thread, il est possible de faire un pre-fork.
La parallélisation de petite zone de code en thread est également inutile en pratique à cause de la gestion des caches.
Erlang ne supporte pas le multicore, ces thread sont des threads léger comme lwp. (Et je ne parle pas de performance.) Je ne sais toujours pas si il supporte le mutli-coeur actuellement.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Il "suffirait de fournir un fork() portable + une lib de message qui fonctionne sans copie.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
"(la représentation des données est beaucoup plus compacte qu'en Java ou Python)"
Et pourtant, c'est un paquet de pointeur et d'indirection, j'aimerais pas voir la tête du layout mémoire Java ou Python.
"le compilateur génère du code natif efficace"
Il est très bien placé dans le shoutout, mais il a pourtant pas mal de marge d'amélioration.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Je crois que tu devrais relire le pavé :) Je n'ai jamais parler d'exception et gérer correctement toutes les erreurs avec le bon messages en C te pourris ton code correctement. Souvent tu préfères tester un truc qui marche avant de toute faire proprement. Si tu fais propre dés le début, il est évidement que tu ira bien plus vite en ocaml.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Dans l'article en question, il parle de différence de vitesse selon l'ordre de link et la taille des variables d'environnement avec des écart de + ou 5 % et + ou - 10%. Cela reste pas énorme.
C'est pour cela que je parlais de savoir de quoi on mesure. Un bench ne peut être qu'une application réelle. J'ai déjà mesuré des bouts d'application. Le problème est qu'entre le temps d'exécution en cache "froid" et le temps en cache chaud,il peut y avoir une différence de 10x ! La mesure n'a de sens que dans le cas d'usage de l'application complète.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Pour les tests, c'est 100% vrai.
Ocaml ne propose pas de "vrai" contrat, mais tu peux faire des choses avec les assertions et ajouter des vérifications "runtime". C'est n'est pas statique comme le typeur, mais cela diminue le besoin d'écrire les tests eux-même, puisque le code (en mode debug) s'autovérifie.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Pour les bug de type 5, j'utilise les assertion autant que possible. Mais ce n'est pas toujours facile.
Ocaml affiche la pile d'appel qui déclenche les assertions fausses, cela localise l'assertion fausse mais aussi le chemin pour y arrivé. Le problème restant est qu'en cas d'inlining, certaines fonctionnes disparaissent de la trace.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 4.
Integer et int qui sont différent. Les comportement bizarre des tests sur les strings selon qu'elles sont canonisé ou pas.
En ocaml, tu peux écrire :
Cette gestion des "types somme" peut te faire gagner un temps de malade sachant que le typeur vérifie que les matchs sont complets.
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Pour rajouter une couche,un code qui marche en ocaml est très proche d'un code fini, pas besoin de rajouter une grosse couche de gestion d'erreur. En C, une fois qu'une maquette marche, il faut rajouter toutes la gestion d'erreur pour éviter les "core dump", il faut revoir toutes les allocations mémoire pour éviter les buffer overflowx, etc…
"La première sécurité est la liberté"
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 5.
Les gens qui se battent contre le typeur sont simplement des gens qui se battent contre leur programme faux.
Ocaml a d'autres limitations : pas d'interface graphique "native", un compilo qui renvoit des message d'erreur pas toujours d'une grande limpidité (même si on apprend à les déchiffrer avec le temps), outils de développement loin d'eclipse ou l'équivalent, ceux qui existe étant très proche de linux et loin de windows.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
Cela donne une idée tout de même. Le principe est de savoir exactement ce que l'on mesure.
"La première sécurité est la liberté"
[^] # Re: Les étages et la liste de confiance
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 4.
J'ai le même genre d'étage pour les passwords, mais uniquement en fonction de la supposé fuite des mots des passes. En gros, j'ai confiance dans mes machines perso, un peu moins sur les machines que je loues, encore un peu moins les services comme Facebook et google, et encore moins les autres (sony…). Le but est d'être "étanche" entre ces sites : ne pas utiliser de mots de passe identiques pour des sites de catégories différentes.
Le problème est posé avec les sites ou l'on va peu souvent, comme certain site de vente, et j'essaye souvent qq mots de passe que j'utilise couramment. Je me suis toujours demandé si un de ces sites enregistraient les essais de mots de passe infructueux. Je considère cela comme une faute professionnel mais on ne sait jamais avec certain prestataire.
"La première sécurité est la liberté"
[^] # Re: lapin compris
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HWA : accéder au matériel autrement. Évalué à 2.
bizarre, m'enfin si cela marche.
"La première sécurité est la liberté"
[^] # Re: vitesse ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3. Dernière modification le 29 juin 2012 à 17:50.
Imagines que la page d'acceuil de linuxfr soit gérer par un truc dynamique, à chaque connexion le moteur doit être exécuter. Si la page html est généré uniquement en cas de modification, 99% du temps, le serveur sert une page statique.
Dans le cas de reverse proxy, il me semble qu'il y a un problème pour prévenir le truc de devant par un "ça a bougé". Il faut fonctionner avec des timeout court si on veut de la réactivité, c'est pas forcément top, car le moteur sera appelé pour rien.
C'est pour cela que je parle de performance à l'époque du passage à templeet, les perf avait exploser avec cette technique (même si il y a avait du php dessous).
Ce n'est pas parce que le code est compilé qu'il ne peut pas avoir d'énorme faiblesse dans l'architecture, vu la complexité du web. Cela serait bête qu'une seul personne puisse faire un DOS sur un site web.
"La première sécurité est la liberté"