swilmet a écrit 647 commentaires

Le flamand est quand même un cours obligatoire dans beaucoup d'écoles, dès la primaire.

C'est pas vraiment le même sujet. Les deux (ou plutôt les 4) bouquins que tu cites n'expliquent pas je pense les techniques pour être le plus efficace en programmant et produire du code de meilleure qualité.

Ça dépend des pays, et sans doute aussi des régions…

Quand j'avais cours de néerlandais les « ij » on les prononçait « eille » et pas « aille ». Donc ça doit sans doute venir des différents accents.

(eh oui en Belgique on a l'énorme chance d'apprendre le néerlandais !)

Sur les bonnes pratiques de programmation j'ai acheté le bouquin Code Complete [1], j'ai pas encore tout lu mais je peux dire que c'est un bon bouquin, le seul défaut c'est que c'est édité par Microsoft Press (mais il n'y a pas grand chose à voir avec crosoft dedans).

Bon maintenant il est un peu plus gros que The Pragmatic Programmer (900 pages contre 350).

Les libristes ils lisent quoi d'habitude dans ce sujet ? (bon OK vous allez me répondre : le code d'autres programmes ;)

[1] http://www.amazon.fr/Code-Complete-Steven-C-McConnell/dp/073(...)

J'ai vérifié dans le livre LaTeX: A Document Preparation System (2e édition) de Leslie Lamport. Et il est indiqué à l'annexe E Using Plain TeX Commands :

« Plain TeX's $$ does not work properly; it has been replaced by the LaTeX commands \[ and \]. »

Étant donné que ce livre est la référence, je vais changer ça pour la version 2.0.1 qui pointe bientôt le bout de son nez.

J'ai aussi appris que les commandes \( et \[ sont fragiles (et donc dans certains cas il faut rajouter \protect), tandis que $ … $ ne l'est pas.

Tu dois installer les paquets *-dev correspondants.
Pour gdk-x11 j'ai eu un retour comme quoi c'était gtkview-dev sur Ubuntu, en tout cas sur Fedora c'est libX11-devel.

Oui, cette erreur est classique, je devrais peut-être expliquer plus en détail dans le fichier INSTALL.

En bref, tu dois installer gsettings-desktop-schemas.

LaTeXila utilise GSettings, qui est le successeur de GConf. GSettings est inclus dans GLib 2.26.

gsettings-desktop-schemas est nécessaire à LaTeXila pour savoir quelle est la police à chasse fixe définie pour le système (Monospace 10 par défaut je pense). Fedora 14 par exemple a un paquet qui porte le même nom, je suppose que dans Ubuntu c'est le cas aussi, mais sinon ce n'est vraiment pas compliqué à installer, c'est juste des fichiers xml.

Aussi, pour que GSettings fonctionne (pour que les préférences soient enregistrées quelque part), il faut un backend : dconf.

C'est étonnant, car le livre* que j'ai dit qu'il est préférable d'utiliser $$ … $$ pour des questions de robustesse et de facilité de saisie (il n'est rien dit de plus).

Bon maintenant ce livre n'est pas la référence, et apparemment $$ … $$ n'est pas compatible avec certains package, donc pour la prochaine version ce sera sans doute \[ … \]. J'aimerais quand même une source plus fiable que wikibooks et le lien donné dans la note.

Merci en tout cas pour cette remarque.

* LaTeX par la pratique, O'Reilly (p.86)

Merci, je suis en train de regarder le spec, il y a quelques modifications à faire (description, versions des dépendances et url de téléchargement, peut-être d'autres choses).

Ensuite il faudra faire une demande d'inclusion dans Fedora, je ne sais pas du tout comment ça fonctionne, il faut encore que je me renseigne à ce sujet, peut-être que toi tu es mieux placé pour le faire ?

Il y a quelqu'un qui m'a contacté aussi pour inclure la version 0.2 dans F13 (la 2.0 ne sait pas aller dans F13 notamment à cause de la dépendance à GLib 2.26). Je n'ai plus eu de réponse depuis.

Aussi, le paquet Debian est divisé en deux : latexila et latexila-data. Le dernier est indépendant de l'architecture et contient toutes les images, etc. Plusieurs logiciels sont packagés comme ça dans Fedora aussi. Mais ici, étant donné que le tar.gz ne fait même pas 400 Ko, est-ce que ça vaut vraiment la peine ?

Super, je vais remettre le lien sur le site alors.

Pour XeLaTeX, malheureusement Rubber ne le supporte pas pour l'instant (un patch existe, mais je ne l'ai pas testé) :
https://bugs.launchpad.net/rubber/+bug/660426

Dans la version 0.2 de latexila, le filtrage des messages d'erreurs se faisait en interne, comme dans Kile. Mais à quoi bon réinventer la roue alors que des programmes comme Rubber et Latexmk existent ?

Avec latexila, il y a deux post processor : generic et rubber. Le generic n'affiche rien du tout, ça prend juste en compte la valeur de retour. Je pourrais rajouter un autre qui afficherait tous les messages, sans aucun filtre.

Ou bien, ce qui existe dans le plug-in de Gedit, c'est un filtre minimaliste pour utiliser directement pdflatex ou autre. Mais Rubber le fait déjà en interne, donc le mieux étant que ce soit supporté directement là bas.

Le problème avec Rubber c'est que ce n'est plus vraiment maintenu (dernier commit il y a 3 mois, alors qu'il y a des patchs et des rapports de bugs en attente), et aussi que ce n'est pas très propre (j'ai quand même galéré pour installer la version en « développment »), ce qui me fait un peu pencher pour Latexmk dans le futur.

C'est un programme très intéressant que je connaissais pas, mais latexmk manque une fonctionnalité essentielle pour LaTeXila qui existe dans rubber :

Le filtrage des messages de compilation pour n'avoir que les warnings, erreurs et badbox, avec le nom du fichier et le ou les numéros de lignes correspondantes, pour pouvoir sauter directement là où il y a eu des erreurs (on peut le voir sur une des captures d'écran).

Je pense qu'il serait assez aisé de rajouter cette fonctionnalité à latexmk, vu que c'est du Perl (et que le filtrage se fait par regex).

Donc pour l'instant Rubber convient assez bien, sauf évidemment le problème des espaces, mais je n'exclue pas la possibilité de passer à latexmk par défaut plus tard. Je dis par défaut, car il est bien sûr possible de rajouter ses propres outils de construction dans LaTeXila et ainsi utiliser latexmk, mais il reste le problème du filtrage des messages d'erreurs.

Oui, je voulais plutôt réagir sur « LaLeXila est un vrai logiciel gnome », car pour l'instant c'est encore raisonnable. Mais en effet, peut-être que par la suite il y aura plus (+) de dépendances envers Gnome, mais j'essayerai dans ce cas-là de faire en sorte que ces dépendances soient facultatives, dans la mesure du possible.

Ce n'est pas moi qui ait fait le PKGBUILD (je ne suis pas sur ArchLinux), j'ai donc rapporté ton problème au packageur (sur la mailing list).

J'avais rajouté le lien sur le site en croyant que la personne avait fait du bon boulot (d'ailleurs j'avais été étonné par sa rapidité), mais apparemment non…

À propos, quand j'aurai le temps je ferai un paquet RPM pour Fedora.

Il n'y a pas tant de dépendance que ça par rapport à Gnome. Quelqu'un qui utilise XFCE par exemple pourra très bien l'installer sans trop de soucis à mon avis.

Mais rien que le fait que ce soit en GTK, ça s'intègre déjà beaucoup mieux à Gnome.
Il y a aussi l'utilisation de GSettings, le successeur de GConf. Mais contrairement à GConf, GSettings est intégré à la GLib (GIO plus particulièrement).

Personnellement, même avec la dernière version en développement, j'ai toujours ce bug :
https://bugs.launchpad.net/rubber/+bug/639983

Tu parlais bien du même problème ?

Dans LaTeXila il y a d'ailleurs un avertissement s'il y a une espace dans le chemin du fichier. Le plug-in de Gedit (qui utilise aussi Rubber) est silencieux de ce point de vue-là, on voit juste que la compilation a échouée, sans rien d'autre comme information…

Y en a qui ont bien fêté ça !

Mais je connais un geek sportif (oui ça existe) qui a fait un marathon aujourd'hui... Et un marathon ça fait... tadadam... 42 km !

« A "parle" à B et si B ne peut répondre (car il n'est pas encore initialisé), A attend (probablement bloqué dans l'appel système d'écriture à B). »

Pas forcément, si A a vraiment besoin d'une réponse de B pour continuer, là oui.
Mais si c'est un service qui envoi des messages à syslog, le service n'a pas besoin de réponse, donc il continue à s'exécuter. Et quand syslog sera lancé il lira ce qu'il y a sur la file d'attente.

« En effet depuis que j'utilise vcp, j'ai tendance à faire des copie de fichier et à supprimer à la main les fichier après à fin de profiter de la barre de progression. »

Euh déplacer un fichier en faisant une copie + supprimer l'original, c'est beaucoup plus lent que de faire un simple mv ! Et si tu dois déplacer un très gros fichier et qu'il ne reste plus assez de place pour faire une copie ?

Je doute très fort que l'implémentation de mv soit un simple cp + rm...

Pertiner veut dire appartenir :
http://fr.wiktionary.org/wiki/pertiner

J'aurais plutôt dit « pertinenter », mais ce verbe n'existe pas…

Enfin bon la langue française est une langue vivante, on peut déformer/créer des mots :)

C'est une très bonne nouvelle que les pilotes soient libres, mais est-ce que les spécifications du matériel sont aussi disponibles ?

Parce que si un jour Broadcom décide de ne plus maintenir les pilotes, ça risque d'être embêtant (il y a eu un journal sur le sujet assez récemment, mais je ne le retrouve plus).

On peut utiliser svn -:) dans des conditions satisfaisante

En bas débit un gestionnaire de versions décentralisé comme Git est beaucoup plus confortable...
Et en haut débit aussi, d'ailleurs.

Ce n'est pas parce que le pourcentage diminue que le nombre d'utilisateurs diminue aussi... Au contraire je pense qu'il a plutôt tendance à augmenter.

Je n'ai pas de chiffres exacts actuels, mais ça me fait un peu penser au billet « Le web est-il vraiment mort ? » du standblog :
http://standblog.org/blog/post/2010/08/19/Le-Web-est-il-vrai(...)

En fait les devs de DNF s'amusent à faire des bêta-test-lan-parties sous Debian/kHurd...

Chez moi ça fait un dégradé : plus je regarde en bas de l'écran moins c'est rouge.
C'est dû à l'inclinaison, si je penche plus mon écran ça devient plus rouge, si je le redresse ça devient normal.

Donc si j'ai envie de moins me petter les yeux je scrolle vers le bas pour que je lise le texte en haut de l'écran (: