swilmet a écrit 647 commentaires

Autant pour des mots comme oignon -> ognon et nénuphar -> nénufar je peux comprendre, mais là je préfère évènement puisqu'on prononce comme ça.

J'ai pas trouvé de liens pour télécharger les *.iso en bittorrent... J'ai pas essayé de chercher à fond non plus en me disant qu'il n'y aurait de toute façon pas grand monde puisqu'apparemment aucun lien direct n'existe.

Je me suis donc résolu à télécharger le *.iso en http, et la vitesse est très bonne : 1,5Mo/s (ça doit pas être loin du maximum possible avec ma connexion).

Il y a des serveurs répliqués un peu partout dans le monde j'image, en tout cas ça tient très bien la charge !

J'ai installé F13 il y a déjà quelques semaines sur le nouveau sony vaio de ma mère (noyau 2.6.34 nécessaire pour la prise en charge du son et du wifi), et j'ai été étonné de sa stabilité, je n'ai eu aucun bug, et ma mère ne se plaint pas.

Avec F12 sur mon ordi, au début j'avais quelques bugs avec Firefox et une ou deux applications gnome, mais avec les mises à jour je n'ai plus aucun problème.

Dans les gestionnaires de paquets le (a) est enlevé pour donner « valide », donc je suppose que c'est mieux de prononcer « valide » comme le mot en français, ce qui fait un petit jeu de mot.

C'est comme les gens dans mon entourage qui prononcent LaTeXila avec un X au lieu d'un K, ça enlève tout le charme ;)

Le lien pour télécharger valide-0.7.0.tar.gz pointe vers l'ancienne version 0.6.1.

Étant donné que je compte aussi réaliser un IDE GTK+ en Vala [1], je m'intéresse beaucoup à la façon dont tu as organisé le code source.
Ne trouves-tu pas que ce serait intéressant que GtkSourceView soit de plus haut niveau, notamment pour tout ce qui est la gestion de documents ? Il y a beaucoup de choses de Gedit qui valent la peine d'être intégrée dans une bibliothèque je trouve.

[1] Voir mon dernier journal à propos de LaTeXila [2] : http://linuxfr.org/~darkagonik/29652.html
[2] http://latexila.sourceforge.net/

#include <stdio.h>

#define SIX 1 + 5
#define NEUF 8 + 1

int
main (void)
{
printf ("%d * %d = %d\n", SIX, NEUF, SIX * NEUF);
return 0;
}

$ gcc -o 42 42.c
$ ./42
6 * 9 = 42

Comme quoi il faut toujours mettre des parenthèses dans les define.

C'est clair qu'avoir seulement quelques commentaires dans le code n'aide pas à attirer de nouveaux développeurs. Même s'il y a beaucoup de commentaires, il n'est parfois pas facile de comprendre la structure générale du code, et on ne sait pas vraiment par où commencer la lecture (le main() est toutefois un bon point de départ, généralement).

Mais écrire d'abord la documentation (pour développeurs) avant le code, ça me parait une perte de temps si on s'aperçoit en codant qu'on n'a pas prévu tous les cas possibles et où une réécriture en profondeur de la documentation est nécessaire...

Pour ce qui est de la documentation pour utilisateurs, autant le faire après le code pour pouvoir insérer des captures d'écran, faire référence à telle ou telle option bien spécifique dans les préférences, etc.

Rien n'empêche d'avoir un dossier contenant le code source qu'on pourrait facilement modifier, compiler puis installer dans le répertoire contenant les binaires.

Et ça permettrait un temps de démarrage beaucoup plus rapide, car notamment moins de processus sont créés (dans l'article un ordre de grandeur est donné avec la commande « echo $$ » exécutée juste après le démarrage : Linux PID 1823; MacOS PID 154).

Pour systemd c'est prévu de réécrire tous les scripts d'init en C au lieu de simples scripts shell (contenus dans /etc/init.d/).

Un autre billet un peu plus récent où il se déchaine (concernant l'intégration de PulseAudio dans Ubuntu 9.10) :
http://0pointer.de/blog/projects/pa-in-ubuntu.html

Faut espérer que la situation s'est améliorée pour la 10.04...

Je pense qu'il voulait plutôt faire référence à l'article :

« For a fast and efficient boot-up two things are crucial:

* To start less.
* And to start more in parallel.

What does that mean? Starting less means starting fewer services or deferring the starting of services until they are actually needed. There are some services where we know that they will be required sooner or later (syslog, D-Bus system bus, etc.), but for many others this isn't the case. For example, bluetoothd does not need to be running unless a bluetooth dongle is actually plugged in or an application wants to talk to its D-Bus interfaces. Same for a printing system: unless the machine physically is connected to a printer, or an application wants to print something, there is no need to run a printing daemon such as CUPS. Avahi: if the machine is not connected to a network, there is no need to run Avahi, unless some application wants to use its APIs. And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.) »

« Dénuée de mono, et pas mal d'autres choses ! ;) »

Ce serait bien de remplacer Tomboy par Gnote, F-Spot par Shotwell et Gwibber par Pino.

C'est une des raisons pour lesquelles j'apprécierai Fedora 13 qui inclura tous ces logiciels par défaut pour éviter d'avoir des applications Mono.

Il me semble que cette loi ne prend pas en compte si la cible est sur un bord ou pas.

Ce que tu voulais sans doute dire, c'est que mettre le bouton de fermeture juste au-dessus du menu fichier n'est pas une bonne idée, car les gens doivent faire plus attention à l'endroit où ils cliquent : « oups j'ai fermé la fenêtre alors que je voulais aller dans le menu fichier... »

J'aime bien la syntaxe de Vala, surtout pcq je suis habitué au C et au Java. Mais la syntaxe de Python ne me dérange pas non plus, mais là Genie (qui est un mélange de Python, Boo, D et Delphi) ne m'attire pas.

En plus, Vala est bien plus documenté, il y a plein d'exemples de code en GTK par exemple. Et je pense que Vala est plus répandu que Genie, donc je peux lire le code source de logiciels comme Val(a)IDE, qui est un IDE écrit en Vala, pour Vala (donc ça peut être intéressant de s'inspirer de ce logiciel, en plus de Gedit).

J'aurais plutôt donné l'exemple de KompoZer (libre et multiplateforme) à la place de Dreamweaver...

Ah ok je comprends mieux. Je ne comprenais pas où tu voulais en venir. Donc une heuristique admissible donne en fait à chaque fois le résultat optimal, et non une approximation. Mais c'est plutôt un cas particulier, et je ne sais pas si ça se présente souvent...

Oui, une heuristique est une approximation, donc ce n'est pas un algorithme qui donne à chaque fois le résultat le plus optimisé. Donc c'est pas parfait, mais ça peut l'être quand même (et c'est généralement le cas ici). Je ne vois pas ce qui cloche en disant ça...

Dans ce cas-ci, c'est la détection au fur et à mesure de la compilation du fichier dans lequel on se trouve qui pose parfois quelques problèmes, comme expliqué dans le code source de Kile (et copié dans LaTeXila) :

// There are basically two ways to detect the current file TeX is processing:
// 1) Use \Input (srctex or srcltx package) and \include exclusively. This will
// cause (La)TeX to print the line ":<+ filename" in the log file when opening a file,
// ":<-" when closing a file. Filenames pushed on the stack in this mode are marked
// as reliable.
//
// 2) Since people will probably also use the \input command, we also have to be
// to detect the old-fashioned way. TeX prints '(filename' when opening a file and a ')'
// when closing one. It is impossible to detect this with 100% certainty (TeX prints many messages
// and even text (a context) from the TeX source file, there could be unbalanced parentheses),
// so we use a heuristic algorithm. In heuristic mode a ')' will only be considered as a signal that
// TeX is closing a file if the top of the stack is not marked as "reliable".

Ça a l'air très intéressant, notamment en voyant des grands noms comme Qt, OpenSuse, FreeBSD, Webkit ou Blender qui l'utilisent !
Je vais comparer les différentes offres et privilégier Gitorious si c'est plus ou moins équivalent.

Un truc que j'aimerais garder en migrant de SF vers autre chose c'est garder le site web avec la feuille de style. Tout ce que j'ai vu sur GitHub ou Gitorious c'est un wiki... Et je ne demande même pas de PHP ou Python avec base de données ou autres, c'est une bête page statique.

Un like-kile en Qt ? euh non klie-like, raah kile-like, je vais y arriver.*
Ben ça existe déjà : TexMaker (multiplateforme lui).

* quoi ça se voit que je fais exprès ? -->[]

Faire du LaTeX permet justement de se concentrer non pas sur la présentation du document mais sur son contenu et sa structure.

Le visionnage en temps réel n'est que rarement utile selon moi. Et l'export en PDF ou autre format ne doit pas se faire toutes les 30 secondes non plus quand on maitrise le LaTeX. Évidemment quand on essaye de faire quelque chose hors des sentiers battus, là c'est nécessaire et c'est plus pratique avec un affichage en temps (presque) réel. Où à la finalisation du document où on arrive pas à placer les figures et tableaux là où on veut.

Ah oui, et aussi peut-être expliquer un peu l'algorithme utilisé pour le filtrage et l'extraction des données de la compilation, qui est en fait une heuristique (donc c'est pas parfait).

D'où aussi une autre idée de projet qui consisterait à améliorer pdfTeX en rajoutant deux options : --output-user-friendly et --output-machine-friendly. La première pour ceux qui compilent en console, et l'autre pour faciliter l'extraction de données par les IDE.

Mais en faisant un grep de certaines chaines de caractères contenues dans la compilation pour voir où se trouvait le code source concerné, je suis tombé sur un truc que j'avais jamais vu : un fichier pdftex.web de 39000 lignes de code dont le développement a débuté en 1977. Le langage WEB est un langage de plus haut niveau que le Pascal, traduit d'abord en Pascal et puis compilé (tiens ça me fait penser à quelque chose...). Pour plus d'info rendez-vous à la ligne 180 de ce fichier (src/texk/web2c/pdftexdir/pdftex.web).

Bref j'ai vite abandonné l'idée... Mais faudrait que je soumette une feature request.

Il faudrait dans ce cas-là rajouter une liste des fonctionnalités les plus importantes (voir journal précédent ou sur le site), la licence (GPL 3+), le gestionnaire de version (Git), le générateur de Makefile (CMake), disponibilité d'un RPM pour Fedora et disponible dans AUR pour ArchLinux et un lien vers une capture d'écran.

Mais si j'avais décidé d'écrire directement une dépêche j'aurais sans doute formulé mes phrases autrement, moins parler en « je » par exemple.

Il faut à ce moment-là une machine connectée en permanence à internet, ce que je n'ai pas. Donc même si c'est moins flexible, je préfère SF ou GitHub, là je suis presque sur que n'importe qui peut prendre la version en développement n'importe quand.
Et il y a aussi l'hébergement du site web qui est fourni aveC.

Pour l'instant le code est sur SourceForge, avec Git comme gestionnaire de versions.
Mais je compte peut-être migrer sur GitHub, qui a l'air plus rapide et meilleur pour gérer un projet avec Git (et qui ne censure pas certains pays ;).

La version 0.2 fait en effet 10 000 lignes de code, donc c'est clair que la « migration » ne se fera pas un jour. Mais j'aurai presque toutes les grandes vacances (3 mois) de libre, si j'ai pas de seconde sess'. Donc j'espère arriver à un assez bon résultat en aout, pour ajouter en septembre une grosse fonctionnalité manquante : la complétion automatique. C'est un peu comme un GSoC sans mentor (il y a toujours les forums et ML de toute façon), sans être payé mais avec moins de pression ;)

Il me semblait qu'en Europe les brevets logiciels n'existaient pas.
Sauf si ce brevet en question n'est pas considéré comme un brevet logiciel, mais j'en doute fortement...

Donc, qu'est-ce qu'à avoir l'Allemagne là-dedans ?