En fait les 2 projets s'entendent déjà sur un certains nombre de point. On peut notamment citer tous les projets sur http://www.freedesktop.org .
C'est projets représente la partie fonctionnel du bureau utilisateur Linux/UNIX . Après Gnome, KDE, Xfce, Lxde et les autres ne suivent pas forcement les normes. Cependant tu peux toujours leur poser la question je suis sur que l'on te répondra avec des arguments et loin des trolls (freedesktop est apolitique :) ).
La documentation de open [http://docs.python.org/3.0/library/functions.html#open] nous indique alors comment l'on configure l'ouverture d'un flux :
========= ===============================================================
Character Meaning
--------- ---------------------------------------------------------------
``'r'`` open for reading (default)
``'w'`` open for writing, truncating the file first
``'a'`` open for writing, appending to the end of the file if it exists
``'b'`` binary mode
``'t'`` text mode (default)
``'+'`` open a disk file for updating (reading and writing)
``'U'`` universal newline mode (for backwards compatibility; unneeded
for new code)
========= ===============================================================
Tu doit pouvoir alors convertir un flux de donné suivant un encodage spécifié (en l'occurrence celui du système).
PS: je n'ai pas fait de python depuis 1 ans
PS2: la documentation de python 3 est vraiment superbe
En même temps, seul les états-unis sont touchés par ce problème.
De plus même si Novell est un 'collabo' je pense que leur politique se tient vis-à-vis de leurs clients. Ils proposent la même infrastructure que la solution soit linux ou windows.
Pros sDNA (ou Protocol Buffer) :
- Les performances sont excellentes (pas d'analyse de texte lourde)
- Représentation et données stocké dans un même fichier (facilite le suivi de versions)
Cons sDNA :
- ne permet pas d'interchanger des données entre programmes écrit dans différents langages (ProtocolBuffer de google génère les structures de données dans chaque langage à partir d'une description)
- ne fournit pas de facilitées pour valider et transformer les données
D'après ce que j'ai compris leur sDNA (pour struct DNA) permet de représenter un objet de façon arborescente (jusque le identique à XML) et de le stocker dans un format binaire.
Typiquement toutes les données sont typées et enregistrées suivant un format binaire connu et non-changé (pour google : [http://code.google.com/apis/protocolbuffers/docs/encoding.ht(...)]). On stocke alors une représentation des données à la version N (le modèle en UML ou la struct en C) ainsi que les données elle-mêmes.
A la lecture on connaît la représentation des données à la version actuelle M et on sait que l'encodage n'a pas changé. Toutes les données sauvegardé sont chargés dans la représentation des données M suivant l'algorithme suivant :
- si l'élément existe dans N et dans M alors on le charge directement
- si l'élément existe dans N mais pas dans M on l'ignore
- si l'élément existe dans M mais pas dans N on le fixe à une valeur par défaut.
En appliquant ces règles on conserve une portabilité binaire entre les versions si les représentations de données ne changent pas trop.
Concernant les différences avec XML on peut considérer ceci :
- Un codage binaire est beaucoup beaucoup beaucoup plus performant que du XML
- Un codage binaire est illisible pour un humain
- En XML on peut réaliser des règles de transformations XML -> XML donc la portabilité entre versions est toujours assurée à partir de ses règles
Super la police mais j'ai une question à poser pour les experts :
Le problème de la police 'rufscript' est qu'elle se contente d'imiter une écriture humaine après une phase d'apprentissage à partir de glyphes générés dans cette phase.
Est-il possible dans une police d'ajouter du bruit de façon à introduire des variations cohérentes dans les glyphes (pseudo kaptcha) ?
J'imagine que quelqu'un ici c'est déjà posé la question non ?
Pour les personnes ne sachant pas vraiment ce qu'est 'Le Canard' ou ne l'ayant jamais lu, c'est un journal d'information satirique.
Les révélations faites dans ce quotidien sont avant tous là pour dénoncer une situation. Il faut donc lire ce journal avec précautions si l'on ne veut pas partir en déprime à la fin ;) . L'écriture est belle et les rédacteurs sont cohérent et franc dans leurs idées.
Pour les personnes allergiques au papier (j'imagine qu'il y en a sur DLFP), je cite la page d'accueil du 'Canard' [http://www.canardenchaine.com/]: notre métier, c'est d'informer et de distraire nos lecteurs, avec du papier journal et de l'encre. C'est un beau métier qui suffit à occuper notre équipe.
Je pense que la mallette compatible arrivera sur le marché en même temps que [AUTOSAR].
Pour simplifier [AUTOSAR] c'est juste une norme automobile logiciel qui doit standardiser les dialogues entre différentes cartes électroniques embarquées [ECU] et le chef de la voiture [BC]. Si l'on connait alors l'interface [CAN] de chaque [ECU], on pourra alors facilement diagnostiquer soit même l'ensemble des fonctions de la voiture en se branchant directement sur le réseau [CAN] de la voiture et non seulement les fonctions décrites dans [ODB-II] ou [EOB].
Globalement, le diagnostique [ODB-II] ou [EOBD] permet le diagnostique à l'extérieur du véhicule alors que le sniffage/envoi de trames [CAN] permet de maitriser le fonctionnement interne de la voiture (interfaces des [ECU]).
Actuellement le souci c'est que chaque constructeur 'standardise' à sa sauce les interfaces des [ECU]s. Cependant ils utilisent quasiment tous le bus [CAN] comme réseau de communication. Pour moi, ce problème pourra être résolu lors de la standardisation des messages [CAN] ou de son successeur le [FlexRay].
Pour information, après 1min de recherche sur google tu entend parler de 'bluetooth-alsa' qui, sur sa page sourceforge, indique qu'il suffit de regarder [http://wiki.bluez.org/wiki/HOWTO/AudioDevices].
Je n'ai pas testé mais vu le nombre d'information disponible sur cette page, je pense que tu va trouver ton bonheur (perso j'ai trouvé le mien [https://fedorahosted.org/d-feet/]) .
Au niveau specs, comme tout ce qui se passe dans ce domaine, il *suffit* d'acheter une licence pour avoir les outils et la doc autour.
Le problème est que cette licence n'est absolument pas donnée. Il faut juste qu'une entreprise/développeur qui a la licence implémente alors un backend GCC (comme le SSE ...) ou une API ouverte pour que la puissance du DSP soit disponible.
La seule différence entre Scons et Waf (au niveau fonctionnalités / rapidité / facilité ) est minime mais si importante :
- Scons doit être installé sur le système
- Waf est uniquement fournis avec les sources et est indépendant de l'installation système (python uniquement)
Concernant la démarche, as-tu opté pour une génération automatique du binding ou une écriture manuel du 'binding' ? (note: je ne connait pas squeak)
La tendance actuelle pour les 'binding' est de faire une recherche des composants par introspection [1][2]. En ayant regardé rapidement l'introduction sur squeak, on retrouve un 'Object Inspector' les propriétés de chaque objet Gtk+ sont elle visibles (même partiellement) ?.
Et enfin un dernière question, si je veux utiliser une librairie GObject existante es ce facilement faisable (en relation avec le premier point) ?
Félicitation pour ton travail, il va peut-être permettre d'utiliser réellement un programme squeak dans la vie de tous les jours ;) .
Je pense que dans ton benchmark (qui est très interressant pour comparer les preformances brutes d'un terminal) il manque un calcul de temps de démarrage.
Si on veut se servir d'un terminal histoire de lancer 3-4 scripts tout fait. Je pense qu'utiliser xterm est un bon compromis entre performance brute et dépendances/temps de démarrage.
L'avantage d'utiliser xterm vient aussi par l'habitude, exemple:
tu veux dépanner un pote, tu n'as pas besoin de t'adapter à son envirronment de bureau tu lance juste xterm (tu est sur qu'il est installé) et tu fait ce que tu veux.
Ceci dit si tu utilise un environnement qui te procure un terminal plus adapté (ergonomie, consommation mémoire, etc...) utilisons le.
[^] # Re: ?
Posté par Clément David (site web personnel) . En réponse au journal Fusion Rails/Merb, quelques questions.. Évalué à 6.
C'est projets représente la partie fonctionnel du bureau utilisateur Linux/UNIX . Après Gnome, KDE, Xfce, Lxde et les autres ne suivent pas forcement les normes. Cependant tu peux toujours leur poser la question je suis sur que l'on te répondra avec des arguments et loin des trolls (freedesktop est apolitique :) ).
[^] # Re: Tout les bugs ? vraiment ?
Posté par Clément David (site web personnel) . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 3.
Il suffit d'utiliser le module fileinput [http://docs.python.org/3.0/library/fileinput.html] que l'on trouve dans la documentation de sys.argv [http://docs.python.org/3.0/library/sys.html?highlight=filein(...)].
La méthode fileinput.input [http://docs.python.org/3.0/library/fileinput.html#fileinput.(...)] permet d'ouvrir un flux (par défault le flux d'arguments) suivant un mode spécifié.
With mode you can specify which file mode will be passed to open(). It must be one of 'r', 'rU', 'U' and 'rb'.
La documentation de open [http://docs.python.org/3.0/library/functions.html#open] nous indique alors comment l'on configure l'ouverture d'un flux :
========= ===============================================================
Character Meaning
--------- ---------------------------------------------------------------
``'r'`` open for reading (default)
``'w'`` open for writing, truncating the file first
``'a'`` open for writing, appending to the end of the file if it exists
``'b'`` binary mode
``'t'`` text mode (default)
``'+'`` open a disk file for updating (reading and writing)
``'U'`` universal newline mode (for backwards compatibility; unneeded
for new code)
========= ===============================================================
Tu doit pouvoir alors convertir un flux de donné suivant un encodage spécifié (en l'occurrence celui du système).
PS: je n'ai pas fait de python depuis 1 ans
PS2: la documentation de python 3 est vraiment superbe
[^] # Re: Microsoft a compris l'intérêt qu'il y a dans l'ouverture de ses sp
Posté par Clément David (site web personnel) . En réponse au journal Où est donc passée la version Linux d'Active Directory. Évalué à 1.
De plus même si Novell est un 'collabo' je pense que leur politique se tient vis-à-vis de leurs clients. Ils proposent la même infrastructure que la solution soit linux ou windows.
[^] # Re: Tentative d'explication
Posté par Clément David (site web personnel) . En réponse au journal Blender - explication du DNA. Évalué à 2.
Pros sDNA (ou Protocol Buffer) :
- Les performances sont excellentes (pas d'analyse de texte lourde)
- Représentation et données stocké dans un même fichier (facilite le suivi de versions)
Cons sDNA :
- ne permet pas d'interchanger des données entre programmes écrit dans différents langages (ProtocolBuffer de google génère les structures de données dans chaque langage à partir d'une description)
- ne fournit pas de facilitées pour valider et transformer les données
[^] # Tentative d'explication
Posté par Clément David (site web personnel) . En réponse au journal Blender - explication du DNA. Évalué à 3.
Typiquement toutes les données sont typées et enregistrées suivant un format binaire connu et non-changé (pour google : [http://code.google.com/apis/protocolbuffers/docs/encoding.ht(...)]). On stocke alors une représentation des données à la version N (le modèle en UML ou la struct en C) ainsi que les données elle-mêmes.
A la lecture on connaît la représentation des données à la version actuelle M et on sait que l'encodage n'a pas changé. Toutes les données sauvegardé sont chargés dans la représentation des données M suivant l'algorithme suivant :
- si l'élément existe dans N et dans M alors on le charge directement
- si l'élément existe dans N mais pas dans M on l'ignore
- si l'élément existe dans M mais pas dans N on le fixe à une valeur par défaut.
En appliquant ces règles on conserve une portabilité binaire entre les versions si les représentations de données ne changent pas trop.
Concernant les différences avec XML on peut considérer ceci :
- Un codage binaire est beaucoup beaucoup beaucoup plus performant que du XML
- Un codage binaire est illisible pour un humain
- En XML on peut réaliser des règles de transformations XML -> XML donc la portabilité entre versions est toujours assurée à partir de ses règles
Sur ce bonne lecture :)
[^] # Re: HS
Posté par Clément David (site web personnel) . En réponse au journal 3DSecure à l'APRIL !. Évalué à 1.
Si si avec mon installation toute fraiche de XXuntu.
Je préfère retourner sous vista qui lui à l'installation ne prend que 10 Go comme ça je peux télécharger plus pour gagner plus...
[^] # HS: Mieux vaut innover
Posté par Clément David (site web personnel) . En réponse au journal «Cloud computing» libre. Évalué à 4.
Le problème de la police 'rufscript' est qu'elle se contente d'imiter une écriture humaine après une phase d'apprentissage à partir de glyphes générés dans cette phase.
Est-il possible dans une police d'ajouter du bruit de façon à introduire des variations cohérentes dans les glyphes (pseudo kaptcha) ?
J'imagine que quelqu'un ici c'est déjà posé la question non ?
[^] # Re: Dangereuses persepctives
Posté par Clément David (site web personnel) . En réponse au journal Fréquence journaux, fréquence dépêches. Évalué à 0.
Fanboy1 : Tu as un bel ordinateur
Fanboy2 : le tien aussi est beau
Fanboy1 & 2: C'est normal c'est des 'Pomme'...
[^] # Re: Ne jetons pas le canard avec l'eau de la marre...
Posté par Clément David (site web personnel) . En réponse au journal L'express et le Canard. Évalué à 4.
Les révélations faites dans ce quotidien sont avant tous là pour dénoncer une situation. Il faut donc lire ce journal avec précautions si l'on ne veut pas partir en déprime à la fin ;) . L'écriture est belle et les rédacteurs sont cohérent et franc dans leurs idées.
Pour les personnes allergiques au papier (j'imagine qu'il y en a sur DLFP), je cite la page d'accueil du 'Canard' [http://www.canardenchaine.com/]:
Tous est dit...
[^] # Re: la diversité
Posté par Clément David (site web personnel) . En réponse au journal Jabber XMPP, comment l'exploiter (enfin) au mieux ?. Évalué à 4.
Cette library support plusieurs protocoles dont tous ceux supportés par Pidgin (en utilisant libpurple )
[^] # Re: ampoules
Posté par Clément David (site web personnel) . En réponse au journal L'informatique est sensiblement identique à la mécanique. Évalué à 3.
Article à lire et à recommander http://www.automobile-club.fr/budget .
[^] # Re: M'en parle pas...
Posté par Clément David (site web personnel) . En réponse au journal L'informatique est sensiblement identique à la mécanique. Évalué à 10.
Pour simplifier [AUTOSAR] c'est juste une norme automobile logiciel qui doit standardiser les dialogues entre différentes cartes électroniques embarquées [ECU] et le chef de la voiture [BC]. Si l'on connait alors l'interface [CAN] de chaque [ECU], on pourra alors facilement diagnostiquer soit même l'ensemble des fonctions de la voiture en se branchant directement sur le réseau [CAN] de la voiture et non seulement les fonctions décrites dans [ODB-II] ou [EOB].
Globalement, le diagnostique [ODB-II] ou [EOBD] permet le diagnostique à l'extérieur du véhicule alors que le sniffage/envoi de trames [CAN] permet de maitriser le fonctionnement interne de la voiture (interfaces des [ECU]).
Actuellement le souci c'est que chaque constructeur 'standardise' à sa sauce les interfaces des [ECU]s. Cependant ils utilisent quasiment tous le bus [CAN] comme réseau de communication. Pour moi, ce problème pourra être résolu lors de la standardisation des messages [CAN] ou de son successeur le [FlexRay].
[AUTOSAR] : AUTOSAR
[ECU] : http://en.wikipedia.org/wiki/Electronic_control_unit
[BC] : Body Controller, carte électronique principale de la voiture
[CAN] : Controller_area_network
[ODB-II] : http://www.obdii.com/
[EOB] : Normes équivalente à ODB-II applicable en europe, plus d'info http://www.eobd.fr/
[FlexRay] : FlexRay
[^] # Re: En bref
Posté par Clément David (site web personnel) . En réponse au journal Sources d'android disponibles.. Évalué à 2.
[^] # Re: Attention à mencoder
Posté par Clément David (site web personnel) . En réponse au journal Essai de transcoding avec Gstreamer-0.10. Évalué à 1.
Suivant les paramètres et la qualité de ton logiciel, tu dois pouvoir gagner en place/qualité.
[^] # Re: format video ?
Posté par Clément David (site web personnel) . En réponse à la dépêche Rasterman passe au Treo-650 et continue d'améliorer e17. Évalué à 3.
[^] # Re: Taaa tatada !........Taaaa taaa tadada !
Posté par Clément David (site web personnel) . En réponse au journal Magnum, le journal de la communauté francophone de mandriva est sorti. Évalué à 2.
"flashçapucestpaslibre"
"lesvideosurinternetcestpasaccessible"
"youtubeçapu"
Il suffit juste de faire une redirection avec tinyurl.
[^] # Re: Information de google
Posté par Clément David (site web personnel) . En réponse au journal Le bluetooth sur les distrib GNU/linux. Évalué à -1.
# Information de google
Posté par Clément David (site web personnel) . En réponse au journal Le bluetooth sur les distrib GNU/linux. Évalué à 1.
Je n'ai pas testé mais vu le nombre d'information disponible sur cette page, je pense que tu va trouver ton bonheur (perso j'ai trouvé le mien [https://fedorahosted.org/d-feet/]) .
[^] # Re: marché de la console
Posté par Clément David (site web personnel) . En réponse à la dépêche OpenPandora, l'autre console de jeux libre. Évalué à 1.
[^] # Re: Entièrement libre ?
Posté par Clément David (site web personnel) . En réponse à la dépêche OpenPandora, l'autre console de jeux libre. Évalué à 1.
Le problème est que cette licence n'est absolument pas donnée. Il faut juste qu'une entreprise/développeur qui a la licence implémente alors un backend GCC (comme le SSE ...) ou une API ouverte pour que la puissance du DSP soit disponible.
[^] # Re: Démo en ligne
Posté par Clément David (site web personnel) . En réponse à la dépêche Publication de Anwiki 0.1.0 alpha 1. Évalué à 1.
Le lien redirige vers http://demo.anwiki.com/wait.html et cette page n'existe pas.
[^] # Re: scons pas bien
Posté par Clément David (site web personnel) . En réponse au journal scons 1.0. Évalué à 1.
- Scons doit être installé sur le système
- Waf est uniquement fournis avec les sources et est indépendant de l'installation système (python uniquement)
A mettre en relation avec [http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems], apparemment il est aussi possible de fournir Scons avec les sources.
Waf mangez en, c'est bon
# Démarche utilisée ?
Posté par Clément David (site web personnel) . En réponse à la dépêche SqueakGtk. Évalué à 3.
La tendance actuelle pour les 'binding' est de faire une recherche des composants par introspection [1][2]. En ayant regardé rapidement l'introduction sur squeak, on retrouve un 'Object Inspector' les propriétés de chaque objet Gtk+ sont elle visibles (même partiellement) ?.
Et enfin un dernière question, si je veux utiliser une librairie GObject existante es ce facilement faisable (en relation avec le premier point) ?
Félicitation pour ton travail, il va peut-être permettre d'utiliser réellement un programme squeak dans la vie de tous les jours ;) .
[1] : http://live.gnome.org/PyBank
[2] : http://live.gnome.org/Vala
[^] # Re: Sun et StarOffice
Posté par Clément David (site web personnel) . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 1.
Il doit aussi y avoir (à mon avis) quelques améliorations à destination des entreprises.
[^] # Re: je suis trop vieux ?
Posté par Clément David (site web personnel) . En réponse à la dépêche Interface graphique fonctionnelle : encore un effort pour l'open source. Évalué à 3.
Si on veut se servir d'un terminal histoire de lancer 3-4 scripts tout fait. Je pense qu'utiliser xterm est un bon compromis entre performance brute et dépendances/temps de démarrage.
L'avantage d'utiliser xterm vient aussi par l'habitude, exemple:
tu veux dépanner un pote, tu n'as pas besoin de t'adapter à son envirronment de bureau tu lance juste xterm (tu est sur qu'il est installé) et tu fait ce que tu veux.
Ceci dit si tu utilise un environnement qui te procure un terminal plus adapté (ergonomie, consommation mémoire, etc...) utilisons le.