Philip Marlowe a écrit 1184 commentaires

Ça fait trois fois au moins que tu racontes la même ânerie, sur le ton docte de l'expert : le langage C n'est pas une machine virtuelle, on peut plutôt le considérer comme un assembleur portable.

Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités.
Les contrats sont dans la spécification initiale du langage Eiffel (à une époque où il n'y avait encore aucune implémentation). SmartEiffel est une implémentation particulière de ce langage. De plus en plus particulière...

Encore merci, Patrick_g, pour ce journal didactique, documenté et agréable à lire sur le nouveau noyau Linux. Comme toujours !

Oui, et au train où vont les choses, je ne serais pas étonné que Lisaac soit bientôt plus utilisé que SmartEiffel... Avec la version 2, tout le monde a fui. Il y a même un programmeur SmartEiffel 1.1 que je soupçonne de pulsions homicides contre le team depuis que toute la compatibilité entre les versions a été jetée aux orties. Il avait fait un gros projet qui, je crois, était une interface graphique de programmation pour le langage Ruby. Mais c'est une autre histoire...

Bien sûr que non. Avec un langage qui propose des assertions par contrat on peut éviter la plupart de ces call sur null.

Chez Eiffel Software, qui propose un compilateur Eiffel, donc avec la programmation par contrat (qu'on utilise en produisant des assertions), ils ont dû trouver, mais ils ne doivent pas avoir ton niveau, que celle-ci ne permet pas totalement d'éviter les void calls. C'est pourquoi, avec la dernière mouture du compilateur/environnement de développement, il y a un mécanisme spécifique pour résoudre le problème avant la compilation.

Un peu de lecture :
http://qconlondon.com/london-2009/presentation/Null+Referenc(...)
http://www.ddj.com/architect/219500827?cid=RSSfeed_DDJ_All

Alors, oui, éviter les void calls avant l'exécution, ça vaut le coup. Merci à l'équipe de Lisaac pour ça. Et non, le recours aux contrats et autres assertions ne peut pas les éviter totalement. C'est le totalement qui est important.

Incidemment, mettre les noms de classes et de types en majuscules ne me dérange pas, c'est déjà ce que je fais :) Je sais, je suis minoritaire...

Ce qui m'amène à cette question: pourquoi as-tu commencé d'en parler ?

Lisaac est donc maintenant compatible 16, 32, 64 bits et non plus seulement 32 bits.

Je ne vois dans cette phrase rien qui revendique un quelconque caractère révolutionnaire ou avant-gardiste. Nulle part il n'est demandé au lecteur de s'extasier devant la caractéristique annoncée. C'est tout bonnement de l'information, il n'y a pas de quoi péter un câble, ou le trollomètre.

désolé, on va pas s'extasier sur le support 16 ou 64 bits

C'est que tu ne vois pas l'intérêt de pouvoir utiliser un langage de haut niveau qui permet de faire de la programmation système, proche du matériel, et qui permet d'adresser des cibles en 16, 32 et 64 bits. Si tu n'en as pas besoin, on ne t'en veut pas, c'est juste que ce n'est pas ton problème.

Ceux qui font de la programmation pour l'embarqué peuvent être autrement intéressés.

Dans une de mes machines, des trous sont disposés en quinconce, je regroupe les cotes en x et en y. Ce n'est pas follement indispensable mais ça me plaît et je trouve que ça améliore la lisibilité en condensant un peu le code là où il a peu d'intérêt algorithmique en regroupant des termes de même nature.

dx1 := -600; dx2 := -124; dx3 := 352
dy1 := 1025; dy2 := 1300; dy3 := 1575; dy4 := 1850
-- dz := 0

puis par la suite :

create Result.make_from_array
(« create {POSITION_ROBOT}.make (dx1, dy1, dz),
create {POSITION_ROBOT}.make (dx2, dy2, dz),
create {POSITION_ROBOT}.make (dx3, dy3, dz),
create {POSITION_ROBOT}.make (dx1, dy3, dz),
create {POSITION_ROBOT}.make (dx2, dy4, dz) »)

ou

aller_xy_absolu (x, y: INTEGER) is
do
x_consigne := x; y_consigne := y
[...]
end


Voilà, c'est du sucre syntaxique, pas de quoi verser le sang, mais je trouverais dommage d'avoir à s'en passer par je ne sais quel intaigrisme.

Dans le même genre, les points virgules sont autorisées en fin de ligne mais sont inutiles. Pourquoi les autoriser dans ce cas ? Je n'ai pas le droit de mettre un point d'interrogation à la fin de ma ligne, pourtant, on pourrait l'ignorer de la même manière.
C'est pratique de les autoriser, cela permet par exemple de grouper plusieurs instructions sur la même ligne aux fins d'améliorer la lisibilité.

As-tu pensé à des entrées et sorties déportées genre Wago ? Tu en as des purement passives et d'autres ayant un comportement autonome programmable. Il y en a même qui sont livrées avec un système d'exploitation RT-Linux.

Pour celles qui sont passives (série 750-3xx) l'USB n'est pas disponible directement mais tout le reste est OK (Ethernet, RS232, RS485, Profibus, Can, etc.). Avec un module de tête RS232 (de tête 750-312 ou750-316) si tu utilises un convertisseur USB/série ça correspond à ta description. Attention, c'est du matériel professionnel, donc assez cher. Il faudra aussi te trouver ou te faire un soft exploitant le protocole Modbus sous Linux, mais ça ne doit pas être la mer à boire, vu que les specs sont publiques.

http://www.wagocatalog.com/okv3/index.asp?lid=3&cid=13&a(...)

Ce genre de matériel est proposé par plein d'autres fournisseurs, comme Phoenix Contact, par exemple.

Ce n'est pas moribond, c'est marginal. Je m'en sers pour mon boulot mais ne comptez pas sur moi pour en faire un plat, une fois que tout le monde aura admis l'aveuglante évidence que c'est le meilleur langage du monde.

Sinon, question compilateur c'est vrai qu'il n'y a pas foule, mais il n'y a tout de même pas que EiffelStudio de Eiffel Software, il y a aussi GEC (Gobo Eiffel Compiler), pas assez avancé pour être utilisé en production et tecomp, The Eiffel Compiler qui est à la fois un compilateur et un interpréteur et qui n'en est pas encore à la version 1.0.

Je me suis renseigné : assister à trois conférences n'est pas obligatoire.

En commande groupée il était à 80 €.

Bien Maître.

Euh tu connais beaucoup de bibliothèques modernes ou langages modernes qui utilise des codes d'erreur ?

Ben oui au moins Eiffel que je connais un peu. La Bibliothèque GOBO propose dans KL_EXCEPTION une catégorisation des exceptions. Elle permet aussi d'engendrer ses propres exceptions, pour décider que tel événement se produisant dans tel contexte est anormal et doit lever une exception.

C'est du Eiffel, pas du C ou du C#. Mets-toi dans le cas ou openFile viole un contrat et lève une exception.

Cette manière de gérer les exceptions se trouve dans Object Oriented Software Construction de Bertrand Meyer (première et seconde édition) qui, il est vrai, ne sait pas bien faire les API.

Un exemple concret en Eiffel. Quand j'ouvre des fichiers qui sont censés exister, dans le cas où justement ils existent, il arrive que le système d'exploitation échoue à les ouvrir. Ma procédure d'ouverture est munie d'une clause de sauvetage qui permet plusieurs tentatives avant d'abandonner ou de retenter la chose différemment.

J'ai des clauses de ce genre aussi pour la gestion des dll externes à mes programmes et en général pour la gestion des résultats dont la fourniture est externe à mes programmes.

Ah oui je l'ai retrouvé, mais je crois qu'il y en a d'autres : le WAGO-IO-IPC référence 758-870 qui fonctionne sous RT-Linux avec un processeur Geode.
http://www.wagocatalog.com/okv3/index.asp?lid=3&cid=13&a(...)

Le jour où il y aura une distribution « Mme Michu capable », à condition que l'essentiel de ses composants reste libre, on pourra continuer se la péter avec des distribs pour geeks, plusieurs pour pouvoir continuer à s'engueulertroller, qui bénéficieront des excellents drivers libres faits pour Mme Michu. Je ne vois pas pourquoi il faudrait fuir le succès, en l'occurrence même pas le succès mais sa seule évocation.

Est-ce que ça peut partir en sucette ? Oui, bien sûr, mais ce ne serait pas si simple de dévoyer le système. N'oublions pas qu'une bonne partie est sous licence libre vaccinante. Le danger principal que je crains, c'est l'épée de Damoclès des brevets logiciels. On a vu des exemples récents qui préfigurent ce qui se passerait si ceux-ci venaient à être adoptés en Europe. Cela consisterait à empêcher toute entreprise de gagner de l'argent avec des produits fondés sur des logiciels libres. Dans tous les cas si ça partait en sucette, il serait toujours temps de reprendre le maquis. Mais ce ne serait plus si simple...

Pour ma part je trouverais sain que l'on trouve des produits, rentables pour ceux qui les créent, sous Linux. Je suis très paresseux, aussi aurais-je déjà dû faire un journal avec des exemples récents de produits développés ou proposés sous Linux. Par exemple de la société américaine Delta Tau qui a développé sa nouvelle gamme de produits, des cartes d'axes destinées à la robotique et à la machine-outil sous Linux. Ce sera la gamme des Power PMAC. Elle a été développée avec Mono sous RT-Linux, parce que, a dit son développeur principal, RT-Linux possédait 99% des caractéristiques dont ils avaient besoin. Ils ont donc développé à façon le 1% qui leur manquait. Je ne sais pas s'ils ont assuré la publicité de ce 1% de code, et donc contribué. Le tout pour faire un produit qui se programme avec Visual Studio 8 sous Windows... Mais qui peut tout aussi bien être programmé de l'intérieur avec GCC.

Il y a aussi la société allemande Wago, qui propose, à côté de divers connecteurs qui sont son activité principale, des modules d'entrées et sorties déportées, fonctionnant avec la plupart, voire tous les bus industriels existants (Modbus sous toutes ses formes, Profibus, CANopen, DeviceNet, etc.). Ils proposent aussi ce genre de modules avec de l'intelligence embarquée, qui permettent de programmer selon la norme IEC-1161 (de mémoire...). Parmi ces modules on en trouve un qui est un mini-PC industriel qui fonctionne sous Linux. Voyez http://www.wago.com/wagoweb/documentation/index_e.htm il y a le 750-860 qui fonctionne sous Linux, mais il est un peu vieux, il y en a un plus récent dont j'ai la doc à mon lieu de travail, mais là je ne suis pas au boulot.

Tout ça pour dire que l'industrie, si la menace des brevets logiciels se dissipe, a toutes les raisons d'adopter significativement Linux. Légèreté, faible empreinte mémoire, outils de développement et bibliothèques accessibles, présence d'environnements temps-réel et plein d'autres avantages, j'ajouterais bien aussi celui de ne pas être à la merci des délires du service marketing d'une entreprise monopolistique, l'y attirent. Je pense en outre que l'industrie serait très intéressée qu'il y ait une distribution « Mme Michu capable » qui soit utilisée par un large public. Un large public, ça veut dire une large diffusion, des économies d'échelle, des produits éprouvés. Depuis quelques années, beaucoup d'éléments, à commencer par les PC, utilisés dans l'industrie ont leur origine dans des produits grand-public. Je pense, entre autres, par exemple au matériel destiné à la vision industrielle, dont les principaux composants sont issus de l'électronique grand-public.

Je ne vois pas en quoi nous serions perdants si Linux devenait un acteur de large audience. Ce qui pourrait principalement l'en empêcher, je le répète, ce sont les brevets logiciels, et ça se décide au niveau des institutions européennes. Les élections européennes, c'est l'an prochain...

Oui, c'est moi qui ai trop rapidement lu, la formulation est un peu ampoulée, et la faute, quand c'en est une, est coutumière ici. Mon œuilœil est passé trop vite. En utilisant la formule en dehors de, cela eut été plus clair.

Mais bon je suis un vieux ronchon qui passe son temps à corriger les autres et qui fait quand même des fautes, et pas toutes d'étourderie.

Ceci dit l'important est le sujet de la dépêche :)

Hors les industries culturelles quémandant cette loi [...]
Or les industries culturelles quémandant cette loi [...]

Dans un journal, ça peut à la rigueur passer, dans une dépêche censée avoir été relue ça arrache au moins un œuil.

Oui mais le clavier coûterait plus cher que tout le reste :) A quand une carte mère de netbook directement dans le typematrix ?

Tu dois confondre avec IsNotGood je pense. M'enfin pour quelqu'un qui ne commente que sur les news Debian ou presque et toujours pour defendre betement tout ce qui concerne cette distrib, je pense que tu ferais mieux de pas trop la ramener en effet.
Le type auquel tu réponds est un développeur Debian, assez connu en fait. Alors je pense que s'il la ramène, comme tu dis, à ce sujet, peut-être est-ce qu'il parle principalement de ce qu'il connaît. Ce n'est pas si répandu. Serait-ce un défaut ?

J'étais venu me réjouir de la sortie de Lenny (comme je m'étais réjoui de la sortie de Fedora 10, entre autres), et quand je vois ce genre de bataille de chiffonniers je suis un peu dégoûté.

Pour l'installation, Debian fournit désormais non seulement un CD pour l'installation avec Gnome, mais aussi (et c'est nouveau) un CD pour KDE et un autre pour XFCE et Lxde.
Pour KDE au moins, et je crois aussi pour XFCE, ce n'est pas nouveau. J'ai installé Etch avec le CD KDE.