Journal Brainstorming : mariage de C# et de Qt

Posté par (page perso) . Licence CC by-sa
7
23
août
2013

Bonjour à tous,

Depuis quelques temps, j'ai une idée qui me trotte dans la tête. Programmant depuis de nombreuses années, j'ai eu l'occasion d'utiliser deux techno qui m'ont particulièrement intéressées :
* le langage C#, pour sa syntaxe claire et ses différents sucres syntaxiques
* le framework Qt, avec sa portabilité, sa clarté et son étendu.

Mon idée consisterait à reprendre la syntaxe du C# et à remplacer l'API de base du langage par le framework Qt.

Mon objectif n'est pas non plus de faire un énième langage (même si en fait, il s'agit d'en reprendre un existant) et qu'il ne soit pas utilisé, mais de répondre à une problématique précise : la portabilité.

En effet, l'implémentation officielle réalisée par Microsoft n'est disponible que sous Windows. Sous d'autres OS (Linux, Mac, …), le projet le plus abouti est sans aucun doute Mono. Si cette dernière implémentation
confère une très bonne compatibilité avec l'implémentation officielle, il y a malgré tout des différences. Par exemple, dernièrement, j'ai voulu faire mon propre dépôt Nuget. Impossible d'en avoir un fonctionnel avec le couple Apache/Mono alors que le même code fonctionne sans problème avec IIS.
La compatibilité est excellent tant qu'on ne fait que du code managé. Dès qu'on souhaite appeler des bibliothèques natives, on se heurte à des problèmes de portabilités (et ceci, même si la dite bibliothèque est portable).

Concernant l'idée en elle-même, elle me semble intéressante pour plusieurs raisons, et notamment :
* l'objectif initial sera la portabilité, qui dépendra de la portabilité de l'API utilisé, donc, de Qt ;
* Il y a beaucoup de concept commun entre l'API de base de C# et Qt (List et QList, String et QString, Dictionary et QMap, etc…). On pourrait donc avoir à quelques choses prêts les mêmes fonctionnalités ;
* les événements C# sont le pendant des signaux/slots Qt, mais en plus facile à utiliser ;
* un concept que je trouve très agréable en C# concerne les requêtes Linq, où comment écrire des requêtes sur des sources de données (base de données, collections, etc…) de manière fortement typée, avec vérification à la compilation et une syntaxe proche du SQL ;
* le support de async / await (nouveauté avec .Net 4.5), qui facilite grandement l'exécution de tâches asynchrones.

Après, il y a de nombreux aspects techniques auxquelles j'ai commencé à réfléchir, mais avant de faire des choix (par exemple, langage compilé ou vm), je pense qu'avoir un retour sur l'idée même du projet pourrait être intéressant.

Par ce journal, j'en appelle donc à la communauté. Est-ce que cela vous semble une bonne idée ? Avez-vous des suggestions d'améliorations ? Si un tel projet existait aujourd'hui, est-ce que cela répondrait à certains de vos besoins et l'utiliseriez-vous ?

  • # Idées

    Posté par (page perso) . Évalué à 4.

    Pourquoi ne pas faire un binding de Qt pour Vala et le nommer Qt Cambi ?

    http://devnewton.bci.im

    • [^] # Re: Idées

      Posté par . Évalué à 3.

      ``> deux techno qui m'ont particulièrement intéressées :
      * le langage C#, pour sa syntaxe claire et ses différents sucres syntaxiques
      * le framework Qt, avec sa portabilité, sa clarté et son étendu.

      ok, fair enough.

      https://wiki.gnome.org/Vala/About : The syntax of Vala is similar to C#, modified to better fit the GObject type system.

      jusqu'ici je suis…

      http://qt-jambi.org/ : Qt Jambi is the Qt library made available to Java

      j'ai du louper un épisode, éclairez moi svp.

      • [^] # Re: Idées

        Posté par . Évalué à 2.

        Qt Cambi != Qt Jambi !!!

        Toutes mes confuses, je ne devrais pas commenter à 4h du matin.

    • [^] # Re: Idées

      Posté par (page perso) . Évalué à 2.

      J'avais pensé à Vala. Par contre, je ne connaissais pas Qt Jambi.

      Vala, même s'il est proche de C#, en est différent sur plusieurs aspects syntaxique. Et n'est pas aussi utilisé que le C#. Ensuite, je ne pense pas qu'un simple binding soit faisable. Qt est un framework composé de bibliothèques et d'outils pour les utilisers (notamment moc). Via un binding, je ne vois pas comment faire le mapping entre les signaux qt et les événements C# / Vala, ou même intégrer les mots-clés async / await.

      L'idéal, serait qu'une personne connaissant C# et Qt puisse utiliser ce projet sans apprentissage.

      Après, comme dis dans le journal, pour l'instant, ce n'est qu'une simple idée que je commence à peine à l'explorer !

  • # Ça semble pharaonique

    Posté par . Évalué à 3.

    Si je ne m'abuse, tu veux aller beaucoup plus loin qu'un simple binding: tu veux former un nouveau tout bien intégré avec des modifs des 2 côtés!

    Ça me rappelle un fil de discussion sur les bindings pour OCaml où un des intervenants disait que tôt ou tard, il faudra un nouveau framework graphique fait sur mesure pour OCaml (orienté fonctionnel, tout ça). Et je me suis dit "rien que ça!?".
    Mais lui ne parlait pas de modifier OCaml.

    C'est sûr, une nouvelle alternative, c'est toujours bon à prendre. Mais en même temps, je me dis que une seule personne même à plein temps pendant des années n'arrivera pas à quelque chose à la hauteur de ce qu'on a aujourd'hui (regarde les EFL, le travail autour de Qt, les moyens que MS avait mis sur C#, etc.).

    Soi je me trompe et tu ne veux pas "tout" changer, soit je me demande si tu as une idée de ce qui t'attend en terme de volume de travail.

    Sinon, il existe déjà un binding Qt pour C#, si je ne m'abuse (aucune idée de son état, vu que je ne programme pas en C#, et que je ne programme que de façon anecdotique tout court d'ailleurs)

    • [^] # Re: Ça semble pharaonique

      Posté par (page perso) . Évalué à 1.

      Si je ne m'abuse, tu veux aller beaucoup plus loin qu'un simple binding: tu veux former un nouveau tout bien intégré avec des modifs des 2 côtés!

      Tout à fait ! Mon idée serait que Qt ne soit pas une bibliothèque de plus disponible, mais la bibliothèque de base à utiliser. Et, ce qu'un simple binding ne pourra pas faire, que les concepts de Qt soient directement mappé à la syntaxe des concepts en C# (gestion des événements, async / await, etc…)

      C'est sûr, une nouvelle alternative, c'est toujours bon à prendre. Mais en même temps, je me dis que une seule personne même à plein temps pendant des années n'arrivera pas à quelque chose à la hauteur de ce qu'on a aujourd'hui (regarde les EFL, le travail autour de Qt, les moyens que MS avait mis sur C#, etc.).

      C'est vrai. C'est pour cela que dans mon étude préliminaire, je n'envisage pas de modifier l'un ou l'autre, mais essayer de faire une glue pour en prouver le concept et la viabilité. Ensuite, éventuellement, je pourrais essayer de chercher des financements et des contributeurs :)

      Soi je me trompe et tu ne veux pas "tout" changer, soit je me demande si tu as une idée de ce qui t'attend en terme de volume de travail.

      Justement, je ne veux rien changer à Qt, ni à la syntaxe C#. Je comptais même me baser sur un parser C# déjà existant (d'où l'intérêt de ne pas modifier le langage !), comme celui de Mono ou peut-être celui de MonoDevelop (j'ai lu qu'il était plus facile d'utilisation, il faut que j'approfondisse le sujet).

      Sinon, il existe déjà un binding Qt pour C#, si je ne m'abuse (aucune idée de son état, vu que je ne programme pas en C#, et que je ne programme que de façon anecdotique tout court d'ailleurs)

      Oui, il en existe même plusieurs. Mais la dernière fois que j'ai regardé, il semblait plus ou moins mort… Par contre, je viens de voir qu'il semble y avoir un regain d'intérêt pour Qyoto !

  • # Qyoto

    Posté par (page perso) . Évalué à 2.

    Je ne sais pas si c'est exactement ce que tu veux ni même si ce projet fonctionne toujours, mais il existe des bindings Qt/.NET:

    http://techbase.kde.org/Development/Languages/Qyoto

    • [^] # Re: Qyoto

      Posté par (page perso) . Évalué à 1.

      Je connaissais Qyoto, mais il me semblait que c'était un projet abandonné. Il faut croire qu'il connait un regain d'intérêt depuis fin 2012.

      Mais comme je le disais, ce n'est pas un simple binding qui m'intéresse, mais bien une intégration de Qt au niveau du C#. Qyoto par exemple, n'intègre pas la gestion des signals/slots via les événements en C#, il garde le même mécanisme qu'en Qt, c'est à dire via la fonction connect.

  • # Bof

    Posté par . Évalué à 2.

    Tu va fragmenter l'écosystème C# de la même manière que Qt à déjà fragmenté l'écosystème C++ en refusant d'utiliser ou de migrer vers la bibliothèque standard et normalisée du langage.

    Même si sur le coup, ça sera toujours mieux d'avoir une API Qt orienté objet dans un langage purement orienté objet comme C# plutôt que d'avoir une API purement orienté objet dans un langage qui n'a pas été fait pour, et qui du coup utilise le langage d'une manière totalement non-naturelle en jetant en l'air des années de bonnes pratiques.

    • [^] # Re: Bof

      Posté par (page perso) . Évalué à 2.

      Tu va fragmenter l'écosystème C# de la même manière que Qt à déjà fragmenté l'écosystème C++ en refusant d'utiliser ou de migrer vers la bibliothèque standard et normalisée du langage.

      Je ne pense pas que cela fragmentera l'écosystème C#. C#/Qt sera un langage à part entière qui aura la particularité d'avoir la même syntaxe que le langage C#. Mais les binaires C# ne seront a priori pas compatible avec les binaires C#/Qt et vice-versa, pour des raisons de portabilité.

      Sur ce point, ce projet se différencie donc de Qt qui était une bibliothèque pour C++ utilisable avec d'autres bibiothèques C++. Là, il s'agit de créer un nouvel écosystème.

      Je sais que cela peut paraitre ambitieux et le fait de ne pas envisager de compatibilité entre des binaires C# et C#/Qt risque d'être un frein pour le projet, mais je pense que la portabilité aura ce prix : il faut se débarrasser de la bibliothèque actuelle du C# (d'où mon idée de la remplacer par le framework Qt). Et qui dit changement d'API C#, dit forcément impossibilité d'utiliser des bibliothèques écrites en C#.

      • [^] # Re: Bof

        Posté par . Évalué à 8.

        Je ne pense pas que cela fragmentera l'écosystème C#. C#/Qt sera un langage à part entière qui aura la particularité d'avoir la même syntaxe que le langage C#. Mais les binaires C# ne seront a priori pas compatible avec les binaires C#/Qt et vice-versa, pour des raisons de portabilité.

        Donc tu fragmente l'écosystème C# en deux, CQFD.

        Si jamais quelqu'un veut écrire une bibliothèque en C#, il va devoir choisir entre le C# normalisé et le C# avec une bibliothèque non standard, sachant que quelqu'un qui utilise le C# normalisé ne pourra pas utiliser du code qui viens de l'autre écosystème et inversement.

        Sur ce point, ce projet se différencie donc de Qt qui était une bibliothèque pour C++ utilisable avec d'autres bibiothèques C++. Là, il s'agit de créer un nouvel écosystème.

        Qt n'est pas qu'une bibliothèque, c'est aussi un générateur de code et un système de build. Mais même sur sa partie bibliothèque, il réimplémente toute la bibliothèque standard C++ en moins bien, et si tu veux utiliser une bibliothèque qui utilise Qt dans du code qui utilise majoritairement la bibliothèque standard (ou inversement), ce n'est certes pas impossible de mixer les deux, mais en pratique c'est beaucoup de glue chiante à écrire pour rien, qui peut casser facilement si tu ne prend pas en compte les différences qu'ont les deux environnements sur les namespaces, les exceptions et la gestion de la mémoire.

        C'est assez pour te dissuader de mixer les deux, et à la place, réimplémenter la fonctionnalité de la bibliothèque dans ton coin. D'ou une fragmentation entre du C++ standard et du C++/Qt.

        • [^] # Re: Bof

          Posté par (page perso) . Évalué à -1.

          Donc tu fragmente l'écosystème C# en deux, CQFD.

          En te lisant, je constate qu'on n'entend pas tout à fait la même chose par fragmentation de l'écosystème C#. Pour toi, la fragmentation correspond à l'aspect technique (en simplifiant grandement, 2 compilateurs C# au lieu d'un et non compatible entre eux). Pour moi, j'entendais fragmentation de l'écosystème dans le sens "communautaire". Et là, ce n'est pas une fragmentation de l'écosystème puisque le public visé ne se limite pas à ceux faisant du C#. Je comprends fragmentation comme une séparation d'une communauté, comme ce qui s'est passé lors de la création du fork LibreOffice lors du rachat de Sun par Oracle par exemple.

          Si jamais quelqu'un veut écrire une bibliothèque en C#, il va devoir choisir entre le C# normalisé et le C# avec une bibliothèque non standard, sachant que quelqu'un qui utilise le C# normalisé ne pourra pas utiliser du code qui viens de l'autre écosystème et inversement.

          Non. S"il quelqu'un veut écrire une bibliothèque C#, il fera du C#. Point. C# = Syntaxe + API. Ce que je propose, c'est de créer un langage reprenant la syntaxe du C# et utilisant l'API de Qt. Ensuite, s'il veut écrire une bibliothèque, il aura le choix entre C#, Java, C++, Afa, PHP, Ruby, Python, Javascript, biduletrucmuche, etc…

          Qt n'est pas qu'une bibliothèque, c'est aussi un générateur de code et un système de build.

          Et c'est bien pour cela qu'un simple binding ne me parait pas la solution, mais qu'il faille une intégration plus poussée au sein d'un langage permettant un développement plus rapide qu'en C++. Et là, j'ai choisi de reprendre la syntaxe du C#.

          Mais même sur sa partie bibliothèque, il réimplémente toute la bibliothèque standard C++ en moins bien, et si tu veux utiliser une bibliothèque qui utilise Qt dans du code qui utilise majoritairement la bibliothèque standard (ou inversement), ce n'est certes pas impossible de mixer les deux, mais en pratique c'est beaucoup de glue chiante à écrire pour rien, qui peut casser facilement si tu ne prend pas en compte les différences qu'ont les deux environnements sur les namespaces, les exceptions et la gestion de la mémoire.

          Et c'est une autre raison pour laquelle je souhaite créer un nouveau langage et non un simple binding (et non, je ne réagirais pas sur la remarque trollesque que Qt fait ça moins bien que la bibliothèque standard puisque là c'est bien loin du sujet initial ;)).

        • [^] # Re: Bof

          Posté par (page perso) . Évalué à 4.

          A noter un détail important que tu omets, lorsque tu parles de la fragmentation entre le C++ et le C++/Qt et qu'il est important de souligner, c'est que malgré cette "fragmentation", Qt répond à un besoin et il est le seul de sa catégorie.

  • # pourquoi virer l'API standard de C# ?

    Posté par . Évalué à 3.

    Si je comprends bien, ce que tu veux au final, c'est faire une bibliothèque (voire bibliothèque slash framework) pour C# qui intègrerait des concepts C# et Qt (donc plus loin qu'un binding). Si je reformule, ce serait une couche intermédiaire entre C# et Qt, et tu imagines que ça serait intéressant de virer toutes les autres API de C# de manière à ce qu'il ne reste plus que ta couche vers Qt. Là par contre, je ne comprends carrément plus.

    Je trouve que l'idée de base est bonne (une bibliothèque C# pour Qt), mais je ne comprends pas le besoin de virer le reste. Il y a plein de choses couvertes par l'API C# qui ne le sont pas par Qt, ça me semble dommage de faire un RAZ de l'API (d'ailleurs tu ne justifies pas pourquoi tu veux te débarrasser de l'API actuelle de C#).

    En tout cas, ça me semblerait plus facile à intégrer dans un environnement de développement en tant que bibliothèque additionnelle que comme "langage" (ça n'en serait pas un vraiment puisque ça reste du C#), incompatible avec le reste du monde (en l'occurrence, incompatible avec C++ ET avec le C# standard).

    • [^] # Re: pourquoi virer l'API standard de C# ?

      Posté par (page perso) . Évalué à 1.

      Si je comprends bien, ce que tu veux au final, c'est faire une bibliothèque (voire bibliothèque slash framework) pour C# qui intègrerait des concepts C# et Qt (donc plus loin qu'un binding). Si je reformule, ce serait une couche intermédiaire entre C# et Qt, et tu imagines que ça serait intéressant de virer toutes les autres API de C# de manière à ce qu'il ne reste plus que ta couche vers Qt

      Tout à fait

      En tout cas, ça me semblerait plus facile à intégrer dans un environnement de développement en tant que bibliothèque additionnelle que comme "langage" (ça n'en serait pas un vraiment puisque ça reste du C#), incompatible avec le reste du monde (en l'occurrence, incompatible avec C++ ET avec le C# standard).

      Mais dans ce cas là, je ne pourrais pas aller aussi loin que je le souhaite en terme d'intégration.

      Je trouve que l'idée de base est bonne (une bibliothèque C# pour Qt), mais je ne comprends pas le besoin de virer le reste. Il y a plein de choses couvertes par l'API C# qui ne le sont pas par Qt, ça me semble dommage de faire un RAZ de l'API (d'ailleurs tu ne justifies pas pourquoi tu veux te débarrasser de l'API actuelle de C#).

      C'est un point sur lequel j'ai longuement réfléchi, et voici des éléments de réponse :
      - d'un point de vue technique, même si je n'ai pas encore tranché en terme de méthode de fonctionnement (compilation, utilisation d'une machine virtuelle, etc…), le plus simple me semble être la compilation, avec génération de code C++ à partir de ce nouveau langage pour pouvoir utiliser ensuite n'importe quel compilateur C++. Je sais qu'il est possible d'appeler du code managé depuis du code natif et vice-versa, mais le projet est déjà de bonne envergure et je préfère donc m'abstraire de cela pour le moment.
      - d'un point de vue de l'homogénéité. L'objectif est d'avoir un ensemble homogène et bien intégré. Si je garde l'API de base du C# alors il y aura 2 API existantes. Dans ce cas, autant faire un binding.

      Je ne dis pas que dans un second temps il n'y aura pas certaines API C# qui ne seraient pas portées (par exemple, Linq). Mais je pense qu'il faut procéder étape par étape.

  • # mouaich

    Posté par (page perso) . Évalué à 5.

    Dès qu'on souhaite appeler des bibliothèques natives, on se heurte à des problèmes de portabilités (et ceci, même si la dite bibliothèque est portable).

    Je ne vois absolument pas en quoi t'appuyer sur Qt va t'aider à résoudre ce problème.
    C# possède au contraire un des rares systèmes pour faire des appels à des bibliothèques natives de façon portable (sans glue façon java) grâce aux PInvoke : tu n'as même pas besoin de recompiler ton code managé qui appelle ta lib native. Evidemment ca suppose que ta lib soit effectivement portable à travers une interface C indépendante de la plateforme (ex : OpenGL).

    langage compilé ou vm

    C# est un langage compilé et nécessite obligatoirement une VM pour fonctionner : introspection, gestion de la mémoire, gestion des exceptions, etc.
    Il peut même être précompilé en code natif avant exécution : les services de la VM sont toujours présents à l'exécution.

    En fait ton problème, c'est pas la portabilité, ce sont des problèmes d'incompatibilité entre 2 implémentations. Dans ton exemple un problème de compatibilité entre Apache/Mono et IIS/.NET.

    Créer une nouvelle plateforme (ce que tu proposes puisque ca ne sera pas 100% du C# ni 100% du Qt) est une fausse solution : si demain quelqu'un fork et que tu te retrouves avec 2 implémentations t'auras les mêmes soucis.

    • [^] # Re: mouaich

      Posté par (page perso) . Évalué à 0.

      Je ne vois absolument pas en quoi t'appuyer sur Qt va t'aider à résoudre ce problème.
      Microsoft .Net et Mono sont deux implémentations différentes, dont l'une est incomplète. Qt est une seule et unique implémentation portable. Je pense que cela peut aider.

      Ce qui serait bien, c'est que ce soit comme pour Ada. Pour qu'un compilateur puisse dire qu'il compile de l'Ada, il a tout une batterie de tests à passer.

      C# possède au contraire un des rares systèmes pour faire des appels à des bibliothèques natives de façon portable (sans glue façon java) grâce aux PInvoke

      C'est une erreur. Le C# permet de faire cela simplement, pas "portablement" (désolé pour le néologisme). Un exemple : un programme qui doit pouvoir tourner à la fois en 32 bits et en 64 bits. Pas de pot : obligé de faire 2 implémentations différentes à l'aide de PInvoke pour que cela fonctionne. C'est simple certes, mais certainement pas portable. Je précise : expérience vécue.

      C# est un langage compilé

      Pour ce type de langage (comme le C# ou le Java), j'aime bien parler de langage cross-compilé :) On compile pour une machine qui n'est pas la machine de compilation.
      Et là, j'entendais compilé "en natif". Mais j'avoue ne pas avoir précisé. Mea culpa.

      C# est un langage compilé et nécessite obligatoirement une VM pour fonctionner : introspection, gestion de la mémoire, gestion des exceptions, etc.

      Il me semble que le projet Mono permette de compiler en code natif et de s'abstraire complètement de la VM. C'est d'ailleurs ainsi qu'ils peuvent compiler une application pour iPhone écrite en C# et la publier, puisque Apple interdit les VM.

      En fait ton problème, c'est pas la portabilité, ce sont des problèmes d'incompatibilité entre 2 implémentations. Dans ton exemple un problème de compatibilité entre Apache/Mono et IIS/.NET.

      Qui génère des problèmes de portabilités. CQFD.

      Et c'est pourquoi je voudrais proposer une implémentation portable, qui ne nécessiterait pas une autre implémentation pour tenter d'assurer la portabilité (cas de Mono vis-à-vis du framework .Net).

      Créer une nouvelle plateforme (ce que tu proposes puisque ca ne sera pas 100% du C# ni 100% du Qt) est une fausse solution : si demain quelqu'un fork et que tu te retrouves avec 2 implémentations t'auras les mêmes soucis.

      C'est vrai. Mais le fork est intrinsèquement lié au libre :) Donc, dès qu'on fait du libre, il y a toujours le "et si demain quelqu'un fork". Demain, quelqu'un peut forker Qt, Mono, Linux, KDE, LibreOffice, etc… mais pour l'instant, on en n'est pas là, puisque le projet n'est qu'un… projet !

      • [^] # Re: mouaich

        Posté par (page perso) . Évalué à 7.

        Ce qui serait bien, c'est que ce soit comme pour Ada. Pour qu'un compilateur puisse dire qu'il compile de l'Ada, il a tout une batterie de tests à passer.

        Le problème ce n'est pas le langage : il y a une batterie de tests également pour C#. Le problème c'est les bibliothèques. Même avec toute les batteries de tests du monde, vu la taille et le nombre d'API, on ne peut passer à côté d'incompatibilités.

        Il me semble que le projet Mono permette de compiler en code natif et de s'abstraire complètement de la VM. C'est d'ailleurs ainsi qu'ils peuvent compiler une application pour iPhone écrite en C# et la publier, puisque Apple interdit les VM.

        Une VM est… virtuelle. Elle n'existe pas. Ce qui compte, c'est le comportement à l'exécution. Et là il existent pleins de techniques pour "simuler" le comportement de la VM : en général c'est un mix d'interprétation, de compilations et de bibliothèques de services (GC & co). Certaines VM se prêtent bien à des techniques de compilation à la volée, d'autres sont fortement limitées à l'interprétation.

        La VM .NET sur laquelle s'appui C# a été conçu pour que techniquement on puisse compiler en code natif l'exécutable avant exécution, histoire de gagner du temps au démarrage (effet de bord : passer outre les restrictions Apple).
        Le reste des services (GC, sécurité, introspection, etc.) est fournis par des bibliothèques qui sont chargées en même temps que le programme, comme c'est d'ailleurs le cas pour le C++ qui nécessite aussi une sorte de "runtime" pour certaines fonctionnalités (exceptions par exemple).

        Donc oui, Mono fait de la compilation en code natif sur iPhone, .NET le fait aussi sous Windows et Mono sait aussi le faire sous Linux : c'est de la compilation Ahead-Of-Time (AOT).
        Même dans le mode plus "classique" façon Java (Just-In-Time (JIT)), c'est le même processus qui se passe : compilation en code natif. La seule différence, c'est que dans un cas c'est fait avant l'exécution et l'autre pendant.

        Qui génère des problèmes de portabilités. CQFD.

        Super, et avec ta solution, je vais appeler une bibliothèque native de IIS, tu vas pas avoir le même problème pour porter ton appli sur Apache ?

        Et c'est pourquoi je voudrais proposer une implémentation portable, qui ne nécessiterait pas une autre implémentation pour tenter d'assurer la portabilité

        Si Mono existe, c'est aussi pour avoir une alternative sous licence "libre" : donc Mono se fait chier à recoder toutes les libs qui sont non-libres, même si elles sont techniquement portables.

        En fait pour résoudre ton problème, t'as qu'à simplement ignorer l'implémentation de Microsoft : voilà, t'as Mono, c'est portable.

        C'est vrai. Mais le fork est intrinsèquement lié au libre :)

        Fork ou implémentation alternative, et t'auras exactement le même soucis que MS.NET/Mono.
        C#/.NET est techniquement une plateforme portable. Les incompatibilités viennent de l'existance de plusieurs implémentations et de choix politiques/économiques de licences de diffusion. Tu résoudras pas ce soucis par une solution technique.

        • [^] # Re: mouaich

          Posté par (page perso) . Évalué à 1.

          Le problème ce n'est pas le langage : il y a une batterie de tests également pour C#. Le problème c'est les bibliothèques. Même avec toute les batteries de tests du monde, vu la taille et le nombre d'API, on ne peut passer à côté d'incompatibilités.

          C'est l'essence même des tests. Ils sont toujours incomplets. Malgré cela, ils permettent de détecter nombre d'incompatibilités. Pour en revenir à Ada, je n'ai jamais eu un comportement différent d'un programme compilé par deux compilateurs différents et / ou tournant dans deux environnements différents (dont de l'embarqué). Ce qui n'est pas le cas avec le couple Mono/Microsoft .Net en restant sur du desktop.

          Une VM est… virtuelle. Elle n'existe pas.

          Autant je suis entièrement d'accord avec toi lorsque tu parles du fonctionnement des VM et des runtimes, autant je ne comprends absolument pas cette phrase. Je m'abstiendrais donc de faire le moindre commentaire dessus et préfère attendre que tu me l'expliques :)

          Super, et avec ta solution, je vais appeler une bibliothèque native de IIS, tu vas pas avoir le même problème pour porter ton appli sur Apache ?

          Là, tu triches. Tu génères des problèmes de portabilités en utilisant, de base, une bibliothèque non portable, alors qu'à la base le problème vient d'une différence de comportement entre deux implémentations de la même API. Ce n'est absolument pas le même problème.

          En fait pour résoudre ton problème, t'as qu'à simplement ignorer l'implémentation de Microsoft : voilà, t'as Mono, c'est portable.

          Sympa la solution. Donc, on change l'implémentation par défaut sous Windows ? Effectivement, cela peut résoudre des problèmes pour une application donnée. Mais quid des applications qui ne fonctionnement pas avec Mono ? Ou alors faut-il demander à l'ouverture de chaque programme l'environnement à utiliser ? Celui de Microsoft ou celui de Mono ?

          C#/.NET est techniquement une plateforme portable. Les incompatibilités viennent de l'existance de plusieurs implémentations et de choix politiques/économiques de licences de diffusion. Tu résoudras pas ce soucis par une solution technique.

          Sauf que ce que je cherche à résoudre, ce n'est pas les problèmes de portabilité entre MS.NET/Mono. C'est le problème de l'utilisation de Qt (car je trouve que c'est un excellent Framework) avec un langage ayant une syntaxe "légère" à la C# en opposition à la "lourdeur" du C++.

          Il est vrai que j'ai mis en avant la portabilité, mais ceci simplement pour assurer que ce nouveau langage soit portable. Si fork ou implémentation alternative il y a, il y aura sans doute des incompatibilités entre deux implémentations différentes. Mais pour le moment, il n'y a aucune implémentation de la solution que je propose et donc se focaliser sur ce type d'incompatibilités me semble limite hors sujet.

          • [^] # Re: mouaich

            Posté par (page perso) . Évalué à 2.

            Je m'abstiendrais donc de faire le moindre commentaire dessus et préfère attendre que tu me l'expliques :)

            Une VM existe essentiellement sur le papier, par opposition à une machine "physique". D'où la présence de briques logiciels pour simuler le comportement de la VM sur une machine "physique".

            Là, tu triches. Tu génères des problèmes de portabilités en utilisant, de base, une bibliothèque non portable, alors qu'à la base le problème vient d'une différence de comportement entre deux implémentations de la même API. Ce n'est absolument pas le même problème.

            Disons que j'avais surtout aucune idée si ton problème venait d'un problème technique au niveau du serveur (IIS vs Apache) ou au niveau des API Nuget serveur que tu utilises.

            Sympa la solution. Donc, on change l'implémentation par défaut sous Windows ?

            Pourquoi ?

            Mais quid des applications qui ne fonctionnement pas avec Mono ?

            Bah justement : tu t'en fou. Comme avec ta solution : ne marcherons que les softs prévus pour marcher avec.

            Ou alors faut-il demander à l'ouverture de chaque programme l'environnement à utiliser ? Celui de Microsoft ou celui de Mono ?

            C'est au loader de l'OS de faire ce taf. T'as qu'à inventer une extension (.myexe) et l'associer à myruntime qui n'est qu'un raccourci vers mono si vraiment tu veux éviter toute confusion.

            Mais pour le moment, il n'y a aucune implémentation de la solution que je propose et donc se focaliser sur ce type d'incompatibilités me semble limite hors sujet.

            Ben c'est un peu l'objectif initial que t'affiche :)

            C'est le problème de l'utilisation de Qt (car je trouve que c'est un excellent Framework) avec un langage ayant une syntaxe "légère" à la C# en opposition à la "lourdeur" du C++.

            Ok. Donc maintenant : quel va être l'intérêt de Qt pour le programmeur C# habitué à son Framework de base ?

            • [^] # Re: mouaich

              Posté par (page perso) . Évalué à 2.

              Une VM existe essentiellement sur le papier, par opposition à une machine "physique". D'où la présence de briques logiciels pour simuler le comportement de la VM sur une machine "physique".

              Ok. Je comprends mieux ce que tu voulais dire. Donc, quand tu dis qu'une VM n'existe pas, c'est n'existe pas physiquement. C'est plus compliqué que cela. Java a été conçu pour fonctionner dans une machine virtuelle. Puis Sun à développer une spécification de processeur PicoJava. L'objetif : que le bytecode soit le jeu d'instruction natif de la machine virtuelle… qui ne serait donc plus virtuelle !

              Pourquoi ?
              C'est au loader de l'OS de faire ce taf. T'as qu'à inventer une extension (.myexe) et l'associer à myruntime qui n'est qu'un raccourci vers mono si vraiment tu veux éviter toute confusion.

              Idée intéressante qui ne m'a même pas effleuré l'esprit. Je cours me flageller…

              Ben c'est un peu l'objectif initial que t'affiche :)

              J'affiche l'idée d'avoir une implémentation. Pas deux. Donc parler de problèmes qui surgiraient dans le cas où il y aurait deux implémentations me semble un peu prématuré :)

              Ok. Donc maintenant : quel va être l'intérêt de Qt pour le programmeur C# habitué à son Framework de base ?

              L'intérêt n'est pas tant pour le programmeur C#. Il est plutôt pour les utilisateurs de Qt :)

              • [^] # Re: mouaich

                Posté par (page perso) . Évalué à 2.

                L'objetif : que le bytecode soit le jeu d'instruction natif de la machine virtuelle… qui ne serait donc plus virtuelle !

                Oui, virtuellement c'est faisable ;)
                Ce que je voulais surtout mettre en évidence, c'est que tu ne dois pas te poser la question "VM ou compilé" : l'un décrit le modèle sur lequel s'appui le programmeur, l'autre une technique pour rendre le code exécutable.

                A partir du moment où tu va vouloir reprendre le langage C# et ses principaux idiomes (async, lambda, linq, gc, securité), tu vas forcement devoir définir une VM. Après libre à toi de choisir une technique pour rendre le bousin exécutable.

                L'intérêt n'est pas tant pour le programmeur C#. Il est plutôt pour les utilisateurs de Qt :)

                Ok, donc l'objectif n'est plus de résoudre les problèmes de portabilité, pas non plus de proposer un nouveau Framework aux dev C# mais de proposer un nouveau langage aux dev Qt.
                Bah fait un binding :)

                Qyoto était pas si pourri, mais visiblement ca n'intéresse pas grand monde.
                Et y'avait bien un mécanisme pour passer d'un event à un slot si je me réfère aux exemples par là :
                http://zetcode.com/gui/csharpqyoto/widgets/

                • [^] # Re: mouaich

                  Posté par (page perso) . Évalué à 1.

                  Oui, virtuellement c'est faisable ;)
                  Ce que je voulais surtout mettre en évidence, c'est que tu ne dois pas te poser la question "VM ou compilé" : l'un décrit le modèle sur lequel s'appui le programmeur, l'autre une technique pour rendre le code exécutable.

                  Assez primaire dans mon esprit, je fais malgré tout une distinction relativement simple : interprété / compilé à la volée -> VM. Après, cela n'empêche effectivement pas d'avoir un runtime qui offre des services lors de l'exécution.

                  A partir du moment où tu va vouloir reprendre le langage C# et ses principaux idiomes (async, lambda, linq, gc, securité), tu vas forcement devoir définir une VM. Après libre à toi de choisir une technique pour rendre le bousin exécutable.

                  VM, non. runtime oui ;)

                  Qyoto était pas si pourri, mais visiblement ca n'intéresse pas grand monde.
                  Et y'avait bien un mécanisme pour passer d'un event à un slot si je me réfère aux exemples par là :

                  Je m'y étais intéressé un peu il y a un an. Mais devant le peu d'activité du projet à l'époque, j'en avais conclus qu'il était mort. Mais il semblerait qu'il ait connu un regain d'activité en 2013.

                  Sinon, concernant la gestion des événements, je n'avais pas vu ces exemples. Seulement des exemples à base de Connect (à la qt donc). Je me souviens que cela m'avait choqué car je me disais qu'il était faisable assez simplement de lié les deux. C# génère par défaut une implémentation de l'ajout / retrait de listener sur un événement qu'il est extrêmement facile de surcharger.

                  Quoi qu'il en soit, je sais que je vais regarder Qyoto de plus près d'ici peu. Car j'ai commencé à plancher un peu sur le problème et je rencontre déjà des problématiques que Qyoto doit déjà résoudre.

                  • [^] # Re: mouaich

                    Posté par (page perso) . Évalué à 2.

                    je fais malgré tout une distinction relativement simple : interprété / compilé à la volée -> VM

                    Sous Windows, .NET s'amuse à précompiler les programmes .NET en code natif et les garde en cache pour les prochaines exécution, il n'y a alors pas d'interprétation ou de compilation à la volée : .NET c'est avec ou sans VM alors ?

                    Quoi qu'il en soit, je sais que je vais regarder Qyoto de plus près d'ici peu. Car j'ai commencé à plancher un peu sur le problème et je rencontre déjà des problématiques que Qyoto doit déjà résoudre.

                    Franchement, ca me paraît beaucoup plus raisonnable que d'essayer de faire un nouveau truc qui mix C# et Qt : déjà qu'un binding c'est complexe, et tu gardes pourtant tous les outils existants des 2 mondes, mais une nouvelle plateforme from scratch où tout est à refaire…

                    • [^] # Re: mouaich

                      Posté par (page perso) . Évalué à 1.

                      Sous Windows, .NET s'amuse à précompiler les programmes .NET en code natif et les garde en cache pour les prochaines exécution, il n'y a alors pas d'interprétation ou de compilation à la volée : .NET c'est avec ou sans VM alors ?

                      La compilation en natif est mise en cache à la première exécution et c'est une optimisation de la VM. Dans ma catégorisation, cela reste donc avec une VM car le développeur ne distribue pas le résultat issu de la compilation à la volée, mais un "bytecode".

                      Franchement, ca me paraît beaucoup plus raisonnable que d'essayer de faire un nouveau truc qui mix C# et Qt : déjà qu'un binding c'est complexe, et tu gardes pourtant tous les outils existants des 2 mondes, mais une nouvelle plateforme from scratch où tout est à refaire…

                      C'est pour cela que je ne souhaite pas repartir from scratch. Ou alors il faudrait tout une équipe dès le départ ! Pour l'instant, j'étudie. On verra ensuite après cette phase préliminaire et l'évaluation du temps nécessaire pour obtenir un premier jet pouvant service de Proof of Concept :)

                      • [^] # Re: mouaich

                        Posté par (page perso) . Évalué à 2.

                        Dans ma catégorisation, cela reste donc avec une VM car le développeur ne distribue pas le résultat issu de la compilation à la volée, mais un "bytecode".

                        Sauf que le développeur peut tout à fait lancer le process manuellement grâce à une simple ligne de commande (ngen monprogramme.exe) : il peut le faire dans son setup par exemple, où sur sa machine de dev…
                        Si pour toi la notion de VM se limite à la façon dont le binaire est déployé, c'est vraiment une définition bien à toi :)

Suivre le flux des commentaires

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