Merci de votre aide, farvardin, dark_star et Xion345, même si je n'ai toujours pas réussi à résoudre le problème.
Pour XMMS, il utilise, je crois, les bibliothèque GTK1 liées en statique. Par contre ce n'est pas le cas pour Scilab qui utilise libfontconfig1. J'utilise KDE comme environnement graphique, ce qui fait que mes .gtkrc sont bien vides.
Bref, je ne comprends toujours pas, mais je cherche...
Je te pertinente des deux mains. Résoudre des problèmes concrets, pour lesquels avoir une solution importe, fait faire des progrès rapides dans n'importe quel langage. En milieu scolaire, le seul travail qui m'ait vraiment intéressé était un programme de dérivation formel en C. J'aime les maths. Le C aussi, mais ce n'est pas ce que je choisirais pour refaire ce genre de choses.
Pour en revenir à la fin de ton POST, il parait qu'il n'est pas facile de faire du code portable entre compilateur Eiffel.
C'est vrai ; il ya trois compilateurs Eiffel, bientôt quatre avec Gobo, tous au moins partiellement sous des licences libres. VisualEiffel est resté à la version 2 de la spécification du langage, et n'implémente donc pas les agents. EiffelStudio et SmartEiffel implémentent, eux, les agents, mais chacun de manière différente. VisualStudio veut implémenter petit à petit les spécifications de l'ECMA, alors que l'équipe de SmartEiffel affirme que c'est la spécification d'un langage différent ; par contre SmartEiffel rend sensible à la casse l'écriture des programmes, alors que les textes Eiffel sont insensibles à la casse depuis la création du langage...
Gobo veut faire des outils et des bibliothèques compatibles avec tous les compilateurs en activité. Comme VisualEiffel en fait partie et n'a pas les agents, les bibliothèques Gobo n'utilisent pas les agents. Si VE s'y met, il faut espérer que ce ne sera pas d'une troisième manière différente... Si l'on suit les mailing lists de Gobo, on peut voir que c'est SmartEiffel qui leur pose le plus de problèmes.
SmartEiffel a produit un compilateur incompatible depuis le 2.0 avec sa version précédente, la 1.1. Du coup, quelques un, dont Daniel Moisset ont créé une version 1.2 de SmartEiffel dont le but est d'être compatible avec le versions 1.1 et la dernière 2.x afin de faciliter la migration des programmes écrits dans la première vers la deuxième.
Mon avis est que SmartEiffel est devenu un compilateur expérimental, un laboratoire où les chercheurs de l'INRIA peuvent essayer leurs excellentes idées, mais qu'on ne peut pas considérer comme un outil de travail permettant de produire des logiciels aspirant à une certaine pérennité. VisualStudio est un outil qui permet de travailler d'une manière efficace. Désormais une version libre existe. Pourquoi ne pas s'en servir ?
Je ne suis pas non plus moi-même un spécialiste de la théorie des langages de programmation. De plus la question de la variance des arguments des routines héritées est ce que je maîtrise le plus mal. Il n'empêche que je suis les mailing lists Eiffel et que la question des catcalls, qui sont les produits de ces problèmes de variance y ont été abondamment abordés. Il me semble que SmartEiffel autant qu'EiffelStudio sont sécurisés à ce point de vue.
Si tu lis le papier de Castagna que je t'ai indiqué, tu verras que la question de la covariance et de la contravariance ne sont pas des notions opposées mais qu'elles recouvrent des objectifs de nature sémantiquement différentes.
Par ailleurs je ne promeus pas ici Eiffel comme un langage expérimental, mais comme un outil disponible aujourd'hui pour produire des logiciels, avec ses défauts. Comme tu le dis, on peut bien aussi utiliser C++... Le vrai défaut d'Eiffel, comme cela a été pertinemment évoqué ici, c'est sa relative pauvreté en bibliothèques et en frameworks.
Ca fait plusieurs fois que tu professes l'opinion selon laquelle la contravariance serait meilleure (ça veut dire quoi, meilleure ?) que la covariance des arguments des routines héritées. J'avais moi-même raconté quelques âneries à ce sujet et j'avais été repris (par Julien Puydt, je crois) qui m'avait aiguillé sur un papier de Giuseppe Castagna dont le titre est covariance and contravariance: a conflict without a cause. http://www.di.ens.fr/~castagna/pub.frame.html
Si j'ai bien compris, l'avantage de la contravariance est qu'elle ne pose jamais de problème. Son inconvénient est qu'elle prive de toutes les possibilités où la covariance serait valide. Mantenant ce sont les compilateurs Eiffel qui analysent le code pour détecter les possibles catcalls. Choisir la contravariance comme l'ont fait les créateurs de Sather semble résulter d'une analyse, sinon simpliste, du moins manquant de finesse. On se prive de possibilités, de la même manière que d'autres langages n'implémentent pas l'héritage multiple, pour ne pas compliquer l'implémentation du compilateur.
Ceci dit, il est assez fréquent que j'entende parler de Sather là où se trouvent des discussions sur Eiffel. Existe-t-il des compilateurs Sather qui permettent de produire des applications de la vie réelle ? Y en a-t-il qui de plus proposent un environnement de développement avec quelques facilités ? Et y a-t-il des applications ou des services informatiques qui utilisent Sather ? Ces questions sont sans malice, j'avoue seulement mon ignorance dans ce domaine.
Ah mon avis Eiffel a deux principaux défaut pour l'industrie informatique. Cela tient au fait que la méthode eiffel permet d'obtenir plus rapidement un résultat de meilleur qualité. Ce qui veux dire :
1. on gagne moins d'argent en utilisant eiffel car on programme plus vite : donc il y a moins d'heure de travail a facturer.
2. on gagne moins d'argent en utilisant eiffel car on produit moins de bug : donc on ne peut pas vendre des nouvelles versions/mise à jour pour corriger les bug.
Je me permets de remarquer que la production de logiciels libres ne souffre pas des mêmes soucis. La qualité tout de suite, c'est bon à prendre.
Oui, j'ai oublié des tas de caractéristiques, je voulais faire court. Dans les qualités, j'ai oublié une chose : cela existe et c'est prêt à l'emploi. Parmi les défauts, il faut citer la relative pauvreté des bibliothèques.
Je ne vois pas pourquoi il faudrait attendre l'arrivée des langages objet à prototypes pour coder avec des outils confortables et puissants.
Je n'ai pas l'impression que l'on évalue ce passage d'EiffelStudio au libre à sa juste valeur. Je vois même des commentaires tendant à déprécier l'intérêt du langage (qui, en effet, n'est pas parfait) ou l'activité des commerciaux d'ISE qui n'a pas conduit à une domination mondiale.
D'abord, en vitesse, les principales caractéristiques, maintes fois exposées, d'Eiffel.
La programmation par contrat permet de spécifier les applications ainsi que de les documenter. En passant, la gestion des exceptions est d'une remarquable simplicité : la génération d'une exception est la violation d'une assertion. Quand j'entrevois le pastis de la gestion des exceptions en, par exemple, Java, ça ne me donne pas envie. L'héritage, multiple bien sûr, ne simplifie pas la vie de ceux qui implémentent des compilateurs Eiffel ; mais celle du reste du monde. La généricité (qui peut certes être simulée par l'héritage, surtout quand il est multiple...) évite la duplication inutile de code et concourt à sa lisibilité.
Si l'on cherche un langage ayant ces trois caractéristiques, il n'y a pas pléthore. On peut ajouter une syntaxe d'une lumineuse clarté, héritée de Simula, de Pascal et d'Ada, l'identité entre la classe et le type, associée à l'unicité de leur représentation par un fichier ainsi que les nombreuses facilités, anciennes ou plus récentes, telles que l'héritage d'implémentation.
Le principal manque de la spécification d'Eiffel concerne les concepts de concurrence et d'application répartie. En ce qui concerne la concurrence, EiffelStudio implémente les threads et permet donc le multitâche. Bertrand Meyer a proposé une conception unifiée de ces concepts sous le nom de SCOOP (Simple Concurrent Object Oriented Programming). Son implémentation offrirait une remarquable facilité d'utlisation aux programmeurs, au prix d'une terrible difficulté pour ceux qui auraient à l'implémenter dans un compilateur.
Bertrand Meyer, le géniteur d'Eiffel, occupe désormais une position académique en tant que titulaire de la chaire de Génie Logiciel à l'Ecole Polytechnique Fédérale de Zurich. Parmi les projets de ses collègues ou élèves, on trouve :
Il y a plein d'autres projets concernant Eiffel sur le site de l'ETH. On peut aussi y découvrir des jeux développés par les étudiants comme sujet d'étude.
Ces derniers temps, Eiffel Software promouvait les qualités du langage en tant qu'elles facilitent les pratiques d'outsourcing et d'offshoring, propres à faire grincer les dents de beaucoup de monde, à commencer par les miennes... Cette facilité de sous-traiter le travail logiciel liée à la capacité de bien spécifier, en particulier grâce à la conception par contrats, est une chose à prendre en compte dans l'élaboration collective de logiciels libres. De plus, l'extrême lisibilité du langage, y compris par les non-spécialistes, peut permettre une communication fructueuse entre les praticiens des aspects métier et ceux de la programmation. Je pense qu'un projet métier libre, genre dont on peut espérer la prolification, tirerait grandement parti des qualités d'Eiffel dans le cadre d'un travail distribué et décentralisé, qui sont les caractéristiques fréquentes des projets libres.
Je ne vous parle pas de l'environnement de développement, faites-vous en une idée par votre propre pratique. Je risque d'oublier des délices, entre la navigation dans le code et les multiples outils et facilités qu'il offre et qui font du développement sous EiffelStudio un vrai plaisir. Jusqu'ici, je me retenais de le dire, la chose étant purement propriétaire, maintenant je peux y aller !
En gros, j'ai l'impression, purement subjective probablement, que certains d'entre vous trouvent que la mariée est trop belle.
Oui, je confirme. Il peut y avoir des variantes, bibliothèques de base compilées avec le projet, ou inclusion de celles-ci en tant qu'élément précompilé, mais du point de vue de la licence ça revient au même.
Ce compilateur est réalisé par Eric Bezault, le créateur de la bien connue bibliothèque Gobo pour Eiffel, qui a pour ambition d'être compatible avec tous les compilateurs Eiffel en activité. Il est réalisé sous la Eiffel Forum License, version 2, compatible GPL, et qui est tellement concise que je peux la citer intégralement ci-dessous :
Eiffel Forum License, version 2
1. Permission is hereby granted to use, copy, modify and/or distribute this package, provided that:
* copyright notices are retained unchanged,
* any distribution of this package, whether modified or not, includes this license text.
2. Permission is hereby also granted to distribute binary programs which depend on this package. If the binary program depends on a modified version of this package, you are encouraged to publicly release the modified version of this package.
THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT WARRANTY. ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE TO ANY PARTY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THIS PACKAGE.
Je sais que c'est triste, mon point de vue sur Microsoft. Mais je comprends très bien que Windows peut booter sans iE, et qu'enlever IE casse certaines fonctionnalités : Windows Update, le système d'aide et d'autres choses que je te fais confiance pour connaître mieux que moi.
Mais c'est une conversation d'arrière-garde, Netscape est mort, c'était là le but visé. Il a laissé une descendance...
Tu es un grand artiste ! Tu contredis les déclarations officielles, devant la justice !, de Microsoft à propos de l'intégration d'Explorer, et tu feins de prendre pour argent comptant les affirmations sarcastiques de briaeros007, en lui reprochant l'inconstance générale de ses réactions aux déclarations de ton employeur ! Vraiment du grand art !
Quand te mutent-ils au service juridique chez MS ? Même si ça compromet tout emménagement de ta part dans le New Jersey...
"Ne laissez jamais un humain faire le travail d'un programme"
Ca me rappelle la signature que j'utilisais avant, qui me venait de réflexions que je me faisais en tant que programmeur Eiffel devant les discussions acharmées de tenants de Java, C# ou C++, surtout quand ils abordaient les notions de virtual : "Se prendre pour un compilateur, c'est un trouble du comportement".
Sinon je saisis l'occasion de te remercier et de t'applaudir de faire connaître le travail de Benoît Sonntag ainsi que pour les essais que tu as écrits autour des concepts de Lisaac,qui donnent lieu à de fructueuses réflexions. Je regrette seulement de ne pas avoir plus de temps à consacrer aux travaux pratiques autour de ça. Merci aussi à nicO, pour les mêmes raisons.
si le compilateur a été capable d'écrire ce code, un programmeur sera capable de le faire
Même si ce que tu racontes était vrai, si le programmeur met 10, 100, 1000 fois plus de temps pour faire la même chose... En plus le fonctionnement des optimisations mises en places par le compilateur peuvent être garanties dans leur fonctionnement, et même parfois carrément être prouvées. Ca engendrera des bugs de pus haut niveau...
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
Tu donnes l'impression de ne pas avoir compris l'utilité de Lisaac : c'est un langage destiné aux couches de bas niveau, et postulant de ce fait au remplacement du C ou le concurrençant, mais permettant une écriture à partir de concepts plus élaborés. Ce n'est pas un langage alternatif aux langages du genre Python, C#, Java ou Eiffel. Ou alors là, c'est moi qui ai mal compris.
Désolé, je ne peux pas indiquer un quelconque article au sujet des deux pourvois en cassation au maximum. Par contre c'est par affablilité que j'ai commencé la phrase par à ma connaissance. J'en ai une certitude absolue. C'est une des notions élémentaires que l'on apprend au tout début de la moindre initiation en droit pour non-spécialiste (l'organisation de la Justice en France).
Pour les révisions des procès, c'était une boutade. Même si ça s'appliquait aux juridictions civiles, à raison de quelques unes par siècle, on a le temps de voir venir...
A ma connaissance, il peut y avoir au plus deux pourvois en cassation, ce qui donne : un jugement en première instance, interjeté une fois en appel, un premier pourvoi en cassation, affaire rejugée une première fois en cour d'appel, repourvoi en cassation et enfin un jugement définitif en cours d'appel qui doit absolument tenir compte des arrêts de le cour de cassation.
Ce qui fait au maximum 6 jugements de tribunaux nationaux, avant d'éventuellement poursuivre devant une juridiction européenne, là j'ai moins de notions, ou une éventuelle révision du procès (comme dans l'affaire Seznec, qui n'a pas suivi ce schéma par ailleurs). En principe, quand on en arrive là, un certain temps s'est écoulé...
# Merci
Posté par Philip Marlowe . En réponse au message Problème d'affichage. Évalué à 2.
Pour XMMS, il utilise, je crois, les bibliothèque GTK1 liées en statique. Par contre ce n'est pas le cas pour Scilab qui utilise libfontconfig1. J'utilise KDE comme environnement graphique, ce qui fait que mes .gtkrc sont bien vides.
Bref, je ne comprends toujours pas, mais je cherche...
[^] # Re: Inutile
Posté par Philip Marlowe . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 1.
Moins tous ceux qui seront passés à Sather...
[^] # Re: Et beh...
Posté par Philip Marlowe . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 3.
[^] # Re: Pendant qu'on est dans les poissons d'avril...
Posté par Philip Marlowe . En réponse à la dépêche Revue de Presse - Avril 2006. Évalué à 2.
[^] # Pendant qu'on est dans les poissons d'avril...
Posté par Philip Marlowe . En réponse à la dépêche Revue de Presse - Avril 2006. Évalué à 3.
L'offre couplée : 79 ¤
Linux Magazine seul : 49 ¤
Linux Pratique seul : 26 ¤
Cherchez l'erreur...
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 4.
Bravo pour le lapsus !
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
C'est vrai ; il ya trois compilateurs Eiffel, bientôt quatre avec Gobo, tous au moins partiellement sous des licences libres. VisualEiffel est resté à la version 2 de la spécification du langage, et n'implémente donc pas les agents. EiffelStudio et SmartEiffel implémentent, eux, les agents, mais chacun de manière différente. VisualStudio veut implémenter petit à petit les spécifications de l'ECMA, alors que l'équipe de SmartEiffel affirme que c'est la spécification d'un langage différent ; par contre SmartEiffel rend sensible à la casse l'écriture des programmes, alors que les textes Eiffel sont insensibles à la casse depuis la création du langage...
Gobo veut faire des outils et des bibliothèques compatibles avec tous les compilateurs en activité. Comme VisualEiffel en fait partie et n'a pas les agents, les bibliothèques Gobo n'utilisent pas les agents. Si VE s'y met, il faut espérer que ce ne sera pas d'une troisième manière différente... Si l'on suit les mailing lists de Gobo, on peut voir que c'est SmartEiffel qui leur pose le plus de problèmes.
SmartEiffel a produit un compilateur incompatible depuis le 2.0 avec sa version précédente, la 1.1. Du coup, quelques un, dont Daniel Moisset ont créé une version 1.2 de SmartEiffel dont le but est d'être compatible avec le versions 1.1 et la dernière 2.x afin de faciliter la migration des programmes écrits dans la première vers la deuxième.
Mon avis est que SmartEiffel est devenu un compilateur expérimental, un laboratoire où les chercheurs de l'INRIA peuvent essayer leurs excellentes idées, mais qu'on ne peut pas considérer comme un outil de travail permettant de produire des logiciels aspirant à une certaine pérennité. VisualStudio est un outil qui permet de travailler d'une manière efficace. Désormais une version libre existe. Pourquoi ne pas s'en servir ?
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
Si tu lis le papier de Castagna que je t'ai indiqué, tu verras que la question de la covariance et de la contravariance ne sont pas des notions opposées mais qu'elles recouvrent des objectifs de nature sémantiquement différentes.
Par ailleurs je ne promeus pas ici Eiffel comme un langage expérimental, mais comme un outil disponible aujourd'hui pour produire des logiciels, avec ses défauts. Comme tu le dis, on peut bien aussi utiliser C++... Le vrai défaut d'Eiffel, comme cela a été pertinemment évoqué ici, c'est sa relative pauvreté en bibliothèques et en frameworks.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 3.
http://www.di.ens.fr/~castagna/pub.frame.html
Si j'ai bien compris, l'avantage de la contravariance est qu'elle ne pose jamais de problème. Son inconvénient est qu'elle prive de toutes les possibilités où la covariance serait valide. Mantenant ce sont les compilateurs Eiffel qui analysent le code pour détecter les possibles catcalls. Choisir la contravariance comme l'ont fait les créateurs de Sather semble résulter d'une analyse, sinon simpliste, du moins manquant de finesse. On se prive de possibilités, de la même manière que d'autres langages n'implémentent pas l'héritage multiple, pour ne pas compliquer l'implémentation du compilateur.
Ceci dit, il est assez fréquent que j'entende parler de Sather là où se trouvent des discussions sur Eiffel. Existe-t-il des compilateurs Sather qui permettent de produire des applications de la vie réelle ? Y en a-t-il qui de plus proposent un environnement de développement avec quelques facilités ? Et y a-t-il des applications ou des services informatiques qui utilisent Sather ? Ces questions sont sans malice, j'avoue seulement mon ignorance dans ce domaine.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
Pour l'enquête psycho-sociologique, je me déclare incompétent :-)
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 4.
Je me permets de remarquer que la production de logiciels libres ne souffre pas des mêmes soucis. La qualité tout de suite, c'est bon à prendre.
[^] # Re: Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 2.
Je ne vois pas pourquoi il faudrait attendre l'arrivée des langages objet à prototypes pour coder avec des outils confortables et puissants.
# Goûtez-y !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 10.
D'abord, en vitesse, les principales caractéristiques, maintes fois exposées, d'Eiffel.
La programmation par contrat permet de spécifier les applications ainsi que de les documenter. En passant, la gestion des exceptions est d'une remarquable simplicité : la génération d'une exception est la violation d'une assertion. Quand j'entrevois le pastis de la gestion des exceptions en, par exemple, Java, ça ne me donne pas envie. L'héritage, multiple bien sûr, ne simplifie pas la vie de ceux qui implémentent des compilateurs Eiffel ; mais celle du reste du monde. La généricité (qui peut certes être simulée par l'héritage, surtout quand il est multiple...) évite la duplication inutile de code et concourt à sa lisibilité.
Si l'on cherche un langage ayant ces trois caractéristiques, il n'y a pas pléthore. On peut ajouter une syntaxe d'une lumineuse clarté, héritée de Simula, de Pascal et d'Ada, l'identité entre la classe et le type, associée à l'unicité de leur représentation par un fichier ainsi que les nombreuses facilités, anciennes ou plus récentes, telles que l'héritage d'implémentation.
Le principal manque de la spécification d'Eiffel concerne les concepts de concurrence et d'application répartie. En ce qui concerne la concurrence, EiffelStudio implémente les threads et permet donc le multitâche. Bertrand Meyer a proposé une conception unifiée de ces concepts sous le nom de SCOOP (Simple Concurrent Object Oriented Programming). Son implémentation offrirait une remarquable facilité d'utlisation aux programmeurs, au prix d'une terrible difficulté pour ceux qui auraient à l'implémenter dans un compilateur.
Bertrand Meyer, le géniteur d'Eiffel, occupe désormais une position académique en tant que titulaire de la chaire de Génie Logiciel à l'Ecole Polytechnique Fédérale de Zurich. Parmi les projets de ses collègues ou élèves, on trouve :
une ébauche d'implémentation de SCOOP, SCOOPLI par Volkan Arslan
http://se.inf.ethz.ch/research/scoop.html
http://eiffelzone.com/esd/scoopli/index.html
AutoTest, un outil de test automatique de code Eiffel, écrit par Andreas Leitner et Ilinca Ciupa comme project de recherche
http://se.ethz.ch/people/leitner/auto_test/
Erl-G, une bibliothèque permettant la réflexivité et l'introspection du langage écrite par Andreas Leitner.
http://se.inf.ethz.ch/people/leitner/erl_g/
Il y a plein d'autres projets concernant Eiffel sur le site de l'ETH. On peut aussi y découvrir des jeux développés par les étudiants comme sujet d'étude.
Ces derniers temps, Eiffel Software promouvait les qualités du langage en tant qu'elles facilitent les pratiques d'outsourcing et d'offshoring, propres à faire grincer les dents de beaucoup de monde, à commencer par les miennes... Cette facilité de sous-traiter le travail logiciel liée à la capacité de bien spécifier, en particulier grâce à la conception par contrats, est une chose à prendre en compte dans l'élaboration collective de logiciels libres. De plus, l'extrême lisibilité du langage, y compris par les non-spécialistes, peut permettre une communication fructueuse entre les praticiens des aspects métier et ceux de la programmation. Je pense qu'un projet métier libre, genre dont on peut espérer la prolification, tirerait grandement parti des qualités d'Eiffel dans le cadre d'un travail distribué et décentralisé, qui sont les caractéristiques fréquentes des projets libres.
Je ne vous parle pas de l'environnement de développement, faites-vous en une idée par votre propre pratique. Je risque d'oublier des délices, entre la navigation dans le code et les multiples outils et facilités qu'il offre et qui font du développement sous EiffelStudio un vrai plaisir. Jusqu'ici, je me retenais de le dire, la chose étant purement propriétaire, maintenant je peux y aller !
En gros, j'ai l'impression, purement subjective probablement, que certains d'entre vous trouvent que la mariée est trop belle.
[^] # Re: Différences par rapport à l'ancienne version "Free"
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 8.
[^] # Re: Proprio vs libre
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 6.
# Encore un autre !
Posté par Philip Marlowe . En réponse à la dépêche EiffelStudio devient un logiciel libre. Évalué à 6.
http://gobo-eiffel.sourceforge.net/gec/index.html
https://sourceforge.net/projects/gobo-eiffel/
Ce compilateur est réalisé par Eric Bezault, le créateur de la bien connue bibliothèque Gobo pour Eiffel, qui a pour ambition d'être compatible avec tous les compilateurs Eiffel en activité. Il est réalisé sous la Eiffel Forum License, version 2, compatible GPL, et qui est tellement concise que je peux la citer intégralement ci-dessous :
[^] # Re: Je trouve que l'UE se trompe.
Posté par Philip Marlowe . En réponse au journal L'UE se méfie de Vista. Évalué à 2.
Mais c'est une conversation d'arrière-garde, Netscape est mort, c'était là le but visé. Il a laissé une descendance...
[^] # Re: Je trouve que l'UE se trompe.
Posté par Philip Marlowe . En réponse au journal L'UE se méfie de Vista. Évalué à 2.
Quand te mutent-ils au service juridique chez MS ? Même si ça compromet tout emménagement de ta part dans le New Jersey...
[^] # Re: Comme dirait mon prof...
Posté par Philip Marlowe . En réponse au journal Le laptop du MIT est indécent .... Évalué à -2.
[^] # Re: Nul n'est prophète en son pays
Posté par Philip Marlowe . En réponse à la dépêche Mandriva licencie 18 personnes dont Gaël Duval. Évalué à 7.
C'est bien d'émailler un commentaire indigné et un peu austère d'une note d'humour. En tout cas merci, j'ai bien ri.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Philip Marlowe . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Ca me rappelle la signature que j'utilisais avant, qui me venait de réflexions que je me faisais en tant que programmeur Eiffel devant les discussions acharmées de tenants de Java, C# ou C++, surtout quand ils abordaient les notions de virtual : "Se prendre pour un compilateur, c'est un trouble du comportement".
Sinon je saisis l'occasion de te remercier et de t'applaudir de faire connaître le travail de Benoît Sonntag ainsi que pour les essais que tu as écrits autour des concepts de Lisaac,qui donnent lieu à de fructueuses réflexions. Je regrette seulement de ne pas avoir plus de temps à consacrer aux travaux pratiques autour de ça. Merci aussi à nicO, pour les mêmes raisons.
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Philip Marlowe . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Même si ce que tu racontes était vrai, si le programmeur met 10, 100, 1000 fois plus de temps pour faire la même chose... En plus le fonctionnement des optimisations mises en places par le compilateur peuvent être garanties dans leur fonctionnement, et même parfois carrément être prouvées. Ca engendrera des bugs de pus haut niveau...
- Ne pas se focaliser uniquement sur les performances, la plupart des langages compilés ont aujourd'hui des performances largement raisonnable et suffisantes.
Tu donnes l'impression de ne pas avoir compris l'utilité de Lisaac : c'est un langage destiné aux couches de bas niveau, et postulant de ce fait au remplacement du C ou le concurrençant, mais permettant une écriture à partir de concepts plus élaborés. Ce n'est pas un langage alternatif aux langages du genre Python, C#, Java ou Eiffel. Ou alors là, c'est moi qui ai mal compris.
[^] # Re: Euh ...
Posté par Philip Marlowe . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Ça tombe bien, il se trouve que c'est le cas.
[^] # Re: Pffff
Posté par Philip Marlowe . En réponse à la dépêche Copie privée des DVD : la cour de cassation a tranché !. Évalué à 3.
Pour les révisions des procès, c'était une boutade. Même si ça s'appliquait aux juridictions civiles, à raison de quelques unes par siècle, on a le temps de voir venir...
[^] # Re: Pffff
Posté par Philip Marlowe . En réponse à la dépêche Copie privée des DVD : la cour de cassation a tranché !. Évalué à 1.
Ce qui fait au maximum 6 jugements de tribunaux nationaux, avant d'éventuellement poursuivre devant une juridiction européenne, là j'ai moins de notions, ou une éventuelle révision du procès (comme dans l'affaire Seznec, qui n'a pas suivi ce schéma par ailleurs). En principe, quand on en arrive là, un certain temps s'est écoulé...