TImaniac a écrit 6423 commentaires

mmmh je crois savoir d'où vient ton problème.

Visiblement tu compiles ton plugin avec le source de l'attribute, puis tu recompiles le programme qui cherche les plugins avec ce même source... je me trompes ?
Donc du coup chacun a sa version de la définition, et malgrès le partage de source, le CLR (Common Langage Runtime, autrement dit l'environnement d'exécution, plus comunément appelé machine virtuelle, qui se lance avec la commande mono) voit 2 versions différentes (ils ont chacuns un numéro de version, etc.)

Ce qu'il faut faire dans ton cas précis :

compiler dans une dll tout ce qui doit être "partagé", autrement dit ce qui doit être connu des plugins et du gestionnaire de plugin, cad en gros les def d'attributes, les interfaces, les classes manipulables par les plugins, etc.
mcs -

ensuite tu compiles un plugin comme ceci :
mcs -target:library monPlugin.cs -r:MonAppliQuiContientLesDefs.dll

les def d'attributs sont dans MonAppliQuiContientLesDefs.dll.
Tu peux également y mettres ton gestionnaire de plugin, celui qui les charges, mais tu peux aussi mettre ton gestionnaire à part. Il se compilera alors de la même façon :
mcs -target:library monGestionnaire.cs -r:MonAppliQuiContientLesDefs.dll

ou dans une application :
mcs monAppli.cs -r:MonAppliQuiContientLesDefs.dll

en espérant que ca marche mieux maintenant :-)

Si ca marche toujours pas tu peux me mailer si tu veux.

Effectivement tu n'as pas bien compris le schmurck :)
Premièrement c'est normale le is null, tu fais ton test dans une boucle foreach, et tu peux très bien trouvé tout pleins d'autres attributes uqi ne sont pas les tiens.

En tout cas chez moi j'ai essayé ton attribute dans une dll, et j'ai testé avec ca :
Assembly asm = Assembly.LoadFrom("plugin.dll");
Attribute[] attributes = Attribute.GetCustomAttributes(asm);

foreach(Attribute attribute in attributes)
{
if (attribute is AssemblyDependencies)
{
Console.WriteLine("trouvé !");
AssemblyDependencies ds = (AssemblyDependencies)attribute;
foreach(string s in ds.Dependencies.Keys) Console.WriteLine(s+" : "+ds.Dependencies[s]);
}
}

et ma fois ca marche nickel, j'obtiens ca en résultat :
trouvé !
aa : 1.0.0.0
ee : 1.0.0.0

Sinon plutôt que de faire un attribute avec un nombre variable d'argument, tu peux aussi en mettre que 2, nom+version, et proposer à l'utilisateur de mettre plusieurs fois l'attribut s'il veut multiplié les dependances.

Ah oui aussi je sais pas trop ce que tu veux faire, mais la gestion des dépendances d'habitudes c'est un obulot réservé au CLR, et tu n'as absolument rien à faire pour les gérer mais bon :)

Gaim semble le mieux correspondre à tes besoins : il est multi-protocoles (yahoo, msn, aim, jabber, etc.), et tourne sous Linux et Windows.

Par contre pour la visio laisse tomber direct, y'a rien qui soit compatible avec les ténors du marché (MSN, etc.)
Pour faire de la visio il y a gnomemeeting, mais pas de support MSN donc, mais support netmetting.

Une bonne idée ?
Oui si elle était réalisable.
Si Apple peut se concentrer sur l'ergonomie de son OS, c'est avant tout parcqu'ils n'ont pas à se soucier des problèmes de matériel et de "généricité" de leurs applications.
Je dis pas que c'est pas possible, mais avant de vraiment concurrencer Windows, il faudrait que l'OS supporte la majorité des composants disponibles sur le marché, tout en relevant le chanllenge de faire une interface qui sache "s'adapter" au matos (une souris à 3 boutons c'est pas pareil qu'avec un seul, etc.)
Mon avis est que c'est trop de boulot pour eux, et que malgrès le sentiment de supériorité préteitneux dont fait preuve Steve Jobs face à son rival, ils ont nettement moins de boulot à fournir que MS ou les développeurs du LL autour de Linux.

Quelle est le rapport entre la fiabilité des solutions d'un éditeur proprio et le fait que LDLC est mal su apprécié son traffic web ?
Essayez d'être un petit peu pertinent des fois.

En même temps ca m'est arrivé d'attérir sur des pages douteuses (hem) me proposant d'installer un .xpi pour mon naviguateur... Je suppose que c'était pas pour m'installer une extension qui me gérait flash&co. Même si l'utilisateur est censé être conscient de son acte, c'est malheurement souvent comme ça que des millions d'utilisateurs d'un navigateur troué ont installé des spywares... Enfin comme d'hab la faille humaine est difficilement colmatable, mais bon si quelqu'un veut tenter d'envoyer un patch...

Pour revenir au test unitaire, il y a différente catégorie de test unitaire. Lorsque je fais une fonction par exemple, je fais un test unitaire assez exhautif avec gdb ou autre.
Non, il y a pas 15000 façon de faire des tests unitaires.
Y'a ceux qui font des tests unitaires, cad :
- qui SEPARENT les tests des classes/modules
- qui tests individuellement chaque classe/module avec son jeu de test
- qui propose une syntaxe permettant de rejouer ces tests
(et ceux qui vont jusqu'au bout, cad qui réalise leurs tests avant d'écrire le code)
Et y'a ceux qui dont des tests divers et variés, qui le mettent dans le code, qui ne test riende façon "unitaire", qui croivent qu'un assert dans le code est un test unitaire (le test unitaire est celui qui lève éventuellement une pré/post condition (en posant éventuellement d'autres conditions, mais ce n'est pas la condition en soit).

Alors pitié, le #ifdef DEBUG ce n'est pas du test unitaire.

Je teste ainsi pratiquement toutes les entrées de fonction.
Ca c'est bien mais celà n'a strictement rien à voir avec les tests unitaires.

Impossible, les méta-données sous forme d'attribut sont des propriétés STATIQUES attachée à une classe, une définition de méthode, etc.
Tu dois donc définir à l'avance les attributs en définissant la classe correspondante si tu veux pouvoir espérer utiliser les champs à l'intérieur.

Si les attributs ont été défini dans un autre assembly que le tient et que tu tombes dessus, tu as tout de même moyen de récupérer des infos à l'intérieur, tu fais de la reflection sur l'attribut trouvé (GetType) et tu te balade dans les propriétés ou méthodes (GetProperties, GetMethod, etc.)

En même temps tu devrais commencer par t'interroger toi même.
Si tu n'es pas capable de trouver toi même des arguments, pose toi des questions sur tes croyances et convictions : tu n'arriveras jamais à tenir un discours argumenté si tu n'es pas toi même convaincu par un certain nombre d'argument.

PS : un indice, si tu veux vriament attaquer Microsoft dans son ensemble, tu vas devoir faire dans l'idéologique et le philosophique, parcque côté technique tu vas vite t'attirer dans un gouffre sans fin puisque tu compareras forcement une particularité d'une application spécifique et en tirant des conclusions fallacieuses en généralisant sur un éditeur logiciel.

Si c'est juste une phrase qui te gène tant que ça, ingore là et passe ton chemin, non ?
Non il y a aussi le fait que le fait de favoriser la génération automatique des controllers pose des problèmes d'indépendance comme je viens de l'expliquer. Mais bon d'après ce que jugent les gens de mon dernier post mes propos ne sont pas intéressant donc je ne m'étendrais pas plus longtemps sur le sujet.

Si on regarde un peu les environnements actuels et qu'on regarde nextstep en même temps, ce qui me sidère c'est de voir que tous les autres on mis une dizaine d'année pour être presque aussi bien...
En même temps pour faire du RAD, le VB existe depuis 91... le Java depuis maintenant plus de 10 ans...

Alors donc je le demande encore une fois : qu'apporte NeXTStep de plus que la concurrence, aujourd'hui ? (afin de justifier son adoption)

Moi j'ai trouvé pas mal d'inconvénients :
- MVC c'est pas top.
- générer des controllers dépendant d'un framework graphique c'est pas top du tout.
- C'est gentil mais ca s'intègre nul part sauf sous Mac, et le modèle MVC fortement intégré ne permet pas d'envisager sereinement une indépendance de la couche graphique sans avoir à réécrire tous les controllers.
- la réutilisation du code basé sur le copié-collé c'est nul.
- la réutilisation de code C++ est limité au monde Mac.

Maintenant je veux les avantages et surtout atouts par rapport aux autres solutions.

Je me rends compte que c'est pas très malin: je veux créer une nouvelle instance d'une interface!!
Non non, tu demandes une instance de "type", qui dans ton code correspond au type concret d'un element, et pas une interface, donc ton morceau de code est tout à fait logique.
De manière générale tu te retrouveras de toute façon avec un problème récurrent : il faut appeler le constructeur du type concret, et là impossible d'être sûr qu'il y a un constructeur par défaut, une interface ne pouvant spécifier celà (ce qui est fort dommage).
Voici par ici le code que j'utilise dans un projet pour charger dynamiquement des plugins :
http://projet.ifsic.univ-rennes1.fr/cgi-bin/viewcvs.cgi/projet/src/(...)

celà marche nickel.
Tu remarqueras que je ne créé pas d'instance sur le tas (parcque j'ai besoin d'en faire pleins à d'autres moment), et que donc je me contente de mémoriser le Type trouvé dans une Hashtable.

Après le principe est exactement le même que ce que tu as proposé, à ceci prêt que j'utilise une classe abstraite (Module) plutôt qu'une interface, mais les 2 auraient été possibles.

Je pars aussi du principe que mes plugins prennent un argument particulier en constructeur (la classe abstraite réclamant un constructeur spécifique, à défaut de pouvoir l'imposer dans la classes fille le développeur va devoir se demander où trouver ce paramètre et lire la doc :) )

c'est qu'il est relativement simple d'encapsuler du code existant
Objective-C n'est pas le seul à proposer cette superbe fonctionnalité. Ce que je voulais dire c'est que c'est surtout compliqué d'utiliser plusieurs langages en parallèle, celà multiplie les coûts de maintenance, sans parler du déploiement... (la preuve celà marche que sur Mac)

On parle souvent de réutilisabilité, c'est le gateau à la crème de la programmation orientée objet. Avec ObjC c'est une réalité.
Stop on dirait un spot publicitaire :)

Alors question réutilisabilité, je veux : utiliser mes composants EJB, tout en interagissant avec des objets COM distribués.
Tu vois ce que je veux dire ?
La réutilisation c'est gentil mais il ne faut pas que ce soit un "copié-collé" d'un morceau de code C/C++ (ce qui limite tout de usite les possibilités d'ailleur) pour l'intégrer dans un composant Objective-C. C'est la pire solution de réutilisation que je connaisse : la maintenance sera affreusement répartie, pouf productivité en chute libre.

lequel est même déporté sur une autre machine, merci les DistributedObjects.
Mais dis donc c'est révolutionnaire tout ça à notr époque :)

GNUstep/Cocoa n'est pas la réponse ultime -- mais au moins pour créer une interface graphique, je te garantit que ça booste.
Mais comme d'hab je suis convaincu que GNUStep permet de gros gain de productivité si l'on compare à la programmation traditionnelle en C, mais si l'on compare avec des solutions plus modernes (JBuilder, Eclipse, Visual Studio), j'ai des gros doutes.

Le seul truc que j'aime bien et qui sort du lot par rapport à la concurrence, c'est effectivement le fait de créer automatiquement un controller. Celà peut être sympa pour faire du RAD, mais dans le cadre d'une vraie application où le controller est INDEPENDANT de l'interface, ben c'est foutu : là tu es limité à utiliser les widgets de GNUStep, pour une autre interface ben faudra recoder ton controller : résultat question gain de temps ben c'est retour à la case départ, voir tu recules encore plus.

Moi je peux te faire une démo en Java ou VB identique qui te prends également 2 lignes de codes à écrire :)

Enfin à part cette featurette (création automatique d'un controller) dont je t'ai montré les limites, je ne vois rien qui innove par rapport à la concurrence actuelle.

Alors oui GNUStep est une bonne solution, qui propose de nombreux avantages (notamment en terme de productivité par rapport aux autres solutions), mais je vois toujours pas l'intérêt de phrase du genre :
"vous allez développez 2 fois plus vite"
Non seulement celà ne veut rien dire, mais en plus si la phrase n'est pas finie, c'est volontaire : vous savez très bien que la comparaison date d'il y a 10 ans et ne tiens plus la route.

On retrouve le fameux esprit UNIX, une appli fait une et une seule chose, mais bien.
On peut aussi dire qu'on se retrouve effectivement avec l'esprit Unix, où chaque appli fait ce qu'elle veut comme elle veut et on a une intégration nulle à chier de l'ensemble, ce qui a entre autre conduit Linux à se demander s'il était vraiment prêt pour le desktop.

Pour le coup du D-Bus c'est bien gentil, mais SunBird vise aussi un public windowzien (je dirais même surtout un public windowzien, comme pour Firefox/Thunderbird) : ce n'est pas du tout la mentalité Unixienne qui prévaut chez ces utilisateurs, et à mon avis Outlook a encore de beaux jours devant lui si SunBird reste StandAlone.

Heuresement chez Novell/Ximian ils ont l'air décidé à porter Evolution sous Windows.

Ceci dit, attendre trois plombes pour que son calendrier charge, très peu pour moi.
Me dit pas qu'il ont séparé les projets parqcu'ils arrivent pas à lancer une appli dans un temps résonnable ? Ca fait un peu pitié tout de même... Il y a des produits bien plus lourds qui se lancent bien plus rapidement, des systèmes de cache mémoire, de chargement dynamique retardé, etc.

First application written was written 2 - 5 times faster.
mais plus vite que quoi ??
Y'a toujours pas d'élément de comparaison !

Maintenant, quand tu dis que le dev informatique a évolué, oui, et non.
Je parles surtout des "alternatives", commes les langages/framework tel Python, Java, .NET, etc, mais aussi les outils comme Eclipse, Visual Studio, etc.
Et là je ne suis pas du tout convaincu que TrucStep puisse se vanter d'améliorer notre productivité.

Par contre, pour implémenter le "contenu" de la brique, un autre langage peut être plus adapté, comme C++ par exemple.. enfin, c'est mon avis.
On croirait entendre les développeurs VB qui disent qu'il vont coder la partie métier en C++ derrière :) Et là tout à coup la productivité chutte lamentablement parcque justement faut utiliser autre chose...

Enfin tout ca pour dire que GNUStep et autre MachinStep ont été réellement innovant mais il est temps à mon avis d'essayer de faire prévalloir d'autres arguments pour le "vendre", l'argument de la productivité ne tenant plus beaucoup debout (je dis pas que que GNUStep est contre-productif, je dis juste que je suis moins convaincu de sa supériorité par rapport à d'autres solutions).

une étude publiée dans les années 90 concernant le développement sur NeXTSTEP indiquaient un facteur de 5 à 10 fois plus rapide
Pourquoi faut-il toujours un argument à la con comme celui-là ?
Ca me rappelle une blague : "Quelle est la différence entre un canard ?"
De plus le chiffre paraît complètment farfelu, même en imaginant qu'on puisse le comparer à quelque chose d'actuel.
Bref, j'en viens à me dire qu'ils ont une bonne dose de prétention exaspérente chez GNUStep, faudrait que quelqu'un leur explique que même si le projet initial semblait novateur et permettait effectivement un certain gain de temps, l'informatique a évolué, les langages et outils également.

Autant Firefox tout seul, je comprend l'intérêt.
Autant Thunderbird, oui effectivement pourquoi pas.
Autant un calendrier comme SunBird séparé d'un client mail j'ai plus de mal à comprendre...
D'habitude les calendriers c'est quand même plus sympa quand c'est utilisé dans un "groupware", bref, quand c'est intégré avec le client Mail, comme le font OutLook ou Evolution, ce qui fait d'ailleur leur force...
Je trouve dommage de vouloir "suivre" cette "mode" consistant à séparer les projet pour faire des applis standalone, effectivement c'est sans doute plus simple à faire, mais quand celà vient à l'encontre de l'ergonomie/fonctionnalités voilà quoi... J'aurais préféré un Thunderbird "Extended" avec Calendar intégré, sous forme d'add-on ou de version amélioré.

Forum :
http://www.dotnetguru.org/index.php?module=pnForum&func=viewfor(...) (les utilisateurs de ce site sont plutôt "qualifiés")
Sinon :
http://www.developpez.net/forums/viewforum.php?f=49(...) (mais bon apparement tu y en viens :) )
ou encore :
http://www.csharpfr.com/forum.v2.aspx(...)
Sinon, ben ici :)

Mailing-lists Mono :
http://www.go-mono.com/mailing-lists.html(...)

Autre mailing-lists plus générales et en ingliche :
http://discuss.develop.com/(...)

SInon pour ton problème de Reflection, comme dis au dessus, GetInterfaces est ton sauveur

C'est marrant sous Epiphany ça marche nickel (pourtant c'est aussi le moteur Gecko de Mozilla)
Leurs règles de filtrage sont vraiment bizzares :)

Eh oh c'était à titre purement informatif, si ça t'intéresse pas j'en suis désolé mais celà peut en intéresser certains.
Le premier lien permet d'avoir un retour utilisateur, et pourquoi pas des améliorations peuvent en découler (si si MS tient parfois compte de l'avis de ses clients) : c'est le même principe que les bugzillas, mais en moins "technique" justement.

Je ne vois pas en quoi ces problèmes d'interopérabilité sont du ressort des utilisateurs
Gni ?
Peut-être parcque c'est l'utilisateur qui est enmerdé ?
Je dis pas à l'utilisateur de trouver une solution, je lui propose juste de reporter le problème au bon endroit, au moins ca aurait peut-être un semblant d'utilité.

M'enfin à voir la notation de ton post et du mien, le tiens semble beaucoup moins inutile, donc je te remercie pour tes informations pertinentes qui vont aider à résoudre le problème.

C'est cool de nous dire ça, mais penses aussi à signaler tes problèmes par ici :
http://www.hotmail.msn.com/cgi-bin/support(...)

Et pour plus d'infos sur la stratégie "anti-spam" de MS (ou comment envoyer un mail à un compte hotmail) : http://advertising.msn.com/adproducts/Email_TechStd.asp(...)

Ben disons que FC3 intègre des versions plus récentes de DISKDRUID, de GRUB, etc.
Donc à priori il y a effectivement un peu plus de chance.
Après c'est aussi histoire que t'es un système à peu près jour, donc FC3 est de toute façon préférable.

Essai déjà avec la FC3 :)

Je pensais que tu parlais de projet commme Psyco.
Et c'est justement parcque sans Psyco (qui ne marche que sur x86) Python n'est pas du tout comparable avec .NET ou Java que je ne comprend pas du tout comme tu peux affirmer qu'il n'a rien à envier en terme de rapidité... En l'état actuel où Java et .NET utilisent un JIT, Python est plus lent (sans Psycho puisque Psycho n'est pas portable et dénature donc le langage)
Bon évidemment on pourrait parler de IronPython ;-)

Je vois pas du tout ce que tu essai de démontrer.
Les clients "savent" ne veut pas dire que les clients "ont la garantie" (ce qui dans le monde de l'informatique est de toute façon impossible)
Au contraire je trouve celà cohérent :
la licence dit clairement qu'ils ne garantissent pas qu'il n'y a aucun bug, et justement ils assument ces erreurs jusqu'au bout en proposant des patchs et upgrade.

L'irresponsabilité c'est affirmer que mon produit est certifié sans bug et de faire la sourde oreille quand on m'en montre 1.

On peut discuter pendant longtemps sur la qualité, sur la vitesse de correction des bugs, etc., mais je vois toujorus pas ce que tu essai de démontrer. Pourtant ton post semble intéressant. Faut que je relise.

Beagle tourne même sous Windows (merci Mono ;-p)