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.
Sauf que le strip est complètement faux. Il compte de l'entropie pour les mots du dictionnaires. Si l'attaquant présuppose l'utilisation de mot du dictionnaire l'entropie tombe en chute libre.
REtourner rien permet d'avoir des fonctions qui fait des effets de bords.
D'ailleurs, pourquoi n'est-il pas possible de définir une entrée/sortie "sous-entendu" ou caché, après tout un read ou un write dans un fichier est simplement une IO caché. Ainsi, on aurait toujours une vérification de type par "en dessous".
Un truc top aussi serait l'inclusion des exceptions dans le typage, car il est difficile de savoir ce qu'une fonction peut lever comme exception. Ou alors, il faut augmenter ocamldoc pour avoir ces infos.
Inline demande l'inclusion dans le code objet quand c'est possible la fonction est toujours "extern" par défaut. Donc, en plus de son inclusion dans le code du fichier .c en cours, il y a une version de la fonction qui est appelable de l'extérieur depuis un autre .o. Le symbole de la fonction est présent et trouvable par le linker.
Aujourd'hui, les linker sont capable d'enlever le code non utilisé dans les .o. Mais c'est assez rare.
De plus, si tu utilises 2 fichiers .c que tu compiles avec un header contenant la même fonction inline foo (), les 2 symboles existent, et le linker va sortir en erreur. Pour masquer au linker, les 2 symboles, la fonction doit être marqué comme static.
Il suffit que tu face une démo utilisant 2 fichiers .c utilisant ton ".h", tu le verra par toi même.
A moins que tu es un linker intelligent qui fait le ménage après coup, toutes tes fonctions vont se retrouver dans objet, car sans "static", cela veut dire que la fonction est appelable de l’extérieur du .o, elle est donc généré même si elle n'est pas utilisé.
Pour les boites, peut-être que tu peux les trouver par apprentissage. Ou alors, tu peux guider le truc avec le codage en dure de tout les symboles qui vont par 2 : (),[], /* */….
[^] # 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é"
[^] # Re: Just sayin...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 4.
Sauf que le strip est complètement faux. Il compte de l'entropie pour les mots du dictionnaires. Si l'attaquant présuppose l'utilisation de mot du dictionnaire l'entropie tombe en chute libre.
"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.
Tu as été jusqu'au link ? Genre :"$ avr-gcc demo-03.c demo-03_2.c" ?
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
REtourner rien permet d'avoir des fonctions qui fait des effets de bords.
D'ailleurs, pourquoi n'est-il pas possible de définir une entrée/sortie "sous-entendu" ou caché, après tout un read ou un write dans un fichier est simplement une IO caché. Ainsi, on aurait toujours une vérification de type par "en dessous".
Un truc top aussi serait l'inclusion des exceptions dans le typage, car il est difficile de savoir ce qu'une fonction peut lever comme exception. Ou alors, il faut augmenter ocamldoc pour avoir ces infos.
"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é à 1.
Tu n'as toujours pas compris l'usage de "inline".
Inline demande l'inclusion dans le code objet quand c'est possible la fonction est toujours "extern" par défaut. Donc, en plus de son inclusion dans le code du fichier .c en cours, il y a une version de la fonction qui est appelable de l'extérieur depuis un autre .o. Le symbole de la fonction est présent et trouvable par le linker.
Aujourd'hui, les linker sont capable d'enlever le code non utilisé dans les .o. Mais c'est assez rare.
De plus, si tu utilises 2 fichiers .c que tu compiles avec un header contenant la même fonction inline foo (), les 2 symboles existent, et le linker va sortir en erreur. Pour masquer au linker, les 2 symboles, la fonction doit être marqué comme static.
Il suffit que tu face une démo utilisant 2 fichiers .c utilisant ton ".h", tu le verra par toi même.
"La première sécurité est la liberté"
[^] # Re: 32 Mo ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Détection de la syntaxe d'un langage informatique via un analyseur statistique naïf de type Bayésien. Évalué à 2.
le lexer universelle serait là uniquement pour détecter une forme hiérarchique. Le reste est identique.
Cela permet de détecter des forme comme if (…) then … ou
if (…) …} // impossible de mettre l'accolade ouvrante : #### Votre titre
"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.
C'est grâce à gold alors. "Inline" ne veut pas dire ce que tu semble croire. gcc utilisait "static inline".
"inline" demande de mettre en ligne le code, et encore souvent les compilateurs ne font plus attention à ce mot clef.
Seul "static" veut dire que tu ne veux jamais accéder au code de l'extérieur. Si tu utilises 2 fichiers .c, tu dois avoir une erreur de compilation.
"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.
A moins que tu es un linker intelligent qui fait le ménage après coup, toutes tes fonctions vont se retrouver dans objet, car sans "static", cela veut dire que la fonction est appelable de l’extérieur du .o, elle est donc généré même si elle n'est pas utilisé.
"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.
Difficile de lire ton code alors :)
A toi de voir si tu peux recoder l'avr-lib en bien plus compact, tu aura du succès dans ce cas. Je n'ai pas vu de "static" dans tes exemples.
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Tu as une liste d'insulte en disant qu'il n'aime pas tel ou tel truc.
"La première sécurité est la liberté"
[^] # Re: Précisions sur la facilité de maintenance?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
Et il se passe quoi avec les données persistantes ?
"La première sécurité est la liberté"
[^] # Re: 32 Mo ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Détection de la syntaxe d'un langage informatique via un analyseur statistique naïf de type Bayésien. Évalué à 3.
Pour les boites, peut-être que tu peux les trouver par apprentissage. Ou alors, tu peux guider le truc avec le codage en dure de tout les symboles qui vont par 2 : (),[], /* */….
"La première sécurité est la liberté"