Vala s'inspire juste de la syntaxe de C#
Oui bah on parle de langage, c'est donc l'essentiel.
Et ma comparaison reste valable : si demain MS sort une version de C# qui sux, Mono peut "forker" et faire son bonhomme de chemin comme le fait Vala, ça lui enlèvera sans doute un intérêt mais la plateforme restera pertinente comme l'est Vala.
Ce qui ne revient pas au même que de dire que le C n’est pas portable, nom d’une pipe en bois !
Je crois qu'au fond on est d'accord, le problème c'est que le commentaire initiale qui a conduit à cette dicussion disait explicitement que tout code écrit en C était portable, ce qui est largement faux, bien au contraire. Il faut mieux se dire : le C n'est pas portable, j'ai intérêt de faire gaffe à éviter toutes les constructions du langage qui ne le sont pas si je veux un code indépendant de la machine ; que de croire, comme l'exposait nicolas, ce que lui ont dit ses professeurs : "le C est portable, il a été conçu pour, j'ai jamais eu de problème, donc c'est vrai".
Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
C'est plutôt pour dire : warning, si vous voulez faire du code portable, le C n'est pas forcement le plus adapté car il demande un certain nombre d'effort pour y arriver, sans aucune garantie au final, d'autres langages t'offre des garanties et ont vraiment été conçu dans ce sens.
Sans parler du fait qu'on parle d'une seule forme de portabilité, celle du source : le langage C implique pourtant la compilation dans un binaire qui n'est pas portable, qui ne garantie pas l'interopérabilité binaire entre compilateurs, etc. Autant de problématiques plus ou moins liées qui ont conduit à la création de langages comme Java ou C# : de vrais abstractions du matériel (avec d'autres inconvénients on est d'accord).
tu as des APIs en dehors de la librairie standard pour te faire de la serialisation
On s'en fou, t'es pas obligé de les utiliser, tu peux faire ta propre sérialisation si ça t'excite.
Ce qui importe, c'est que les API de sérialisation peuvent faire confiance à la JVM qui te garantie l'endianess, la taille des types primitifs, l'alignement : ces API seront portables.
En C, les API sont obligés de faire du cas par cas en fonction de la plateforme cible.
Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme,
On te parle d'un même programme, le même code source, mais sur 2 plateformes différentes : le programme ne pondra pas le même binaire et ne lira pas le binaire de la même façon. C'est bien un problème de portabilité du code qui a des comportements différents suivant la plateforme sur laquelle il est compilé/exécuté.
si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas
Le langage/la JVM ne te permet pas de le faire, justement parcque ce n'est pas portable : Java ne t'autorise qu'à faire des trucs portables là où le C te permet de faire des trucs non portables.
c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime
Bah oui, c'est ce qui permet d'obtenir des garanties en terme de portabilité, de sécurité. Au détriments d'autres aspects on est d'accord.
Et je te signale que tu entres ici dans la question de la portabilité des API
Ce n'est pas un problème d'API : on parle bien de la définition du langage. Le C te permet de par sa grammaire d'obtenir des résulats différents d'une machine à l'autre là où le Java ou C# ne te le permettent pas. Ce n'est pas un comportement différent de l'API : le problème vient bien de la trop forte liaison entre les types primitifs du C avec l'architecture hardware, les I/O fichiers binaires ne sont qu'un révélateur, les API spécialisés en C ne sont là que pour cacher les lacunes natives du langage. Java ou C# n'utilises pas des API pour régler le problème, mais définissent une machine virtuelle qui constitue une véritable abstraction de l'hardware, et ouvre donc la voie à une portabilité totale du code qui le cible. En fait le C# et Java ne sont pas du tout portables : ils ciblent avant tout une seule machine, avec une architecture bien précise. L'astuce consistant en fait à porter cette machine qui est une machine virtuelle pour obtenir la portabilité de tout ce qui tourne au dessus.
dans la communication avec l’extérieur.
Peut-on vraiment parler de communication avec l'extérieur ? Le fichier ne voit pas sa structure modifiée lorsque tu le changes de machine. Par contre le comportement de ton programme, si.
Le code est portable, les fichiers binaires ne l’ont jamais été
Ce sera mon dernier commentaire.
C'est con c'est exactement l'inverse :) Le problème n'est pas le fichier binaire en soit : lui est parfaitement portable et à peu prêt tous les systèmes sont capables de stocker un fichier en conservant sa structure intacte.
Par contre, le code qui lit/écrit le fichier, s'il est écrit en C, a un comportement différent suivant la machine sur laquel il s'exécute : il va intepréter différemment le fichier suivant l'architecture.
Qui ici a dit que le C était toujours portable ?
Toi je sais pas, mais nicolas: "Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant"
Ou encore : "Le C est portable, oui," "parce que précisément le C est portable"
- Java ne permet pas de faire du code correct (le C n’est pas portable)
J'ai jamais dit que le C ne permettait pas de faire du code portable. si tu veux être portable, il faut suive des bonnes pratiques
En C oui, en Java, non. (je parle strictement du langage).
"Most people new to Java coming from C think that they need to code differently depending on whether the machine they are using internally represents integers as big or little endian. In Java it does not matter. Further, without resorting to native classes, there is no way you can even tell how they are stored. The JVM may store them either way internally but Java is cleverly constructed so that it never matters." http://mindprod.com/jgloss/endian.html
Arrête de t'exciter sur des conneries. Oui, un doc écrit avec word 95 aura du mal à être lu par Word 2010. Par contre un doc écrit avec Word 97 pourra être lu, est ceci de manière correct (ne veut pas dire "parfait"). On peut pas en dire de même de OpenOffice 3 avec un doc écrit avec OpenOffice 1.
Alors oui, la compatibilité ascendante n'est pas parfaite chez Microsoft, mais c'est clairement une volontée et un de leur atouts/inconvénients : ils traînent des boulets dans le code de leur logiciels, chose dont ne s'embarassent pas de nombreux logiciels libres.
Le rapport, c’est qu’à part la quantité de données que sera capable d’ingurgiter le programme,, je vois pas ce que la taille des entiers change au niveau fonctionnel.
Bah c'est déjà un gros changement... Et je vois toujours pas le rapport avec les limitations de ressource mémoire disponible.
Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
Trouves moi un guide qui parle de portabilité de code Java (qui parle du langage, pas d'API spécifiques style accès au système de fichier).
C'est quand même fort : "le code ANSI C est toujours portable" et après "évidemment faut suivre des bonnes pratiques sinon faut pas venir pleurer".
Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier.
Evidemment ta question est tourné à ta façon : si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée. Tu ne fais que justifier ce que je dis depuis le début : en C, la portabilité du code dépend de la compétence du développeur car la norme en soit ne garantie pas un code portable, au contraire d'un code Java par exemple.
Après tout, on peut aussi dire que le C est un langage à typage fort : après tout, si y'a des erreurs de typage, c'est parcque le programmeur il code comme les pieds.
Après tout, on peut aussi dire que le C est un langage totalement secure : si y'a des débordements de tampon ou des dereferencement de pointeurs null, c'est la faute au programmeur, il a qu'a bien coder.
Ben non. PowerShell, c’est une couche d’abstraction, comme on l’a souligné.
Comme Bash est une couche d'abstraction au dessus de certains API Posix. Je te parle des fonctionnalités spécifiques aux lignes de commandes, bref de ses possibilités en ligne de commande.
Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible.
Le problème c'est que vim ne sait pas discuter avec l'environnement powershell et les objets qui y circulent. vim est trop lié aux API Posix.
Mais si tu as un éditeur qui sait le faire, c'est une ligne de commande qui est envisageable.
donc dire « je peux faire avec PowerShell ce que je peux faire avec Unix, donc l’architecture de Windows et d’Unix, c’est kif-kif »), c’est légèrement de mauvaise foi.
Euh, la mauvaise foi c'est plutôt ne pas vouloir considérer la réalité et se référer au passer quand ça nous arrange. Si PowerShell était sorti y'a 2 mois, tu aurais une excuse, mais PowerShell est sorti y'a 4 ans, il est maintenant intégré par défaut dans les déclinaisons serveur et desktop de Windows : ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
PowerShell, c'est par définition la même chose que la ligne de commande sous Linux mais en plus puissant : les programmes ne communiquent pas avec des pipes de données quelconque mais communiquent avec des données structurées : bref la même chose avec des métas.
La question n'est pas de relever les "bugs" pour dire "MS c'est des naz niveaux compatibilité", la question est de regarder si dans les solutions alternatives c'est globalement mieux : prenons OpenOffice.org, l'alternative de référence. La comparaison est sans appel, niveau compatibilité y'en a un qui est bien meilleur que l'autre.
Que fait la Mono ? Suivre la norme… bien… mais on perd, encore une fois, toute compatibilité avec la référence, et donc le risque de perdre la très grande majorité des programmes ou développeurs qui se soucient peu de la compatibilité.
Tiens on va prendre un exemple d'un langage qui s'écarte de la norme : Vala. Il est largement inspiré de la norme C#, et s'en écarte sensiblement sur certains points. Est-ce que celà gène ses utilisateurs ? Est-ce que les gens crient au FUD des brevets alors que justement Vala n'est pas protégé n'implémentant explicitement pas la norme ? Est-ce que ce langage perd de son intérêt ?
Je te parles pas de bugs qui peuvent effectivement survenir si on utilise pas les bonnes constantes : je te parle tout simplement de comportement différents, et donc pas forcement prévu, d'une plateforme à l'autre : cela donne un code qui n'est pas portable, puisque par définition avec un comportement différent.
Imagine que tu codes un logiciel qui a une feature dont la capacité dépend d'un int : tu vas dire à ton client "oui bah euh cette fonctionnalité dépend de la machine sur laquelle vous exécuter le logiciel... J'ai un tableau à 6 colonnes et 8 lignes pour les différentes situations si vous voulez".
INT_MAX ne change rien au problème : sa valeur diffère elle aussi d'une plateforme à l'autre.
En Java ou en C#, Integer.MAX_VALUE ou Int32.MaxValue sont des constantes qui ont toujours les mêmes valeurs, sur toutes les plateformes : bref le code associé aura toujours le même comportement et le résultat sera prévisible : le code est bien portable.
Pour celà, ces langages définissent une véritable abstraction de la machine physique, une machine virtuelle. Le C, par définition, autorise les optimisations bas-niveau qui dépendent du hardware : le C n'offre pas, par définition, la garantie d'un code portable, c'est au codeur de s'en assurer.
coder en ANSI veut dire respecter la norme et ne pas faire de suppositions sur les comportements indéfinis de la norme.
Si tu veux utiliser des int, va pourtant bien falloir que tu fasses une supposition sur le comportement du compilateur... Si tu ne veux pas faire de supposition, la seule alternative qu'il te reste, c'est de ne pas utiliser le type int.
Tu peux aussi t'amuser à faire des tests à coup de #ifdef : pour que ton code deviennt "portable" : c'est jamais qu'un aveu de non portabilité : tu écris du code spécifiques dans chaque branche de ton if.
Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible.
On est d'accord, y'a une bonne raison : c'est pour des questions de perf/optimisation. Mais il n'en reste pas moins que le code devient non portable puisqu'avec un comportement potentiellement différent d'une architecture à l'autre.
D'ailleur la phrase que tu cites est effectivement éloquente : grosso modo il est de la responsabilité du programmeur de s'assurer que son code est portable. Ce qui montre bien que la norme ne l'assure pas.
CQFD.
On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
Le problème, c'est que t'as visiblement jamais bosser sur un vrai projet en C : la vraie vie, c'est que t'as intérêt de faire gaffe quand tu codes en C si tu veux qu'il soit portable, et t'as sacrément besoin de vérifier. T'appelles ça des "erreurs" de programmation si tu veux, le fait est que le compilateur ne t'offre aucune garantie que le code que tu pondes soit portable, et pour cause, la norme l'oblige à faire un choix qui ne sera pas le même que celui du voisin.
Voilà la vraie vie de nombreuses personnes. Rien à voir visiblement avec ton expérience personnelle.
Quand tu codes en Java ou en C#, t'es pas en train de poser des questions sur le fait que ton code soit portable ou non en fonction de l'architecture matérielle, tu te demandes juste si les libs que tu utilises sont portables (cad s'appui sur du code natif portable ou non) : ce sont des beaucoup plus portables que le ANSI C.
Le C est portable, oui, il a été conçu pour ; Wikipedia le dit, mes professeurs me l’ont toujours dit, et je le constate tous les jours
Ca c'est la théorie. Pourtant, moi aussi je vais citer Wikipedia, à la rubrique inconvénients :
"il est difficile d'écrire des programmes portables car le comportement exact des exécutables dépend de l'ordinateur cible ;"
Ca c'est la vraie vie.
Un langage qui laisse le choix à l'implémentation de la taille d'un "int", c'est clairement une lacune qui fait qu'un code, bien que respectant la norme ANSI C, ne sera pas portable. Et c'est ce qui se passe en pratique : suivant l'architecture cible, la taille d'un int diffère.
Cet exemple suffit à montrer, que bien qu'étant "relativement" portable, la norme ANSI C est loin d'être la panacée niveau portabilité.
Si je reprends toujours ta même source, Wikipedia, il y a même une rubrique dédiée aux trucs mal définis qui font qu'un code écrit en ANSI C n'est pas forcement portable, le résultat dépendant des choix d'implémentation : http://fr.wikipedia.org/wiki/C_(langage)#Comportements_mal_d(...)
Bref, ne pas confondre la théorie, les objectifs affichés, les blablas de chercheurs et la vraie vie.
Qu'il n'existe strictement aucun logiciel de cette boite tournant sous linux de facon native (en particulier avec Mono) montre bien que cela ne sert a rien de faire des efforts pour se rapprocher.
T'es toujours aussi stupide dans tes affirmations. Après le coup des brevets-que-c-sur-que-mono-violent-mais-que-je-peux-pas-pointer, voici les logiciels qui n'existent pas, strictement, en particulier avec Mono.
C'est tellement comique que Mono diffuse pourtant des logiciels Microsoft, sûrement une preuve qu'ils ne marchent sûrement pas avec Mono :
- ASP.NET MVC
- DLR
- Managed Extensibility Framework (MEF)
- System.Data.Services.Client
D'autres tournent sans problème avec Mono :
- Le compilateur F#
- Le compilateur IronPython
- Le compilateur IronRuby
Voir sont packagés spécifiquement pour Mono :
- Les codecs Windows Media pour Moonlight
Après oui, ce sont essentiellement des logiciels à destination des développeurs et non des produits "grand public", mais c'est assez logique : ces briques n'ont pas de pertinence à être fortement liées à Windows.
D'autres softs sont fournis par MS pour Linux, sans rapport avec Mono :
- Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2
Et apres il existe des bisounours qui veulent croire que cette boite joue "fair-play"?
Si tu savais le nombre d'entreprise qui ne portent pas leurs logiciels grand public sous Linux, avec leurs 1% de parts de marché sur le desktop, c'est tellement étonnant... MS n'a rien contre les autres OS quand y'a un marché, regarde Mac OS X...
mais ca a tendance a me faire peur ce genre d'approche, disons qu'avec le brevet, tu peux payer si t'en as les moyens. La meme si t'as les moyen, tu te retrouves gros jean comme devant.
Oué bah oué, c'est la base même de l'épée de Damoclès des brevets logiciels. Mais Mono est plus concerné qu'un autre, quoiqu'en dise certains.
Donc il faut combattre les brevets logiciels dans leur ensemble et arrêter de taper gratuitement sur un logiciel plus qu'un autre.
Faut juste ne pas se tromper sur ce que veux dire copyright : il désigne celui qui possède les droits sur une oeuvre particulière à un instant donné.
A ne pas confondre avec l'auteur, qui de toute façon n'est sûrement pas plus "Sun" que "Oracle" mais un employé de Sun, voir même peut être un sous-traitant, va savoir.
Bref, ce n'est en rien une réécriture de l'histoire, justement un changement de "propriétaire" des droits associés au code.
A noter qu'ils ne demandent pas à modifier l'ensemble du code déjà diffusé, ils mettent juste à jour le code actuel pour bien préciser qu'ils faut s'adresser à eux en cas de question sur les droits associés au code. L'histoire, ce sont les archives, l'historique GIT, etc.
Il parle de la compatiblité avec l'ancien. Et ce qui est sûr, c'est qu'Office 2010 a beaucoup plus de chance d'ouvrir un doc rédigé sous Office 97 sans encombre que OpenOffice 3 d'ouvrir un document texte rédigé avec OpenOffice 1.
Donc oui, même si c'est pas parfait, la compatibilité avec l'ancien est sans doute la préocupation majeure de MS, ce qui est d'ailleur un avantage et un inconvénient: maintient de vieilles API avec ce que celà implique en terme de sécurité, maintient de vieilles interfaces, avec ce que celà implique en terme de modernité, lourdeur dans les process de conception/développement (je suppose) pour tenter d'innover tout en gardant la compatibilité, etc.
On s'en branle total : si demain MS impose des trucs totalement débile dans C#, c'est leur problème : si Mono juge que c'est inutile d'aller dans cette direction, rien ne les obligent à suivre MS.
Mono est un logiciel libre, tu peux forker et faire ce que tu veux avec.
si tu fais l'effort de lire
J'ai lu, et ?
La politique de Mono est clair : si y'a un brevet qui peut géner, on l'utiliser pas en trouvant un algo alternatif. Si c'est pas possible, on supprime le code en question.
Je réitère donc ma demande : montre moi un brevet et un morceau de code de Mono qui violerait le dit brevet.
Je vais pas me fatiguer a repondre plus a tes attaques
Ou comment avouer que tu n'as strictement aucune preuve de ce que tu prétends. Mais t'as raison, arrête de répondre, c'est tellement ridicule.
Ah oui tiens c'est amusant va donc voir pourquoi Moonlight n'est pas inclu dans Fedora et apres on reparle.
Moonlight reste un projet à part dans Mono, ça serait bon de ne pas généraliser.
Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe.
Tu sais très bien que c'est impossible à prouver gros malin. Et tu sais très bien que j'ai jamais dit que Mono ne violait aucun brevet : j'ai dit que Mono avait un risque, comme tous les autres logiciels libres.
Mais en tout cas tu confirmes mon intuition : tu te fou bien de la gueule du monde. Tu affirmes quelque chose (Mono utilise forcement des brevets MS) sans aucune preuve. Ton argumentation est detestable et totalement irrespectueuses des développeurs et utilisateurs de ce logiciel libre.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Oui bah on parle de langage, c'est donc l'essentiel.
Et ma comparaison reste valable : si demain MS sort une version de C# qui sux, Mono peut "forker" et faire son bonhomme de chemin comme le fait Vala, ça lui enlèvera sans doute un intérêt mais la plateforme restera pertinente comme l'est Vala.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Je crois qu'au fond on est d'accord, le problème c'est que le commentaire initiale qui a conduit à cette dicussion disait explicitement que tout code écrit en C était portable, ce qui est largement faux, bien au contraire. Il faut mieux se dire : le C n'est pas portable, j'ai intérêt de faire gaffe à éviter toutes les constructions du langage qui ne le sont pas si je veux un code indépendant de la machine ; que de croire, comme l'exposait nicolas, ce que lui ont dit ses professeurs : "le C est portable, il a été conçu pour, j'ai jamais eu de problème, donc c'est vrai".
Si c’est juste pour dire que le C est un langage beaucoup, beaucoup moins neuneu-proof que Java, je suis d’accord.
C'est plutôt pour dire : warning, si vous voulez faire du code portable, le C n'est pas forcement le plus adapté car il demande un certain nombre d'effort pour y arriver, sans aucune garantie au final, d'autres langages t'offre des garanties et ont vraiment été conçu dans ce sens.
Sans parler du fait qu'on parle d'une seule forme de portabilité, celle du source : le langage C implique pourtant la compilation dans un binaire qui n'est pas portable, qui ne garantie pas l'interopérabilité binaire entre compilateurs, etc. Autant de problématiques plus ou moins liées qui ont conduit à la création de langages comme Java ou C# : de vrais abstractions du matériel (avec d'autres inconvénients on est d'accord).
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
On s'en fou, t'es pas obligé de les utiliser, tu peux faire ta propre sérialisation si ça t'excite.
Ce qui importe, c'est que les API de sérialisation peuvent faire confiance à la JVM qui te garantie l'endianess, la taille des types primitifs, l'alignement : ces API seront portables.
En C, les API sont obligés de faire du cas par cas en fonction de la plateforme cible.
Et si un programme essaie de lire au petit bonheur la chance un truc écrit au petit bonheur la chance par un autre programme,
On te parle d'un même programme, le même code source, mais sur 2 plateformes différentes : le programme ne pondra pas le même binaire et ne lira pas le binaire de la même façon. C'est bien un problème de portabilité du code qui a des comportements différents suivant la plateforme sur laquelle il est compilé/exécuté.
si tu essaies de faire un dump mémoire dans un fichier et de reloader brutalement ce dump mémoire sur une autre architecture, il y a de fortes chances que ça marche pas
Le langage/la JVM ne te permet pas de le faire, justement parcque ce n'est pas portable : Java ne t'autorise qu'à faire des trucs portables là où le C te permet de faire des trucs non portables.
c’est la résolution des problèmes selon Java : si une fonctionnalité peut potentiellement être mal utilisée, on la supprime
Bah oui, c'est ce qui permet d'obtenir des garanties en terme de portabilité, de sécurité. Au détriments d'autres aspects on est d'accord.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
int* fib = stackalloc int[Int32.MaxValue];
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Ce n'est pas un problème d'API : on parle bien de la définition du langage. Le C te permet de par sa grammaire d'obtenir des résulats différents d'une machine à l'autre là où le Java ou C# ne te le permettent pas. Ce n'est pas un comportement différent de l'API : le problème vient bien de la trop forte liaison entre les types primitifs du C avec l'architecture hardware, les I/O fichiers binaires ne sont qu'un révélateur, les API spécialisés en C ne sont là que pour cacher les lacunes natives du langage. Java ou C# n'utilises pas des API pour régler le problème, mais définissent une machine virtuelle qui constitue une véritable abstraction de l'hardware, et ouvre donc la voie à une portabilité totale du code qui le cible. En fait le C# et Java ne sont pas du tout portables : ils ciblent avant tout une seule machine, avec une architecture bien précise. L'astuce consistant en fait à porter cette machine qui est une machine virtuelle pour obtenir la portabilité de tout ce qui tourne au dessus.
dans la communication avec l’extérieur.
Peut-on vraiment parler de communication avec l'extérieur ? Le fichier ne voit pas sa structure modifiée lorsque tu le changes de machine. Par contre le comportement de ton programme, si.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Ce sera mon dernier commentaire.
C'est con c'est exactement l'inverse :) Le problème n'est pas le fichier binaire en soit : lui est parfaitement portable et à peu prêt tous les systèmes sont capables de stocker un fichier en conservant sa structure intacte.
Par contre, le code qui lit/écrit le fichier, s'il est écrit en C, a un comportement différent suivant la machine sur laquel il s'exécute : il va intepréter différemment le fichier suivant l'architecture.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Toi je sais pas, mais nicolas:
"Quand j’écris un code ANSI C il doit tourner et rendre le même résultat quelque soit la machine le supportant"
Ou encore :
"Le C est portable, oui,"
"parce que précisément le C est portable"
- Java ne permet pas de faire du code correct (le C n’est pas portable)
J'ai jamais dit que le C ne permettait pas de faire du code portable.
si tu veux être portable, il faut suive des bonnes pratiques
En C oui, en Java, non. (je parle strictement du langage).
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
http://mindprod.com/jgloss/endian.html
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Alors oui, la compatibilité ascendante n'est pas parfaite chez Microsoft, mais c'est clairement une volontée et un de leur atouts/inconvénients : ils traînent des boulets dans le code de leur logiciels, chose dont ne s'embarassent pas de nombreux logiciels libres.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Bah c'est déjà un gros changement... Et je vois toujours pas le rapport avec les limitations de ressource mémoire disponible.
Ce sont des listes de bonnes pratiques. Comme il y en a dans tous les langages — si tu les suis pas, vient pas pleurer si ton programme te pète dans les mains.
Trouves moi un guide qui parle de portabilité de code Java (qui parle du langage, pas d'API spécifiques style accès au système de fichier).
C'est quand même fort : "le code ANSI C est toujours portable" et après "évidemment faut suivre des bonnes pratiques sinon faut pas venir pleurer".
Encore une fois, ce que je te demande, c’est une fonctionnalité bien codée dont le comportement dépend de la taille d’un entier.
Evidemment ta question est tourné à ta façon : si je trouve un exemple, tu vas dire que la fonctionnalité est mal codée. Tu ne fais que justifier ce que je dis depuis le début : en C, la portabilité du code dépend de la compétence du développeur car la norme en soit ne garantie pas un code portable, au contraire d'un code Java par exemple.
Après tout, on peut aussi dire que le C est un langage à typage fort : après tout, si y'a des erreurs de typage, c'est parcque le programmeur il code comme les pieds.
Après tout, on peut aussi dire que le C est un langage totalement secure : si y'a des débordements de tampon ou des dereferencement de pointeurs null, c'est la faute au programmeur, il a qu'a bien coder.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Comme Bash est une couche d'abstraction au dessus de certains API Posix. Je te parle des fonctionnalités spécifiques aux lignes de commandes, bref de ses possibilités en ligne de commande.
Donc, je doute que taper "vim HKEY_CURRENT_USER\ma_clef" soit possible.
Le problème c'est que vim ne sait pas discuter avec l'environnement powershell et les objets qui y circulent. vim est trop lié aux API Posix.
Mais si tu as un éditeur qui sait le faire, c'est une ligne de commande qui est envisageable.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Vaguement drôle, mais y dit qu'il voit pas le rapport.
Mais peut-être est-ce juste mon manque d’imagination ?
Je me suis fait chier à pondre des liens plus haut sur les bonnes pratiques en matière de portabilité du code C, avec des exemples concrêts.
Si t'as pas d'imagination, google est ton ami, exemples :
http://webcache.googleusercontent.com/search?q=cache:liqP32f(...)
http://docs.hp.com/en/5921/portability.html
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Euh, la mauvaise foi c'est plutôt ne pas vouloir considérer la réalité et se référer au passer quand ça nous arrange. Si PowerShell était sorti y'a 2 mois, tu aurais une excuse, mais PowerShell est sorti y'a 4 ans, il est maintenant intégré par défaut dans les déclinaisons serveur et desktop de Windows : ça montre juste ta méconnaissance du sujet sur lequel tu trolls.
Au fait, je peux faire vim sur une partie de la base de registre avec PowerShell ?
PowerShell, c'est par définition la même chose que la ligne de commande sous Linux mais en plus puissant : les programmes ne communiquent pas avec des pipes de données quelconque mais communiquent avec des données structurées : bref la même chose avec des métas.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Tiens on va prendre un exemple d'un langage qui s'écarte de la norme : Vala. Il est largement inspiré de la norme C#, et s'en écarte sensiblement sur certains points. Est-ce que celà gène ses utilisateurs ? Est-ce que les gens crient au FUD des brevets alors que justement Vala n'est pas protégé n'implémentant explicitement pas la norme ? Est-ce que ce langage perd de son intérêt ?
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Imagine que tu codes un logiciel qui a une feature dont la capacité dépend d'un int : tu vas dire à ton client "oui bah euh cette fonctionnalité dépend de la machine sur laquelle vous exécuter le logiciel... J'ai un tableau à 6 colonnes et 8 lignes pour les différentes situations si vous voulez".
INT_MAX ne change rien au problème : sa valeur diffère elle aussi d'une plateforme à l'autre.
En Java ou en C#, Integer.MAX_VALUE ou Int32.MaxValue sont des constantes qui ont toujours les mêmes valeurs, sur toutes les plateformes : bref le code associé aura toujours le même comportement et le résultat sera prévisible : le code est bien portable.
Pour celà, ces langages définissent une véritable abstraction de la machine physique, une machine virtuelle. Le C, par définition, autorise les optimisations bas-niveau qui dépendent du hardware : le C n'offre pas, par définition, la garantie d'un code portable, c'est au codeur de s'en assurer.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Si tu veux utiliser des int, va pourtant bien falloir que tu fasses une supposition sur le comportement du compilateur... Si tu ne veux pas faire de supposition, la seule alternative qu'il te reste, c'est de ne pas utiliser le type int.
Tu peux aussi t'amuser à faire des tests à coup de #ifdef : pour que ton code deviennt "portable" : c'est jamais qu'un aveu de non portabilité : tu écris du code spécifiques dans chaque branche de ton if.
Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible.
On est d'accord, y'a une bonne raison : c'est pour des questions de perf/optimisation. Mais il n'en reste pas moins que le code devient non portable puisqu'avec un comportement potentiellement différent d'une architecture à l'autre.
D'ailleur la phrase que tu cites est effectivement éloquente : grosso modo il est de la responsabilité du programmeur de s'assurer que son code est portable. Ce qui montre bien que la norme ne l'assure pas.
CQFD.
On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
Le problème, c'est que t'as visiblement jamais bosser sur un vrai projet en C : la vraie vie, c'est que t'as intérêt de faire gaffe quand tu codes en C si tu veux qu'il soit portable, et t'as sacrément besoin de vérifier. T'appelles ça des "erreurs" de programmation si tu veux, le fait est que le compilateur ne t'offre aucune garantie que le code que tu pondes soit portable, et pour cause, la norme l'oblige à faire un choix qui ne sera pas le même que celui du voisin.
D'ailleurs, quelque chose qui montre bien que la norme ANSI C n'est pas un garant de portabilité (même si son respect met le code sur la bonne voie), c'est le nombre de "guide" pour le programmeur afin qu'il fasse attention à la portabilité du code qu'il écrit :
"Guide pour la portabilité" : http://docs.hp.com/en/B3901-90005/ch05s02.html
http://serghei.net/docs/programming/autobook-1.1/writing20po(...) (citation rigolote : "The C language makes it easy to write non-portable code")
Le mythe de la portabilité du C : http://spinning-yarns.org/blog/?p=451
http://www.psgd.org/paul/docs/cstyle/cstyle16.htm (avec ma préférée : "C combines the power of assembler with the portability of assembler. " )
http://unixwiz.net/about/porting.html ( "Ultimately, most software porters created portability macros that allowed the use of many of these features in code that could be straight K&R or ANSI.")
Voilà la vraie vie de nombreuses personnes. Rien à voir visiblement avec ton expérience personnelle.
Quand tu codes en Java ou en C#, t'es pas en train de poser des questions sur le fait que ton code soit portable ou non en fonction de l'architecture matérielle, tu te demandes juste si les libs que tu utilises sont portables (cad s'appui sur du code natif portable ou non) : ce sont des beaucoup plus portables que le ANSI C.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 1.
Ca c'est la théorie. Pourtant, moi aussi je vais citer Wikipedia, à la rubrique inconvénients :
"il est difficile d'écrire des programmes portables car le comportement exact des exécutables dépend de l'ordinateur cible ;"
Ca c'est la vraie vie.
Un langage qui laisse le choix à l'implémentation de la taille d'un "int", c'est clairement une lacune qui fait qu'un code, bien que respectant la norme ANSI C, ne sera pas portable. Et c'est ce qui se passe en pratique : suivant l'architecture cible, la taille d'un int diffère.
Cet exemple suffit à montrer, que bien qu'étant "relativement" portable, la norme ANSI C est loin d'être la panacée niveau portabilité.
Si je reprends toujours ta même source, Wikipedia, il y a même une rubrique dédiée aux trucs mal définis qui font qu'un code écrit en ANSI C n'est pas forcement portable, le résultat dépendant des choix d'implémentation :
http://fr.wikipedia.org/wiki/C_(langage)#Comportements_mal_d(...)
Bref, ne pas confondre la théorie, les objectifs affichés, les blablas de chercheurs et la vraie vie.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
T'es toujours aussi stupide dans tes affirmations. Après le coup des brevets-que-c-sur-que-mono-violent-mais-que-je-peux-pas-pointer, voici les logiciels qui n'existent pas, strictement, en particulier avec Mono.
C'est tellement comique que Mono diffuse pourtant des logiciels Microsoft, sûrement une preuve qu'ils ne marchent sûrement pas avec Mono :
- ASP.NET MVC
- DLR
- Managed Extensibility Framework (MEF)
- System.Data.Services.Client
D'autres tournent sans problème avec Mono :
- Le compilateur F#
- Le compilateur IronPython
- Le compilateur IronRuby
Voir sont packagés spécifiquement pour Mono :
- Les codecs Windows Media pour Moonlight
Après oui, ce sont essentiellement des logiciels à destination des développeurs et non des produits "grand public", mais c'est assez logique : ces briques n'ont pas de pertinence à être fortement liées à Windows.
D'autres softs sont fournis par MS pour Linux, sans rapport avec Mono :
- Linux Integration Services v2.1 for Windows Server 2008 Hyper-V R2
Et apres il existe des bisounours qui veulent croire que cette boite joue "fair-play"?
Si tu savais le nombre d'entreprise qui ne portent pas leurs logiciels grand public sous Linux, avec leurs 1% de parts de marché sur le desktop, c'est tellement étonnant... MS n'a rien contre les autres OS quand y'a un marché, regarde Mac OS X...
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 5.
Oué bah oué, c'est la base même de l'épée de Damoclès des brevets logiciels. Mais Mono est plus concerné qu'un autre, quoiqu'en dise certains.
Donc il faut combattre les brevets logiciels dans leur ensemble et arrêter de taper gratuitement sur un logiciel plus qu'un autre.
# bof
Posté par TImaniac (site web personnel) . En réponse au journal oracle réécrit l'histoire. Évalué à 10.
A ne pas confondre avec l'auteur, qui de toute façon n'est sûrement pas plus "Sun" que "Oracle" mais un employé de Sun, voir même peut être un sous-traitant, va savoir.
Bref, ce n'est en rien une réécriture de l'histoire, justement un changement de "propriétaire" des droits associés au code.
A noter qu'ils ne demandent pas à modifier l'ensemble du code déjà diffusé, ils mettent juste à jour le code actuel pour bien préciser qu'ils faut s'adresser à eux en cas de question sur les droits associés au code. L'histoire, ce sont les archives, l'historique GIT, etc.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à -1.
Donc oui, même si c'est pas parfait, la compatibilité avec l'ancien est sans doute la préocupation majeure de MS, ce qui est d'ailleur un avantage et un inconvénient: maintient de vieilles API avec ce que celà implique en terme de sécurité, maintient de vieilles interfaces, avec ce que celà implique en terme de modernité, lourdeur dans les process de conception/développement (je suppose) pour tenter d'innover tout en gardant la compatibilité, etc.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Mono est un logiciel libre, tu peux forker et faire ce que tu veux avec.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
J'ai lu, et ?
La politique de Mono est clair : si y'a un brevet qui peut géner, on l'utiliser pas en trouvant un algo alternatif. Si c'est pas possible, on supprime le code en question.
Je réitère donc ma demande : montre moi un brevet et un morceau de code de Mono qui violerait le dit brevet.
Je vais pas me fatiguer a repondre plus a tes attaques
Ou comment avouer que tu n'as strictement aucune preuve de ce que tu prétends. Mais t'as raison, arrête de répondre, c'est tellement ridicule.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Moonlight reste un projet à part dans Mono, ça serait bon de ne pas généraliser.
Prouve moi par un lien provenant de Microsoft que aucun brevet n'est viole par aucune version de Mono et des softs associe.
Tu sais très bien que c'est impossible à prouver gros malin. Et tu sais très bien que j'ai jamais dit que Mono ne violait aucun brevet : j'ai dit que Mono avait un risque, comme tous les autres logiciels libres.
Mais en tout cas tu confirmes mon intuition : tu te fou bien de la gueule du monde. Tu affirmes quelque chose (Mono utilise forcement des brevets MS) sans aucune preuve. Ton argumentation est detestable et totalement irrespectueuses des développeurs et utilisateurs de ce logiciel libre.