LINQ (j'en parle dans le journal) est intégré dans la grammaire de C#.
Je cherche à faire un utilitaire qui me permette de me traduire une requête SQL en code de n'importe langage.
Le but étant que la personne qui passe derrière toi, ne voit que des boucles classiques, claires, bien écrites et ne se rendent pas compte qu'il s'agit du code généré.
Imagine donc, je donne à mon utilitaire :
select CNN.Object
from
Figure.ListeDeCNN.Property
where
Figure.ListeDeCNN.Property.NomValeur = "SEE_CNN"
Il me renvoi
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
là c'est de l'algorithme mais imagine qu'il puisse me le rendre en C, C++, Java, Eiffel, etc...
Le langage que je veux...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bon je vois que personne a rien compris. J'ai essayé d'être clair, mais pas réussi :-(
Imagine que tu travaille dans une SSII, sur un projet quelconque en Java, C++, etc...
Tu es dans une entreprise donc, tu travailles sur l'amélioration d'un logiciel qui possède déjà des milliers de lignes de code depuis des années.
Le language t'es imposé, l'éditeur texte t'es imposé, etc...
On te donne un cahier des charges dans lequel on te demande de sortir un reporting sur des classes interne au projet. ce reporting étant effectué au sein du logiciel, pendant qu'il tourne sur les objets en mémoire.
Tu n'as pas hibernate ou qq chose du genre, on te donne un liste stricte de librairie à utiliser, le reste étant interdit.
Il te faut jongler avec plein de donnés pour refaire, à la main des manipulation qui prendrai 10 fois moins de temps en SQL (je n'exagère pas).
Si tu as la "chance" d'utiliser C# et d'avoir le droit d'utiliser LINQ (oui parce qu'on peut t'interdir de coder de tel façon (pas de fonction lambda, etc...)) , le problème n'a pas lieu, mais si tu utilise Java, c++, ou autre chosen t'es obligé de tout faire à la main.
Mon objectif est donc de disposer d'un espèce de script qui prend en entrée une requête OQL, et te rend du code que tu pourras mettre dans ton source, comme si tu l'avais écrit à la main.
Comme ça, tu n'utilise pas de librairie interdite, tu n'as pas écrit de parser SQL qui ferai hurler ton chef de projet, etc... etc...
Python est un beau langage, mais dans une SSII, on te parle plus souvent de J2EE, etc...
Mais merci de me faire découvrir qu'on peut aller aussi loin avec ce langage :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai déjà lu ce papier il y a quelques années, mais ce n'est pas de la gestion d'arborescence sur une base de donnés que je faire, mais une gestion d'arbo sur un code source en java, python, C++ etc... whatever
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je connais TOM, je suis depuis quelques années ce qu'ils font.
Premièrement, c'est beaucoup trop surdimensionné par rapport au besoin que je définis.
Deuxièmement c'est encore un truc d'universitaire de plus, qui comme de nombreux projet universitaires est conceptuellement géniak, mais totalement imbitable.
Si mon chef me voyait utiliser ce truc, il me truciderait sur place.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Par quel miracle Lisaac serait-il capable d'inliner le code de la liste ou du tableau dans mes calculs alors qu'il n'y a aucun moyen de savoir quelle est la structure de données choisie par l'utilisateur avant le runtime ?
Simple : il inline les deux cas ;-)
Là j'avoue que je ne comprend pas ce que tu veux dire. Ce n'est pas du tout mon domaine mais pour moi la liaison dynamique c'est le contraire de l'inlining...
Justement, les compilateurs objets classiques utilisent une table de pointeurs en mémoire pour savoir sur quel fonction se brancher.
Lisaac transforme cela en appels statiques, en utilisant une recherche dichotomique.
Non, j'ai trouvé des slides, et les slides ça ne sert à rien sans la présentation qui va avec...
Exact, je vais donc le faire.
Slide 127 : Floppy et hard_disk hérite de drive et possède tout deux une fonction read. Liaison dynamique sur cette fonction.
Slide129 : les compilo classiques utilisent une table de fonction
Slide 130 : Lisac fait de l'analyse de flot. il analyse la géométrie du graphe du code pour prévoir les types.
Dans cette exemple, r peut être de type A, B , C ou D.
Avec une solution syntaxique type SmartEiffel, on supprime la liaison dynamique (la table de fonction), en faisant une recherche, pour savoir si, à l'exécution du code, r est de type A, B, C ou D.
C'est un bête switch case, mais on a déjà supprimé la liaison dynamique, donc on peut inliner.
Lisaac va plus loin :
Dans la branche où on évalue r.method, on voit que r ne peut être que de type A ou B (les branches correspondent à un test).
Donc, on fera un test sur A ou B seulement (Slide 131,132).
Slide 133 : on associe le type d'un objet en nombre, ce qui permet de faire des recherches dichotomique ayant l'avantage d'être en nlog(n) (si je me souviens bien)
Slide 134 : on inline... Et on réduit le résultat. ici on présente un cas extrême.
Slide 135 : dans l'ancienne version du compilateur (la nouvelle a fait de nettes progrès), on avait 91% d'appels monomorphiques natifs (sur le compilateur), plus 4 % d'appels polymorphique transformés en monomorphiques.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Lisaac, avec son analyse de flot, traduit la plupart des appels polymorphique en appel monomorphique, quand ils le sont réèllement, on atteint des chiffres de plus de 97 %.
de plus l'inlining se fait aisément, si tu résoud la liaison dynamique en utilisant une table dynamique.
C'est pas spécifique à Python, la programmation orientée objet est plus lente qu'un programme cablé en dur (du C par exemple), mais aujourd'hui on peut se permettre des perdre quelques pourcents de CPU et de mémoire à l'exécution pour accélérer le temps de développement.
Faux, le compilateur Lisaac en est la preuve. Ce n'est qu'un problème de compilateur, pas de paradigme de langage :-)
À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)
C'est clair, le problème c'est qu'il y a peu de recherche dans le domaine...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Premièrement, on programmera effectivement avec un sous ensemble "moins ambigue du langage". On pourra difficilement enlever toute ambiguité comme le lobjan mais c'est surment possible d'en retirer pas mal. De plus, les logiciels que l'on décrira seront par nature assez précis. On parlera de traiter des fichiers, des BDD, de l'XML, de faire des interfaces graphiques, etc... On pourra difficlement se passer de langages comme SQL, ou CQL (ou un de ses descendants bitable) pour travailler des données sur un SGBD, ou de l'XML...
Deuxièmement, un langage de dévelopement basé sur un sous ensemble de langage naturel sera amené à interagir avec l'utilisateur.
On y est pas habitué, donc on y pense pas, mais le changement de paradigme implique un changement de méthode.
Un langage de programmation classique comme ceux que nous connaissons possèdent intrinsèquement une structure non ambigüe du code : il n'est pas une représentation de ce que l'on veut faire, mais une représentation de ce que l'automate virtuelle doit faire.
Or, programmer en langage naturel implique que l'on glisse vers une logique de description de spécification, l'ordinateur devant rédiger l'algo pour y arriver.
Cela implique que dès que le moteur tombera sur une ambigüité, il entamera un dialogue afin de préciser cette ambigüité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Certes, c'etait un exemple parmi d'autres superlatifs encensant ton propre produit ("de reve", franchement.... ;-).
Bon c'est vrai que j'y crois beaucoup ;-) Ya mes rêves d'informaticien qui se réalise dedans ;-)
Concernant l'Xml je disais que je m'y connaissais, parce que c'est mon métier, je fais ça toutes la journée :-)
Par contre vis a vis de mes questions sur le modele COP, peux tu eclairer ma lanterne?
En gros COP, c'est un modèle.
Si tu déclare ton objet en '-' (- devant la section NAME), ton objet sera une sorte de thread.
Si un autre objet appel une fonction (rendant un résultat)sur cette objet, l'appelant sera bloqué.
Si c'est une méthode sans résultat, elle s'exécutera en parallèle.
Le compilateur se débrouille tout seul avec les thread, les verrous, etc...
C'est une amélioration de SCOOP que B. Meyer avait inventé pour Eiffel.
Mais c'est bien mieux expliqué dans le manuel :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
et je vais personnellement l'améliorer pour en faire une lib de rêve, car je connais très bien le sujet...
Mais dis moi, il a pas completement tort TIManiac...tu te la petes a fond!!
C'est bien d'etre (sans doute) une brute en theorie et (sans doute) un bon codeur. Est-ce bien la peine de la ramener ainsi a la premiere occasion? Je parlais de faire une librairie XML. Juste la lib qui te permet de manipuler un arbre.
C'est franchement pas quelques chose qui prend des mois à faire.
Si on commence à parler d'XSL,etc... là d'accord.
Pour le reste, faut bien commencer un jour, et prendre des risques, sinon on fait jamais rien, non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
En fait, de façon générale, on peut toujours transformer un code recursif en un code impératif.
Tu es vraiment sûr ? On m'a souvent dit que beaucoup de récursive non terminal était impossible à transformer en impératif.
Si tu as la recette magique, tu nous intéresse ! :-)
Tu le traduit comment impératif ça ? int tak(int x, int y, int z) {
if (y < x) {
return tak(tak(x - 1, y, z), tak(y - 1, z, x), tak(z - 1, x, y));
}
return z;
}
Certains langages le détectent et optimisent tout seuls.
Le compilateur Lisaac par exemple :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bon, les deux premiers se foutent de toi et c'est vrai que c'est tentant.
Sérieusement il n'y aucun risque de conflit, tout simplement car Windows va totalement "ignorer" Linux. Pour lui ça sera une zone du disque dur illisible qu'il ignorera, donc.
Linux te permettra d'accéder à ta partition Windows, au moins en lecture seul. Pour éviter tout problème, n'essaye pas d'écrire sur la partition windows, ou créé en une qui servira à faire d'éventuel échange entre les deux.
Penses bien à défragmenter ton disque avant d'installer.. :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai une doc un peu moins concise, plus joli, mais moins complète, que je compte mettre sur le site, bientôt, quand j'aurai eu le temps de la reprendre. Je te l'envoi perso si tu veux :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai scotché quelques minutes en tête à tête avec ta doc, et soudain fiat lux !
En fait c'est quoi les iterator à la Sather ?
C'est l'idée que je définis une boucle, et qu'un message sur une classe integer va me permettre de définir le sous ensemble parcouru dans cette boucle.
C'est potentiellement très puissant, car ça évite de faire joujou avec un index à l'intérieur, et ça aide à la lecture du code parce qu'on comprend tout de suite ce qu'on fait.
Figure toi que j'ai implémenté ça en Lisaac (avec l'aide de Ben sur la fin) en Lisaac il y a quelques jours... Mais en plus puissant !
Le pb des parcours d'ensemble y est pas mal abordé.
Sather te permet de le faire, mais le problème est que tu es limité par les messages sur int (ceux avec le !), alors que le système qu'on a codé permet d'aller plus loin :
La méthode se trouve dans numeric :
- to upper:NUMERIC do action:BLOCK items func:BLOCK <-
ça s'utilise comment ?
1.to 7 do { i : NUMERIC;
//code
sum := sum + i;
} items { j:NUMERIC;
j.factorial
}
Dans cet exemple tu va sommer les factoriel (le i du premier bloc, prend le resultat de l'itérateur (j, qui va de 1 à 7) appliqué au deuxième), et ce qu'il y a de mieux par rapport à Sather, c'est que tu n'a pas besoin d'utiliser un message existant dans NUMERIC... Il te suffit de définir un BLOCK qui prend un int et t'en renvoi un. Et tu définis ce que tu veux
D'après ce que j'ai vu, ça apas été rajouté dans la dernière release (c'est un oubli), tu te le rajoute et tu pourras jouer avec :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est dans les cartons.
En fait, on aura carrément un système qui permettra de définir certaines optims de manière extren au compilateur, des sortes de fichiers de configuration.
Il faudra en écrire une par archi, ou on pourra mettre différentes choses :
- Taille de ligne de cache code et donnée
- Optimisation sur les entiers (mélange pipeline flottant et entier)
- Taille max de la mémoire
- etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Le fait que les professionnels de l'informatique ne connaissent rien au math, et plus généralement à la théorie est pour moi un gros problème.
Je travaille avec des gens qui ne connaissaient même pas les expressions régulières ou les tables de hashage. On leur donne pourtant des responsabilités et des projets de plusieurs milliers d'euros et de ligne de code à gérer.
Résultat, ils sont incapables de penser en terme de généricité, et passent leur temps à refaire, et à faire refaire (et c'est moi qui prend...) ce que l'on a déjà fait.
Pire, ceux qui ont eu affaire avec des théoriciens, les méprisent parce qu'ils "se souciaient plus de l'élégance que de l'efficacité".
Pour eux, théoricien = Type qui veut se faire plaisir avec des trucs qui coutent cher et qui ne marchent pas.
Ils ne voient pas au delà et ne comprennent pas que leur budget pourraient diminuer d'un tiers (et leur gains augmenter de tout autant) s'il était capable de voir un tout petit peu plus loin.
Le fait d'avoir un diplome d'ingénieur est mieux considéré que d'avoir fait une thèse en France est très symptomatique des oeillères des dirigeants dans le domaine...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai l'impression que c'est surtout un problème français.
En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
L'aspect mathématique, voire même théorique, est ainsi rejeté par les professionnels de l'industrie.
"Mathématique" c'est une notion, savoir ce qui rentre ou pas dans le champ d'une notion, n'est pas un débat sémantiquement profond, mais simplement un débat de sens, "que met-on dans telle ou ou telle catégorie ?"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: LINQ
Posté par Ontologia (site web personnel) . En réponse au journal Création du projet "OQLToLang". Évalué à 2.
LINQ (j'en parle dans le journal) est intégré dans la grammaire de C#.
Je cherche à faire un utilitaire qui me permette de me traduire une requête SQL en code de n'importe langage.
Le but étant que la personne qui passe derrière toi, ne voit que des boucles classiques, claires, bien écrites et ne se rendent pas compte qu'il s'agit du code généré.
Imagine donc, je donne à mon utilitaire :
select CNN.Object
from
Figure.ListeDeCNN.Property
where
Figure.ListeDeCNN.Property.NomValeur = "SEE_CNN"
Il me renvoi
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
là c'est de l'algorithme mais imagine qu'il puisse me le rendre en C, C++, Java, Eiffel, etc...
Le langage que je veux...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Heu...
Posté par Ontologia (site web personnel) . En réponse au journal Création du projet "OQLToLang". Évalué à 2.
Imagine que tu travaille dans une SSII, sur un projet quelconque en Java, C++, etc...
Tu es dans une entreprise donc, tu travailles sur l'amélioration d'un logiciel qui possède déjà des milliers de lignes de code depuis des années.
Le language t'es imposé, l'éditeur texte t'es imposé, etc...
On te donne un cahier des charges dans lequel on te demande de sortir un reporting sur des classes interne au projet. ce reporting étant effectué au sein du logiciel, pendant qu'il tourne sur les objets en mémoire.
Tu n'as pas hibernate ou qq chose du genre, on te donne un liste stricte de librairie à utiliser, le reste étant interdit.
Il te faut jongler avec plein de donnés pour refaire, à la main des manipulation qui prendrai 10 fois moins de temps en SQL (je n'exagère pas).
Si tu as la "chance" d'utiliser C# et d'avoir le droit d'utiliser LINQ (oui parce qu'on peut t'interdir de coder de tel façon (pas de fonction lambda, etc...)) , le problème n'a pas lieu, mais si tu utilise Java, c++, ou autre chosen t'es obligé de tout faire à la main.
Mon objectif est donc de disposer d'un espèce de script qui prend en entrée une requête OQL, et te rend du code que tu pourras mettre dans ton source, comme si tu l'avais écrit à la main.
Comme ça, tu n'utilise pas de librairie interdite, tu n'as pas écrit de parser SQL qui ferai hurler ton chef de projet, etc... etc...
Python est un beau langage, mais dans une SSII, on te parle plus souvent de J2EE, etc...
Mais merci de me faire découvrir qu'on peut aller aussi loin avec ce langage :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Gestion d'arbres par représentation intervallaire
Posté par Ontologia (site web personnel) . En réponse au journal Création du projet "OQLToLang". Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Tom
Posté par Ontologia (site web personnel) . En réponse au journal Création du projet "OQLToLang". Évalué à 2.
Premièrement, c'est beaucoup trop surdimensionné par rapport au besoin que je définis.
Deuxièmement c'est encore un truc d'universitaire de plus, qui comme de nombreux projet universitaires est conceptuellement géniak, mais totalement imbitable.
Si mon chef me voyait utiliser ce truc, il me truciderait sur place.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le futur
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: intéressant mais...
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: intéressant mais...
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 3.
Ahh, le politiquement correct !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 4.
Simple : il inline les deux cas ;-)
Là j'avoue que je ne comprend pas ce que tu veux dire. Ce n'est pas du tout mon domaine mais pour moi la liaison dynamique c'est le contraire de l'inlining...
Justement, les compilateurs objets classiques utilisent une table de pointeurs en mémoire pour savoir sur quel fonction se brancher.
Lisaac transforme cela en appels statiques, en utilisant une recherche dichotomique.
Non, j'ai trouvé des slides, et les slides ça ne sert à rien sans la présentation qui va avec...
Exact, je vais donc le faire.
Slide 127 : Floppy et hard_disk hérite de drive et possède tout deux une fonction read. Liaison dynamique sur cette fonction.
Slide129 : les compilo classiques utilisent une table de fonction
Slide 130 : Lisac fait de l'analyse de flot. il analyse la géométrie du graphe du code pour prévoir les types.
Dans cette exemple, r peut être de type A, B , C ou D.
Avec une solution syntaxique type SmartEiffel, on supprime la liaison dynamique (la table de fonction), en faisant une recherche, pour savoir si, à l'exécution du code, r est de type A, B, C ou D.
C'est un bête switch case, mais on a déjà supprimé la liaison dynamique, donc on peut inliner.
Lisaac va plus loin :
Dans la branche où on évalue r.method, on voit que r ne peut être que de type A ou B (les branches correspondent à un test).
Donc, on fera un test sur A ou B seulement (Slide 131,132).
Slide 133 : on associe le type d'un objet en nombre, ce qui permet de faire des recherches dichotomique ayant l'avantage d'être en nlog(n) (si je me souviens bien)
Slide 134 : on inline... Et on réduit le résultat. ici on présente un cas extrême.
Slide 135 : dans l'ancienne version du compilateur (la nouvelle a fait de nettes progrès), on avait 91% d'appels monomorphiques natifs (sur le compilateur), plus 4 % d'appels polymorphique transformés en monomorphiques.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 2.
de plus l'inlining se fait aisément, si tu résoud la liaison dynamique en utilisant une table dynamique.
Tu trouveras des explications ici : http://isaacproject.u-strasbg.fr/download/workshop.pdf
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 4.
Faux, le compilateur Lisaac en est la preuve. Ce n'est qu'un problème de compilateur, pas de paradigme de langage :-)
À mon avis, les langages de programmations doivent monter en abstraction. Le but ultime étant d'écrire un programme dans sa langue maternelle... comme ce qui est présenté dans ce journal... sauf que je doute que ce jeu pacman soit jouable (c'est pas encore au point) ;-)
C'est clair, le problème c'est qu'il y a peu de recherche dans le domaine...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On gagne en abstraction
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 3.
Premièrement, on programmera effectivement avec un sous ensemble "moins ambigue du langage". On pourra difficilement enlever toute ambiguité comme le lobjan mais c'est surment possible d'en retirer pas mal. De plus, les logiciels que l'on décrira seront par nature assez précis. On parlera de traiter des fichiers, des BDD, de l'XML, de faire des interfaces graphiques, etc... On pourra difficlement se passer de langages comme SQL, ou CQL (ou un de ses descendants bitable) pour travailler des données sur un SGBD, ou de l'XML...
Deuxièmement, un langage de dévelopement basé sur un sous ensemble de langage naturel sera amené à interagir avec l'utilisateur.
On y est pas habitué, donc on y pense pas, mais le changement de paradigme implique un changement de méthode.
Un langage de programmation classique comme ceux que nous connaissons possèdent intrinsèquement une structure non ambigüe du code : il n'est pas une représentation de ce que l'on veut faire, mais une représentation de ce que l'automate virtuelle doit faire.
Or, programmer en langage naturel implique que l'on glisse vers une logique de description de spécification, l'ordinateur devant rédiger l'algo pour y arriver.
Cela implique que dès que le moteur tombera sur une ambigüité, il entamera un dialogue afin de préciser cette ambigüité.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Liens
Posté par Ontologia (site web personnel) . En réponse au journal Language naturel 2 python. Évalué à 5.
Le pdf publiant la chose : http://web.media.mit.edu/%7Ehugo/publications/papers/IUI2005(...)
Ya surtout la lib qui le permet : http://web.media.mit.edu/~hugo/montylingua/
dans une espèce de licence libre.
Voilà, désolé pour l'oubli, fatigué en ce moment...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Bon c'est vrai que j'y crois beaucoup ;-) Ya mes rêves d'informaticien qui se réalise dedans ;-)
Concernant l'Xml je disais que je m'y connaissais, parce que c'est mon métier, je fais ça toutes la journée :-)
Par contre vis a vis de mes questions sur le modele COP, peux tu eclairer ma lanterne?
En gros COP, c'est un modèle.
Si tu déclare ton objet en '-' (- devant la section NAME), ton objet sera une sorte de thread.
Si un autre objet appel une fonction (rendant un résultat)sur cette objet, l'appelant sera bloqué.
Si c'est une méthode sans résultat, elle s'exécutera en parallèle.
Le compilateur se débrouille tout seul avec les thread, les verrous, etc...
C'est une amélioration de SCOOP que B. Meyer avait inventé pour Eiffel.
Mais c'est bien mieux expliqué dans le manuel :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Mais dis moi, il a pas completement tort TIManiac...tu te la petes a fond!!
C'est bien d'etre (sans doute) une brute en theorie et (sans doute) un bon codeur. Est-ce bien la peine de la ramener ainsi a la premiere occasion?
Je parlais de faire une librairie XML. Juste la lib qui te permet de manipuler un arbre.
C'est franchement pas quelques chose qui prend des mois à faire.
Si on commence à parler d'XSL,etc... là d'accord.
Pour le reste, faut bien commencer un jour, et prendre des risques, sinon on fait jamais rien, non ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
tak__TJ:
.LFB16:
.loc 1 1134 0
.LVL9:
pushl %ebp
.LCFI7:
movl %esp, %ebp
.LCFI8:
pushl %edi
.LCFI9:
movl %ecx, %edi
pushl %esi
.LCFI10:
movl %eax, %esi
pushl %ebx
.LCFI11:
movl %edx, %ebx
subl $8, %esp
.LCFI12:
.LVL10:
.L26:
.loc 1 1137 0
cmpl %esi, %ebx
jge .L27
.loc 1 1138 0
movl %ebx, %ecx
movl %esi, %edx
leal -1(%edi), %eax
call tak__TJ
movl %esi, %ecx
movl %edi, %edx
movl %eax, -16(%ebp)
leal -1(%ebx), %eax
call tak__TJ
movl %edi, %ecx
movl %ebx, %edx
movl %eax, -20(%ebp)
leal -1(%esi), %eax
call tak__TJ
movl -20(%ebp), %ebx
movl -16(%ebp), %edi
movl %eax, %esi
jmp .L26
.LVL11:
.L27:
.loc 1 1143 0
popl %edx
movl %edi, %eax
popl %ecx
popl %ebx
.LVL12:
popl %esi
.LVL13:
popl %edi
.LVL14:
popl %ebp
ret
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Tu es vraiment sûr ? On m'a souvent dit que beaucoup de récursive non terminal était impossible à transformer en impératif.
Si tu as la recette magique, tu nous intéresse ! :-)
Tu le traduit comment impératif ça ?
int tak(int x, int y, int z) {
if (y < x) {
return tak(tak(x - 1, y, z), tak(y - 1, z, x), tak(z - 1, x, y));
}
return z;
}
Certains langages le détectent et optimisent tout seuls.
Le compilateur Lisaac par exemple :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Sérieusement
Posté par Ontologia (site web personnel) . En réponse au message Partitionnement. Évalué à 8.
Sérieusement il n'y aucun risque de conflit, tout simplement car Windows va totalement "ignorer" Linux. Pour lui ça sera une zone du disque dur illisible qu'il ignorera, donc.
Linux te permettra d'accéder à ta partition Windows, au moins en lecture seul. Pour éviter tout problème, n'essaye pas d'écrire sur la partition windows, ou créé en une qui servira à faire d'éventuel échange entre les deux.
Penses bien à défragmenter ton disque avant d'installer.. :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Sather
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
En fait c'est quoi les iterator à la Sather ?
C'est l'idée que je définis une boucle, et qu'un message sur une classe integer va me permettre de définir le sous ensemble parcouru dans cette boucle.
C'est potentiellement très puissant, car ça évite de faire joujou avec un index à l'intérieur, et ça aide à la lecture du code parce qu'on comprend tout de suite ce qu'on fait.
Figure toi que j'ai implémenté ça en Lisaac (avec l'aide de Ben sur la fin) en Lisaac il y a quelques jours... Mais en plus puissant !
j'ai pensé à ça, après avoir lu et relu cette doc qui est géniale :
http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf
Le pb des parcours d'ensemble y est pas mal abordé.
Sather te permet de le faire, mais le problème est que tu es limité par les messages sur int (ceux avec le !), alors que le système qu'on a codé permet d'aller plus loin :
La méthode se trouve dans numeric :
- to upper:NUMERIC do action:BLOCK items func:BLOCK <-
ça s'utilise comment ?
1.to 7 do { i : NUMERIC;
//code
sum := sum + i;
} items { j:NUMERIC;
j.factorial
}
Dans cet exemple tu va sommer les factoriel (le i du premier bloc, prend le resultat de l'itérateur (j, qui va de 1 à 7) appliqué au deuxième), et ce qu'il y a de mieux par rapport à Sather, c'est que tu n'a pas besoin d'utiliser un message existant dans NUMERIC... Il te suffit de définir un BLOCK qui prend un int et t'en renvoi un. Et tu définis ce que tu veux
D'après ce que j'ai vu, ça apas été rajouté dans la dernière release (c'est un oubli), tu te le rajoute et tu pourras jouer avec :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Cette lib sera celle d'IsaacOS, elle ne se repose que sur putPixel.
Mais on peut envisager des binding...
Il y a un générateur de binding pour Eiffel, qu'on pourra ensuite traduire en lisaac, on pourrait peut être l'utiliser ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
En fait, on aura carrément un système qui permettra de définir certaines optims de manière extren au compilateur, des sortes de fichiers de configuration.
Il faudra en écrire une par archi, ou on pourra mettre différentes choses :
- Taille de ligne de cache code et donnée
- Optimisation sur les entiers (mélange pipeline flottant et entier)
- Taille max de la mémoire
- etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
http://isaacproject.u-strasbg.fr/API/index.html
Si tu l'as pas vu, c'est qu'on ne l'as pas assez mis en exergue :)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 5.
Je travaille avec des gens qui ne connaissaient même pas les expressions régulières ou les tables de hashage. On leur donne pourtant des responsabilités et des projets de plusieurs milliers d'euros et de ligne de code à gérer.
Résultat, ils sont incapables de penser en terme de généricité, et passent leur temps à refaire, et à faire refaire (et c'est moi qui prend...) ce que l'on a déjà fait.
Pire, ceux qui ont eu affaire avec des théoriciens, les méprisent parce qu'ils "se souciaient plus de l'élégance que de l'efficacité".
Pour eux, théoricien = Type qui veut se faire plaisir avec des trucs qui coutent cher et qui ne marchent pas.
Ils ne voient pas au delà et ne comprennent pas que leur budget pourraient diminuer d'un tiers (et leur gains augmenter de tout autant) s'il était capable de voir un tout petit peu plus loin.
Le fait d'avoir un diplome d'ingénieur est mieux considéré que d'avoir fait une thèse en France est très symptomatique des oeillères des dirigeants dans le domaine...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: sonntag
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
En France, les ingénieurs pensent que les chercheurs sont des professeurs Nimbus qui ne servent à rien, et les chercheurs pensent que les ingénieurs sont des gros nuls à peine capable d'écrire un intranet en Java.
Résultat, t'as fait une thèse, ou même t'as un diplôme nul et t'as quelques papiers de recherches à ton actif, c'est mal vu quand tu cherches un boulot. C'est mon cas...
L'aspect mathématique, voire même théorique, est ainsi rejeté par les professionnels de l'industrie.
"Mathématique" c'est une notion, savoir ce qui rentre ou pas dans le champ d'une notion, n'est pas un débat sémantiquement profond, mais simplement un débat de sens, "que met-on dans telle ou ou telle catégorie ?"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker