Anthony Jaguenaud a écrit 1957 commentaires

… à tout le monde, mais dans ce cas, pourquoi ne pas poser quand même la question et la réponse comme je l’ai fait ici. Ce n’est jamais inutile, si quelqu’un se pose la même question.

Après, ça arrive souvent quand tu expliques quelques chose à quelqu’un pour qu’il t’aide tu poses les choses pour être sûr qu’il comprenne et du coup, tu dépoussières ton cerveau et trouve la solution.

Il semble que liquid prompt te fournisse un script qui fait ça seul. Il faut donc « sourcer » liquidprompt.
Je reprends ci-dessous le exemple.bashrc :

# if you want to use the liquidprompt without bothering about its configuration,
# just:
# cp example.bashrc ~/.bashrc
# This part is a minimalist bash config file example
# Use the system config if any
if [ -f /etc/bashrc ]; then
. /etc/bashrc # --> Read /etc/bashrc, if present.
fi
# Use bash completion, if installed
if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
# If you have your own config for the liquid prompt, edit and uncomment this line:
# source /path/to/liquidpromptrc
# Use the liquidprompt
source ~/.liquidprompt

Les dernières lignes doivent être dans tes bashrc. Soit directement une fois sous le home de ton utilisateur, et une pour ton root. Soit une seule fois dans /etc/bashrc pour tous les utilisateurs à condition d’avoir les lignes : if [ -f /etc/bashrc ];… pour chaque utilisateur voulant l’utiliser.

Si tu mets la modification dans le /etc, pense bien à mettre le chemin complet vers le script liquidprompt car le raccourcis ~ est différent en fonction de l’utilisateur.
Après, je ne l’ai même pas essayé car je trouve qu’il y a trop d’info sur le screenshot et que mon prompt actuel me convient.

J’espère avoir été clair, mais si tu ne connais pas le shell c’est peut-être encore obscur…

Il faut que tu définisses ton PS1 dans le bashrc de root, où dans le bashrc général (/etc/bashrc). S’il est dans le général, il faut peut-être ajouter une ligne du genre : . /etc/bashrc dans /root/.bashrc histoire de mettre à jour ton environnement shell.

De mémoire, si tu envoies en texte, il coupera les lignes au moment de l’envoie, pas lors de la rédaction (dans mon souvenir). Tu peux essayer de t’envoyer un mail pour vérifier.

J’ai un prompt personnalisé depuis 2005, je suis très loin de ce qui est présenté ici, mais ça marche pas mal.
Au départ, je recalculais tout tout le temps, et le prompt finissait par s’afficher en 2s, très énervant. Finalement, la solution que j’ai appliquée, c’est une variable MYPROMPT mise à jour à chaque commande cd. L’optimisation du script à également aidé.

Mon prompt ressemble à ça :

login:[AJa]/.../rép1/rép2/rép3 [RW] $

login:[AJa]/...pertoire_trop_long/rép3 [RW] $

Le login est géré par bash, le [AJa] est un remplacement réaliser par des expressions régulières. Construit à partir de ls /home puis un finger et un sed ou awk pour récupérer le tri-gramme. Les expressions régulière sont dans un fichier de conf. Ensuite on affiche entre 1 et 3 (personnalisable) répertoire mais avec un maximum de 40 caractère.

Le RW s’affiche en vert ou rouge en fonction des droits d’écriture dans le répertoire courant.

Le calcul de la deuxième partie est faite par la commande cd qui est une fonction appelant le builtin cd.

Je m’étais également ajouté une commande xcd allant chercher dans mon fichier d’expression régulière pour aller directement dans le répertoire associé.

login:[AJa]/.../rép1/rép2/rép3 [RW] $ xcd AJa
login:[AJa]/ [RW] $

Le tout compatible GNU/Linux, SUN et HPUX. Enfin, à l’époque…

Je ne t’ai pas moinsé, mais tu es néanmoins dans l’erreur. De mémoire, weboob stocke les mots de passe quelque part sous ~/.config/weboob. Rien ne t’empêche si tu as plusieurs utilisateur de changer les droits des répertoires. ssh le rend obligatoire, ça pourrait être une évolution intéressante d’avoir des droits pour le seul utilisateur de la session. Après, dans tous les cas, c’est à toi de sécurisé ta session.

J’ai installé WOT sur le firefox de mon fils en mode enfant. Je n’ai pas pris le temps de me pencher vraiment sur les système disponible sur debian.

Je ne connais pas les systèmes sous GNU/Linux. Si l’un d’entre vous à des connaissances et veut les présenter dans un journal ou une dépêche, je serai ravi de le lire.

S'il y a une vérification dans l'interface graphique

Bah, pardon, mais il n’y a pas d’interface graphique en web. Juste un fichier décrivant une interface qui est interprété par le navigateur. Si celui-ci est firefox il affichera la page d’une certaine manière, si c’est IE il le fera autrement. Et Weboob le fait encore de manière différente.

Après, de ce que j’ai compris, weboob a un navigateur, qui fourni les données à un module de traitement spécifique au site, qui fourni les données à l’interface de manière spécifique au type d’application (banque, site de rencontre…). Tu peux faire la même chose avec un script et lynx ou links… À moins que lynx et links ne soient pas des navigateurs web.

Et quid des vilains appareille pour le braille, il dénature aussi le site ?

J'ai quelque installations depuis un an sur du matériel très récent (des portables avec la dernière famille de CPU intel) et l'installation était technique avec stable et triviale avec testing

Je confirme cela, néanmoins, pour être tranquille, j’ai opté pour le kernel et les firmwares en backports, et le reste en stable.

Aucun intérêt de tout avoir dans un même logiciel.

Sauf quand il faut relier l’information. Nous avons eu le cas sur un projet, liste des exigences dans un .doc, code dans plein de .c, et matrice de traçabilité dans un .xls. Objectif : corriger et vérifier l’ensemble :

• Chaque fonction doit être relié à au moins une exigence.
• Chaque exigence doit être relié à au moins une fonction.

Un collègue, maîtrisant la bête, à en 3h, coder une série de fonctions pour vérifier la traçabilité du code avec les exigences. De plus, grâce aux ctag, il pouvait aller de la doc au code… Je ne connais aucun outils permettant de faire ça aussi vite. D’autant que du coup, c’était réutilisable à chaque nouvelle livraison d’un avenant.

Certes, pour le faire il faut connaître, mais écrire des plug'in pour différents IDE n’est pas trivial. Dans emacs, tu essayes en live dans ton interpréteur puis, quand ça marche tu le sauvegardes ou pas.

Quel est pour toi l'avantage d'un seul return?

Sur une demande de modification, tu dois modifier la fonction après, 1 mois, 5 ans… si la fonction est grande avec de multiple return, tu as une bonne chance d’insérer du nouveau code après un return qui sera passé à cause d’une condition. Alors tu finiras par trouvé, mais tu perds un peu de temps. Je suis assez partisant également d’un seul return. Parfois, tu as du code bizarre genre :

…
if (retVal != NOError)
{
    …
}

if (retVal != NOError)
{
    …
}
…

return retVal;
}

mais le compilateur fait lui même le return ou le goto. Et le code est séparé en petits blocs ce qui aide à comprendre rapidement l’algo global. Après, sur ton exemples avec peu de ligne, je suis d’accord que ce n’est pas un problème.
Mais les « règles » ne sont-elles pas là pour être contournées ?

Si tu veux faire intervenir la personnalité de ton interlocuteur dans une discussion,

Je te prie de m’excuser, mon but n’était pas d’insinuer ce que tu as cru comprendre. Ce que je voulais dire, c’est que nous n’avons pas la même approche du fait que nous n’avons pas les même contraintes.

J’ai beaucoup d’estime pour les chercheurs, car, de ce que je crois en percevoir, ils ont du temps pour réfléchir, tester en efficacité et performance des nouveaux algo. Ce qui lorsqu’on peut lire les publications sert au plus grand nombre.

Sur l’ensemble de ce que tu écris je suis d’accord, je voulais juste apporté une nuance, car en te lisant j’avais compris : « Pour programmer, il faut absolument comprendre l’architecture d’un processeur. » Je voulais nuancer en disant deux choses :

• La première : qu’optimiser ne doit pas être le but. Le but c’est de répondre à une exigence. Si cette dernière est : « Faire le plus vite possible » alors pourquoi pas. Mais si le but peut-être atteint sans nuire à la lisibilité, alors tant mieux, même si ce n’est pas le plus rapide. C’est la différence entre assez et plus rapide.
• La deuxième : c’est que des étudiants ou de jeunes ingénieurs peuvent croire en lisant cela qu’il est impératif d’optimiser à mort, et je voulais nuancer cela.

Ceci me semble bien naïf. Un compilateur compile, il ne comprend rien.

Pour avoir testé des boucles imbriquées simple avec accès par indice, ou par pointeur, les compilateurs aujourd’hui et depuis quelques années sont capables de d’analyser le code et de l’optimiser. Souvent il fait beaucoup mieux que l’ingénieur moyen que je suis d’après ton reproche. Hélas nous sommes nombreux à n’être que très moyen, et pour s’adapter à ça, il me semblait intéressant de préciser que l’optimisation ne devait être que la réponse à un vrai besoin. Pas juste pour se faire plaisir. (Tu noteras que j’évite le terme de masturbation intellectuelle que je qualifierais d’ailleurs volontiers le gars qui a fait ça, et ce n’était pas péjoratif dans mon esprit).

Et plus généralement, qui de sérieux peut cracher sur un facteur 10 ?

Bah, si tu passes 10s dans un algo qui prend 4h, le fait qu’on peut passer que 1s dans cette partie, ramené à 4h, ça fait une belle jambe.
Je me souviens étudiant, on cherchait à optimiser des boucles de remplissage de triangle. On passait au final 90% du temps dans la fonction putpixel. Qui ne prenait déjà que l’accès RAM. Sachant que on écrivait en ligne, les caches de l’époque étaient mis à contribution. mais on ne pouvait raisonnablement gagner que dans les 10%. Cela valait-il l’effort, nous avons laissé là notre TP.
Ce que je veux dire par là, c’est que, dans mon métier, il faut choisir les endroits où tu optimises. Pour les chercheurs en algo, si j’ai bien compris, c’est de prendre un algo (× de matrice) et l’optimiser à mort. Ce n’est simplement pas comparable.

Bon, j’espère m’être mieux exprimé, et ne blesser personne cette fois ci. Et que mon propos sera mieux compris.

On ne parle pas de la même chose. D’un côté vous parlez de calcul scientifique, recherche modification d’algo pour gagner du temps. Quand l’algo est prêt, après plusieurs années de recherche, il est publié, intégré dans une bibliothèque et utilisable.

De l’autre, je parle rationalisation, coût.

Le problème à la base est de savoir si openBSD a raison de refuser les optimisations qui nuise à la lisibilité du code. Je réponds : « oui ». Car openBSD est la comme serveur, ce n’est pas un super calculateur numérique.

Quand à ta remarque :

Tu n’as vraiment pas l’air de bosser dans le domaine.

Tu as raison, je ne suis pas mathématicien, je suis spécialisé dans le temps réel aéronautique. Ce qui nous intéresse par exemple, c’est de garantir que l’information du capteur vts, alt soit afficher au pilote en moins de x ms. On s’en fout complètement de rendre l’algo obscure pour donner l’information en x÷5, car le coût induit en test, certification etc. explosera d’un facteur × 10 ou plus.

Mon expérience, d’optimisation est là. Quand ça passe pas, il faut trouver une solution. Le plus contraint que j’ai eu à optimiser, c’est sur un calculateur relier à d’autre par 3 bus différents. Où il fallait caler les échanges bus + les calculs en dessous de 1ms. Avec un proc PowerPC en dessous de 1GHz. On a fait des analyses de ce qui passait sur les bus (vive les analyseurs PCI). Quand on a atteint les 987μs, on a fait validé le produit.

L’utilisation de la carte graphique 3D permet de faire des choses sympa et joli. Je suis d’accord que compiz était too much, mais avec kwin (de kde), tu peux en utilisant + éclater toutes les fenêtres et les afficher en petit sur ton écran quelque soit le bureau. Ensuite, avec les flèches tu peux sélectionner la bonne fenêtre. Mais tu peux aussi filtrer en tapant le nom du logiciel, du titre de la fenêtre (contenant souvent le nom du fichier ouvert…). Personnellement, je trouve ça très ergonomique, joli et surtout sans sortir les mains de mon clavier ;-)

Oui et non.

Oui, je suis d’accord sur le principe, mais dans la pratique, le coût non négligeable de te baser sur des euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération, car :

• Les lignes de cache ne feront plus la même taille,
• La prédiction de branchement sera plus efficace,
• Le cache sera plus gros et tout tiendra dedans.

n’est pas intéressant. Il vaut mieux se concentrer sur les structures de données, et faire des algo compréhensible par les compilateurs de façon à se qu’ils optimisent. Par expérience, à moins d’investir énormément, le choix de l’algo et son codage simple permet au compilateur de donner de très bon résultat.

De plus, tu occultes le fait que tout le monde n’a pas une puce Intel et que dans ce cas, il faut aussi optimiser pour AMD, faire un algo spécial pour chaque ARM, etc.

C’est envisageable quand tu fais de l’embarqué, que tu connais ta cible pour de l’applicatif PC, c’est de la masturbation intellectuelle. C’est ce que je disais dans un autre commentaire, c’est intéressant pour le sport, pour le défi, mais ça n’a aucune importance pour ça.

Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances… mais pour de l’applicatif, ce n’est pas généralisable.

Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. Mais il ne faut pas tomber dans le travers inverse à chasser la dernière ns en dépensant 30 jours de développement.

Je vois que tu es universitaire d’après ton lien page perso. Ce qui explique cela. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)

Sur certains projets, on peut même diminuer une contrainte temporelle si on sent qu’elle risque de coûter trop cher.

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 ?