Guillaum a écrit 472 commentaires

(->) r est une instance de Monad, donc "Les fonctions sont des monades" ;) Mais je t'avoue que au niveau théorie des catégories, je suis largué et comme tu le dis, on peut vraiment dire n'importe quoi et que cela ai du sens.

Mais en effet, tu as raison, c'est simplement Reader en mode anonyme, merci de m'avoir fait observer cela.

Et les fonctions sont aussi des Monads… Et là j'ai souvent le cerveau qui fond. Je crois que je me suis servi une fois de l'instance d'Applicative pour les fonctions, pour un code golf, mais plus jamais ;) Alors l'instance de Monad ;)

1.

Merci, je ne connaissais pas cmp_to_key.

1. L'utilisation d'une telle fonction de comparaison qui doit choisir entre "plus grand", "plus petit" ou "égal" est loin d'être aisé dans le cas général où on peut être "aucun des trois".

Tu as un exemple de cela ? Si tu veux trier, tu dois forcement pouvoir définir un ordre, au moins arbitraire. Tu peux te contenter de <= pour établir une relation d'ordre. Il y a un mapping bijectif entre key et cmp, du moins je pense.

1. Finalement, comme plusieurs l'ont fait remarquer, utiliser key est généralement plus efficace que cmp, puisque key est appelé une seule fois par élément (O(n) donc), puis la comparaison (O(n log n) pour ordonner) est effectuée en C si les clés sont des type de base. À l'opposé, utiliser cmp fait en sorte que ces O(n log n) comparaisons impliqueront toutes un appel d'une fonction Python.

En effet, mais l'overhead mémoire peut ne pas être négligeable. Je n'ai pas regardé l'implementation, mais j'imagine que le tri en place avec cmp peut se faire en O(1) en mémoire, si on ignore la mémoire prise par la liste initiale. Alors que le tri avec le DSU ajoute forcement un overhead en O(n) pour stocker les résultats de l'appel à key. En fonction du problème cela peut être une limitation, même si j'avoue que dans le cas d'un tableau énorme on passera surement par une autre structure, type numpy.

Pour le coté dense, oui je l'admet. Comme je le dis dans un commentaire plus haut c'est partie d'une moment "Whaou" simple mais qui demande du contexte, et puis j'ai toujours eu du mal à être concis ;( Saint Exupéry ne serait pas fier de moi.

Merci pour la remarque "marrant", je prend cela comme un compliment ;)

Par exemple, il n'est pas évident de se dire que la signature des fonctions est logique sans comprendre qu'une fonction de plusieurs paramètres peut-être écrite comme la composition de plusieurs fonctions partielles dont la dernière est à 1 paramètre, ceci expliquant la notation des types en Haskell (Curryfication) qui ne ressemble pas au C++/Python.

J'ai essayé de faire un paragraphe la dessus mais finalement je me rend compte qu'il arrive au milieu du texte alors qu'il mériterait d'être au début.

Par contre, je pense qu'il y a une question à laquelle il serait bon de répondre par un journal / dépêche : celui de l'organisation du code, ou de sa différence entre l'approche objet, l'approche déclarative, l'approche fonctionnelle pure sans DataType, avec DataType, impérative sans Objet, etc.

Tu aurais un exemple de la problématique que tu sous entend ? J'ai l'impression que je suis biaisé parce que depuis que je fais du Haskell mon style en C++ et en Python a évolué vers quelque chose qui ressemble à Haskell et forcement je suis convaincu que c'est la bonne solution ;)

J'ai tendance à penser que l'approche fonctionnelle motive la séparation donnée / comportement alors que l'approche objet couple souvent les deux, mais à mon avis ce n'est pas imposé par la technologie, c'est plus un choix de développeur. D'ailleurs la STL C++ a vraiment une approche découplée depuis quelque temps, std::begin() ou lieu de obj.begin() ou l'ensemble <algorythms>, où le discours dernier sur le fait que f.method() pourrait devenir équivalent à method(f) pour unifier les styles d'appel.

La seule grosse difference que je trouve vraiment dure entre les deux approches c'est pour le polymorphisme runtime, (i.e: les appels virtuels en nomenclature POO). En fonctionnel, du moins en Haskell, j'ai l'impression que 99% des cas de figures sont remplacés par du curying ou des types sommes.

Par contre je ferais bien un article sur l'organisation de code et le typage. Je trouve que beaucoup de monde dans la communauté POO/mutable confonds généricité et absence de type. Un example que je donne souvent c'est pour la réalisation d'une librairie de vecteur pour un moteur 3D, un développeur c++/python vas faire une classe Point avec pleins d'operations : soustraction, addition, produit scalaire. Finalement il sera heureux, sous prétexte de généricité, d'utiliser la même classe pour generer les points, directions, normales, couleurs. De mon coté, j'aurais plus tendance à définir plusieurs classes / types, au moins Point, Direction, Normal / DirectionNormalisée, Couleur avec un sous ensemble de méthodes limitées aux besoins du domaine. (Par exemple, pas d'addition entre Point, pas de produit scalaire entre Couleur…). Mais encore une fois, c'est Haskell qui m'a biaisé l'esprit de cette manière, mais ce n'est pas inapplicable aux C++…

Bon par contre je vais le re-lire à tête reposée par ce que je ne suis pas sur d'avoir tout capté :-)

En même temps c'est dense ;) N'hésites pas à discuter les points pas clairs. Je suis parti de ma révélation de hier soir de "Mon dieu, les fonctions sont aussi des Monoids" et en fait je suis arrivé à ce truc immonde ;)

+1

Pour moi cela implique:

• Faire plus de Haskell dans ma vie professionnelle
• Perdre du poids
• Finaliser mon projet sportif commencé il y a 3 ans, sans que ma femme ne me quitte ;)

Quand j'ai découvert Haskell, j'ai cru que c’était le plus beau langage du monde. Ce qui est le cas (a part quelques trucs subtiles).

Puis j'ai compris certains concepts, alors j'ai voulu les appliquer au c++. La première chose que j'ai fais c'est implémenter mon propre Maybe. (qui se nomme std::optional dans c++17 le draft).

Mais en fait, cela n'a AUCUN intérêt sans la do notation malheureusement puisque cela force a chainer des lambdas. Exemple :

maybe<float> doSomething(...)
{
return doSomethingInt(...).bind([](int ret){
return doSomethingFloat(ret);
});
}


Alors, c'est personnel, mais ce n'est pas parce que le pointfree existe et qu'il y a plein d’opérateurs marrant qu'ils faut les utiliser.

Autant je trouve que la version 1 est lisible. Mais (Je me permet de corriger l’opérateur ;) (<=< existe, mais c'est la combinaison de kleishi inverse, enfin bref ;)

push_var_on_stack = pushq =<< get_var_addr
Aussi, je crois que Haskell on prefere le camelCase ;)

Parce qu'en ce moment je prototype beaucoup et que ce langage me permet d'être super efficace, faire moins d'erreur et avec des performances correctes.

Après je reecrirais en C++ parce que c'est ce que nous utilisons dans notre compagnie.

Ba oui… Globalement c'est surtout les fichiers ignoré que je supprime avec git clean. Les autres j'ai tendance à supprimer à la main car c'est soit des fichier à ajouter, soit des fichiers qui doivent sans doute avoir une raison d'être là ou d'être bougé ailleurs.

Attention au git clean dans le mauvais répertoire, cela fait désordre…

Histoire vécue. Je fais souvent des git clean (enfin moi c'est du hg purge, mais c'est pareil) pour nettoyer un dépôt de tous les trucs inutiles qui sont arrivés et pan… plus de home…

Personnellement j'ai une solution avec un sous répertoire de mon home pour les fichiers de config versionnés et je crée automatiquement les liens symboliques qui vont bien.

Si on enlève evolve, Mercurial est au même niveau que Git sur la facilité de réécrire l'historique.

Je m'auto répond. La seule difference que je vois (et qui est vraiment un problème) c'est qu'au lieu de "cacher" les commits qui disparaissent du fait d'une réecriture (comme le fait git), ils sont supprimés et stockés dans un fichier de backup. Il est vrai que c'est une limitation importante, mais je n'y pensais plus tellement evolve marche bien depuis quelques années.

C'est vrai j'avais oublié evolve. Je m'y étais intéressé l'année dernière, mais l'avais mis de côté car j'évitais les extensions qui ne sont pas fournies en standard ou qui sont expérimentales. Apparemment ce n'est toujours pas fournie en standard ou jugée suffisamment stable, je ne la trouve pas dans la liste http://mercurial.selenic.com/wiki/UsingExtensions. J'attend ça avec impatience car pouvoir réécrire l'historique sans rien détruire, et pouvoir relire ces réécritures, c'est une tuerie.

C'est à mon sens un problème de communication de la part de l'équipe de Mercurial, c'est qu'ils ont tendance à être très conservateur et le système d'extension donne cette idée que seulement un petit sous ensemble des fonctionnalités sont vraiment correctes et que le reste c'est juste des truc un peu bancales qui marchent plus ou moins. J'ai l'impression qui Git fait un peu l'inverse, c'est à dire proposer un truc en standard, alors que cela marche plus ou moins et corriger dans les version suivantes.

De ma dernière discussion avec un développeur d'evolve (je ne peux pas prouver cette affirmation cependant), je crois avoir compris que la plupart des composantes d'evolve sont déjà dans le core de mercurial et c'est maintenant plus des problèmes cosmétiques qu'autre chose pour en faire une extension officielle.

En pratique, j'utilise evolve depuis quelques temps et aucun problème et je connais quelques développeurs qui bossent sur des "petites" base de code de "petites" entreprises "familiales" (genre facebook…) qui l'utilisent quotidiennement sans soucis majeurs.

Mais ça n'enlève rien à Git qui ne propose peut-être pas cette fonctionnalité, mais qui répond quand même au besoin de beaucoup de dev sur la facilité de réécrire l'historique, et ça depuis qu'il existe.

Si on enlève evolve, Mercurial est au même niveau que Git sur la facilité de réécrire l'historique.

Hormis github, qui est un argument tout à fait valable, je ne vais aucun avantage à git comparé à mercurial.

En faisant abstraction de son horrible UI, Git permet d'être plus souple au quotidien : quand je fork un dépôt Git pour y contribuer, je peux me permettre de retravailler l'historique de ma branche comme je le souhaite sur mon dépôt perso (y'a peu de chance que quelqu'un l'ait forké à son tour donc je me permet de tout péter à coup de git rebase et git push -f avant de faire la pull request sur le projet upstream). Simple et rapide pour moi dans le cadre des petites contributions, et historique lisible pour ceux qui vont faire la revue de code avant un éventuel merge.

Et ? C'est pareil avec Mercurial. Je trouve même que c'est bien plus simple qu'avec Git. Avec mercurial, tu update (checkout) le commit qui t’intéresse, tu commit --amend, puis en utilisant evolve, tous les autres commit sont rebasés par dessus.

http://mercurial.selenic.com/wiki/ChangesetEvolution

Tu peux toujours faire du reordonancement et de la suppression avec histedit (qui est l'équivalent à quelques détails de rebase -i).

La dessus, tu as le système de phase qui t’évite de rebaser des commits publique, donc qui t'evites de te retrouver par erreur après quelques heures de travail avec un dépôt dans un état qui va te prendre quelques heures à rétablir.

De plus, mercurial (avec evolve) garde l'historique des manipulation d'historique. Ainsi tu peux voir quel est le commit à l'origine d'un amend, ou d'un rebase. Git ne sait pas faire cela et tu dois chercher dans le reflog à la main, ce qui peut être laborieux.

Hormis quelques détails, comme l'absence d'auto !fixup ou !squash dans Mercurial et que l'ajout interactif d'éléments dans un commit (i.e, l’équivalent de git add -p) est un peu moins élaboré (il existe crecord, mais je n'ai jamais accroché), je suis très souvent frustré par les limitations et le manque de flexibilité de git comparé à mercurial.

Pour finir, Facebook a dernièrement annoncé qu'il passaient de git à mercurial pour des raison de flexibilité et de performance https://www.youtube.com/watch?v=X0VH78ye4yY et google annonce aussi collaborer avec facebook pour l'évolution de Mercurial.

Je sais que ce n'est pas le propos, mais discutons en quand même.

Personnellement j'ai deux uses case de mon clavier de téléphone, soit en mode une main avec l'index soit en mode deux mains avec les deux pouces (le plus rare).

Dans les deux cas, je trouve qu'une disposition type bépo (ou dvorak que j'utilise tous le temps sur des claviers traditionnels) n'est pas adaptée, mais la disposition "azerty" qui m'est proposé par défaut est tout aussi mauvaise.

Connaissez vous des claviers plus adaptés (qui minimise l'effort à faire avec le pouce) ? Y a il des études faites sur ce sujet ?

Merci et bonne journée.

Pour avoir formaté la thèse de médecine et les publications de ma femme en utilisant zotero sous word il s'agit d'un très mauvais souvenir. Perte de travail, citations incohérentes ou manquantes, mise à jour qui supprime du texte du document… Seul point positif j'ai trouvé la documentation pour customiser les styles de citation très bonne contrairement a bibtex/biblatex.

Très clairement, pour les documents à faire en moins de trente minutes, j'utilise libre office.

Par contre, pour ma thèse qui contenant plusieurs centaines de figures générées (tableaux, courbes, graphiques, images issues de simulations), je n'ose même pas imaginer comment j'aurais fais cela avec Word / LOW.

Loin du troll, c'est une vraie question, ce type de production est elle possible en Word ?

Je pense qu'il parlaient de Word, le traitement de texte. Cependant je ne vois pas le rapport avec la matière première utilisée dans la conception de préservatifs…

marrant tient, cela veut dire que 32 Go et 41 Go c'est le même prix ;)

J'aurais tendance à dire que c'est plutôt :

8 * 0.7 + 8 * 0.5 + 16 * 0.3095 + 32 * 0.2360 == 22.104

Changer cela veut dire s'exposer au changement. Cela veut dire revalider les logiciel, cela veut dire s'assurer que ce qui fonctionnait avant fonctionne encore. Par exemple, quand tu compiles avec un vieux gcc, tu as des chances que la libc++ utilisée soit disponible sur la plupart des distributions, donc cela simplifie ton packaging. Quand tu as tout un environnement de build automatique, mettre a jour une partie de ta toolchain te force a de nombreuses mises à jour, potentiellement de nombreuses dépendances pour lesquelles tu doit maintenir ton code. En gros, c'est beaucoup de temps (et donc de cout) pour un gain qui n'est pas forcement important (hormis en qualité, mais la qualité a un cout, et n'est pas forcement la priorité numéro 1).

Autre chose, malheureuse, mais quand tu dois maintenir un logiciel sur de nombreuses plateforme, tu as tendance à niveler vers le bas.

pareil ;) Visual 2005, qui doit péniblement faire du C++98 et gcc 4.3…

Un peu tout pareil, mais j'y ajouterais quelques points.

Le plus important (pour moi), c'est que cela donne de la visibilité. J'ai mon job actuel grâce à mes contributions au logiciel libre. J'ai fais ma plus grosse conférence scientifique grâce à mes contributions au logiciel libre (Pour la petite note, j'ai fais une thèse en informatique, au final, en conférence, les gens me connaissent pour ma contribution à LuxRender et absolument pas pour mes travaux de recherche qui sont passablement minables ;)

En second lieu, je contribue quand un logiciel me casse les yeux ;) Si cela ne marche pas comme je veux, je contribue, et cela me simplifie la vie (Sauf quand mon patch de deux lignes est discuté pendant 12 mois, là je perd patience, et je quitte le projet ;)

Dernier point, j'insiste sur le coté technique, si je n'avais pas contribué au libre, je serais surement un ingénieur en costume cravate payé 2 fois plus que maintenant, mais je m’ennuierais. Grâce au libre, j'ai acquis beaucoup de compétences qui me permettent d'avoir un job qui me motive à me lever le matin (mais bien moins payé, faut pas déconner ;)

Je me suis toujours demandé s’il était possible de faire rebooter la carte entre l'host (ici un Linux) et l'esclave (ici un Windows) SANS rebooter le système host.

Exemple d'utilisation, j'ai une machine avec un CPU Intel contenant un GPU Intel intégré, suffisant pour les besoins de bureautique. J'ai aussi un GPU Nvidia et un GPU AMD dans la machine.

90% du temps, je "travaille", ce qui implique que je développe sous Linux et que je teste mon code openGL/openCL sur mes différents GPUs.

Le serveur X tourne sur le GPU Intel intégré, et je pourrais utiliser virtualgl pour envoyer des commandes à mes GPU AMD et nvidia.

De temps à autre, je joue. Sous wine, en utilisant virtualgl pour addresser le GPU qui va bien (en fonction du jeu).

Dans de rares occurrences, je veux pouvoir faire cela sous Windows aussi, avec la carte NVIDIA et l'ATI. a) pour tester mon code et b) pour jouer.

Solution a) Je reboot tout, c'est lourd. Solution b) Je peux seulement "désactiver" les GPU NVIDIA et ATI et booter la VM dessus. Comme cela je garde ma session "bureautique" qui tourne sur le GPU intégré Intel, mais je peux booter un Windows à performance "native" sur les deux autres GPU.

Beaucoup de bugs pourrait être évités avec un warning/erreur qui vérifie la consistance de l'indentation, et c'est bien plus simple à implémenter qu'un outil qui vérifie le code mort. Ici il y a un goto qui n'est pas correctement indenté.

Cela pourrait aussi sauver le cas horrible de :

for/if/while(...)      ;
   // block toujours executé

C'est le débat python versus le reste du monde et l'indentation significative qui ressort ;)

(edit: toutes mes excuses, c'est le débat du second lien)

Je tuerais pour avoir cette fonctionnalité dans les barres de menu de i3 par exemple.