Raah tu changes de pseudo mais c'est toujours du même niveau tes propos.
Je ne cherches pas à défendre MS, je n'aime pas leur politique mono-plateforme, je n'aime pas leur politique de brevet, c'est pas pour autant que toutes les technos qu'ils concoivent sont pourris et que rien ne mérite de l'attention. http://en.wikipedia.org/wiki/Common_Language_Infrastructure "The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures."
C'est un environnement conçu dès le départ pour être portable, c'est un fait, que ca te plaise ou non. Que MS ne veuille pas porter son implémentation, c'est son problème, et ce troll ne m'intéresse pas, je parle de logiciel libre, de linux, de mono, de standards, de technique.
Toi tu nous ressors ton vomi traditionnel anti-MS là où c'est pas le sujet, qui est je te le rappel les bindings C# pour Qt. C# est un standard, qui s'appui sur une infrastructure ouverte, standard et parfaitement implémentée sous Linux, on peut se cantonner à ce périmètre sans que tu vomisse sur une implémentation proprio pour un OS proprio non ?
Qt est multiplateformes
Qt propose des briques qui ne sont pas portable et même pas libre, c'est une infime partie qui ne remet pas en cause l'intérêt de Qt, mais qui mérite critique quand on propose cette solution sur LinuxFR il me semble.
montre à quel point il est dangereux d'utiliser des technologies liés à Microsoft.
A part montrer que tu sais même pas FUDer correctement, tu montres pas grand chose.
J'ai pourtant cru être clair : les tests "non formels" apporteront un degré de confiance dans ce cas précis, là où la méthode formelle ne te donnera aucun degré. C'est ON/Off : prouvé/pas prouvé. Ca marche tout le temps, ou pas. Y'a pas de milieu. Ben dès fois la spec elle dit qu'il faut que ca marche 95% du temps dans des conditions normales d'utilisation. Ben ca la méthode formelle peut pas m'aider.
car comme par hasard les technos "portables" de Microsoft ce ne sont jamais eux qui les portes
MS a porté Silverlight sur Mac.
Quand ils veulent, ils peuvent.
Mais bon on est d'accord que Mono a du retard sur l'implémentation des bibliothèques disponibles dans .NET. Mais c'est pas un problème de technique, c'est essentiellement un problème de moyen.
Ca m'intéresse pas de discuter de ça, là on parle pas des bibliothèques de .NET mais de la bibliothèque Qt et de son utilisation dans Mono.
"aiT WCET Analyzers statically compute tight bounds for the worst-case execution time (WCET) of tasks in real-time systems"
C'est bien ce que je dis, si t'as pas la contrainte OS temps réel, t'es bien avancé.
Quelle différence entre une vérification formelle et un test, ici ?
Les tests de performance et d'endurance vont te permettre d'obtenir un degré de confiance en mesurant le temps de réponse.
Si tu joues le jeu de la vérification formelle, tu démonteras juste que ce n'est pas prouvable. T'es bien avancé.
Je te souhaite bien du courage pour expliquer d'où vient le problème à ton client ! (sa spec et pas ton code)
C'est tout le problème des clients qui ne savent pas ce qu'ils veulent :)
Je commençais à comprendre que ton client ne faisait pas des avions :)
Oué bah on en revient toujours à la base : en dehors des domaines où la sécurité est primordiale, en général personne se fait chier à atteindre le niveau de spécification formelle nécessaire à l'utilisation de ces méthodes de vérification.
Y'a 2 trucs qui limite la portabilité dans .NET :
- une raison technique : certains API s'appui sur des libs Windows et sont donc difficilement portable. Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple. Après ca ne concerne pas grand chose dans .NET, voir quasiment rien. Le problème est ailleur, voir ci-dessous.
- une raison commerciale : la licence de l'implémentation de .NET ne permet pas de réutiliser les composants sur autre chose qu'un OS Windows. Ca pu c'est pas libre. C'est pas pour ca que c'est pas portable. Et c'est ce que fait Mono : elle propose une implémentation alternative libre sans limitation de plateforme.
Mais techniquement je le répète, le socle technique de .NET/Mono est parfaitement portable. Y'a une abstraction de tout : les instructions machines, la mémoire, les threads, etc.
Et c'est bien de technique dont on parle ici quand on parle de binding. Et on est sur LinuxFR, donc on s'intéresse à Mono, qui est une plateforme portable ET portée.
Je veux bien discuter, mais faut argumenter alors.
En quoi le socle technique/C# n'est pas portable ?
En quoi MS ne respecte pas du tout la norme ISO correspondante ?
Je suis d'accord qu'il faut laisser la communauté développer les bindings dont elle a besoin.
Mais Nokia pourrait tout de même faire un truc de base qui intéresserait tout le monde : un binding C officiel et maintenu. Ca simplifierait les bindings dans tous les langages.
Je ne critiques pas la portabilité de Qt en soit, je critique juste la doc de Nokia qui préconise des solutions non portables (et pas open-source au passage) pour faire un binding dans un langage pourtant portable.
Attend c'est pas de ma faute si Nokia conseille ces méthodes non portable sur son site officiel : http://doc.trolltech.com/4.5/activeqt-dotnet.html
Moi aussi je trouve ca fort de café que les équipes de Nokia conseille d'utiliser des glues non portables pour utiliser un framework portable, mais j'invente rien, c'est eux qui l'écrivent hein.
Tu as perdu quoi ?
Tu as perdu la possibilité de prouver quoique ce soit, puisque sur un OS non temps-réel tu n'as strictement aucune garantie sur la disponibilité des ressources.
Pourquoi tu sous entends que la solution formelle serait moins bonne alors ?
J'ai jamais dis ca, je dis juste que la solution formelle a trop de contraintes fortes et qu'elle n'est pas applicable dans certains cas, auquel cas il faut bien faire une autre forme de test.
Bien sur qu'elle valide les specs !
Si la spec contient une erreur, le fait de formaliser la spec va peut être t'aider à trouver l'erreur, mais en aucun cas la méthode formelle en soit ne garantie que tu vas trouver ces erreurs.
C'est pas parcque tu as réussi à formaliser les specs que les specs sont valides. Ca veut juste dire que l'humain qui les as interprétés n'a pas trouver de problème lors de la formalisation. Si ca se trouve le client c'est mal exprimé et ton logiciel vas pas faire ce qui est prévu, va savoir !
En rédigeant la spec formelle tu identifies immédiatement tous les manques et précision à demander à ton client !
N'importe quoi. Tu peux identifier certains manques et certaines imprécisions, mais tu ne peux pas identifier toutes les erreurs dans les specs. Si la spec dit que le volant doit être dans le coffre de la voiture, c'est peut être tout à fait valide techniquement mais totalement abhérent du point de vue utilisateur. Et là si tu fais pas des tests d'ergonomie...
Quand à demander au client, c'est un doux rêve, souvent le client il veut pas tout formaliser, parcque ca supposerait qu'il réfléchisse sur ses besoins... hors il a en parti fait appel à tes services pour que tu l'aide dans cette tâche de formalisation. C'est con mais c'est comme ca dans la vraie vie, souvent tu te buttes face à un client qui ne veut pas répondre (pas le temps ou ne sais pas trancher) et tu dois faire des choix.
Ce qui est quand même hallucinant, c'est que je te donne un exemple concrêt de binding portable, que j'utilise de manière portable, bref la vraie vie, et tu trouves le moyen de dire que je dis n'importe quoi.
C'est .net qui devrait être ouvert est capable d'incorporer l'existant sans avoir à ajouter des extensions dans un langage ou limiter son utilisation à quelques fonctionnalités,
Tu lis ce que je mets ou quoi ?
.NET permet le même niveau de réutilisation de l'existant que tous les autres langages comme Java ou Python. Ces derniers ont exactement les mêmes problème que .NET pour faire des bindings sur des API C++ et sont obligés de passer par une couche de glue.
Ce qui n'est pas portable, c'est les surcouches intermédiaire écrites en C/C++ que propose d'utiliser Nokia : COM ou C++/CLI. Pas le binding en soit.
Donc voilà, y'a moyen, comme en PyQt ou Jambi de faire des bindings portables pour Qt, c'est Qyoto, et Nokia ne veut pas s'y intéresser. (ce que je ne critique pas, c'est leur choix).
ok donc tu n'as pas lu les suggestions du lien principal
ok donc t'as pas lu ou bien compris ce que j'ai mis :
"méthode également conseillée par la quadraturedunet"
Si je prône l'utilisation d'un produit bio plus respectueux de la nature, et si trois connards insultent les utilisateurs d'un produit concurrent qui pollue, est-ce qu'il faut déconseiller l'utilisation du produit bio ?
Non mais il faut déconseiller d'utiliser les mêmes méthode que les 3 connards. Ca c'est une meilleure comparaison.
C'est comme on peut être anti-OGM et ne pas cautionner le défonçage d'un MacDo.
J'ajouterai que le socle technique de .NET/Mono normalisé ISO propose une méthode pour écrire des bindings bien plus portable qu'en Java par exemple.
Par exemple pour la bibliothèque sqlite, qui est une lib qui expose "correctement" ses API binaires, le binding .NET/Mono est écrit en C# et est parfaitement portable (même pas besoin de recompiler, juste à s'arranger pour qu'il y est sqlite.so à la place de sqlite.dll).
Mais tout ca suppose des API binaires portables et standardisés, ce que n'offre pas C++ avec son foutu nommage à la con des méthodes. http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_(...)
net, de mon point de vue, est une solution propriétaire née suite à un désaccord entre deux grands acteurs de l'informatique contemporaine.
Ce dont je te parle, c'est du modèle technique pour appeler des libs natives depuis la machine virtuelle implémentée dans .NET. C'est spécifié, standardisé et normalisé ISO.
Qt est portable, je ne crois pas que ce soit discutable (?)
la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre. C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
Si les solutions que propose Nokia ne s'appliquent pas à Mono, c'est que Mono se contente d'implémenter .NET, et pas les briques non portables qu'ils proposent d'utiliser : COM ou C++/CLI.
Et c'est le même problème pour tous les langages, pas seulement Mono, en Python on peut attaquer un composant COM, donc celui de Qt, et c'est exactement le même problème : ca ne tournera que sous Windows. C'est pas pour rien que PyQt existe de la même manière qu'il y a Qyoto.
Le support de .Net est très inégal entre l'implémentation de Microsoft et l'implémentation de Mono.
D'où l'idée d'utiliser des frameworks comme Qt dont l'implémentation de référence elle-même est portable.
Ca marche très bien avec GTK+mono, parcque l'implémentation de référence de GTK est portable.
Y'a 3 façons d'utiliser des bibliothèques "natives" en .NET :
- si la bibliothèque est bien conçu et exporte des API "plats" portables, les bindings se font de manière portable, directement en C#. Cas de la plupart des bibliothèques C.
- si la bibliothèque exporte ses API en C++, point de salut : il faut se coltiner de la glue en C++, soit pour exporter un API plat facilement utilisable avec la solution précédente (c'est ce que fait Qyoto), soit directement en utilisant une variante de C++ capable d'intéragir avec les 2 environnements (pas portable comme langage).
- si la bibliothèque exporte ses API à travers une interface COM, directement en C# en créant un binding automatiquement. Pas portable non plus.
En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.
Je penses que ce qui provoque cette satisfaction, c'est le sentiment du "devoir" accompli en réalisant cet acte citoyen qui demande beaucoup d'engagement personnel (ironie inside).
La satisfaction vient également de la propagation du phénomène comme une mode auprès des geeks acquis à la cause. Au début j'ai trouvé ca super génial comme initiative, j'ai inscrit l'url de linuxFR sur le site de la quadraturedunet, étant donné que je suis d'accord avec les idées "ant-HADOPI".
Mais c'est vrai qu'après avoir lu cette réflexion de Maître Eolas, ca m'a fait réfléchir : au final est-ce bien utile ? Pourquoi j'ai trouvé ca génial si l'effet recherché ne sera manifestement pas atteint ? Après tout c'est facile comme action, mais qui va vraiment cliquer sur les fameuses bannières noires pour voir de quoi il en retourne réellement ? Qui va se forcer à lire un article qu'il n'a pas envie de lire (sinon il serait déjà au courant et aurait déjà un point de vue bien arrêté sur le sujet) ?
Vu les effets qui risquent d'être quasi-nul, ca revient presque à enculer les mouches, et il y a sûrement des moyens plus pertinent d'agir (voir exemples que je donne plus bas). Autre exemples : les critiques toujours argumentées de Maître Eolas.
Que les choses soient clair : je suis en accord avec le fait que cette loi est une grosse merde liberticide.
C'est pas pour autant qu'il ne faut pas accepter aucune critique sur les moyens mis en oeuvre pour propager cette idée.
J'essai juste de comprendre la réaction de Maître Eolas, et effectivement son point de vue (et son expérience en matière juridique) montre les limites de ce genre d'actions, à commencer par un effet quasi-nul sur le but recherché (la suppression du projet de loi).
y'a peut être des moyens plus efficace, comme contacter son député par exemple (ce qui revient à faire du mini-lobbying, méthode également conseillée par la quadraturedunet), ou troller avec des amis , ce qui est toujours plus efficace je penses que d'afficher un logo noir négatif sur un site, la plupart des gens ne cliquant jamais sur les banières de ce type.
Sinon j'aime bien ce thème black de LinuxFR, j'espère qu'il restera après :)
C'est une manif numérique.
Et c'est bien connu, la France et ses manifs est beaucoup plus avancé que les autres pays. Et encore, une manif ca a un impact souvent plus important car est généralement lié à une grève avec des impacts économiques.
Bref, peut être que Maître Eolas a raison et que c'est pas forcement le meilleur moyen de servir la cause anti-HADOPI.
Mais je penses que ca provoque y a un certain sentiment d'autosatisfaction chez les convaincus.
Un peu comme les partis d'extrême gauche qui crient à la révolution et tente désespérement d'agir sans que l'effet se fasse ressentir concrêtement dans les urnes.
Garanti par la théorie du temps réel
Si t'as pas d'OS temps réel, t'as perdu.
Nullement garanti par des tests.
Personne n'a dit que les tests offraient de garanties.
Fallacieux car Il n'y pas de specification formelle (juste une informelle pour ça).
Bienvenu dans la vraie vie ! Je dirais que la grande majorité des spécifications logicielles telles qu'exprimées par le client sont informelles, incomplètes ou insuffisantes, et c'est ma principale remarque initiale. Toutes les tentatives de formalisation à partir de ces specs (specs détaillées, specs formelles puis pre-post conditions) passent par une interprétation humaine de specs informelle, et c'est là que le test reste utile. Tu es obligé de rédiger un cahier de tests, tu peux le faire valider par le client pour voir s'il est conforme à ses attentes, tu le soumets aux équipes de validation qui vont y jeter un regard humain et y déceler des erreurs d'interprétation, y ajouter leur interprétation, etc.
Un valideur formelle ne valide pas les specs, d'où l'intérêt de mon exemple qui n'a strictement rien de fallacieux, et qui au contraire me paraît très réaliste.
Pour tout état du programme, la police affiché (l'affichage fait partie de l'état) est celle de l'environement.
Je te pari que t'es incapable de prouver une telle propriété.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.
Je ne cherches pas à défendre MS, je n'aime pas leur politique mono-plateforme, je n'aime pas leur politique de brevet, c'est pas pour autant que toutes les technos qu'ils concoivent sont pourris et que rien ne mérite de l'attention.
http://en.wikipedia.org/wiki/Common_Language_Infrastructure
"The specification defines an environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures."
C'est un environnement conçu dès le départ pour être portable, c'est un fait, que ca te plaise ou non. Que MS ne veuille pas porter son implémentation, c'est son problème, et ce troll ne m'intéresse pas, je parle de logiciel libre, de linux, de mono, de standards, de technique.
Toi tu nous ressors ton vomi traditionnel anti-MS là où c'est pas le sujet, qui est je te le rappel les bindings C# pour Qt. C# est un standard, qui s'appui sur une infrastructure ouverte, standard et parfaitement implémentée sous Linux, on peut se cantonner à ce périmètre sans que tu vomisse sur une implémentation proprio pour un OS proprio non ?
Qt est multiplateformes
Qt propose des briques qui ne sont pas portable et même pas libre, c'est une infime partie qui ne remet pas en cause l'intérêt de Qt, mais qui mérite critique quand on propose cette solution sur LinuxFR il me semble.
montre à quel point il est dangereux d'utiliser des technologies liés à Microsoft.
A part montrer que tu sais même pas FUDer correctement, tu montres pas grand chose.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
MS a porté Silverlight sur Mac.
Quand ils veulent, ils peuvent.
Mais bon on est d'accord que Mono a du retard sur l'implémentation des bibliothèques disponibles dans .NET. Mais c'est pas un problème de technique, c'est essentiellement un problème de moyen.
Ca m'intéresse pas de discuter de ça, là on parle pas des bibliothèques de .NET mais de la bibliothèque Qt et de son utilisation dans Mono.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
C'est bien ce que je dis, si t'as pas la contrainte OS temps réel, t'es bien avancé.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Les tests de performance et d'endurance vont te permettre d'obtenir un degré de confiance en mesurant le temps de réponse.
Si tu joues le jeu de la vérification formelle, tu démonteras juste que ce n'est pas prouvable. T'es bien avancé.
Je te souhaite bien du courage pour expliquer d'où vient le problème à ton client ! (sa spec et pas ton code)
C'est tout le problème des clients qui ne savent pas ce qu'ils veulent :)
Je commençais à comprendre que ton client ne faisait pas des avions :)
Oué bah on en revient toujours à la base : en dehors des domaines où la sécurité est primordiale, en général personne se fait chier à atteindre le niveau de spécification formelle nécessaire à l'utilisation de ces méthodes de vérification.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 3.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 4.
- une raison technique : certains API s'appui sur des libs Windows et sont donc difficilement portable. Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple. Après ca ne concerne pas grand chose dans .NET, voir quasiment rien. Le problème est ailleur, voir ci-dessous.
- une raison commerciale : la licence de l'implémentation de .NET ne permet pas de réutiliser les composants sur autre chose qu'un OS Windows. Ca pu c'est pas libre. C'est pas pour ca que c'est pas portable. Et c'est ce que fait Mono : elle propose une implémentation alternative libre sans limitation de plateforme.
Mais techniquement je le répète, le socle technique de .NET/Mono est parfaitement portable. Y'a une abstraction de tout : les instructions machines, la mémoire, les threads, etc.
Et c'est bien de technique dont on parle ici quand on parle de binding. Et on est sur LinuxFR, donc on s'intéresse à Mono, qui est une plateforme portable ET portée.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.
En quoi le socle technique/C# n'est pas portable ?
En quoi MS ne respecte pas du tout la norme ISO correspondante ?
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à -3.
C'est pas une idée, une pensée, c'est un fait. Le socle technique de .NET/C# est portable.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
Mais Nokia pourrait tout de même faire un truc de base qui intéresserait tout le monde : un binding C officiel et maintenu. Ca simplifierait les bindings dans tous les langages.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
http://doc.trolltech.com/4.5/activeqt-dotnet.html
Moi aussi je trouve ca fort de café que les équipes de Nokia conseille d'utiliser des glues non portables pour utiliser un framework portable, mais j'invente rien, c'est eux qui l'écrivent hein.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Tu as perdu la possibilité de prouver quoique ce soit, puisque sur un OS non temps-réel tu n'as strictement aucune garantie sur la disponibilité des ressources.
Pourquoi tu sous entends que la solution formelle serait moins bonne alors ?
J'ai jamais dis ca, je dis juste que la solution formelle a trop de contraintes fortes et qu'elle n'est pas applicable dans certains cas, auquel cas il faut bien faire une autre forme de test.
Bien sur qu'elle valide les specs !
Si la spec contient une erreur, le fait de formaliser la spec va peut être t'aider à trouver l'erreur, mais en aucun cas la méthode formelle en soit ne garantie que tu vas trouver ces erreurs.
C'est pas parcque tu as réussi à formaliser les specs que les specs sont valides. Ca veut juste dire que l'humain qui les as interprétés n'a pas trouver de problème lors de la formalisation. Si ca se trouve le client c'est mal exprimé et ton logiciel vas pas faire ce qui est prévu, va savoir !
En rédigeant la spec formelle tu identifies immédiatement tous les manques et précision à demander à ton client !
N'importe quoi. Tu peux identifier certains manques et certaines imprécisions, mais tu ne peux pas identifier toutes les erreurs dans les specs. Si la spec dit que le volant doit être dans le coffre de la voiture, c'est peut être tout à fait valide techniquement mais totalement abhérent du point de vue utilisateur. Et là si tu fais pas des tests d'ergonomie...
Quand à demander au client, c'est un doux rêve, souvent le client il veut pas tout formaliser, parcque ca supposerait qu'il réfléchisse sur ses besoins... hors il a en parti fait appel à tes services pour que tu l'aide dans cette tâche de formalisation. C'est con mais c'est comme ca dans la vraie vie, souvent tu te buttes face à un client qui ne veut pas répondre (pas le temps ou ne sais pas trancher) et tu dois faire des choix.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 2.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 3.
Tu lis ce que je mets ou quoi ?
.NET permet le même niveau de réutilisation de l'existant que tous les autres langages comme Java ou Python. Ces derniers ont exactement les mêmes problème que .NET pour faire des bindings sur des API C++ et sont obligés de passer par une couche de glue.
Ce qui n'est pas portable, c'est les surcouches intermédiaire écrites en C/C++ que propose d'utiliser Nokia : COM ou C++/CLI. Pas le binding en soit.
Donc voilà, y'a moyen, comme en PyQt ou Jambi de faire des bindings portables pour Qt, c'est Qyoto, et Nokia ne veut pas s'y intéresser. (ce que je ne critique pas, c'est leur choix).
[^] # Re: Efficace ?
Posté par TImaniac (site web personnel) . En réponse au journal Maître Eolas se positionne contre le Blackout. Évalué à 1.
ok donc t'as pas lu ou bien compris ce que j'ai mis :
"méthode également conseillée par la quadraturedunet"
[^] # Re: Efficace ?
Posté par TImaniac (site web personnel) . En réponse au journal Maître Eolas se positionne contre le Blackout. Évalué à 3.
Non mais il faut déconseiller d'utiliser les mêmes méthode que les 3 connards. Ca c'est une meilleure comparaison.
C'est comme on peut être anti-OGM et ne pas cautionner le défonçage d'un MacDo.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 5.
Par exemple pour la bibliothèque sqlite, qui est une lib qui expose "correctement" ses API binaires, le binding .NET/Mono est écrit en C# et est parfaitement portable (même pas besoin de recompiler, juste à s'arranger pour qu'il y est sqlite.so à la place de sqlite.dll).
Mais tout ca suppose des API binaires portables et standardisés, ce que n'offre pas C++ avec son foutu nommage à la con des méthodes.
http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_(...)
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à -1.
Ce dont je te parle, c'est du modèle technique pour appeler des libs natives depuis la machine virtuelle implémentée dans .NET. C'est spécifié, standardisé et normalisé ISO.
Qt est portable, je ne crois pas que ce soit discutable (?)
la critique sous-jacente, c'est les API C++. Binairement, des API C++ ne sont pas portable d'un compilateur à l'autre, alors ne parlons même pas d'une plateforme à l'autre. C'est ce qui fait qu'on est obligé dans tous les bindings de se taper une couche de glue pour contourner le problème.
Qt propose les solutions de glue les plus crades : celles qui ne sont pas portable, ce qui est quand même balo pour un framework portable.
mono est censé être un substitue donc les solutions que propose Nokia, même si elles ne te plaises pas, devraient pouvoir s'appliquer pour mono.
Si les solutions que propose Nokia ne s'appliquent pas à Mono, c'est que Mono se contente d'implémenter .NET, et pas les briques non portables qu'ils proposent d'utiliser : COM ou C++/CLI.
Et c'est le même problème pour tous les langages, pas seulement Mono, en Python on peut attaquer un composant COM, donc celui de Qt, et c'est exactement le même problème : ca ne tournera que sous Windows. C'est pas pour rien que PyQt existe de la même manière qu'il y a Qyoto.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à -1.
D'où l'idée d'utiliser des frameworks comme Qt dont l'implémentation de référence elle-même est portable.
Ca marche très bien avec GTK+mono, parcque l'implémentation de référence de GTK est portable.
[^] # Re: Qyoto/Kimono
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Qt 4.5. Évalué à 1.
- si la bibliothèque est bien conçu et exporte des API "plats" portables, les bindings se font de manière portable, directement en C#. Cas de la plupart des bibliothèques C.
- si la bibliothèque exporte ses API en C++, point de salut : il faut se coltiner de la glue en C++, soit pour exporter un API plat facilement utilisable avec la solution précédente (c'est ce que fait Qyoto), soit directement en utilisant une variante de C++ capable d'intéragir avec les 2 environnements (pas portable comme langage).
- si la bibliothèque exporte ses API à travers une interface COM, directement en C# en créant un binding automatiquement. Pas portable non plus.
En gros l'équipe Qt propose sur ton lien... les 2 solutions non portables.
[^] # Re: Efficace ?
Posté par TImaniac (site web personnel) . En réponse au journal Maître Eolas se positionne contre le Blackout. Évalué à 3.
La satisfaction vient également de la propagation du phénomène comme une mode auprès des geeks acquis à la cause. Au début j'ai trouvé ca super génial comme initiative, j'ai inscrit l'url de linuxFR sur le site de la quadraturedunet, étant donné que je suis d'accord avec les idées "ant-HADOPI".
Mais c'est vrai qu'après avoir lu cette réflexion de Maître Eolas, ca m'a fait réfléchir : au final est-ce bien utile ? Pourquoi j'ai trouvé ca génial si l'effet recherché ne sera manifestement pas atteint ? Après tout c'est facile comme action, mais qui va vraiment cliquer sur les fameuses bannières noires pour voir de quoi il en retourne réellement ? Qui va se forcer à lire un article qu'il n'a pas envie de lire (sinon il serait déjà au courant et aurait déjà un point de vue bien arrêté sur le sujet) ?
Vu les effets qui risquent d'être quasi-nul, ca revient presque à enculer les mouches, et il y a sûrement des moyens plus pertinent d'agir (voir exemples que je donne plus bas). Autre exemples : les critiques toujours argumentées de Maître Eolas.
[^] # Re: Efficace ?
Posté par TImaniac (site web personnel) . En réponse au journal Maître Eolas se positionne contre le Blackout. Évalué à 2.
C'est pas pour autant qu'il ne faut pas accepter aucune critique sur les moyens mis en oeuvre pour propager cette idée.
J'essai juste de comprendre la réaction de Maître Eolas, et effectivement son point de vue (et son expérience en matière juridique) montre les limites de ce genre d'actions, à commencer par un effet quasi-nul sur le but recherché (la suppression du projet de loi).
y'a peut être des moyens plus efficace, comme contacter son député par exemple (ce qui revient à faire du mini-lobbying, méthode également conseillée par la quadraturedunet), ou troller avec des amis , ce qui est toujours plus efficace je penses que d'afficher un logo noir négatif sur un site, la plupart des gens ne cliquant jamais sur les banières de ce type.
Sinon j'aime bien ce thème black de LinuxFR, j'espère qu'il restera après :)
[^] # Re: Efficace ?
Posté par TImaniac (site web personnel) . En réponse au journal Maître Eolas se positionne contre le Blackout. Évalué à -1.
Et c'est bien connu, la France et ses manifs est beaucoup plus avancé que les autres pays. Et encore, une manif ca a un impact souvent plus important car est généralement lié à une grève avec des impacts économiques.
Bref, peut être que Maître Eolas a raison et que c'est pas forcement le meilleur moyen de servir la cause anti-HADOPI.
Mais je penses que ca provoque y a un certain sentiment d'autosatisfaction chez les convaincus.
Un peu comme les partis d'extrême gauche qui crient à la révolution et tente désespérement d'agir sans que l'effet se fasse ressentir concrêtement dans les urnes.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Si t'as pas d'OS temps réel, t'as perdu.
Nullement garanti par des tests.
Personne n'a dit que les tests offraient de garanties.
Fallacieux car Il n'y pas de specification formelle (juste une informelle pour ça).
Bienvenu dans la vraie vie ! Je dirais que la grande majorité des spécifications logicielles telles qu'exprimées par le client sont informelles, incomplètes ou insuffisantes, et c'est ma principale remarque initiale. Toutes les tentatives de formalisation à partir de ces specs (specs détaillées, specs formelles puis pre-post conditions) passent par une interprétation humaine de specs informelle, et c'est là que le test reste utile. Tu es obligé de rédiger un cahier de tests, tu peux le faire valider par le client pour voir s'il est conforme à ses attentes, tu le soumets aux équipes de validation qui vont y jeter un regard humain et y déceler des erreurs d'interprétation, y ajouter leur interprétation, etc.
Un valideur formelle ne valide pas les specs, d'où l'intérêt de mon exemple qui n'a strictement rien de fallacieux, et qui au contraire me paraît très réaliste.
Pour tout état du programme, la police affiché (l'affichage fait partie de l'état) est celle de l'environement.
Je te pari que t'es incapable de prouver une telle propriété.