>>>la finalité d'un graphique n'est pas d'être joli
>>Ce n'est peut etre pas la finalité, mais ça aide *beaucoup* a faire passer le message. Et assurer un minimum de lisibilité c'est bien.
>Pour moi, la lisibilité, c'est le travail de l'utilisateur, pas celui de l'outil qu'il utilise. J'irais même jusqu'à dire qu'un graphique lisible doit pouvoir se comprendre quand il est affiché en noir et blanc (mais c'est peut-être à force de bosser avec un chef daltonien ...)
Je suis d'accord avec ce dernier point, un graphe de qualité est aussi un graphe qui est lisible en noir et blanc. J'ai en effet des collègues daltoniens, et en plus l'imprimante du bureau est, comme dans bien des endroits, noir et blanc. De ce côté, gnuplot fait un très bon bouleau, l'export en postscript en noir et blanc produit des lignes en pointillés bien distinguables.
Je rajouterais qu'un bon logiciel de graphe doit être capable d'exporter dans tous les formats dont j'ai besoin : postscript (ou pdf) pour l'impression, pdf pour l'envoi par courrier électronique, svg (ou pdf) pour l'édition ultérieure, png également, mais aussi latex. Matplotlib gère bien le pdf depuis les dernières versions (merci à http://www.cairographics.org ), mais pas le latex. Gnuplot fait tout ça, et il le fait bien (le pdf avec cairo, c'est encore dans le CVS et pas en version officielle, mais ça vient!).
J'utilise un oscilloscope Agilent série 6000 pour faire de l'acquisition de données sur 4 voies. L'oscilloscope est connecté en usb2. Le programme tourne sous Windows, essentiellement parce que j'ai aussi d'autres instruments à contrôler qui n'ont pas de pilotes linux, et est construit de la sorte :
- sous-couche VISA fournie par Agilent (la seule partie non-libre),
- pyvisa
- numpy & scipy four le traitement de données
- pyqt pour l'interface graphique, avec pyqwt pour les graphes en tant que tels
Honnêtement, ça fonctionne remarquablement bien, et c'est particulièrement agréable de pouvoir écrire ainsi un programme dédié aussi rapidement avec tous ces éléments de qualité !
J'ai rencontré le même problème, et je m'y confronte toujours. Dans mon cas, c'est une image venant d'une caméra CCD scientifique, qui sort du 12 bits, enregistré dans un PNG 16 bits.
Alors, ce qui suit a trait au 16 bits, mais s'applique peut-être aussi au 12 bits natif, à vérifier au cas par cas :
- Krita gère le 16 bits, peut donc remplacer Gimp (même si je trouve que les outils du premier sont légèrement moins agréables à utiliser que les outils du second)
- GraphicsMagick, un fork d'ImageMagick, se targue (je n'ai pas essayé) de supporter des profondeurs arbitraires, au moins pour le TIFF, sans doute pour les autres formats aussi:
TIFF format support is completely re-written to support all subformats, an arbitrary number of sample bits, floating point types, and improved performance.
Le 16 bits en tout cas semble bien supporté. Voilà donc de quoi faire du traitement de masse en ligne de commande.
- La Python Imaging Library gère au moins le PNG 16 bits, à vérifier pour les autres formats, mais j'ai confiance. C'est parfait pour transformer l'image en un tableau de données pour un traitement numérique en Python & Numerical Python. C'est ce que j'utilise quotidiennement.
- enfin, ImageJ, le fameux logiciel de traitement d'image à caractère scientifique écrit en Java, supporte les formats exotiques, à l'aide de plugins éventuellement. Personnellement, depuis que j'ai trouvé Krita, je n'y vois plus trop d'intérêt.
Oui, c'est bien de cet appareil que je parlais. Comme indiqué sur la page de la Fnac, il est muni d'une sortie jack et de deux sorties RCA, et se présente à l'émetteur bluetooth comme un "Stereo adapter".
En gros, l'essentiel est dans les quelques lignes suivantes à rajouter dans le .asoundrc :
pcm.bluetooth {
type bluetooth
device 00:11:22:33:44:55
}
Après, il faudra demander aux applications, ou à pulseaudio (mais je n'ai pas testé parce que je n'ai pas pulseaudio sur ubuntu), d'utiliser la carte son nommée "bluetooth".
Pour ce qui est de la qualité du son, j'ai été très agréablement surpris : en fonctionnement normal, je n'entends pas de différence entre une connexion directe et la connexion bluetooth sur mon kit d'enceintes 2.1 Creative. D'après Wikipedia, le flux audio est encodé en "SBC", qui est semble-t-il un codec semblable au mp3 : http://fr.wikipedia.org/wiki/SBC
Quand je parle de fonctionnement "normal", je veux dire "sans coupures". Dans mon expérience, c'est très dépendant du lecteur audio utilisé (audacious est bien meilleur qu'xmms par exemple). Avec xmms ou rythmbox, le son est parfois un peu coupé. C'est peut-être un problème de jeunesse du pilote de son, il faut préciser d'ailleurs qu'ubuntu est loin d'avoir la dernière version !
En bref : avec pulseaudio et la suite bluez récente, ça devrait être parfait !
J'ai fait la même recherche, et voici mes conclusions:
J'ai acheté l'airport express d'abord, parce que mon portable est un macbook surtout (même s'il tourne avec ubuntu). Le problème est que le streaming vers les haut-parleurs correspond à un protocole fermé, qui n'est possible qu'avec iTunes (avec Wine sous Linux), ou avec des programmes obtenus par ingénieurie inverse, comme raop-play, qui sont à l'usage assez limités. Adieu Amarok, et autre lecteurs sophistiqués, à moins d'un travail assez lourd que je n'ai pas osé entreprendre (utiliser pulseaudio pour envoyer le son des applications à raop-play ?).
Finalement, je me suis tourné vers ce qui est actuellement standardisé pour le streaming du son : le bluetooth avec le profil a2dp. Un récepteur bluetooth-a2dp avec une sortie ligne coûte 89 euros à la fnac, et ça marche très bien depuis n'importe quelle application dans ubuntu, avec très peu de travail "manuel" (voir les pages sur le support audio de www.bluez.org). En plus, ça marche même avec le téléphone portable. Et ça marche même avec Windows sans installer aucun pilote ou application particulière.
L'inconvénient ? Si ta machine n'a pas de bluetooth, il faut acheter un dongle usb-bluetooth qui coûte une dizaine d'euros.
D'après la notice: 'scanf' accepte plusieurs spécifications numériques mais gnuplot n'accepte en entrée que des réels en virgule flottante double précision, donc lf est le seul spécificateur permis.
Disons que j'ai pas le choix au niveau du format des données. ce serait coool si il existait un patch où autre permettant de gérer des milli seconde dans gnuplot ?
Voir ma solution dans l'autre message. Pour info, je ne pense pas que les millisecondes soient ajoutées à gnuplot dans le timefmt, parce que cette fonction imite ce que propose le langage C, où les secondes sont des nombres entiers, sans autre subdivision... Regarde 'man time.h' pour t'en convaincre.
(le développeur de gnuplot fait remarquer qu'avoir une résolution à la milliseconde quand on trace des choses qui s'étendent sur plusieurs jours n'a pas beaucoup de sens.)
Tu peux t'en sortir avec "using" en specifiant le format (tu perds alors le label en heures/minutes/secondes cependant). Par exemple, avec des dates de la forme 07/12/2007 18:46:01.870, tu doix pouvoir utiliser:
plot 'datafile' using ($1*3600*24+$4*3600+$5*60+$6):7 '%lf/%lf/%lf %lf:%lf:%lf %lf'
Contrairement au timefmt, ceci marchera parce que %lf désigne un nombre décimal, pas seulement un entier.
Remarque que je n'ai pas pris en compte les mois, parce qu'ils n'ont pas tout le même nombre de jours... donc ceci ne marche que pour des données d'un même mois.
Avec ça, les étiquettes de l'axe des abscisses ne seront plus formattées, mais indiquées en nombre de secondes cumulées. Si ça ne te convient pas, on doit pouvoir trouver une solution...
En lieu et place des cdrtools, qui te fournissent mkisofs, tu peux utiliser le cdrkit (fork de cdrtools datant de l'année dernière, pour des raisons dont je ne me souviens plus - peut-être un problème de license, ou de comportement du mainteneur des cdrtools, ou les deux). K3b sait utiliser cdrkit, et chez moi cdrkit marche mieux que les cdrtools.
Avec cdrkit, l'équivalent de mkisofs est geniosimage.
J'ai l'impression qu'il manque une bonne librairie pour tracer des graphs dans le monde du libre.
Très bonne remarque. Je suis de ceux qui aimeraient voir gnuplot devenir aussi une librairie. Il y a bien Qwt (C++) et matplotlib (python), mais si on avait une vraie librairie en C, on pourrait imaginer des bindings vers n'importe quel langage.
Voici le statut actuel des choses:
* le problème majeur est d'extraire une API du code de gnuplot. Actuellement, le 'parser' (analyseur lexical/syntaxique) de gnuplot est complètement mélangé au reste du code. Il faudrait séparer tout ce petit monde en deux couches distinctes, la première étant l'interface utilisateur, la deuxième étant accessible en tant que librairie "standard", via des commandes du genre:
* un deuxième problème est la séparation entre les fonctions de plot et de lecture des fichiers de données. Gnuplot est très fort pour lire des fichiers formatés en colonne, avec des séparateurs variés, ou en matrice (sans abscisses ni ordonées explicites), ou encore avec des dates/heures. Heureusement, cette partie du code est déjà relativement séparée du reste.
* enfin, pour ce qui est de l'export graphique, je suis d'avis qu'il faut garder la plupart des terminaux gnuplot comme ils sont : latex, metapost, gd (gif, png, jpeg) et cairo (svg, postscript, pdf, mais Xlib, Win32, Quartz). La bonne nouvelle est que tout ce code existe déjà ! Gnuplot 4.2 utilise cairo pour le terminal interactif 'wxt', un patch est en développement pour exporter en pdf avec (et ce patch est minuscule comparé au code déstiné à cairo déjà dans gnuplot, c'est la force de cairo), et il serait relativement simple de l'étendre sous forme de librairie pour que gnuplot exporte vers n'ilmporte quelle surface que gnuplot sait gérer.
Il ya donc du travail, mais rien n'est impossible. S'il y a des volontaires, au passage...
Pour ce qui est de la "propagande", c'est vrai que c'est curieux que le mail avec les identifiants d'accès soit envoyé automatiquement à tous les élèves de l'université. Il aurait été plus fin d'envoyer un mail indiquant que le partenariat existe, sans donner tous les détails, et qu'il est possible de demander un mot de passe pour en profiter.
Il faut aussi relativiser l'importance de ce genre d'offres: la plupart des pc ont déjà Windows, donc les élèves n'iront pas le retélécharger pour le plaisir. Sauf ceux qui l'ont piraté pour un pc d'assembleur, ok. Ceux-là sont en général déjà un peu bidouilleurs et ont sûrement entendu parler de linux. Et puis ils sont aussi souvent "gamers"...
Moi j'ai été agréablement surpris par ce système et j'en ai profité pour me télécharger un Windows XP et sa licence pour l'installer dans une machine virtuelle QEmu, légalement (puisque le Windows XP livré avec mon PC est déjà installé... sur mon PC). Je peux vérifier que ce que je développe tourne sous Windows, tout en restant dans mon système préféré, Linux !
Alors primo oublie ndiswrapper, les cartes a base de Prism sont gérées par le driver .. prism54.
Ceci dit, c'est pas gagné pour prism54, étant donné que les WG511 ne sont pas toutes les mêmes, et certaines dites "softmac" (comme la mienne) ne marchent pas avec le pilote libre prism54. Auquel cas ndiswrapper est la seule issue.
Netgear a eu la bonne idée de ne pas changer les vendor ID, ce qui fait qu'il est difficile de les distinguer. Cf la page de ndiswrapper sur les cartes wifi.
Je me trouvais dans le canal #cairo sur le serveur IRC de freenode quand Carl Worth (responsable de Cairo) et Zack Rusin discutaient de ces mesures, hier. Il était intéressant de voir la conservation franche entre les deux, Carl reconnaissant bien volontiers qu'il y avait encore du travail à faire, et Zack expliquant ses résultats. Comme le précise Zack dans son blog, la prochaine version de Cairo contiendra un nouveau tesselator (algorithme qui transforme un polygone compliqué en petites entités que la couche d'abstraction inférieure - png, xrender, opengl... - sait représenter) qui pourrait bien réduire l'écart. Toujours est-il que Zack est un pro de ces fameux tesselators, et qu'il a proposé à Carl de collaborer sur le sujet.
Il me semble qu'il faut faire un "bundle" sous MacOS X pour que les fenêtres de l'application obtiennent le focus. Voir [1]
Une alternative est de rajouter manuellement un appel vers "CPSEnableForegroundOperation" qui est dans la librairie CoreFoundation. Cherche le code dans les #ifdef __WXMAC__ dans le fichier wxwidgets.cpp de plplot par example [2].
Posté par tipote .
En réponse au journal Maxima.
Évalué à 2.
Ah effectivement j'avais fait un racourci et oublié Simulink, qui n'a sans doute pas d'équivalent libre, pas plus que LabView d'ailleurs (puisque tu parles d'interface graphique). Merci de la faire remarquer.
la plupart des codes des fonctions sont disponibles, ce qui est l'aspect le plus important pour les chercheurs.
Justement, en terme de licence, c'est loin d'être bien ! Les codes sont disponibles, mais sont-ils réutilisables ? Utiliser Matlab, c'est aussi s'enfermer... Bien entendu, en tant qu'employé, on ne choisit pas forcément et c'est dommage.
... le pilote "pwc" pour les webcams Philips est revenu dans le noyau dans une version qui fonctionne !
Pour rappel, il avait d'abord été retiré complètement parce qu'il contenait un module binaire pour le protocole de décompression depuis la webcam. Puis il avait été réintégré après avoir enlevé le module binaire, mais ne supportant plus les hautes résolutions par la même occasion. [1]
Pour ma webcam pcvc840 (Philips Toucan II), ce module réintégré ne me donnait que du gris, mais point d'image...
Dans le même temps, Luc Saillard développait une alternative [2].
Dans le noyau version 2.6.18, le numéro de version du pilote pwc (1.0.12) correspond à la dernière fournie par Luc. À la lecture des sources, il semble que même le code de décompression (open-source cette fois) a été intégré. Ma webcam me fournit une image maintenant !
Au départ, les version fournies par Luc avaient été critiquées parce qu'on avait supposé qu'il avait décompilé le binaire original plutôt que procédé par ingénieurie inverse. Cette supposition vient des tables de décompression que contient le pilote. Les sources contenues dans le noyau 2.6.18 contiennent ces tables, mais elles expliquent comment les obtenir mathématiquement, et pourquoi on les utilise (pour des questions de performances). Le doute semble donc être levé.
Posté par tipote .
En réponse au journal Maxima.
Évalué à 1.
Et bien tu ne me fera jamais utilisé quoique ce soit d'autre que Matlab. C'est cher, c'est vrai. Mais qu'est ce que c'est rapide et puissant. Quelque chose de bien codé en matlab est rapide a l'execution et rapide a developper. Un code C ne sera, généralement, pas vraiment plus rapide car c'est plus dur a coder pour arriver aux memes performances (mais en y passant beaucoup de temps avec les bonnes bibliothèques, on améliore quand meme les choses, mais vu le l'énergie que ca demande, ca vaut pas le coup).
Donc oui, les logiciels scientifiques sont cher, mais ceux que j'ai utilisé était un vrai bonheur, et ne sont pas destinés aux particuliers.
Il me semble qu'Octave peut être aussi rapide et puissant que Matlab avec "quelque chose de bien codé". En gros, tout ce que tu sais écrire vectoriellement sera très rapide (comme sum(M), où M est un vecteur), tandis que les boucles sont lentes (comme faire une boucle sur les coordonnées de M). Matlab est plus performant de ce côté-là parce qu'il contient un compilateur à la volée ("just in time", JIT) pour rattraper la lenteur des boucles. Mais ça ne fait qu'empêcher de prendre des bonnes habitudes et d'écrire vectoriellement.
Il y a aussi une question d'options de compilation. Je doute que toutes les distributions se valent dans ce domaine. Pour pousser Octave dans ses retranchements, il faut le compiler avec ATLAS, BLAS, LAPACK et compagnie. Ce n'est probablement pas partout le cas, et c'est dommage.
étant donné que dans l'industrie, il est souvent demandé de savoir utiliser les logiciels proprio, que doit on utiliser en TP ?
Tu crois qu'ils utilisent Maple dans l'industrie ? J'en doute. C'est quand même pour les calculs formels, hein ! C'est pas du calcul de structure...
Matlab ? Ça mérite d'être vérifié aussi. "Industrie" pour moi est synonyme de développement, conception. Matlab est peu utile dans ce cas. Il l'est plus dans le domaine de la recherche, et là je trouve que les laboratoires publics en particulier pourraient utiliser le libre bien plus.
Posté par tipote .
En réponse au message wxWidjets.
Évalué à 3.
wxWidgets est le nom générique de la librairie, chacun de ses ports sur chaque plate-forme porte un nom partculier. Sur Linux, c'est wxGTK (parce que c'est basé sur gtk+). C'est sans doute ce nom-là que tu dois chercher dans ton gestionnaire de paquets.
XGL est précisement un Xnest qui fournit GLX_EXT_texture_from_pixmap à partir de l'accélération OpenGL sous-jacente.
On est d'accord.
Novell l'a présenté comme le futur de X à des utilisateurs médusés.
Eh oui, le marketing... Bon, il y a une part de vrai quand même, les compositeurs basés sur OpenGL sont sans doute l'avenir même si les EFL arrivent à faire une quantité raisonnable d'effets en software. Xgl(x), lui, n'est qu'une partie de la pyramide. Et puis, dans tous les cas, (1) ça marche même si c'est suboptimal, (2) il n'y a vraiment pas de raison que ce soit plus instable qu'une autre implémentation, (3) c'est suffisant pour que compiz et compagnie nous montrent des choses au mieux jolies, au pire impressionnantes.
Ça aussi a crée un fort engouement pour des technologies immatures et mal comprises (avec des reflexions du type "même si compiz sert à rien, l'affichage de firefox iras plus vite").
Tiens, c'est intéressant. Pour avoir joué un peu avec Xgl et compiz, je confirme que ça n'accélère pas firefox, sans doute parce que la couche de composition rajoute quand même une bonne quantité de travail en plus au serveur (et ma carte graphique n'est plus toute jeune). Par contre, en théorie, ce n'est pas impossible. L'idée de Xgl, c'est de baser toutes les opérations graphiques sur OpenGL. Aiglx, lui, se contente de fournir un moyen de faire de la composition avec OpenGL, mais les autres opérations restent gérées par les habituels XAA, ou EXA quand ça marche. C'est d'ailleurs pour cela qu'a été introduite très récemment [1] une troisième architecture appelée "glucose" pour combler cette différence. La solution qui se dessine à l'horizon est donc un serveur X doté d'Aiglx pour la composition, et de "glucose" pour l'accélération des opérations graphiques habituelles.
Je ne peux rien dire concernant les EFL, ne les ayant jamais utilisées.
En ce qui concerne Xgl, AIGLX et consorts, il n'y a pas lieu d'en faire un fromage et de dire que l'un est une bidouille tandis que l'autre l'est moins.
Xglx n'est pas une bidouille, c'est juste une des solutions les plus directes au problème, même si elle ne permet pas de répondre aux objectifs à long terme. Est-ce que tu dirais qu'Xnest est une méchante bidouille ? Sans doute pas, parce que ça marche, et pouvoir faire tourner un deuxième serveur X à l'intérieur d'un premier est très utile pour le développement de certaines choses (en ce qui me concerne, je joue avec kicker ainsi). Xglx, c'est exactement ça, mais en puisant dans les ressources d'OpenGL en plus. Partant de là, il est possible de faire en sorte que ce serveur X basé sur OpenGL prenne tout l'écran, et c'est comme ça qu'il est utilisé en pratique dans les distributions.
Astucieux, moi je trouve ça astucieux.
AIGLX prend une approche différente, qui a ces avantages indéniables, mais aussi ces inconvénients. Impossible de faire tourner un Xnest avec AIGLX activé. Ou plutôt si, c'est possible, mais l'extension Composite n'est alors pas activée pour des raisons techniques qui m'échappent, donc compiz et metacity accompagné de son compositeur n'y fonctionneront pas...
À mon avis, Xglx a le mérite d'avoir accéléré le développement des gestionnaires de fenêtres avec compositeurs. C'est une bonne chose.
Quant à l'architecture du serveur X, je trouve bien ambitieux de vouloir la critiquer avant de réellement la connaître. Le serveur X est construit de manière modulaire (indépendamment de la façon dont il est distribué) autour de ses extensions, ce qui me semble plutôt une architecture évolutive. Les aspects du serveur X encore en retrait vont sans doute s'améliorer dans l'avenir, parce exemple la gestion dynamique des périphériques d'entrée, etc. Enfin, comparer l'architecture des EFL et du serveur X n'a pas beaucoup de sens, ce serait comparer la structure d'un moteur et de la voiture qui le porte. Comparer les EFL et Qt ou GTK a beaucoup plus de sens.
Comme le disent les commentaires ci-dessus, la compilation aux petits oignons pour sa propre machine ne rend pas les applications plus rapides d'un coup de baguette magique. Les réglages qui font les grosses différences pour la compilation, comme fvisibility=hidden pour qt/kde, ont de toute façon de grande chances d'être aussi utilisés par les distributions binaires.
Par contre, la modularité (décrite aussi plus haut) et le concept global de la distribution qu'on se construit soi-même apporte un grand plus en terme de performances. Par exemple, je viens d'installer une fedora core 4 et j'ai observé qu'un certain nombre de choses vraiment inutiles étaient en fonctionnement, comme les démons hplip alors qu'il n'y a pas d'imprimante hp ou comme le démon bluez alors qu'il n'y a pas de bluetooth. Sur ma sourcemage, une distribution source au concept proche de gentoo, rien de tout ça puisque le principe est de partir avec un système minimal et d'ajouter petit à petit ce dont j'ai besoin.
Je pense que le choix de Fedora et des autres grosses distributions binaires est guidé par la volonté de faire tout fonctionner au premier démarrage, sans intervention de l'utilisateur novice. C'est un avantage indéniable pour la catégorie d'utilisateurs en question, et qui ressemble d'ailleurs beaucoup à l'approche Windows si je ne m'abuse. Par contre, combien de fois je me souviens avoir lu sur des forums windows des remarques du genre "fait ctrl-alt-suppr et regarde si tu n'as pas des trucs inutiles"... eh bien maintenant on retrouve exactement les mêmes remarques pour les services sur fedora et compagnie.
En attendant, la fedora que je viens d'installer est d'un lenteur poussive et décourageante. J'espère que les mises à jour vont améliorer cette situation, parce que même si je suis capable de modifier la configuration, un utilisateur novice, lui, n'aurait pas forcément su.
Deux hypothèses (dans la série des conspirations):
1) En fait les majors se moquent du piratage, c'est juste qu'ils veulent déposer le bilan sans trop perdre la face. Leur stratégie actuelle est donc de marquer sur les pochettes que les cd sont protégés pour dégouter l'acheteur potentiel.
2) Au contraire, ils veulent montrer que les DRM ne sont pas si dangereuses que ça en faisant des vrai-faux cd DRMisés qui ne bloquent rien !
Plus sérieusement, je n'ai jamais eu beaucoup de soucis pour passer mes cd protégés en mp3/ogg. J'ai peut-être été chanceux.
[^] # Re: Octave
Posté par tipote . En réponse à la dépêche Calcul scientifique : Scilab 5 enfin libre. Évalué à 1.
>>Ce n'est peut etre pas la finalité, mais ça aide *beaucoup* a faire passer le message. Et assurer un minimum de lisibilité c'est bien.
>Pour moi, la lisibilité, c'est le travail de l'utilisateur, pas celui de l'outil qu'il utilise. J'irais même jusqu'à dire qu'un graphique lisible doit pouvoir se comprendre quand il est affiché en noir et blanc (mais c'est peut-être à force de bosser avec un chef daltonien ...)
Je suis d'accord avec ce dernier point, un graphe de qualité est aussi un graphe qui est lisible en noir et blanc. J'ai en effet des collègues daltoniens, et en plus l'imprimante du bureau est, comme dans bien des endroits, noir et blanc. De ce côté, gnuplot fait un très bon bouleau, l'export en postscript en noir et blanc produit des lignes en pointillés bien distinguables.
Je rajouterais qu'un bon logiciel de graphe doit être capable d'exporter dans tous les formats dont j'ai besoin : postscript (ou pdf) pour l'impression, pdf pour l'envoi par courrier électronique, svg (ou pdf) pour l'édition ultérieure, png également, mais aussi latex. Matplotlib gère bien le pdf depuis les dernières versions (merci à http://www.cairographics.org ), mais pas le latex. Gnuplot fait tout ça, et il le fait bien (le pdf avec cairo, c'est encore dans le CVS et pas en version officielle, mais ça vient!).
[^] # Re: Et Scicos?
Posté par tipote . En réponse à la dépêche Calcul scientifique : Scilab 5 enfin libre. Évalué à 1.
J'utilise un oscilloscope Agilent série 6000 pour faire de l'acquisition de données sur 4 voies. L'oscilloscope est connecté en usb2. Le programme tourne sous Windows, essentiellement parce que j'ai aussi d'autres instruments à contrôler qui n'ont pas de pilotes linux, et est construit de la sorte :
- sous-couche VISA fournie par Agilent (la seule partie non-libre),
- pyvisa
- numpy & scipy four le traitement de données
- pyqt pour l'interface graphique, avec pyqwt pour les graphes en tant que tels
Honnêtement, ça fonctionne remarquablement bien, et c'est particulièrement agréable de pouvoir écrire ainsi un programme dédié aussi rapidement avec tous ces éléments de qualité !
# Très bonne question !
Posté par tipote . En réponse au message Manipulations Images 12-bit. Évalué à 3.
J'ai rencontré le même problème, et je m'y confronte toujours. Dans mon cas, c'est une image venant d'une caméra CCD scientifique, qui sort du 12 bits, enregistré dans un PNG 16 bits.
Alors, ce qui suit a trait au 16 bits, mais s'applique peut-être aussi au 12 bits natif, à vérifier au cas par cas :
- Krita gère le 16 bits, peut donc remplacer Gimp (même si je trouve que les outils du premier sont légèrement moins agréables à utiliser que les outils du second)
- GraphicsMagick, un fork d'ImageMagick, se targue (je n'ai pas essayé) de supporter des profondeurs arbitraires, au moins pour le TIFF, sans doute pour les autres formats aussi:
TIFF format support is completely re-written to support all subformats, an arbitrary number of sample bits, floating point types, and improved performance.
Le 16 bits en tout cas semble bien supporté. Voilà donc de quoi faire du traitement de masse en ligne de commande.
- La Python Imaging Library gère au moins le PNG 16 bits, à vérifier pour les autres formats, mais j'ai confiance. C'est parfait pour transformer l'image en un tableau de données pour un traitement numérique en Python & Numerical Python. C'est ce que j'utilise quotidiennement.
- enfin, ImageJ, le fameux logiciel de traitement d'image à caractère scientifique écrit en Java, supporte les formats exotiques, à l'aide de plugins éventuellement. Personnellement, depuis que j'ai trouvé Krita, je n'y vois plus trop d'intérêt.
Voilà, j'espère que ceci te sera utile !
[^] # Re: bjr
Posté par tipote . En réponse au message Manipulations Images 12-bit. Évalué à 1.
[^] # Re: Bluetooth
Posté par tipote . En réponse au message Equivalent Airport Express pour linux. Évalué à 1.
La page de manuel à laquelle je pensais est celle-ci : http://wiki.bluez.org/wiki/HOWTO/AudioDevices
En gros, l'essentiel est dans les quelques lignes suivantes à rajouter dans le .asoundrc :
Après, il faudra demander aux applications, ou à pulseaudio (mais je n'ai pas testé parce que je n'ai pas pulseaudio sur ubuntu), d'utiliser la carte son nommée "bluetooth".
Pour ce qui est de la qualité du son, j'ai été très agréablement surpris : en fonctionnement normal, je n'entends pas de différence entre une connexion directe et la connexion bluetooth sur mon kit d'enceintes 2.1 Creative. D'après Wikipedia, le flux audio est encodé en "SBC", qui est semble-t-il un codec semblable au mp3 :
http://fr.wikipedia.org/wiki/SBC
Quand je parle de fonctionnement "normal", je veux dire "sans coupures". Dans mon expérience, c'est très dépendant du lecteur audio utilisé (audacious est bien meilleur qu'xmms par exemple). Avec xmms ou rythmbox, le son est parfois un peu coupé. C'est peut-être un problème de jeunesse du pilote de son, il faut préciser d'ailleurs qu'ubuntu est loin d'avoir la dernière version !
En bref : avec pulseaudio et la suite bluez récente, ça devrait être parfait !
# Bluetooth
Posté par tipote . En réponse au message Equivalent Airport Express pour linux. Évalué à 2.
J'ai acheté l'airport express d'abord, parce que mon portable est un macbook surtout (même s'il tourne avec ubuntu). Le problème est que le streaming vers les haut-parleurs correspond à un protocole fermé, qui n'est possible qu'avec iTunes (avec Wine sous Linux), ou avec des programmes obtenus par ingénieurie inverse, comme raop-play, qui sont à l'usage assez limités. Adieu Amarok, et autre lecteurs sophistiqués, à moins d'un travail assez lourd que je n'ai pas osé entreprendre (utiliser pulseaudio pour envoyer le son des applications à raop-play ?).
Finalement, je me suis tourné vers ce qui est actuellement standardisé pour le streaming du son : le bluetooth avec le profil a2dp. Un récepteur bluetooth-a2dp avec une sortie ligne coûte 89 euros à la fnac, et ça marche très bien depuis n'importe quelle application dans ubuntu, avec très peu de travail "manuel" (voir les pages sur le support audio de www.bluez.org). En plus, ça marche même avec le téléphone portable. Et ça marche même avec Windows sans installer aucun pilote ou application particulière.
L'inconvénient ? Si ta machine n'a pas de bluetooth, il faut acheter un dongle usb-bluetooth qui coûte une dizaine d'euros.
[^] # Re: Une solution
Posté par tipote . En réponse au message [Gnuplot] utiliser des dates avec des millisecondes. Évalué à 2.
[^] # Re: Une solution
Posté par tipote . En réponse au message [Gnuplot] utiliser des dates avec des millisecondes. Évalué à 1.
'scanf' accepte plusieurs spécifications numériques mais gnuplot n'accepte en entrée que des réels en virgule flottante double précision, donc lf est le seul spécificateur permis.
Quel autre type de donnée voudrais-tu entrer ?
[^] # Re: besoin ...
Posté par tipote . En réponse au message [Gnuplot] utiliser des dates avec des millisecondes. Évalué à 1.
Voir ma solution dans l'autre message. Pour info, je ne pense pas que les millisecondes soient ajoutées à gnuplot dans le timefmt, parce que cette fonction imite ce que propose le langage C, où les secondes sont des nombres entiers, sans autre subdivision... Regarde 'man time.h' pour t'en convaincre.
# Une solution
Posté par tipote . En réponse au message [Gnuplot] utiliser des dates avec des millisecondes. Évalué à 2.
Cette question est apparue il y a quelques temps (2004) dans la mailing-list de gnuplot. Voici un lien:
http://marc.info/?l=gnuplot-info-beta&m=108627878612170&(...)
(le développeur de gnuplot fait remarquer qu'avoir une résolution à la milliseconde quand on trace des choses qui s'étendent sur plusieurs jours n'a pas beaucoup de sens.)
Tu peux t'en sortir avec "using" en specifiant le format (tu perds alors le label en heures/minutes/secondes cependant). Par exemple, avec des dates de la forme 07/12/2007 18:46:01.870, tu doix pouvoir utiliser:
plot 'datafile' using ($1*3600*24+$4*3600+$5*60+$6):7 '%lf/%lf/%lf %lf:%lf:%lf %lf'
Contrairement au timefmt, ceci marchera parce que %lf désigne un nombre décimal, pas seulement un entier.
Remarque que je n'ai pas pris en compte les mois, parce qu'ils n'ont pas tout le même nombre de jours... donc ceci ne marche que pour des données d'un même mois.
Avec ça, les étiquettes de l'axe des abscisses ne seront plus formattées, mais indiquées en nombre de secondes cumulées. Si ça ne te convient pas, on doit pouvoir trouver une solution...
J'espère que ceci va t'aider.
# cdrkit
Posté par tipote . En réponse au message K3B et fichiers de 4GO. Évalué à 1.
Avec cdrkit, l'équivalent de mkisofs est geniosimage.
Bon courage !
[^] # Re: Et pourquoi pas une libgnuplot ?
Posté par tipote . En réponse à la dépêche Gnuplot 4.2 est disponible !. Évalué à 5.
Très bonne remarque. Je suis de ceux qui aimeraient voir gnuplot devenir aussi une librairie. Il y a bien Qwt (C++) et matplotlib (python), mais si on avait une vraie librairie en C, on pourrait imaginer des bindings vers n'importe quel langage.
Voici le statut actuel des choses:
* le problème majeur est d'extraire une API du code de gnuplot. Actuellement, le 'parser' (analyseur lexical/syntaxique) de gnuplot est complètement mélangé au reste du code. Il faudrait séparer tout ce petit monde en deux couches distinctes, la première étant l'interface utilisateur, la deuxième étant accessible en tant que librairie "standard", via des commandes du genre:
gnuplot_crerate_context(...);
gnuplot_set_borders(...);
gnuplot_set_pm3d(...);
gnuplot_plot(data);
* un deuxième problème est la séparation entre les fonctions de plot et de lecture des fichiers de données. Gnuplot est très fort pour lire des fichiers formatés en colonne, avec des séparateurs variés, ou en matrice (sans abscisses ni ordonées explicites), ou encore avec des dates/heures. Heureusement, cette partie du code est déjà relativement séparée du reste.
* enfin, pour ce qui est de l'export graphique, je suis d'avis qu'il faut garder la plupart des terminaux gnuplot comme ils sont : latex, metapost, gd (gif, png, jpeg) et cairo (svg, postscript, pdf, mais Xlib, Win32, Quartz). La bonne nouvelle est que tout ce code existe déjà ! Gnuplot 4.2 utilise cairo pour le terminal interactif 'wxt', un patch est en développement pour exporter en pdf avec (et ce patch est minuscule comparé au code déstiné à cairo déjà dans gnuplot, c'est la force de cairo), et il serait relativement simple de l'étendre sous forme de librairie pour que gnuplot exporte vers n'ilmporte quelle surface que gnuplot sait gérer.
Il ya donc du travail, mais rien n'est impossible. S'il y a des volontaires, au passage...
# Mon avis de développeur occasionnel
Posté par tipote . En réponse au journal propagande MS à la fac, par la fac.... Évalué à 2.
Il faut aussi relativiser l'importance de ce genre d'offres: la plupart des pc ont déjà Windows, donc les élèves n'iront pas le retélécharger pour le plaisir. Sauf ceux qui l'ont piraté pour un pc d'assembleur, ok. Ceux-là sont en général déjà un peu bidouilleurs et ont sûrement entendu parler de linux. Et puis ils sont aussi souvent "gamers"...
Moi j'ai été agréablement surpris par ce système et j'en ai profité pour me télécharger un Windows XP et sa licence pour l'installer dans une machine virtuelle QEmu, légalement (puisque le Windows XP livré avec mon PC est déjà installé... sur mon PC). Je peux vérifier que ce que je développe tourne sous Windows, tout en restant dans mon système préféré, Linux !
[^] # Re: Probleme interface chaise/clavier
Posté par tipote . En réponse au message ndiswrapper avec une carte netgear WG511. Évalué à 1.
Ceci dit, c'est pas gagné pour prism54, étant donné que les WG511 ne sont pas toutes les mêmes, et certaines dites "softmac" (comme la mienne) ne marchent pas avec le pilote libre prism54. Auquel cas ndiswrapper est la seule issue.
Netgear a eu la bonne idée de ne pas changer les vendor ID, ce qui fait qu'il est difficile de les distinguer. Cf la page de ndiswrapper sur les cartes wifi.
# Collaboration
Posté par tipote . En réponse au journal Benchs QT VS Cairo. Évalué à 10.
# Focus
Posté par tipote . En réponse au message Compilation d'un programme sous Mac OS X avec wxWidgets. Évalué à 1.
Une alternative est de rajouter manuellement un appel vers "CPSEnableForegroundOperation" qui est dans la librairie CoreFoundation. Cherche le code dans les #ifdef __WXMAC__ dans le fichier wxwidgets.cpp de plplot par example [2].
[1] http://en.wikipedia.org/wiki/Bundle_(Mac_OS_X)
[2] http://plplot.sourceforge.net/
[^] # Re: oubli
Posté par tipote . En réponse au journal compiz et aiglx dans ma sid box !. Évalué à 2.
Ça se passe par là : http://www.kde-apps.org/content/show.php?content=46021
[^] # Re: Quelques mots sur Maxima
Posté par tipote . En réponse au journal Maxima. Évalué à 2.
Justement, en terme de licence, c'est loin d'être bien ! Les codes sont disponibles, mais sont-ils réutilisables ? Utiliser Matlab, c'est aussi s'enfermer... Bien entendu, en tant qu'employé, on ne choisit pas forcément et c'est dommage.
# Et dans la discrétion...
Posté par tipote . En réponse à la dépêche Sortie du noyau Linux 2.6.18. Évalué à 7.
Pour rappel, il avait d'abord été retiré complètement parce qu'il contenait un module binaire pour le protocole de décompression depuis la webcam. Puis il avait été réintégré après avoir enlevé le module binaire, mais ne supportant plus les hautes résolutions par la même occasion. [1]
Pour ma webcam pcvc840 (Philips Toucan II), ce module réintégré ne me donnait que du gris, mais point d'image...
Dans le même temps, Luc Saillard développait une alternative [2].
Dans le noyau version 2.6.18, le numéro de version du pilote pwc (1.0.12) correspond à la dernière fournie par Luc. À la lecture des sources, il semble que même le code de décompression (open-source cette fois) a été intégré. Ma webcam me fournit une image maintenant !
Au départ, les version fournies par Luc avaient été critiquées parce qu'on avait supposé qu'il avait décompilé le binaire original plutôt que procédé par ingénieurie inverse. Cette supposition vient des tables de décompression que contient le pilote. Les sources contenues dans le noyau 2.6.18 contiennent ces tables, mais elles expliquent comment les obtenir mathématiquement, et pourquoi on les utilise (pour des questions de performances). Le doute semble donc être levé.
Profitez bien de la vidéo-conférence ! [3]
[1] http://linuxfr.org/2005/05/31/19026.html
[2] http://www.saillard.org/linux/pwc/
[3] http://tipote.free.fr/ekiga.png
[^] # Re: Quelques mots sur Maxima
Posté par tipote . En réponse au journal Maxima. Évalué à 1.
Il me semble qu'Octave peut être aussi rapide et puissant que Matlab avec "quelque chose de bien codé". En gros, tout ce que tu sais écrire vectoriellement sera très rapide (comme sum(M), où M est un vecteur), tandis que les boucles sont lentes (comme faire une boucle sur les coordonnées de M). Matlab est plus performant de ce côté-là parce qu'il contient un compilateur à la volée ("just in time", JIT) pour rattraper la lenteur des boucles. Mais ça ne fait qu'empêcher de prendre des bonnes habitudes et d'écrire vectoriellement.
Il y a aussi une question d'options de compilation. Je doute que toutes les distributions se valent dans ce domaine. Pour pousser Octave dans ses retranchements, il faut le compiler avec ATLAS, BLAS, LAPACK et compagnie. Ce n'est probablement pas partout le cas, et c'est dommage.
Tu crois qu'ils utilisent Maple dans l'industrie ? J'en doute. C'est quand même pour les calculs formels, hein ! C'est pas du calcul de structure...
Matlab ? Ça mérite d'être vérifié aussi. "Industrie" pour moi est synonyme de développement, conception. Matlab est peu utile dans ce cas. Il l'est plus dans le domaine de la recherche, et là je trouve que les laboratoires publics en particulier pourraient utiliser le libre bien plus.
# wxGTK
Posté par tipote . En réponse au message wxWidjets. Évalué à 3.
[^] # Re: Plussagement
Posté par tipote . En réponse au journal Apercu Enlightenment v17. Évalué à 2.
On est d'accord.
Eh oui, le marketing... Bon, il y a une part de vrai quand même, les compositeurs basés sur OpenGL sont sans doute l'avenir même si les EFL arrivent à faire une quantité raisonnable d'effets en software. Xgl(x), lui, n'est qu'une partie de la pyramide. Et puis, dans tous les cas, (1) ça marche même si c'est suboptimal, (2) il n'y a vraiment pas de raison que ce soit plus instable qu'une autre implémentation, (3) c'est suffisant pour que compiz et compagnie nous montrent des choses au mieux jolies, au pire impressionnantes.
Tiens, c'est intéressant. Pour avoir joué un peu avec Xgl et compiz, je confirme que ça n'accélère pas firefox, sans doute parce que la couche de composition rajoute quand même une bonne quantité de travail en plus au serveur (et ma carte graphique n'est plus toute jeune). Par contre, en théorie, ce n'est pas impossible. L'idée de Xgl, c'est de baser toutes les opérations graphiques sur OpenGL. Aiglx, lui, se contente de fournir un moyen de faire de la composition avec OpenGL, mais les autres opérations restent gérées par les habituels XAA, ou EXA quand ça marche. C'est d'ailleurs pour cela qu'a été introduite très récemment [1] une troisième architecture appelée "glucose" pour combler cette différence. La solution qui se dessine à l'horizon est donc un serveur X doté d'Aiglx pour la composition, et de "glucose" pour l'accélération des opérations graphiques habituelles.
[1] http://lists.freedesktop.org/archives/xorg/2006-August/01752(...)
[^] # Re: Plussagement
Posté par tipote . En réponse au journal Apercu Enlightenment v17. Évalué à 8.
En ce qui concerne Xgl, AIGLX et consorts, il n'y a pas lieu d'en faire un fromage et de dire que l'un est une bidouille tandis que l'autre l'est moins.
Xglx n'est pas une bidouille, c'est juste une des solutions les plus directes au problème, même si elle ne permet pas de répondre aux objectifs à long terme. Est-ce que tu dirais qu'Xnest est une méchante bidouille ? Sans doute pas, parce que ça marche, et pouvoir faire tourner un deuxième serveur X à l'intérieur d'un premier est très utile pour le développement de certaines choses (en ce qui me concerne, je joue avec kicker ainsi). Xglx, c'est exactement ça, mais en puisant dans les ressources d'OpenGL en plus. Partant de là, il est possible de faire en sorte que ce serveur X basé sur OpenGL prenne tout l'écran, et c'est comme ça qu'il est utilisé en pratique dans les distributions.
Astucieux, moi je trouve ça astucieux.
AIGLX prend une approche différente, qui a ces avantages indéniables, mais aussi ces inconvénients. Impossible de faire tourner un Xnest avec AIGLX activé. Ou plutôt si, c'est possible, mais l'extension Composite n'est alors pas activée pour des raisons techniques qui m'échappent, donc compiz et metacity accompagné de son compositeur n'y fonctionneront pas...
À mon avis, Xglx a le mérite d'avoir accéléré le développement des gestionnaires de fenêtres avec compositeurs. C'est une bonne chose.
Quant à l'architecture du serveur X, je trouve bien ambitieux de vouloir la critiquer avant de réellement la connaître. Le serveur X est construit de manière modulaire (indépendamment de la façon dont il est distribué) autour de ses extensions, ce qui me semble plutôt une architecture évolutive. Les aspects du serveur X encore en retrait vont sans doute s'améliorer dans l'avenir, parce exemple la gestion dynamique des périphériques d'entrée, etc. Enfin, comparer l'architecture des EFL et du serveur X n'a pas beaucoup de sens, ce serait comparer la structure d'un moteur et de la voiture qui le porte. Comparer les EFL et Qt ou GTK a beaucoup plus de sens.
[^] # Re: Faîtes chauffer les CPU
Posté par tipote . En réponse à la dépêche Gentoo 2006.1 est prête !. Évalué à 3.
Comme le disent les commentaires ci-dessus, la compilation aux petits oignons pour sa propre machine ne rend pas les applications plus rapides d'un coup de baguette magique. Les réglages qui font les grosses différences pour la compilation, comme fvisibility=hidden pour qt/kde, ont de toute façon de grande chances d'être aussi utilisés par les distributions binaires.
Par contre, la modularité (décrite aussi plus haut) et le concept global de la distribution qu'on se construit soi-même apporte un grand plus en terme de performances. Par exemple, je viens d'installer une fedora core 4 et j'ai observé qu'un certain nombre de choses vraiment inutiles étaient en fonctionnement, comme les démons hplip alors qu'il n'y a pas d'imprimante hp ou comme le démon bluez alors qu'il n'y a pas de bluetooth. Sur ma sourcemage, une distribution source au concept proche de gentoo, rien de tout ça puisque le principe est de partir avec un système minimal et d'ajouter petit à petit ce dont j'ai besoin.
Je pense que le choix de Fedora et des autres grosses distributions binaires est guidé par la volonté de faire tout fonctionner au premier démarrage, sans intervention de l'utilisateur novice. C'est un avantage indéniable pour la catégorie d'utilisateurs en question, et qui ressemble d'ailleurs beaucoup à l'approche Windows si je ne m'abuse. Par contre, combien de fois je me souviens avoir lu sur des forums windows des remarques du genre "fait ctrl-alt-suppr et regarde si tu n'as pas des trucs inutiles"... eh bien maintenant on retrouve exactement les mêmes remarques pour les services sur fedora et compagnie.
En attendant, la fedora que je viens d'installer est d'un lenteur poussive et décourageante. J'espère que les mises à jour vont améliorer cette situation, parce que même si je suis capable de modifier la configuration, un utilisateur novice, lui, n'aurait pas forcément su.
# Vrai-faux cd protégé
Posté par tipote . En réponse au journal Faux CD et vraie colère .... Évalué à 2.
1) En fait les majors se moquent du piratage, c'est juste qu'ils veulent déposer le bilan sans trop perdre la face. Leur stratégie actuelle est donc de marquer sur les pochettes que les cd sont protégés pour dégouter l'acheteur potentiel.
2) Au contraire, ils veulent montrer que les DRM ne sont pas si dangereuses que ça en faisant des vrai-faux cd DRMisés qui ne bloquent rien !
Plus sérieusement, je n'ai jamais eu beaucoup de soucis pour passer mes cd protégés en mp3/ogg. J'ai peut-être été chanceux.