Anthony Jaguenaud a écrit 1967 commentaires

Je suis en accord avec ton post, sauf sur le 32 bits. S’il change de machine, un système 64bits est plus logique, de plus, wine n’a plus vraiment de soucis pour utiliser des logiciels 32 bits sur un OS 64 bits.

Sinon, pour la tradition linuxfrienne un peu d’orthographe : il y a (verbe avoir) ne prend pas d’accent. On pourrait écrire, « il y avait de l’eau dans ce verre. ». Bon je retourne boire mon rhum puisqu’il n’y a plus d’eau…

Je ne vois vraiment pas comment des projets pourraient investir autant dans la performance alors qu'il y a si peu de projet qui investissent la moité dans la correction de leur logiciel.

Oui, je suis d’accord avec toi. C’est la conclusion à laquelle je voulais venir, c’est que d’un côté les projets libres n’ont pas les moyens d’optimiser dans les règles. Et que openBSD n’a pas les moyens d’auditer les optimisations de logiciel tiers. Donc ils ont fait le choix de faire les choses simplement. Avec des exigences perfo simple et pas trop contraignantes. La sécurité est, de leur point de vu, à ce prix.

En général, on optimise pour atteindre un objectif. Si c’est juste pour le sport (passer 1 mois à gagner 3 requêtes par seconde), le code devient crade.

Avant d’optimiser, il faut avoir un objectif. Pour nginx ça pourrait-être livrer 1000000 de pages statique d’une certaine taille par seconde.

Ensuite, il faut vérifier que le code simple initial ne répond pas déjà à l’objectif.

Si ce n’est pas le cas, il faut trouver quels sont les points de ralentissement du logiciel.

Optimiser intelligemment certains points uniquement jusqu’à atteindre l’objectif. Et surtout documenter et prouver chaque optimisation.

En faisant tout ça dans les règles, optimiser coûte cher. C’est simple de gagner au début en organisant correctement les données en fonction de l’usage : ne pas utiliser des listes chaînés si on accède principalement par index…, mais gratter les dernière μs pour passer en dessous de 1 ms sur des processeurs pas tout jeune, en étant capable de prouver qu’il n’y a de régression, ce n’est pas évident.

Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas. Après, les goûts et les couleurs…

Moi, quand j’ai vu l’exemple de la liste de fibo infinie, et on demande la valeur qu’on veut, comme l’index de la liste, je me suis mis en tête de faire la même pour les nombres premiers. Je suis d’accord que dans ce cas, l’exercice est intéressant pour le style, pour la lisibilité…

prem = 2:[a | a <- [3,5..], (product (map (\x -> mod a x) ([3,5..truncate(sqrt (fromIntegral a::Float))]))) /= 0 ]
prem' = 2:[a | a <- [3,5..], (product (map (\x -> mod a x) (takeWhile (<= truncate(sqrt (fromIntegral a::Float))) prem'))) /= 0 ]
prem'' = 2:[a | a <- [3,5..], (all (/= 0) (map (\x -> mod a x) (takeWhile (<= truncate(sqrt (fromIntegral a::Float))) prem''))) ]

Il m’a fallu deux jours pour aboutir… la version la plus rapide est la liste prem''.

Sinon, je trouve haskell plutôt simple et clair. Il faut rentrer dans le langage, mais comme dans tous. On peut y écrire des trucs affreux comme dans tous.

Je crois que le problème vient plus de l’usage détourné de certaines spécificités :

c = (toto % 2 ? add: mult)(a,b);

(f) && f(param1);

(p) && delete (p) || (p = new(int));

C’est évidemment lisible, mais rarement au premier coup d’œil. Après, j’ai connu l’excès inverse sur certains projets, où pour simplifier on interdit plein de construction du langage, et tu te retrouves à recoder ou contourner les limitations imposées…

Le print d écrit 0.0 donc float sinon ce serait : 0 comme l’autre.

La division entière est définie de

Donc comment définir le résultat de 15,1 / 5,1 ?

• Ça revient à 15/ 5 == 3 ?
• Ou E(15,1 / 5,1) == 2 ? (15,1 / 5,1 == 2,96… la partie entière vaut donc 2)

Et ton message révèle en beauté pourquoi c'est moche de forcer l'indentation…

Sérieusement, c'est le truc qui m'empêche de me mettre au python. Après tout, l'indentation, je sais que c'est nécessaire, mais j'aime avoir la liberté de choisir celle que je préfère, et il y à même des gens qui ont créé astyle, qui permets de pull un projet avec mon codestyle, et de le push avec le codestyle d'origine.

Honnêtement, quand tu arrives sur un projet, c’est chiant de faire comme tout le monde au niveau de l’indentation… mais quand tu es sur la troisième version d’un projet, avec 30 personnes qui bossent dessus, tu es content que les deux premières versions respectassent des règles de codage… parce que sinon, avec 2 × 30 personnes avant, sur différents composants, je te raconte pas l’horreur de te retrouver dans un code où chaque fichier suis un template différent.

Je suis d’accord pour dire que c’est contraignant et nécessaire.

---

P.S.: À la place de respectassent, j’avais initialement écrit respectaient… mais antidote RX m’a dit de l’écrire ainsi.

Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques. C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.

Bah, la différence, c’est que ta variable est var :
est différent de ou plutôt .

Et expliquer : « L’ordinateur est un peu stupide, il ne sait pas additionner un nombre de avec un nombre de … ». Les élèves comprennent. Àmha.

Je rejoins ceux qui disent que les fonctions préfixés nuisent à la compréhension. Un langage plus proche du langage naturel me semble mieux.

Néanmoins, il y a vers la fin de la page principale un système de boite permettant de faire de la programmation visuelle, un peu comme dans scratch. Je trouve ça pédagogique, quelqu’un sait-il si ça existe pour d’autre langage ?

Les IO j’ai à peu près compris (j’espère), mais je n’en suis pas là. J’ai lu Tutorial Haskell pour le développeur C et j’ai lu un peu plus de la moitié de Apprendre Haskell vous fera le plus grand bien ! j’ai fini le chapitre 9. Mais c’est dense, il me faut un peu de temps pour croire comprendre les concepts… je dois parfois relire plusieurs fois. Et j’ai surement oublié des trucs lus par manque de pratique.

Est-on obligé d’écrire : <int> ou le compilateur peut-il le déduire seul ?

Bon, j’ai essayé ce code :

// includes …
int main() {
  auto square = [](auto x) { return x * x; };
  auto twice = [](auto x, auto f) { return f(x) + f(x); };

  std::cout << twice(5,square) << std::endl;
  std::cout << twice(5.1,square) << std::endl;

  return 0;
}

Le but étant de vérifier comment il instancie les différentes versions en fonction des types.

Compilation :

$ g++ -std=c++11 main.cpp
main.cpp: In function 'int main()':
main.cpp:29:25: error: parameter declared 'auto'
   auto square = [](auto x) { return x * x; };
                         ^
main.cpp: In lambda function:
main.cpp:29:37: error: 'x' was not declared in this scope
   auto square = [](auto x) { return x * x; };
                                     ^
main.cpp: In function 'int main()':
main.cpp:30:24: error: parameter declared 'auto'
   auto twice = [](auto x, auto f) { return f(x) + f(x); };
                        ^
main.cpp:30:32: error: parameter declared 'auto'
   auto twice = [](auto x, auto f) { return f(x) + f(x); };
                                ^

…

Je ne suis pas un pro du C++11, quelqu’un pourrait m’expliquer ?

Je croyais qu’il fallait éviter les monades si possible pour faire du « pur »…

Sinon, pour square, quitte à définir la fonction sans paramètre, j’aurais écrit :

square :: Num a => a -> a
square = (^2)

Quand à ton deuxième code, j’ai du mal à comprendre l’avantage à part rendre obscur une fonction simple.

J’ai bien aimé la blague ;-) donc en C++ :

int twice(int x, int (*f)(int))
{
  return f(x) + f(x);
}

int main() {
  int (*square)(int) = [] (int x) { return x * x; } ;

  twice(5,square);

  return 0;
}

Avec des types génériques :

template <class T> T twice(const T& x, T (*f)(const T&))
{
  return f(x) + f(x);
}

template <class T> T square(const T& x)
{
   return x*x;
}

int main() {
  twice(5,square);   // Évalué à 50
  twice(5.0,square); // Évalué à 50.0

  return 0;
}

Je n’ai pas essayé à faire une lambda template. Les objets de type T pouvant devenir gros, j’ai décidé de passer les paramètres par référence, pour préciser au compilateur que l’objet ne serait pas modifié, j’ai ajouté const. Ce que je n’ai pas fait sur le premier exemple avec des paramètres par copie.

En haskell :

twice :: (Num a) => a -> (a -> a) -> a
twice x f = f x + f x

square :: (Num a) => a -> a
square x = x * x

Dans ghci :

Prelude> twice 5 square
50
Prelude> twice 5 (^2)
50

Les déclarations de type ne sont pas nécessaire, mais permette de garantir que la fonction prend un type numérique et retourne le même type. Fonctionne avec Int, Integer, Float, etc.

à part les extrémistes, il n'y a personne de "divisé".

Ouai, alors là, tu m’insultes… je suis dubitatif sur le projet en lui même pour différentes raisons, mais me traiter d’extrémiste, je trouve que tu y vas un peu fort.

Il semble confortable pour les « fan » de traité ceux qui ne suivent la sainte parole aveuglément de les traiter d’intégriste…

J’aurais tendance à dire qu’il faut regarder le pour et le contre. Mais c’est parce que je suis intégriste !

C'est quand la dernière fois que t'as eu une carte Ethernet qui ne fonctionnait pas directement

Pour moi, c’est quand j’ai passé ma femme sous GNU/Linux… carte mère qui fume, changement en urgence, elle avait un truc à faire pour le lendemain. Après les x redémarrage, pas de carte réseau, ni d’USB pour transférer les drivers depuis mon PC. Donc switch sous GNU/Linux.

C’est ce que fait img.linuxfr.org, si l’image disparait, elle reste dans le cache du site pour toujours. Si elle est modifiée, alors, la nouvelle apparaitra.

C’est ce que m’avait répondu quelqu’un sur un commentaire il y a un moment… je n’arrive pas à remettre la main dessus.

Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais… si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut
* ni ajouter de breakpoint à la volée
* ni modifier de variable à la volée
* ni faire du pas-à-pas

Non, ce n'est ni ce que j'ai dit, ni ce que je crois.

Dans quel monde tu vis ?

Dans un monde où les bancs industriels coûte cher, ils sont donc partagés. Donc quand tu as une après midi sur le banc pour faire tes tests, tu y restes coûte que coûte. Si tu trouves un bug rapidement à 14h30. Tu as deux choix, soit tu corrigse et recompiles, mais le temps de recompilation (4h) me donnera un nouvel essai dans, heu ben demain en fait. Sauf que le lendemain, je n'ai pas de créneau avant 16h.
Pour optimiser mon temps sur le banc, je recommence en « corrigeant » le bug dans le débugger. A ce point, j'ai deux choix, soit je contourne le bug à chaque fois manuellement (avec une interface graphique), avec gdb, je peux scripter cette partie et gagner du temps.

Il est possible qu'une bonne interface graphique de debug permette de scripter, mais je n'en connais pas.

Est-ce qu'avec ton gdb tu peux exprimer une condition pour activer ou non un breakpoint (genre "arrête-toi ici seulement si ceci et cela" en ayant accès à toute l'expressivité de groovy et même ta logique métier) ?

Oui.

Est-ce que tu peux sélectionner une ligne de ton programme et cliquer/taper le raccourci clavier "j'ai pas mis de breakpoint mais relance le flot d'exécution jusqu'à cette ligne peu importe ce qu'il se passe" ?

Je ne suis pas sûr de comprendre le « peu importe ce qu'il se passe ».

Est-ce que tu peux abandonner le contexte courant ("drop frame" dans IntelliJ, désolé flemme de chercher mieux) en revenant au début de ta méthode et en remettant tout le contexte (variables, paramètres, etc.) dans l'état où il était au début histoire de revoir ce qu'il se passe ?

Je ne sais pas le faire, mais il me semble que gdb sait faire depuis quelques versions.

Moi j’ai eu des cas, ou tu as du matériel de test pendant 4h. Tu trouves un premier bug, mais si on le corrige, il y a 5h de recompilation… donc, pouvoir scripter un test, ajouter un breakpoint, modifier une variable avancer de 5 instructions, remodifier une variable, pour enfin être prêt à trouver un deuxième bug… et bien je suis content que gdb soit en ligne de commande, qu’on puisse lui passer des scripts, etc.

Après, pour des softs avec IHM, un débogueur en IHM aussi peut suffire.

Tu sais, dans l’industrie, j’ai des clients qui nous demande encore visual 6… alors tu sais…

Pour ton information, kdevelop, qtcreator, emacs sont très bien, font de la très bonne complétion. Kdev te propose même les inclusions. Visual a aussi pas mal progressé que ce soit au niveau du compilateur comme de l’IDE… mais personnellement, pour faire des remplacements, compilation… je préfère une ligne de commande. C’est juste une question de gout et d’habitude.

À la maison, firefox 24.5.0 ça marche. Avec konqueror 4.12.5 j’ai un souci de css… les trois colonnes se trouvent les unes à la suite des autres verticalement.

Sinon, je trouve que c’est une belle IHM locale, mieux que gitk.

Bonjour,

Sur une debian stable sous kde, il démarre konqueror et j’obtiens les erreurs suivantes :
Erreur : http://localhost:8000/js/jquery.min.js : TypeError: Attempt to use a non-function object or a value as a function.
Erreur : http://localhost:8000/js/bootstrap.min.js : Error: Bootstrap's JavaScript requires jQuery
Erreur : http://localhost:8000/js/git-webui.js : ReferenceError: Can't find variable: $

Je me dis qu’il y a peut-être une dépendance silencieuse à JQuery ?

J'ai dû mal comprendre le problème initial, car pour moi on parlait de la longueur du nom du répertoire ou du fichier. Pas de la profondeur de la récursivité (--depth).