Sytoka Modon a écrit 4538 commentaires

Je suis assez d'accord avec toi avec les + et les manques. Je continue de penser que la contravariance est mieux qua la covariance, surtout qu'elle n'engendre aucun problème de typage. les personnes qui ont développé Sather l'ont bien montré.

Il manque aussi les itérators de Sather qui simplifie grandement l'arbre des classes.

Enfin, en plus de pouvoir rajouter des méthodes a des classes, il faudrait aussi pouvoir supertypé l'arbre des classes, c'est à dire introduire une nouvelle classe en plein milieu de l'arbre.

Un des problèmes d'Eiffel est que l'arbre des classes est trop rigide et trop imbriqué, du coup, c'est très difficile de le faire évoluer. Or, par définition, un langage se doit d'évoluer, il y a toujours quelques erreurs de conception.

> Ca ne t'empêche pas de le faire tourner sur une Debian si tu veux

Ca, je suis au courant. Ils ne valident que RHEL et Suse. Or la debian est super utilisé (évidement, on va tous dire que sa distribution est super utilisé mais il faut être aussi réaliste, la debian avec son développement communuatiare, indépendante... est incontournable, sauf pour les logiciels propriétaire !).

Il pourrait donc au moins faire l'effort pour la debian, surtout que la certification debian ne coute pas un centime contrairement a RHEL (enfin or cout de développemnt). Il suffit de mettre sur le site un paquet valable pour debian. C'est pas comme sous Windows ou il faut payer pour avoir le logo Microsoft Certified.

Bref, il ne se défonce quand meme pas trop....

> C'est d'ailleurs un sacré cirque pour s'assurer que ca tourne sur n
> version de Linux

Pourquoi ? Il suffit de compiler en statique et d'avoir une archive autonome... que les personnes installent où elles veulents, en général sous /opt

> frais de formation serait conséquent.

T'entend quoi par là ? La grande majorité des écoles d'ingénieur en mécanique sont des écoles publiques. Les frais d'inscription sont heureusement encore faible (je dis encore car avec leur réforme des universités qu'ils ont mis de coté mais qu'ils gardent au cas où, ca risque de faire mal).

Sinon, pour Catia, c'est un problème de CV. Tu places 10 fois mieux tes étudiants en stage s'ils ont fait du Catia, car Catia est largement numéro 1.

Pour les coùts, Dassault ou IBM sont capables de te donner en taxe d'apprentissage ce qu'ils te demandent en licence... ce que ne sont pas toujours capable de faire les concucrrents payant. Bilan : il faudrait être fou pour choisir autre chose !

Pour l'avoir enfin essayer avec XP sous Linux+qemu+kernelkqemu..., je peux dire que XP est BEAUCOUP plus reactif avec cette nouvelle version. Je ne vois quasiment pas la différence avec un Windows natif.

Tout cela est bien subjectif mais heureusement, il n'y pas pas que les chiffres pour nous guider.

Et il ne prends pas les paramètres du proxy dans la config d'IE ?

C'est FAUX !

Je connais quelqu'un qui a vu tourner Catia sous Linux ! De toute manière, tout ca sont des mensonges, ces logiciels ayant été conçu sous UNIX, le portage sous Linux devrait être relativement simple, surtout qu'OpenGL tourne maintenant relativement bien.

Catia (Dassault) est marié à IBM depuis le début. IBM doit protéger ses stations. Si Catia, comme SolidWorks tourne sous Linux, c'est la fin des stations scientifiques sous Windows ainsi que sous les autres UNIX. En plus Dassault a une politique plus proche de Microsoft, exploitant au maximum son monopole, que de l'open source. Même dans les projets RNTL (Réseau National des Technologies Logiciels), il ne joue le jeu de l'open source que du bout des doigts, contraint et forcés.

Il faut aussi savoir que pas mal des ces logiciels tournent sous Windows avec Exceed, qui est un serveur X non libre ! Alors, ne leur laissez pas dire que c'est optimisé pour la plateforme Windows ! Bref, ils n'ont aucune volonté d'ouverture.

Le seul qui fait des effort est ProE qui d'ailleurs marche très bien.

Ces histoires de logiciels scientifiques ne tournant pas sous Linux n'ont aucune raison d'être aujourd'hui autre que politique.

Pour ceux que ca intéresse, Matlab, Comsol (FemLab), Fluent, Ansys tourne très bien sous Linux. Les deux premiers ont même des versions complètement native sous AMD64 (pour fluent, il y a des bouts en 64b et d'autre en 32b, pour Ansys, je n'en sais rien).

T'as raison, j'avais oublié ma règle cfengine qui me met automatiquement nvi ou wim par defaut ;-)

Et comment tu mets à jour ta machine ?

Sachant qu'une machine qui n'est pas à jour est une machine morte, surtout sous Windows, IE est indispensable.

Et lorsque tu as un GROS logiciel de type Catia, il serait idiot de la part de Dassault de le livrer sans toutes les librairies (Non, ne rêvez pas, Catia n'existe pas en version Linux sauf chez Dassault).

Pour être complet, il y a aussi : vym == View Your Mind

http://www.insilmaril.de/vym/

Un des problèmes est que Fabrice n'est pas très clair. A une époque, il parlait d'une certaine somme d'argent pour libérer le code. Combien ?

Si on ne sais pas la somme qu'il souhaite, ni le valeur du compteur à un instant t, qui irait donner de l'argent. Le module se développant, la somme souhaité augmente...

Bref, on n'a aucun moyen de savoir où on en est, et ce point là est effectivement génant.

Surtout que j'ai lu hier que le module libre qvm86 pouvait aller aussi vite que l'ancien module kqemu dans certain cas, il est donc un peu bête que ce module ne soit pas intégré en standard dans qemu. On arrive à la limite de la logique du semi-libre où un module non libre est privilégié devant un module libre, du seul fait du principal (et génial) développeur.

Personnellement, je récupère qemu sur

http://www.dad-answers.com/qemu/

Il y a une image réalisée quasiment toutes les nuits. Par exemple

qemu-snapshot-2006-03-30_23.tar.bz2

De même qu'il y a des bouts de boch dans qemu (au niveau du driver de la carte reseau et de la carte vga si mes souvenirs sont bons). Il serait idiot de ne pas reprendre du code qui marche bien et de ne pas en profiter pour l'améliorer au passage.

Je ne sais pas comment Fabrice Bellard à mis en place la virtualisation dans kqemu mais je ne serais pas étonné qu'il se soit inspiré des idées implémentées dans Xen.

Sauf que je crois que c'est nvi l'editeur par défaut sous debian. En effet, nvi est plus proche des bogues de l'original que vim. Mais j'ai vu passer sur une liste debian qu'ils envisagent de remplacer nvi par vim-tiny.

Je ne parle pas d'une debian où tu installes tout. Je parle d'une debian minimale. Si tu installes vim, il prend la place de nvi par défaut car il a une priorité plus élevée (voir le système des update-alternative de debian pour cela).

Qemu et Xen n'ont aucun rapport en tant que projet.

Qemu était (et est toujours) un émulateur, au même titre que boch. Qemu tourne en espace utilisateur (c'est une application standard). Cependant, depuis quelque temps, il y a un module noyau, kqemu, qui permet d'accélérer le code qui tourne en espace utilisateur dans la machine virtuelle (il y en a même un autre qvm86 si mes souvenirs sont bons qui est libre mais moins performant). Conclusion, jusqu'a il y a peu, avec qemu+kqemu, on lancait une machine virtuelle et tout le code des applications dans la machine virtuelle était directement envoyé au CPU de la machine réelle, seul le code du noyau virtuel était émulé (donc aussi tous les appels systèmes que l'on trouve dans une application).

Xen virtualise un système. Ce n'est pas un émulateur. Donc avec Xen, on lance des machines virtuelles et Xen se charge de la répartition des ressources physiques, notament du CPU, pour chacune des machines virtuelles. Dans Xen, le code noyau ainsi que les applications des machines virtuelles sont directement exécutés par le CPU de la machine réelle. En pratique, avec Xen, les applications tournent quasiment aussi vite dans une machine virtuelle que si elles étaient directement exécutés sur une machine normale. Au niveau des serveurs, c'est très intéressant, il vaut bien mieux virtualiser. C'est bien plus souple dans ces conditions.

Maintenant, avec la dernière version de kqemu, on peux faire de la virtualisation complète, même du code noyau ! Donc qemu marche un peu sur les plate-bande de Xen. D'où ma remarque finale et le lien entre les deux projets.

Cependant, il ne faut pas se tromper. En production, avec des machines virtuelles, il faut être capable d'attribuer des ressources aux différentes machines, de superviser en temps réel. Je ne suis pas sur que les deux projets soit comparable de ce point de vue là aujourd'hui.

Je vois que tu limites à la plateforme windows pour ton développement. Tu peux donc prendre des modules Win32:: de perl. Par exemple les Win32::Gui qui utilisent la couche graphique native de Windows (jamais testé, je préfère personnellement perl/tk ou perl/gtk+glade).

Pour ta connection avec Excel via COM, tu as ton bonheur avec Win32::OLE. Ca parle même d'Excel sur la documentation du module OLE (j'avoue que je n'ai pas été plus loin).

http://search.cpan.org/~jdb/libwin32-0.26/OLE/lib/Win32/OLE.(...)

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 ;-)