Sortie de Mono 1.0 beta 1

Posté par  . Modéré par Nÿco.
Étiquettes :
0
7
mai
2004
Communauté
La première des deux versions béta prévues de Mono 1.0 vient d'être publiée. Mono est une implémentation libre de .Net soutenue par Novell qui fonctionne sous GNU/Linux, *BSD, Solaris, MacOS X et Windows.

Mono propose deux "piles" d'APIs :
- une pile d'APIs compatible avec Microsoft .Net Framework 1.1
- une pile d'APIs Mono.

NdM : FAQ Question 129 : Le compilateur C# est sous GPL. Les bibliothèques de runtime sont sous LGPL. Les bibliothèques de classes sont sous MIT X11. Le runtime Mono et le compilateur C# sont également disponibles sous une licence propriétaire pour ceux qui ne peuvent utiliser du code GPL et LGPL.

Merci à gradix et _matt_ pour avoir également proposé la brêve. Mono 1.0 beta 1 propose :
- un environnement d'exécution (que l'on peut même embarquer dans d'autres applications C/C++) compatible avec la norme ECMA-CLI
- une intégration Java à l'aide de IKVM
- compilation Just-in-Time et Ahead-of-Time
- support des plate-formes StrongARM et HPPA
- un compilateur C# 1.0 (mcs).

La pile d'APIs compatible avec le Microsoft .Net Framework 1.1 permet d'utiliser entre autres ASP.NET (Web Forms et Web Services), ADO.NET (connectivité avec les bases de données) ainsi que l'exécution d'objets distribués (de manière "binaire" façon Java/RMI ou à l'aide de SOAP). Une application .Net n'utilisant pas les APIs spécifiques à Windows a de grandes chances d'être utilisable avec Mono.

La pile d'APIs Mono propose :
- Gtk# + intégration avec Gnome
- ponts vers PostgreSQL, MySQL, DB2, Sybase, Sqlite, Oracle
- intégration LDAP
- crypto
- intégration en tant que module Apache
- intégration avec Cairo.

L'emploi de JScript et VB.NET n'est visiblement pas encore recommandé. Les APIs System.Windows.Forms ne sont disponibles qu'en version alpha, il reste encore beaucoup de travail sur ce plan.

À l'heure où SUN fait la sourde oreille pour placer Java sous une licence plus acceptable, Mono commence à apparaître comme un challenger intéressant pour le développeur de logiciel libre et/ou open source. .Net est un framework élégant et Mono permet de l'employer sur plusieurs plate-formes. Ceci dit il faut tenir compte des bémols suivants :
- Mono n'est pas aussi complet que l'implémentation Microsoft
- la documentation n'est pas complète
- on peut craindre que le fait que Mono implémente les mêmes APIs que Microsoft soit une épée de Damoclès ...

Le meilleur moyen de se faire une idée est de l'essayer :-)

Aller plus loin

  • # Mono SUCKS

    Posté par  . Évalué à -10.

    Mono SUCKS
    MDI est un Gros Con

    • [^] # Re: Mono SUCKS

      Posté par  (site web personnel) . Évalué à 2.

      Moi au contraire, je pense que mono est une très bonne chose, et sera une pièce maitresse à l'avenir.

      Je pense personnellement que MDI a une bonne vision des choses. Il a art de faire les bons choix.

      • [^] # Re: Mono SUCKS

        Posté par  . Évalué à 10.

        Je pense que c'est un gars qui est d'une énergie et d'un dynamise qui forcent l'admiration. Il a été à l'origine du portage de Linux sur Silicon graphics, à l'origine de Gnome, et maintenant de mono. C'est aussi quelqu'un qui n'hésite pas à experimer ses opinions même si elles ne sont pas politiquement correctes, il a le courage de déplaire en experimant des opinions à contre courant, et ce sont ces gens la qui font évoluer les choses.

        "Il y a des gens qui s'adaptent et des gens qui adaptent" nous dit-on !! quand MDI a lancé le projet mono il y a une vague d'indignation sans précédent sur Slashdot, c'était un scandale sans nom, un crime de lèse majesté, il continué son bonhomme de chemin et voila les premiers résultats concrets.

        Il fallait une réponse à Microsoft pour son initiative .NET ne pas le faire en en prenant des position dogmatiques de "pureté du code" ou de fanatisme Stallmanien aurait été une erreur grossière.

        MDI est également à l'origine de la réponse en préparation à XAML/Avalon, (voir son blog et les posts sur Slahdots) et la aussi les motivations sont les mêmes, ne jamais laisser une initiative de Microsoft sans réponse, sinon, très rapidement il sera trop tard.

        • [^] # Re: Mono SUCKS

          Posté par  . Évalué à -10.

          XUL est une formidable réponse à XAML/Avalon, et MDI n'a rien à voir avec XUL.D'ailleurs MDI n'a jamais rien à voir avec des choses vraiment bien...son parcours est une suite d'erreurs sans cesses renouvelées, un fait c'est même pas un con c'est juste un gros naze.

        • [^] # Re: Mono SUCKS

          Posté par  . Évalué à 4.

          Et encore un beau troll tout poilu ;-)

          Bon aller, je vais essayer de répondre à qqe points en expliquant clairement et calmement certaines choses.

          En premier, un ancien post que j'ai fait pour rappeler certaines base nécessaire afin d'éviter les trolls autour de Java, merci d'y jeter un oeil ;-)

          http://linuxfr.org/comments/406097,1.html(...)

          >Une application .Net n'utilisant pas les APIs spécifiques à Windows a de grandes chances d'être utilisable avec Mono.

          C'est quoi l'estimation de la probabilité d'un "grande chance" ? Il est ou le test résultat des tests de compatibilité avec .net ? Tant que MS ne livrera l'intégralité de ses specs, et des tests de compatibilités (à la mode du TCK de Java). Personne ne peut parier sur le caractère hypothétique d'une solution !

          En clair, Mono n'est pas compatible .net ! Et l'inverse n'est pas vrai non-plus. Mono est simplement un sous ensemble non-précisé de .net sur lequel une iterroperabilité a été envisagée. Sur cet ensemble se pose le problème de l'évolution dans le temps (améliorations du périmètre et régressions fonctionnelles). Ainsi que les effets de bords dus au changement d'une spec sur laquelle Mono n'a aucun regard (ni contrôle, ni vérification, ni vision claire).

          > À l'heure où SUN fait la sourde oreille pour placer Java sous une licence plus acceptable, Mono commence à apparaître comme un challenger intéressant pour le développeur de logiciel libre et/ou open source.

          "une license plus acceptable", si ça c'est pas du FUD ;-)
          Je te propose de relire ce qui a été expliqué sur Java sur le lien ci-dessus. Pour rappel, oui on peut faire une version Opensource de Java et la FSF y travaille le projet s'appelle Classpath ! Et Non, pour l'instant la versions de Sun à savoir la RI du J2SE, n'est pas opensource même si les sources sont publiquement disponible (sous licence JSPA/RI ou JCSL si ma mémoire est bonne).

          Quand à Mono, "challenger" de Java, cela ferait même sourire à Redmont. Car même , si Mono arrive à avoir un jour le dixième de projet opensource de référencé sur sourceforge ou sur Apache dont Java dispose. Se posera toujours le problème du suivit des évolutions de Mono par rapport à son « modèlée ». Il illusoire de penser écrire qqch de compatible avec un spécification mouvante et non définie publiquement. Tout comme il est illusoire de penser que MS laissera Mono arriver à un niveau de compatililité tel qu'il mettrait en danger l'interdépendance entre .net et windows ;-)

          De plus Sun a prouver (sans le vouloir) qu'assurer la portabilité inter-plateforme du binaire est quelque chose de très délicat qui nécessite une spécification fine et complète de l'ensemble de la plateforme virtuelle. Ou sont les specs de .net ? Pour rappel, mise à par les quelques pourcentage (CLI/CLS/langage...) que MS a bien daigné donné à ECMA pour s'assurer un alibi d'ouverture, l'ensemble des API restent propriétaires et contrôlés intégralement par MS.
          A l’opposé coté Java chaque Spec est contrôlée par un groupe de surveillance multilatéral (éditeurs commerciaux, organisations à but non lucratifs, groupes d’utilisateurs, …). Et même si sur les specs les plus important de Java Sun reste le chef d’ochestre, une fois le TCK publié il ne peuvent plus exercer aucun contrôle sur les implémentations effectuées. Car seul le TCK est juge de la bonne implementation d'une API. Ici on ne dépend pas du bon vouloir d’un tiers certificateur ;-)

          Pour rappel la plateforme Java, tout est entierement disponible et sans contrapartie du moment que tu es une organisation à but non-lucratif.

          > .Net est un framework élégant et Mono permet de l'employer sur plusieurs plate-formes.

          Non, c'est faux ! Mono permet de faire fonctioner certain programmes .net particulièrement conçus pour fonctioner sous Mono. Car la portabilité complète n'etant pas assurée, on ne peut présager de la portabilité à posteriori.

          >- Mono n'est pas aussi complet que l'implémentation Microsoft

          CQFD ;-) Mais j'aurait dit "Mono n'implemente pas entièrement .net".
          Certains morceaux "facheux" genre COM+ ont été oubliés ;-)
          Adieu donc les plateformes à haute dispobilités pourtant incontournables dans du developpement coté serveur.

          >- on peut craindre que le fait que Mono implémente les mêmes APIs que Microsoft soit une épée de Damoclès ...

          Ce que l'on peut surtout craindre, c'est que les developpeurs du monde libre attirés par les lumières se retrouvent piégés par VS.net ;-)
          Car il faut être clair, aucun outil adapté à .net "n'existe" en dehors des outils de MS (on mettra entre parenthèse les outils de borland, dont la strategie .net et leur implication sur le long terme dans cette plateforme n'est pas encore bien établie).

          Partir sur Mono c'est avant tout faire une fleur à MS en favorisant une technologie entièrement controlée et dirigée par MS.

          Enfin, quelques points divers évoqués dans les fils:

          - La performance, la différence entre les perfs d'exécution d'une JVM et de la VM .net (celle disponible sur WindowsXX) sont négligeable. Sur windows, la VM de MS prend l'avantage car elle effectuée des préchargement et des optimisations au lancement (optimisations dont certaines ont été remarquées par le securityfocus et indiquées comme faille potentielle de l'architecture de sécurité). Mais sur ce point les dernieres JVM comblent plus que largement la différence. On attend avec impatience que MS autorise ses partenaires .net à publier des vrais comparatifs Java/.net sans contrôle préalable par MS des résultats et conclusions ;-)

          - Les fonctionnalités : ont peu sans choquer personne dire que Java et .net sont à peu prés au même niveau et se suivent de très près. La force de .net tient dans le rouleau compresseur MS, qui est capable d'écraser tout rival commercial devant lui en utilisant un compte en banque illimité. Pourtant la force de Java est dans sa communauté opensource riche et dynamique qui invente constamment de nouveaux concepts et relance en permanence le débat sur la pertinence de tel ou tel élément.

          Pour finir, je dirais simplement que l'innovation ce n'est pas se contenter de copier ce que fais le voisin même si il le fait bien. Où est l'innovation dans Mono ? Quelle est son utilité face à un éditeur qui peut à tout moment changer la donne ? On peut regretter de voir tant d'heures de perdu, pour un projet dont la viabilité ne peut être assurée à long terme. Alors qu'a l'opposé un projet comme Classpath à besoin de beaucoup de ressources pour fournir lui une implémentation GPL intégrale d'une plateforme complètement définie et qui assurerait une réelle suprématie aux logiciels libres.

          Ainsi, il y a des fois ou je regrette les choix purement politiques de certains car je pense qu'il manque d'ambition et de perspective pour le libre. Et je ne peux que m'interroger sur les réelles raisons qui poussent ses choix d’autres ...

          http://www.theregister.co.uk/2002/02/05/explain_yourself_miguel_dem(...)

          :-)

          • [^] # Re: Mono SUCKS

            Posté par  (site web personnel) . Évalué à 4.

            Tu pouvais pas résumer ? nan j'déconne :-) Mais ce qui est marrant, c'est que tu ne dis rien de nouveau, tous les points que tu cites ont été débattus plus bas... je vais donc tenter de te résumer les "contre-arguments".

            Tout d'abord un intérêt de Mono que tu sembles oubliés : c'est une alternative à Java (je serais tenté de dire la seule qui vise les même objectifs), et rien que pour celà son existence est justifiée.

            Ensuite tu rabaches que Mono est et restera une pâle copie de .NET sans intérêt basé sur des spécifications mouvantes...

            Mono a 3 buts :
            - proposer une implémentation complète des spécifications de l'ECMA.
            - proposer un ensemble d'API destiné à la programmation sous Linux (GTK# & Co)
            - proposer une compatibilité avec le framework .NET

            Evidemment ce dernier point ne pourra jamais être parfait, mais l'ignorer, c'est ignorer le nombre important d'application ou de développeurs qui pourraient "migrer" (genre 300 serveurs à Munich).

            Car il faut être clair, aucun outil adapté à .net "n'existe" en dehors des outils de MS (on mettra entre parenthèse les outils de borland, dont la strategie .net et leur implication sur le long terme dans cette plateforme n'est pas encore bien établie).
            Eh eh eh... Donc déjà on met de côté Borland qui est pourtant une solution complète... Tu semble indiquer qu'il n'y a quasiment rien pour développer avec .NET à part VS... Et ? Il commence a fleurir un peu partout de nombreux outils, libre ou non, pour exploiter cet environnement, s'il n'y a pas de solution complète (à part si on enlève celles qui existent), c'est aussi dû à la relative jeunesse de .NET... On a mis combien de temps avant d'avoir un environnement potable pour Java ?

            Partir sur Mono c'est avant tout faire une fleur à MS en favorisant une technologie entièrement controlée et dirigée par MS
            .NET n'est présent que dans la compatibilité, sinon c'est juste le respect d'un standard établi, défini à l'ECMA par un consortium, et Mono a même fait des propositions pour des nouvelles spécifications... On peut dire que celà évolue en tout cas beaucoup plus vite que chez Sun...

            La performance, la différence entre les perfs d'exécution d'une JVM et de la VM .net (celle disponible sur WindowsXX) sont négligeable. Sur windows, la VM de MS prend l'avantage
            Si je te suis sous WindowsXX les perfs sont identiques mais celle de MS a quand même l'avantage... plutôt que d'aller chercher dans des considérations techniques hasardeuse, regarde plutôt comment les plateformes sont conçus : y'en a une qui a été conçu pour exécuter du code optimisé pour être interprété, et l'exécution commencera toujours par une interprétation; l'autre solution est conçu pour exécuter du code non interprété, il n'y a donc pas de bidouille pour essayer de déterminer la partie du code qu'il faut compiler en natif comme c'est le cas des JVM recentes... Et puis là le débat c'est linux, alors il faut plutôt comparer une JVM sous nux et Mono, je suis curieux de voir les premiers benchs (qui seront de toute façon des nids à troll comme tout bench qui se respecte)...

            Pour finir, je dirais simplement que l'innovation ce n'est pas se contenter de copier ce que fais le voisin même si il le fait bien.
            A défaut de pouvoir innover (parcque pas tout le monde peut se payer 10000 ingénieurs spécialisés R&D), il faut respecter les standards. Les développeurs ont besoins d'une alternative à Java, qui en comble certaines lacunes (notamment sur les langages, la gestion des versions), et qui de plus respecte les standards : c'est tout ce que fait Mono. le standard de l'ECMA est amené à être améliorer, comme c'est le cas par exemple pour les generics (si on prend la plateforme Sun ils ont choisi de faire des templates et de ne rien faire évoluer du tout)... On peut par exemple penser à des améliorations pour des langages comme OCaml ou encore pour les langages interprétés... En tout cas je trouve qu'il y a beaucoup plus d'avenir sur le long termes aux standards ouverts qu'aux standards de Sun...

            Quelle est son utilité face à un éditeur qui peut à tout moment changer la donne ?
            De toute façon les spécif sont ouvertes, ils ne peuvent changer la base sans prévenir, et sinon tant pis celà fait une plateforme performante... Et puis si tu prend le modèle de Windows : la plupart des problèmes de sécurité et stabilité viennent de la compatiblité avec les anciennes versions des programmes...Et pourtant ils assurent la compatibilité (évidemment certaines parties finissent par ne plus l'être) Sachant que Microsoft développe son prochain OS autour de .NET, il paraît clair que leur objectif ne sera pas de casser les normes existante en empêchant une compatibilité avec Mono... Sinon ils vont casser la compatibilité avec eux même... Et puis il faut aussi voir qu'il y a une demande de plus en plus forte de compatilibté entre Linux et Windows pour les applications, je crois surtout que Microsoft a voulu proposer une solution à ses clients pour répondre à leurs attentes (pour concurrencer Sun par exemple), et Mono est pour eux la preuve du bon fonctionnement de leur stratégie, c'est un atout supplémentaire, bref, aucune raison de casser la compatibilité.

            Alors qu'a l'opposé un projet comme Classpath à besoin de beaucoup de ressources pour fournir lui une implémentation GPL intégrale d'une plateforme complètement définie et qui assurerait une réelle suprématie aux logiciels libres.
            Alors là je comprend pas, tu dis de ne pas suivre Microsoft parcque il faut innover et toi tu proposes de copier la solution de Java...
            Ta phrase suivante me fait encore plus rire... C'est vrai que le projet CLassPath a plus d'ambition que le projet Mono... Ah bon en quoi ? Sachant que Mono a quand même l'ambition de proposer une plateforme complète qui s'intègre à Gnome, que propose ClassPath de plus ?

            Un point où on est d'accord : la portabilité. Evidemment c'est illusoire, à moins de concevoir une application dans cette perspective... Mais justement, tout ce qui est défini à l'ECMA, c'est l'équivalent du J2RE de Sun sans la partie liée aux interface graphiques, bref, il manque ce qui n'est pas portable, on ne va pas s'en plaindre. Celà forcera peut être certains développeurs à concevoir une interface différente pour chaque environnement, et d'en exploiter les possibilités spécifiques plutôt que d'utiliser un toolkit à la Java qui ne s'intègre nul part et auquel il manque beaucoup de fonctionnalités... Sinon ce sera toujours la même chose, quelque soit l'environnement : les applications seront dépendantes des API qu'elles utilisent, et seront supportés sur les plateformes où ces API sont implémentés...

            Certains morceaux "facheux" genre COM+ ont été oubliés ;-)
            Tu sais ce que c'est com+ ? Sous Windows il y a effectivement une certaine compatilibité avec com+, parcqu'il y a l'existant. Sous Linux aucun intérêt d'être implémenté.

            PS : allez, n'oublies pas que Microsoft a fait parti du consortium qui a normalisé le XML et ses dérivés (schémas & Co), je te déconseille donc d'utiliser ces technos qui sont des standards sans avenirs, que Microsoft peut changer à tout moment...

            • [^] # Re: Mono SUCKS

              Posté par  . Évalué à 2.

              PS : allez, n'oublies pas que Microsoft a fait parti du consortium qui a normalisé le XML et ses dérivés (schémas & Co), je te déconseille donc d'utiliser ces technos qui sont des standards sans avenirs, que Microsoft peut changer à tout moment...

              Rajoutons CORBA et XML-RPC aussi :D

              Sur le plan de l'innovation je conseillerait à l'auteur de ne plus jamais utiliser Linux, c'est vrai quoi ils ont copiés un truc qui s'apelle UNIX et qui était même pas totalement normalisé !
              Et en plus au lieu de participer à l'avancée de la techno OpenSource en place (BSD) ils en ont crée une nouvelle pour des raisons personnelles et juridiques... Mince alors l'histoire se répèterait'elle.

              • [^] # Re: Mono SUCKS

                Posté par  . Évalué à 1.

                Oups SOAP pas CORBA...

                Mauvais cerveau, Changer de cerveau...

    • [^] # Re: Mono SUCKS

      Posté par  . Évalué à 10.

      Le choix de porter les technologies .NET exposait assurément à la critique.
      Cependant, lorsqu'on se penche objectivement sur les intérêts de cette technologie, et sur le boulot fait par l'équipe de Mono, on découvre une plateforme de développement multi environnements, une VM performante, bien plus que la JVM sous linux sans AUCUN désir de troll. Le C# est un langage propre, puissant et clair, c'est un fait, peu importe de savoir s'il a été trop recopié sur java et c++. Les WebControls et Webforms permettent enfin un développement web soigné de manière simple (je n'ai pas dit que ça n'existait pas avant). On a à l'heure actuelleune alternative extrêmement crédible à Java qui apporte beaucoup de fonctionnalités en natif,et en libre... Après celà, chacun jugera évidemment, à juste titre, opportun de se méfier de certaines API qui de toutes façon n'ont rien d'irremplaçable.

      ma vie:
      J'aime Java mais j'avoue craquer pour .NET depuis que j'ai découvert Mono.
      Félicitations à Miguel de Icaza et tous les membres du projet, avec aussi une mention à Monodevelop.

      • [^] # Re: Mono SUCKS

        Posté par  . Évalué à 8.

        moi je trouve que vouloir faire "comme" le proprio, en implémentant les technologies propriétaires, c'est se être condamné à avoir 2 ans de retard,suivre signifie ne jamais rattraper.

        • [^] # Re: Mono SUCKS

          Posté par  . Évalué à 6.

          Oui, ils implémentent des trucs proprios, c'est leur choix. Ca permet d'assurer une compatibilité. Ceci dit, c'est vrai que c'est un combat discutable de vouloir imiter et rattraper le maître, mais rien n'oblige à utiliser tout ce qui est propriétaire. Mono implémente ses propres APIS, propose GTK#, plein d'autres choses originales pour linux et pour tous ; on peut citer la jvm IKVM etc...
          Moi je suis maintenant motivé pour le dev sous linux, mais hors de question que je touche une Windows Form, una authentification Passport etc... Par contre, jeserais curieux de voir ce que donne Qt#.. Quelqu'un a t il une expérience à raconter?

          • [^] # Re: Mono SUCKS

            Posté par  (site web personnel) . Évalué à 1.

            ca marche bien.
            très bien.
            la place de gtk dans mono n'est du qu'a la personnalité des developpeurs.

            • [^] # Re: Mono SUCKS

              Posté par  . Évalué à 2.

              Ah, tu tombes bien, tu vas peut être pouvoir me renseigner : d'après ce que j'ai pu comprendre, la solution officiellement supportée par Kde serait un système de Bindings QT par KaXul, laissant Qt# de côté. Quel est l'avancement du projet, qui m'a l'air dater du 1er Avril? Je n'ai rien trouvé sur le site kde. Est ce déjà utilisable? As tu une doc/ des exemples sous le coude?
              Merci si tu peux éventuellement me fournir des pistes.

              • [^] # Re: Mono SUCKS

                Posté par  . Évalué à 1.

                Euh... je ne suis au courant de rien, mais la date ne me met pas en confiance: ce serait pas une blague?

                • [^] # Re: Mono SUCKS

                  Posté par  . Évalué à 2.

                  Certains ont aussi soutenu que c'en était une sur kde.org, mais il y a eu des confirmations par la suite. Seulement depuis, plus aucune news...
                  Pour info, et si j'ai bien capté, le projet KaXUL + Qt se nomme Kimono.
                  Je reste preneur de toute info à ce sujet.

                  • [^] # Re: Mono SUCKS

                    Posté par  (site web personnel) . Évalué à 5.

                    Quelques precisions:
                    - le binding historique de Qt en C# est mort car trop complique a maintenir.
                    - le nouveau projet de C# pour Qt/KDE s'appelle en effet kimono et genere automatiquement des bindings pour C# en utilisant le meme moteur que le generateur de binding pour perl, java et objective C. Tout ca est automatise grace au genie une fois de plus de David Faure.
                    - kaxul est un plugin konqueror qui premet de faire tourner/afficher des applets XUL
                    - a ma connaissance, il n'y a _aucun_ rapport entre XUL et C#, si ce n'est le battage mediatique qu'on fait autour
                    - il y a encore moins de rapport entre kaxul et kimono qu'entre XUL et C#
                    - kaxul est un kpart donc accessible a toute applications KDE
                    - dans la mesure ou C# est un binding pour KDE, il peut utilise kaxul comme toute appli KDE

                    Les deux derniers points montrent qu'il est possible d'ecrire une appli en C# avec une interface en XUL. Ca fera surement plaisir aux combattants du XAML.

                    • [^] # Re: Mono SUCKS

                      Posté par  . Évalué à 0.

                      des liens, des liens, des liens !!!

                    • [^] # Re: Mono SUCKS

                      Posté par  . Évalué à 2.

                      Les deux derniers points montrent qu'il est possible d'ecrire une appli en C# avec une interface en XUL. Ca fera surement plaisir aux combattants du XAML.
                      Une maniere plus elegante de proceder sera d'utiliser directement les bindings XUL pour le CLI.

                      • [^] # Re: Mono SUCKS

                        Posté par  (site web personnel) . Évalué à 0.

                        mmmh, un binding des API de mozilla tout court serait encore plus clean... et après on applique le même principe que XAML aux API de Mono et le tour est joué... sans limiter la syntaxe XML à Mozilla (pour les API de GTK, pour ceux de Qt, etc.) .

                    • [^] # Re: Mono SUCKS

                      Posté par  . Évalué à 3.

                      Donc, si j'ai bien compris, kimono n'est_pas_basé sur Kaxul.
                      Merci beaucoup pour tous ces éclaircissements.

                      Donc, étant donné que tu sembles avoir trouvé plus d'infos que moi, sais tu si Kimono est déjà quelque chose d'utilisable( enfin je veux dire au moins pour tester)? Une url sous la main peut être?

                      Quant aux combattants du XAML, ils devraient se rendre compte que si on n'offre pas une couche de compatibilité, on pourra se passer de la moitié des sites Internet d'ici 5 ans, cause standards de faits/de force.
                      Je vote pour la compatibilité XAML, du moins en affichage, je ne parle pas des éventuels ajouts genre ActiveX. Ou alors je voterais bien pour un gigantesque procès du style on relance l'histoire d'IE intégré à Win$.

                      • [^] # Re: Mono SUCKS

                        Posté par  . Évalué à 0.

                        >Ou alors je voterais bien pour un gigantesque procès du style on relance l'histoire d'IE intégré à Win$.

                        T'iras pas tres loin, MS n'a pas ete reconnu coupable d'avoir tue Netscape en integrant IE a Windows, il a ete reconnu coupable pour d'autres raisons.

                        • [^] # Re: Mono SUCKS

                          Posté par  . Évalué à 2.

                          De toute façon je préfère à titre personnel laisser MS tranquille, du moins tant qu'ils ne bloquent rien pour permettre un Mono suffisamment évolué, cad pour moi tant qu'on peut garder ADO.NET, asp.NET(ou au moins les WebControls) et SOAP, et qu'ils permettent l'interopérabilité de XAML sur d'autres plateformes. Après ça je t'avoue que sur les points juridiques de l'interopérabilité et du reverse ingineering je n'y connais pas grand chose.
                          Ma "tirade" ne se voulait pas être de l'anti microsoft primaire.
                          Au fait, que fais tu (en gros) comme genre de taf chez eux?

                          • [^] # Re: Mono SUCKS

                            Posté par  . Évalué à 1.

                            Ma "tirade" ne se voulait pas être de l'anti microsoft primaire.

                            Je sais, t'en fais pas :+)

                            Au fait, que fais tu (en gros) comme genre de taf chez eux?

                            Service packs pour Windows, partie reseau

                            • [^] # Re: Mono SUCKS

                              Posté par  . Évalué à 1.

                              Service packs pour Windows, partie reseau

                              LE truc qui évolue avec le SP2 quoi :D

                        • [^] # Re: Mono SUCKS

                          Posté par  . Évalué à 2.

                          Oui pour abus de position dominante je crois.

                          Tuer un concurent n'est pas interdit, le faire en utilisant une position de monopole, si !

                      • [^] # Re: Mono SUCKS

                        Posté par  (site web personnel) . Évalué à 3.

                        Desole, je ne retrouve plus les liens correspondants et j'ai fait quelques amalgames. Je ne comprenais pas d'ou tu sortais ton kaxul + mono mais maintenant, j'ai compris:

                        http://dot.kde.org/1080785038/(...)

                        C'etait un poisson d'avril.

                        Le reste est cependant vrai, a savoir que kaxul est un vrai projet qui marche et que des bindings C# sont en route et seront generes automatiquement.

                        Pour mes sources d'information, c'est juste dot.kde.org, les kde cvs traffic et les resume de mailing listes. Tres interessant a mon avis, meme si on ne s'interesse pas a KDE. Je trouve ca toujours passionnant de voir les hackers discuter technique.

        • [^] # Re: Mono SUCKS

          Posté par  . Évalué à 4.

          comme OpenOffice et StarOffice suivent Microsoft Office, quoi...

  • # Dans la gueule du loup

    Posté par  . Évalué à 10.

    > À l'heure où SUN fait la sourde oreille pour placer Java
    > sous une licence plus acceptable,

    Y a aucun rapport Mono n'est pas développé par Microsoft. Pour Java il existe également des environement libres en cours de développement et complètement indépendant de Sun.

    cf. http://gcc.gnu.org/java/(...) (entre autres)
    et pour les librairies :
    http://www.gnu.org/software/classpath/classpath.html(...)

    > Une application .Net n'utilisant pas les APIs spécifiques à
    > Windows a de grandes chances d'être utilisable avec Mono.

    C'est bien pour cela que le projet classpath développé par la FSF est intéressant, il permettra à terme d'avoir une vraie portabilité entres différentes plateformes (et à mon avis totalement illlusoire sous .Net - cf. Wine).

    > - on peut craindre que le fait que Mono implémente
    > les mêmes APIs que Microsoft soit une épée de Damoclès ...

    Ca effectivement, ca reste un mystère pour moi. Pourquoi s'engager dans l'environnement de développement du monopolisateur N°1 et faire le jeu de celui-ci ??? J'imagine demain les pubs de Microsoft : .Net/Windows c'est super, la peuve regardez l'environnement Mono/Linux, il se traine avec trois ans de retard et n'est même pas compatible avec une implémentation de référence (à cause de pb juridiques évidemment). (Poun info si le langage C# est standardisée ECMA - et ca peut changer demain - la platforme ne l'est pas...)

    Bon j'm en vais lire le deuxième tome du combat ordinaire de Larcenet, ça me calmera :-).

    • [^] # Re: Dans la gueule du loup

      Posté par  (site web personnel) . Évalué à -1.

      Le troll est bien poilu...

      Il était temps qu'arrive une vraie alternative à Java, basé sur des standards. Les 2 ont leurs avantages et inconvénients, mais . Mais ignorer cette plateforme, c'est ignorer des millions de programmeurs potentiels et les softs qui vont avec. Cette techno a l'avantage d'être librement implémentable, ce serait vraiment dommage de passer à côté.

      Pour la portabilité, c'est illusoire, aussi bien sur Mono que sur Java : si on veut faire du 100% portable, on enlève de nombreuses qualités à un soft : l'intégration et une bonne partie de l'ergonomie spécifique à chaque plateforme.

      Et puis dis toi que si Microsoft a choisi de rendre possible Mono (les ingénieurs de Microsoft ont gentiment aidé, parcque Microsoft présente Mono comme une implémentation sous Linux - vu sur un powerpoint destiné aux décideurs - et invite même MDI), c'est aussi qu'ils y voient un intérêt...

      Bref, Java c'est bien, Mono aussi...
      Au fait Eclipse tourne sur Mono, ca fait une JVM libre supplémentaire pour MacOSX, Windows et Nux ;-)

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 4.

        > Le troll est bien poilu...
        Non mon cher TImaniac, ce n'est pas un troll mais la triste réalité, s'engager pour .Net (même au travers de Mono), cela revient à supporter Microsoft.

        > Et puis dis toi que si Microsoft a choisi de rendre
        > possible Mono (les ingénieurs de Microsoft ont gentiment aidé
        C'est justement ce qui me fait douter de Mono/.Net. Le "gentiment" que tu emploies si affectueusement à l'égard de Microsoft me rend encore plus perplexe :-)

        > Bref, Java c'est bien, Mono aussi...
        Techniquement cela va de soi. Politiquement c'est un autre affaire.
        (M$ 95% du CA desktop vs Sun 0.01%).

        >Au fait Eclipse tourne sur Mono, ca fait une JVM libre
        > supplémentaire pour MacOSX, Windows et Nux ;-)
        Eclipse tourne sous Ikvm/Mono. La VM de Mono ne me pose pas de problème, (y a déja des masses de VM) le problème est dans l'environnment .Net.

        • [^] # Re: Dans la gueule du loup

          Posté par  (site web personnel) . Évalué à 0.

          M$ 95% du CA desktop vs Sun 0.01%

          C'est bien pour ça que je trouve plus important d'attirer les développeurs Windows que les autres sous Nux, ils sont quand même plus nombreux ;-) Et si tu attires des développeurs tu attireras aussi des utilisateurs...

          • [^] # Re: Dans la gueule du loup

            Posté par  . Évalué à 4.

            Les développeurs Windows de solutions proprétaires sont sans aucun doute beaucoup plus nombreux que ceux de Linux. Pour ce qui est du libre, je ne serais pas étonné du contraire.

            D'autre part, tu penses vraiment que des développeurs Windows accepterons de coder dans un environment .Net de seconde zone.

            J'ai bien peur qu'il ne se passe justement le contraire. Pour bénéficier des dernières améliorations de la plateforme (et dieu sait si les développeurs en sont friands), ils risquent de se tourner vers Microsoft... Quelle ironie !

            • [^] # Re: Dans la gueule du loup

              Posté par  (site web personnel) . Évalué à 1.

              Evidemment je penses comme toi qu'il y a plus de développeurs de LL sous nux que sous Windows... mais justement la meilleur façon de convertir des programmeurs à cette philosophie n'est elle pas de commencer par les attirer sous Linux ?

              Et puis si tu étais un développeur .NET sous Windows, tu verrais qu'il y a beaucoup d'engouement pour Mono... Moi j'y vois pleins de développeurs potentiels...

              Toi tu préfères dire aux programmeurs : venez sous nux que si vous adhérez à la philosophie et à ses technos spécifiques non compatibles. Moi je préfères les aider à venir pour les raisons que bon leur semble (gratuité, alternative, sécurité, que sais-je) et ainsi leur faire découvrir la philosophie du libre.

              • [^] # Re: Dans la gueule du loup

                Posté par  . Évalué à 5.

                Et puis si tu étais un développeur .NET sous Windows, tu verrais qu'il y a beaucoup d'engouement pour Mono... Moi j'y vois pleins de développeurs potentiels...

                Si c'est .Net est moins bien sous Linux (ce qui a de trés forte chance d'être le cas), ils resteront sous Windows et critiqueront Linux.

                Toi tu préfères dire aux programmeurs : venez sous nux que si vous adhérez à la philosophie et à ses technos spécifiques non compatibles

                La compatibilté c'est trés relatif, ça dépend d'ou on se place. Cela peut être justement un trés bon argument pour M$, cf. mon post plus haut.

                • [^] # Re: Dans la gueule du loup

                  Posté par  (site web personnel) . Évalué à 3.

                  ls resteront sous Windows et critiqueront Linux.
                  Les développeurs Windows sont parfois plus ouverts, curieux et beaucoup moins critiques que certains fanatiques...

                  La compatibilté c'est trés relatif, ça dépend d'ou on se place.
                  Tout à fait d'accord. Celà à des avantages pour tout les 2 parties. C'est comme le fait d'utiliser les standards, c'est globalement positif. Vu la proportion d'utilisateurs Windows/Linux et vu la tendance, je crois plutôt que la compatibilité va attirer sous nux plutôt que l'inverse.

                • [^] # Re: Dans la gueule du loup

                  Posté par  . Évalué à 10.

                  Et si .NET sous Linux etait meilleur ?

                  Et si les developpeurs .NET d'une appli Web migraient sous Linux en montant en charge parceque les licences Microsoft quand on a besoin de beaucoup de machines c'est cher ?

                  Et si C# etait un excellent language (normalisé ECMA) indépendemment de sa source ?

                  Par hasard quand GNU a démarré, est ce que les UNIX proprio n'avaient pas des années d'avance ? (et aujourd'hui qui ne prefere pas les commandes GNU a leurs concurents d'origines ?)

                  Est-ce que par hasard, parceque les pressions sur le libre sont différentes de celle sur le logiciel proprio on ne peut pas obtenir un resultat différent mais meilleur ?

                  En exemple ? si je code en proprio en C# que je veuilles utiliser une librairie tierce, je serai obligé d'aller l'acheter chez des marchands de composants. Dans le monde du libre, et bien j'aurai le choix des composants développés par des tiers en GPL, LGPL ou assimilés. La réutilisation sera meilleure et je pourrai m'en permettre plus car elle sera moins couteuse.

                  Mono a de grande qualités, et si son chemin est cauillouteux (en particulier à l'aune de la brevetite aigue qui touche Ms en ce moment), son avenir est interessant !

                  • [^] # Re: Dans la gueule du loup

                    Posté par  . Évalué à 3.

                    Ta comparaison avac Linux est excellente car si Linux fait justement peur à Microsoft, c'est qu'il ne s'agit pas d'une pâle copie de Windows mais d'un développement original sans contraintes importantes. En bref, c'est la cathédrale et le bazarre.
                    Si Linus T. avait décider de faire un clone de Windows en 1991, je doute fort que l'on serait aussi avancé aujourd'hui. Malheureusement c'est la voie choisie aujourd'hui par Icaza pour concurrencer (?) Microsoft, je doute que ce soit la bonne.

                    • [^] # Re: Dans la gueule du loup

                      Posté par  . Évalué à 1.

                      La conjecture a changé !
                      On ne peut pas vraiment dire si c'est le meilleur moyen ou pas. Ce qui est sûr, c'est que Mono implémente .Net avec des bindings propres à linux et apparemment simples à utiliser (Gtk#, Qt#) donc mono devrait permettre peut être de limiter l'utilisation du C/C++ et donc accroître le potentiel des développeurs, non ?

                    • [^] # Re: Dans la gueule du loup

                      Posté par  . Évalué à 4.

                      Linus ne s'est pas inspiré de Windows mais de UNIX, dont à l'époque il ne pouvait pas avoir de version libre.

                      D'ailleurs si à l'époque il avait voulu copier une interface graphique novatrice (.NET est assez novateur à mon sens), il aurai sans doute mieux valu se tourner vers NeXTStep, ou à la limite Mac OS que vers Windows qui en était au 3.11.

                      Néanmoins je te ferai remarquer que Microsoft aussi copié UNIX (Xenix) et son succés fut .... fugitif, prouvant que le monde libre, non tenu au succés commercial, peut réussir mieux que le proprio dans les mêmes domaines.

                      Ce que je voulais souligner c'est que la techno soit "purement venue du libre" (rare) ou inspirée par un modèle proprio, les qualités intrinsèques au libre permettent de faire des programmes différents et souvent meilleurs.

                      Pourquoi une copie serai-t'elle pâle ?

                      Faire une "copie" c'est bénéficier de l'expérience de se prédécesseurs. La prime au premier entrant n'est pas que bénéfique.
                      exemples :
                      - VIM améliore VI,
                      - les commandes GNU étendent les commandes UNIX de base,
                      - les processeurs AMD "copient" le jeu d'instruction Intel,
                      - .NET copie largement Java,
                      - Postgresql "copie" le moteur PL/SQL de Oracle,
                      - Zebra copie largement 'interface de l'IOS de Cisco
                      ...

                      Qui s'en plaindrait.

                      Se concentrer plus sur des programmes performant et moins sur une surrenchere de mots avec Microsoft, voila qui devrait etre la force du monde libre car sa force est dans sa legitimite et dans le fait technique accompli.

                      De toute façon les propos de Ms, force marketing évidente, auront toujours plus d'audience. Mais ceux-ci ne seront pas éternellement crédibles au fur et à mesure que l'informatique sera appropriée par ses utilisateurs. C'est juste une question de temps, et Ms le sait.

                      Alors Mono par rapport au CLR de Ms ?

                      Une copie conforme non (puisque réalisé sans le code de Ms), une inspiration assurément, une amélioration sans doute.


                      Le seul point d'ombre à mes yeux est le risque de "minage" aux brevets.

            • [^] # Re: Dans la gueule du loup

              Posté par  . Évalué à 1.

              D'autre part, tu penses vraiment que des développeurs Windows accepterons de coder dans un environment .Net de seconde zone.

              mais où sont ces fameux softs?? des exemples?

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 10.

        >Et puis dis toi que si Microsoft a choisi de rendre possible Mono

        sauf que ceci est une demi vérité

        en réalité .NET (la plateforme avec les classes etc etc etc) n'est PAS OUVERT

        ni toutes les specs sont disponibles, ni leur implémentation est ouvert.

        il y a une définition ecma de C#, de cli et classes de bases.

        mais au dela ?
        et demain ?
        et winFX ?
        et etc ?

        bref, oui y a une épée de damocles

        alors, Mono en tant que technologie, que nouveau langage et comme fondation pour un GTK# ,gnome# etc , OUI , mais en aucun cas cela donnera une "plateforme .NET pour linux qui eclipsera le rouleau compresseur .net SUR WINDOWS)

        accessoirement, il reste encore à etre sur et certain que mono jusqu'à gtk# sont libres de tout risques de licences/brevets/restrictions que microsoft pourrait imposer suite à d'obscures brevets obligatoire pour suivre les specs ecma de cli ou du langage.

        et ceci EST IMPORTANT

        aussi IMPORTANT que les trolls JAVA ou les trolls C#

        sinon, le choix aurait déjà été fait

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 5.

          accessoirement, il reste encore à etre sur et certain que mono jusqu'à gtk# sont libres de tout risques de licences/brevets/restrictions
          Extrait de http://lists.ximian.com/archives/public/mono-list/2004-March/019042(...) :

          Microsoft has granted RAND+Royalty Free licenses to any patents they
          might own that are required to implement the ECMA 334/335 standards.
          So at least our core VM, classes and compilers are safe from any
          litigation from *Microsoft*.

          • [^] # Re: Dans la gueule du loup

            Posté par  . Évalué à 3.

            >So at least our core VM, classes and compilers are safe
            > from any litigation from *Microsoft*.

            Soit 5% du total de l'envirronment .Net. C'est à dire... la sécurité.
            J'attends de voir demain avec xaml...

            • [^] # Re: Dans la gueule du loup

              Posté par  (site web personnel) . Évalué à 4.

              Et demain quand Microsoft déploira tous ses API de LongHorn, il sera bien évident que ces technos seront utilisées, et on peut facilement prévoir que beaucoup d'appli en tireront parti, même si ce n'est pas normalisé... Ce qui fait le succès de OpenOffice c'est sa compatibilité avec les formats de Microsoft, c'est ce qui permet à de nombreux utilisateurs de faire la transition plus doucement vers Linux...
              A défaut de proposer une alternative révolutionnaire à Java ou .NET, il faut au moins être compatible, et Mono jouera pour moi le même rôle que OpenOffice dans le futur... Sinon on risque de voir beaucoup d'utilisateurs ne souhaitant pas migrer sous nux parcqu'ils ne peuvent accéder à staracademy.com codé en Xaml.

              • [^] # Re: Dans la gueule du loup

                Posté par  . Évalué à 6.

                Un environnement de développement n'a pas grand chose à voir avec un tableur ou un traitement de texte.

                A défaut de proposer une alternative révolutionnaire à Java ou .NET, il faut au moins être compatible
                ¨
                Etre compatible avec quoi ? .Net est sorti, il y a à peine un an et est très loin d'être un succès planétaire. En terme de bibliothèques libres ou de projets Java/C/CC++ sont à des années lumières.

                Etre compatible .Net, (je me répète _ diable) c'est par définition faire du .Net en moins bien. C'est le Canada Dry du développement . Je comprends que Microsoft soutienne le projet de Icaza.

                > parcqu'ils ne peuvent accéder à staracademy.com
                > taracademy.com codé en Xaml.
                Je ne vois pas pourquoi coder xaml (si ce sera légalement possible) serait plus difficile dans un autre environnement que .Net. Par ex. XUL existe déja dans bien d'autres langages. Je ne vois pas bien l'intérêt de copier Microsoft. Rien de bon ne sortira à terme d'une telle politique. S'interfacer ok, imiter non.

                • [^] # Re: Dans la gueule du loup

                  Posté par  (site web personnel) . Évalué à 2.

                  Evidemment, la comparaison avec OpenOffice est très limité (mais bon comme la plupart des comparaison...)
                  Evidemment, .NET n'est pas encore utilisé partout... Mais le prochain Windows ne laissera pas le choix au développeur : les nouveaux API sont codé au dessus du framework .NET. Bref, même si .NET n'est pas massivement adopté il le sera (sous Windows en tout cas).

                  Etre compatible .Net, (je me répète _ diable) c'est par définition faire du .Net en moins bien.
                  Non, c'est respecter un standard ouvert et techniquement performant, c'est proposer des API pour Gnome pour montrer qu'on peut faire autre chose que imiter et c'est proposer des API compatibles par soucis de portabilité pour ceux qui le désire.

                  Sinon je suis d'accord avec toi que copier c'est pas bien... Mais ce serait idiot de développer une autre plateforme non compatible... Et puis il ne s'agit pas seulement de copier... Mono a fait des proposition pour les nouvelles spécifications de C# 2.0 & Co et les a même implémentées avant Microsoft...

                  Je ne vois pas bien l'intérêt de copier Microsoft.
                  Le but n'est pas de copier. Le but est de proposer la compatibilité en plus de nouveaux API.

                  • [^] # Re: Dans la gueule du loup

                    Posté par  . Évalué à 3.

                    >c'est respecter un standard ouvert
                    Non c'est faux 95% de .Net n'est pas ouvert et est à la discrétion de Microsoft.

                    >c'est proposer des API pour Gnome
                    On peut trés bien faire des bindings pour d'autres langages.

                    >Mais ce serait idiot de développer une autre
                    >plateforme non compatible...
                    Mais justement comme on ne sera jamais compatible (ou uniquement en moins bien- cf. Wine) Au lieu de se lancer dans un redéveloppement de .Net autant faire du libre de chez libre.

                    > Mono a fait des proposition pour les nouvelles
                    > spécifications de C# 2.0 & Co et les a même
                    >implémentées avant Microsoft

                    Et si Microsot n'est pas d'accord, qu'est ce qui se passera. On ne sera plus compatible avec .Net et on aura rien gagné. Si le risque d'être poursuivi un jour par M$.

                    • [^] # Re: Dans la gueule du loup

                      Posté par  (site web personnel) . Évalué à 2.

                      Non c'est faux 95% de .Net n'est pas ouvert et est à la discrétion de Microsoft.
                      Est-ce que j'ai écrit que c'était .NET le standard dont je parlais ? Et ca sors d'où ce chiffre complètement bidon de 95% ?

                      c'est proposer des API pour Gnome
                      On peut trés bien faire des bindings pour d'autres langages.
                      Est-ce que j'ai dit le contraire ? Pouquoi tu ne cite pas ma phrase en entier ? Tu aurais compris que je voulais juste dire qu'on pouvait faire autre chose qu'imiter et proposer du nouveau (comme les classes de sécurité, l'API Posix, le support du format RelaxNG, le support des appli Java, et j'en passe).

                      Franchement je veux bien discuter mais là je vois vraiment pas où tu veux en venir, à part démontrer que faire des libs compatibles avec celles de Microsoft est parfaitement inutile (d'ailleur on se demande pourquoi ceux qui le font le font !), là encore rien ne t'oblige de toute façon à les utiliser... et l'avenir nous dira si elles sont vraiment utile pour quelqu'un.

                      • [^] # Re: Dans la gueule du loup

                        Posté par  . Évalué à 2.

                        Bon je cite plus largement :

                        >>Etre compatible .Net, (je me répète _ diable) c'est par définition faire du .Net en moins bien.
                        >Non, c'est respecter un standard ouvert et techniquement performant

                        Je parlais bien de .Net qui est appelé à devenir le socle du prochain OS de Microsoft. Je ne pense pas que Microsoft standardisera toutes ses API .Net. Donc, je persiste à penser que 95% de la pateforme .Net sera non standard et propriété de Microsoft.

                        Est-ce que j'ai dit le contraire ? Pouquoi tu ne cite pas ma phrase en entier ? Tu aurais compris que je voulais juste dire qu'on pouvait faire autre chose qu'imiter et proposer du nouveau (comme les classes de sécurité, l'API Posix, le support du format RelaxNG, le support des appli Java, et j'en passe).

                        Pour ce point d'accord et c'est trés bien. Dans ce cas la peut on encore parler de .Net. Visisiblement ce n'est pas le but prioritaire du projet Mono : "The Mono project is an open source effort sponsored by Novell to create a free implementation of the .NET Development Framework"

                        Franchement je veux bien discuter mais là je vois vraiment pas où tu veux en venir, à part démontrer que faire des libs compatibles avec celles de Microsoft est parfaitement inutile (d'ailleur on se demande pourquoi ceux qui le font le font !),

                        Trés simplement, mais je l'ai déja dit et redit dans mes précédents posts, je ne pense pas que rechecher à implémenter .Net soit une bonne idée. C'est risqué et illusoire. (Dans le même esprit, je ne pense pas que Wine ait rapporté beaucoup d'utilisateurs Windows à Linux eu égard à l'énergie dépensée de ce projet).

                        En revanche, je suis tout à fait d'accord avec l'idée de faire un compilateur c#, une VM associée et qq bibliothèques de base et autres bindings (gnome, gtk, freetype, etc...) en tout genre.

                        et l'avenir nous dira si elles sont vraiment utile pour quelqu'un
                        J'espère bien :-).

            • [^] # Re: Dans la gueule du loup

              Posté par  . Évalué à 5.

              Soit 5% du total de l'envirronment .Net.
              Le reste n'est pas interessant. Nous avons deja nos propres plate-forme de developpement. Les utiliser en collaboration avec ce qui se trouve dans l'ECMA-335 est une possibilite tres interessante d'un point de vue technique.

              • [^] # Re: Dans la gueule du loup

                Posté par  . Évalué à 0.

                Le risque de se faire bloquer à terme dans l'évolution de la plateforme n'est pas négligeable.

                Si c'est justement que pour 5% pourquoi les copier alors?

                • [^] # Re: Dans la gueule du loup

                  Posté par  . Évalué à 3.

                  DotGNU continuera a faire evoluer la plate-forme. Que mono suive ou pas n'a pas d'importance. Comme le travail est fait sur des standards, les projets pourront migrer vers DotGNU et ses ameliorations si ca leur chante.

          • [^] # Re: Dans la gueule du loup

            Posté par  . Évalué à 2.

            > Microsoft has granted RAND+Royalty Free licenses to any patents they
            >might own that are required to implement the ECMA 334/335 standards.

            Oups, ça va finir dans non-free tout ça...
            Trêve de plaisanterie, il font bien ce qu'ils veulent dans le language qu'ils veulent, pourvu qu'ils ne fassent pas dépendre des projets important pour linux de trucs litigieux. Imaginez, ils ne faudrait pas que gnome, kde, mozilla, OOo aient des dépendances là dessus, et qu'un jour on se rende compte qu'il y a un problème.

    • [^] # Re: Dans la gueule du loup

      Posté par  . Évalué à 4.

      À la lecture de la FAQ, on se rend compte que les développeurs MS répondent plutôt gentillement aux questions que les dev. Mono leur demande...

      Et il y a une entrée qui dit en gros: et si d'un coup .NET n'est plus standardisé ECMA ? Tant pis, on aura quand même un très bon framework à utiliser [ et qui sera lui disponible sous pleins d'architectures différentes, dont, win, linux, *bsd, macos, etc. ]

      De plus, si tout cela s'engage dans une collaboration Mono/Gnome/Mozilla, ça ne peut être au final que très positif, enfin je trouve. Après, il faut voir si le framework est vraiment bien. De ce que j'en voit, ça a l'air pas mal.

      J'avoue que la lecture de la FAQ sur go-mono.org/ ouvre pas mal l'attention, et montre un autre visage que le sempiternel « ça vient de MS, c'est mal. »

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 4.

        oui, "Tant pis, on aura quand même un très bon framework"

        oui, cela me parait bien plus important. et espérons que gnome et mozilla sauront capitaliser aussi avec ce framework.

        (je n'ai PAS dit une réécriture mozilla en mono hein!!!! mais c#/gtk# ne sont pas indignes pour faire des applications natives gnome, mono peut etre interessant pour des webservices avec une interface gnome client etc etc )

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 2.

        > À la lecture de la FAQ, on se rend compte que les développeurs
        > MS répondent plutôt gentillement aux questions que les dev.
        >Mono leur demande...

        Et cela ne t'interpelles-pas? Mais bon dieu arrétez d'être naif à ce point !!!! C'est tout leur intérêt.

        Mono/.Net techniquement n'est pas plus mal qu'autre chose. Copier .Net, c'est s'assurer de rester éternellement l'éternel n°2 (au mieux) au plus grand bonheur de Microsoft.

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 3.

          Tu peux aussi imaginer que la transistion entre pour un programmeur C#/Forms Windows vers C#/GTK#(ou QT# ou Wx#...) sera moins dure que C/API WIN32 (qui est une horreur et requiers un investissment considerable en temps (je pense qu'on y sacrifie pas mal de points de SAN) ) ou C++/MFC vers ..... C/GTK; C/Motif ou C++/QT, ou .XLib.

          Bref on peut imaginer que outre une certaine compatibilité, le caractère propre de Mono le rende séduisant mais surtout réduise la barrière à la migration d'un développeur d'un environnement à l'autre.

          Considérant le nombre de personnes ayant une expérience de dev. Windows, considérant que beaucoup doivent être en train de potasser leur .NET (ou devraient), Mono me semble etre plutot positif.

          Que Ms vienne dire que le libre est un éternel suiveur importe peut. Une chose compte bien plus (comme dirait Steve Balmer) : "Developers Developers, Developers !!!!!!" (à répéter en sautillant ridiculement)

          (au fait il existe une autre machine virtuelle universelle libre : Parrot :-) )

          • [^] # Re: Dans la gueule du loup

            Posté par  . Évalué à 4.

            C'est vrai, nous sommes des suiveurs.
            Mais à ce jeu là, tout le monde est très doué :
            • le .NET rappelle par certaine côtés le................................Java. "SAPUSAIPALIBRE" mais c'est pour montrer que la copie ça arrive aussi aux grands

            • Le XAML pointe son nez, dérivé de XUL opérationnel dans Mozilla depuis... 1 an à peu près, mais n'utilisant pas Mozilla, je peux me tromper.

            • Windows gère maintenant, depuis NT4 pour les pros et XP pour tout le monde, de vrais utilisateurs à privilèges distincts.... Tiens mais ça vient d'où? ; )


            Dans l'autre sens:
            • OpenOffice suit les formats M$ Office.

            • Mono suit .NET pour l'interopérabilité, et ajoute son petit bout de chemin au passage avec GTK#, un ADO.NET mieux fourni...

            • Les projets foisonnent pour suivrent XAML au niveau de l'intégration des interfaces.


              • Je pense que dans sens M$ > autres c'est pour récupérer les bonnes idées qui lui manquaient.
              Je pense que dans le sens autres > M$ c'est pour récupérer la bonne idée de .NET, ET aussi parce que quand on possède + de90% du marché des OS et qu'on sort une nouvelle techno copieusement marketisée, si le LL ne suit pas derrière, on va perdre du terrain sur des choses qui seront des standards de fait d'ici peu de temps.
              Moi, ça me ferait peur que tout le monde windowsien se gave de pages qui "déchirent" en XAML/3D/Hologrammes sur IE 10.0 pendant que les unixiens visionneront du Hteumeuleu restant sur 3 pauvres sites avec Mozilla 3.0 : )

              Tout ceci me fait me sentir mieux quand je me dis "ah bah oui, mais ça c'est copié sur Microsoft, c'est nul pour du LL"

            • [^] # Re: Dans la gueule du loup

              Posté par  . Évalué à 2.

              Petite note :

              Les privileges distincts sont depuis toujours dans Windows NT, et viennent de specs du gouvernement US.

              Le modèle d'ACL utilisées dans NT à sans doute plus à voir avec VMS(ont un des concepteurs dirigeait l'équipe chargée de NT) qu'avec Unix.

              Mais comme la plupart des technos, ca ne sort pas de spontanément de nulle part.

              • [^] # Re: Dans la gueule du loup

                Posté par  . Évalué à 2.

                Ouaip, c'est bon à savoir, merci de rectifier.
                Mon idée était aussi de montrer que rien ne sort de nulle part.

        • [^] # Re: Dans la gueule du loup

          Posté par  (site web personnel) . Évalué à 1.

          > Et cela ne t'interpelles-pas? Mais bon dieu arrétez d'être naif à ce point !!!! C'est
          > tout leur intérêt.

          L'intéropérabilité (même réduite) c'est l'intérêt de tout le monde.
          Il faudrait voir si le but c'est de lutter contre MS (auquel cas effectivement le fait qu'ils y trouvent un intérêt est gênant) ou si c'est d'avoir un truc efficace, compatible, utile (auquel cas si ils y trouves leur intérêt *aussi* je n'y vois rien de gênant)

          • [^] # Re: Dans la gueule du loup

            Posté par  . Évalué à 1.

            En tout cas aujourd'hui les barrieres à l'interroperabilité jouent largement en faveur de Ms.

            Dans un monde ou 90% des postes de travail sont sous Windows, si on ne peut faire portable, on fait dédié au leader.

            Ca marche pour les programmes, mais plus encore pour les compétences.

            Il n'y a qu'a suivre les précautions dont Ms entoure toute communication sur ses API.

            Le monde Microsoft est en phase de transition de l'API WIN32 et des MFC vers .NET, c'est une période de vulnérabilité.
            Les développeurs doivent se remettre à la formation et ca peut être aussi pour eux l'occasion de regarder ailleurs que MSDN, histoire de voir...

            De plus, plutot que de se positionner dans une posture de défense vis à vis de Ms, si on peut le faire (légalement), pourquoi ne pas utiliser les bonnes idées même si elles viennent d'ailleurs (syndrome "Not Invented Here" ?).

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 4.

        on se rend compte que les développeurs MS répondent plutôt gentillement aux questions que les dev. Mono leur demande...


        La dessus je trouve que MDI est un peu léger. En général pour tous les projets qui touchent à la compatibilité MS (Samba et autres) on impose à tous les devs un code de conduite stricte : Ne jamais toucher à une info/doc en provenance de MS sans avoir une license claire. Si c'est déja fait plus le droit de toucher au projet. Là, ils discutent tranquille avec les gars de chez MS. Et si demain ils se réveillent en disant "Ah mais on ne vous pas dis que vous aviez les droit d'utiliser ça dans un produit concurrent", dommage.

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 1.

          Tout ce qui est normalisé l'est avec la certitude que microsoft ne peut rien faire contre, apprès pour ce qui n'est pas normalisé c'est vrai que c'est un risque à prendre... Mais bon perso je m'en fous je me sert seulement de la partie normalisée...

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 2.

        C'est aussi mon point de vue : après tout, si le .NET crosoft s'éloigne de Mono, il restera un EXCELLENT outil de développement multi plateformes. Même dans le pire des cas, on y trouvera notre compte.
        Moi, c'est Mono qui me pousse à enfin vouloir développer sous linux.
        Avis peut être faux mais entièrement personnel.

    • [^] # Re: Dans la gueule du loup

      Posté par  . Évalué à 3.

      (Poun info si le langage C# est standardisée ECMA - et ca peut changer demain - la platforme ne l'est pas...)
      Toute la technologie qui fait l'elegance et l'efficacite de la plate-forme .NET est placee sous ECMA : http://www.ecma-international.org/publications/standards/Ecma-335.h(...) Il n'y a que quelques classes qui sont proprietaires et non standardisees, mais elles n'interessent personne endehors des Windowsiens.

      et complètement indépendant de Sun.
      Mono est egalement completement independant de Microsoft... MDI a repete et repete que si Microsoft sortait une nouvelle version non standardisee et incompatible de ces technologies, ce ne serait pas grave car l'ancienne version restera un acquis de tres bonne facture.

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à -1.

        Mono est egalement completement independant de Microsoft...
        MDI a repete et repete que si Microsoft sortait une nouvelle version non standardisee et incompatible de ces technologies, ce ne serait pas grave car l'ancienne version restera un acquis de tres bonne facture

        Un acquis qui ne peut plus évoluer en informatique et un acquis rapidement mort.

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 2.

          Stupide comme citation.

          Si microsoft ne standardise pas la prochaine version, bah les dev pouront faire évoluer l'ancienne à leur manière, ils ne pouront pas continuer à copier microsoft mais ça ne veut pas dire qu'ils aretteront d'évoluer.

    • [^] # Re: Dans la gueule du loup

      Posté par  . Évalué à 6.

      C'est bien pour cela que le projet classpath développé par la FSF est intéressant, il permettra à terme d'avoir une vraie portabilité entres différentes plateformes (et à mon avis totalement illlusoire sous .Net - cf. Wine).

      A mon avis MDI n'aurait même pas du s'emmerder à réimplémenter les API Windows (genre WinForms) dans Mono et repartir sur un framework complètement libre. De toutes façon la portabilité MS->reste du monde est illusoire. Microsoft continuera d'ajouter des extensions à son bébé donc une appli codée sur VS.net ne tournera jamais tel quelle sur Mono. Autant partir sur des bases saines.

      Et puis pour ce qui est de la standardisation, bof. Un standard c'est bien quand c'est propre. La le standard est calqué sur Windows Exemple tout con : Les chemins. DOS a inventé une dénomination "unique" (C:, D:) qui n'existe nulpart ailleurs que dans le petit monde MS. Et bien c'est cette nomenclature qui est bien sûr utilisée pour DotNet. La première fois qu'on se mange une exception "Cannot open D:\..." en essayant d'ouvrir un fichier sous Linux ça fait tout drôle. Pareil pour les nom de fichiers (exe, dll). Le standard c'est Windows. Que du bonheur.

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 4.

        A mon avis MDI n'aurait même pas du s'emmerder à réimplémenter les API Windows (genre WinForms) dans Mono et repartir sur un framework complètement libre.
        C'est le but du projet DotGNU. Les bindings gnome aussi avec.

        http://www.gnu.org/projects/dotgnu/(...)
        http://gtk-sharp.sourceforge.net/(...)

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 0.

          Ah Enfin d'accord.

          Réimplémenter un compilateur, une VM et qq librairies de base ok. Réimplementer .Net, c''est totalement illusoire et extrémement risqué. A priori c'est bien le but poursuivi par l'équipe de Mono et ç'est ce qui me gêne et rend tout le projet suspect.

          En revanche tous les nouveaux bindings GTK ou gnome sont les bienvenus. Qu'ils soient python, java ou c#.

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 1.

          Euh DotGNU à ce que j'en sait cherche aussi à réimplémenter System.Windows.Forms que je sache, c'est en gros sur leur site...

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 1.

        En fait cest pas gagné pour la portabilitée facile, du fait que pour cause de license sur une partie du framework n'est pas eéimplémentable sous mono.

        A mon avis, si on veut eviter les lacunes de java, MS aurait interet a faire un sys de package et un équivalent du cpan (a mon avis une des grosses erreurs de Sun fut le lamentable format jar, et de ne pas regrouper la plupart des packages sur un serveur accessible via un utils a la cpan). Ca permetrait au dev mono de porter facilement leurs applis sous win (vu que les gtk# et cie serait dans un repository), et plus difficielent l'inverse.

        J'aime beaucoup .net, mais j'ai bien peur que le portage d'appli ne soit facile que dans 1 sens...

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 3.

          Le portage est facile si bien codé :
          - Utiliser un toolkit graphique multi plateforme : GTK, QT, ...
          - Oublier les spécificités de l'OS : Pas de Path1 +
          '\' + Path2 il existe des fonction qui le font très bien..., pas de Mono.Posix évidement, pas de Microsoft.* ou de System.Windows.*

          Une appli codée dans un esprit de portage est simple à porter mais c'est pas une baguette magique, si les dev ne sont pas formés pour ça ça ne se fait pas tout seul, plateforme .Net ou pas.

    • [^] # Re: Dans la gueule du loup

      Posté par  . Évalué à 4.

      "Y a aucun rapport Mono n'est pas développé par Microsoft. Pour Java il existe également des environement libres en cours de développement et complètement indépendant de Sun."

      Hum ... comment dire ... tu n'as rien compris en fait. .Net est une alternative à Java (la plate-forme) qui _devient_ intéressante par le biais de Mono. Sun est en train de faire une erreur de stratégie vis-à-vis des développeurs "libres / oss", ce qui fait que beaucoup lorgnent vers une plate-forme 'similaire' mais qui soit plus portable et sous une licence qui convienne mieux à leurs aspirations.

      "C'est bien pour cela que le projet classpath développé par la FSF est intéressant, il permettra à terme d'avoir une vraie portabilité entres différentes plateformes (et à mon avis totalement illlusoire sous .Net - cf. Wine). "

      Si ça continue comme ça GNU Classpath va devenir un troll de fins connaisseurs comme l'est le Hurd. Classpath est à peu près compatible Java 1.2. Pour le 1.3 on repassera. Pour le 1.4 ... on est à la rue. Si j'ai bien compris tes propos, tu parles de GUI portables en Java avec Classpath, or saches que ça n'est pas implémenté du tout. AWT est potentiellement utilisable (en étant optimiste), mais pour Swing c'est le néant. En revanche pour Mono et System.Windows.Forms, il y a deux travaux en cours. Un à base de Wine comme tu le dis et un qui vise à employer Gtk#. Et puis pour faire des GUIs .Net portables, on peut employer wx.Net, Qt# et un port de SWT dont j'ai oublié le nom. Bref System.Windows.Forms c'est juste pour ammener tant bien que mal des applis développées sous MS/.Net vers Mono/.Net. Et puis Mono avance à un rythme soutenu en étant nettement plus jeune que Classpath.

      J'ai fait pas mal de choses avec Java et l'attitude récente de Sun vis-à-vis de la politique sur les licences de Java m'irrite. Pour faire simple, on ne risque pas d'avoir d'implémentations sous une licence acceptable. GNU Classpath ne sera jamais une solution de remplacement valable, mais ça n'est que mon avis. Du coup je lorgne sur Mono car .Net a une architecture intéressante et Mono est _vraiment_ portable. A la rigueur je me fiche que Mono n'implémente pas tout ce que MS implémente, Mono est en soit une plate-forme .Net. Rien ne dit que je ferai effectivement des développements avec Mono, mais tout ça est fort alléchant, donc j'essaie, je me documente pour me constituer un avis réfléchi sur la question. C'est toujours mieux que de jouer les puritains des immondes GNU Coding Standards.

      • [^] # Re: Dans la gueule du loup

        Posté par  . Évalué à 1.

        Hum ... comment dire ... tu n'as rien compris en fait. .Net est une alternative à Java (la plate-forme) qui _devient_ intéressante par le biais de Mono. Sun est en train de faire une erreur de stratégie vis-à-vis des développeurs "libres / oss",

        Désolé mais je pense que c'est toi qui n' a bien compris. L'auteur de la news cite le projet Mono pour ensuite l'opposer Sun qui n'a pas passé Java en Opensource.

        On peut opposer Microsoft à Sun ( 2 société commerciales qui n'ont pas libérés le code source de leurs implémentations respective de C# et Java - encore que pour Sun il est possible de se procurer les sources mais pas en GPL).

        Mono s'apparente plutot au projet GCJ et à Classpath qui sont deux projets libres supportés par la FSF qui visent à recréer un environnement de développent Java.

        ce qui fait que beaucoup lorgnent vers une plateforme 'similaire' mais qui soit plus portable.
        Plus portable en quoi !?! AHMA, l'environnement Java est disponible sur beaucoup plus de plateformes.

        Pour le reste de ton post, tu soulignes combien il est déja compliqué d'implémenter classpath, alors je n'ose même pas imaginer pour .Net. (Wine malgré plus de dix ans de développement et des ressources non négligeables est encore trés loin de pouvoir passer en production par ex.)

        on ne risque pas d'avoir d'implémentations sous une licence acceptable
        Ah bon, les licences de GCJ, SableVM et Classpath ne te plaisent pas. Elles sont pourtant supportées par la FSF.

        A la rigueur je me fiche que Mono n'implémente pas tout ce que MS implémente, Mono est en soit une plate-forme .Net
        Non justement une plateforme .Net qui n'implémente pas tout .Net est au mieux qu'une plateforme .Net au rabais. Crois moi que Microsoft s'en servira pour faire de la pub contre linux.

        C'est toujours mieux que de jouer les puritains des immondes GNU Coding Standards.
        !?!

        • [^] # Re: Dans la gueule du loup

          Posté par  . Évalué à 3.

          "Désolé mais je pense que c'est toi qui n' a bien compris. L'auteur de la news cite le projet Mono pour ensuite l'opposer Sun qui n'a pas passé Java en Opensource."

          Coucou c'est moi l'auteur de la news :-)

          "Plus portable en quoi !?! AHMA, l'environnement Java est disponible sur beaucoup plus de plateformes."

          Ok, trouves moi le JDK pour Linux/PPC ou de façon plus générale pour tout processeur non dans la lignée Intel. Trouves moi aussi le JDK pour *BSD. Pour l'instant sous FreeBSD il faut télécharger les sources de Sun (en acceptant une licence super-contraignante), appliquer des patches puis compiler un truc qui te demande d'avoir 1,3Go de libres. Pour Mono, il n'y a pas de problèmes de portages ni de problèmes de redistribution sous forme compilée.

          "Pour le reste de ton post, tu soulignes combien il est déja compliqué d'implémenter classpath, alors je n'ose même pas imaginer pour .Net. (Wine malgré plus de dix ans de développement et des ressources non négligeables est encore trés loin de pouvoir passer en production par ex.)"

          Le but de Mono n'est pas de tout implémenter. Les classes non spécifiques à Windows sont en particulier celles qui sont intéressantes. Je n'ai pas assez de recul sur Mono à ce jour, mais la plupart des classes implémentées ont l'air relativement fonctionnelles. Et puis Mono utilise un jeu de tests automatisés visiblement rigoureux. Ca peut paraitre être un détail méthodologique pour certains, mais ça permet d'avancer très vite ce genre de choses.

          "Ah bon, les licences de GCJ, SableVM et Classpath ne te plaisent pas. Elles sont pourtant supportées par la FSF. "

          Tu confond VM, compilateur et classes de la bibliothèque "standard" de Java. En l'occurence le nerf de la guerre concerne surtout les classes dites "standard".

          • [^] # Re: Dans la gueule du loup

            Posté par  . Évalué à 0.

            Ok, trouves moi le JDK pour Linux/PPC ou de façon plus générale pour tout processeur non dans la lignée Intel. Trouves moi aussi le JDK pour *BSD. Pour l'instant sous FreeBSD il faut télécharger les sources de Sun (en acceptant une licence super-contraignante), appliquer des patches puis compiler un truc qui te demande d'avoir 1,3Go de libres. Pour Mono, il n'y a pas de problèmes de portages ni de problèmes de redistribution sous forme compilée.


            Je ne comprends pas pourquoi tu t'escrimes à comparer Mono avec la JDK de Sun. Des environnment sde développement Java en libre existent (incomplets, certes, mais pas plus que ne l'est Mono par rapport à .Net). Un de ces environnments, GCJ pour ne pas le citer, est disponible sous une foultitude d'architectures (X86 ou non) et est parfaitement redistribuable sous forme de package binaire ou source. Dans cet environnement, et grace à Classpath, il est tout de même possible de faire tourner Eclipse ce qui n'est pas rien.

            Le but de Mono n'est pas de tout implémenter. Les classes non spécifiques à Windows sont en particulier celles qui sont intéressantes.

            Le but de mono est le suivant : "The Mono project is an open source effort sponsored by Novell to create a free implementation of the .NET Development Framework". Visiblement cela concerne tout .Net. De plus, je serais content de savoir ce qu'est une classe .Net non specifique de Windows...

            Et puis Mono utilise un jeu de tests automatisés visiblement rigoureux. Ca peut paraitre être un détail méthodologique pour certains, mais ça permet d'avancer très vite ce genre de choses.


            Pour info tous les gros projets (commerciaux ou libres) utilisent ce genre de tests. C'est entre autre le cas de Classpath.

            Tu confond VM, compilateur et classes de la bibliothèque "standard" de Java.
            Ah bon ou ca ??

            En l'occurence le nerf de la guerre concerne surtout les classes dites "standard" de Java.
            C'est bien pour cela que je parle de classpath, qui sont les bibliothèques libres du projet et sont disponibles en licence GPL. C'est plutot toi qui n'a pas l'air de maitriser trés bien ce sujet.

            • [^] # Re: Dans la gueule du loup

              Posté par  (site web personnel) . Évalué à 1.

              A t'écouter ClassPath rulezzz mais y'a les même problème que pour Mono (pas 100% compatible avec son modèle proprio)... Donc si y'a les mêmes problèmes comparons les avantages : techniquement y'a pas photo, question compatibilité on peut faire tourner du Java sur Mono et pas l'inverse.

              Visiblement cela concerne tout .Net.
              En tout cas le projet Mono vise une compatibilité avec la version 1 du framework .NET cette année... ClassPath c'est prévu pour quand la compatibilité avec le JDK 1.4 ?

              De plus, je serais content de savoir ce qu'est une classe .Net non specifique de Windows
              C'est l'ensemble des classes définies à l'ECMA et à l'ISO + les classes qui n'appartiennent pas au namespace Microsoft.* (sont gentils, z'ont même cloisonné ce qui était dépendant de la plateforme, en gros les WinForms...)

              • [^] # Re: Dans la gueule du loup

                Posté par  . Évalué à -1.

                Mais non le problème n'est pas la. Il ne s'agit pas de comparer les mérite respectifs de Java et de .Net. Ce qui est enervant c'est de voir le FUD propagée (par une partie) de cette news et par les commentaires de l'auteur de cette news. C'est le mensonge par omission si caractéristique des 'press releases' style M$. Citer Java pour le comparer (défavorablement) à Mono et oublier les implémentations libres de ce langage c'est malhonnête. Point.

            • [^] # Re: Dans la gueule du loup

              Posté par  . Évalué à 2.

              Pour ce qui concerne Eclipse, ils se limitent à Java 1.3 et n'emploient au final qu'un sous-ensemble relativement restreint des APIs dites standard de Java. Avec un petit jeu de patchs ça compile effectivement. Maintenant on en reparlera avec des applications Java/Swing (la quasi-totalité des applications client-lourd écrites en Java) et des applications J2EE. Je serai curieux de voir des projets sérieux faits avec JBoss et compagnie tourner sans les classes standard de Java ... Dans le meme temps certaines applis ASP.Net on déjà pu être portées sur Mono qui est pourtant jeune et pas assez éprouvé.

              Pour ta confusion VM/Compilo/Classes standard, c'est très simple. Tu me parles de Kaffe, Jikes RVM et compagnie. Effectivement il s'agit d'implémentations libres (et pour certaines très efficaces) de machines virtuelles Java. Avec ça je peux effectivement espérer faire tourner du bytecode Java sans passer par une VM made-in-Sun. Ceci dit il me faut les classes standard et la seule alternative à l'implémentation proprio de Sun s'appelle Classpath, qui est on ne peut plus limité.

              Au passage GCJ n'est pas un environnement comme tu le dis, il s'agit d'un compilateur, ce qui n'a pas grand chose à voir avec un environnement (compilo + APIs standard + VM). A part ça c'est moi qui ne maitrise pas le sujet.

              Tu m'accuses un peu plus bas de FUD. C'est un peu facile de brandir le spectre du FUD dès que ça arrange. En l'occurence j'oppose Java et .Net car il s'agit bien de deux plate-formes qui s'opposent. Si l'on fait abstraction de la paternité de .Net, c'est une bonne plate-forme. Pour un développeur libre qui veut travailler sur ce type de plate-forme, Mono rend .Net intéressant dans la mesure où Mono est libre et la seule implémentation de Java utilisable est proprio et le restera. Est-ce du FUD anti-Java ? Non, relis la définition du FUD. Je ne suis pas un fan de MS ni de MDI, mais quand je regarde Mono, je me dis que c'est peut-être une excellente piste pour faire des applications libres sur une implémentation libre et portable d'une plate-forme intéressante.

              • [^] # Re: Dans la gueule du loup

                Posté par  . Évalué à 1.

                Au passage GCJ n'est pas un environnement comme tu le dis, il s'agit d'un compilateur, ce qui n'a pas grand chose à voir avec un environnement (compilo + APIs standard + VM). A part ça c'est moi qui ne maitrise pas le sujet.

                Rien que par cette phrase , j'ai la confirmation qur tu n'y connais rien. GCJ est un ensemble de soft : dont un compilateur (qui produit du bytecode ou des exe), un interpréteur (gij), etc. et une implementation des librairies Java (libgcj) en cours de fusion avec classpath.

                Mono rend .Net intéressant dans la mesure où Mono est libre et la seule implémentation de Java utilisable est proprio et le restera

                C'est bien du FUD. Depuis quand tu sais lire dans le futur.
                Si la taille des librairies Java rend effectivement la complétion d'un tel travail difficile, il en est exactement de même pour les librairies .Net. (cf. Wine)

                mais quand je regarde Mono, je me dis que c'est peut-être une excellente piste pour faire des applications libres sur une implémentation libre et portable d'une plate-forme intéressante.

                Je n'attaque pas les qualité techniques de Mono (ou des autres implémenations libres de VM/framework), je regrette juste que ce choix fait le jeu de Microsoft.

                • [^] # Re: Dans la gueule du loup

                  Posté par  (site web personnel) . Évalué à 1.

                  Mais arrête de comparer Mono à Wine :-) Ca n'a strictement rien à voir... Dans un cas il faut adapter un ensemble d' API de bas niveau qui simule toutes les fonctionnalités d'un OS, dans l'autre cas il faut faire une adaptation d'un ensemble d'API de plus haut niveau, beaucoup plus facile à implémenter... (à part pour les WinForms qui font encore trop appel à certains principes sous-jacent de Windows, mais là encore ce n'est pas insurmontable...) Comme tu l'as très bien dis plus haut, Wine au bout de 10 ans n'est toujours pas utilisable en production et puis ce n'est pas du tout une plateforme de développement... A contrario, Mono en 2 ans et demi a déjà fait un framework suffisament complet pour par exemple migrer sans rien faire les applications ASP.NET...

  • # bugzilla

    Posté par  (site web personnel) . Évalué à 6.

    Et comme pour toutes les versions béta, le plus important c'est de participer par ici : http://www.go-mono.com/bugs.html.(...) La doc est disponible également à travers un browser spécial Wiki (monodoc, livré avec la beta) qui permet à tous de contribuer facilement.

    Sinon, il faut préciser que cette béta n'est pas dispo pour MacOSX(prévu pour la prochaine beta dans 1 mois).

    Pour ceux qui veulent avoir un aperçu de l'IDE (également prévu pour la version finale), allez voir par ici : www.monodevelop.com. Pas mal de bugs, mais déjà agréable à utiliser.

  • # Monavis à moi

    Posté par  . Évalué à 7.

    Bon
    Je veux juste donner l'avis d'un petit dévelopeur.
    À une époque, je développais sous win avec Delphi. J'adorais l'auto-completion, bien foutue...
    Puis je suis passé à linux, j'ai erré entre Python, PHP, C++...
    Aucun EDI (sauf quanta pour le php) ne me fournissait une autocomplétion correcte.

    Il y a 2 jours, par pure curiosité, j'ai essayé MonoDevelop. J'ai été séduit par l'autocompletion, très rapide et surtout super intuitive. Bien entendu, il a des défauts de jeunesse, mais il m'a l'air bien parti pour former un superbe EDI.

    Il faut arrêter de se voiler la face. Le C et le C++ ont leurs énormes avantages (rapidité, nombre de librairies...) mais surtout leurs défauts. La gestion de la mémoire, la vitesse de compilation (je sais, avec gcc, ça s'améliore...), la lourdeur du langage... Autant d'éléments qui peuvent rebuter un mec qui cherche à se plonger dans les sources. Franchement, python (que j'adore) souffre en terme de performances sur les grosses applis, perl est repoussant pour les newsbies...
    Il leur manque à tous un super EDI avec donc l'auto complétion, un créateur de fenêtres intégré (qui manque à monodevelop, mais j'espère qu'il apparaîtra vite!)
    KDevelop est sur le bon chemin bien sûr. L'avenir va être superbe pour KDevelop avec QT4 si ils détachent le dessinateur de fenêtres du designer...

    Mono, même si il passe incompatible à 100% avec le .Net de m$, est et restera probablement une plateforme de développement multi-plateformes très correcte, pour ne pas dire plus (tout dépend de l'avenir)
    Même si on doit en supprimer tout ce qui est dépendant de m$ comme le VB.net, ou asp.net...

    Attention, je tiens à le signaler, je déteste et j'abhorre m$ ! Ils sont pour moi responsables de la disparition de la qualification de "science" pour l'informatique avec leurs OS à plantages aléatoires, leurs bugs immondes, leurs softs mal foutus...


    Je demande juste une chose : que le développeur débutant puisse bosser FACILEMENT sous linux ! Pour l'instant, seul MonoDevelop et Python (couplé à Eric) m'ont convaincu...

    • [^] # Re: Monavis à moi

      Posté par  . Évalué à 2.

      >Franchement, python (que j'adore) souffre en terme de performances sur les grosses applis, perl est repoussant pour les newsbies...

      Brainfuck est ton ami.
      on trouve brainfuck là :
      http://www.muppetlabs.com/~breadbox/bf/(...)

      et un exemple de prog en brainfuck :
      #Echos whatever is typed until Alt 255 reached
      ,+[-.,+]

      trop puissant.

      J'aime particulièrementcelui-ci :
      http://www.muppetlabs.com/~breadbox/bf/factor.b.txt(...)

      je pense que chez c#, ils peuvent s'accrocher. ;-)

      Par contre j'aimerais réellement voir de quoi mono est capable. Y'a deja des applis réalisées ? y'a des exemples concrets?

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 1.

        À part monodoc, monodevelop et d'autres applis autour de Mono, pas grand chose...
        Enfin, http://www.monodevelop.org(...)

        • [^] # Re: Monavis à moi

          Posté par  . Évalué à 1.

          Quand mono va se diversifier,va s'alourdir de nombreuses fonctionnalites, ca va plomber les perfs GRAVE.

          Tout ceci n'est que pour faire perdre du temps en discussions inutiles. Ca me fait penser aux projets anterieur a XviD. Il y a de tres mauvais choix qui ont ete fait pour .Net, c'est une pure operation marketing a 2 balles qu'on nous fait la.

          Pourquoi autant de communication autours de Mono ? Y a pas le tier de communications autours des autres alternatives libres, qui bouffent du terrain a ne plus savoir qu'en faire a Microsoft ...

          L'argument de base "ha, mais ca va permettre au gens de passer + facilement sous Linux" est la plus grosse blague qui soit. Les "gens" vont surtout passer sous Long Claxon.

          Puis les arguments autours des perfos m'ont toujours fait pitier.

          • [^] # Re: Monavis à moi

            Posté par  . Évalué à 0.

            Quand mono va se diversifier,va s'alourdir de nombreuses fonctionnalites, ca va plomber les perfs GRAVE.
            J'ai jamais dit le contraire !
            J'espère juste qu'ils réussiront à éviter qu'il ne devienne inutilisable...

            Pour les perfs, à vrai dire je m'en fous aussi pas mal... Enfin, maintenant (depuis 1-2 ans) Mais le développeur débutant sous win il va lire les benchmarks, et il dit : "ho, ce langage est une daube il lui faut 0.12 seconde de plus que celui ci pour résoudre y'=ay+b !" alors que son programme il utilise pas la moindre fonction mathématique "évoluée"

            • [^] # Re: Monavis à moi

              Posté par  . Évalué à 2.

              J'ai constaté des délais de 5 secondes entre le clic sur un bouton et l'ouverture d'une connexion TCP procoquée par ce clic avec le .NET made in Redmond (j'ai même pu lancer le serveur après le clic). Ca ne me semble pas négligeable et n'a pas étonné outre mesure le prof qui me cotait.

      • [^] # Projets en C#

        Posté par  . Évalué à 4.

        Il y a F-Spot, un visualisateur d'images utilisant Gtk#, orienté apparemment vers la gestion de photos numériques : http://www.gnome.org/projects/f-spot/(...) (version très alpha ;)

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 4.

        Y a muine aussi qui est pas mal du tout http://muine.gooeylinux.org/(...)

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 2.

        y'a des exemples concrets?
        Je viens de tomber la-dessus : http://www.bitron.ch/software/nautilus-bitron-extensions.php(...)

    • [^] # Re: Monavis à moi

      Posté par  . Évalué à 3.

      Bonjour à tous,

      Connaissez-vous Gambas (un Basic pendant de VB sous linux) ?
      IDE, complétion, widgets Qt, encore pas finalisé à 100 % mais la version 1.0 est pour bientôt d'après leur user-list.

      Je ne suis pas programmeur de métier, mais je me suis écrit quelques petits utilitaires en quelques lignes à peine ..... et ça marche en plus !

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 1.

        Là on tombe aussi sur des problèmes...
        J'ai essayé Gambas, c'est un superbe logiciel, je suis tout à fait désolé de l'avoir oublié dans ma liste miniature. Néanmoins, Gambas manque de bindings vers d'autres librairies, et nécessite aussi un interpréteur, comme Mono... Malheureusement, il est moins répandu donc on verra moins souvent d'interpréteurs gambas installés que de mono.
        Mais oui, n'oublions pas Gambas, écrit par un français en plus je crois...

        • [^] # Re: Monavis à moi

          Posté par  . Évalué à 9.

          je vais pousser un peu plus loin ma façon de voir les choses concernant Gambas.

          Contrairement à la majorité des gens qui fréquentes ces pages, je suis ce que l'on appel un end-user, un newbie, ou ce que vous voudrez. J'ai fais mais premières sur linux il y a 3 ans à peine, d'abord par curiosité puis, au fil du temps, par adhésion au principe du libre. Il va sans dire que la qualité des logiciels que j'utilise au quotidien (graphisme, bureatique, etc...) a suffit à éradiquer Windows de ma machine.

          Puis vient le jour où, à force de se retouver dans une situation d'utilsateur passif (je download, j'installe, j'utilise), on a aussi envie de faire profiter les autres de ses maigres connaissances et de faire que la palette de choix en matière de logiciel s'etoffe un peu plus. Pourquoi ne pas apporter sa pierre (ou son petit caillou :-) à l'édifice ?... Mais voilà : je voudrais écrire des petits (ou gros) utilitaires mais je ne suis pas programmeur (tout au plus passionné).
          Bien-sûr, à force de mettre les mains dans le cambouis, ont fini pas aligner quelques scripts shell, une ou deux moulinettes en Perl, mais guère mieux. Dès qu'il sagit de faire une belle appli avec une GUI, les choses se compliquent sérieusement. Après avoir essayé Glade, QTDesigner, c'est avec Gambas que j'ai fait mes plus gros progrès (intuitf, facile à comprendre, on peut faire beaucoup de choses en quelques lignes de code), et j'ai dans mes cartons une ou deux idées d'appli que je vais essayer de mettre en forme. C'est, à mon humble avis, l'environnement qui peut donner envie à un néophite de franchir le pas et essayer de rentrer dans la cour des grands par la petite porte ........

          Concernant mono, j'ai eu à faire à lui il n'y a pas plus tard qu'hier en essayant de recompiler une appli dont j'ai vraiment besoin ( le couple autopano-sift/hugin pour faire des panoramas photos). Galère, galère .... et échec. Les paquets mdk (pour ne pas la citer) m'ont renvoyés je ne sais combien de dépendances et j'ai passé 3 heures à faire urpmi àprès urpmi ( et un disque dur plombé de quelques dizaines Mo de plus) pour m'appercevoir que le dit programme a besoin du dernier mono en vigueur.
          Du coup, j'abandonne là. Me compiler à la main le fameux mono me donne déjà des sueurs ..... (il n'y a que des paquets RH9 et Fédora dispos,soit une trentaines paquets !)

          Voilà l'avis d'un end-user qui comprend pas toujours ce qui ce dit ici, mais qui de viens de faire son premier post sur cette liste....

          • [^] # Re: Monavis à moi

            Posté par  . Évalué à 2.

            NNooooon! N'bandonnes pas Mono comme cela :)
            Pour info on m'a signalé hier que les rpm pour le dernier Mono sont sur les repository de Cooker. Car effectivement, le compiler soi même c'est une horreur : moi, je me suis fait avoir et mon pc a souffert pendant 7h de compilation pour monodoc.
            Ajoute un média cooker par ex. à ton urpmi, et il s'occupera de tout pour le "dernier mono en vigueur". Tu peux aussi tester Monodevelop.
            Enfin bon, c'était juste une ptite info, en l'espérant utile.

            • [^] # Re: Monavis à moi

              Posté par  . Évalué à 1.

              Ajouter un repository cooker n'est pas, et de loin, la meilleure solution, loin de là!!!
              Le mieux est de pomper les .src.rpm de la cooker et de les recompiler, ce qui n'est pas une partie de plaisir, mais au moins tu obtiens des "vrais" rpms pour "ta" mandrake... Sinon, une bonne âme charitable aura eu la bienveillance de le compiler, non ? En cherchant un peu ça doit se trouver je pense

              • [^] # Re: Monavis à moi

                Posté par  . Évalué à 2.

                Ah oui, peut être qu'une âme charitable nous aura mâché le travail depuis... Ceci dit, quand moi j'ai voulu l'installer, il venait juste de sortir. Pas trop le choix donc!
                Cependant, pour des applis "non critiques", je ne pense pas que prendre un rpm cooker soit risqué.

                • [^] # Re: Monavis à moi

                  Posté par  (site web personnel) . Évalué à 1.

                  A mon avis, le problème est plus dans l'incohérence des dépendances que cela va entrainer : Mono semble avoir *beaucoup* de dépendance, et toutes celles-ci vont devoir être résolues. Or, j'ai toujours eu beucoup de problème avec Mandrake en utilisant plusieurs "niveau" de distrib (des source pour la stable et la cooker par ex).
                  Je crois que urpmi s'embrouille un peu les pinceaux dans ce cas (en même temps, ça fait assez longtemps que je n'ai pas utilisé de Mandrake, ça a peut être changé).

                  • [^] # Re: Monavis à moi

                    Posté par  . Évalué à 1.

                    J'ai pas remarqué de problèmes sur des mandrake récentes (9.2 et 10)

          • [^] # Re: Monavis à moi

            Posté par  . Évalué à 1.

            > Concernant mono, j'ai eu à faire à lui il n'y a pas plus tard qu'hier en essayant de recompiler une appli dont j'ai vraiment besoin ( le couple autopano-sift/hugin pour faire des panoramas photos). Galère, galère ....

            Malheureux :-)
            Le problème ici n'est pas mono mais simplement le packaging le plus monstrueux que l'on puisse faire. Les hugin a besoin des panorama tools qui ne sont plus maitenu depuis plus de 3 ans. Sachant quand plus l'auteur des panotools etait un boulet fini (genre il a oublie un .h dans la derniere release que j'ai mis 2h a trouver a quoi de google et d'autres trucs sympa).

            Bref sauf si tu te sens l'ame guerriere ne t'aventure pas de ce côté la. Je me suis cassé les dents à faire le package pour sourcemage. Si un jour j'ai le courage de finir le couple je mettrais quelque part comment arriver au bout du défi :-)

            Pour ce qui est de mono il n'est utile que pour autopano-sift et je pense que tu peux tres bien utilisé hugin sans en mourrir ! Cherche du cote de Debian ou le paquet est sympa.

        • [^] # Re: Monavis à moi

          Posté par  . Évalué à 2.

          Exact, c'est écrit par un Français.
          C'est super sympa comme truc (et ca ne veut pas être un clone de vb).
          Dommage que ca soit si peu répandu !

    • [^] # Re: Monavis à moi

      Posté par  . Évalué à 3.

      Franchement, python (que j'adore) souffre en terme de performances sur les grosses applis

      Psyco est ton ami! c'est un optimiseur python qui s'intercale entre ton code et l'interpreteur pour retranscrire le premier en code machine
      résultat : un code python 4 à 100 fois plus rapide (et souvent aussi rapide que du C pour des algos équivalents..)

      http://www-106.ibm.com/developerworks/linux/library/l-psyco.html(...)

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 0.

        c' est meme 42 fois plus rapide que de l'asm algos equivalent !

        tu serais pas un gentoo user toi des fois ?
        --
        gentoo user les marseillais du monde linux

    • [^] # Re: Monavis à moi

      Posté par  (site web personnel) . Évalué à 1.

      Tu parles de python, perl, ....

      Je suis aussi en cours de tâtage pour voir quelles languages prendre. Je souhaite quelque chose de portable, de rapide et de sympa à coder.

      Mono est une solution, mais j'avoue que j'ai l'impression de me lier à m$.
      Python est lent, il y a psyco, .... bof. Perl me semble avoir une grammaire horrible. Je pense me tourner verso OCaml. Vous en pensez quoi ?

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 2.

        Mon conseil : python (pas si lent que ça, si nécessaire utiliser psyco, mais c'est pas obligé). Sinon, en portable, y'en a pas des masses !
        Mais c'est pour faire quoi ?

        • [^] # Re: Monavis à moi

          Posté par  (site web personnel) . Évalué à 4.

          J'adore python pour les scripts.

          Mais pour des grosses applications, je ne suis pas convaincu. Quand je regarde GNUE, les contre-performances sont telles que cela en deviens pénible.

          • [^] # Re: Monavis à moi

            Posté par  . Évalué à 2.

            Regarde skencil ou Zope. En Python et pourtant rapides.
            Le problème de perfo avec Python, c'est de vouloir tout coder soi-même. Identifie les parties les plus sensibles aux perfos de ton code, puis utilise un module approprié : ils sont généralement bien plus rapides et résolvent ainsi ton problème.

            Richard

      • [^] # Re: Monavis à moi

        Posté par  (site web personnel) . Évalué à 2.

        OCaml est un très bon langage, avec plein d'avantages. Par exemple, c'est un langage fonctionnel, avec toute la puissance d'expressivité que cela entraine. Bon, évidemment ça demande un peu d'efforts pour comprendre comment ça marche, mais une fois aquis c'est vraiment très fort. Surtout que OCaml possède un systèmes de modules assez impressionnant (avec des foncteurs (modules paramétrés par d'autres modules), entres autres choses intéressantes).
        D'autre part, OCaml peut être soit soit compilé (en bytecode ou en code natif, donc portabilité et performances suivant ses besoins, d'autant plus que le compilo n'est pas mauvais du tout), soit interprété, ce qui permet de vérifier que son code est correcte au fur et à mesure du développement.
        Bref, un langage intéressant, ne serait-ce que parce qu'il change vraiment par rapport aux langages impératifs usuels.

        • [^] # Re: Monavis à moi

          Posté par  . Évalué à 2.

          Je vais pas faire l'éloge de OCaml, je suis grand fan! ;)

          Mais pour rester dans le topic, je me suis renseigné sur l'utilisation éventuelle de ocaml dans mono. Le résultat est que la machine virtuelle mono ne supporte pas plein de truc liés à caml qui feraient perdre à caml une grande partie de son interet... :(
          Domage car je trouve les deux très interessants, et j'avoue que si à terme faire une interface graphique se trouve être beaucoup plus simple dans un autre langage, je vais peut-être y réfléchir à deux fois...

          Question d'un gars qui n'y connais rien : puisque ocaml a sa propre machine virtuelle, ne serait-il pas possible de l'inclure à celle de mono pour qu'il n'y ai plus de problème?

          • [^] # Re: Monavis à moi

            Posté par  (site web personnel) . Évalué à 2.

            Tu peux bien sûr faires des propositions à l'ECMA pour le futur de la machine virtuelle qui peut être évolutive, comme elle a évoluer pour intégrer les generics (contrairement à celle de Java, parcque Sun préfère garder la compatibilité avec les vieilles VM)... Sinon regarde du côté de OCamIL.

            • [^] # Re: Monavis à moi

              Posté par  . Évalué à 2.

              Le problème est que je suis débutant, et en plus autodidacte. Je me vois mal faire des propositions au sujet d'un domaine auquel je ne m'y connais pas du tout...

              Pour ce qui est de OCamIL, ben... Je travaille plus du tout sous windows, et c'est donc mono qui m'aurais interessé. Mais l'avantage est que si Mono l'intègre aussi, alors on pourra les programmes pourront aussi bien tourner sous win que sous unix ;)

          • [^] # Re: Monavis à moi

            Posté par  . Évalué à 0.

            À la vue du "débat" me vient une question : quelqu'un connaît-il une page référençant les principaux langages existants avec une comparaison et du code d'exemple à la clé (1 hello world + 2-3 autres mini programmes) afin que l'on se fasse une idée de ce que vaut chaque langage ?
            Pour Caml, je ne m'exprime pas, je connais pas ce langage.
            Chaque langage a ses fans, tous de plus mauvaise foi les uns que les autres !

            • [^] # Re: Monavis à moi

              Posté par  . Évalué à 2.

              http://www.99-bottles-of-beer.net/(...)

              Attention, ce site n'est qu'un délire, et ne permet pas du tout de juger un langage (par exemple, en ocaml, il utilise une boucle for et effet de bord, alors qu'une fonction recursive aurait été bien plus adaptée).

              Le problème du Caml, c'est que ce sont probablement ses détracteurs qui sont le plus de mauvaise foi ;) Le premier devoir que j'ai du rentre en caml (que j'ai appris en math sup), je l'ai rendu en C, tellement je trouvais ce langage limité, sans interet, et casse-couille pour rien :p

          • [^] # Re: Monavis à moi

            Posté par  . Évalué à 1.

            Pour un "OCAML sous .Net", il faut regarder du côté de F#: http://research.microsoft.com/projects/ilx/fsharp.aspx(...) qui est une implémentation d'un langage fonctionnel assez proche de OCAML sous .Net. Ca marche, c'est assez performant, et c'est fait de manière plutôt carrée. Y'a aussi de la documentation technique pour se rendre compte de pourquoi ce n'est pas aussi simple que ça de porter un langage fonctionnel sur la VM de .Net.

      • [^] # Re: Monavis à moi

        Posté par  (Mastodon) . Évalué à 2.

        Python est lent

        Ça dépend du genre de programmes que tu veux faire. Parfois il est utile d'avoir le maximum de rapidité, mais ce n'est pas le cas si souvent que ça. Pour ma part j'utilise Ruby et j'en suis content. Ruby est assez lent, donc dans certains cas, je dois recoder des portions de mes algos en C, mais c'est rare.

      • [^] # Re: Monavis à moi

        Posté par  . Évalué à 1.

        OCAML c'est bien: un assez haut niveau d''expressivité, rapide, différents paradigmes de programmation.
        Les inconvénients: il faut se donner la peine de comprendre le typage, pas très facile pour programmer des interface graphiques (ça vient sans doute de moi)

        Python: excellent langage, je l'utilise tout les jours.
        c'est vrai qu'il est lent, mais pour la majorité des application ça n'est pas sensible.
        Et pour les applications qui le necessite, on utilise des libs. Résultat: on dévelppe rapidement, et on à un prog qui s'execute en temps raisonnable.

    • [^] # Re: Monavis à moi

      Posté par  . Évalué à 2.

      Pour l'auto-completion, emacs le fait aussi tres bien avec les packages semantic et intellisense, et il le fait pour tout un tas de langage dont Emacs Lisp, Java, C/C++, C#, Python.

      http://cedet.sourceforge.net/(...)

      • [^] # Re: Monavis à moi

        Posté par  (site web personnel) . Évalué à 4.

        Oué enfin quand tu lis la FAQ, tu te poses des question sur l'intérêt, j'aime bien la première :
        Q1) When I type the name of a struct or class and press "." nothing
        happens:
        A1) Nothing is supposed to happen when you press ".". you need to
        explicitly use the command `semantic-analyze-possible-completions'
        or (better) `semantic-ia-complete-symbol'.

        Vlà l'intérêt...

        A2) The context analyzer has a bug that requires at least on symbol
        character to appear after the "."

        En plus faut déjà connaître le début de la fonction désirée...

        Les autres Q/R me font dire qu'ils ont oublié le côté "intelli" du terme "intellisense" qu'ils expliquent au début...

        et faudra m'expliquer comment emacs il fait, même avec ces packages, pour déterminer ce qu'il y a dans un assembly .NET et proposer à l'utilisateur l'ensemble des méthodes applicables à un objet...
        Bref, c'est rigolo mais l'intérêt numéro 1 c'est d'être pratique, et là je suis pas du tout convaincu...

        • [^] # Re: Monavis à moi

          Posté par  (Mastodon) . Évalué à 2.

          Euh, la commande est faite pour être associée à une touche, très probablement ;-)

          Pour ma part j'utilise la completion très basique livrée en standard dans Emacs, qui me suffit, et je l'ai mappée sur une des touches de fonction.

          Après, pour proposer l'ensemble des méthodes applicables à un objet, Emacs doit faire comme les autres, se débrouiller avec ce qu'il a... Pour les langages qui savent faire de l'introspection, par exemple, ça doit être beaucoup plus facile. Pour les autres il faut comprendre le langage, mais c'est à peine plus dur que de la coloration syntaxique.

          • [^] # Re: Monavis à moi

            Posté par  (site web personnel) . Évalué à 2.

            Euh, la commande est faite pour être associée à une touche, très probablement ;-)
            C'est bien ce que je dis, celà perd tout son intérêt...

            Franchement, essai l'"intellisense" de MonoDevelop (qui n'est pas encore parfait), tu verras la différence :-)

            Emacs j'ai envi de dire qu'il est touche à tout et bon à rien... Mais on est bien content de le trouver quand on n'a pas d'environnement dédié...

  • # les quelques retours volés sur mono

    Posté par  . Évalué à 8.

    Après quelques impressions volés à quelques conversations, il apparaît clairement que mono est plus populaire auprès des personnes issues du monde M$ que des autres. Les questions suivantes se posent donc :
    " Que va apporter Mono ?, quels risques va t-il apporter ?"

    D'après les premiers échos il semblerait que la réponse la plus fréquente de "dotnetiste" : nous allons enfin pouvoir adresser la plate-forme Linux (sur un ton de conquête). Les personnes issues du monde linux étant plus réservées.

    Ceci amène à quelques questions :
    - Contrairement à beaucoups de rumeur prétendant à la supériorité de Windows. Il semblerait donc que Linux soit non seulement reconnu pas ses partisants actuels mais aussi par un certain nombre de developpeurs Windows séduits par les atout de cette plate-forme et n'attendant que la possibilité de pouvoir l'utiliser. Linux se trouve donc être une plate-forme cible pour l'avenir de tous, mono permettant peut-être de conquérir les développeurs windows.

    - Cette approche devrait amener rapidement les développeurs de la plate-forme windows à développer des applications multi-plateforme et assurer, par cette action, la démocratisation de la plate-forme Linux en tant que poste client.

    De nombreux langages existent sous linux, le framework Dotnet tend à définir un socle commun sous windows permettant une mutualisation entre les différents langages. Java n'a pas su s'imposer sur l'ensemble des environnments comme langage fédérateur sur le poste client pour de nombreuses raisons (Rusticité d'awt, lourdeur de swing, lancement au démarrage d'appli d'une JVM accaparant les ressources du poste... niveau des IDE en retrait (pour ce type d'appli) par rapport à des delphi ou visual studio...). Le processus de normalisation SUN est sans doute partiellement responsable, néanmoins il est évident que les applications sont plus lourde à développer sur notre plate-forme favorite que sous Windows.

    Utiliser mono comme socle, associé à qt ou gtk, peut sans doute permettre d'avancer plus rapidement en gardant toute la richesse de notre plate-forme, quelquesoit le langage utilisé sans pour autant adopter le référentiel de classe M$.

    • [^] # Re: les quelques retours volés sur mono

      Posté par  . Évalué à 1.

      Bon résumé, merci !
      Au moins, on se retrouve pas avec les combats entre pro- et anti- mono
      Il serait bon pour mono d'avoir des bindings pour KDE sinon il va pas être suffisamment bien intégré !
      Bon résumé pour les EDI ! Eternel combat entre les amoureux d'emacs et consorts et ceux qui préférent des environnements à la souris !

      Pour conclure :
      L'avenir devrait être radieux pour "notre" plateforme !

      • [^] # Re: les quelques retours volés sur mono

        Posté par  . Évalué à 2.

        Je salue également le résumé.
        Et réclame aussi un binding élégant vers Qt, d'une part parce que celui pour GTK exista déjà, d'autre part parce qu'à titre personnel je trouve Qt/KDE plus à même de fournir des interfaces attrayantes et "dans l'air du temps", pour l'instant en tout cas.

        • [^] # Re: les quelques retours volés sur mono

          Posté par  (site web personnel) . Évalué à 1.

          Pour un binding vers Qt, GTK et Windows, l'idéal serait d'utiliser .... XUL.

          Au moins, l'ergonome ou le graphiste (qui n'est pas toujours un codeur) n'aurait pas à se soucier de la plateforme de destination.
          Et pour développer une nouvelle implémentation vers un autre toolkit, ce serait d'autant plus facile (XUL comme référence "universelle" ??).

          • [^] # Re: les quelques retours volés sur mono

            Posté par  . Évalué à 2.

            Je crois que c'est ce qui est en train de se faire pour C# /Mono>> Qt/KDE, ça passe par KaXUL, le XUL de KDE. Le projet s'appelle Kimono.
            Ceci dit très peu de news du projet sont disponibles, on trouve seulement l'annonce du 1er avril, qui n'est pas un poisson.

          • [^] # Re: les quelques retours volés sur mono

            Posté par  . Évalué à 1.

            Enfin garder la même interface et changer totalement le toolkit sous-jacent dans un projet réel c'est pas réaliste (Sauf dans la phase du choix du toolkit/language mais à ce moment là on se contrefous de l'interface)

    • [^] # Pour le "pur libriste"

      Posté par  . Évalué à 1.

      D'un autre côté, pour l'utilisateur/concepteur de logiciel libre pas trop stupide, Mono n'apporte qu'un langage de plus, assez sympa à programmer il est vrai, et apporte une surcharge inutile avec la machine virtuelle puisque la possibilité de recompiler le code source nous apporte cette portabilité à moindre coût. La seule utilisation sensée d'une machine virtuelle est dans une utilisation genre applet java, où l'"exécutable" doit être fourni tel quel sans connaître l'OS sur lequel il tournera.

      Evidemment, en cas d'environnement hétérogène avec des systèmes propriétaires, rien de ce qui précède ne s'applique.

      • [^] # Re: Pour le "pur libriste"

        Posté par  . Évalué à 0.

        Moi j'ai trouvé la machine virtuelle de mono très rapide par rapport à ce que j'ai déjà vu pour Java, Python et autres...
        Après faut voir : si le langage est plus simple, tu peux coder des algos plus performants normalement.
        De même, si le langage gère seul la mémoire, le développeur gagne du temps, et peux optimiser son code ailleurs...
        Enfin, éternels combats entre les intégristes du C, du C++, du C#, du python, du perl, du java...

        • [^] # Re: Pour le "pur libriste"

          Posté par  . Évalué à 1.

          En terme d'interroperabilité, cela a également un avantage indiscutable. Je peux dev. un module dans un langage parce que : c'est plus pratique, je le préfère, .... .
          Ce morceau de code peut alors être réutilisé sous un autre langage, c'est déjà un premier intérêt.
          Dans un second temp, cela formalise des format d'interface standard permettant une normalisation de la plate-forme et une approche plus simple à appréhender en même temps.

          Je ne justifie pas mono, mais c'est une approche qu'il est maintenant nécessaire d'avoir afin d'améliorer l'accès à notre plate-forme.
          Mono est le premier à s'être jeter sur ce problème en prenant le modèle MS ...
          Il nous faut maintenant utiliser le meilleur de mono et ne pas utiliser le reste qui servira néanmoins à garantir l'interopérabilité entre Windows et linux et pourquoi pas faire du remoting.

          • [^] # Re: Pour le "pur libriste"

            Posté par  . Évalué à 0.

            Pardonnez moi ma méconnaissance de ce domaine !
            Qu'est-ce que du "remoting" ?

            • [^] # Re: Pour le "pur libriste"

              Posté par  . Évalué à 1.

              Pour appeler des composants entre diverses machines. On parlait à une époque de Corba, en Java c'est devenu iiop, et des mechanismes similaires existent de manière standardisée sous .dotnet (dcom). Ceci permet d'avoir des applis réparties sur plusieurs machines.

            • [^] # Re: Pour le "pur libriste"

              Posté par  . Évalué à 1.

              Dans le cas des VM (Java, .Net) c'est le procédé de communication mais aussi tout le système d'automatisation qui permets de pouvoir appeler les méthodes, propriétés et autres d'une instance de classe comme si elle était présente localement (Alors que le code est exécuté en réalité sur une machine distante)

      • [^] # Re: Pour le "pur libriste"

        Posté par  . Évalué à 1.

        Je ne vois pas ou est la différence avec java, si tu veux vraiment faire du code plateform dépendent dans les deux cas tu peux, il est évident que quant on parle de portabilitée c'est pour des programmes qui le veulent bien et dont les auteurs ont réfléchis aux implication et à comment faire.

        Penser qu'une plateforme (Java ou .Net) par son simple fait apporte l'interopérabilité est stupide, ça ne fait que la faciliter.

        • [^] # Re: Pour le "pur libriste"

          Posté par  . Évalué à 1.

          Il ne s'agit de dire que .net ou Java est interropérable. Mais qu'il s'agit de standardiser des couche de plus haut niveau que l'OS.
          C'est ce que font ou tentent tous les langages actuellement :
          - CPAN pour perl
          - PEAR pour PHP
          - le framework PYTHON
          - SUN avec les normalisation JAVA
          - ...

          Le seul apport de .NET dans ce cas est de permettre à chacun d'interropérer avec des composants écrits par d'autres dans différents langages.

          D'où l'intérêt d'une normalisation hors du langage et dispo de différents langages.

          Bien que supporter de JAVA et du libre, il y a là une véritable avancée et mono est sur cette trace.

          Il reste 2 solutions de mon point de vue :
          - reconstruire un autre système avec les mêmes apports
          - utiliser et supporter mono pour bénéficier des avantages sans céder à la tentation de tout reproduire (risque de se faire piégé à terme)

          Cette dernière solution permet cependant d'aller vite et de prendre de l'avance pour la prochaine marche ...

  • # Multi plate-forme ?

    Posté par  (site web personnel) . Évalué à 6.

    J'aimerai ici résumer un passage de l'interview de JC Cimetière , :) , de Microsoft France parue dans le numéro 58 du magazine Programmez. Cela me semble intéressant à bien des égards.

    Lorsqu'on lui demande qu'elle est la vision de MS du Multi Plate-forme, il explique que MS fait du multi plate-forme "du PDA au DATA Center". Autrement dit l'un des grand intérêt de .NET pour microsoft est de pouvoir porter facilement une application de Windows, à Windows CE, Smartphone...

    De plus il précise bien que le portage de .NET sous MacOS X et FreeBSD (ROTOR) à un objectif "éducatif", laissant explicitement entendre que microsoft ne support le développement .NET que sous Windows.

    Je pense que l'un des gros avantages de Mono sur .NET se trouve peut-être dans la possibilité de porter les applications
    sur un plus grand nombre de plate-forme. Cela peux séduire des entreprises désireuses de diversifier leur parc (par mesure de sécurité par exemple), des développeur Windows simplement soucieux de pouvoir rapidement sortir une version linux ou MAC si leurs clients la demande.

    N'oublions pas non plus le coût d'un Visual Studio ou d'un C# Builder si mono sait fournir un EDI intelligent et bien fait.

    Pour moi Mono a toutes les chances d'être un grand projet. Et de participer amplement au succes des Logiciels Libres (enfin on verra bien).

    Je rajouterai aussi, pour le troll, une petite citation tirée de la même interview (gniiiiiiiii) : "Nous avons de bonnes relations avec les auteurs du projet Mono, sans pour autant supporter ni encourager cette initiative."

    • [^] # Re: Multi plate-forme ?

      Posté par  . Évalué à 1.

      "Nous avons de bonnes relations avec les auteurs du projet Mono, sans pour autant supporter ni encourager cette initiative."

      Ils ont montrés par leurs actions qu'ils l'encouragent quand même un peu.
      Mais chez MSFT encourager doit s'écrire "encourager financièrement" donc c'est normal que ça ils ne le fassent pas :D :D :D

  • # information complementaire sur la future influence de .NET et JAVA

    Posté par  . Évalué à 1.

    je pense que mono n'oblige personne à l'utiliser, et qu'il est indispensable pour le futur du LL :

    un article de gartner sur .NET/JAVA très instructif, qui précise entre autre l'importance de .NET (et JAVA) et ce qu'il en est pour la partie normalisé par l'ECMA (40%).

    http://www.zdnet.fr/techupdate/infrastructure/0,39020938,39134264-1(...)

    bonne lecture :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.