mackwic a écrit 302 commentaires

Comme beaucoup de gens qui disent ne pas aimer le thé, il suffit d'en gouter du bon, dans de bonnes conditions, pour etre conquis ! … C'est a dire ailleurs que dans un pays importateur dont le systeme de distribution se base sur les grandes surfaces ! ;-)

On a du mal a se rendre compte a quel point les saveurs sont normalisées et rangées, tout ca dans le but d'aider la distribution et de faciliter la vente (et c'est tres efficace, autant pour le consommateur que pour le distributeur, ce systeme est plein d'avantages).

Cependant, dans le cas du thé, il faut avouer que le résultat est tres décevant. C'est l'un des rares produits ou je m'y connais assez pour juger, et, clairement, les importateurs font mal leur boulot.

Le problème du thé accessible en France, c'est qu'il est périmé, complètement cramé. Je te rejoins complètement sur l'Ice Tea de Lipton qui est une boisson formidable, et il faut bien tout ces acidifiants et ce sucre pour rendre du Yellow Label buvable !

La conséquence de ce thé de tres mauvaise qualité, c'est qu'on le fait beaucoup trop infuser. Un bon thé, frais, jeune (moins de 6 mois pour du thé vert chinois, pareil pour du thé blanc, un thé de bonne qualité se reconnait a ses feuilles entieres, petites, commencant a avoir des bourgeons a peine nés. Les feuilles doivent-etre encore souples, pas cassantes, et humer sensiblement), un bon thé disais-je, n'a pas besoin de beaucoup infuser pour laisser ses aromes dans l'eau. Deux minutes suffisent. D'ailleurs l'eau ne doit pas trop changer de couleur, c'est un mauvais présage, disent les chinois…
De meme on peut tirer plusieurs tasses de quelques feuilles de thé. Petit a petit l'arome va se sucrer et la légere amertume (j'insiste sur le "legere", rien a voir avec les thés importés) va changer un peu. La tradition dit qu'a la troisième tasse, il est temps de partir et de laisser le maitre de maison a ses affaires …

J'ajouterais enfin que le thé chinois possède. toujours selon la tradition, de nombreuses qualités médicinales et que le coté excitant n'est présent que pour le thé amer (difficilement appréciable pour un Européen, je conseille surtout le Oolong au Ginseng, fortifiant). J'ai pu en expérimenter quelques unes (parfois involontairement), ca marche toujours mieux que de l'homéopathie. ;-)

A quoi sert le réservoir en alu relié au balon en haut a droite de ton image ? Et puis puisque le balon n'est pas chauffé, le liquide devrait rester bloqué dans le balon ?

En fait, si c'est vraiment ce que tu fais, tu pourrais détailler le fonctionnement de ton montage ? :-)

Non, c'est bien du bash. Tu peux tester si tu veux.

L'operateur |& permet de piper aussi stderr, et comme valgrind s'en sert pour tout…

J'ai sorti la premiere commande qui me passait par la tete, etant donne que c'est celle que j'utilise le plus frequemment en ce moment, mais ca aurait pu etre n'importe quelle redirection.

Ou pas…

valgrind --mes-super-options=yes ./a.out |& ./parse_log |& most

Pour l'execution de processus et la redirection de flux, bash est imbattable.

Absolument, ca me faisait penser a prism, mais en plus poussé.

Rien sur le tracker ne laisse entendre que c'est une friture qu'a implémenté NoNo<… Ca serait dont automatique ?

Franchement respect.

Ma productivité a décrue. Beaucoup.
Faut dire que j'avais pas mal de journaux de retard…

Et puis aussi je suis curieux de savoir comment marche ce truc, c'est vachement bien !

Oups ! Mon trackpad un peu sensible m'a fait déposer une portion de texte non-désirée en début de journal.

Si un modérateur passait par la, son assistance serait la bienvenue, merci !

Par contre ça ajoute quoi -ggdb3 par rapport à -g ?

Des options de débug spécifiques a gdb, plus d'information, des informations plus précises. Je met toujours les deux quand je sais que j'utiliserais gdb.

Au hasard, les commandes:
- print qui est surpuissant (genre print *(*argv + 2 * sizeof (size_t)) ou p *0x44ff006b
- disassemble car oui, tout le monde ne compile pas avec -g -ggdb3 :-)
- est-il nécessaire de spécifier jump et call ?
- dump dumpe tout simplement la ram a un offset donné et l'interprete s'il le peut
- le hardware watchpoint offrent souvent un support meilleur que ce que font la plupart des IDE

En tout cas, j'adore Kdevelop pour sa souplesse et son confort visuel, mais ce n'est pas pour son débuggueur que je le favoriserait…

Super astuce:
- compiler un fichier .c avec gcc -g -ggdb3
- lancer emacs -f gdb
- sélectionner votre exécutable
- M-x gdb-many-windows
- profit

Gdb est quand meme 'achement puissant. ;-)

Ca commençait bien, avec tous ces formats, ce sujet prometteur, et la haute résolution.

Quel dommage que ces saccades se présentent aux plus mauvais endroits (comment reconnaitre un mauvais endroit ? Facile : quelqu'un parle).
Franchement, j'ai énormément de mal a comprendre M. Haskell, qui en plus de parler vite, bénéficie de nombreux bullet times…

A ma décharge, ce n'était pas cité dans le journal et c'était bien plus logique pour expliquer une fuite de mémoire.

Pas du tout, il a raison, mais son code correctif est incomplet.

Ça serait plutôt ça:

tmp = realloc(ptr, size);

if (tmp == NULL)
{ /* die... */ }

if (tmp != ptr)
  free(ptr); // ICI

ptr = tmp;

blablabla

Si on ne compare a aucun moment tmp et ptr, le premier pointeur sera perdu dans la mémoire assez souvent. C'est ballo

Bah c'est une liste de fonctions ou méthodes précisément documentées, qui permet de se s'abstraire de l'implémentation enfin !

Ces jeunes, ça ne comprend plus rien a rien je vous jure… :)

Fais gaffe a pas en foutre partout, et tu nettoieras après.

Et bien… Un mois ou deux, le temps que les sous rentrent.

Honte à moi ! /o\

Quelles sont tes dates préférées pour prendre le livre ? Je suis dispo a partir du 29.

Et bien, je suis intéressé. Très intéressé, surtout que mon portable va bientôt me lâcher…

Mais euh, comment dire ? 1050€… Disons que là comme ça je ne les ai pas. Tu es prêt à attendre un peu ?

D'ailleurs tu pourais donner les informations de batterie ? Je ne les vois pas…

Ce qui est bien, c'est qu'avec des exemples comme ca on est convaincu que l'OCaml est super lisible comparé au C++

Je n'ai pas lu ces livres, je n'ai donc pas d'avis dessus. Cependant, je suis d'accord pour dire qu' "il y a tous les ans beaucoup trop de mauvais livres C++".

C'est pourquoi je ne peux que te conseiller de piocher dans Da Definitive C++ book guide list qui ne contient que des bons bouquins triés par genre et par niveau.

En espérant que ça t'aidera.

Plussoire, la plupart des {lave,sèche}-ligne ont cette sonnerie d’arrêt qui est désactivable par un bouton en façade.

Cherche encore ? :-)

En même temps, entre une recherche par un outil qui doit ouvrir tous les fichiers un a un et les parcourir et la recherche par un outil qui a déjà les fichiers ouverts en cache, on pourrait penser que l'IDE part avec un très net avantage.

D'ailleurs la recherche VS2010, si elle utilise celle fournit par .NET, utilise en effet PCRE dans sa dernière version, qui est censé être plus efficace que l'outil de recherche de grep (cf la manpage de grep).

Donc non, VS n'a aucune excuse pour être plus lent que grep (et il l'est en effet, de beaucoup). Je conseille vivement l'utilisation de l'extension Reshaper qui améliore sensiblement cet état de fait.
Après pour les histoires de FS, je vous laisse tirer vos propres déductions, j'en suis personnellement incapable.

Lesquelles des problématiques sus-citées concernent un toolkit graphique ?

Excellente idée ! Et puis on va utiliser un truc qui vérifie statiquement que les conditions sont toujours remplies (tu peux utiliser un objet dans différentes fonctions qui ajoutent différentes contraintes), et on appellera ça l'inférence de type !

Le principal argument du typage dynamique, c'est que tu ne te fais pas chier avec, tant que tu reste cohérent.
Le principal argument du typage statique, c'est que tu as beaucoup de barrières de sécurité qui s'ajoutent.

Le principal argument de l'inférence de type, c'est que ça combine les deux a la fois, tu ne te fais pas chier avec les types, mais le compilateur vérifie a tout moment que tu reste cohérent.

Trop peu de dev se rendent compte de la puissance de l'inférence et de sa facilité d’accès.

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".

Je ne comprends pas, tu veux dire un truc comme ça ?

let write_str str =
  let file = open_out "toto.txt" in
    output_string file str;
    close_out file