Sytoka Modon a écrit 4546 commentaires

Puisque tu ne connais pas Python, pourquoi tu t'accroches a lui et tu ne fais pas tout en perl. Il y a tout sur le CPAN. Juste un exemple qui m'a pris moins de 5mn a trouver

http://search.cpan.org/~kwitknr/DBD-Excel-0.06/Excel.pm

> ls voulaient implémenter un support (propriétaire) d'Objective-C dans
> GCC...mais comme la GPL impose de libérer le code ils ont plutot
> décidé de

créer java ...

Ben oui, java n'est pas sortis tout seul du chapeau de Sun. Il partageait NexT, ils ont eu java tout seul ;-) Java est clairement le bébé d'ObjectiveC.

C'est vraiment facile de faire une application graphique en perl. Tu peux le faire avec plein de toolkit : gtk, tk...

Je ne connais pas ton cahier des charges mais ce genre de truc est souvent plus simple à faire en langage de script. Va voir sur le CPAN, c'est pas le nombre de paquetage qui manque. Tu peux même attaquer ton fichier excel avec du SQL si mes souvenirs sont bon (voir les modules DBD/DBI). Pour la partie graphique, tu peux aussi la charger depuis l'API glade.

Ce qu'il te faut, c'est dibs

http://www.csua.berkeley.edu/~emin/source_code/dibs/

Je n'ai pas encore testé, c'est dans ma liste des taches à faire...

Lire pour la derniere URL

http://www.gnu.org/software/sather/docs-1.2/tutorial/iterators1034.html

C'est la aussi ou on voit toute la puissance des itérator de Sather. En Sather, les classes ont des attributs, des méthodes et des itérators. Le gros avantage est de pouvoir itérer sur plusieurs iétrateurs dans une même boucle et le compilateur peux optimiser en mettant toute la partie initialisation en dehors de la boucle. L'autre gros avantage, il n'y a plus de structure for, while until ! Inutile, dépassé. for devient l'iterator upto! sur les entiers

for (i=1, 1000) {....} 

devient

loop
  1.upto!(1000)
  ....
end

Idem pour while

while (test) {....}

qui devient

loop
  while!(test)
 ...
end

L'itérator while! est appellé sur aucun objet. En fait, on pourrait le mettre sur un objet booléen #BOOL, true ou false et considérer que cette notation n'est que du "syntatic sugar". Bref, tout un tas de structure devienne bien plus simple avec cette notion d'itérator.

• http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)

La contruction de l'itérator while! est très simple (les autres aussi), en voici un exemple d'implémentation

while!(pred:BOOL) is
   -- Yields as long as 'pred' is true
   loop
      if pred then
         yield;
      else
         quit;
      end;
   end;
end;

Si on s'authorise l'opérateur ? : du C, cela raccourci carrément le code

while!(pred:BOOL) is
   loop
      pred ? yield : quit;
   end;
end;

• http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...) l

Qui a dis que l'algo de la stegano était libre ? Comme ce code ne te sers a rien, il n'y a aucune raison que tu le connaisse. Cela n'empeche pas la lecture du film ni sa copie. Ca permet juste de tracer chaque copie de film de manière unique a la sortie de l'usine. D'ailleurs, je suis sur qu'il y a u truc d'équivalent sur les billets de banque et cela ne gène personne.

Et même si l'algo de stegano était libre, comme tu ne sais pas ce qui est codé, par exemple ta clef publique chiffré par la clef privé de l'usine, ca t'avance a quoi. Je croyais, j'ai peut être tords, qu'il y avait des procédés de stéganographie inviolable aujourd'hui (inviolable au même sens que l'algorithme RSA dans un autre domaine).

Mais depuis que j'ai fait pour premier post, j'ai l'impression que mon idée est identique a ce qu'ils appellement watermarking.

Génial, faut que j'essaye ca ;-)

Dans le systeme présenté ci-dessus, le serveur chiffre avec la clef publique de l'utilisateur. Cependant, rien ne l'empêche a ce moment la de mettre une clef unique par stéganographie ;-) Du coup, retrouver la source devient beaucoup plus facile, chaque film diffusé étant unique.

Je crois que le Perl est plus récent que le C++ ;-)

Quitte a parler du java et du C#, t'aurais pu évoquer le petit frère du C++, l'ObjectiveC, qui en ai la grande source d'inspiration.

> Perso je pense que ça peut être bien pratique.

C'est vrai que c'est pratique mais avec du recul, c'est pratique pendant combien de temps ? Combien coute de faire des "restart" ? Au bilan, tu acceptes de diminuer ta sécurité pour un problème annexe, qui ne peux pas être, a ma connaissance, dé-activé.

Sinon, nous sommes d'accord, gconf en fait bien plus que ce pour quoi il est appeller : les fichiers de configuration.

Le propre d'UNIX est la séparation des taches. A cause de ce gconf qui en fait trop, gimp n'utilise pas gconf.

Moi, ca me gonfle qu'ekiga utilise gconf pour ces parametres (/A priori/, il ne partage rien avec les autres). Ca m'oblige a avoir un daemon gconfd qui tourne.

Idem, si je fais mon propre programme. Je ne veux pas forcement avoir un daemon gconfd qui soit associé a mon programme. D'ailleurs, pour mes fichiers de configuration, j'utilise le format YAML qui est très simple et répond parfaitement au cahier des charges.

Bref, j'aime beaucoup de programmes fait avec les librairies gtk et gnome mais je n'ai pas envie d'avoir toute l'artillerie de gnome derrière pour un simple problème de configuration de mes applications (remarque, c'est pareil avec les application kde). Je ne veux pas être enfermer a choisir soit les applications gnome ou les applications kde. Je veux pouvoir piocher et utiliser les applications qui me plaisent. Bref, la base gnome a un peu trop tendance a t'enfermer dans son environnement.

Je reprends, cvs gère les fichiers binaires, il faut mettre l'option -kb. Ce que je ne me souviens plus, c'est si il garde chaque version, j'avais le souvenir qu'il ne gardait que la dernière.

subversion gère aussi parfaitement les méta-données. Pour les fichiers binaires, il les détecte automatiquement et n'en conserve que les xdelta de différence.

Bref, subversion est très robuste, simple.

Si tu veux un mode local, tu peux utiliser la surcouche décentralisé svk qui marche aussi très bien.

Les autres gestionnaires de versions, je ne les connais pas trop mais j'ai souvent eu l'impression qu'ils sont plus orientés code source que subversion. Par exemple, les gestionaires basé sur la notion de patch sont super bien pour améliorer le développement de code source, ca oblige a dissocier les modfications que l'on apporte en fonction d'objectif clair. L'idée derrière est de pouvoir appliquer les patch dans un autre ordre, et c'est généralement possible.

Dans le cas de fichier binaire, on est obligé de suivre l'ordre des "commit". La notion de patch a donc moins d'intérêt il me semble.

A propose de gconf, il y a des paramètres dans gconf qui sont pris en charge instantanément. Ce n'est pas le cas des fichiers de configuration. Si tu modifie la configuration d'Apache par exemple, il faut lui envoyer le signal HUP pour qu'il recharge a chaud sa configuration. C'est le "restart" des anciens Window Manager basé sur le génial fvwm.

Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.

Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)

Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.

Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...

A mes souvenirs, cvs écrases l'ancienne version binaire par la nouvelle.

Par contre, subversion fait bien tout cela. Pourquoi cherche tu autre chose sachant que tu en parles dans ta question ?

PS : par contre, ce serait bien que subversion versionne les archives (zip, tar, gz...) en versionnant leur contenu et non en global.

Je suis entouré de gens lambda et ils ne passent pas leur vie au bureau a changer les paramêtres de leur bureau !

Si ils utilisent un bureau a distance via xvnc, tu peux leur préparer un bureau bien configuré sous icewm (comme ca ils ne sont pas trop perdus) et t'as gagné un paquet de ressources.

Avoir un utilitaire graphique qui t'aide a paramétrer, pourquoi pas. Mais faut pas non plus en faire une condition éliminatoire.

Je suis d'accord que ma phrase sur gconf était un peu hors sujet. J'ai deja pas mal posté sur gconf et je maintiens que ce truc n'est pas bon et que c'est un equivalent des variables globales. D'ailleurs, il y a un daemon gcond qui tourne en permanence (meme que parfois, ce co. survie a une fermeture de sessions...).

Personnellement, ca fait longtemps que je suis passé sur une base debian. Sur cette base la, a ma connaissance, il n'y a pas 50 gestionnaire de paquet, quel que soit la distribution. Par ailleurs, il m'arrive da faire mes propres .deb car c'est plus facile à déployer ensuite sur un gros parc de machine.

Donc, je ne vois pas le problème que tu invoques, surtout que j'avais parlé de faire une API commune. Après, que chaque distribution fasse ses propres paquetages avec ses numéros de version, c'est autre chose et cela n'a rien a voir avec le gestionaire lui même.

Malheureusement, il n'y avait aucune blague dans mon post.

Dans la fonction publique, tu es soumis à la règle des marchés, tu n'as donc pas le choix de ce que tu achètes. DELL a perdus le marché des serveurs au CNRS et c'est NEC qui l'a. Cela veut dire que si tu achètes via le CNRS, tu te retrouves avec une machine NEC, ou alors, faut justifier que NEC ne propose pas ce que tu souhaites.

Cependant, NEC a l'air assez ouvert même si leur matériel est surtout validé pour RedHat et Novell (et Windows). Tous les moyens sont donc bons pour qu'il s'ouvre encore plus et valide un plus grand nombre de distribution, notament une base différente que la RedHat.

Il en ai de même avec pas mal de logiciels propriétaires : matlab, comsol (ex femlab)... Si tu ne les installes pas sous RedHat ou Novell, tu perds le support, et ceci même si ca marche très bien.

Quelqu'un pourra m'expliquer cette folie de se faire chacun ses commandes pour installer les rpm ? urpmi, apt2rpm, yum... Pourquoi ils ne travaillent pas ensemble ?

C'est si dur que cela que de décrire un cahier des charges et une API et de partager ensuite le développement ?

sauf que debian ne les sors pas officiellement ! Et puis,les debian se mettent a jour sans CD d'une version a une autre... Bref, ca n'a rien a voir.

On m'a refilé un serveur sous fedora, j'attend la panne matériel pour le reformater sous debian. Rien à voir, mais si il y a du monde dans la salle, vous pouvez comme moi titiller NEC a propos de debian qui a le marché serveur au CNRS. A chaque fois que je les ais au bout du fils, je leur en parle.

Personnellement, j'utilise pwm car je ne veux pas de barre de titre ayant la largeur de la fenêtre... Cependant, je ne bidouille pas mon environnement TOUS les jours ! J'ai personnellement un script qui a tous les paramêtres qui vont bien, je le lance au démarrage et c'est bon. Les rares fois ou je veux modifier un paramêtre, je "restart" mon gestionaire de fenêtre.

Désolé mais le tout graphique avec du gconf en variable globale... c'est bien un peu mais des choses simples, c'est bien aussi.

> Ça va « descendre » assez vite.

J'ai un copain au Canada (Montréal), son fournisseur lui file une adresse IPv6, rien en IPv4. Dommage, on a jamais reussi a communiquer correctement, il y a toujours un canal qui foire.

Bref, IPv6 est déjà là.

Sinon, j'ai jamais fait de la programmation réseau mais j'avais compris qu'avec le systeme de couche, on ne se préocuppait pas trop de la couche en dessous dans tcp/ip. Il n'y a pas d'instruction pour ouvrir une socket reseau vers un nom dns et hop, ca se débrouille ?

> Comment faire pour sélectionner son éditeur de texte dans Gnome?

Je viens de faire l'essai ce soir, c'est vrai que Nautilus ne tiens pas compte de la variable d'environnement EDITOR. Ca sers a quoi ces bonnes vielles variables ?

T'as raison, ca marche sur mon ordinateur de bureau. Je vais voir le problème chez moi ce soir ;-)

> Enfin voila, ca ne vous intéresse peut être pas mais c'est un peu ce
> que j'attend d'un éditeur de texte ...

J'ai aussi besoin de faire des selections carré, c'est à dire pouvoir sélectionner un bloc rectangulaire positionné n'importe ou et pouvoir le déplacer graphiquement. nedit fait ca super bien ;-)

Sinon, c'est vrai que le copier coller qui ne suis pas la tradition unix du bouton du milieu est fatal pour mon gedit 2.8.3. Bref, gedit, ca va pour lire un readme mais guère plus.

> Et je réponds à nouveau que si tu cherches la récursivité, tu utilises
> des noeuds (donc des balises). D'un point de vue temps de
> définition, c'est à peu près équivalent (avec une DTD).

C'est un peu un probleme. Surtout que les noeuds sont fait pour etre un conteneur et non expliciter le noeud lui-même. Par exemple, dans une interface graphique, je peux assigner des signaux aux éléments graphiques sous forme d'attribut et mettre d'autres éléments graphiques dedans. Si je passe mes atributs sous forme de noeud, je peux avoir des clash avec les noeuds qui sont déjà la.

Il est vrai que si les attributs deviennent des arbres a part entière, la ligne de démarcation attribut/noeud sera moins claire, ce sera au schema de la préciser. Mais au moins on aura une double structure symétrique ayant une API propre laissant le développeur s'exprimer.

> Euh non. :-)

T'as raison, j'avais mal saisie la dynamique de la phrase.

Pour la suite, je suis d'accord que le développement du XML texte a dynamiser, popularisé, révolutionné (...) le développpement de librairies de recherche dans les arbres. et je trouve ca TRES BIEN. C'est le XML texte que je n'aime pas.

> XML, dans sa forme « écrite » n'a rien à voir avec ce qu'est XML
> fondamentalement.

Tu vois, on est d'accord ;-) Sauf que moi, le XML fondamentalement, je l'appelle arbre. Même que parfois, on est limité et on a la structure de graphe qui est pas mal et ce serait bien si elle profitait de la même énergie que les arbres.

> on s'en fiche un peu.

Malheureusement non. La mode Tomcat est au fichier de conf imbittable. Tu prends les fichiers de conf des modules Perl sur le CPAN, du beau YAML, c'est que du bonheur.

> NB : en TeX/LaTeX, tu as aussi des attributs, qui ne sont pas
> récursifs non plus, et qui - surprise ! - sont non ordonnés :

Attention, TeX est reprogrammable ! Si LaTeX avait eu la même énergie mise dessus que le XML, on aurait une API tip-top. Je sais qu'il y a des problèmes avec TeX mais regardes le nombre de personnes qui sont dessus. C'est quand même impressionant pour ce résultat.

> Si tu continues comme ça, tu pourrais dire qu'à part XSL/T, les
> langages de transformation de XML ne ressemblent pas trop à du
> XML.

Justement, je continue. C'est pour cela que je parle de fatras. Au moins, en TeX, tu programmes en TeX ;-)

> Et après ? XML est fait pour être lu par des machines.

Encore une fois, je suis d'accord. Mais autant prendre alors un format binaire. C'est bien plus performant. Si mes souvenirs sont bon, le format HDF est tout a fait capable de stocker un arbre XML de manière portable.

Bref, ca montre encore une fois qu'il y a un réel problème de conception, et qu'on a pour longtemps.

> D'ailleurs, XSL/T, ça a beau être super puissant, c'est tellement
> chiant à utiliser que dès que je peux éviter ben... j'évite :-)

J'avais pas osé en parlé mais comme horreur, c'est merveilleux. Dire que j'ai croisé des personnes qui ont critiqué mes Makefile sur des arguments fallacieux (en gros, c'est pas sexy ! Bon ok, la syntaxe des Makefiles a aussi des defauts). Le XSLT, c'est vraiment poussé le XML sur une mauvaise voie et ca montre clairement les limites de la syntaxe. Limite qu'on aurait pas eu avec une syntaxe de type LISP.

D'ailleurs, avec AxKit, tu peux faire des filtres en XSLT ou en XPS (XpathScript, un savant mélange de Perl et de XPath). Et bien, j'ai fait quasiment tous mes filtres en XPS ;-) Le seul défaut, c'est pas portable, le XPS n'ayant jamais percé en dehors de AxKit (dommage).