Jean-Baptiste Faure a écrit 1724 commentaires

Bref oui il est grand temps que Firefox obéissent à ses utilisateurs!

Firefox obéit à ses utilisateurs, quand ils lui demandent quelque chose. Mais combien d'utilisateurs se préoccupent de décider eux-mêmes ?

Très intéressant. À ton avis, en combien de journaux tu pourras traiter tout ça et à quelle fréquence tu pourras les publier ?

As-tu essayé en mettant l'équation comme image PNG ?

Tout ce qui est déduit du comportement de navigation n'est pas fiable, ça ne serait par exemple pas opposable devant un tribunal.

Aucune importance, on n'a pas besoin de l'avis d'un tribunal pour te ficher S, te mettre sur écoute ou te refuser un prêt ou une assurance.

Google n'est pas nécessaire pour utiliser service-public.fr. Chez moi les requêtes éventuelles vers google.com sont bloquées par uMatrix et Firefox LightBeam me montre une icône service-public.fr isolée sans aucun lien vers un autre site.
Je n'ai aucune icône Google dans LightBeam depuis que j'ai l'ai réactivé. Il faut dire que j'ouvre les sites sensibles (en gros la presse) dans des fenêtres de navigation privée séparées.

Qu'est-ce que tu appelles un champ textuel ? Une zone de texte ?

Entre un logiciel que, je cite, «on a besoin d'apprendre à utiliser», et un logiciel qui m'a permis d'aboutir au résultat désiré sans avoir rien à apprendre (markdown, je connaissais déjà, et HTML/CSS, sans le pratiquer énormément, j'en connaissais suffisamment pour obtenir le résultat désiré), appelle ça un problème entre la chaise et le clavier si tu veux, mais moi je préfère le logiciel qui me permet d'obtenir le résultat désiré sans avoir rien apprendre.

Ma critique n'est pas là, elle est dans le fait que tu justifies ton choix de ne pas utiliser LibreOffice-Impress par un lieu commun complètement erroné. Je n'aurais rien trouvé à redire si tu avais écrit que tu trouves la courbe d'apprentissage de Impress trop raide ou que l'acquisition des bases te semble trop longue par rapport à ce que tu peux faire avec les outils que tu maîtrises déjà. Ce sont des jugements personnels parfaitement recevables alors que cette histoire de contenu et de mise en forme est une rengaine qui montre que ceux qui la chantent ne savent pas ce qu'est une suite bureautique et qu'ils confondent ça avec une machine à écrire (bien que probablement ils n'en aient jamais vu à part dans des films).

Cette histoire de contenu et de mise en forme est un lieu commun répété à l'envie pour prouver la soi-disant supériorité de Latex sur les traitements de texte et logiciels de présentation. Il est complètement erroné parce qu'il n'existe pas de contenu sans mise en forme (le code Latex, html ou markdown est déjà une mise en forme) et que la mise en forme fait partie du contenu.

le fait de devoir m'occuper, en même temps, et du contenu, et de sa mise en forme

Comme dans tout bon logiciel la mise en forme est automatique ce qui permet de se concentrer sur le contenu. Il suffit de choisir un modèle, l'adapter à ses besoins (arrière-plan, pied de page, logo, etc.) puis de l'oublier.

Autrement dit si on s'occupe de la mise en forme en même temps que du contenu, c'est qu'on a besoin d'apprendre à utiliser le logiciel, donc un problème entre la chaise et le clavier.

Oui et la licence LGPL est justement là pour éviter ça si on le souhaite.

Le point de départ : https://doc.ubuntu-fr.org/debutant

Pour poser des questions : https://forum.ubuntu-fr.org/index.php et voir les 2 premiers forums.

Je ne comprends pas pourquoi tu écris que ooo.hg est 0% libre. Peux-tu détailler ?

Cela dit ooo.hg n'est pas un logiciel, c'est une extension qui ajoute une collection de cartes à la galerie de LO ou AOO. D'où, je présume, la licence CC.

Le profil de poste indique :

La rémunération est comprise entre 2100 et 2400 € brut selon l’ancienneté.
soit environ 1740 à 1992 € en net.

Oui, pareil en Fortran, mais le problème n'est pas dans l'ouverture des fichiers, il est dans le décodage des chaînes de caractères.
J'ai des fichiers nommés par exemple ../rep1/rep2/foo.txt et j'ai besoin de séparer le chemin et le nom du fichier. Il faut donc que je cherche le 1er / dans la chaîne de caractères en partant de la droite. Il est plus simple de savoir a priori quel séparateur de fichier chercher que de systématiquement essayer les deux.

Exactement, c'est l'un des buts de l'empaqueteur que de faire le lien entre les utilisateurs de sa distribution
et le projet officiel. L'utilisateur ne doit pas rapporter un bogue upstream directement (sauf s'il sait ce qu'il
fait bien entendu).

C'est un point de vue qui me paraît complètement irréaliste pour un logiciel comme LibreOffice dont les utilisateurs sont vraiment nombreux. L'empaqueteur ne ferait que ça de la journée et passerait son temps à remonter des doublons upstream. Quand on suit les rapports de bug upstream, les bugs spécifiques à une distribution ne me semblent pas si nombreux que ça en fait.
Le meilleur moyen de savoir si un bug vient du packaging de la distribution, c'est justement d'en avoir connaissance upstream et d'essayer de le reproduire sur d'autres distributions et d'autres OS.

C'est rigolo parce que les paquets Debian n'ont pas ces problèmes (à ma connaisance)!

Les paquets Ubuntu non plus à ma connaissance à moi, c'est pour cela que j'aimerais savoir sur quelle distribution ces paquets sont utilisés.
René Engelhard est effectivement un développeur LibreOffice, tout comme Bjoern Michaelsen (Canonical) qui est mainteneur des paquets pour Ubuntu.

Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar.

Ce paquet Ubuntu, tu le fais tourner sur Ubuntu / Unity ou bien sur une dérivée d'Ubuntu ?
Parce qu'il y a les mêmes problèmes avec les distributions et leurs dérivées qu'avec les logiciels upstream vs. packaging des distributions.

et ca ne correspond pas à l'enoncé premier de detecter si tu es sous windows natif ou sous linux natif
en effet l'appel system lors de l'execution devrait permettre de detecter l'OS
mais ce n'est alors pas à la compilation que tu detectes l'OS sur lequel tu compiles, mais bien à l'execution
du programe

Mon problème n'est pas la compilation, je compile toujours sous Linux, même pour produire un exécutable win32 ou win64. Là il n'y a pas de détection d'OS, juste un switch dans le makefile.

avec un simple ls ou un dir
ca devrait deja te dire si la commande existe ou pas,
et si elle n'existe pas, c'est que tu n'es pas sur l'OS visé (ls = linux, dir = windows)

Non, justement c'est le même cas que celui de mon 1er résultat : sous Linux, un programme win64 exécuté avec Wine me répondra que la commande ls n'existe pas et que la commande dir existe, donc ça ne me permet pas de savoir que l'OS sous-jacent est Linux. En plus il faut analyser la réponse pour détecter l'erreur, c'est plus compliqué que juste récupérer un booléen me disant si le fichier /bin/. existe ou pas. Le bout de code Fortran pour faire cela pourrait être quelque chose comme ça :

detection_Wine: block
logical :: bExist
inquire(file='/bin/.',exist=bExist)
if (bExist) slash='/'
end block detection_Wine

avec slash une variable définie précédemment en fonction de la variable OS définie à la compilation pour l'OS cible et insérée dans le code grâce à un include.

J'ai fait quelques essais ce matin :
- exécuter une commande genre uname : ça ne marche pas car c'est Wine qui répond et il ne connaît pas les commandes Linux ;
- analyser la variable d'environnement PATH : encore raté, si le code tourne sous Wine, c'est le PATH Windows qui est renvoyé ;
- tester l'existence du fichier /bin/. : ça ça marche

Au final, cependant, changer le séparateur de fichier seulement sur la base de l'OS cible et de l'OS hôte, complique les choses. Je peux tester avec Wine un code Windows sur des données Linux, mais je ne peux plus tester avec Wine un code Windows sur des données Windows. Donc ça ouvre une porte et ça en ferme une autre.
Du coup, je pense que le plus raisonnable est de laisser la main à l'utilisateur sur cette question, surtout que l'utilisateur en question c'est moi, les autres utilisateurs ne se poseront pas cette question. J'ai donc implémenté la lecture d'une variable d'environnement ad-hoc qui me permet de changer le séparateur de fichier seulement quand je le décide explicitement. Une option de la ligne de commande serait plus compliquée à implémenter car il y a une autre option avec un nom de fichier, donc potentiellement un séparateur de fichier, il me faut donc fixer le séparateur de fichier avant de décoder la ligne de commande.

En tous les cas un grand merci à tous pour vos commentaires.

À part le nombre de cpu disponibles qui s'obtient à l'exécution avec OpenMP, les autres détections me semblent devoir être faites à la compilation. Et comme la production des exécutables Windows est faite sous Linux, c'est un exécutable générique que je produis. Je n'ai pas trouvé de réglage plus efficace que l'option -O3 de gcc/gfortran.

Oui tu as raison, j'ai retrouvé où C. Villani en parle dans son bouquin : chapitre 31, où il parle de sa rencontre avec Voevodsky dans un parc à Princeton, de la preuve du théorème des quatre couleurs, de l'Inria, de Georges Gonthier et son travail sur COQ.

J'ai écrit que Villani et Mouhot avaient utilisé Coq pour vérifier leurs démonstrations : celles de Villani et Mouhot. Ils ne travaillent pas sur Coq mais avec Coq.

Je pense que c'est déjà le cas pour certains mathématiciens. Dans Théorème vivant on voit que Cédric Villani et Clément Mouhot utilisent un outil de calcul formel pour manipuler leurs équations ainsi que Coq pour vérifier leurs démonstrations.

Ah, merci. Je n'ai pas le réflexe stackoverflow, je devrais. Et puis j'aurais du refaire ma recherche en restreignant la question à celle du séparateur de fichier. Je vais faire des essais lundi avec une fonction inspirée de ce bout de code. Je suis curieux de voir quelle valeur de PATH je vais obtenir à travers Wine.

Cela dit la question n'est pas si souvent posée. Celle qui l'est c'est celle à laquelle a répondu Sytoka et ça je fais déjà.
Une autre présentation de mon problème : comment mon exécutable win32 ou win64 peut-il détecter qu'il tourne en réalité sur une machine Linux avec Wine ?

Une autre piste : Fortran 2008 permet de tester l'existence d'un fichier ou d'un dossier, je peux tester l'existence de /bin ou /boot pour savoir si l'OS est Linux, à moins qu'il y ait un problème de droits pour obtenir une réponse. Je testerai.

Oui à peu près, mais là c'est juste pouvoir décider si slash = '/' ou slash = '\' de façon que le décodage des chemins fonctionne dans tous les cas. ;-)

À la réflexion, ce dont j'ai besoin pour l'instant c'est en fait détecter si le code est en train de tourner sur une machine Linux. Donc un script basé sur la commande uname devrait me donner la réponse, il faut juste que je traite correctement l'échec du script dans le cas où je le fais tourner sur MS-Windows.
S'il y avait une variable d'environnement qui donne l'info ce serait quand même plus pratique.

The Document Foundation a publié en urgence les versions 5.4.5 et 6.0.1 pour corriger des graves régressions sur 6.0.0 pour MS-Windows et une faille de sécurité pour 5.4 et 6.0.

http://blog.documentfoundation.org/blog/2018/02/09/early-availability-libreoffice-5-4-5-libreoffice-6-0-1/
http://nabble.documentfoundation.org/Publication-anticipee-de-LibreOffice-5-4-5-et-LibreOffice-6-0-1-tp4232542.html
https://www.libreoffice.org/about-us/security/advisories/

Mettez-vous à jour !