• # Idées

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

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

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # 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  (site web personnel) . Évalué à 5.

          Pour Vala, ça pourrait même être Qt Valmy!

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Ç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)

  • # Qyoto

    Posté par  (site web personnel) . É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

  • # 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.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # 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.

  • # 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).

  • # mouaich

    Posté par  (site web personnel) . É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.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 0.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: mouaich

        Posté par  (site web personnel) . É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.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: mouaich

            Posté par  (site web personnel) . É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 ?

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: mouaich

                Posté par  (site web personnel) . É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/

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 1.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: mouaich

                    Posté par  (site web personnel) . É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…

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 1.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: mouaich

                        Posté par  (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.