Cela ne marche effectivement qu'avec la version CVS : New version with full virtualization support - use only with the current QEMU CVS (documentation) http://fabrice.bellard.free.fr/qemu/download.html
Dans la PME ou je bossais il y a quelques mois, les problèmes de versions étaient souvent un facteur de problèmes et de perte de temps insurmontable. Ca a d'ailleurs été pour moi l'argument majeur, outre les coûts de licences, d'installer OpenOffice sur pas mal de postes.
Personnelemment, je n'ai jamais vu ces systèmes de versions sur les Office version 95 à Xp que j'ai eu à administrer.
Je suis intéressé, je leur ferai passer le message, car je sais qu'ils se prennent encore la tête avec ça.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bien sûr, mais j'ai peur que cela se passe comme avec XP, qui, dès sa première version nécessite 512 Mo pour tourner correctement. Je parle par expérience pratique.
2 Go seront probablement nécessaires pour le voir tourner "correctement"...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Maintenant si les jeux pour la PS3 seront sous Linux, il sera peut être plus facile de les porter sous PC/Linux et donc créer quelques migrations vers Linux, Windows n'ayant plus d'avantage.
J'ai quelques doutes quand à la rationalité économique de la chose d'une part, voire la prétendue facilité technique d'autre part.
A mon avis, outre que le noyau Linux va être un petit peu modifié, pas mal d'interface risquent d'être propriétaire, comme les API sons, vidéo, IA, réseaux peut être (pour le haut niveau tout au moins).
Donc passer les jeux d'une PS3 sur un PC linux avec un une architecture assez différente, j'y crois peu.
Après, pourquoi faire l'effort de porter un logiciel qu'il faut pouvoir garantir sur x distributions parce qu'elles ne sont pas toutes compatibles entre elles au niveau binaire.
Il me semble qu'il tourne sur un ARM IsaacOS. Je me souvient que Benoit m'avait raconté à quel point l'assembleur est prise de tête sur ce processeurs (bah oui pour faire l'OS, ya un centaine de lignes à écrire).
Après le tester....
A voir si on le met dans la distrib
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je te rejoint pour affirmer avec toi, que cette possibilité qui a été présenté est un choix de design de l'OS.
Néanmois, ne pas oublier que ce genre de possibilitée est directement offerte par le fait que Lisaac soit un langage objet à prototype, et que cette différence permet une bien plus grande flexibilité qu'un modèle à classe où il faudrait écrire des composants (voir Think, etc...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
PostgreSQL gère très bien une chose qui n'a pas été mis en avant ici, ce sont les requêtes un tant soi peut complète, du genre select machin,truc from (select from where...) where (select from where)...
Avec Postgre, tu peux faire de belles requêtes bien complexes, et il va te les exécuter à une vitesse phénoménale.
MySQL, c'est bien pour faire select prenom, nom from client, mais dès que ça devient trop compliqué, il suit plus.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ah non !!
Au contraîre !
Ecrire un driver sous Isaac devient d'une simplicité enfantine.
Regarde le driver VIDEO. VIDEO hérite de BITMAP, donc il possède toutes les fonctions de dessins, etc...
Dans VIDEO tu as a écrire les méthodes :
- make w,h:INTEGER
Pour initialiser
- close
Pour clore ;-)
- pixel_hard x,y:INTEGER color col:UINTEGER
Le pixel_ hard.
C'est la seule méthode indispensable. Tout est écrit dans bitmap à partir de celles-là.
- line_h_hard x,y:INTEGER until x1:INTEGER color col:UINTEGER
Méthode facultative
- line_h_hard x,y:INTEGER until x1:INTEGER image line:BMP_LINE offset ofs:INTEGER
Idem, pour dessiner une ligne de bitmap.
Comme VIDEO hérite de BITMAP et que BITMAP contient tout ce qu'il faut pour dessiner des lignes, des points, polygones, cercles, etc.. il suffit que VIDEO redéfinisse la méthode et c'est bon.
Donc si Nvidia ou ATI veulent écrire un driver pour IsaacOS, il leur suffit d'écrire quelques méthodes de ce genre, plus des méthodes pour la 3d.
Les fonctionalités systèmes de Lisaac font le reste.
Donc, non, écrire un driver pour IsaacOS est enfantin.
C'est une de ses intérêts majeurs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Effectivement, tu peux t'amuser à réécrire la lib et dans ce cas je te souhaite bonne chance. Surtout qu'il y a certaines primitives que tu devras réécrire d'une façon différente pour ne pas amener le juge à constater que tu as copié la lib originale.
Tiens, et si on verrouillait toutes les façons de faire des messages if, while, etc... ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
quels sont ses technologie innovante dont l'Inria est si jalouse ?
Le compilateur utilise une technique d'analyse de flot qui permet d'analyser l'ensemble du code vivant. Cette annalyse de flot permet de faire pas mal de prédictions de types, spécialisation, etc...
C'est un algo novateur qui n'a jamais été utilisé ailleurs et qui doit être protégé.
Je ne veux que cela tombe dans l'escarcelle du logiciel propriétaire.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Non car les lib C sont en LGPL, ce qui permet de faire ce que tu veux en éliminant le caractère viral.
Donc le fait que la licence de la lib soit viral, implique que tout code généra avec le compilateur utilisant cette lib est sous cette licence (Cecill en l'occurance), le source C ainsi que le binaire.
Il est donc interdit de faire du proprio avec le compilateur Lisaac en l'état, à mois de réécrire la lib...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
La librairie est libéré en CeCILL V2. Cela implique que tout code produit avec le compilateur est automatiquement en CeCILL...
Le compilateur, pas encore.
L'INRIA "exige" les droits sur le brevet, bien qu'à ma connaissance rien n'ait été déposé. Par contre le programme a été déposé dans plusieurs pays pour prouver l'antériorité, éventuellement.
IsaacOS sera bientôt libéré (l'autorisation en a été donnée jusqu'à nouvel ordre), mais Benoit aimerait terminer la version 0.2 du compilateur (qui a impliqué une récriture complète de celui-ci), faire une belle distrib, avec quelques explications.
Bref, faire les choses proprement.
En ce qui concerne le compilateur, il y a encore incertitude, surtout que si l'INRIA veut déposer un brevet, c'est un long processus.
Trollez bien pendant 24 h (je ne serai pas là) ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je précise que ce que j'ai proposé plus haut est pas une "bidouille" conçu sur un coin de table par un ingénieur pour générer du code.
C'est une tentative de repenser intégralement la façon de programmer en introduisant des notions de reconnaissances de forme, de manipulation ensembliste des données, de métaprogrammation, etc...
Cela dit, tu soulèves des points intéressants, bien que je pense qu'il est possible de faire un langage de spec très haut niveau sufiseament léché au niveau théorique pour cracher quelque chose de propre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Why génère une preuve pour COQ qui se charge dé montrer que l'algo est valide.
Le problème est que COQ n'est pas incrémental.
Il y a plusieurs défis :
1/ Concevoir un générateur de preuve à partir des contrats
2/ Concevoir un système qui vérifie la cohérence des contrats, ie. qu'il n'y ait pas incomplétude.
3/ Prouver le compilateur ou au moins une bonne partie
donc
4/Prouver le langage (sa grammaire)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'en ai parlé à Benoit, et il m'a répondu que cela ne l'intéressait pas, que ça limite Lisaac à Gcc et qu'on serait tributaire des changements de langage de Gcc.
Plus précisément ça le gonfle, il estime (et je suis d'accord) qu'il y a des choses plus intéressantes à faire.
Je te rappel qu'il est chercheur et t'informes qu'il est plus intéressé par des problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
C'est pas une mauvaise idée en soit du moment qu'elle soit optionnelle.
Cela dit, on ferait beaucoup mieux de travailler sur l'optimisation de la sémantique que de pinailler sur des optimisation en assembleur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Bonne question.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Si on essaye de coder la même chose directement en C, étant donné que le C n'a pas de concept d'héritage et que son préprocesseur n'est pas assez puissant, on est obliger de chercher la fonction toto() à l'étape 3 (runtime), ce qui signifie qu'on se traine des pointeurs de fonctions, et qu'on ne peut pas inliner. Autrement dit, si tu veux gérer l'héritage, le problème "trouver toto" doit être résolu à une étape, et le C ne permet pas de le résoudre à l'étape 2. Si tu le résouds à l'étape 3, tu perds en performance. Il ne reste que l'étape 1 pour optimiser.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
T'es lourd.
C'est la dernière fois que te répond parce que t'es vraiment bouché, et c'est pas la première fois que je me fait cette réflexions. Tu as une aptitude pour donner l'impression d'argumenter d'une façon qui se révèle en fait bancale qui me laisse rêveur.
J'ai essayé d'être constructif en soulevant ce qui pour moi était essentiel dans un langage avec cet objectif de remplacer le C, dans l'espoir d'avoir des explications.
Question : T'as au moins fait l'effort de jeter un oeil sur la doc ?
Elle est là : http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Va falloir que je la cite pour t'expliquer.
Page 47.
3.2.3 The mapping section The mapping section purpose is to format data slots description according to some o/xed hard-ware data structure.
In such a section, the compiler follows exactly the order and the description of slots as they arewritten to map exactly the
corresponding hardware data structure. Thus, one is able to write data slots description according to the hardware to handl
e.You can only deo/ne slots with the + symbol, and only datas (not code). Otherwise, these attributes are used exactly as th
e others not in the mapping section (readingor writting).
These prototype match exactly a 16 byte physical structure.
Slots inside some mapping section are considered private for any other objects. Slotscan only be deo/ned with the + property
. No slot outside this section can be deo/ned with the + property.
La section INTERRUPT
Page 48
3.2.4 The interrupt section
The goal of the interrupt section is to handle hardware interruptions.In this section you can deo/ne methods (code slots) that will be executed only while there is an interrupt associated.Each slot is associated with one of the processor's interruptions [Hum90]. These slots dioeer from others in their generated code. For example, their entry and exit codesare related to the interrupt processing. Their invocations are asynchronous and borrow the quantum of the current process.Generally, these slots are little time consumers and they don't require specio/c process' context for their executions.It is thus necessary to be careful while programming such slots to ensure the consistency of the interrupted process.
Deo/ne your method (without return value, because you don't explicitly call it) as any otherclassical method. Then associate the adress of your method with the eoeective interrupt jump adress (it dependsof your architecture). This can be done using a system mapped object. When your interrupt physically happends, there is the call of your associated method, whichreturns a pointer on the code. The compiler will not optimize local variables of your interrupt method because of its particu-larity : the call depends of the context and cannot be anticipated during compilation.
Je te renvoi à cette page, si tu pouvais y passer ne serait-ce que 30 secondes.
L'intérêt de Lisaac est de permettre de gérer des interruptions ainsi que des sections Mapping permettant de poser le code sur une structure binaire.
Ceci permet donc d'écrire des drivers. IsaacOS, que certains qui se sont exprimés ont comme moi vu tourner sur une machine est un OS entièrement écrit en Lisaac qui utilise ces fonctionalitées pour écrire un OS from scratch.
Il te faut quoi comme preuve ?
Pour le reste, c'est une affaire de goût (pointeurs, langages, etc...) mais ces fonctionalitées permettent d'écrire des drivers.
mais il y a de gros problème de performance du compilateur.
Un langage qui sur une application "critique", un décodeur Mpeg2, 9852 lignes de code en C, 6176 lignes de code après traduction en Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
T'es con ou t'es con ?
Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
C'est vrai... mon logiciel de GPAO ou mon gros client mail, je le compile tout les matins en arrivant au boulot. Mon FireFox aussi..
Qu'est-ce qu'on en a à foutre que la compilation est "lente" (parce qu'en passant, "lente", Lisaac met 30 secondes pour compiler 60 000 lignes, je crois pas que Gcc puisse soutenir la comparaison, désolé).
Est-ce que tu pourrais me démontrer en quoi dans l'industrie, à part pour ces conneries de JIT (nous c'est pas notre problème, c'est compilé), on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non.
C'est de ma faute à moi ?? C'est de la faute à l'auteur de la news ???
Non, c'est une question qui concerne celui qui a le pouvoir de libérer le code, soit la direction de l'INRIA.
T'es prié d'apprendre à te plaindre à la personne responsable, pas ceux qui n'y peuvent rien.
Quand on te colle une amande parce que tu t'es mal garé, tu gueule contre le flic ?
Moi non. Il fait son boulot, et c'est normal qu'il le fasse.
J'aimerai que ça soit pareil vis à vis de moi, merci.
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
De plus, tu as toute la doc disponible sur le site pour apprendre ce qu'est l'objet à prototype. C'est un concept vieux de 20 ans, et cela ferai du bien à ta culture.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Apprend que tout est lié.
Il faut vraiment que tu apprennes à raisonner, TImaniac, ça devient grave.
Boubou te l'a déjà dit, lui qui est normalien et docteur en maths, il est bien placé pour le savoir.
Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Il est très loin d'être parfait, vu tout ce que je veux mettre dedans, et de toutes façon le modèle des langages à grammaire classique m'emmerdent, je trouve ça beaucoup trop restrictif.
Donc non. Je défend Lisaac parce que je pense que ce langage apporte ce qui n'existait pas jusqu'alors : un langage de haut niveau avec des performances proches du C (et bientôt meilleurs je pense) avec des fonctionalitées bas niveau.
La preuve, un OS a été écrit avec.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
Je te l'ai déjà dit p****, c'est pas de notre ressort.
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
va falloir être fort pour vendre ça aux types qui comme moi continuent à faire du C aujourd'hui, après avoir essayé C++ et Java, et en être revenu.
Oui bien sûr, ça va prendre du temps.
Lisaac aura ses utilisateurs, C sera encore utilisé encore longtemps... Et alors.
Certains projets utiliseront C, d'autres Lisaac, ce sera en fonction de la situation de chacun.
Personnelement, à la différence de nicO, qui en tant qu'ingé microélectronique s'intéresse au bas niveau, je suis plus attiré par les fonctionnalités haut niveau, le (bon) design de la lib, etc...
Après... Lisaac possède en natif des fonctionnalités système, personellement je ne les utiliserai pas et de toutes façons, elles sont là et les utilisera qui veut.
Seulement, quand on aura un code qui pour un algo similaire fera 30 % de lignes code en moins pour 10 % de perf en mieux (pour le moment on est à 2% moins bien), pas mal de projet faisable qu'en C à l'heure actuel pourront être fait en Lisaac.
Pour le très bas niveau, ok, le C, c'est très bien.
Pour des applications critiques comme un player mpeg2 ou autres choses du même style, j'en vois par contre un gros intérêt : réduire les coûs, de dev, mais aussi de debugging.
Le leimotiv de Benoit (je l'ai entendu 15 fois) c'est "un gros projet en C, ça devient ingérable. C'est vrai qu'on se sent puissant à jouer avecles pointeurs, mais à un moment ça devient trop lourd". Et il sait de quoi il parle !
Effectivement, les langages de scripts ont des avantages (introspection), mais je pense qu'en bidouillant, on peut se débrouiller pour les compiler.
Lisaac est une aventure qui ne fait que commencer.... ;-)
En ce qui me concerne, le travail à fournir est plus dans les fonctionnalités du langage (fonctionnalités agent créant des threads automatiquement, type MATCH permettant de choisir son type au dernier moment, SQL intégré, etc..) mais aussi dans le designe de la lib.
Regarde la librairie graphique, pour gérer des fenêtre, elle est super bien faites, avec son système de boite au lettre qui te permet de gérer les éveènements clavier souris comme du courrier.
L'avenir du langage passe aussi par là...
- Faire gaffe à l'inflation de types, comme Java. --> minimum de type pour le maximum de choses. Merci l'héritage dynamique, ça va servir à ça.
- Faire des fonctions avec des noms et mot clés intuitifs.
Pour la question des licences, je suis totalement d'accord avec toi, comme je l'ai expliqué plus haut.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# amule
Posté par Ontologia (site web personnel) . En réponse au message emule. Évalué à 3.
Dans ton menu K suit Système -> Configuration -> Paquetages -> installer des logciels.
Dans la zone de texte à gauche de "chercher", tapes "amule"
Cliques sur chercher. Tu devrais voir amule apparaître.
Installe le.
Il devrait être dans ton menu, section internet/transfert de fichiers.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: [x] WML
Posté par Ontologia (site web personnel) . En réponse au sondage Pour développer un site web, je préfère utiliser. Évalué à 2.
C'est quoi fondamentalement, les différences avec PHP ? (je ne parle pas de syntaxe, ni de lib, mais de concept) ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Attention à la version de Qemu
Posté par Ontologia (site web personnel) . En réponse à la dépêche Virtualisation complète avec kqemu. Évalué à 2.
http://fabrice.bellard.free.fr/qemu/download.html
On apprend là http://fabrice.bellard.free.fr/qemu/kqemu1-doc.html qu'il faut recompiler le noyau, c'est personnelement, ce qui me bloque. Pas envie de repartir dans les galères.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Deux questions
Posté par Ontologia (site web personnel) . En réponse à la dépêche La stratégie de Microsoft contre le Logiciel Libre. Évalué à 2.
Ouais ils vont créer IsaacOS ;-))
Ok, je ---> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: mon avis
Posté par Ontologia (site web personnel) . En réponse à la dépêche La stratégie de Microsoft contre le Logiciel Libre. Évalué à 2.
Personnelemment, je n'ai jamais vu ces systèmes de versions sur les Office version 95 à Xp que j'ai eu à administrer.
Je suis intéressé, je leur ferai passer le message, car je sais qu'ils se prennent encore la tête avec ça.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le retard de Vista a du bon...
Posté par Ontologia (site web personnel) . En réponse au journal Contestation interne chez Microsoft. Évalué à 3.
2 Go seront probablement nécessaires pour le voir tourner "correctement"...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Cool, un linux avec des jeux
Posté par Ontologia (site web personnel) . En réponse au journal Des nouvelles de la PS3. Évalué à 4.
J'ai quelques doutes quand à la rationalité économique de la chose d'une part, voire la prétendue facilité technique d'autre part.
A mon avis, outre que le noyau Linux va être un petit peu modifié, pas mal d'interface risquent d'être propriétaire, comme les API sons, vidéo, IA, réseaux peut être (pour le haut niveau tout au moins).
Donc passer les jeux d'une PS3 sur un PC linux avec un une architecture assez différente, j'y crois peu.
Après, pourquoi faire l'effort de porter un logiciel qu'il faut pouvoir garantir sur x distributions parce qu'elles ne sont pas toutes compatibles entre elles au niveau binaire.
Ce lien est un nid à troll, mais il donne des pointeurs sur le débat :
http://www.logiciellibre.net/2004/news20040330.php
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Autres langages à prototype
Posté par Ontologia (site web personnel) . En réponse au journal Un compte rendu de la conf sur isaac/lisaac. Évalué à 2.
Non, juste 95 % ;-*)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et c'est où pour tester ?
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 3.
Après le tester....
A voir si on le met dans la distrib
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pour vous éviter un clic
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 2.
Néanmois, ne pas oublier que ce genre de possibilitée est directement offerte par le fait que Lisaac soit un langage objet à prototype, et que cette différence permet une bien plus grande flexibilité qu'un modèle à classe où il faudrait écrire des composants (voir Think, etc...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Concrètement...
Posté par Ontologia (site web personnel) . En réponse au journal Introduction à PostgreSQL. Évalué à 3.
Avec Postgre, tu peux faire de belles requêtes bien complexes, et il va te les exécuter à une vitesse phénoménale.
MySQL, c'est bien pour faire select prenom, nom from client, mais dès que ça devient trop compliqué, il suit plus.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pour vous éviter un clic
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 4.
Au contraîre !
Ecrire un driver sous Isaac devient d'une simplicité enfantine.
Regarde le driver VIDEO. VIDEO hérite de BITMAP, donc il possède toutes les fonctions de dessins, etc...
Dans VIDEO tu as a écrire les méthodes :
- make w,h:INTEGER
Pour initialiser
- close
Pour clore ;-)
- pixel_hard x,y:INTEGER color col:UINTEGER
Le pixel_ hard.
C'est la seule méthode indispensable. Tout est écrit dans bitmap à partir de celles-là.
- line_h_hard x,y:INTEGER until x1:INTEGER color col:UINTEGER
Méthode facultative
- line_h_hard x,y:INTEGER until x1:INTEGER image line:BMP_LINE offset ofs:INTEGER
Idem, pour dessiner une ligne de bitmap.
Comme VIDEO hérite de BITMAP et que BITMAP contient tout ce qu'il faut pour dessiner des lignes, des points, polygones, cercles, etc.. il suffit que VIDEO redéfinisse la méthode et c'est bon.
Donc si Nvidia ou ATI veulent écrire un driver pour IsaacOS, il leur suffit d'écrire quelques méthodes de ce genre, plus des méthodes pour la 3d.
Les fonctionalités systèmes de Lisaac font le reste.
Donc, non, écrire un driver pour IsaacOS est enfantin.
C'est une de ses intérêts majeurs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pour vous éviter un clic
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 4.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas exactement
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 4.
Tiens, et si on verrouillait toutes les façons de faire des messages if, while, etc... ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pourquoi breveter ?
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 3.
Le compilateur utilise une technique d'analyse de flot qui permet d'analyser l'ensemble du code vivant. Cette annalyse de flot permet de faire pas mal de prédictions de types, spécialisation, etc...
C'est un algo novateur qui n'a jamais été utilisé ailleurs et qui doit être protégé.
Je ne veux que cela tombe dans l'escarcelle du logiciel propriétaire.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas exactement
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 2.
Donc le fait que la licence de la lib soit viral, implique que tout code généra avec le compilateur utilisant cette lib est sous cette licence (Cecill en l'occurance), le source C ainsi que le binaire.
Il est donc interdit de faire du proprio avec le compilateur Lisaac en l'état, à mois de réécrire la lib...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Pas exactement
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac libéré ?!?. Évalué à 4.
Le compilateur, pas encore.
L'INRIA "exige" les droits sur le brevet, bien qu'à ma connaissance rien n'ait été déposé. Par contre le programme a été déposé dans plusieurs pays pour prouver l'antériorité, éventuellement.
IsaacOS sera bientôt libéré (l'autorisation en a été donnée jusqu'à nouvel ordre), mais Benoit aimerait terminer la version 0.2 du compilateur (qui a impliqué une récriture complète de celui-ci), faire une belle distrib, avec quelques explications.
Bref, faire les choses proprement.
En ce qui concerne le compilateur, il y a encore incertitude, surtout que si l'INRIA veut déposer un brevet, c'est un long processus.
Trollez bien pendant 24 h (je ne serai pas là) ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: qques questions sur Lissac et... Ruby, Java, Caml...
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
C'est une tentative de repenser intégralement la façon de programmer en introduisant des notions de reconnaissances de forme, de manipulation ensembliste des données, de métaprogrammation, etc...
Cela dit, tu soulèves des points intéressants, bien que je pense qu'il est possible de faire un langage de spec très haut niveau sufiseament léché au niveau théorique pour cracher quelque chose de propre.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
C'est dans la lignée des travaux de Jean-Christophe Filliatre
http://why.lri.fr/index.fr.html
Exemple : http://why.lri.fr/examples/sqrt/sqrt.mlw.html
Why génère une preuve pour COQ qui se charge dé montrer que l'algo est valide.
Le problème est que COQ n'est pas incrémental.
Il y a plusieurs défis :
1/ Concevoir un générateur de preuve à partir des contrats
2/ Concevoir un système qui vérifie la cohérence des contrats, ie. qu'il n'y ait pas incomplétude.
3/ Prouver le compilateur ou au moins une bonne partie
donc
4/Prouver le langage (sa grammaire)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
Plus précisément ça le gonfle, il estime (et je suis d'accord) qu'il y a des choses plus intéressantes à faire.
Je te rappel qu'il est chercheur et t'informes qu'il est plus intéressé par des problématiques de preuves automatiques de programmes que par des histoires d'optimisations.
C'est pas une mauvaise idée en soit du moment qu'elle soit optionnelle.
Cela dit, on ferait beaucoup mieux de travailler sur l'optimisation de la sémantique que de pinailler sur des optimisation en assembleur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
C'est vrai que c'est une optimisation de très bas niveau.
On est en train de réfléchir à des optimisations plsu haut niveau, comme le déroulement et la paraléllisation de grosses boucles. Du genre transformer
http://www.haypocalc.com/wiki/Image:Graphe_s%C3%A9quentiel.j(...)
en
http://www.haypocalc.com/wiki/Image:Graphe_paral.jpg
L'intérêt de ce genre de chose, c'est que pour des grosses boucles, on peut carrément demander au compilateur, de paralélliser le code, et de créer n threads (en lui donnant les primitives de gestion de threads), ce qui permet d'optimiser le code pour n cores...
Je recopie un mail que j'ai envoyé à nicO
"
Imagine qu'on ait un gros calcul de ce type à optimiser sur plusieurs cores.
On peut carrément imaginer de réorganiser la mémoire du tableau in et out de sorte à les couper en n portions, et mettre à la suite les octets de in espacés de n octets, en intercalant in et out
Genre
Zone 1
in[1], out[1],in[n+1],out[n+1]
Zone 2
in[2],out[2],in[n+2],out[n+2]
etc... n fois
Là en fonction des paramètres qu'on lui donne à la compil (lié à l'organisation de la mémoire ainsi que la capacité pour les cores d'y accéder), on lui fait mener, sur n threads, n calculs paralèlles.
On somme à la fin.
Ça torche.
"
Pour généraliser et conclure : un compilateur avec un nombre minimum de primitive , couplé à une bonne analyse de flot permet de remonter très facilement à la sémantique et d'optimiser énormément de choses : on peut imaginer un moteur de pattern matching (reconnaissance de structure dans le graphe du code) et ses règles de transformations.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
On ne cherche pas à cracher de l'assembleur pour tel ou tel processeur car
1/ C'est pas portable. Donc c'est stupide.
2/ Que le C est un langage qui peut être très bas niveau
3/ Que les vrais optimisations intéressantes sont des optimisations haut niveau. J'entend toujours Benoit me dire ("Dans les optims de bas niveau, c'est pas la peine, tout à été fait"). Une vrai optimisation intéressante, c'est détecté un if caché dans une résolution dynamique, dérursiver une récursive terminale, etc...
4/Enfin et surtout, que faire cracher de l'assembleur pour un processeur est un travail de fourmi !! C'est un travail qui prend un temps fou, il faut s"adapter à chaque architecture, et, en terme d'optimisation ça n'a quasiment aucun intérêt.
Cracher un assembleur correcte nécessite un travail énorme, faire des optimisations nécessite de maîtriser à fond les spec d'un processeurs.
Et à chaque fois, faut recommencer. C'est un travail énorme, à plein temps.
Le C, langage dans lequel tu peux contrôler énormément de choses, te permet de faire beaucoup d'optimisations bas niveau, ça suffit amplement.
Je t'invite à lire les articles de nicO dans LinuxMag pour t'en convaincre.
Conclusion : il est totalement stupide de faire un compilateur qui crache de l'assembleur alors que des gens (ceux qui font gcc) le font à notre place. Notre boulot, c'est de faire des optimisations haut niveau qui marchent sur tous les processeurs ! Pas la bidouille qui marche sur Athlon Barton, mais pas sur Athlon 64 X2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
C'est la dernière fois que te répond parce que t'es vraiment bouché, et c'est pas la première fois que je me fait cette réflexions. Tu as une aptitude pour donner l'impression d'argumenter d'une façon qui se révèle en fait bancale qui me laisse rêveur.
J'ai essayé d'être constructif en soulevant ce qui pour moi était essentiel dans un langage avec cet objectif de remplacer le C, dans l'espoir d'avoir des explications.
Question : T'as au moins fait l'effort de jeter un oeil sur la doc ?
Elle est là : http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Va falloir que je la cite pour t'expliquer.
Page 47.
3.2.3 The mapping section The mapping section purpose is to format data slots description according to some o/xed hard-ware data structure.
In such a section, the compiler follows exactly the order and the description of slots as they arewritten to map exactly the
corresponding hardware data structure. Thus, one is able to write data slots description according to the hardware to handl
e.You can only deo/ne slots with the + symbol, and only datas (not code). Otherwise, these attributes are used exactly as th
e others not in the mapping section (readingor writting).
Section MAPPING
+ x1:uinteger; // 4 bytes, unsigned
+ x2:usmallint; // 1 byte, unsigned
+ x3:smallint; // 1 byte, signed
+ x4:ushortint; // 2 bytes, unsigned
+ x5:uinteger; // 4 bytes, unsigned
+ x6:shortint; // 2 bytes, signed
+ x7:ushortint; // 2 bytes, unsigned
These prototype match exactly a 16 byte physical structure.
Slots inside some mapping section are considered private for any other objects. Slotscan only be deo/ned with the + property
. No slot outside this section can be deo/ned with the + property.
La section INTERRUPT
Page 48
3.2.4 The interrupt section
The goal of the interrupt section is to handle hardware interruptions.In this section you can deo/ne methods (code slots) that will be executed only while there is an interrupt associated.Each slot is associated with one of the processor's interruptions [Hum90]. These slots dioeer from others in their generated code. For example, their entry and exit codesare related to the interrupt processing. Their invocations are asynchronous and borrow the quantum of the current process.Generally, these slots are little time consumers and they don't require specio/c process' context for their executions.It is thus necessary to be careful while programming such slots to ensure the consistency of the interrupted process.
Deo/ne your method (without return value, because you don't explicitly call it) as any otherclassical method. Then associate the adress of your method with the eoeective interrupt jump adress (it dependsof your architecture). This can be done using a system mapped object. When your interrupt physically happends, there is the call of your associated method, whichreturns a pointer on the code. The compiler will not optimize local variables of your interrupt method because of its particu-larity : the call depends of the context and cannot be anticipated during compilation.
Je te renvoi à cette page, si tu pouvais y passer ne serait-ce que 30 secondes.
L'intérêt de Lisaac est de permettre de gérer des interruptions ainsi que des sections Mapping permettant de poser le code sur une structure binaire.
Ceci permet donc d'écrire des drivers. IsaacOS, que certains qui se sont exprimés ont comme moi vu tourner sur une machine est un OS entièrement écrit en Lisaac qui utilise ces fonctionalitées pour écrire un OS from scratch.
Il te faut quoi comme preuve ?
Pour le reste, c'est une affaire de goût (pointeurs, langages, etc...) mais ces fonctionalitées permettent d'écrire des drivers.
mais il y a de gros problème de performance du compilateur.
Un langage qui sur une application "critique", un décodeur Mpeg2, 9852 lignes de code en C, 6176 lignes de code après traduction en Lisaac est 1,94 % + lent, t'appelles ça des "gros problème de performance du compilateur" ?
T'es con ou t'es con ?
Mais quel est l'intérêt de proposer une optimisation globale avec un algo à la complexité exponentielle ? Tout le problème des optimisations c'est justement de les faire dans un temps raisonnable, là ca sera une vraie évolution et véritable apport à l'informatique.
C'est vrai... mon logiciel de GPAO ou mon gros client mail, je le compile tout les matins en arrivant au boulot. Mon FireFox aussi..
Qu'est-ce qu'on en a à foutre que la compilation est "lente" (parce qu'en passant, "lente", Lisaac met 30 secondes pour compiler 60 000 lignes, je crois pas que Gcc puisse soutenir la comparaison, désolé).
Est-ce que tu pourrais me démontrer en quoi dans l'industrie, à part pour ces conneries de JIT (nous c'est pas notre problème, c'est compilé), on a besoin de compilateurs qui doivent absolument optimiser le code en temps polynomiale ?????
J'aimerai bien comprendre.
On aurait les sources on pourrait se faire une idée de ce fameux algo. Mais non.
C'est de ma faute à moi ?? C'est de la faute à l'auteur de la news ???
Non, c'est une question qui concerne celui qui a le pouvoir de libérer le code, soit la direction de l'INRIA.
T'es prié d'apprendre à te plaindre à la personne responsable, pas ceux qui n'y peuvent rien.
Quand on te colle une amande parce que tu t'es mal garé, tu gueule contre le flic ?
Moi non. Il fait son boulot, et c'est normal qu'il le fasse.
J'aimerai que ça soit pareil vis à vis de moi, merci.
Tu noteras au passage que je me suis bien gardé de critiquer la technique objet à base de prototype puisque je n'ai pas étudié la question : je n'ai parlé que de ce je connaissais : les langages objets "classiques" et leur environnement, le C et les optimisations.
Déjà, j'ai pas l'impression que tu connaisses, a te lire. J'ai l'impression d'en connaitre plus que toi.
De plus, tu as toute la doc disponible sur le site pour apprendre ce qu'est l'objet à prototype. C'est un concept vieux de 20 ans, et cela ferai du bien à ta culture.
Cela montre ta vrai nature TImaniac : tu débats pied à pied et tu n'as pas l'élémentaire réflexe d'aller te documenter sur le coeur de la notion.
Apprend que tout est lié.
Il faut vraiment que tu apprennes à raisonner, TImaniac, ça devient grave.
Boubou te l'a déjà dit, lui qui est normalien et docteur en maths, il est bien placé pour le savoir.
Ontologia a essayé d'avoir réponse à tout sans jamais remettre en cause Lisaac, à croire que le langage est parfait.
Il est très loin d'être parfait, vu tout ce que je veux mettre dedans, et de toutes façon le modèle des langages à grammaire classique m'emmerdent, je trouve ça beaucoup trop restrictif.
Donc non. Je défend Lisaac parce que je pense que ce langage apporte ce qui n'existait pas jusqu'alors : un langage de haut niveau avec des performances proches du C (et bientôt meilleurs je pense) avec des fonctionalitées bas niveau.
La preuve, un OS a été écrit avec.
Ben continuez à tripper sur ce langage, et revenez poster une news ou un journal quand vous apporterez enfin quelque chose d'intéressant à la communauté informatique libre : le partage de vos connaissances en matière d'optimisation. Là on pourra voir si c'est applicable à d'autres langages plus "utilisables" dans un contexte industriel.
Je te l'ai déjà dit p****, c'est pas de notre ressort.
Je te signale tout de même que la lib est libre et que l'OS sera publié bientôt.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: One size fits all
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Oui bien sûr, ça va prendre du temps.
Lisaac aura ses utilisateurs, C sera encore utilisé encore longtemps... Et alors.
Certains projets utiliseront C, d'autres Lisaac, ce sera en fonction de la situation de chacun.
Personnelement, à la différence de nicO, qui en tant qu'ingé microélectronique s'intéresse au bas niveau, je suis plus attiré par les fonctionnalités haut niveau, le (bon) design de la lib, etc...
Après... Lisaac possède en natif des fonctionnalités système, personellement je ne les utiliserai pas et de toutes façons, elles sont là et les utilisera qui veut.
Seulement, quand on aura un code qui pour un algo similaire fera 30 % de lignes code en moins pour 10 % de perf en mieux (pour le moment on est à 2% moins bien), pas mal de projet faisable qu'en C à l'heure actuel pourront être fait en Lisaac.
Pour le très bas niveau, ok, le C, c'est très bien.
Pour des applications critiques comme un player mpeg2 ou autres choses du même style, j'en vois par contre un gros intérêt : réduire les coûs, de dev, mais aussi de debugging.
Le leimotiv de Benoit (je l'ai entendu 15 fois) c'est "un gros projet en C, ça devient ingérable. C'est vrai qu'on se sent puissant à jouer avecles pointeurs, mais à un moment ça devient trop lourd". Et il sait de quoi il parle !
Effectivement, les langages de scripts ont des avantages (introspection), mais je pense qu'en bidouillant, on peut se débrouiller pour les compiler.
Lisaac est une aventure qui ne fait que commencer.... ;-)
En ce qui me concerne, le travail à fournir est plus dans les fonctionnalités du langage (fonctionnalités agent créant des threads automatiquement, type MATCH permettant de choisir son type au dernier moment, SQL intégré, etc..) mais aussi dans le designe de la lib.
Regarde la librairie graphique, pour gérer des fenêtre, elle est super bien faites, avec son système de boite au lettre qui te permet de gérer les éveènements clavier souris comme du courrier.
L'avenir du langage passe aussi par là...
- Faire gaffe à l'inflation de types, comme Java. --> minimum de type pour le maximum de choses. Merci l'héritage dynamique, ça va servir à ça.
- Faire des fonctions avec des noms et mot clés intuitifs.
Pour la question des licences, je suis totalement d'accord avec toi, comme je l'ai expliqué plus haut.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker