jyes a écrit 925 commentaires

le système actuel est […] le moins pire qu'on ai pu faire jusqu'à maintenant

Et ça durera ainsi tant qu’on essaie pas de l’améliorer !

Je ne remets pas du tout en question ton commentaire avec lequel je suis dans l’ensemble relativement en accord, mais si les “client side decorations” de Gnome sortent par les trous de nez, tu n’es pas complètement obligé de les subir. On peut contourner les choix douteux de GTK3 en la matière avec le petit outil suivant :
https://github.com/PCMan/gtk3-nocsd

Pas besoin de casser la même couche tous les dix ans, il suffit d’assurer un roulement bien organisé pour garantir une expérience utilisateur de qualitay : il suffit de casser le serveur d’affichage (X.org/Wayland) juste quand les environnement de bureaux principaux redeviennent stables (on a encore des thèmes GTK incompatibles à chaque nouvelle version donc X.org peut encore attendre un ou deux ans avant qu’il soit nécessaire de le remplacer). Pour assurer le coup, entre temps, au cas où Gnome et KDE se seraient rétablis trop vite, il aurait suffit de changer la gestion du son (pulseaudio) ou des services (systemd) pour introduire des périodes de transitions bancales. Heureusement, tout ça n’a jamais eu lieu.

Ce dernier “l’a emporté” par la suite et c’est dommage.

Ce n’est pas « dommage », c’est le résultat d’une politique de masculinisation volontaire de la langue dans laquelle l’école et les programmes éducatifs ont joué un rôle fondamental. Les règles du « bon français » ont été imposées à l’école à la même époque où l’on condamnait l’usage des patois.

la population ici est trop à droite pas assez à gauche

Ah, les dinos partouzeurs de DLFP!

Et c'est bien le problème : la démocratie n'est pas la dictature de la majorité

Cette maxime est vraie, mais la démocratie ce n’est pas non plus censé être une dictature d’une minorité, fût-elle élue tous les 5 ans. Elle n’infirme donc en rien les critiques émises dans ce fil de discussion.

Et ouais, comme quoi, etre intermédiaire, c’est pas si évident que ça.

À peu prêt comme tout métier qui demande une position de quasi-monopole. Et, en quoi ça contredit l’argument de Strash ?

makedepf90 fonctionne bien mais il tombe dans la catégorie des outils spécifiques à un langage. Je l’avais essayé il y a quelques temps et en avais gardé un souvenir mitigé, mais je l’ai réessayé suite à ta suggestion et il semble effectivement faire du très bon boulot. Merci de l’avoir rappelé à mon souvenir.

On peut tout de même garder son calme. D'une part tous les langages sorti depuis 10 ou 15 ans ont résolu par conception l'ensemble de ses problèmes

Les langages oui, les chaines de compilation non.

Pour le moment, les seules fois que je connais où le problème est réglé, c’est quand on code avec un seul langage, et qu’il a son propre outils de construction. Mais tous ces outils spécifiques ne connaissent qu’un langage à la fois.

À l’inverse, le Fortran (post 90) fonctionne avec des modules, ce qui résout le problème des dépendances proprement, mais aucun outil de construction ne les interprète correctement. Ma solution actuelle, c’est un script shell qui construit un Makefile.in en lisant les fichiers sources, mais ce n’est pas très robuste (à moins de réimplémenter tout un interpréteur Fortran dans mon script).

Du coup, je trouve smk très bien pensé et non seulement j’approuve la remarque de Michaël, « La meilleure façon de capturer les dépendances […] est de tracer les appels système » mais je ne connais aucun exemple d’outil générique qui fasse du bon travail autrement.

J’applaudis aussi des deux mains et des deux pieds ! Justement, ça faisait un moment que je saturais des outils de “build” modernes qui soit se limitent à un langage, soit ont une détection des dépendances catastrophique malgré leurs promesses. En comparaison, je trouve l’idée de smk vraiment bonne.

La seule limitation que j’y vois pour que je me mette à l’utiliser, c’est la gestion des profils. J’imagine qu’entre ce que l’auteur présente dans le texte avec ses « sections » et des substitutions de variables, il sera à terme possible de très bien s’en sortir. En attendant, je n’écris quasiment jamais les Makefile à la main, mais c’est un script « ./configure » qui l’écrit, en le paramétrant en fonction du système et d’options (compilateur trouvé, bibliothèques disponibles). Un tel paramétrage peut être envisagé avec des variables dans le « smkfile » et éventuellement des sections (qui pour les cas simples remplaceraient même complètement le « ./configure »).

En tout cas, super idée, super outils ! Je suis impatient de voir la suite.

Et puis, on pourrait avoir une page tendances pour les bulles !

Un exemple, pas parmi les plus gros services du web, mais filesender ne permet pas de télécharger les fichiers partagés depuis Firefox.

les textes des commits (ou même des révisions intermédiaires du code) faisaient référence à des éléments internes à LG

J’ai le même problème avec un code que j’aimerais libérer, mais dont l’historique est plein de verrues que je ne peux pas partager. Il finira probablement par être libéré sans historique (et un historique publique reprendra à partir de là).

Pour me simplifier la vie, maintenant je choisi mes contacts en fonction de l’appli de messagerie qu’ils utilisent.

Depuis, je n’ai plus d’autre contact que ma mère mais au moins j’utilise GNU/Ring !

En même temps, le P2P c’était beaucoup de partage et peu d’organisation et c’est le seul piratage auquel se sont réellement attaqués les industriels du divertissement. Le streaming et dérivés sont la solution technique à disposition du pirate-consommateur pour se cacher. Ça le rend aussi dépendant d’un pirate-hébergeur qui en profite pour rendre la chose lucrative, via de la pub, du minage de cryptomonnaie en javascript ou autre innovation disruptive de la cyber-startup-nation des méchants (celle des gentils développe les outils de filtrage automatisés pour Youtube et Facebook, pour rendre l’offre illégale encore plus attractive).

C’est l’industrie du divertissement qui a fait la place pour un business model viable sur le piratage.

Pas de réécriture de l'historique, comme en compta, on ne supprime pas ses erreurs, on les corrige, chaque action de correction laisse une trace dans la timeline (je déteste git rebase perso)
Git, son utilisation est bien trop complexe et les risques de perdre du taf trop importants.

Depuis que j’ai découvert son existence, j’ai toujours trouvé Fossil intéressant sur le principe mais n’ai jamais vraiment appris à m’en servir. Pourtant les tickets distribués avec le répo de code, je trouve le principe excellent. Mais, ce que tu écris ci-dessus est une limitation qui fait que je n’imagine pas l’utiliser un jour. Je ne comprends pas comment tu peux ne pas aimer le rebase et trouver que les risques de perdre du taf trop importants avec Git en même temps. Le rebase, c’est justement ce qui fait qu’en codant, dès que j’ai touché à plus de 10 lignes, j’enregistre un commit. Ce commit n’a pas vocation à durer, mais à m’assurer que je peux revenir à cet état facilement. Une fois que j’ai une fonctionnalité qui marche (ou du moins le crois-je) je regroupe les commits en opérations unitaires liées par la logique (et si j’ai touché d’autres trucs à côté pour me faciliter les tests, je les enlève des commits). J’ajoute des descriptions et j’ai une séquence de commits qui correspondent chacun à un patch le plus indépendant possible des autres et dont l’impact sur le code est clair.

J’ai donc des sauvegardes permanentes de mon code, y compris des commentaires personnels que je ne compte jamais partager, et un historique de développement clair. Comment faire cela sans rebase ?

De plus, en committant tout tout le temps, on se met bien à l’abris des fausses manips, même des "git reset --hard" malencontreux au milieu d'un rebase en cours se retracent finalement bain avec "git reflog".

Bon, comme tu le vois, j’aime bien Git. Mais mon commentaire est surtout là pour que tu m’aides à identifier comment je pourrais modifier ma manière de faire si je voulais utiliser Fossil, pas pour te dire combien Git est mieux. Concrètement, avec Fossil, tu travailles comment ?

De ce que j'en sais, aux US, ça roule quand même un peu mieux,

Ce n’est pas mon expérience. On y trouve facilement six voies dans le même sens, mais elles sont largement aussi saturées que nos deux voies en période de pointe. Et pourtant mon expérience des US est surtout dans des villes et des régions aérées et/ou bien complétées de transports en communs corrects.

Oui et c'est facile: vim est interactif

On peut aussi l’appeler avec la commande ex ou vim -e qui en fait un très bon remplaçant de ed.

Après lecture du code d’Android (8.0.0_r4), je contredis mon intuition précédente : une réponse locale est acceptée.

Par contre, pour qu’une réponse soit valide il faut qu’elle retourne un code HTTP 204 ou un code HTTP 200 à condition que le contenu soit vide. Or le serveur donné en exemple retourne 200 et un contenu HTML qui affiche « Success ». C’est donc la réponse du serveur local qui ne fonctionne pas.

Il y a une exception à cela, c’est si la connection utilise un script PAC, auquel cas c’est l’adresse du proxy qui est testée, et s’il retourne un code 200, la réponse est valide.

L’erreur ne doit donc pas être dans la configuration réseau, mais à la ligne 7 du script captive_alternative.bash.

Je n’avais pas précisé ça dans ma réponse précédente, mais le service qui fonctionne chez moi est bien réglé pour retourner un code 204 (j’avais déjà un nginx sous la main et n’ai donc pas utilisé le script indiqué sur la page wiki).

Donner des privilèges à un executable pourquoi pas […] mais le problème c'est que cela semble lié à l'éxécutable

Ce n’est pas la solution présentée dans cette dépêche. Ici, ce qui est présenté; c’est une alternative à su/sudo qui repose sur les « capabilities » et rend ce mécanisme de sécurité utilisable relativement facilement. C’est justement une réponse aux limitations que tu soulèves (et c’est expliqué dans la dépêche).

Pour mettre en place une alternative, ne vaut il mieux pas changer les réglages du téléphone que de rediriger via le DNS tous les services connus de détection de portail captif vers un serveur local ? Ici une doc plutôt bien fichue: https://android.stackexchange.com/questions/186993/captive-portal-parameters. Il y a le service Apple mentionné dans la page wiki, mais Google a aussi les siens ainsi que Qualcomm et plein d’autres.

Suite à la lecture de cette page wiki, j’ai créé mon propre service et l’ai utilisé dans mon téléphone, c’est sûrement plus efficace que le contournement DNS.

Par contre, mon service est accessible via une IP publique, je ne serais pas surpris qu’Android refuse explicitement les adresses privées, justement pour ne pas faire croire à l’utilisateur qu’il y a accès à Internet quand, en fait, ce n’est qu’une machine locale qui répond. Accepter une réponse locale serait à l’opposé exact de ce à quoi est censé servir la détection de portail captif.

Juste pour compléter, je ne sais pas ce qui posait problème hier, mais j’utilisais un script de compilation avec beaucoup trop d’options et j’ai du me mélanger les pinceaux. Mes essais d’aujourd’hui m’ont montré que MALT profile bien mon code avec tous les niveaux de compilation.

Du coup, j’ai pu constater que l’option "-fstack-arrays" faisait disparaître le "malloc" étonnant. Par contre, vu ce que fait cette option, reste que la copie inutile du tableau doit encore avoir lieu, elle est juste cachée, mais ça, ce n’est pas du ressort de MALT.

Merci pour cette réponse détaillée !

Je confirme que les allocations étonnantes apparaissent lors du passage d’une « allocatable array » comme paramètre d’une fonction qui attend une « assumed-shape array (intent(in)) ». Normalement, il n’y a pas de raison de faire une copie, mais il semble bien que ce soit GFortran qui en ajoute une (version 6.3.0, je devrais peut-être aussi essayer avec une plus récente). C’est pourquoi, je me disais que peut-être que cette allocation inutile disparaîtrait à un niveau d’optimisation supérieur. Je testerai avec IFort pour comparer. Le code en question n’est pas open-source (bien qu’il devrait « bientôt » le devenir).

En tout cas, après une utilisation un peu plus longue de MALT, j’ai fait deux découvertes agréables :
- mon code ne semble finalement pas si mal codé :-) (au moins du point de vue des allocations, les cache miss que m’indiquent callgrind sont plus difficiles à améliorer) ;
- MALT est vraiment pratique et je m’attends à ce qu’il m’aide beaucoup sur d’autres codes de calcul (notamment un en C++ où beaucoup d’objets sont créés et détruits mais je ne sais pas a priori lesquels ont une incidence importante sur le temps de calcul).

Merci pour l’outil. Merci aussi pour la proposition d’aide. Il se trouve que MALT est assez facile à utiliser pour que je n’en aie finalement pas besoin. Prochaine étape, tester NUMAPROF !

Je viens d’essayer MALT sur un code de calcul de mécanique des fluides que je développe en Fortran. Je testerai NUMAPROF plus tard car pour ces tests, j’ai lancé les calculs sur ma machine de bureau.

L’outil (MALT) semble bien pratique mais j’ai du mal à interpréter le résultat. Quand je regarde les volumes alloués, toutes les fonctions qui se démarquent sont celles d’initialisation, avant les calculs lourds. Ce doit juste être cette métrique qui n’est pas pertinente dans le cas de mon code. En terme de nombre d’allocations, là j’ai une fonction inattendue qui ressort (mais étonnamment, la ligne incriminée pointe son appel, pas l’intérieur de celle-ci). Bien qu’assez improbable vu la nature des paramètres de cette fonction, je me suis dis que ça pouvait être dû à un tableau qui serait passé en copie plutôt que par référence et ai donc tenté avec différents niveaux d’optimisation pour voir si le problème évoluait en fonction des efforts que fait GCC pour rendre mon code performant. Eh bien, je n’ai pas réussi à obtenir quelque-chose de MALT pour un niveau d’optimisation O3 ou avec « link time optimization ».

Du coup, les conditions dans lequel je teste mon code sont assez différentes de celles dans lesquelles il tourne usuellement. C’est une limitation due au Fortran, à MALT ou à mon incompréhension de l’outil ?

J’avoue qu’au départ, je suis mécanicien (des fluides), pas développeur, et je ne serais pas surpris d’être passé à côté d’un truc important.

Merci pour ces outils en tout cas. Il n’y pas grand chose de tel pour étudier les codes HPC et j’ajoute avec plaisir MALT (et plus tard NUMAPROF) à ma trousse à outils.

Arg, j’ai oublié “E”

    integer, dimension(6), intent(inout), optional :: E

pour le cas où l’on souhaite un type “nullable”.