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
Forcément un langage type statiquement n'a pas les qualités d'un langage dynamiquement, il n'en a pas le défauts non plus (cf.. pyprotocols, pychecker, test sur les types d'arguments, ...)
Et vu les innombrables trolls sur le sujet sur la toile on ne peut guère être categorique.
Lisaac est fortement typé, ce n'est pas un langage à typage dynamique, attention :-)
En revanche ca m'aurait plus de savoir dans quelle catégorie se placait Lisaac en lisant la dépêche parce que perso, le fait qu'il optimise l'arbre de décision du programme ca m'apporte pas grand chose.
Bref j'aurais aimé du concret, une vraie comparaison avec un langage comme Java et Ruby plûtôt qu'une liste complète de concepts que seul une minorité connait (enfin je crois).
Par exemple la curryfication et la tail recursion, c'est quoi ? peut on vivre sans ?
Pour les contrats , tu as à disposition des librairies qui s'en chargent et il n'y a guère de languages hormis Eiffel qui l'intègrents nativement. Est-ce le cas de Lisaac ?
C'est vrai que j'ai été un peu trop conceptuel.
La curryfication c'est le fait de transformer par exemple une fonction de 2 paramètre, en fonction de fonction, comme ça si tu as un paramètre tu le renvoi à la premiere et ça te renvoi une fonction. curryfication
L'intérêt des contrats en Eiffel et lisaac (parce qu'il y en a vraiment en lisaac), c'est que tes contrats sont hérités : ils suivent l'arbre d'héritage, ce qui fait que tu peux les ajouter en comlpétant cet arbre.
Ya des mots clé dans le langage, en Lisaac, le mot clé Old te permet de comparer l'ancienne valeur d'une variable en début de fonction et à la fin.
Ce que comble la programmation aspect c'est une des faiblesses du modèle objet (à proptotypes ou non). Elle prend en charge les problématiques transverses qui auparavant etaient disséminées et vise justement à alléger et rendre encore plus réutilsable ces briques de base.
Elle se veut donc complémentaire. et on ne peut pas dire qu'elllees n'evoluent pas.
Lisaac n'est donc pas objet ?
Perso, mais ce n'est que mon avis, je trouve ça bidouille, l'AOP..
ça revient à quoi en fait ?
ça revient à mettre des goto conditionnels dans ton code.
Je faisais ça en Basic quand j'étais gosse...
'fin cela dit tu pourras le faire sur des variables en lisaac : tu met un print dans le contrat de ta variable, ça va t'afficher le print à chaque fois qu'on accèdera à la variable (et testera le contrat, en passant)..
« 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
[^] # Re: Packaging pour distributions ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
Comme 0.12 qui tend vers la spécification 0.2
Ya un schéma ici : http://isaacproject.u-strasbg.fr/li/li_download.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Mouais
Posté par Ontologia (site web personnel) . En réponse au journal Excel 2007 c'est super. É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.
Et vu les innombrables trolls sur le sujet sur la toile on ne peut guère être categorique.
Lisaac est fortement typé, ce n'est pas un langage à typage dynamique, attention :-)
En revanche ca m'aurait plus de savoir dans quelle catégorie se placait Lisaac en lisant la dépêche parce que perso, le fait qu'il optimise l'arbre de décision du programme ca m'apporte pas grand chose.
Bref j'aurais aimé du concret, une vraie comparaison avec un langage comme Java et Ruby plûtôt qu'une liste complète de concepts que seul une minorité connait (enfin je crois).
Par exemple la curryfication et la tail recursion, c'est quoi ? peut on vivre sans ?
Pour les contrats , tu as à disposition des librairies qui s'en chargent et il n'y a guère de languages hormis Eiffel qui l'intègrents nativement. Est-ce le cas de Lisaac ?
C'est vrai que j'ai été un peu trop conceptuel.
La curryfication c'est le fait de transformer par exemple une fonction de 2 paramètre, en fonction de fonction, comme ça si tu as un paramètre tu le renvoi à la premiere et ça te renvoi une fonction.
curryfication
L'intérêt des contrats en Eiffel et lisaac (parce qu'il y en a vraiment en lisaac), c'est que tes contrats sont hérités : ils suivent l'arbre d'héritage, ce qui fait que tu peux les ajouter en comlpétant cet arbre.
Ya des mots clé dans le langage, en Lisaac, le mot clé Old te permet de comparer l'ancienne valeur d'une variable en début de fonction et à la fin.
Ce que comble la programmation aspect c'est une des faiblesses du modèle objet (à proptotypes ou non). Elle prend en charge les problématiques transverses qui auparavant etaient disséminées et vise justement à alléger et rendre encore plus réutilsable ces briques de base.
Elle se veut donc complémentaire. et on ne peut pas dire qu'elllees n'evoluent pas.
Lisaac n'est donc pas objet ?
Perso, mais ce n'est que mon avis, je trouve ça bidouille, l'AOP..
ça revient à quoi en fait ?
ça revient à mettre des goto conditionnels dans ton code.
Je faisais ça en Basic quand j'étais gosse...
'fin cela dit tu pourras le faire sur des variables en lisaac : tu met un print dans le contrat de ta variable, ça va t'afficher le print à chaque fois qu'on accèdera à la variable (et testera le contrat, en passant)..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker