TImaniac a écrit 6423 commentaires

Oué j'ai hésité, mais bon j'ai eu la flemme :) Cela dit si j'ai rien à faire demain soir je m'y collerais.

Ah non, Novell fait parti du consortium de normalisation à l'ECMA et a son mot à dire.
Et les spécif de .NET (tout comme les brevets virtuels toujours pas validés) sont depuis le départ coécrites par HP, Intel et MS. Donc même en amont MS n'est pas seul à décider.

Vi enfin le travail ne doit être fait qu'une fois, ca reste automatique comme processus... Qt# est pas écris à la main de A à Z :)
Pour les slots :
"Connecting and disconnecting C++ signals and slots requires some additional C++ support code. The code is contained in libqtsharp. The mechanism used in libqtsharp is a bit cumbersome. However, at the time it was created, it seemed the only way to interact with signals and slots without hacking into the undocumented and possibly non-portable sections of Qt's Meta-Objects."

Est-il encore vivant ?
Oui
Qu'apporte t-il face à Mono (et inversement) ?
Y'en a un qui a le logo GNU (et tout ce que cela implique) et l'autre qui a le logo Novell (et donc le support commercial et marketing qui va avec).
C'est aussi une différence de licences : dotGNU c'est à peu prêt tout en GPL, Mono c'est un mix GPL/LGPL/MIT.
Les différences entre les 2 projets vues par dotGNU :
http://wiki2.dotgnu.info/DotGnuVsMono
Il y a eu au départ des tentatives de mise en commun d'une partie du travail, mais il n'y a plus vraiment de coopération.

Autre chose : est-il envisageable / prévu de concevoir un frontend à GCC (CLR->RTL) un peu comme gcj ?
Pas beaucoup d'intérêt, Mono sais déjà le faire puisqu'ils ont depuis longtemps (avant GCJ) la possibilité de compiler en natif :
mono --aot monappli.exe
L'inverse par contre est en cours (summer of code Google), à savoir un backend pour gcc :
http://mono-project.com/Summer2005#GCC_CIL

Qt#
http://qtcsharp.sourceforge.net/
Par contre ca n'a pas été mis à jour depuis 2002, visiblement ca n'intéresse pas grand monde.

F-Spot
http://www.gnome.org/projects/f-spot/

J''avais prévenu que y'avait du discrous marketing là dedans :)

Et puis bon ... mono sur mon iMac G3 350Mhz, ça passera jamais (pas plus que java) ...
Essai toujours, ca tourne bien sur un processeur ARM à 220 Mhz (Nokia 770) :)

Quoi t'as osé faire une modif dans un wiki ??? Ralalala :) Merci quand même ;)

Merci ! Corrigées.

Pour moi avoir 15000 distributions LInux par rapport au marché qu'elles occupent, constitue en soit un bordel monstre quand on compare à MS Windows ou Mac OSX. Le nombre d'incompatibilités entre ces distributions est un autre exemple de bordel monstre.

« on notera en particulier le nombre intact d?employés travaillant sur Hula, un projet de serveur mail, et des coupes « minimales » sur Mono, une implémentation libre et open source de l?environnement .Net de Microsoft. »
Moi je comprends ca comme : la plupart des secteurs de l'entreprise sont touchés, sauf le projet Hula et le projet Mono, le premier n'étant pas du tout touché, et le 2ème que très légèrement impacté.
Donc l'ex-Ximian ne morfle pas du tout. Ce qui aurait été assez idiot vis-à-vis de la décision de se recentrer sur Linux. C'est plutôt Netware qui morfle dans l'histoire, ce qui est beaucoup plus cohérent avec le recentrage.

"Novell is not pulling the plug on the desktop. We feel we lead it today, and we look forward to the next generation of the desktop. The desktop is in the core set of Novell open enterprise stack of data center, workgroup and desktop, identify and resource management."
"As for the other open-source projects, Mancusi-Ungaro said, "I don't know of any Hula [an open-source e-mail server project] cuts. There have been minimal cuts in Mono [an open-source implementation of Microsoft's .Net], and none of those cuts were in developers."

Source eWeek.com

En fait je viens de faire un constat rigolo :
- une grosse équipe soudée, professionnelle, organisée accouche généralement d'un ou plusieurs softs cohérents et intégrés.
- une communauté de joyeux lurons éparpillés et aux compétences hétéroclytes accouche de softs rigolo qui marche mais sans aucune cohérence globale.
C'est du mapping Relationnel/Objet en fin de compte ! :D

Le charme de Linux et des logiciels libres c'est son bordel ambiant et le résultat tout aussi bordélique et du coup passionnant à explorer pour peut qu'on en ai l'envie et non pas seulement le besoin. Peut être que pour être un geek il suffit d'être un aventurier-explorateur au fond.

Ben vas-y toi, sors ton matos et numérise la British Library !
Evidemment qu'on aimerait tous qu'une initiative "communautaire" s'en occupe, mais avec quels moyens ? Avec nos impôts ? Combien seront d'accord de dépenser les millions nécessaires ?
Cela n'enlèvera strictement rien à la nature de ces oeuvres, elles existeront toujours sous leur forme actuelle, la seule différence c'est qu'on aura un moyen d'accès supplémentaire.
De plus il faut quand même noter que contrairement à Google, Microsoft compte numériser au "cas par cas", avec l'accord des éditeurs, bref plus en tant que partenaire que concurrent.

Les imports ca sert juste à t'éviter de taper le nom complet d'une classe dans ton code. Des imports inutilisés ne vont strictement rien changer sur les perfs de ton appli, tout au plus vas-tu voir quelques micro-secondes de compilation supplémentaire (ouachement vital)...
Nan en fait le seul problème éventuel que tu peux rencontrer, c'est des conflits de noms entre des classes qui ont le même nom "court" mais pas le même nom long, un import inutile pourrait mettre en évidence un conflit dans le genre, mais ca reste assez rare... bien que possible sinon on aurait pas inventé les packages (espaces de nom) :)
Bref, laisse Eclipse faire mumuse avec les imports et pense à autre chose de plus intéressant ;)

En fait y'a qu'un seul GAC, je me suis mal exprimé. Le GAC peut cependant contenir plusieurs versions d'un même assembly. Tu veux pas montrer le code que t'utilises ? Parcque chezmoicamarche comme qui dirait :-)

Remplacer NUnit par log4net bien sûr :)
En fait log4net est compilée explicitement avec System.Data 1.0.5.
Ta bibliothèque est compilée explicitement avec System.Data 2.0
Forcement y'a un conflit :)

Un truc qui a l'air de marcher, utilise le compilateur gmcs plutôt que mcs. Celui-ci est prévu pour ne marcher qu'avec le profile 2.0, et il fait donc un mapping des versions forcé. Enfin je viens de tester et ca semble marcher.

Le problème c'est que NUnit dépend explicitement de System.Data.1.0.5. Hors ton programme utilise lui System.Data.2.0. Pour mono ce ne sont pas les même bibliothèque, il y a naturellement un conflit entre les 2.

Je vois 2 solutions : log4net est peut être enregistré dans le gac 2.0, essai de le référencer directement. Sinon télécharge log4net, et enregistre le dans le GAC 2.0 avec gacutil.
S'il insiste toujours, tu peux toujours essayer de recompiler log4net en lui explicitant d'utiliser System.Data 2.0.

Bon courage :)

Un peu de pub au passage :
http://monofrance.free.fr

Le pire c'est qu'il y en a qui sont conscient que les 2 mots ne s'écrivent pas pareil, mais ils ne font aucune différence à leur prononciation...

Le libre pourrait éduquer les gens. Si Microsoft étends Excel à 131072 lignes dans le futur. Excel sera il plus puissant? Non, car c'est inutile! Pure Marketing!
Oué enfin aux dernières nouvelles c'est OOo qui a été tout fier d'annoncer qu'ils supportaient ~32000 lignes ;)

Le seul intérêt du tableur pour cette usage est l'interface pour la saisie des chiffres
La saisie des formules et leur application aux cellules est également relativement intuitif. L'enregistrement de macro l'est également.

Les gens demandent n'importe quoi par manque de compétence.
Comment peux tu affirmer que les besoins des gens sont "nimporte quoi" ?
Les gens veulent une interface "visuelle" et "intuitive", ce ne sont pas des programmeurs. Excel & Co répondent en partie à ces types de besoins. Y'a pas de solution unique pour tous les besoins, mais une solution adaptée à chaque situation.

Maintenance ? Où ca ?
Ici : windowsupdate.microsoft.com

y'a pas de garantie non plus (j'invente rien, tout est dans le CLUF
Bent t'as pas dû lire le CLUF. Il y a des engagements de support. (Pas de garantie au sens "garanti sans bug", mais tu en conviendras que personne ne peut garantir cela en matière de logiciel)

On parlait au-dessus de produits OEM, et dans ce cas M$ n'assure aucune maintenance
Ton commentaire semble être pertinent, et pourtant visiblement tu dis n'importe quoi :)

En ce qui concerne le développement et le coût de maintenance de la version bridée, je ne pense pas qu'ils s'embêtent à faire une base de code différente (en tout cas c'est ce que je ferais).
Discours pourtant mainte fois rabaché. Bien sûr que non qu'ils ne recodent pas une version spéciale pour la version "Light".
Mais Microsoft ne vend pas un produit, mais un produit AVEC des services : il n'est pas normal que madame Michou qui a juste besoin d'aller sur internet paie pour le support et la maintenance d'un windows server qui a beaucoup plus de fonctionnalités, il faut donc faire des prix différents en fonction des produits, à cause des services associés. Donc même si cela n'a pas un coût différent au développement, il est normal qu'un Windows avec moins de fonctionnalités coûte moins cher, tout simplement parcqu'il y a moins (et il y a besoin de moins) de services.

Plus on s'approche de la fin de la phrase, plus c'est pertinent ;-)
Mouais je comprends mieux pourquoi ton post a été pertinenté ;)

Le nouveau format de MS est surtout destiné à uniformisé le rendu graphique sous Windows, notamment à destination des imprimantes, il ne vise pas à créer un format de document portable et multimédia.
Le format de MS correspondrait plutôt au PostScript.
C'est tellement pas concurrent que MS va intégrer l'export PDF dans sa suite Office.

Ca résoud le problème de l'installe mais pas de la maintenance des packages. Si je prends un machin comme ca, et que j'essai de l'installer dans 4 ans il se passera quoi ?

Faut quand même payer le développement, la documentation utilisateur, le conditionnement, la distribution et la marge.

D'accord, mais tu ne crois pas que cela coûte le même prix à Microsoft de fournir un Windows "complet" en OEM qu'un Windows bridé ?
Pas du tout. Microsoft vend une licence avec des services associés. Dans les services il y a la maintenance. Et plus t'as de fonctionnalités, plus t'as de maintenance à faire. Il est donc logique qu'une version avec moins de fonctionnalités coûte moins cher à maintenir et que la licence coûte moins cher.
L'absence de support technique en ligne va dans le même sens. A l'arrivée cette version bridée coûte effectivement moins cher à Microsoft.

On a beau dire ce qu'on veut mais ca doit être plus facile à administrer ce genre de parc ;)