Je crois que le concept de démocratie liquide du partie pirate est une démocratie directe qui fonctionne massivement par délégation du vote. En gros, le travail du peuple est de faire confiance à une personne en particuliers pour savoir quoi voter. Il reste toute de même le problème de déléguer le vote par scrutin ou par domaine. Mais la définition des domaines, n'est pas simple du tout. La personne qui choisie de passer une loi dans un domaine ou un autre à un pouvoir considérable.
Comment fais-tu pour le gc ? J'ai l'impression qu'il est impossible de faire un bon système de GC en passant par du C ou du C++. C'est une des raisons qui a fait choisir Ocaml de générer directement de l'assembleur.
Si les règles de riff sont tellement fixes, il serait donc possible de faire un "générateur" de riff ? Voir de les générer tous ? Comme il a pu être fait un générateur de la musique de Bach ?
Concernant la gestion de mémoire, cela dépend de la durée de vie des tableaux en question. Si tu fais des agrandissements tu peux tenter le mmap et remap, mais cela fonctionne uniquement par tranche de 4ko, par contre, l'agrandissement doit être bien plus rapide, qu'une nouvelle allocation suivi d'une copie.
Si la duré de vie des tableaux est courte, je ferais simplement une zone mémoire avec une gestion de pile (comme le gc mineur de ocaml) en utilisant mmap pour l'allocation de chaque pile.
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…
[^] # Re: Arrow
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La définition de démocratie, quelle est-elle selon vous ?. Évalué à 2.
Je crois que le concept de démocratie liquide du partie pirate est une démocratie directe qui fonctionne massivement par délégation du vote. En gros, le travail du peuple est de faire confiance à une personne en particuliers pour savoir quoi voter. Il reste toute de même le problème de déléguer le vote par scrutin ou par domaine. Mais la définition des domaines, n'est pas simple du tout. La personne qui choisie de passer une loi dans un domaine ou un autre à un pouvoir considérable.
"La première sécurité est la liberté"
[^] # Re: LLVM
Posté par Nicolas Boulay (site web personnel) . En réponse au journal pythran rampe. Évalué à 2.
Comment fais-tu pour le gc ? J'ai l'impression qu'il est impossible de faire un bon système de GC en passant par du C ou du C++. C'est une des raisons qui a fait choisir Ocaml de générer directement de l'assembleur.
"La première sécurité est la liberté"
[^] # Re: PS4
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Jon lord est bronsonisé. Évalué à 3.
Si les règles de riff sont tellement fixes, il serait donc possible de faire un "générateur" de riff ? Voir de les générer tous ? Comme il a pu être fait un générateur de la musique de Bach ?
"La première sécurité est la liberté"
[^] # Re: allocation de tableau
Posté par Nicolas Boulay (site web personnel) . En réponse au journal pythran rampe. Évalué à 3.
Si les fonctions de base sont lentes, tu ne pourras jamais rien faire avec le langage.
"La première sécurité est la liberté"
# allocation de tableau
Posté par Nicolas Boulay (site web personnel) . En réponse au journal pythran rampe. Évalué à 4.
Concernant la gestion de mémoire, cela dépend de la durée de vie des tableaux en question. Si tu fais des agrandissements tu peux tenter le mmap et remap, mais cela fonctionne uniquement par tranche de 4ko, par contre, l'agrandissement doit être bien plus rapide, qu'une nouvelle allocation suivi d'une copie.
Si la duré de vie des tableaux est courte, je ferais simplement une zone mémoire avec une gestion de pile (comme le gc mineur de ocaml) en utilisant mmap pour l'allocation de chaque pile.
"La première sécurité est la liberté"
[^] # 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é"