tipote a écrit 105 commentaires

Oups, mea culpa, je n'ai pas lu l'avant-dernière ligne attentivement !

Et est-ce que l'enregistrement en PDF depuis Inkscape ne permettrait pas de gagner une étape ? (je suis feignant, je n'ai pas essayé)

D'ailleurs, si c'est pour utiliser la figure dans un fichier LaTeX, on pourrait s'arrêter là et compiler le LaTeX avec PDFLaTeX...

À propos de la mise à jour du firmware, ça m'étonnait que les constructeurs de lecteurs/graveurs de DVD n'y avaient pas pensé plus tôt : puisque ces machines sont des vrais ordinateurs avec un système d'exploitation, ils n'échappent pas aux bugs. Donc si le système de mise à jour permet de corriger ce genre de choses (comme la mise à jour du firmware d'un routeur par exemple), je suis pour !

Merci à vous, pour vos félicitations, commentaires et autres remarques encourageantes. Voilà une raison de plus pour continuer à travailler sur ce projet !

Ah, et à la question "il en pense quoi maintenant ?", eh bien il semble enthousiasmé, mais il n'a jamais laissé de côté sa casquette de maintainer.

Pendant le développement, il a été le premier à me faire remarquer que l'antialiasing accentue les défauts sur les droites qui dansent à cause des coordonnées entières. C'était finalement constuctif, puisque j'ai trouvé comment l'éviter, et le rendu est alors incontestablement meilleur, sur n'importe quelle courbe.

Enfin, juste après la copie du code sur le CVS, il s'est attaqué à la compilation sous Windows, pour constater que ce n'est pas évident.

Il joue bien son rôle, et ce genre de critiques est constructif quand elles sont exprimées avec tact !

Le développeur qui m'a dit ça est un des plus actifs sur gnuplot, je crois même qu'on peut lui attribuer le qualificatif de maintainer. C'est souvent le premier sur les bug reports, et pas seulement pour commenter, mais pour régler réellement les problèmes. Il avait une vue d'ensemble que je n'avais clairement pas quand j'ai posté pour la première fois sur la liste de diffusion.

Il avait raison dans une large mesure : dans le contexte, je parlais d'améliorer l'interactivité du terminal. Or, il se trouve que gnuplot a déjà un mécanisme de raccourcis clavier très puissant (c'est la commande bind), mais c'est juste difficile à deviner pour le nouvel utilisateur !

Par rapport à l'interactivité du terminal X11, je n'ai fait que rajouter une barre d'outils dont 5 icônes sur les 8 font ce que des touches clavier font déjà.

Parmi les 3 icones restants, le premier copie le "plot" vers le presse-papier, ce que le terminal X11 fait automatiquement à chaque plot ! Un autre affiche une fenêtre du genre "A propos", avec une ou deux phrases pour diriger l'utilisateur vers le système d'aide de gnuplot. Le dernier affiche une fenêtre de configuration, où on peut désactiver l'antialiasing, ajuster le comportement du terminal (prendre le focus à chaque plot, ne pas quitter à la fin d'un script, etc.). La seule vraie nouveauté est la façon dont ces réglages sont gardés en mémoire pour les prochaines utilisations. Grâce à wxWidgets, un fichier .quelquechose ou la base de registres sous Windows s'en occupe, et l'utilisateur n'a rien à faire de particulier. Avec le terminal X11, il falait bidouiller avec les .Xressources pour modifier ce genre de comportement et le garder en mémoire.

> il faut être un brillant normalien

Je regrette maintenant d'avoir mentionné ça ! Je crois que ça fausse le jugement : j'aime beaucoup l'informatique mais ce n'est pas du tout ce que je fais pour mes études.

> manger du C/C++ à haute dose au petit déjeuner, maitriser les redoutables autotools, dompter des engins aussi complexes que Cairo ou Pango, rigoler à la face des algorithmes d'antialiasing, savoir s'expliquer techniquement en anglais sur les mailings lists et, pour finir en beauté, se plonger dans la programmation multithreads

Listé comme ça, c'est vrai que ça peut paraître décourageant. Mais c'est un constat, j'ai eu à m'habituer à ces différents aspects. Par contre, au début on ne se rend pas du tout compte de tout ça, et c'est pour ça qu'on arrive à se lancer ! Par la suite, quand on réalise l'étendue du travail à faire et qu'il n'y a pas que du pré-maché, c'est là que la motivation est vraiment éprouvée.

> je crois que je vais continuer avec mes quelques pauvres bug reports...en étant juste un poil plus déprimé...

Alors là, je suis vraiment désolé, c'est pas du tout ce que je voulais ! Je vois la communauté du logiciel libre comme une association de passionnés, comme des modélistes par exemple. Chacun fait un petit boût, certains ont plus de temps à consacrer à leur hobby, certains sont doués pour une tâche particulière (construire un nouveau modèle réduit, apprendre aux autres à piloter), tous participent à l'entretien des locaux, certains s'occupent de communiquer sur les activités du club. Au final, tout le monde a sa place, et il n'y a pas de hiérarchie.

Oui, c'est dans le CVS, et donc la prochaine version devrait inclure ce terminal (et pas mal d'autres nouvelles fonctions qui ont été rajoutées depuis gnuplot 4.0).

Par contre, je n'ai aucune idée de la date de sortie de la prochaine version ! gnuplot ne vit pas dans le monde des logiciels au cycle de sortie de 6 mois...

Merci pour ce commentaire constructif, qui ne mérite pas d'être moinssé ! Je comprends bien ton point de vue, et d'ailleurs je crois qu'on ne m'aurait jamais laissé mettre mon patch sur le CVS s'il empêchait de compiler seulement les autres terminaux

Concernant cairo et pango, ils sont à la base de gtk+, donc je ne m'inquiète pas outre mesure.

Et quant à wxWidgets, c'est vrai que c'est moins répandu. Sur UNIX, wxWidgets est construit sur gtk+, donc il se révèle relativement accessible. Sous Windows, je m'en suis sorti avec MinGW sans trop de soucis (à part que c'est long).

Je me suis d'ailleurs longtemps demandé si je n'aillais pas utiliser gtk au lieu de wxWidgets.
Avantage de wxWidgets : implémenté nativement sous Windows et MacOS
Avantage de Gtk+ : c'est écrit en C, comme le reste de gnuplot

Bien sûr, voici un screenshot pour comparer le rendu avec le terminal X11, tel qu'on el trouve dans gnuplot 4.0, et avec le terminal wxWidgets en question :

http://tipote.free.fr/wxt19.png

Le bulletin d'inscription indique que c'est 40¤ dans le cas d'une inscription avant le 31 janvier, 60¤ sinon, sans aucune précision sur une éventuelle gratuité pour les étudiants (d'ailleurs le repas est compris). C'est dommage que ce soit si cher... pour un colloque organisé entre autres par des écoles gérées par l'Etat (ENS Cachan, Polytechnique).

Je viens d'essayer cette beta3, et je suis assez impressionné ! C'est la première fois que j'essaye wormux, et il est évident qu'il y a déjà un énorme travail derrière... Je trouve en particulier les graphismes sympas, et le jeu relativement fluide. D'ailleurs, je n'ai pas eu de plantages pendant mon court essai.

Quelques remarques, que vous devez déjà connaître je suppose :

* si le jeu en lui-même est réactif, les menus au démarrage du jeu (options...) ne le sont pas,
* le positionnement des armes sur les personnages est assez curieux,
* il serait bien que la caméra suive les projectiles (grenade...) quand celles-ci sont lancées hors écran

En bref, bravo ! Je crois que wormux a la possibilité de surfer sur la même vague de popularité que Battle For Wesnoth par exemple.

On peut se satisfaire de mettre tout en minuscules aussi !
Personnellement je préfère la forme du 'e' minuscule que celle du 'E' majuscule...

A part ça, l'idée est bonne de vouloir éviter les noms avec un lien direct avec la fonction du logiciel. En tout cas, c'est à la mode.

Julien, je crois que l'orthographe est plutôt Ekiga que eKiga ! La deuxième forme laisserai penser que c'est un projet KDE, alors que 'gnomemeeting' a été changé justement pour souligner que ce n'est pas un programme spécifique à Gnome...

Ceci dit, Ekiga semble être réellement un progrès majeur pour la vidéoconférence sous unix, et on peut noter les efforts pour respecter les standards (SIP) et soutenir les codecs et autres projets libres (speex, dbus, avahi), tout en ménageant l'utilisateur, comme en témoigne tes efforts, Julien, pour porter Ekiga sous Windows !

Un gros merci à toi et à tous les contributeurs de Gnomemeeting / Ekiga !

Pour en savoir plus : http://blog.gnomemeeting.net

L'information que tu as trouvé sur le web concernant l'impossibilité d'utiliser plusieurs formats de temps différents est à la fois la source et la clé du problème.

La version de développement (en cvs) de gnuplot donne l'indication suivante concernant les formats d'heure et date :

Internally all times and dates are converted to the number of seconds from the year 2000. The command set timefmt defines the format for all inputs: data files, ranges, tics, label positions---in short, anything that accepts a data value must receive it in this format. Since only one input format can be in force at a given time, all time/date quantities being input at the same time must be presented in the same format. Thus if both x and y data in a file are time/date, they must be in the same format.

Ainsi, il faut que tu t'arranges pour que tes données heure/date soient toutes dans le même format. En pratique, ça donne ça :

Le fichier de données original :

# Date Time T6 H6 T4 H4
03/01/05 09:30 19.5 27.0 22.5 23.0
04/01/05 11:41 19.6 28.0 22.3 24.0
10/01/05 09:30 18.7 40.0 22.2 22.0
...

Il doit s'écrire :

# Date Time T6 H6 T4 H4
03/01/05_00:00 01/01/05_09:30 19.5 27.0 22.5 23.0
04/01/05_00:00 01/01/05_11:41 19.6 28.0 22.3 24.0
10/01/05_00:00 01/01/05_09:30 18.7 40.0 22.2 22.0
...

Ca prend trois secondes avec un éditeur de texte, où tu remplaces "/05 " par "/05_00:00 01/01/05". Ainsi, les deux colonnes sont dans le même format.

Pourquoi mettre toute la deuxième colonne à la même date ? Parce que ce qui t'intéresse, c'est justement l'heure, mais que gnuplot prend en compte la donnée d'ensemble heure+date. (La commande 'set format ...' n'influe que sur la façon dont les échelles sont affichées en abscisse et ordonnée, les 'labels').

A quoi doit ressembler ton fichier de script ?
Pratiquement inchangé, à ceci près que tu n'appelles qu'une fois "set timefmt ...". J'ai utilisé le script suivant :

set xdata time
set ydata time

set timefmt "%d/%m/%y_%H:%M"

set xrange ["01/01/05_00:00":"31/12/05_00:00"]

set format x "%d/%m"
set format y "%H:%M"

set missing 'NaN'

set title "Time of measurement - 2005"
set xlabel "Days"
set ylabel "Time"
set autoscale y
plot 'th.txt' using 1:2 notitle with lines

et j'obtiens le résultat attendu : http://tipote.free.fr/time.png

En conclusion, gnuplot, c'est formidable !

Si l'on ne trouve que peu d'interfaces graphiques pour commander gnuplot, c'est parce que ce logiciel n'est pas très adapté à ce type d'interface. En effet, le logiciel depuis ses origines est conçu à partir du traitement de lignes de commandes (étendu aux 'pipes' et séquences de commandes enregistrées dans un fichier).

Le plus intéressant est sans doute de mettre le nez dans un tutorial pour se rendre compte que les commandes sont construites toutes grosso modo de la même façon :

set machin-chose une-valeur
show machin-chose (affiche la valeur)
plot une-fonction
plot un-fichier-de-données
splot une-fonction-de-deux-paramètres

Après, on rajoute des infos supplémentaires sur les échelles du graphe, les titres, etc.
Pour mieux comprendre, je t'invite à jeter un coup d'oeil au tutorial suivant, listé sur http://www.gnuplot.info :

http://www.info.univ-angers.fr/pub/gh/tuteurs/tutgnuplot.htm

Sinon, pour revenir à ta question de départ, il existe l'interface suivante, appelée "plotdrop" :

http://icculus.org/~jcspray/plotdrop/

Bon tracé de courbes !

Il doit te manquer une dépendance...

Voici l'information qui t'intéresse tiré du README fourni sur http://ipw2100.sourceforge.net :

MAKE SURE THAT THE FOLLOWING CAPABILITIES ARE ENABLED:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_NET_RADIO 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Failure to enable this will result in the Wireless Tools (iwconfig, iwlist,
etc.) not functioning. In 2.6.x, this is enabled via menuconfig:

Device Drivers ->
Networking support ->
Network device support ->
Wireless LAN (non-hamradio) ->
Wireless LAN drivers (non-hamradio) & WE


~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_FW_LOADER 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
ipw2100 loads firmware via the Linux firmware hotplug capability (see later
section on firmware loading). In 2.6.x, this is enabled via menuconfig:

Device Drivers ->
Generic Driver Options ->
Hotplug firmware loading support


~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_CRYPTO 1
#define CONFIG_CRYPTO_ARC4(_MODULE) 1
#define CONFIG_CRC32(_MODULE) 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
ipw2100 uses the WEP encryption and decryption algorithms provided
by the Linux kernel. To use WEP you must enable the Crypto library support
(CONFIG_CRYPTO) and the ARC4 cipher algorithm (CONFIG_CRYPTO_ARC4) via:

Cryptographic options ->
ARC4 cipher algorithm

You also need to enable the CRC32 (CONFIG_CRC32) algorithm via:

Library routines ->
CRC32 functions


~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_CRYPTO_MICHAEL_MIC(_MODULE) 1
#define CONFIG_CRYPTO_AES_586(_MODULE) 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you wish to enable (optional) WPA support, you also need to enable the
following Crypto library modules (in addition to those required for WEP above):

Cryptographic options ->
Michael MIC keyed digest algorithm
AES cipher algorithms (i586)

Une restriction néanmoins : la version incluse dans le kernel 2.6.14 est un peu plus ancienne que celle-ci (c'est le même README qui le dit). Donc il peut y avoir d'autres subtilités. Dans ce cas, direction /usr/src/linux/Documentation/...

Bonne compilation !

Solution intéressante !
En tout cas, elle a eu le mérite de bien me faire rigoler ;-)

Pour revenir aux choses sérieuses, c'est quand même dommage de devoir déployer tout cet attirail de sécurité (pare-feu, et antivirus sous windows en particulier) sur un appareil qui, au départ, est censé être un outil de travail, un canal de communication et d'échange, un passe-temps, ou encore un moyen de divertissement selon les gens... mais jamais une source de stress, peur, tracas, énervement, comme il le devient trop souvent !

Effectivement, gnuplot est en ligne de commande, mais la fenêtre d'affichage des graphes est malgré tout interactive : zoom à la souris, rotation des graphes 3D... Le principal objectif est de faire du plot, mais il contient un algorithme de régression ("fit") de Levenberg-Marquardt (donc capable de régression non-linéaire).

Mon expérience en terme de traitement de données scientifiques, c'est qu'il n'y a pas de logiciel universel. En pratique, j'utilise octave[1] pour le traitement des données. Octave lui-même utilise gnuplot pour tracer les graphes. Octave est en ligne de commande (interactif quand même, comme matlab). On peut bien sûr lui faire exécuter des fichiers de scripts (les ".m" de matlab) que n'importe quel éditeur de texte avec coloration syntaxique rendra accessible...

Par contre, pour un équivalent d'Origin ou Igor Pro, autrement dit beaucoup plus "clickovore", l'offre est moins dense, mais Labplot[2] (cité dans un commentaire plus bas) ou QtiPlot[3] semblent prometteurs, mais n'ont une base d'utilisateurs/développeurs qui est moins importante.

Enfin, matplotlib[4] est une librairie de plot écrite en/pour python, qui est apparemment un langage très facile à utiliser et très puissant, en particulier pour des calculs scientifiques. PLPlot[5] est aussi une librairie de plot, mais en C.

[1] http://www.octave.org(...)
octave est un clone de matlab, dédié aux calculs numériques. Il possède bon nombre de boîtes à outils de traitement de données. En plus, il y a une importante communauté d'utilisateurs/développeurs.

[2] http://labplot.sourceforge.net/(...)
LabPlot est un clone d'Origin, donc du traitement de données "par interface graphique". Projet un peu plus jeune aparemment, mais qui semble attirer les utilisateurs, à voir les traductions disponibles !

[3] http://soft.proindependent.com/qtiplot.html(...)
QtiPlot, autre clone d'Origin...

[4] http://matplotlib.sourceforge.net/(...)
matplotlib, librairie pour python.

[5] http://plplot.sourceforge.net/(...)
Plplot, librairie interfacée avec plein de langages : C,C++,Java,Fortran, Python, Perl...

Ce qui fait que je suis obligé de mettre des pincettes quand je recommande OpenOffice à des scientifiques.

Je ne suis pas sûr qu' OpenOffice soit le plus indiqué pour des scientifiques de toute façon... J'ai eu la même réaction il y a quelque temps concernant les graphes sous OpenOffice. Mais ça a été l'occasion de découvrir des logiciels dédiés comme gnuplot[1] pour les graphes, ou encore inkscape[2] pour les diagrammes, qui font un boulot vraiment formidable !

A vrai dire, en tant que scientifique je ne suis pas prêt d'utiliser OpenOffice souvent depuis que j'ai découvert LaTeX. Par contre, comme tu le soulignes, il est très approprié pour la bureautique traditionnelle.

[1] http://www.gnuplot.info(...)
Logiciel dédié au tracé de graphes 2D/3D, il trace avec tous les systèmes de coordonnées, il fait de belle surface 3D même pour des points de données non équidistants, et il exporte dans tous les formats de fichiers imaginables, en plus de son interface interactive. Il sait aussi faire des régressions, même non-linéaires. Et pour finir, il est un des logiciels les plus multi-plateforme que je connaisse.

[2] http://www.inkscape.org(...)
Logiciel de graphisme vectoriel dédié au format standard SVG. Très très confortable à utiliser pour faire des diagrammes propres et agréables à l'oeil.

Pour avoir suivi le travail de Jon Smirl sur Xegl à travers la mailing-list de dri[1], je suis un peu déçu de son état d'esprit. Il faisait vraisemblablement un travail impressionnant, et Xegl avait aussi des effets de bord intéressants comme des modifications pour lancer X en tant qu'utilisateur normal et non root... Malheureusement, il me semble très "Xegl-centrique", à tel point qu'il critique Zack Rusin, qui a implémenté EXA [2] et qui fait des miracles en ce moment grâce à l'extension composite accélérée [cf le post plus haut avec la vidéo].


Par contre, le ton de son article a l'avantage de remuer les foules ! Il est en train de dépoussiérer la mailing-list de Xorg[3], et même la mailing-list du noyau linux[4] ! Impressionnant !


[1] http://dri.freedesktop.org/wiki/(...)
[2] http://www.kdedevelopers.org/blog/14(...)
[3] http://lists.freedesktop.org/pipermail/xorg/(...)
[4] http://ww.lkml.org(...)

Non pas content :^p ... Je l'avais bien vu ce truc, mais les problèmes sont les suivants:
- tu n'a que 3 tailles de flèches possibles pour chaque style, chacun s'adaptant à l'épaisseur du trait. Difficilement customisable (avec XFig tu peux tuner ta flèche en choisissant les paramètres d'épaisseurs, de longeur et de largeur, et ce pour tous les styles de flèches)
- Impossible de changer la couleur de la flèche. Peut-être un bug de ma version (0.41-5, package officiel Debian) qui aurait été corrigé par la suite, mais la flèche reste pitoyablement noire quelle que soit la couleur des traits.

Et puis pareil pour les pointillés, tu doit choisir tes types de pointillés dans la liste, mais tu ne peux pas régler précisément leur longueur (qui est elle aussi proportionnelle à l'épaisseur du trait).

Comme quoi, je n'avais pas fouillé énormément. Effectivement, c'est un peu pauvre par rapport à ce qu'on pourrait imaginer avec des réglages totalement libre.
J'ai d'ailleurs le même problème que toi pour les couleurs, sur la version 0.41 compilée par mes soins.

Est-ce que cela te convient : http://tipote.free.fr/fleches.png(...) ?

C'est tout simple : ça se passe dans la fenêtre de réglage de l'épaisseur des traits comme tu peux le voir. On y trouve un choix important de marqueurs de début et fin de trait, tous très jolis. Voilà de quoi faire des flèches superbes !

Pour ce qui est des toolkits portables, je vois pas en quoi wxwidgets est plus attractif que Qt ou GTK. Je dirais même le contraire vu la clarté de l'API de Qt et GTK et l'affreuse API de wxwidgets.

Un des côtés attratifs de wxwidgets est son rendu : natif sous windows, natif sous MacOS, natif sous OS/2, en gtk+2 sous unix. Ca me semble un argument intéressant quand il s'agit d'écrire une application portable.

Quant à l'API, je ne la trouve pas "affreuse". Rien ne m'a semblé tiré par les cheveux dans wxwidgets. Néanmoins, je ne suis pas le mieux placé pour comparer avec gtk ou Qt, vu que je n'y ai jamais touché ;-). Si tu pouvais me donner quelques éléments de comparaison pour le côté "affreux" , je serais heureux d'en prendre connaissance...

C'est peu étonnant que les interfaces de vlc en gtk+, qt et autres ne soient plus maintenues, puisque c'est l'interface wxwidgets qui est la principale. Le code y est à 99 % indépendant de la plate-forme, ce qui la rend sans doute plus attractive pour les développeurs...

En ce qui concerne mplayer et xine, ce sont de très bons lecteurs multimédia (et/ou librairies) mais quant à parler de leurs interfaces graphiques, je suis pas sûr que ce soit franchement mieux que vlc ! Moralité : la diversité fait la force.