C'est avec quelques mois de retard que je vous propose un rapide petit compte rendu de la réunion du projet Isaac ayant eu lieu du 25 au 28 juillet 2008 à Strasbourg.
Environ une quinzaine de personnes étaient présente, dont certains habitués de ces pages.

Divers questions y ont été abordé dans la chaleur moite et statique de l'été Strasbourgeois (35 °C, 0 Km/h de vent)

Le programme se trouve ici : http://lisaac.u-strasbg.fr/index.php/R%C3%A9union_25-28_juil(...)
Parmi les points fort, on pourra remarquer la présentation de travaux autour de Lisaac : externalisation des optimisations, Programmation par aspect, une GUI automatique, le fantastique binding OpenGL de Damien Bouvarel, le nouvel Isaac OS. Citons aussi, pour ne pas l'oublier, "Raton Parser" une librairie de mapping mémoire.

Eurent lieu quelques débats théologiques : Quid de la gestion des erreurs, de la compilation de module, de la gestion de la configuration des librairies, choix cornélien entre GIT et Mercurial, etc...

L'externalisation consiste, grâce à un pattern visiteur, de détecter des pattern au sein du graphe de code que traite le compilateur Lisaac, le compilateur travaillant en interne avec un langage minimaliste (une vingtaine d'instruction).

Isaac OS, qui n'avait pas bougé depuis 2003, a été entièrement repris par Jérôme Hilbert et Simon Fuhlaber, Jérôme ayant joué les prolongations pour implémenter le multitâche dans le système.

GUII, par Johnatan Ponté et Maxime Audrin est un très intéressant système d'adaptation automatique de l'organisation de l'interface afin que celle-ci s'adapte à toute résolution : elle construit un arbre abstrait reprenant l'arbre réel des widgets de l'interface et le transforme en arbre concret pour redessiner l'interface. Outre l'aspect de calcul sur l'arbre, ce projet utilise des possibilités uniquement offertes par Lisaac et plus largement le paradigme objet à prototype.

Vous trouverez les slides ici : http://isaacproject.u-strasbg.fr/download/2008Meeting/



Lisaac est encore en cours d'évolution et donne toujours lieu à des réflexions diverses sur le génie logiciel, l'expérience que l'on a accumulé avec d'autres langages, les extensions qu'on aimerait avoir.
Quelques liens pour illustrer les débats ayant eu lieu :
http://lisaac.u-strasbg.fr/index.php/Aspect_programming
Les présentations de Nicolas Boulay rassemblées ici : http://lisaac.u-strasbg.fr/index.php/Pr%C3%A9paration_r%C3%A(...)
Les Fallback de Mildred : http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Fal(...)

Enfin, n'oublions pas l'impressionnant port OpenGL réalisé par Damien Bouvarel (que vous trouverez sur le repo git), qui nous avait déjà gratifié d'un tout aussi impressionnant compilateur Prolog générant du Lisaac.

L'ensemble des présentations présentés durant cette session sont maintenant disponible sur

C'est le débat sur la gestion des erreurs qui m'a le plus marqué, surtout au vu de mes expériences récentes : j'ai été affecté deux mois sur le travail de test d'un énorme logiciel de gestion commerciale, et largement sensibilisé à la vision fonctionnelle du développement logiciel. Du débat que nous avons eu lors de cette réunion, il ressortait, après étude de tous les systèmes de gestion d'erreurs existant, qu'aucun n'était réellement satisfaisant.
Le débat est d'ailleurs né ici même, puisque c'est Nicolas Boulay qui nous a un jour posé la question.
Le système par contrat de Lisaac/Eiffel, est gênant pour son approche "le contrat n'est pas respecté pas donc je crash", mais intéressant dans sa capacité à chercher la cause d'une erreur 20km plus loin.
Le système à exception de Javouille est intéressant dans sa capacité à faire remonter une erreur, à la capter. Le problème est que c'est un système qui peut vite être très mal utilisé, et pour travailler sur des projets de plusieurs millions de lignes en Java/J2EE, même en environnement très contrôlé, cela devient vite très problématique.
Typiquement, Hibernate perd la connexion à la base, il charge des null dans les objets et l'appli part en carafe...
Le errno est intéressant, pas de rupture de contexte, pas de mort du signaleur, mais difficile de savoir d'où ça vient.

Récemment dans mon entreprise, j'ai beaucoup travaillé avec les fonctionnels, et j'espère d'ailleurs continuer sur cette voie qui permet de prendre un recul très intéressant sur la capacité de l'humain de se représenter ce que doit rendre possible un logiciel, quel service doit-il offrir. Les fonctionnels que j'ai rencontré m'ont expliqué que, selon eux, les langages utilisés dans l'industrie étaient conçu pour faire plaisir aux développeur, mais pas "orienté client". En particulier la gestion des erreurs est un énorme problème : le logiciel doit se comporter de diverses manière en cas d'erreur logiciel survenu quelques part, mais pas forcément de façon bloquante : une souscription à un service sur son téléphone portable doit pouvoir marcher même si la base de données est momentanément hors d'usage, ou fournir le service au client, même si la banque n'a pas encore répondu.
Je ne parle même pas des erreurs qui ne remontent pas, ou remontent mal..

C'est pour cela qu'il faudrait se demander si l'invention d'un système d'erreur ne deviendrait pas nécessaire : on pourrait imaginer un système basé sur un moteur de règle, avec un arrière gout Prolog. Cela aurait l'avantage de pouvoir gérer des conjonctions d'erreurs, et au compilateur de déterminer les cas possibles d'interaction pour proposer aux développeurs de prévoir une réponse. Le moteur de règle serait intrinsèquement d'assez haut niveau pour être accessible au fonctionnel, qui pourrait alors faire des choix.
Reste qu'il nous manque un modèle, que nous implanterions alors sûrement dans le langage...

Quelques liens :
http://lisaac.u-strasbg.fr/index.php/Gestion_d%27erreur
http://lisaac.u-strasbg.fr/index.php/Reflexion_de_08/2008

http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Ges(...)
http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Ges(...)

> Lire le journal (67 commentaires, moyenne: 2,5).

Il est raciste, intégriste religieux, bouseux assumé et fier de l'être, inculte, persuadé qu'il détient la vérité de Dieu du fin fond des états-unis. Il a un blog, et il affiche fièrement qu'il est un gros beauf, j'ai nommé http://redneckrepublican.wordpress.com
Ce blog est effarant. On est partagé entre l'envie de rire, et la consternation quand on sais que pas mal de beauf au fin fond des états-unis, jamais sorti de leur campagne, sous éduqués pensent comme lui, et élisent le chef de l'état de la première puissance mondiale.
Il vit évidemment dans le Mississipi.

Son combat ? Les liberals, la gauche aux états-unis, le centre droit ouvert et eduqués.
Bien evidemment, Fox news dit la vérité (ben voyons !), Bush est un saint (!!!!) - ce qui fera sans doute drastiquement baisser le niveau de QI des saints de la chrétienté - et Obama est un nègre, c'est à dire un sous homme.

Il y a quelques billets d'anthologies, comme celui-ci où il explique que Dieu a créé le pétrole (bien évidemment, puisque Dieu à créé la terre en 6 jours), que les musulmans vont de toutes façons en enfer puisqu'ils ne reconnaissent pas Jésus (et en tant que gros beauf sous éduqué, il ne sait pas Jésus est un des prophètes les plus important pour les musulmans), et donc, merveilleux syllogisme, que Dieu a voulu le pétrole pour les américains... Mais pourquoi l'a t-il mis sous les pieds des arabes alors, et pas aux Etats-unis (qui en ont beaucoup moins) ? Pour éprouver les fidèles ?
Les voix du seigneur sont impénétrables...

Son billet 9 steps to identify liberals est tout aussi hillarant, surtout que nous français y sommes visés.
Racisme oblige (Dieu n'aime pas les noirs voyons, mais d'ailleurs pourquoi les a-t-il créés ? Pour servir les blanc ?), les noirs et asiatiques sont visés en premiers... Viennent les français, les gens avec un autre accent que le sien de gros beauf du fin fond de son pays de bouseux, les profs, les non chrétiens, etc....

Sa vision d'intégriste est simple : ceux qui ne sont pas intégristes comme lui vont en enfer, les autres au paradis. Bien entendu, il est parfaitement morale d'être raciste.

Heureusement, pour l'humour, certaines bonnes volontés, viennent allumer cet obscurantiste patenté pour se moquer de lui, mais de toutes façons il est totalement irrécupérable.

> Lire le journal (31 commentaires, moyenne: 3,1).

Mon cher journal, Je ne résiste pas au plaisir de te conter cette fabuleuse histoire de plaque d'immatriculation que le gouvernement veut changer car l'ancien arrive au bout, principalement à Paris.
Un système plus intelligent a donc été pensé : plaque d'immatriculation assigné au véhicule à vie, numéro national.

Quel scandale ! Car comment saura t-on de quel département j'ai éclo ? Je suis vendéen/mayennais et fier de l'être !! Je veux que mon département soit affiché en gros sur la plaque, pour affirmer mon attachement à la terre (qui ne ment pas, comme chacun sait).
Ainsi s'est créé un mouvement, association loi 1901 gorgée d'élus de tout bord (qui savent se rassembler pour les grandes causes nationales) "Jamais sans mon département !".
On a ainsi vu apparaître des tags rebelles envahir les centres villes, et les voitures de bourgeois.

C'est vrai, comment vas t-on repérer un vendéen (qui conduit n'importe comment, par définition), un parisien (qui sait conduire, avec un comportement dangereux) ?

Le gouvernement, dans sa grande magnanimité, a résolu à aider le pauvre homme à marquer son attachement à sa terre, en mentionnant obligatoirement le département... de son choix ! Avec le logo de la région correspondante !
Le récit :
http://www.liberation.fr/societe/0101165473-plaques-d-immatr(...)

Je me demande de quel département je pourrais me réclamer...
Et je me demande surtout ce que le snobisme et la honte des origines va impliquer...

> Lire le journal (110 commentaires, moyenne: 2,7).

Un court et très intéressant article dans Le Monde, rubrique opinion

Il suffit de regarder autour de nous, et de regarder dans le rétroviseur pour remarquer que les plus de 50 ans ont le mieux profité de la situation de paix discontinu qui a prévalue en Europe et aux Etats-Unis depuis 1945.
Profitant du boom économique, des logements pas cher, pour pas mal d'entre eux, acheté lors d'une période d'inflation sans précédent (celle des années 1970) qui rendait peu à peu les remboursement d'emprunt de moins en moins dolore, la génération de mes parents et leur ainés en sont arrivés à posséder plus de la moitié du patrimoine détenu par des particuliers.
Comme l'article le précise bien, on hérite souvent après 50 ans.

Louis Chauvel, sociologue, analyste de la crise de l'ascenseur social expliquait il y a quelques mois dans l'émission Esprit Public (le dimanche à 11h sur France Culture), que le pouvoir d'achat en immobilier des jeunes d'aujourd'hui, par rapport à leur salaire, est moitié moindre que celui de leur parents (il y a 25 ans).

La crise des subprimes, mais surtout la chute du marché de l'immobilier, si la baisse des prix en France se confirme*, risque de toucher les possédants de ces biens, donc, les vieux (qui en passant nous ont une fois de plus mis dans la m*** puisqu'ils ont élus Sarkozy).

L'auteur évoque une inflation qui risque de nous tomber sur le coin du nez d'ici peu.
C'est fort probable, car même une politique belliciste de la BCE - qui en a d'ailleurs pris le contrepied, en s'accordant avec la FED pour baisse les taux - dans les années à venir, va difficilement pouvoir nous éviter l'inflation qui suivra l'inondation de crédit, injecté en ce moment pour éviter la catastrophe, suivez mon regard...
"L'inflation est l'euthanasie des rentiers" disait Keynes, et ce pourrait bien être le cas.

En tout cas, aux états-unis, c'est bien parti pour, car l'immobilier baisse sans discontinuer, et les expulsions se poursuivent.
Malgré la récession, le temps que le déclin macro économique des USA se fasse, on risque bien d'assister à un transfert des richesses, une fois que le resserrement du crédit ce sera un peu calmé et la phase d'inflation démarrée.

Cela suppose beaucoup de chose, mais quelques part, ça ne serait pas plus mal...

* On peut se poser quelques questions, car si le marché de l'immobilier est totalement bloqué du fait de la raréfaction de crédit (j'ai un copain qui vient de se faire licencier économiquement d'un courtier en négociation de prêt, c'est concret, les banques prêtent plus), le marché locatif est toujours en crise, ce qui va impliquer qu'au pire les propriétaires pourront toujours se faire payer un loyer.

> Lire le journal (37 commentaires, moyenne: 3,6).

On en parle comme d"un sujet assez secondaire, mais un grande catastrophe serait bien en passe de se profiler à l'horizon : partout dans le monde on assiste à une surmortalité des abeilles, comme en rend compte Dennis van Engelsdorp[1], chercheur en agronomie à l'université de Pennsylvanie.
On assiste à une surmortalité de 30% par rapport à la normale, chaque années.

Rappelons que 80 % des plantes, et le même pourcentage de plante alimentaires nécessitent des polinisateurs, dont les abeilles fournissent les gros bataillons des 100 000 espèces qui remplissent ce rôle.

J'ai personnellement assisté ces dernières années à des manifestations extrêmement inquiétantes : j'ai vu des jardins fruitiés sans aucun fruit, et de nombreuses ruches que j'ai toujours vu en activité désespérement vide.
Mon grand père, qui fut apiculteur (amateur) pendant très longtemps, m'a affirmé ne jamais avoir vu en 70 ans une situation aussi critiques. Ses ruches qu'il a confié à un apiculteur plus fringant sont quasiment toutes mortes, sans avoir fait faute de les mal surveiller.
Les reproductions deviennent de plus en plus difficile...

Si la situation perdure, les conséquences sur notre société seront extrêmement grave !
Peut-être qu'avec quelques millions de morts, une sous-nutrition chronique, même dans les pays développés, on comprendra qu'il faudrait peut être cesser de mettre des pesticides partout ?

Devra t-on se mettre faire des abeilles OGM résistantes aux pesticides (de Monsanto, évidemment) ?

[1] http://www.lemonde.fr/sciences-et-environnement/article/2008(...)

> Lire le journal (58 commentaires, moyenne: 4,9).

C'est avec une grande tristesse que je viens d'apprendre la mort de Richard Wright, à 65 ans, d'un cancer.

Claviériste discret de Pink Floyd, Richard Wright a été pour beaucoup dans la définition du son moderne, a expérimenté toutes sortes de sons, poussé très loin les synthétiseur des années 70 (écoutez le solo de synthé dans Dogs - Animals), pour en faire autre chose que ce que nous proposait Jean-Michel Jarre ;-)

Mais loin d'être un expérimentateur de sons froids et techniques, c'était un homme doté d'une grande sensibilité, fragile, qui a composé des morceaux superbes et profond comme "The great gig in the sky" (Dark Side of the Moon).
Des délires sympa dans Ummaguma...

Et tant d'autres...

Bien que Pink Floyd ne fasse plus grand chose depuis pas mal d'années, c'est triste de perdre un tel musicien.

> Lire le journal (43 commentaires, moyenne: 3,1).

"Il y a deux type d'informaticiens : les informaticiens compétents, qui maîtrisent UNIX, et les autres..."

> Lire le journal (21 commentaires, moyenne: 3,2).

Bonjour, je cherche à écrire un petit programme permettant de découper des phrases en structure sujet - verbe - objet, ie. de découper ma phrase en groupe sujet, groupe verbal, et groupe objet.

Un exemple simple :
"Pierre et son ami ont fabriqué un avion en papier"
Ici, le groupe sujet est "Pierre et son ami" ,
le groupe verbal "ont fabriqué",
et le groupe objet "un avion en papier"

Un autre moins simple :
"Un employé de la télévision publique suédoise a découvert dans les archive, cet été, une vidéo inédite d'un concert de Jimi Hendrix"
Groupe sujet : "Un employé de la télévision publique suédoise"
Groupe verbal : " a découvert dans les archive, cet été,"
Groupe objet : "une vidéo inédite d'un concert de Jimi Hendrix"

J'imagine que ce genre de problème est un grand classique en TAL (Traitement Automatique du Langage), néanmoins, je ne parviens pas à trouver une doc claire et xploitable sur le sujet. Je manque aussi de recul sur l'ensemble des solutions existantes.

A priori, j'imagine que l'on peut traiter le problème simple de la manière suivante : Etant donné que je dispose de Morphalou, un arbre XML listant 600 000 mots et donnant leur nature grammaticale de chaque mot ("mangeaient" dans morphalou est défini comme le verbe manger à la troisième personne du pluriel, à l'imparfait de l'indicatif. De même "il" est un pronom personnel), j'imagine que je peux repérer des structures grammaticales schématiques et découper en fonction :
"Charles joue à la balle" : Charles = pronom personel (nom propre) ; joue = indicatif présent, 3ème personne du singulier ; à = préposition ; la = déterminant ; balle = nom commun;
Et donc de matcher que mon groupe sujet est mon pronom, mon groupe verbal mon verbe et mon groupe objet ma structure Préposition+déterminant+nom commun.

Le problème est que je peux avoir une grande variabilité dans ce genre de schéma. J'imagine qu'il est impossible de découper de grande phrase Desprogiennes (aller pour le plaisir : "'La femme est le produit d'un os surnuméraire', disait Bossuet qu'on ne saurait taxer de mysoginie étant donnée l'excellente compréhension qu'il afficha toute sa vie à l'endroit de la gente féminine, Huguenottes et catins exeptées"), mais au moins d'avoir des résultats probant pour des phrases à peu près simple.

D'où mes questions :
- Quels sont les principales approches utilisées pour résoudre ce problème (Prolog, Markov, ???) ?
- Existe t-il des cours, des docs exploitables sur le sujet ?

> Lire le journal (13 commentaires, moyenne: 4).

Ce sera principalement des liens... une start-up israëlienne, Lucid Logix, a conçu un processeur permettant de répartir les calculs sur plusieurs GPU, connectés en SLI.

D'après la société, cela permet de répartir linéairement les calculs. Ils veulent le proposer avant tout pour le grand public (j'en vois d'ailleurs pas trop l'intérêt, à part pour quelques extrémistes), puis pour le calcul (là d'accord).

Liens :

http://www.lucidlogix.com/technology/technologies.html
http://www.lucidlogix.com/
http://www.tgdaily.com/content/view/38410/135/
etc...

> Lire le journal (13 commentaires, moyenne: 4,2).

Eh oui ! Nous sommes sauvé ! Nous pouvons continuer à consommer comme avant, aller toujours plus loin dans le matérialisme le plus obtus, l'exploitation des ouvriers chinois, les guerres en afriques, etc...
Le choc énergétique n'est pas pour demain : la solution existe.

Le pied !

Fonctionnement/principe

Les diatomées sont des algues unicellulaires constituant l'essentiel de la biomasse du plancton en mer comme en eau douce. Ces sont elles qui sont à l'origine des falaises de craie ainsi que du silex.
Ce sont de fabuleuses nano-usines biochimique capable de fixer le CO2 par photosynthèse.
Comme les plantes terrestres, elles utilisent l'enzyme rubisco (Ribulose 1,5 bisphosphate carboxylase) pour casser le C02 et en récupérer le carbone,
lors d'un cycle biochimique que les spécialistes nomment cycle de Calvin.
Théoriquement le cycle de Calvin produit du sucre, mais la présence de l'enzyme acétylcoenzyme A carboxylase (ACCase) chez les diatomées permet de produire des lipides en cas de stress en calcium. De même, en cas de stress azoté, les algues vertes unicellulaire ont tendance à avoir le même comportement.

6CO2 + 12H2O + lumière -> C6H12O6 + 6O2 + 6H2O

La société GreenFuel Corporation, émanation du MIT (eh oui, encore eux ! ), a commencé à passer en phase industrielle. Ils ont conçu un système de bio-réacteur couplé à une centrale à charbon, qui envoie ses fumées de combustion dans ceux-ci au lieu de les balancer dans l'atmosphère.
Le bio réacteur est une sorte de triangle constitué de tubes, dans lequel barbotent les algues et le CO2 injecté.



Rendements

Le gaz injecté aux algues est constitué de 13% de CO2, ainsi que pas de Nox dont on essaie aussi de se débarrasser.
Non content d'absorber 80 % de Nox si exposé à une luminosité maximale, les algues retraitent jusqu'à 80 % du CO2... et 50% par temps couvert.

Pressées, on obtient une huile végétale qui, bien qu'assez visqueuse, peut être directement utilisés par les vieux moteurs diesels... ou les nouveaux s'ils deviennent conçus pour.
On obtient 75 % de la masse des algues en huile pur par simple pression à froid, 99% avec un solvant organique (qui augmente pour le moment les coûts).

Les algues sont environ 30 fois plus productives que le colza : unicellulaires, elles baignent en milieu aqueux, avec en suspension tout ce dont elles ont besoins.

Un chercheur a ainsi calculé que 38 000 km² de ce système (soit à peu près la surface de la région Pays de la Loire) permettrait de produire la consommation annuelle des USA !!
Les désert ne manquent pas, et un telle surface est assez facile à trouver.

Les calculs montrent qu'au maximum, le baril de biopétrole, coûte 120 $ !!!

Conséquences

Cette technologie a plusieurs intérêts majeurs :
- Le biopétrole devient avec ce système une sorte d'énergie solaire stockable.
- Le biocarburant produit est très propre (pas de souffre), et totalement biodégradable.
- On pourra difficilement mieux utiliser l'énergie solaire : la photosynthèse est un système fonctionnant depuis 3 milliards d'années, quand les mécanismes évolutifs valident à ce point un système, c'est qu'on peut difficilement faire mieux. Suffit de regarder l'équation bilan plus haut pour s'en convaincre.
- Potentiel de l'excès de CO2 pour en faire de l'énergie utilisable.

On peut craindre la réaction des industriels pétrolier. Depuis que je suis gosse, j'entends des histoires de créateurs de moteurs alternatifs au pétrole, ayant disparu bizarrement sans laisser de traces. En France, Total fait la pluie et le beau temps, et vu que le baril de pétrole à 500 $ leur assurera des bénéfices faramineux, ils préfèreront scier la branche de la société sur laquelle ils sont assis, à moins qu'ils se reconvertissent intelligemment. Mais vu leur inertie (corps de métier, complexes industriels, ...), j'ai un peu peur.

Un problème de cycles

Pour le moment, le système nécessite de bruler du charbon pour fournir du CO2 en grande quantité : d'une façon ou d'une autre, il faut fournir une concentration suffisamment de CO2 pur pour le faire barboter dans les tubes.
Il faut donc trouver le moyen de fournir du CO2 :
- Le charbon n'est pas l'idéal, c'est une énergie fossile, mais c'est très facile à bruler, on a l'habitude et on a qu'à brancher les fumées de sortie sur les bioréacteurs. En passant, on produit de l'électricité
- Le bois consomme beaucoup de CO2 en phase de croissances. Mais si l'on utilise cette source, au vu des quantité d'énergie consommées, il va falloir être vraiment intelligent, pour ne pas flinguer les sols. Il faudra replanter tout de suite, gérer intelligemment les essences d'arbres, les cycles. Vu les implications géopolitiques (on peut pas planter n'importe où), c'est tout de même risqué. De même, cela soutiendra la voiture électrique.
- Encore des algues ? De même, on pourrait les utiliser, soit en mer, soit en bassin, pour aller chercher le CO2 de l'atmosphère, de la mer (la mer absorbe chaque année 92 milliards de tonnes de CO2, et en rejette (pour le moment) 90). Une fois séchée, elle pourrait servir de combustible
- On pourrait coupler ces diverses solutions avec un pseudo mouvement perpétuel : l'apport énergétique venant du soleil, on peut toujours bruler une partie de l'huile produite, ça fera toujours de l'électricité.


Bref, il nous faut un poumon, qui nous sauvera peut être du réchauffement. car on aura forcément des émissions de CO2.

Business

C'est l'entreprise GreenFuel Corporation qui a lancé la danse. Les USA ont une vieille expérience des algues pétrolières : issu de travaux lancés à l'époque par la NASA.
GreenFuel passe en phase commerciale cette année, forte de son essai réussi sur le CoGen, une centrale de 20 MW au charbon.
Les américains qu'on caricature en gros pollueur deviennent de plus en plus écolos : ils évoluent beaucoup plus vite que nous, c'est dans leur culture.

En France, eh oui incroyable mais vrai, il y a un concurrent ! Comme quoi il y a du talent dans ce pays, encore que nos chers énarques ne nous ont pas encore planté le projet, ce qui ne va sans doute pas tarder, histoire de s'assurer une belle carrière dans le privé, devinez chez qui ?

Shamash, n'est pas vraiment une entreprise : c'est un projet de l'Inria avec le pôle de compétitivité Cap énergie, dans le midi, Ifremer, diverses équipes sur le territoire. Ils font la même chose, mais ont l'air moins avancé. Ils ont l'air de faire ça à la franchouillarde : on parle, on fait des
J'avoue que je ne sais pas ce que l'Inria fait là dedans, mais il y a plein de fric à gagner, ils ont tout à fait raison.
Malgré tout, espérons qu'ils ne vont pas planter la "poule aux oeufs d'or" comme les projets Caml, et Isaac (j'ai assisté au désastre de près, ils voulaient vendre Isaac OS aux chinois !!).
La différence, c'est que ça, c'est une véritable poule aux oeufs d'or.

Bref, préparez vous à mettre vos économies chez ces deux là, l'avenir leur appartient !

Dossier complet : http://www.greenfuelonline.com/news/Biofutur.pdf

(Merci à Will)

PS : je vous le met quand même, j'hésite, parce que c'est le Mal™ , ya du flash : http://www.biopetroleo.com/english/index2.htm

> Lire le journal (50 commentaires, moyenne: 3,2).

Recette de cuisine :

Prenez votre tit compilateur java et compilez ceci :


package test;

import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;



public class test {
public static void main(String[] args) throws Throwable {

ServerSocket ss = new ServerSocket(80);
Socket sc = ss.accept();
InputStream in = sc.getInputStream();
while (in.available()>0) {
System.out.print((char)in.read());
}
sc.close();
}


Notre ami Souhail, auteur de cette superbe idée, obtient :


GET /ADSAdClient31.dll?GetAd=&PG=IMSFRF&AP=1007 HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Accept-Language: en-gb

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)

Host: rad.msn.com

Connection: Keep-Alive

Cookie: ANON=A=CF913843612DEA578DFC67A5BFFFFFFFF&E=6a7&W=3; NAP=V=1.7&E=669&C=kGnDtOefhf_iJSC-y0FBk7Y86deypRj5Lh1yC8rv3rfHH9eeyL7l5A&W=4; MC1=V=3&GUID=f6ca2df261ffe48bace5912798df8420; MUID=E61F9D7499CE4E60985A13F6BF7883A0


Dégustez !

> Lire le journal (38 commentaires, moyenne: 4,5).

En revenant de Barcelone cette nuit, j'ai eu comme souvent une idée saugrenue d'un nouveau moyen de transport censé être écologique.

Le concept utilise deux moyens de transport : une espèce de mongolfière à l'hélium, et un planeur.

Imaginons donc un Nantes-Barcelone.

A Nantes, une cinquantaine de personne monte dans une espèce de mongolfière/dirigeable à l'hélium. Cette mongolfière monte en flèche à haute altitude.
( Pour la démonstration physique, faite depuis très longtemps : 1 mètre cube = 1 kg d'air, donc d'après la poussée d'Archimède, une personne équivaut à 70 mètre cube d'air (en gros).
La masse volumique de l'hélium étant de 0,1785 kg.m-3, il faudrait environ 8.10^3 m3 pour "porter 70 personnes". 8000 m3 équivaut à un cube de 19m de côté, ce qui n'est pas énorme).

A haute altitude (15 km par exemple), "attend" un planeur.
Celui-ci pourrait être monté de la même façon avec une mongolfière.
Ce planeur est tout de même équipé d'un petit moteur, pour rectifier la trajectoire, gérer les situations d'urgence.
Le planeur embarque alors les passagers, et utilise les couloirs d'air afin de planer jusqu'à sa destination.
Les planeurs sont extrêmement précis : les allemands les ont utilisés lors de la seconde guerre mondiale pour prendre un fort belge imprenable. Le planeur permettait d'atterrir avec une précision de 10 m sur un objectif, dirigé par un pilote entraîné, ce qui était stratégique à une époque ou l'hélicoptère n'était encore qu'un vague prototype.

Tout le voyage serait ainsi réalisé par la descente du planeur vers sa destination.

J'imagine qu'on ne pourrait pas forcément dépasser les quelques milliers de kilomètres avec cette méthode, ni être indépendant de la météo. Mais cela pourrait constituer un moyen de transport pas trop cher (hélium réutilisable, de même que le matériel).

C'est viable ?

(et non, j'ai pas fumé pendant le voyage)

> Lire le journal (80 commentaires, moyenne: 4).

Voici un exemple assez consternant de l'exploitation des pigeo^Wfan de MacGyver, qui a sûrement bercé l'enfance de pas mal d'entre nous, votre serviteur en tout cas.

J'imagine le pied qu'a du prendre le marketeux ayant lancé ce concept : vendre à quelques dizaines de cents, voire quelques dollar un pareil produit, ça doit être assez jouissif... de marger à un tel niveau.

Le capitalisme néolibéral crée de la valeur, camarade !

> Lire le journal (9 commentaires, moyenne: 4,9).

En l'an de grâce 2000 après JC nous avions 1 Dollar à 1,2 Euros et 1 Baril de Pétrole à 60 Dollars soit le Baril à 72 Euros et on payait 1,00 Euro / litre d'essence environ.

En 2008 après JC (toujours) nous avons 1 Dollar à 0,65 centimes d'Euro et 1 Baril de pétrole qui a explosé à prêt de 100 Dollars, soit le Baril à 65 Euros (Oups !) et on leur donne 1,35 Euros / litre d'essence.

Durant cette même période, les bénéfices de Total ont explosés.

Alors on fait quoi ? On diffuse l'information pour dénoncer ce scandale ?... ou on achète en masse des actions Total ?

> Lire le journal (57 commentaires, moyenne: 3,5).

C'est le titre d'un article lumineux, paru sur le site Agoravox.

Pour résumer vite fait, tout empire, pour assurer son hégémonie taxe ses vassaux afin de s'enrichir, et s'assurer de la domination de son armée sur ceux-ci.
L'empire américain a inventé un système novateur puisqu'aucune taxe n'a été levé sur nous, les vassaux. C'est en jouant sur la valeur du dollar que les états-unis dégagent une "marge", et peuvent ainsi acheter des biens au rabais en dehors de son territoire.

Le système monétaire à beaucoup évolué lors du siècle dernier : on est passé d'une stricte équivalence entre les réserves d'ors des banques centrales nationales, vers un système de taux de change à parité quasiment fixes (Accord de Bretton Wood, en 1944) dans lequel la monnaie de référence devenait le dollar. Il fut alors possible à la banque centrale américaine de jouer avec la planche à billet et ainsi accroitre leur puissance économique.

A l'heure actuelle, les états-unis assoient leur puissance sur une monaie se dépréciant sans cesse, mais utilisée pour payer la denrée qui joue le rôle de l'or du début du XXème siècle : le pétrole. L'immense majorité des transactions pétrole sont effectuées en dollar. Même l'europe achète des dollars pour acheter du pétrole au moyen-orient. Ce qui nous est profitable pour le moment vu la baisse continue du dollar.

Or, un mouvement de fond commence à s'amorcer ici ou là qui pourrait avoir des conséquences extrêmement retentissantes : certains pays commencent à penser à se passer du dollar pour payer leur pétrole. Certains pour des raisons politiques et beaucoup d'autres pour éviter d'être tributaire d'une monnaie qui se déprécie de plus en plus.
Et c'est l'Iran qui semble décider à lancer le mouvement : http://www.agoravox.fr/article.php3?id_article=36339

Comment les Etats-Unis vont-ils réagir ? Vont-ils tenter de trouver un prétexte pour attaquer l'Iran afin de sauver leur hégémonie ?
Quel conséquence, sur nos vies, dans les années à venir ?

On en parle quasiment jamais et cela pourrait bien être fondamental...

> Lire le journal (56 commentaires, moyenne: 2,6).

Il y avait, il y a encore 3 heures, un journal sur KDE 4, relevant un nombre de bouton élevé, sur une page de configuration du bureau.

Un débat mi-trollesque/mi-sérieux sur les interfaces utilisateurs y était né.

Ce journal a disparu.

Que s'est-il passé ?
- Un problème de donnés, du aux erreurs de jeunesse du nouveau templeet mis en production ?
- Une supression délibéré d'un modérateur ?

En tout cas je ne me souviens pas avoir déjà vu cela ?

(en espérant que ce journal ne sera pas supprimé aussi ;-)

> Lire le journal (57 commentaires, moyenne: 4,6).

Les langages de programmation actuellement utilisés par l'ensemble des développeurs, malgré l'amélioration des paradigmes et autres sucre syntaxiques , restent basés sur un certain nombres de primitives très restreint : Affectation d'une valeur en mémoire, calcul arithmétique sur celle-ci, branchement conditionnel.
Muni de ces axiomes, le code exécuté, même dans des langages fonctionnels, objet et autres, travaille sur les données qu'il possède à l'instant T, manipulant des contenus d'adresses mémoire : il s'agit d'une sémantique opérationnelle.

Les projets informatique grossissent, le nombre de bug et de coût de maintien avec, et c'est guère l'amélioration de sucre syntaxique ou paradigmatique des langages utilisés dans l'industrie, qui permettra de tenir la barre le plus longtemps possible.

Il y a deux ans, votre serviteur avait traduit les interview de Jarold Lanier et Victoria Livschitz , tous deux (à l'époque) chercheurs dans les laboratoires de SUN, critiquant le manque de sémantique des langages.
Jarold Lanier, en particulier, relevait judicieusement que les langages que l'on connait, ne sont que la virtualisation des câbles connectant les blocs logiques d'ordinateur primitifs comme l'ENIAC. Celui-ci préconisait une approche plus basé sur la reconnaissance de forme.

Victoria Livschitz répond à son collègue en déclarant que c'est le manque d'intuivité de la sémantique des langages de programmation modernes qui implique la difficulté de maîtrise des gros projets informatique.
Elle cite aussi l'impossibilité pour une brique logiciel de s'adapter à un nouvel environnement, et partant, de la difficulté de créer des architectures pérennes.
Le problème réside donc dans la sémantique des langages, et moins dans les méthodes de génie logiciel qui sont elles très étudiées.
Il n'y a qu'à voir tout l'engouement des journalistes et architectes pour les technologies SOA ( Source Wikipedia : Service_Oriented_Architecture) et autres méta-trucs.
Le talon d'achille de cette approche est que l'on retombe toujours sur du code classique : ce ne sont que des générateurs de code qu'il faut ensuite faire vivre, maintenir... quand le code généré a la qualité d'être lisible, voire non bogué..

Après quelques réflexions, principalement réalisées dans le cadre du projet Isaac, dont le langage offre des possibilités inédites et réjouissantes, j'en suis venu à vous proposer quelques mécanismes, issu de mon expérience personnelles et surtout professionnelle.
Je me contente de proposer quelques primitives de plus, principalement pensé pour des langages objets, mais probablement adaptable pour d'autres langages. Je ne suis pas à l'abri d'avoir réinventé la poudre, conçue ici et là. Certains mécanismes ne sont que la généralisation de concepts vu ailleurs.
Les utilisateurs de langage orientés aspect reconnaitront peut être des choses faisable avec cette approche, mais un des principes majeur de cette réflexion est d'essayer de rendre la programmation plus intuitive. Cela implique souvent des choix qui peuvent paraitre arbitraire : utiliser une syntaxe de type SQL dans un langage objet est sémantiquement équivalent à d'autres syntaxes plus adapté à la logique objet, mais surement moins intuitives, le SQL se rapprochant du langage naturel.
Il faut donc bien avoir à l'esprit que concevoir des briques pour langages de plus haut niveau est autant de l'informatique théorique que de la psychologie humaine : il faut rapprocher la sémantique d'un langage de l'imagination humaine et de sa psychologie.



Je précise un vocabulaire lisaacien que j'utiliserai dans le texte qui suit :
- Un objet ne doit pas être vu comme un objet d'un langage à classe. Il est cloné et non instancié, il peut changer dynamiquement de parents à l'exécution
- Un slot, est un élément d'un objet. C'est soit une donnée, soit une méthode. En Lisaac, une donnée peut devenir du code, et vice-versa.
- Un block est une fonction, ou peut être encore vu comme une liste d'instructions à évaluation retardée. Un block peut prendre plusieurs valeurs en argument et renvoyer plusieurs autres valeurs. Un bloc s'exécute lorsqu'on appel le message value. Bien évidemment, un block peut être promené un peu partout et exécuté comme on veut. Il peut aussi être transformé en donné (du type de données qu'il est censé renvoyer).
- la syntaxe - unevariable : TYPE := valeur_d_init [ code;]; représente une définition de la variable de unevariable de type TYPE, qui a l'initialisation vaudra valeur_d_init, et dont on définira un contrat, dont le code est contenu entre les crochet.
Ce code sera exécuté à chaque accès (en lecture ou écriture) sur la variable. C'est une sorte de primitive de type aspect. Nous pensons rajouter une primitive dans le compilateur permettant de n'exécuter du code que lorsque l'on écrit ou lit la variable, ce qui permettra d'éviter des traitement inutile. Pour plus d'information, se référer au manuel d'utilisateur de Lisaac


Commençons par le premier que j'ai pompé chez TrollTech. Vous avez sûrement deviné : le système de Slots/Signaux

Ce concept consiste à permettre à des élément d'interface graphique d'être connecté à la méthode d'un objet quelconque, afin de lui envoyer un message lorsqu'un évènement quelconque relatif audit élément survient.
L'intérêt est qu'on a pas à se trimbaler des références d'objet dans les diverses parties du code. On défini une connexion à l'initialisation, et il suffit ensuite d'écrire le code associé.
Ce modèle pose quelques problèmes dans une logique d'objet à classe, mais beaucoup moins dans une logique d'objet à prototype : en effet, un prototype n'est pas une définition formelle d'un objet qui deviendra vivant à l'instanciation, il est d'ors et déjà vivant dès que le programme début son exécution. Il n'y a donc pas de problème, à définir une connexion entre deux objets qui ne s'échangeront jamais leur référence.
Bien utilisé, cela permet une séparation propre du code selon un pattern MVC, en permettant en plus de threader tous les traitements.


Lisaac étant un langage permettant de rendre et prendre en argument des n-uplet typés, on pourrait imaginer des connecter des slot typés.
Par exemple, si l'on connecte un champ éditable d'interface utilisateur, et que l'on connecte l'évènement "modification du texte" à un slot, on pourra utiliser un signal qui renvoi la chaine du champ texte nouvellement modifié. Le slot connecté doit donc prendre une chaîne en argument.
C'est le compilateur qui fera la vérification de cohérence de type à la compilation.

evenement_changement_texte.connect block_a_executer;




Le mapping directionnel de données avec filtre

Très souvent dans les logiciels que j'ai eu à écrire, j'ai passé pas mal de temps à écrire de la glue entre éléments d'interfaces, voires objets, et organiser un système de rafraichissement, permettant de synchroniser deux couches d'objet, et autres variables. J'imagine que je suis loin d'être le seul...
Tous ces problèmes reviennent en réalité à définir une équation d'équivalence entre données.

Soit à poser axiomatiquement :
Donnée2 = fonction(Donnée1)

Ce mécanisme consiste donc à définir qu'un objet est toujours égal à un autre, via une relation fonctionnelle.
Cela implique, que toutes modifications de Donnée1 implique un traitement du type Donnée2 = fonction(Donnée1) mettant à jour le contenu de Donnée2, où qu'elle se trouve.

Cela peut être implémenté pratiquement grâce à des langages orientés aspect, comme AspectJ par exemple, où, en Lisaac, grâce à la possibilité de définir un contrat sur un slot, donc une variable.

liststr : LIST[STRING] := NULL [ Self := otherobject.unechaine.split ";"];
Ici, on défini que liststr est par définition otherobject.unechaine splité pour le ";". On est obligé (de par la syntaxe actuelle de Lisaac) de définir une valeur "de départ" pour ce slot.



Ce genre de détail à un intérêt majeur dans des interfaces de logiciel gestion, ou il suffira de définir des filtres entre les objets de la vue et du modèle, la vue se mettant à jour toute seule.



Une réflexivité sur les arbres

Lorsqu'on code, on travaille beaucoup sur les arbres, et force est de constater que c'est souvent galère.
Caml nous apporte deux outils fabuleux pour simplifier la difficulté : les types somme et le filtrage de type.

On peut définir un arbre très simplement :

type arbre = Feuille of string | Noeud of arbre;

Un filtrage de type nous aide ensuite à trier

let rec affichearbre = function
Feuille(s) -> print s
|
Noeud (n)-> affichearbre n;;

L'ajout de cette primitive éprouvée dans pas mal de langage aiderait souvent. On pourrait ensuite greffer d'autres mécanismes, existantes dans des logiciels comme CodeWorker.





La gestion du temps

En sémantique opérationnelle, le code exécuté à un instant T travail sur l'état de la mémoire à ce même instant T. Ceci implique que l'on doit en permanence mettre de côté des données, gérer des dépendances diverses et variées afin de simuler une possibilité qui nous semble naturelle pour l'esprit humain : recueillir des informations à partir des évènement de la vie passé, dont on se souvient

Un langage de très haut niveau possède une sémantique permettant de gérer la dimension supplémentaire qu'est le temps. On devrait pouvoir demander au programme de nous donner des informations calculée précédemment, mais sans nécessiter de les mettre de côté.
Prenons un exemple : on doit réaliser un traitement sur des milliers de fichiers XML (une petite manipulation de l'arbre). Ce traitement a la particularité de nécessiter deux passes, car le deuxième traitement, nécessite que le premier soit terminé sur tous les fichiers.
En effet, le document global est éclaté en milliers de fichiers qui s'appellent les uns les autres, on cherche à poser des liens hypertextes dans cette documentation à partir des données contenus dans les documents, puis à vérifier que ces liens sont bijectifs (un lien doit toujours renvoyer vers un document qui permet de revenir au document précédent).
On utilise un objet que l'on va créer pour chaque fichier et que le GC détruira pour nous.
Dans la sémantique du langage, on devrait pouvoir exprimer qu'une information donnée se trouve parmi tous les objets exécutés à tel endroit du code.

Lorsqu'un block de code contenant une boucle a exécuté un traitement sur tous les fichiers, on devrait pouvoir interroger ce block de code sur les liens qui ont été posés.



Pour illustrer certains autres mécanismes, je propose de jouer avec du pseudo-code autour de l'écriture de certaines partie d'un petit jeu de sous-marin : BlueWar est un vieux jeu des années 80 qui consistait à manoeuvrer un sous-marin pour descendre tous les bateaux ennemis qui trainait dans les parages. Ce jeu est sorti sur Amiga, Thomson TO8/TO9, et surement d'autres plateforme !
On disposait de plusieurs vues comme l'écran de commande, avec périscope, carburant disponible, lance torpille ou l'indispensable carte dynamique sur laquelle on voyait se déplacer tous les bateaux.
Vous pourrez avoir une idée de ce qu'était la première version de ce jeu sur Thomson TO8, en regardant quelques screenshot : http://www.logicielsmoto.com/viewsoftware.php?softid=57


Selon un modèle Vue-Agents, ce logiciel comporte

Une vue périscopique avec
- Profondeur
- Charge des batteries, niveau de réservoir
- niveau d'oxygène
- 2 indicateurs de torpille
- Direction
- Voyant avarie


Une vue radar


Une carte marine dynamique



On défini le terrain de jeu :

Agents/sma.li (le sytème multi agent dans son ensemble)

- mysubmarine : SELFSUBMARINE;
- vaisseau_ami : LIST[VAISSEAUAMI];
- vaisseauennemi : LIST[VAISSEAUENNEMI];




Puis le sous-marin que l'on va commander :

Agents/selfsubmarine.li :


Section Private

- time : TIME;
- profondeur : INTEGER := 0;
- charge_batterie : INTEGER;
- niveau_reservoir : INTEGER := 0 [Self := Self.modulo 300];
- moteur_electrique : BOOLEAN;
- vect_direction : VECT2D [(Self.module_zero > 1).if { warning "Attention, le module du vecteur direction n'est pas à 1 !\n"};];
- torpille_prete_à_lancer1, torpille_prete_à_lancer2,avarie : BOOLEAN;
- niveau_oxygene := 0 [Self := Self.modulo 100];
- vitesse : INTEGER;
- position : VECT2D [TIME.each_second {Self := Self+vitesse*vect_direction};]; // On colle une équation liant position, vitesse et direction
- pression_trop_importante : BOOLEAN := FALSE;
- periscope : BOOLEAN; // périscope utilisable en surface;






Equation d'Etat

Il arrive très souvent que l'on ait besoin de programmer une machine à état plus ou moins complexe. Ce qui est particulièrement pénible en procédurale, l'est beaucoup moins avec un langage objet. Mais cet exercice reste encore souvent fastidieux. On aimerait pouvoir définir un ensemble d'équations d'état, qui, du moment qu'elle sont cohérentes entre elle (et c'est là qu'on déplacera la difficulté), permet de définir un agent animé et autonome.

J'utilise mon exemple de jeu BlueWar, pour décrire, par l'exemple, ce que pourrai être une définition d'état.
La syntaxe, inspirée du langage Lisaac est totalement fictive et n'est même pas une proposition, prière de ne donc pas la commenter.

On définit une section dans le code où l'on va "poser" les "équations"

Section State

La section State ne définie pas des fonctions destinées à être appelées, mais des fonctions d'état fonctionnant à la manière d'un flip-flop : une fois enclenchée un état A, seul l'enclenchement d'un autre état B, avec une équation spécifiant que l'enclenchement B annule l'état de A, arrête cet état A.

Un état n'est donc pas un morceau de code exécuté à un instant T, mais la manière d'être de l'objet/agent, durable.
Je vois donc deux type de code définissable dans un agent :
- Soit l'exécution d'une équation d'état
- Soit l'exécution d'un block selon une équation de temps (que ce soit une fois par seconde ou plus souvent/irrégulièrement). Ce block sera donc réexécuté selon l'équation temporelle. Elle définira l'animation de l'agent.

On a les propriétés suivante pour un état
- Un état est paralellisable
- Un état est démarrable ou stopable arbitrairement.
- Un état est démarrable ou stopable par une équation d'état.


On définie ici une équation entre 3 états :

- gestionprofondeur : STATE_EQUATION := plonger ^ remonter ^ maintenirprofondeur;
On a ici défini que le sous-marin soit remonte à la surface, plonge, ou se maintient à la même profondeur (ou exclusif).


- init <- // appelé à la création
(

TIME.each_minute {
moteur_electrique.if {
charge_batterie := charge_batterie - 2;
} else { // La combustion consomme de l'oxygène
niveau_oxygene := niveau_oxygene - 2;
niveau_oxygene := niveau_reservoir - 2;
};
};

);


Définition des 3 états :


- plonge <-
(
TIME.each_second { profondeur := profondeur - 5;};

{profondeur > 300) => {pression_trop_importante := TRUE; plonge.off;}; // le sous-marin implose à cause de la trop grande pression

);


- remonte <-
(
// Code a exécuter à intervals réguliers
TIME.each_second { profondeur := profondeur + 5} until {profondeur := 0};

// Equation d'état
(profondeur = 0) => {
maintient_profondeur.on; // on démarre l'état "maintient_profondeur"
remonte.off; // on stop l'état "remonte"
};
);

La logique d'une définition d'état n'étant pas la même, il faut bien voir qu'on a ici deux définition parallèle, et non successives : toutes les secondes la profondeur du sous-marin va diminuer et l'équation sera régulièrement testé.
L'idéal serait que le compilateur réécrive le code de sorte que l'équation d'état soit exécuté à la suite du block {profondeur := 0}, car cela évite des tests régulier.


- maintien_profondeur <-
(
// A la surface on recharge les réserves en oxygène.
(profondeur = 0).if {
niveau_oxygene := 100;
périscope := TRUE;
};
);


On revient à du code plus classique où l'on définie les slots d'un objet :



Section Public

- set_direction nb : INTEGER <- // converti orientation horloge -> vecteur 2D
(
vect_direction.x := (nb*pi/6).cos;
vect_direction.y := (nb*pi/6).sin;
);

- lance_une_torpille <-
(
// ...
);


On défini 3 objets, sans leur code :

Agents/vaisseau.li

Agents/vaisseauEnnemi.li hérite de vaisseau

Agents/VaisseauAmi.li hérite de vaisseau


Le radar

View/Radar.li

On définie ici un mapping de données directionnelles, avec filtre :


radar : LIST[VECT2D] [select position from sma.vaisseau_ennemi, sma.vaisseau_ami where (position.module sma.mysubmarine) < 100;];

On notera qu'on a ici utilisé une requête OQL afin sélectionner les vaisseaux se trouvant dans un disque de 100 de rayon autour de mysubmarine


View/Carte.li


- points_vaisseaux : LIST[VECT2D] [Self := select position from sma.vaisseau_ennemi, sma.vaisseau_ami;];






L'ensemble des primitives que je propose ici sont assez difficile à exécuter pour un interpréteur et encore plus à compiler, en particulier pour les sémantiques de gestion d'état et d'interrogation de données sur traitement effectués dans le passé.
Cela nécessite une nouvelle race de compilateur doté d'une intelligence artificielle, capable de détecter pas mal d'incohérence dans le code et ainsi de prévenir des code qui s'emballent, boucles, et autres comportement ingérable.
Cela nécessitera aussi d'autres méta-machins, pardon méthode de modélisation et gestion de projets informatique.

L'avenir nous dira si tout cela est possible.

> Lire le journal (91 commentaires, moyenne: 1,6).

Je me dévoue puisque personne ne l'a fait pour le moment.

Les membres de l'association Linuxfr demandent des fonds afin d'acheter un serveur. je suppose qu'ils reviendront plus officiellement sur le sujet

Sur le blog de F. Penso
http://blog.penso.info/2007/10/09/linuxfr-crash-serveur-site(...)
est expliqué qu'un Serveur DELL a été trouvé.

Certains expriment leur doute et le risque d'envoyer de l'argent dont on connaitrait pas la potentielle utilisation.

Il nous faudrait donc savoir :

1) Quel est exactement la configuration, le prix, les coûts de maintenance de ce serveur de remplacement ?

2) Pourra t-on disposer publiquement des comptes officiel de l'association ? Pourra t-on être sûr que cet argent récolté ne servira pas à organiser une grosse fiesta autour d'un petit nombre (dont un sous ensemble actif aura surement mérité d'en profiter vu leur investissement en temps, en code, etc...) ?

3) Les informations mis en page d'accueuil (disparues depuis) pour envoyer nos dons sont-elles sûres (ie. s'agit il bien du compte officiel e l'association) ?

En effet, sur le blog de F. Penso, est né un troll sur la sureté des dits dons.
( exemple http://blog.penso.info/2007/10/09/linuxfr-crash-serveur-site(...) )

On ne peut maintenant plus voir ces informations, et est - on sûr qu'elles vont bient tomber sur le compte bancaire de l'association ?

Personnellement j'ai confiance et ait l'intention de modestement contribuer, mais un certain flou règne encore...

> Lire le journal (7 commentaires, moyenne: 4,4).

La plupart des logiciels (surtout en gestion) nous amènent à manipuler des arborescences de données dans tous les sens.
Nous, pauvres programmeurs, devont le faire à la main, avec des boucles.
Le comble est qu'il existe des langages très bien conçus pour manipuler des donnés au sein d'arborescences de donnés. OQL en est un exemple.
OQL est une extention de SQL pour les SGBDO.
On pourrait utiliser d'autres dialectes, l'essentiel étant d'avoir un langage simple et intuitif, OQL me parait un bon candidat.

J'ai personnellement beaucoup de facilités avec des langages type SQL, et beaucoup de difficultés avec la manipulation d'arbre de donnés avec des boucles. J'adore jouer avec le premier et déteste me farcir le second exercice.
De plus je trouve totalement stupide que l'on continue en 2007 à encore faire à la main quelque chose qui pourrait être automatisé. On nous parlent sans cesse de diminuer les coûts, mais on perd des heures (et beaucoup d'argent) sur des problèmes de ce genre.
Cela éviterait de plus de nombreux bugs, qui coutent eux aussi très cher.
Microsoft l'a bien compris, en proposant un langage SQL interne dans C# (LINQ)

Bref, c'est pour cela que je vous propose le projet "OQLtoLang", dont l'objectif est de générer le code de toute sorte de requête OQL pour différent langage.
On pourra ainsi générer du java, Perl, Python, C++, etc...
Un système de plugin permettra d'adapter le code de sortie aux spécificités de chaque langage.

En effet, selon le genre de chose que l'on code, on a pas obligatoirement un framework genre Hibernate ou autre sous la main. De plus, il est souvent fastidieux de coder un interpréteur dans le langage que l'on utilise et utiliser ce genre de manière "tordu", au yeux de certains chefs de projet pas très ouvert, peu provoquer des problèmes. Un interpréteur, qui plus est, intrinsèquement lent, implique aussi de veiller à ce qu'une couche de la librairie soit disponible, il impose de disposer de réflexivité dans le langage, etc...

Le but de ce projet est de générer un code lisible, compréhensible et reprenable par n'importe qui et correspondant à la requête.
En effet, dans une équipe, le niveau du code doit souvent être nivelé par le bas pour être compréhensible par tout le monde.
Une personne extérieur relisant le code doit croire qu'il s'agit d'une bête boucle écrit par un humain. Cela permettra à n'importe qui d'utiliser cet utilitaire avec n'importe quel langage, sans risquer aucun problème vis à vis de son équipe, de son supérieur, etc... Tout en gagnant énormément de temps.



J'ai commencé à écrire du code en Ocaml, non pas que c'est le langage que je maîtrise le plus, mais qu'il me parait le plus adapté, avec son type somme, pour le problème.
Faire ça sans type somme, ça serait l'horreur.

En voici une description didactique.

Je défini l'ensemble des type possible. C'est un système criticable parce qu'on pourrait avoir toutes sortes d'objet à récupérer, et du moment que l'on dispose d'une fonction d'égalité par référence et par structure sur 2 objets, cela suffirait amplement. On va faire sans pour le moment.

type types_possibles = Entier| Chaine| Date| Tablo_entier | Tablo_ch | Collection | Objet | Chaine_const | Entier_const | Date_const | Tablo_entier_const | Tablo_ch_const;;


Il faut ensuite pouvoir définir le chemin d'un objet (par exemple toto[4].proptab.elementAt(5).mumu ...), qui est ni plus ni moins qu'un chemin dans une arborescence

type chemin_obj = Feuille of string*types_possibles | Obj_seul of string | Obj of string*chemin_obj | Collect_seul of string|Collect of string* chemin_obj;;


On peut d'ors et déjà définir le select, liste d'items de l'objets à récupérer :

type axiom_select = string*types_possibles;;
type select = axiom_select list;;


Le from n'est pas compliqué à définir, c'est une liste de différents chemins.

type from = chemin_obj list;;


La représentation de la clause where est beaucoup plus complexe :

Dans une clause where, on trouve des comparaison (égalité, différence, supérieur, inférieur), bref des fonction binaire de type E,E -> bool , des tests ensemblistes d'appartenance ou non appartenance.

type axiom_where = Comparaison of comp_vars | Ensemblein of ens_in | Ensemblenotin of ens_not_in ;;
type where = axiom_where list;;


Une comparaison s'effectue entre deux objets. Il faudra ajouter plus tard la possibilité d'y mettre une sous requête à la place. je ne l'ai pas mis pour simplifier.

type operat = Egal | Diff | Sup | Sup_egal | Inf | Inf_egal;;
type comp_vars = { op : operat ; vc1: chemin_obj; vc2 : chemin_obj};;


Les test d'appartenance sont la comparaison entre deux élements : une requête, et un élement.


type ens_in = { ve1 : chemin_obj; r : requete};;
type ens_not_in = { vf1 : chemin_obj; r : requete};;



une requête est donc la synthèse de tout cela :

type requete = { sel : select ; from : from ; where : where };;



Il nous faut maintenant modéliser le code :


type code = Foreach of chemin_obj*code | Test of chemin_obj*chemin_obj*code | Ajout of chemin_obj;;

permet de modéliser

res : liste d'objet CNN // type donné par select
pour chaque Figure.ListeDeCNN
i : entier
pour chaque Figure.ListeDeCNN[i].Property
j : entier
si Figure.ListeDeCNN[i].Property[j].NomValeur == "SEE_CNN" alors
res.ajoute(Figure.ListeDeCNN[i]) // type de select
fin si
fin pour
fin pour


avec


Foreach(
Obj("Figure",Collect_seul("ListeDeCSN")),
Foreach(
Obj("Figure",Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const)))),
Test(Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const))),
Feuille("SEE_CNN",Chaine_const),
Ajout(Obj("Figure",Collect_seul("ListeDeCNN")))));;


Ce code correspond à la requête :

select CNN.Object
from
Figure.ListeDeCNN.Property
where
Figure.ListeDeCNN.Property.NomValeur = "SEE_CNN"


transformé selon la structure de donné en :



let req = { sel = ("CNN.Object",Objet) ;
from = [Obj("Figure",Collect("ListeDeCNN",Obj_seul("Property")))];
where = [Comparaison({
op = Egal ;
vc1 = Obj("Figure",Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const)))) ;
vc2 =Feuille("SEE_CNN",Chaine_const)})] };;



Je ne me suis pas lancé dans le code de la fonction qui va transformer la requête en code, en partie parce que je ne maîtrise pas assez bien ocaml et surtout par manque de temps.
je cherche des personnes intéressées par la création de ce projet. Ocaml n'est pas imposé, bien qu'il me semble le plus adapté et le plus clair pour ce genre de chose avec son type somme et son filtrage de type.

Si certains sont intéressés, nous pouvons créer un projet sur GNA ou un autre hébergement de ce style.

Partant ?

> Lire le journal (30 commentaires, moyenne: 2,5).

En surfant par hasard, j'ai découvert qu'un chercheur du MIT (décidément, encore eux !), Hugo Liu, s'est amusé à ecrire un logiciel capable de produire du code python à partir d'un texte en langage naturel, l'anglais.

Ainsi écrire un pacman revient à écrire :
Pacman is a character who loves to run through a maze and eat dots. Whenever Pacman eat a dots, it disapears and he wins a point.

Qui génère :

def __main__() :
class Pacman(character) :
def run(maze) :
pass

def eat(dot):
dot.disappear()
Pacman.win(point)

def win(point)
pass

class dot:
def disappear() :
pass



Pas mal, non ?

Comment ça marche ?

En gros, le système cherche des structures verbe-sujet-objet-objet, ayant préalablement étiqueté chaque mot en fonction de sa morphologie, il réalise quelques transformation pour isoler ce genre de structure.
Il recherche ensuite des structures if-then, des listes, etc..
Grâce a une petite analyse sémantique, il détermine ce qui est animé ou ne l'est pas, de quel sorte d'objet a t-on affaire, quelle est la proximité linguistique (champ lexical).
A noter que l'auteur explique que les ambiguités peuvent être une aide, car elle permette parfois de préciser un concept en le comparant avec d'autres structures s'y rapportant.

Cela ne génère pas tout le code, mais c'est un jeu intéressant :-)

> Lire le journal (31 commentaires, moyenne: 3,6).