small_duck a écrit 142 commentaires

Ça fait un certain temps que je me suis penché sur la question, mais il me semble que l'argument contre le chaînage des techniques de cryptage était que la combinaison est généralement plus facile à déchiffrer que la somme des parties, car mieux à même de faire ressortir des invariants, ou de magnifier les faiblesses des algos, un peu comme faire un double ROT13. Maintenant, ce n'est peut-être plus vrai avec les algos modernes.

Et en plus, je suis même pas foutu de cliquer sur le bon "répondre" :(

Vais aller me coucher.

Il a fallu que je cherche le sens de DPI... Pour ceux qui sont aussi nuls que moi, il ne s'agit donc pas de "double pénétration intellectuelle" (quoique) mais de "deep packet inspection".

La plupart du boulot autour de C++0x a été fait dans g++4.4 et g++4.5, la principale nouveauté dans g++4.6 étant le "range based for", qui va permettre enfin de mettre en retraite forcée le bon vieux BOOST_FOREACH.

Les autres ajouts, nullptr, constexpr, et quelques trucs sur les unions, sont moins enthousiasmants, mais c'est toujours ça de pris. Il ne manque plus grand chose, maintenant (non, par pitié, pas le GC!).

J'attends aussi beaucoup de bonnes choses du WHOPR, en espérant cependant que le temps passé à faire l'édition de liens n'explose pas.

Vu qu'aucun programme ne semble s'accorder sur la manière de passer les paramètres, j'aurais tendance à dire qu'une telle spec n'existe pas!

Dans mes programmes C++, j'utilise boost::program_options, et je le laisse se débrouiller.

Faire des centrales plus sûres, c'est possible, comme par exemple avec les réacteurs à sel fondu, qui travaillent en basse pression, avec des réactions moins dangereuses et un retraitement moins polluant. Le problème, c'est d'investir, rénover notre parc de centrales, et d'avoir une politique énergétique ambitieuse qui cherche à la fois à réduire la consommation (ou tout du moins à en réduire l'augmentation), et à profiter des technologies les plus récentes, avec prudence, mais sans hystérie. C'est pas gagné!

Bon, allons y doucement :)

Tout d'abord, ton souci de compilation est dû au fait que OCaml n'aime pas mélanger les classes et et les types. De manière générale, évite les classes si tu n'utilises pas l'héritage, et utilise plutôt les record. De cette manière, tu pourrais écrire:

type agent = 
    {
      mutable startState : state 
    }
and transition = Condition of (agent -> bool) 
                 | Event of (agent -> bool) 
                 | ConditionOr of (agent -> bool) 
                 | ConditionAnd  of (agent -> bool) 
                 | ConditionXor of (agent -> bool) 
                 | ConditionNor of (agent -> bool)
and state = 
    {
      mutable parentstate : state option;
      mutable substate : state option;
      mutable transitions : state list;
      mutable begin_action : state -> state;
      mutable action : state -> state;
      mutable end_action : state -> state
    }

Note que je ne suis pas tout à fait sûr de tes types pour state, j'ai mis ce qui me paraissait logique. Le type option de la bibliothèque standard remplace avantageusement ton stateOuRien.

J'espère que cela répond également à la question subsidiaire: quand bien même l'on peut gérer la plupart de ses types implicitement, il est pratique de définir tout d'abord ce sur quoi on travaille, à l'aide de records et de variants. Il est ensuite possible par exemple de forcer un type dans une fonction, par exemple:

let run_state (a:state) = a

sera typée comme fun : state -> state au lieu du générique fun : a ->a. Cela peut notamment rendre les messages d'erreur plus explicites et moins ésotériques.

Pour la question 2, je sèche, je ne comprends pas ce qu'est un type bloc (je suis un programmeur un peu old school :) ). Si tu as un record, tu peux le modifier directement:

let a =
  {
    parentstate = None;
    substate = None;
    transitions = [];
    begin_action = (fun e -> e);
    action = (fun e -> e);
    end_action = (fun e -> e)
  };;

a.transitions <- [a];;

C'est autre chose que tu cherches?

De manière générale, pour s'en sortir en Ocaml, mieux vaut une approche bottom-up:

• Créer les types dont on a besoin, à partir de records et de variants, en tentant de les garder aussi non-mutables que possible, et laisser de côté l'objet tant qu'on est sûr de ne pas en avoir besoin
• Construire les fonctions qui vont travailler sur ces types, en partant du plus basique, et en testant souvent
• Augmenter la complexité en écrivant des fonctions de plus haut niveau, s'appuyant sur les plus basses.

Bonne chance!

Boost est une excellente bibliothèque, la trousse à outils du développeur C++, et je me bats quotidiennement pour remplacer nos vieux (et moches) utilitaires fait maison par du beau boost.

Ceci dit, je me demande comment ils vont gérer la montée en charge de C++0x. De nombreuses bibliothèques du nouveau standard ont été prises de boost, mais parfois de manière incomplète. Ainsi, std::thread ne propose pas les pourtant bien utiles thread_group et shared_mutex.

L'idéal serait qu'ils se mettent rapidement à utiliser les briques du standard quand elles sont disponibles, et construisent autour leurs outils haut niveau. En gros, que boost::thread_group construise des std::thread.

Ah, et toujours pas de bibliothèque de log, snif...

Ça m'a ensoleillé mon week-end :) Bravo à toute l'équipe!

Les seuls logiciels libres que j'utilise et qui plantent sont ceux que j'ai développé moi-même...

Pour ceux des autres, je n'utilise pas (plus) ceux qui plantent (kdenlive, je te vois!).

Et rien ne m'a totalement convaincu jusque là. Dès que les dépendances sont un peu complexes (générer un programme qui génère du code, pour enfin générer le projet principal, par exemple...), il faut des kilomètres de configuration. Sans parler du support pour la compilation en parallèle, souvent mal supportée. CMake fait le boulot, mais au final pas si bien documenté, et trimballe avec lui ses défauts et ceux de Make. Et quand quelque chose ne marche pas, c'est pas particulièrement agréable à debugger.

Les solutions modernes, telles Ant ou Rake, sont souvent soit horriblement verbeuses, soit très légo: l'on assemble des blocs trouvés sur le Net, et si l'on a besoin de quelque chose d'un peu ésotérique, c'est l'horreur. Ceux qui me déplaisent le moins sont Scons et OMake, ce dernier, écrit en OCaml, étant mon favori dans mes projets perso.

Comme d'ailleurs les langages de programmation, tous ces outils ont été écrits pour résoudre des problèmes particuliers, et je crains qu'il n'existe pas de solution vraiment universelle, contrairement à la gestion de sources, par exemple, où Git et Mercurial proposent un modèle très solide.

Snif.

En fait, j'attends surtout Squeeze pour que la testing passe à g++ 4.5. Je veux mes lambdas!

OpenTTD est l'archétype du clone ayant transcendé l'original. Probablement un excellent exemple à suivre sur la manière de développer de bon jeux libres: modestie et développement itératif, sur un concept de niche.

Ils ont commencé petit (mais couillu!) avec du reverse engineering de Transport Tycoon Deluxe, puis ré implémenté le moteur en continuant d'utiliser les ressources graphiques originales. Petit à petit, de nouvelles fonctionnalités ont été ajoutées, les ressources originales remplacées, ajout du multijoueurs...

Avec peu de concurrence des jeux propriétaires (les récentes sorties dans ce domaine n'étaient pas à la hauteur), et un seul autre jeu libre (Simutrans) qui s'en approche, OpenTTD est pour moi le meilleur jeu de gestion de tous les temps.

Je confirme, OVH est un fournisseur à étudier, leurs prix sont raisonnables et l'offre plutôt complète. Leur interface d'administration est plutôt bien fichue, il est possible de configurer certaines redirections. Cela fait plusieurs années que j'ai affaire à eux (certes pour des mini-sites) et j'ai toujours été satisfait.

Postgres est LE projet qui me fait aimer les bases de données. Le système est incroyablement cohérent et solide. L'ergonomie du système est impressionnante, plus je l'utilise et plus je découvre de nouvelles fonctionnalités et petits détails qui facilitent l'utilisation. Pour moi, c'est là que Postgres se démarque:

- Postgres fournit des fonctions stockées en place des procédures stockées. En plus des utilisations habituelles des procédures, les fonctions peuvent également être chaînées, utilisées au sein d'une requête pour retourner une table... Beaucoup plus pratique pour structurer et généraliser son code.

- Postgres est la seule base à ma connaissance à fournir une excellente API cliente en C++, officielle (et donc maintenue), et moderne. Enfin un système utilisable sans avoir au préalable à passer une semaine à se casser la tête à coder un wrapper!

- Postgres fournit un très bon client graphique, officiel (et donc maintenu lui aussi!), proposant entre autres une représentation graphique du plan de requête, ce qui est particulièrement pratique lorsque l'on a une requête géante à optimiser

Au boulot, dès que j'ai à faire quelque chose d'un poil compliqué avec mes données, je copie tout le bazar depuis le gros serveur DB2 vers le Postgres installé en douce sur ma machine, et je me régale.

Bravo à l'équipe Postgresql, et longue vie au projet!

Très bien, très bien, la peur a changé de camp! Vivement que Youtube et Dailymotion laissent enfin tomber le format, qu'on puisse passer à autre chose.

On devient casanier avec l'âge! Et puis, ma Debian me le rend si bien :)