small_duck a écrit 139 commentaires

Tout à fait. Depuis l'apparition en standard des std::unique_ptr et des std::shared_ptr, je n'ai pas encore rencontré de cas où j'aurais eu envie d'un ramasse-miettes. Cela me semble très à l'opposé des principes du langage, très déterministe, très RAII, et un poil TOC sur les bords avec la mémoire. Mais bon, c'est comme les singletons: ce n'est pas parce que c'est possible qu'une bonne base de code doit l'utiliser.

J'ai convaincu mon employeur de passer à C++11, et c'est très plaisant d'utiliser les listes d'initialisation, les variables auto, et bien sûr la sémantique de déplacement. Le gain de performances lors de la redimension de vecteurs de pointeurs partagés est impressionnant.

C'est une nouvelle vie pour le langage, et ça me donne une bonne excuse pour passer du temps sur les nouveaux Guru of the Week d'Herb Sutter.

wxWidgets a FileFilla.

Et pgAdmin!

J'avais parlé de mon projet Médoc. J'en suis à plus de 200 documents et 300MB de données.

De manière générale, numériser et archiver proprement ses documents prend un peu de temps, mais le retour sur investissement est très bon, surtout quand on a pas la place d'avoir un beau range-documents bien classé.

Si je comprends bien, c'est différent: ils s'étaient vendus à O2, mais gardaient leur propre réseau et support. Là, c'est tous les abonnés qui vont passer au réseau de Sky. Leur FAQ est un peu courte, mais cela donne l'impression que BE va être phagocytée et disparaître…

Be There, très bien! J'apprécie le côté pro, on a immédiatement quelqu'un au téléphone, et un système de tickets sur leur site Web permet de savoir exactement où on en est. L'on reçoit des SMS lorsqu'ils prévoient des travaux qui pourraient affecter la connexion.

Malheureusement, ils viennent de se vendre au grand méchant Sky. J'appréhende.

C'est pertinent. Mon cas est un peu particulier: la migration était "obligatoire", et passer à MySQL, nous forçant à émuler tout un tas de fonctionnalités, aurait été bien pire. La base est stable, donc peu de changements. Et enfin, l'environnement dit "d'intégration", où les tests grandeur nature se font, reste sous DB2.

Dans l'absolu, je suis d'accord que toute différence entre la prod et le test est une catastrophe en devenir.

Mes DBAs sont fans de Postgresql, mais n'ont pas réussi à convaincre leur management. Quelque part, cela se tient: ils doivent déjà supporter MySQL, Oracle, DB2 et Sybase, et tentent de réduire leur offre à Sybase pour les applications critiques, et MySQL pour les autres. Alors en proposer un de plus…

Par contre, quand j'ai expliqué à notre propre management que je ne pouvais pas remplacer notre base DB2 par MySQL, mais que je pouvais par contre passer "en douce" sous Postgres pour nos environnements de test, économisant ainsi des centaines de milliers de $, ça leur a plu. On ne passera jamais à Postgres en production, parce que nous avons besoin d'un vrai support de nos DBAs. Mais, comme dirait l'autre, il n'est pas interdit d'être habile.

Merci pour ce journal très complet!

Ce qui m'a toujours beaucoup rebuté dans l'édition de partitions, c'est la lenteur à laquelle j'arrive à entrer les notes. C'est rageant d'aller beaucoup plus vite avec un crayon qu'avec un clavier.

Le cliquodrome, peu précis, fait rapidement très mal à la main, et je n'ai pas encore trouvé d'éditeur dont le mode d'édition complètement au clavier me satisfasse.

Peut-être une combinaison clavier pour le rythme, et piano midi pour la hauteur du son?

Quelle est ta méthode préférée, et à quelle vitesse arrives-tu à créer tes partitions?

Le temps de copier mon .emacs!

Je suis fan de types fantômes, et j'en colle partout (trop?). Mais quand je fais du C++ en lieu et place d'OCaml, je m'assure de toujours avoir dans un coin ma template StrongId:

template<typename DISCRIMINANT, typename TYPE>
class StrongId
{
public:
  StrongId(const TYPE & type):
    _type(type)
  {
  }

  bool operator==(const StrongId<DISCRIMINANT, TYPE> & other)
  {
    return _type == other._type;
  }

  TYPE _type;
};

class DistanceDiscriminant;
class TempsDiscriminant;

typedef StrongId<DistanceDiscriminant, int> DistanceT;
typedef StrongId<TempsDiscriminant, int> TempsT;

int main()
{
  DistanceT d1(1);
  DistanceT d2(2);
  d1 == d2;
  TempsT t1(1);
  d1 == t1; // Erreur de compile
}

Il est ensuite possible d'ajouter des méthodes supplémentaires pour comparer, sérialiser, afficher… Voire de rajouter un peu de template magic pour permettre de diviser une distance par un temps et d'obtenir une vitesse.

(attention petit serveur autohébergé, je cherche un site libre friendly où mettre mes vidéos)

Bittorrent?

Je suis plutôt content de ma HP OfficeJet 6500, qui fait fax, scanner, et imprimante, via le réseau. Le driver hplip est dans les paquets Debian, la configuration est aisée, et une fois que c'est dans Cups, ça marche tout seul. Je ne suis pas sûr des capacités d'impression de photos, en revanche.

LWT est très bien, mais il faut s'accrocher au début pour comprendre comment l'utiliser, et comment adapter ses bibliothèques non coopératives. Une fois qu'on a compris, vient la phase où on veut tout faire en coopératif :)

Toutafé: il est possible d'envoyer un signal au serveur Ocsigen pour lui faire recharger tous ses modules.

Ayant présenté Médoc il y a quelques temps, je suis ravi de voir d'autres approches pour résoudre le problème de la paperasse qui s'accumule. Ton logiciel m'a l'air beaucoup plus intégré, ce qui est un plus: Médoc reste particulièrement crampon à installer.

De manière générale, je trouve l'OCR plutôt moins utile que les tags, parce que typiquement je cherche la "facture EDF d'il y a 2 ou 3 mois", plutôt que des mots spécifiques au document, mais c'est peut-être ma manière de chercher.

J'ai aussi pas mal creusé du côté des formats, et je trouve le PDF assez nul, au final. Je suis tout à fait satisfait de mes bons vieux JPEG, qui au moins sont triviaux à lire. Puis-je te demander quel format tu utilises pour tes documents?

Il nous manque. Il était venu nous faire une présentation de RHEL6 au boulot. On n'avait pas pu s'empêcher de le lancer sur quelques trolls velus (icc? "Waste of money!"). Ça doit être sport, les réunions projet chez Goldman.

Pas un mot de plus à ajouter à la BD, pas un mot de plus à ajouter au grand homme.

• À faciliter l'interopérabilité entre composants. De ce point de vue là, les primitives de base ont tout intérêt à être standardisées. Il n'y a qu'à voir les soucis causés par les vieilles bibliothèques n'utilisant pas std::string, ou encore maintenant le bazar sans nom autour des chaines Unicode, chaque framework débarquant avec le sien. Cela alourdit inutilement les applications avec du "boilerplate code" (des idées pour la traduction?)
• À ne pas avoir à redémarrer de zéro en débarquant dans un nouveau projet. Si tous les projets C++ de la planète utilisent la même bibliothèque réseau, sérialisation, accès à la BDD, GUI, l'on est plus rapidement opérationnel.
• Enfin, c'est aussi un moyen de guider les développeurs vers certains paradigmes. La bibliothèque standard, de ce côté là, a montré une approche très fonctionnelle qui a eu une influence énorme sur la manière d'approcher le langage.

Mais peut-être qu'une différence fondamentale du C++ avec les monstres Java, C# et Python est que l'on a de nombreuses implémentations, et une décision par comité. Cela veut dire une longue recherche de consensus, pour au final un résultat souvent à minima (par exemple, std::thread n'a ni les verrous partagés, ni les thread groups...).

Le résultat? La communauté se prend par la main. Boost propose de nombreuses bibliothèques, certaines très matures, d'autres plus expérimentales. À un problème, de nombreux développeurs vont apporter des solutions, parfois très différentes (comparez Boost Asio et SDL_net, QT et WxWidgets...), et les meilleures survivre. Peut-on espérer la totalité des Intel Threading Blocks dans la bibliothèque standard? Ou une API d'accès aux bases de données suffisamment puissante et suffisamment générique?

Standardisons donc le bas niveau, et les problèmes pour lesquels il n'existe vraiment qu'une seule solution. Pour le reste, pas touche!

J'opine, mais j'ajoute juste un détail supplémentaire: un GC concurrent. N'utiliser qu'un seul processeur à la fois, c'est dommage.

La réponse des concepteurs du langage est d'écrire des applications multi-processus, ce qui fonctionne pour une certaine classe de problèmes, mais pas pour tous... Intégrez-moi Lwt, la bibliothèque de fibres, au dessus d'une vraie concurrence, et l'on aura enfin une belle alternative à boost::asio pour faire de l'asynchrone et de l'orienté événements.

De nombreux langages se présentent comme un inventaire à la Prévert de fonctionnalités à la mode. J'applaudis l'effort d'innovation, mais je ne peux m'empêcher de me demander l'intérêt de l'approche.

Je préfère de beaucoup que l'on me dise: "Tiens, voilà un super produit! Malheureusement, aucun langage ne répondait à nos besoins pour le développer, nous avons donc créé le nôtre.", que "Tiens, voilà un super langage! On ne sait pas trop quoi faire avec, par contre. Des idées?".

Existe-t-il donc des applications écrites en Rust et qui bénéficient des fonctionnalités du langage?

D'autant plus qu'il suffit de voir sur Wikipedia la liste des Stradivarius pour s'en convaincre: l'on semble bien plus intéressé par l'histoire de l'instrument, qui l'a possédé, qui a joué dessus, que par des qualités intrinsèques difficiles à déterminer.

C'est pareil avec le marché le l'art: un tableau qui sera passé dans le bureau d'un président ou le salon d'un grand acteur sera vendu bien plus cher. Imaginez l’œil gourmand du collectionneur expliquant que son tableau a "vu" Eisenhower...

Magnifique, on retrouve les bonnes vielles sensations d'Ages of Empire (en particulier la frustration de se faire égorger par l'IA...). Probablement un des jeux Open Source les plus aboutis.

Chapeau.

Si Sane le connait, alors ça devrait marcher tout seul en théorie. Dans la pratique, la gestion des batch et mon support limité des différents types d'options de Sane pourraient causer des soucis... Je suis preneur de rapports de bugs!

Comment gère-tu les document à page multiples avec des images ?

Chaque image est une page, et un document peut donc être composé de plusieurs images. Ça rend le code plutôt propre, mais cela n'est pas particulièrement pratique, par exemple, pour consulter ou imprimer un gros document, puisqu'il faut cliquer sur chaque vignette séparément pour afficher l'image en grand.

Je vais m'intéresser à DjVu, mentionné dans un commentaire un peu plus haut, et qui devrait m'aider à avoir une approche plus orientée document que page.