gloups a écrit 163 commentaires

Cela m'agace assez de voir que l'on re-invente sans cesse ce qu'etait HTML à l'orgine.
Le HTML est un media indépendant à l'aide de balise indépendante du formalisme (, ... (les tag font ne sont qu'un ajout issue de la volonté de certains acteurs par le passé...je ne citerai personne...)

* HTML : Contenu
* CSS : Formalisme de mise en mise en page.
* Javascript : c'est un ajout pour permettre l'interraction coté client.

Le meilleur format de representation de l'information est bien HTML, rien ne sert d'inventer d'autre format que de propriatairisé les formats....

Le seul manque :
* Pouvoir intégrer les images dans le meme fichier ;-)

Je suis totalement en phase avec cette dernière approche, c'est une des raisons pour laquelle je m'interesse à lisaac.

Pour les break/return ..., je ne suis pas certain que l'on puisse l'assimiler à un goto qui est explicitement une mauvaise pratique, je l'assimilerai plus à une simplification de conditionnelles imbriquées, pratique de mon point de vue saine, d'ailleurs die_with_code() existe et effectue cette action bien au delà du bloc puisqu'il s'agit de la sortie intégrale du programme.
Mais il semble s'agir effectivement d'un choix conceptuel déjà tranché, aussi je ne reviendrais plus dessus.

Je souhaiterai par contre revenir sur la gestion d'erreur de manière plus générale. Contexte dans lequel les exceptions fournissent une solution élégante à la problématique :
1. La gestion d'erreur ne devrait pas être attaché uniquement à une phase debug, nombre de circonstances provoquent des erreurs, souvent lié au logiciel ou matériel sous-jacent, donc difficilement contrôlable et anticipable.
Prenons l'exemple de lisaac qui s'appuie sur des lib C, en cas d'erreur de la lib, lisaac devrait fournir un mécanisme permettant de trapper l'erreur et prendre la décision adéquat. Quelques types par defaut existent généralement (erreur de contrainte, Div/0, systeme, ...) .
Un de mes premiers tests lisaac a été l'utilisation de la ligne de commande, étonnant non ;-) ...; en itérant un cran trop loin (trop classique...), j'ai eu le droit à un magnifique core dump... . Je m'attendais plutot à erreur de contrainte ou erreur de Fctn sous-jacentes beaucoup plus explicite.

2. Le traitement d'erreur n'est pas forcement réalisé au même niveau que la détection et de survenance de l'évènement.. Il est donc nécessaire de pouvoir remonté la pile des appels.
Dans un système complexe, toutes les interactions ne sont pas forcement déterministe (en particulier quand on s'interface avec des éléments externes, il est alors pertinent d'avoir un mécanisme générique et simple d'emploi sans devoir spécifier à tous les étages les types d'erreurs attendus ... ;-)

3. Afin d'être traiter convenablement, l'information de contexte d'erreur doit exister au moment du traitement.

4. Une exception doit pouvoir remonter la pile d'exécution, jusqu'à son traitement éventuel.Si ce n'est le cas, le programme s'arrête avec sa pile d'exécution classique.

Dans ce contexte, Lisaac possède quelques embryons intéressants :
1. La programmation par contrat couvre effectivement bien la partie déclenchement d'exception à condition que l'on puisse ajouter un contrat sur affection de valeur et non uniquement en pre et post condition. Dans ce cas, de manière déclarative, il est possible d'exprimer une contrainte qui sera sujette à erreur et donc déclenchement d'exception.

Un exemple classique simpliste, la lecture d'un capteur doit retourné une valeur entre 1 et 10, Lors de la lecture, une valeur de 0 ou 11 déclenche une exception qui interrompra les appels en cours, jusqu'au niveau du controleur du système qui trappera l'exception pour re-initialiser convenable le capteur.

Dans ce cas, en pseudo algo, cela peut être ecrit :
...
Valeur = lecture()
si Valeur <1 ou Valeur > 10 alors
raise Hors_limite;
...

Je préfere nettement, la vision déclarative qui sépare nettement les cas d'erreurs ou exceptionnels de l'algo nominale sans pour autant terminer l'application.
Header :
Check Valeur < 1 ou Valeur > 10, sinon exception Hors_limite
Code :
...
Valeur = lecture()
...


2. La propagation et la capture de l'exception reste à définir. Le contexte de remontée ne doit pas créer de nouveaux objets (difficile en cas de memoire pleine...) mais devrait plutot s'appuyer sur un contexte statique réservé à cet usage.

3. Dans une vision volontairement unifiée, les exceptions pourraient apporter à lisaac :
- un mécanisme générique de remontée d'erreur :
- émis par les contrats, pouvant être utilisé en debug mais également en production.
- émis volontairement par le programmeur
- être le support générique de terminaison de bloc, méthode ou programme.



Sur les exceptions ADA (dans le même esprit que cellede PL/1).
La structure de l'exception ADA est a la fois :
- intrégré dans la structure syntaxique (fait partie intégrante du bloc)
- simple d'usage
- Le contexte transmis est statique, une exception levée et trappée doit être traité avant q'une autre puisse être levée. ceci évite les tentation de traitement complexe dans l'exception.....
pour aller plus loin dans ce sens, un commentaire sur le sujet :
http://www.les-ziboux.rasama.org/faq-ada-presentation.html#e(...)

Il s'agit encore d'un problème de lisibilité et non de défense d'ADA.
En ADA chaque bloc possède implicitement un section exception qui fait partie de la structure syntaxique. Il est donc aisé de mettre en oeuvre une exception; la programmation par exception est alors réalisable pour exprimer clairement un algorithme et ses conditions d'arrêts qui peuvent être analysés à differents niveaux y compris au niveau le plus haut pour re-initialisé un système par exemple.

Begin
...
Exception:
excep1 => traitement1()
End

Les langages plus récents ont cantonnés les exceptions à de la gestion d'erreurs tout en voulant adjoindre une mécanique de remontée d'informations. Ceci est louable mais alourdi considérablement la syntaxe au point de ne pouvoir l'utiliser pour autre chose de la gestion d'erreurs. Il suffit d'imbriquer 2 ou 3 blocs d'exception en Java pour se rendre compte du probleme.

Dans un système temps réel, les conditions d'arrêt sont multiples et souvent provenant de cause hors logiciel, il est plus simple de lâcher une exception et de la trapper au niveau adéquat pour reprendre le traitement sans devoir gérer la pile d'erreurs en cascade en retour de chaque fonction.

Effectivement, il est toujours possible de coder sans rupture de sequence, toutefois cela est souvent au détriment de la clarté de l'algorithme.
Un deuxieme argument souvent présenté est la difficulté de prouver le code contenant des ruptures... Il s'agit d'un probleme d'analyse de code donc hors de notre contexte...

Sachant qu'un code est ecrit une fois et re-lu N-fois durant la vie du programme en maintenance, je privilégie la facilité de relecture.
Une succession de tests complexes est plus lisible avec des break qu'avec une succession de clause else qui perdent leur sens au bout de 3 ou 4 conditions...

Un langage se voulant de haut niveau comme Lisaac me semble devoir faciliter la vie du codeur pour exprimer le plus simplement possible l'algorithme; le reste de la tuyauterie doit être le domaine de l'optimisation et du controle du compilo.
Pour qu'un langage soit attractif face aux langages installés, il est nécessaire qu'il puisse offrir les mêmes facilités, un pouvoir d'expression plus important (le minimum de mots nécessaires pour décrire un concept) et être lisible (un algo doit pouvoir s'écrire le plus naturellement possible).
Il me parait curieux, d'apporter des contextes très avancés comme ceux présentés dans cet article en laissant à coté des lourdeurs syntaxiques qui rebuteront nombre de programmeurs.

Curieux de tous les langages qui augmentent le degré d'abstraction, qui facilitent la relecture et qui limitent le nombre d'erreurs de manière auto, j'ai décidé de jeter un petit coup d'oeil à Lisaac. Visiblement destiné à de l'embarqué, on est très loin de ce que propose un ruby pour de la gestion, il possède nombre de qualité qui réduit fortement le coût de codage par rapport à du C. Il intégre la notion d'agent, cela me parait efffectivement une bonne piste pour cette cible.


Etant néophyte sur ce lisaac, je me suis limité à parcourir les doc et faire quelques tests typiques. Voici mes premières remarques sur les limite du pouvoir d'expression de lisaac actuellement :

- Pas d'élément de rupture de séquences (type return, exit ,...). S'il est facile de substituer ces éléments par des tests, il n'en est pas de même pour la lecture. Cela me parait un manque, il serait souhaitable que le compilo prenne en charge cette transformation.

- Je n'ai pas vu de notion d'exception (pas à la java, mais plutot à la ADA) ce qui permettrait de remonter correctement les erreurs provenant des couches basses sans ajouter une nuée de tests partout. J'en profite pour dire que gestion d'exception ne doit pas être simplement une gestion d'erreur comme cela a été implementé dans de nombreux langages. La programmation par exception releve plus du concept évènementiel et entrerait totalament dans la philosophie de lissaac de ce point de vue.
La gestion d'exception permettrait également de mieux traiter les retours d'erreurs. Un exemple, une fonction C embeddée dans le core provoque une erreur, j'obtiens actuellement un magnifique "core dump" lisaac pas très corporate ;-); Une exception me permettrait de trapper l'erreur et de prendre la décision adéquat. C'est une chose indispensable si le logiciel doit s'auto-géré.
Une dernière remarque sur l'intégration d'exception aux langages, le traitement d'exception doit faire partie intégrante de la structure de bloc du langage pour être lisible (les try catch et autres syntaxes de ce genre sont à prohiber..., l'approche ADA est certainement la meilleure sur ce point)

- Dans la même veine, les pre et post conditions peuvent être une réponse élégante aux conditions "exceptionnelles" (à rapprocher de la gestion d'exception). Dans ce contexte, elle ne doivent pas seulement être cantonnée au debug. Je verrais bien des pre/pro conditions + et - liée au débug ou toujours activée qui déclancherait des exceptions trappable.
Ainsi, si j'ai la fonction log avec comme pré-condition x > 0, Je ne doit pas avoir à faire de tests pour une valeur saisie < 0, une exception doit pouvoir être générée et trappé au moins pour relancer le processus.


Ces quelques manques liés à la jeunesse du langage devrait permettre faire augmenter le niveau d'abstraction de lisaac.

Sinon Bravo, c'est un bon début et la gestion des agents me semble une piste prometteuse.

J'ai fait migré à Linux pas mal d'amis non informaticiens et windowziens qui en avait marre de de devoir faire des interventions régulières sur leur système pour palier à l'instabillité dû aux multiples installations de n'importe quoi, aux anti-virus à changer tous les quatres matins, ...

Certain on eu Mandriva ou Fedora, d'autres Ubuntu et là on s'aperçoit que les plus techies s'adaptent bien à l'un comme à l'autre, par contre pour les moins à l'aise avec l'informatique, il y a un bien meilleur retour sur Ubuntu mais je ne saurais dire pourquoi...

Pour les informaticiens autour de moi et intialement sur Fedora, je constate également une tendance à passer sur Ubuntu pour son coté plus FUN. Pour ma part, après avoir de multiples distributions, j'ai atterri sur Ubuntu pour l'usage courant du fait d'un desktop (IHM + appli dispos) bien fini convenant bien à toute ma petite famille

Toujours 4 versions pour windows et une pauvre petite version qui ne fonctionne que sur linux ia32...
A quand un version qui soit compatible avec firefox en version amd64 ?

Il est amusant de constater que le principe des députés sur la précédente loi etait de transformer le frodeur en vache à lait.
(Lui faire payer après coup le cd au prix fort)

Avec ces amémagements, il va être dificile :
- de justifier la taxe pour copie sur les médias
- de taper trop fort sur les internautes sous risque de revolte
( quoique le petit Nicolas en serait capable... )

Ce qui risque d'arriver :
- quelques procès pour l'exemple
- et essayer de calmer le jeu, pour éviter que tous décroche de ce système fort lucratif

Dans ce cas, deux reactions possibles à priori :
1. touts les montons deviennent dociles (je n'y croit guère...)
2. Un mouvement d'ambleur est déclencher vers une economie de musique/video libre qui contraindra à terme les majors

Cette loi ne permettra de toutes manières que la survie pendant quelques années d'industrie qui n'on su s'adapter plus tot.

Le conseil ne juge pas la manière donc la loi a été votée me semble t-t-il mais uniquement la constitutionalité de la loi.

La manière d'arriver à cette loi est empreinte de mauvaise foi, c'est évident; il s'agissait d'un statégie pour faire passer la loi au mépris des députés et des citoyens mais tout en restant dans la légalité du processus. Le conseil n'a donc rien à dire...

Il ne reste plus aux citoyens qu'un boycott organiser sur les achats de CD et DVD et autres musique en ligne organisé sur 1 semaine, puis 1 mois, puis... et les majors demandront d'elles-même l'assouplissement de la loi...

C'est elles qui ont le pouvoir dans ce dossier, c'est sur elles qu'il faut faire pression.

L'occasion de refaire passer l'ensemble en douce ?
- recadrons des brevets
- une petite ligne interprétable permettant d'intégrer les Logiciel dans la reforme

Pas franchement clos...
1. Les brevets débiles existent toujours à l'OEB
2. Les fameux eicta vont faire pression de manière individuelle sur chaque pays... et hop une petite législation voté par l'UMP comme le droit aux ordonnances...
3. On est pas à l'abri pour une prochaine législature

Donc il faudrait une vraie directive avec de vraies limites...
mais comment faire ?

Et quelle a été la réponse ?

Sous Windows certains clients sont plus efficaces que d'autres, m'a t on dit...
Qu'en est-il sous linux ?
J'utilise btdownloadcurse.py, la classique en quelques sortes, pour recuperer ma distrib favorite ;-) mais peut-être y a-t-il plus efficace ?

Le seul problème de xpdf, gpdf, ... est qu'ils ne gèrent aucunement la notion de formulaire PDF qui voit de plus en plus le jour en PDF.

L'administration électonique, les demandes renseigments officielles passent de plus en plus par ce canal et là....il n'y a pas d'autre solution qu'acroread.

Si tu veux pouvoir construire un site institutionnel avec quelques briques type article, news, forum, ... les CMS classiques en PHP (mambo, Xoop, copix CMS, EZPublish, typo3, drupal, ...) te fourniront une base ouverte permettant d'étendre à volonté ton site page par page...
C'est un besoin classique mais ce n'est pas forcement le domaine de SPIP.

SPIP est orienté publication éditoriale, il permet donc de traiter la structure globale du site et permet d'intégrer du contenu non lié à une page mais catégorisé. Le site se chargeant de permettre l'accès au contenu. (La première grosse référence SPIP est le monde diplo et cela montre bien l'objectif de SPIP.)

C'est une approche fondamentalement différentes dans la manière de gérer le contenu.

La réponse officiel d'Adobe est que Windows 98 n'est plus supporté par M$ et qu'ils ne peuvent donc pas certifier un produit sur une plate-forme non certifiée. Devant les demandes, une version pour 98 semblerait à l'étude.

Pour Linux, la certification ne porte que sur quelques distribs, mais le produit reste compatible avec les autres...

Il est problable également que cette plate-forme deviennent au fil du temps comme une alternative crédible à celle de Billou et que temps du desktop est proche.

Perdu..., le commentaire précedent dit que MS peut attaquer openoffice en dehors du giron de SUN.
On peut imaginer :
- attaque d'un fork libre
- attaque de développeurs sur des contribs à OOO
....

Dans le sens contraire : EDF, GDF, La poste, ....

http://www.01net.com/article/268317.html(...)

Le problème avec les média, c'est que l'éveil est TRES LENT, ils se seraient un poil impliqués précédement, on n'en serait pas à espérer qu'un hypothétique pays s'oppose à chaque fois au passage en force.

Tous les éléments sont là pour que les média puissent s'y intéresser, même le canard enchainé, mais...non...personne...

En réponse à un courrier de novembre à notre brave ministre délégué à l'industrie daté de Novembre, voici en substance le résultat :
- n'ayez pas peur des brevets, il sont bon pour vous...
- Les garde-fous ont été mis en place pour garantir leur portée
- une commision ré-examinera l'impact sur le PME et les LL dans quelques années.....
- Ayez CONFIANCE.... (c'est presque ça)

Les paroles sont celles retrouvées dans beaucoups de dicours pro-brevets.

J'ai donc un gros doute sur l'ouverture de notre gourvernement sur le sujet...

Mouais, un bon anti-spam avec une règle avec les mots "brevet" et "logiciel" devrait faire l'affaire...

Rien ne vaut une vrai avanche de courrier qui eux doivent être :
- enregistré
- catégorisé
- ...

Dommage pour le service en question, mais cela a surement beaucoups plus de poids...

Ce qui est réellement impressionnant, c'est le nombre de de trouvailles pour faire passer les choses en force.

Cela veut donc dire que les "standards" de l'OASIS ne seront plus utilisés => fin d'un organisme normalisateur ?

Dans les courriers renvoyés par le ministère de l'industrie, la reponse n'est clairement pas dans ce sens :
- on sait ce qui est bon pour la france
- ayez confiance...

Je pense qu'il y a un gros lobby derière tout cela...bien incrusté avec cette dimension phénoménale qui est d'entendre le bon peuple mais de ne surtout pas l'écouter... voir tous les derniers passages en force législatifs.

L'avenir est ce qu'on en fait, ...
c'est pourquoi nous serons responsable même si l'option 3 arrive...