Articles précédents : Développeur
- [5] Trophées du Libre 2007 : derniers jours pour les candidats
- [14] Squeak By Example
- [51] Un représentant d'AMD annonce l'ouverture des spécifications des Radeons
- [58] Sortie de la version 3.0a1 du langage Python
- [19] Clutter : enfin une bibliothèque d'animation pour GNOME
- [14] Appel à contributeur synthèse vocale
- [15] Azuki recherche des contributeurs
- [126] Intel libère TBB
- [21] Sortie de la version 2.5 du langage Tom
- [15] Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0
Liens connexes
- Isaac Project (1051 hits)
- Page de téléchargement (240 hits)
- Benchmarks (482 hits)
- Lisaac sur Wikipédia (1056 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Lisaac 0.12 en GPL v3
Posté par Ontologia (page perso, ). Modéré le 24 septembre 2007.Les benchs effectués sur des traductions fidèles de programmes C donnent des résultats différents en fonction de l'architecture cible : on obtient, grossièrement, un code de 20 % plus rapide à 30 % plus lent.
La spécification 0.2 apporte de nombreuses nouveautés au langage : un système de types amélioré, une syntaxe où la casse permet de séparer clairement mot-clé, prototype/type et variables, un système de contrats amélioré et gérant l'héritage, une gestion automatique des micro/macro objets, l'héritage alimentaire, une gestion des blocks très puissante. L'innovation la plus visible est l'apparition des résultats multiples : une méthode peut retourner plusieurs valeurs, de même qu'elle peut en accepter plusieurs en argument.
Le compilateur est en outre capable de produire des statistiques sur les appels potentiels sur NULL et de prédire l'endroit où ils risquent d'arriver. Les temps d'exécution, la consommation mémoire et surtout la stabilité du compilateur ont été considérablement améliorés.
L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code. Cette technique de compilation, qui analyse et prédit les chemins potentiellement empruntés par le code à l'exécution permet une optimisation très poussée de celui-ci afin se rapprocher des performances du C (voir les benchs).
Dominique Colnet (auteur de SmartEiffel) et Benoit Sonntag ont quasiment terminé un traducteur Eiffel vers Lisaac. Ce traducteur permettra à Lisaac de bénéficier d'une bibliothèque Eiffel rigoureusement traduite de l'originale, et donc de disposer d'une bibliothèque testée et sûre. Cette bibliothèque devra ensuite être retravaillée afin d'utiliser au mieux la puissance d'un langage objet à prototype.
La version 0.3 de Lisaac, implémentera la gestion de la concurrence avec le modèle COP, qui automatisera celle-ci. La version 0.4 apportera la stabilisation syntaxique, sémantique et fonctionnelle du langage, ce qui permettra le lancement du projet Isaac OS, le système d'exploitation objet à prototype. Le projet Isaac sera ainsi réellement lancé.
Espérons que la communauté répondra présent à ce formidable défi.
NdM : l'"héritage alimentaire" est appelé comme cela car c'est un héritage qui possède toutes les propriétés de l'héritage classique, mais "secrètement". C'est à dire que vu de l'extérieur de l'objet qui utilise ledit héritage alimentaire, on ne sait pas qu'il hérite.
Isaac Project (1051 hits)
Page de téléchargement (240 hits)
Benchmarks (482 hits)
Lisaac sur Wikipédia (1056 hits)
> Lire la suite (345 commentaires, moyenne: 2,3). [dépêche : 9904 caractères]
La principale difficulté fut de réussir à compiler un tel langage afin d'obtenir des performances permettant d'écrire un système d'exploitation autonome. En effet, la plupart des langages orientés objet compilés (C++, Eiffel...) utilisent soit des techniques de tables virtuelles (C++) pour résoudre la liaison dynamique (choix de l'objet sur lequel appeler une méthode, en fonction de l'arbre d'héritage) ou de résolution syntaxique grossière (Eiffel). Le compilateur Lisaac utilise une technique d'analyse de flot, certes très consommatrice en mémoire (algorithme exponentiel), afin d'analyser les possibilités d'exécution, prédire les appels, les spécialisations de type et optimiser le code en conséquence. Le langage étant très minimaliste (le compilateur ne connait pas la conditionnelle qui est défini dans la bibliothèque, à la manière de Smalltalk), le compilateur travaille sur une sémantique très bas niveau, ce qui lui permet de généraliser toutes sortes d'optimisations, en analysant la géométrie du graphe du code.
Adhérant largement aux principes de génie logiciel définis par Bertrand Meyer, le concepteur d'Eiffel, Benoit Sonntag a conçu un langage fortement typé et doté de contrats.
Le compilateur embarque aussi la possibilité de définir des contrats qui permettront de s'assurer de la validité de chaque unité de code et de s'arrêter à l'endroit où se trouve le problème, puis de l'afficher. Un système permettant de vérifier statiquement une partie des contrats a été implémenté dans cette version.
Lisaac, un peu à la manière de Smalltalk, possède le prototype BLOCK comme fondement. BLOCK est une liste d'instructions à évaluation retardée jusqu'à l'appel de la méthode .value. On peut ainsi écrire toutes les structures de contrôle que l'on désire, écrire des fonctions que l'on ne retrouve généralement que dans les langages fonctionnels (comme map/fold/filter).
La fonction fold_left de collection, est définie par :
- fold_left function:BLOCK with element:E :E <-
( + result:E;
result := element;
lower.to upper do { j:INTEGER;
result := function.value (result,item j);
};
result
);
s'utilise
maliste.fold_left { i,j : INTEGER;
i.max j
} with 0;
maliste étant un tableau d'entier.
La bibliothèque, directement issue de celle d'Eiffel, n'utilise que très peu ces possibilités. Les évolutions de celle-ci vont donc entre autre chercher à en tirer plus souvent partie.
En Lisaac, il n'existe pas de différence entre slots et données, ainsi la syntaxe est la même entre une propriété et une méthode. De même une méthode peut devenir une donnée :
- code_vers_donnee : INTEGER <- (
+ un_entier_quelconque : INTEGER;
// code
// ...
code_vers_donnee := un_entier_quelconque
);
code_vers_donnee va devenir et rester une propriété. Bien évidemment, il pourra redevenir plus tard une fonction.
On peut jouer de la même façon avec le slot définissant le parent. En effet, héritage dynamique oblige, le parent est défini dans la section Inherit :
Section Inherit
+ parent : Expanded FATHER := FATHER;
// Code...
Section Public
- set_parent p_parent : FATHER <- (
parent := p_parent;
);
On peut définir parent où l'on veut dans le reste du code du prototype.
Apport de la spécification 0.2
La spécification 0.2 apporte des innovations importantes
- Meilleur typage grâce à l'héritage alimentaire et au mot clé Strict qui impose strictement l'utilisation d'un type.
- L'héritage alimentaire (Interfaces ou mix-ins) permet de profiter des avantages de l'héritage sans hériter du type. Ainsi si B hérite alimentairement de A, B ne peut être de type A, même s'il hérite de l'ensemble de ses slots. C'est un concept existant dans les langages SmartEiffel (qui a maintenant sa propre norme) et Sather, qui permet de réaliser des arbres d'héritage beaucoup plus propre.
- Un système de contrats amélioré permet de choisir le niveau de debug, afin de choisir la "profondeur" de test des contrats.
- Un slot peut renvoyer une liste de valeurs, et on peut de même définir un slot (une variable) comme une liste de type :
- mavar : (INTEGER,STRING,CHARACTER);
- Le mot clé Expanded remplace *.
- Une meilleur gestion des BLOCK. Lisaac est maintenant capable d'encapsuler le contexte Self dans un block, ce qui permet de stocker ceux-ci où l'on veut et de les déclencher au besoin.
- Le support en natif des réels flottants et à virgule fixe.
- Un nouveau gestionnaire mémoire et le Garbage Collector ont été totalement réécrits.
Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY (prototype de base pour les collections, qu'il est déconseillé d'utiliser).
Des contrats sur des données et du code
Non content de permettre de poser des contrats sur des slots de code, il est aussi possible d'en poser sur des slots de données. Par exemple, je veux qu'un entier soit strictement supérieur à 50 et soit un multiple de 11.
Autrement dit que
[i in |N | i>50 | i mod 11 = 0 ]
Rien de plus facile en Lisaac. À la déclaration de la variable, on écrit :
- i : INTEGER := 110 [ ? {(Result > 50) && {(Result % 11) = 0}}; ];
Le mode debug activé, le compilateur compilera le programme de façon à ce que chaque accès à la variable i vérifie ce contrat. Si celui-ci n'est pas respecté, le programme s'arrête avec un message d'erreur indiquant une valeur non autorisé pour la variable i.
Cette fonctionnalité appartenant à la spécification 0.2 est désactivée dans cette version 0.12 et sera activée dans la version suivante.
Éditeurs et coloration syntaxique
Des templates de coloration syntaxique sont disponibles pour les principaux éditeurs, notamment emacs, Vim, récemment proposé par Xavier Oswald, mais aussi Kate/KDevelop, développé par Anthony Pajot, qui, outre la coloration syntaxique, permet même la complétion sous KDevelop.
Projets
Les prochaines évolutions de la bibliothèque, pour une bonne partie d'entre elles, serviront de base à IsaacOS, qui sera libéré dans quelques mois, lorsque la version de Lisaac implémentant la spécification 0.3 proposant COP (Concurent Object Programming), sera prête.
Lorsque le traducteur Eiffel vers Lisaac sera disponible, on synthétisera une bonne partie de la bibliothèque avec celle de SmartEiffel, qui est testée et certifiée depuis 15 ans. Il sera alors temps d'amender celle-ci d'un point de vue cosmétique, afin de lui faire épouser les réelles possibilités du langage (en particulier les possibilités offertes par le type BLOCK).
Un effort de documentation est à fournir, en effet la bibliothèque donne lieu à deux version de la doc : la version "référence" qui se veut complète mais succincte, et une version plus détaillée qui renseigne chaque méthode des principaux prototypes de la bibliothèque, en détaillant chaque paramètre. Les deux documentations sont incomplètes pour le moment, mais suffisantes pour démarrer. En outre, à la suite de la contribution de Jérome Hilbert, Simon Fuhlhaber et Grégoire Jacquemin produisant un schéma UML (en svg) d'un ensemble de source Lisaac, nous aimerions améliorer celui-ci afin de le rendre plus configurable (position, couleurs des items)
Des rapports de bugs sont attendus pour la bibliothèque et le compilateur, n'hésitez pas à compiler vos programmes avec, cela vous (et nous) permettra de savoir où cela plante exactement.
Nous envisageons, dans les mois qui viennent, de mettre en place une sorte de CPAN pour le langage Lisaac.
À noter que la bibliothèque étant GPLv3, tout logiciel écrit avec cette bibliothèque est elle-même GPLv3 (vaccination oblige).
Sather
Etant un admirateur de Sather, je ne peux qu'être enchanté par cette annonce parfaitement rédigée.
Merci.
-
[^]Re: Sather
Posté par Ontologia (page perso, ) le 24/09/2007 à 20:07. (lien). Évalué à 3.Ah et en passant, je rend à césar son idée, puisque le projet de CLAN (clone de Perl CPAN) est une idée de Sytoka.
Espérons que la masse critique soit suffisante pour que cela serve à quelques chose...-
[^]Re: Sather
Posté par Sytoka Modon (page perso, ) le 27/09/2007 à 05:54. (lien). Évalué à 6.Génial, je suis bien content que nos discutions est amené ce point là qui manque tant à OCaml et à Effeil.
En parlant du CLAN, la notion d'espace de nom a-t-elle été rajouté dans Lisaac ? Je sais que Benoit est contre mais comme il a été indiqué dans pas mal de post de cette nouvelle, l'aspect social est important dans la réussite d'un langage. Or je suis sur que pouvoir structurer l'arbre des classes dans des espaces de noms et donc pouvoir les ranger par thème dans le CLAN est très important. Au niveau du compilateur, vu qu'il y a une optimisation globale, la notion d'espace de nom n'a aucun intérêt. C'est cependant un des soucis d'Effeil de ne pas supporter cela car l'arbre des classes d'Effeil est un 'bordel' à mon sens car il y a 10000 classes à plat. Comment retrouver ses petits la dedans ?
Si on prends le CPAN de Perl, les choses sont classées dans des boites, ce qui est sous l'espace Apache:: concerne Apache et ainsi de suite... C'est hyper clair pour l'utilisateur et facilite grandement search.cpan.org !
Puisque je suis cité, j'en profites, c'est pas tous les jours ;-) Un autre de mes dadas était les iterator de Sather qui était implémenté sous forme de coroutine et qui était bien supérieur a tout ce que j'ai vu dans d'autres langages. Tu l'as dis toi-même dans un de tes posts ci-dessous, un GROS problème en programmation est le nombre d'erreur réalisé dans les bornes des boucles. C'est là ou les iterators de Sather était sublime car je ne me souviens plus avoir fait ce genre d'erreur dans ce langage ce qui n'a pas été le cas avec tous les autres langages que j'ai utilisé.
Pour ceux qui pense que les iterators de leur langage sont aussi bien que ceux de Sather, je conseille d'aller voir la page suivante et de prendre le temps d'aller au dela du premier exemple...
http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
Ma question est donc : est-il possible de faire aussi bien en Lisaac ?-
[^]Re: Sather
Posté par Mildred (Jabber id, page perso, ) le 27/09/2007 à 10:40. (lien). Évalué à 4.Non, il n'y a pas d'espaces de noms. Actuellement, tous les prototypes du compilateur (l'équivalent des classes) doivent avoir un nom différent.
Je ravaille sur un patch du compilateur afin de pouvoir séparer la compilation en projets. Un projet contient des prototypes publics accessibles par les autres projets, et des prototypes privés réservés à lui seul.
Le gros avantage c'est de permettre d'avoir plusieurs prototypes de même nom dans la compilation. Et permet donc un cloisonnement minimal. Cela permet de créer des bibliothèques sans se soucier des noms des prototypes publics par exemple.
Par contre, il n'y a pas de possibilité de préfixer les noms des prototypes par le nom du projet (il faudrait changer le langage, je change juste le compilateur), et il n'y a pas de possibilité de faire des imports partiels ou de renommer des prototypes. Si le besoin est vraiment grand, c'est toujours possible de faire un import partiel/renommage en important un projet intermédiaire qui exporte juste les bons prototypes.
-
[^]Re: Sather
Posté par Ontologia (page perso, ) le 27/09/2007 à 13:01. (lien). Évalué à 2.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 !
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 :)-
[^]Re: Sather
Posté par Sytoka Modon (page perso, ) le 28/09/2007 à 06:54. (lien). Évalué à 6.- As tu regardé les pages suivantes ?
- comment définir un iterator http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
- quelques exemples avec plusieurs iterator et pas forcément entier http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
- J'ai l'impression que ce que tu fait est à des lieux des iterators de Sather et ressemble fortement à ceux de Ruby.
- Il faut bien comprendre ceci. Un objet dans Sather peut avoir trois types d'objet qui lui sont rattaché : des attributs, des méthodes (jusque là, que du classique) et des iterators. Un itetator N'EST PAS une méthode et ne se comporte pas du tout pareil.
- Un iterator est une coroutine qui n'est valable que dans un block loop. Il peut y avoir plusieurs iterators dans un même block (ce qui n'est souvent pas le cas dans les autres langages qui n'ont pas d'iterator de bas niveau mais un truc simulé via des méthodes).
- Un iterator peut avoir des paramêtres de type IN, OUT et INOUT mais avec aussi la notion ONCE ou non. Si un paramêtre à l'adjectif ONCE, il n'est évalué que lors du PREMIER appel alors que sinon, il est évalué à chaque appel.
- Un iterator n'a pas de valeur de retour comme une fonction mais se suspend via l'instruction yield et renvoi provisoirement une valeur à ce moment là. Lors du prochain appel, c'est l'instruction qui suit yield qui est exécuté.
- S'il y a une boucle avec plusieurs iterators, c'est le premier iterator qui se termine (plus de yield) qui permet de quitter la boucle, que les autres iterators soit finis ou non. Par contre, le langage à ce moment termine tous les contextes des autres co-routine non finit et purge la mémoire (mais tout cela est complètement transparent).
- Les iterators de Sather ne sont pas du tout limité aux entiers. C'est juste un cas particulier. Il y a par exemple des ietrator sur les booléens qui permettent de faire les boucles while et until facilement. Il y a plein d'iterator sur les chaînes et aussi sur les réels.
- Je vais mettre deux exemples que j'aime bien mais la syntaxe de linuxfr est parfois casse-pied. On en trouve d'autres sur le web mieux rédigés.
- Il faut évidement définir x mais il n'y a pas besoin de l'initialisér, c'est l'iterator sum! qui s'en occupe. Dans cet exemple, trois itérators fonctionnent en parallèle et le code est particulièrement clair et sur (qui n'a pas oublié un jour de faire x:=0 avant la boucle ?).
loop x := sum!(a.elt! * b.elt!); end;
- Un autre qui parle d'affichage qui permet d'imprimer "1,2,3" en mettant une virgule entre les éléments juste ou il faut.
a:ARRAY{INT} := |1,2,3|; loop #OUT + ",".separate!(a.elt!.str); end;- L'iterator separate! est définit comme suit :
class STR is ... separate!(s: STR): STR is -- La premiere iteration, on retourne juste la chaine 's' -- Sur les suivantes, on retourne Self + 's' yield s.str; loop yield self + s.str; end; end; ... end;- On remarque qu'il y a une boucle infini dans l'itérator separate! Cette boucle ne s'arrête jamais, simplement, lorsque l'iterator separate! n'a plus rien à manger, la boucle au dessus s'arrête d'elle même et toutes les coroutines en cours de tout le contexte sont automatiquement nettoyé.
- On voit bien sur ces exemples que le block LOOP est particulier et permet de gérer les contextes des iterator. C'est le fait d'avoir ce block spécial qui donne toute la force à ces iterators. Les iterators ne peuvent être employés que dans les block loop avec une petite extension syntaxique avec 'parloop' pour la partie calcul parallèle de Sather
http://www.gnu.org/software/sather/docs-1.2/specification/pa(...)- Un dernier lien qui donne les spécifications du langage, c'est pas le document le plus pédagogique que j'ai trouvé ;-)
http://www.gnu.org/software/sather/docs-1.2/specification/sa(...)
-
-
-
[+] Pertinence de cette dépeche ?
A chaque fois qu'une dépeche sur Lissac passe sur DLFP, je me demande ce qu'elle fait là. Alors cette fois-ci, j'exprime mes doutes.
Il me semble que Lissac est juste un language de recherche parmi énormément d'autres. Je ne remets pas en doute son côté innovant, mais pourquoi publier cette dépêche sur DLFP ? Surtout en première page ? Est-ce que ça veut dire que tous les projets de recherche publiés sous licence libre vont avoir droit à une dépêche de premiere page sur DLFP ?
De plus, qui est cet "Ontologia", dont la page perso est celle du projet Isaac ? Quelle est sa relation avec Benjamin Sonntag et avec les modérateurs de DLFP ? A noter que la page Wikipédia de Lisaac[1] est également écrite par lui, et qu'elle provoque également des interrogations[2,3].
[1] http://fr.wikipedia.org/wiki/Lisaac
[2] http://fr.wikipedia.org/wiki/Discuter:Lisaac
[3] http://fr.wikipedia.org/wiki/Utilisateur:Ontologiae
-
[^]Re: Pertinence de cette dépeche ?
Posté par Troy McClure (page perso, ) le 24/09/2007 à 17:18. (lien). Évalué à 9.rapport avec le libre: oui
depeche bien redigée: oui
moi je ne vois pas en vertu de quoi on refuserait une telle dépeche.-
[^]Re: Pertinence de cette dépeche ?
Posté par Antoine () le 24/09/2007 à 17:21. (lien). Évalué à 0.moi je ne vois pas en vertu de quoi on refuserait une telle dépeche.
Parce qu'il y a chaque jour des centaines de projets libres qui sortent une nouvelle version et qu'il faut bien faire un choix ?-
[^]Re: Pertinence de cette dépeche ?
Posté par Benoît Sibaud (Jabber id, page perso, ) le 24/09/2007 à 17:42. (lien). Évalué à 10.> Parce qu'il y a chaque jour des centaines de projets libres qui sortent une nouvelle version et qu'il faut bien faire un choix ?
Le jour où ces centaines de projets libres enverront des centaines des dépêches concernant leur projet respectif, on envisagera de faire un tel choix. En attendant, on passe les dépêches bien rédigées traitant de logiciel libre, et si certains veulent plus de dépêches, qu'ils en proposent, et si certains veulent des dépêches sur un sujet X ou Y, qu'ils en proposent... Maintenant si certains ne veulent pas voir de dépêches sur W ou Z, et bien qu'ils ne les lisent pas...
Les règles de modération sont détaillées sur https://linuxfr.org/moderateurs/moderation.html .-
[^]Re: Pertinence de cette dépeche ?
Posté par Lucas (page perso, ) le 25/09/2007 à 06:49. (lien). Évalué à 6.Attention: je ne remets pas en cause l'intérêt pour la recherche et l'innovation de Lisaac. Je trouve juste votre manière de communiquer un peu curieuse. Comme je l'ai dit plus haut, il y a des dizaines de langages de recherche, tous très innovants dans un domaine particulier. Et il y a aussi des centaines de projets de recherche très innovants qui ne sont pas des langages. :-) Pourtant, il n'y a que sur Lisaac qu'on a régulièrement des dépêches DLFP. Bon, on m'a dit que si une dépêche est bien rédigée en français, et parle de libre, pas de problème pour la passer en première page. OK. J'en prends note.
Maintenant, des questions constructives:
Sur Wikipédia, Lisaac est mis à côté de langages qui ont été utilisés pour des centaines de softs. Peux-tu donner quelques exemples de logiciels écrits en Lisaac ?
Il y a un problème courant de licence avec les compilateurs. Puisqu'en général, ils recopient une partie de leur code dans les fichiers générés, il faut utiliser une exception pour que les fichiers générés ne soient pas soumises à la même licence. C'est le cas de GCC ou de flex: GCC est sous GPL, mais cela n'a pas d'incidence sur les programmes compilés avec GCC. Est-ce qu'une exception similaire est présente dans Lisaac ? Ce qui permettrait à qqun de réimplémenter la bibliothèque (qui elle, est sous GPL, c'est sûr) sous une autre licence ?-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 25/09/2007 à 09:07. (lien). Évalué à 1.Tu racontes n'importe quoi sur les licences. Les licences ne peuvent absoluement pas s'appliquer sur ce qui est généré, c'est du n'importe quoi.
Tu mélanges la licence du compilo et la licence de la library qui va avec.-
[^]Re: Pertinence de cette dépeche ?
Posté par Matthieu C () le 25/09/2007 à 19:38. (lien). Évalué à 2.mouais la frontière n'est pas si nette que ca ?
Par exemple les buildin gcc ca rentre dans quelle catégorie ?
c'est pas du code de la bibliothèque (et pas library), car on ne fait pas appel a une fonction externe
c'est pas du code générer bêtement (ie traduite un + du language en un + assembleur).-
[^]Re: Pertinence de cette dépeche ?
Posté par Mildred (Jabber id, page perso, ) le 27/09/2007 à 10:50. (lien). Évalué à 1.Il n'y a pas vraiment de builtin en Lisaac, tout est pris de la lib standard.
mais c'est vrai que si tu fait un string du compilateur, tu va trouver des constructions C qui sont utilisés pour générer le code. Mais je ne pense pas que ce soit problématique.
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 29/09/2007 à 18:14. (lien). Évalué à 2.Renseigne toi un peu avant de critiquer comme ça : Il existe une exception spéciale de la libstd++ qui permet d'utiliser les templates dans du code proprio car quand tu utilises des templates de cette lib, un bout du code de la libstd++ va se retrouver dans ton code. Et donc théoriquement tu ne pourrais pas faire de proprio, ou autre chose que de la (L)GPL, s'il n'y avait pas cette exception.
-
[^]Re: Pertinence de cette dépeche ?
Posté par TeXitoi (Jabber id, page perso, ) le 29/09/2007 à 18:55. (lien). Évalué à 2.Les templates, c'est des bibliothèques, c'est pas le compilo...
-
[^]Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (page perso, ) le 30/09/2007 à 16:11. (lien). Évalué à 2.Oui, mais tel que GCC les compile, le code compilé correspondant aux templates est dans le binaire, et non dans la bibliothèque partagée.
-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 30/09/2007 à 16:52. (lien). Évalué à 3.... ce qui en fait donc un travail dérivé et devrait donc se soumettre aux conditions de la LGPL, car cela n'est pas du simple linkage. Bref, c'est uniquement grâce à cette exception (en plus de l'"exception" pour linkage) qu'on peut faire du proprio avec la libstd++ et les templates, et qu'un compilateur quelconque, même sous LGPLv3, devrait se préoccuper si des bouts de sa "lib standard" ne se retrouveraient pas dans le code généré, ce qui ferait que tous les programmes compilés avec seraient forcément sous (L)GPLv3.
C'était pour préciser un peu que les problèmes de licences ne sont pas si simples que ça... et ça me fait peur que nicO (qui fait apparemment plus ou moins partie des "devs" de Lisaac ?) en ait rien à foutre...-
[^]Re: Pertinence de cette dépeche ?
Posté par Sytoka Modon (page perso, ) le 30/09/2007 à 19:04. (lien). Évalué à 0.D'un autre coté, je préfère un Lisaac 100% libre que la solution batarde de scilab. Au moins avec un Lisacc et un CLAN, on peut espérer voir quelque chose dans le monde libre alors que scilab a un réel problème à résoudre qui n'a toujours pas de solution.
Si on prends un autre langage que j'aime bien, perl, j'avoue que je n'ai vu que du perl libre la ou je suis passé.
J'ai cru comprendre que Lisaac était passé du coté du CNRS ? Serais L'INRIA le problème...
Ok, je -> []-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 30/09/2007 à 19:11. (lien). Évalué à 0.Tu parles de la clause "non commerciale" de scilab ? Donc le 100% libre selon toi, c'est bien qu'on puisse commercialiser Lisaac ?
Je pose ces questions parce que je ne vois pas complètement le rapport avec avoir du "100% libre" : avec scilab, c'est du libre forcément non commercial, et avec Lisaac c'est du libre éventuellement commercialisé. Donc dans les deux cas c'est "libre" au sens où on ne pourra pas dériver du code pour faire du proprio (!= commercial, hein), ce qui est déjà pour moi une très bonne chose (mais c'est vrai que le non-commercial de scilab peut bloquer un peu sa montée en popularité).-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 30/09/2007 à 19:28. (lien). Évalué à 4.Par définition, du libre non commercial n'est _pas_ du libre.
Les clauses nc empèchent de faire des distributions type mandriva, red hat, suse. Ils empèchent de distribuer les binaires dans une révue. Il empèche de diffuser sur des sites web qui vivent de la pub. Bref, c'est quasi ingérable à redistribuer, ce qui est un des points majeurs du libre.
Alors, certe, tu peux me dire que l'on peut demander. Mais l'un des points fort du libre, c'est justement que l'on a pas besoin de demander ! J'imagine bien Mandriva gérer un contact avec les détenteurs des copyrights des 16000 logiciels de leur distrib...-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 01/10/2007 à 11:53. (lien). Évalué à 1.Oui bien sûr que ce n'est pas libre si on ne peut pas commercialiser le résultat. Je ne comprenais juste pas le "on peut espérer voir quelque chose dans le monde libre", alors qu'avec scilab c'est tout à fait possible, même si ce ne sera pas complètement libre, au sens où on ne pourra pas commercialiser des dérivés de scilab.
-
-
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 30/09/2007 à 19:33. (lien). Évalué à 2.Il n'y a pas de notion de "link" dans la GPL. Uniquement une notion de "travaux dérivés".
Il peut y avoir des travaux dérivés de la la lib standard. Mais un compilo ne génère jamais du travail dérivé. Je ne voix d'ailleurs pas de quel exception tu parles pour libstd++. Elle n'est pas simplement sous lgpl ?
La LGPL définit une sorte de périmètre/module autour de la lib. Je pense qu'il est clair que l'utilisation d'une collection dans un code, ne contamine pas le code en question puisque l'on ne touche pas à la signification de la dite collection.-
[^]Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (page perso, ) le 30/09/2007 à 21:24. (lien). Évalué à 3.> Mais un compilo ne génère jamais du travail dérivé.
Si je prends un cas d'école (pas un compilateur, mais c'est pour le principe) :
#! /bin/sh
[... pleins de choses ...]
cat $0
Est-ce que la sortie de mon script est un travail dérivé de mon script ?
> Je ne voix d'ailleurs pas de quel exception tu parles pour libstd++
Une solution aurait été de regarder la licence de ladite libstdc++ :
The libstdc++-v3 library is licensed under the terms of the GNU General
Public License, with this special exception:
As a special exception, you may use this file as part of a free software
library without restriction. Specifically, if other files instantiate
templates or use macros or inline functions from this file, or you compile
this file and link it with other files to produce an executable, this
file does not by itself cause the resulting executable to be covered by
the GNU General Public License. This exception does not however
invalidate any other reasons why the executable file might be covered by
the GNU General Public License.
Par contre, ce que je ne comprends plus (j'étais persuadé que c'était LGPL + exception), c'est comment une application propriétaire peut linker la libstdc++ (partie non-template).-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 01/10/2007 à 11:57. (lien). Évalué à 2.Contrairement à ce que dit nicO, il y a bien une notion de linkage dans la GPL : c'est d'ailleurs pour ça que le LGPL existe ... Cette licence dit juste que un programme qui se linke à la libstd++ (ou tout autre lib sous LGPL) n'est pas considéré comme du travail dérivé, et ne doit donc pas forcément respecter les obligations de la LGPL. Typiquement, quand on fait du proprio.
Merci d'avoir ressorti le texte de l'exception : c'est juste la "continuité" de l'exception pour linkage dont je parle, pour dire que comme dans le C++ on peut se retrouver avec du code LGPL dans son code quand on utilise des templates, et bien on n'est pas non plus obligé de respecter la LGPL, puisque ce n'est alors pas considéré comme un travail dérivé.-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 01/10/2007 à 12:17. (lien). Évalué à 2.Trouves dans la gpl l'endroit ou l'on parle de bibliothèque ou de notion de link, je suis curieux...
-
[^]Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (page perso, ) le 01/10/2007 à 12:36. (lien). Évalué à 4.Tu as tout à fait raison sur ce point : les seules occurences des mots « link » et « library » dans la GPL sont dans le dernier paragraphe, qui ne fait pas partie à proprement parler de la licence :
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.
La GPL se base sur la notion de « travaux dérivés », sans la définir (donc, il faut prendre les définitions dans la loi qui s'applique). Mais l'interprétation usuelle de « travaux dérivés » est que linker avec une bibliothèque (statique ou dynamique) constitue un travail dérivé. C'est en tous cas l'interprétation des auteurs de la GPL :
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
D'ailleurs, en parlant de libstdc++, il y a une question de cette FAQ dessus :
http://www.gnu.org/licenses/gpl-faq.html#LibGCCException
Does the libstdc++ exception permit dynamic linking?
Yes. The intent of the exception is to allow people to compile proprietary software using gcc.
Mais je ne comprends pas très bien pourquoi ne pas avoir utilisé la LGPL, si c'est pour avoir une GPL avec exception pour autoriser le link avec du propriétaire.-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 01/10/2007 à 13:13. (lien). Évalué à 1.Le link est un cas pratique mais il y en a d'autres. MySQL par exemple, est un serveur, et pourtant la GPL s'applique aussi sur les applications qui l'utilisent directement.
Il n'y a pas de link mais pourtant ton application a besoin de MySQL, c'est donc un travail dérivé.-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 01/10/2007 à 17:57. (lien). Évalué à 3.Tu peux donner un exemple de ce cas pour MySQL ? Ça me paraît très bizarre...
-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 01/10/2007 à 20:32. (lien). Évalué à 1.C'était le discours du stand MySQL a Solution Linux. Ils ne font qu'utiliser la GPL.
-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 01/10/2007 à 21:05. (lien). Évalué à 2.Bon alors déjà demader à MySQL AB s'ils sont d'accord avec leur interprétation de la GPL ...
Ensuite, ça veut dire quoi "utiliser directement" ? Parce qu'il existe quand même un nombre énorme de programmes qui utilisent MySQL, et je pense qu'une très grosse partie est proprio et ne s'embête pas avec ces soit-disantes restrictions de la GPL (et je ne pense pas qu'ils aient payé de licence autre non plus).
-
-
-
-
[^]Re: Pertinence de cette dépeche ?
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par benoar (Jabber id, ) le 01/10/2007 à 17:55. (lien). Évalué à 2.Je dis que la notion de link existe dans la LGPL. Point 5 de la LGPL :
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
Elle précise même le problème liées aux templates ou assimilés, qui incluent du code sous LGPL dans l'exécutable résultat :
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
D'où l'exception de la libstd++.-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 01/10/2007 à 20:38. (lien). Évalué à 2.C'est bien pour cela que je demandais pour la GPL ...
-
[^]Re: Pertinence de cette dépeche ?
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par Yusei () le 25/09/2007 à 09:42. (lien). Évalué à 7.Moi j'aimerais bien lire plus de news sur de nouveaux langages et sur des projets de recherche innovants. Sans se passer des news sur Lisaac, tant qu'à faire. Même s'il y en a, soyons fou, une par semaine.
D'ailleurs à chaque fois qu'on parle de Lisaac je vois mentionner d'autres langages innovants dont je n'ai jamais entendu parler, et des fois dans ma grande paresse je trouve la force de rechercher des infos dessus, et j'apprends des choses intéressantes.-
[^]Re: Pertinence de cette dépeche ?
Posté par Sylvain Sauvage () le 25/09/2007 à 14:42. (lien). Évalué à 2.Moi j'aimerais bien lire plus de news sur de nouveaux langages et sur des projets de recherche innova[teur]s. Sans se passer des news sur Lisaac
En clair :
— tu veux A (avec A = « des articles sur de nouveaux langages et des projets de recherche innovateurs ») ;
— sans te passer de B (avec B = « des articles sur Lisaac »).
D’où je déduis que B ne fait pas partie de A, et même qu’il est en contradiction avec A (le fait d’avoir A empêcherait d’avoir B).
Donc, Lisaac n’est ni un nouveau langage ni un projet de recherche innovateur ? Ça doit faire plaisir…
;oP-
[^]Re: Pertinence de cette dépeche ?
-
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par GTof (Jabber id, ) le 26/09/2007 à 13:03. (lien). Évalué à 2.Pourtant, il n'y a que sur Lisaac qu'on a régulièrement des dépêches DLFP
C'est peut être parce que ce sont les seuls à proposer des news sur leur langage. On va quand même pas leur reprocher ce que font les autres ...
Puis à chaque news sur Lisaac que j'ai vu il y avait du bon pour le libre surtout que là le compilateur et la lib en GPLv3, si ca a pas sa place sur DLFP, je vois pas où !
Tu veux l'avouer, tu as une dent contre eux ?
-
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par L () le 24/09/2007 à 22:04. (lien). Évalué à 10.Pour ma part, en tant que développeur d'envergure professionellement internationale au coeur même de GCoinCoin Inc. LTD International, je ne comprends rien à Lissac, ça ne m'intéresse pas un brin (pour l'instant) mais ne serait-ce que de voir qu'il existe encore des français (je pense aussi à Fabrice Bellard) qui ont les coronesses pour se lancer dans des projets aussi gargantuesque, ça me plaît bien. Non parce que dans LinuxFr, il y a Linux mais aussi Fr ...
-
[^]Re: Pertinence de cette dépeche ?
Posté par baud123 (Jabber id, page perso, ) le 24/09/2007 à 22:33. (lien). Évalué à 2.Fr comme Francophone aussi, pour LinuxFR, les initiatives extra-européennes de groupe d'utilisateurs de logiciels libres, telles que https://linuxfr.org/~khapin/25340.html sont les bienvenues aussi :D
-
[^]Re: Pertinence de cette dépeche ?
Posté par Khâpin (Jabber id, page perso, ) le 24/09/2007 à 23:17. (lien). Évalué à 4.Mouais, en l'occurrence, tous les participants à cette "rencontre extra-européenne" étaient français...
Ceci dit, je suis d'accord avec toi pour souligner que linuxFR se résume souvent à linux France (+ parfois Belgique), et le regretter.
-
-
-
-
-
[^]Re: Pertinence de cette dépeche ?
-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 24/09/2007 à 19:23. (lien). Évalué à 2.Qu'est-ce que cela peut te foutre que cela soit publié ?
Tu as un compte à régler avec des personnes du projet ou quoi ?
-
[^]Re: Pertinence de cette dépeche ?
Posté par Pierre Jarillon (page perso, ) le 24/09/2007 à 20:48. (lien). Évalué à 4.J'ai rencontré "Ontologia" en 2005 ou 2006 lors d'un salon "Solutions Linux" à Paris. Il essayait alors de convaincre les responsables de l'INRIA de libérer le logiciel mais les commerciaux voulaient le vendre.
Je suis convaincu qu'aucune technologie nouvelle ne peut plus percer si elle n'est pas libre. En effet, les frais de commercialisation sont énormes et la rentabilité n'est plus qu'une utopie. Il faut s'appeler Microsoft pour pouvoir lancer .NET en s'appuyant sur un parc de machines captives.
Lisaac est une technologie particulièrement innovante et il est très heureux de la voir maintenant sous licence GPL.-
[^]Re: Pertinence de cette dépeche ?
Posté par √λιi () le 25/09/2007 à 09:20. (lien). Évalué à 3.Je suis convaincu qu'aucune technologie nouvelle ne peut plus percer si elle n'est pas libre.
Pas tout a fait vrai : dans tous les domaines très spécifiques, c'est même l'inverse, elle n'a aucune chance de survivre si elle n'est pas proprio : le libre a besoin d'un masse critique de développeur (libres) pour survivre, et dans certains domains ils sont très rares.
Par contre dès que l'on parle de développement logiciel (les compilateurs est l'exemple type de ce qui n'a aucune chance d'avoir de succès en proprio) ou n'importe quelle technologie destinée a être déployée massivement (format de fichier genre codec image par ex) je suis d'accord, aujourd'hui le libre est indispensable.-
[^]Re: Pertinence de cette dépeche ?
Posté par Nicolas Boulay () le 25/09/2007 à 09:55. (lien). Évalué à 3.Je dirais que ton premier cas est vrai, si très peu de client veulent bien mettre beaucoup d'argent. (par exemple le développement de puce, ou des soft pour fondeur, qui doivent être une dizaine dans le monde)
-
-
[^]Re: Pertinence de cette dépeche ?
Posté par Rémi Pannequin (Jabber id, ) le 02/10/2007 à 15:07. (lien). Évalué à 1.« Je suis convaincu qu'aucune technologie nouvelle ne peut plus percer si elle n'est pas libre. [...] Il faut s'appeler Microsoft pour pouvoir lancer .NET en s'appuyant sur un parc de machines captives.»
Et tant bien même... cf faible succès de Vista !--
Qui invente, qui réinvente, quelle importance ? (Yakari, tome 16)-
[^]Re: Pertinence de cette dépeche ?
Posté par Matthieu Moy (page perso, ) le 04/10/2007 à 10:03. (lien). Évalué à 3.Faible succès ?
En quelques mois, Vista est devant MacOS et Linux toutes versions confondues en parts de marché.
Faut s'appeler Microsoft pour considérer ça comme un faible succès !-
[^]Re: Pertinence de cette dépeche ?
Posté par Antoine () le 04/10/2007 à 15:05. (lien). Évalué à 5.En quelques mois, Vista est devant MacOS et Linux toutes versions confondues en parts de marché.
Dans la mesure où cette progression peut s'expliquer par le chargement par défaut de Vista avec les nouveaux PCs, on ne peut pas en conclure un "succès" quelconque.
La plupart des articles traitant de Vista sur Internet (hors journalisme-croupion type 01Net et autres) sont assez négatifs, et je ne vois personne s'extasier sur les nouveautés offertes par Vista (alors qu'avec XP ou 95, par exemple, il y avait de vraies avancées).
Du point de vue technique comme de celui de la satisfaction de l'utilisateur, Vista est un échec.
Croire que le succès se mesure au taux de pénétration, la réussite à l'argent, voilà la bêtise moderne.-
[^]Re: Pertinence de cette dépeche ?
Posté par darkleon (page perso, ) le 05/10/2007 à 17:03. (lien). Évalué à 2.Du point de vue technique comme de celui de la satisfaction de l'utilisateur, Vista est un échec.
Croire que le succès se mesure au taux de pénétration, la réussite à l'argent, voilà la bêtise moderne.
Peut-être, mais l'argent intéresse plus Microsoft que la qualité technique globale :-)
Et c'est le seul truc qui intéresse une entreprise (personne morale avec un profil de psychopate faut il le rappeler), la qualité, la satisfaction utilisateur ne sont là que pour maximiser le profit.
Et comment vendre de la maintenance si les applis et les OS étaient blindés et sans bugs ?
C'est un équilibre entre "ne pas dégouter les clients" et les rendre captifs
Le but ultime de notre société moderne étant de vendre une fortune un "truc" qui ne coute rien, voir pas de "truc" du tout :-)-
[^]Re: Pertinence de cette dépeche ?
Posté par Antoine () le 06/10/2007 à 15:00. (lien). Évalué à 3.Peut-être, mais l'argent intéresse plus Microsoft que la qualité technique globale :-)
Certes... mais à moyen terme je pense que la médiocrité de Vista peut avoir de grosses répercussions sur l'image de Microsoft (qui n'est déjà plus, aux yeux des gens, l'extraordinaire prodige économique qu'on nous décrivait à la fin des années 90). Une fois cette image devenue aussi banale que celle de Renault ou Peugeot, les produits MS sont beaucoup plus vulnérables à la concurrence.
-
-
-
-
-
seul compilateur objet au monde à réaliser une analyse de flot ?
L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code.
Je ne sais pas quels sont les critères pour toi d'un "compilateur objet", mais pypy fait aussi ce genre d'analyse.
http://codespeak.net/pypy/
-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Sigmatador () le 25/09/2007 à 07:57. (lien). Évalué à 2.Est-ce qu'il y aurait des documents ou des papiers à propos de ces techniques d'analyse poussé du flot d'execution ? (liisac ou pypy peu importe)
-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Ontologia (page perso, ) le 25/09/2007 à 08:32. (lien). Évalué à 4.Pas à ma connaissance car ça n'a pas été publié (y compris pour Lisaac, mais ça va venir).
Google m'a trouvé un petit doc écrit par Xavier Leroy (ocaml)
ça explique en gros le principe.
http://pauillac.inria.fr/~xleroy/dea/compil/flow
L'analyse de flot en Lisaac a pour mission de déterminer le type vivant d'un objet en fonction des diverses possibilités d'exécution du code.
Cela permet d'éviter les switch sur type dans le code.
Le compilateur arrive à retomber, à 96 % sur du code monomorphique (un seul type possible), et utilise une table dichotomique pour le reste .
Tu trouveras des explications dans les slides ici : http://isaacproject.u-strasbg.fr/download/workshop.pdf
En ce qui concerne pypy, je ne sais pas, il va falloir que j'analyse la chose, mais ce doit être plus difficile de compiler un langage non typé, car le compilateur doit sérieusement mouliner pour typer son flot..-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Yusei () le 25/09/2007 à 08:41. (lien). Évalué à 3.Si jamais quelque chose de théorique (ie. compréhensible par quelqu'un qui n'a jamais codé de vrai compilateur mais qui aime bien les graphes) est publié sur le sujet par Benoit Sonntag ou quelqu'un d'autre, ça serait intéressant de faire un journal pour le signaler.
-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (page perso, ) le 25/09/2007 à 16:06. (lien). Évalué à 6.Le compilateur arrive à retomber, à 96 % sur du code monomorphique
Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé.
Je conçois que Lisaac ne soit pas destiné à faire des briques de composants logiciels comme on pourrait le faire en Java ou autre, mais quand même : chercher à résoudre statiquement les appels polymorphique revient à partir du principe que le code est pas vraiment modulaire et/ou réutilisable sous forme de composant, bref codé "ala C".
Quand on voit le résultat au niveau perf, je me demande également où est l'intérêt, c'est quand même très relatif comme gain, surtout quand tu vois les contraintes sur les ressources nécessaire à la compilation.
Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?
Quelques remarques :
"Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY "
Les GC modernes font également cela. D'ailleur les types "primitifs" (entier, etc.) sont généralement alloués sur la pile et non le tas, et ne sont donc pas du tout manipulés par le GC.
Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style :
"La spécification 0.2 apporte des innovations importantes"
Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.".
"certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien)
"Non content"[...]
Et j'en passe.
Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack () le 25/09/2007 à 16:36. (lien). Évalué à 4."Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé."
Je dirais que ca depend du contexte. Dans le cadre d'une appli fortement orientée plugin, pour l'instant on ne peut rien dire, la compilation séparée n'est pas encore gérée. Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections. Mais sinon, vu que tu as à ta disposition tout ce qui va être executé, et donc tous les chemins possibles, tu peux specialiser toutes les fonctions pour les types qu'elles vont pouvoir recevoir, et ainsi éviter le polymorphisme. Le chiffre de 96% sort des stats du compilo. Si je prends ce qu'il me sort pour le bootstrap du compilo lui meme, voila ce qu'il me met :
Polymorphic call : 0.8% (1996/231824)
"Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?"
A priori c'est celui qui revient le plus dans les bench shootout[1], et en plus c'est celui qu'on trouve très largement sur toutes les distros Linux. À mes yeux c'est déjà pas mal comme justification, mais il y en a peut être d'autres ;)
[1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Yusei () le 25/09/2007 à 17:16. (lien). Évalué à 3.Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections.
Pire que ça, le cas embêtant c'est à chaque fois que tu veux définir une vraie méthode virtuelle, dont l'implémentation dépend des sous-classes, et que tu ne sais pas toi même quel est le type de l'objet à un moment donné. Donc, dans tous les cas où l'héritage n'est pas juste une manière de coder proprement mais un besoin.
Tu auras un problème avec les collections, mais tu auras aussi un problème dès que l'utilisateur peut entrer des données qui déterminent le type de tes objets. C'est déjà assez problématique.
Le chiffre de 96% sort des stats du compilo.
Là dessus, il marque un point: ça peut vouloir dire que le compilo est efficace, mais aussi qu'il est codé sans utiliser vraiment de concepts d'objets. S'il n'y a pas beaucoup d'héritage, forcément, ça marche mieux. Et un compilateur, c'est assez bas niveau en terme de modélisation.
De toutes façons, difficile de débattre de points aussi techniques sans étudier le langage et les algos du compilateur, mais il est évident que l'analyse de flot atteint vite ses limites de par sa complexité. Il serait intéressant de voir des benchs portant sur ce point plutôt que sur la rapidité.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack () le 25/09/2007 à 17:39. (lien). Évalué à 3.Pire que ça, le cas embêtant c'est à chaque fois que tu veux définir une vraie méthode virtuelle
Lisaac simule des schemas d'executions et trace tous les types possibles. Meme si les types dépendent de données, il ne sont pas créés en fonction des données (il faudrait pouvoir definir des prototypes à la volée, en runtime). Tu as juste différent types prédefinis (ceux que tu as créés pour ton programme) qui sont utilisés en fonction de celles-ci, donc tu peux tracer.
Il serait intéressant de voir des benchs portant sur ce point plutôt que sur la rapidité.
Si tu parles de l'heritage (sinon j'ai mal compris et je m'en excuse ;) ), des benchs avait été fait par Xavier Oswald pour tester ces points là. En gros il y avait un bench sur l'heritage horizontal (une classe A et 500 classes filles directes par exemple) et vertical.
Pour le vertical, il prenait un proto du bas de l'arbre et faisait 2.000.000 appels sur des methodes codées dans un des parents, quelconque (ca allait de 25 à 500 parents). Voilà les chiffres, tirés d'un log irc ^^ :
xoswald: c++ croit rapidement 1.4s , 2.1s, 2.6s etc..
xoswald: alors que lisaac reste pratiquement stationnaire
xoswald: 0.7s a 1s
xoswald: et java met deja 5.7s pour 25 parents
-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (page perso, ) le 25/09/2007 à 17:48. (lien). Évalué à 1.Lisaac simule des schemas d'executions et trace tous les types possibles.
Sauf qu'un des gros atouts de l'objet, c'est de bosser avec des contrats d'interface, sans connaître le type sous-jacent, souvent fourni par un composant tiers, soit mis à la disposition des programmeurs (framework).
Rassures moi : Lisaac envisage bien la programmation modulaire quand même ? Non parcqu'il est soit disant génial et il faut abandonner C# et Java, alors je me pose des questions de programmation de tous les jours... (je ne fais pas référence à tes propos mais à ceux de Benoît).-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack () le 25/09/2007 à 18:21. (lien). Évalué à 2.Il faut distinguer 2 types de modularité : modularité dans ton architecture logicielle et modularité binaire.
La modularité de l'architecture logicielle est bien sûre possible. Un exemple typique, ce sont les collections dans Lisaac. Un type abstrait COLLECTION[E], et ensuite tu ne passes que par là. Donc si ton framework est constituée d'un ensemble de prototypes dont tu as le code source, tu peux utiliser ton framework de maniere normale, avec ses interfaces. Le compilo fera le boulot d'aller voir ce qu'il y a derriere, via son analyse de flot. Coté concepteur (vu que c'est ce coté là qui t'interesse visiblement), tu ne verras rien, tu coderas en boite noire comme d'habitude.
La modularité binaire (ou compilation séparée) dans un contexte d'optimisation globale est bien plus dure que dans un contexte d'optimisation locale (comme en Java ou autres), mais là aussi il y a 2 niveaux : la modularité type plugin, et la modularité type bibliothèque partagée.
La modularité type plugin parait plus simple. Avec Benoit on avait quelques idées qui, à la fin, permettraient de garder une optimisation globale même pour les plugins.
La modularité type bibliothèque partagée est bien plus complexe, car la bibliothèque est compilée sans connaitre les contextes d'utilisation de ses fonctions, donc out l'optimisation globale.
Ce sont clairement des domaines de recherche actuelle.
Il faut bien voir que Lisaac a été construit avec en tête l'idée de ne jamais prendre la solution de facilité. Pour la compilation séparée, il y a une solution simple si on ne prend pas cet engagement : on pond une interface en C, sans aucune optimisation sur les contextes etc, et l'autre prog se lie dessus. Probleme : on perd enormement des benefices de l'optimisation globale, alors que c'est ca qui permet d'avoir des perfs proches du C, voir meilleures dans certains cas. Rien ne dis qu'au final c'est ce qui sera fait, mais ca sera pas avant une longue analyse de ce qui est faisable.
Comme tous les projets de recherche, Lisaac cherche avant tout à être au top. Ca amène quelques contraintes, mais au final c'est parce que des gens prennent le temps de tout examiner que la JRE va un peu plus vite qu'un escargot et que Lisaac arrive à avoir une approche très haut niveau et de très bonnes perfs :-)-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet () le 25/09/2007 à 20:33. (lien). Évalué à 2.Bibliotheque partagée, ca je vois bien, mais qu'appelez-vous "plugin" ?
Sinon, ne le prennez pas mal, mais j'ai l'impression que vous vous focalisez un peu trop sur les performances par rapport au C. Ce n'est pas un mal en soit, mais il y a d'autres aspects a prendre en compte, comme la maintenance ou la facilité d'apprentissage.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack () le 25/09/2007 à 20:50. (lien). Évalué à 1.Ce que j'appelle un plugin, c'est une bibliothèque respectant une certaine API afin d'etre utilisée par un programme donné (on code la bib specifiquement pour ce programme là) qui la chargera et l'utilisera. par exemple, on peut citer les modules apaches qui sont des plugins pour apache, les drivers linux le sont aussi d'une certaine manière pour le noyau. pour résumer, un plugin est fait specifiquement pour un programme, contrairement à la bibliothèque partagée. Certes les 2 donnent la meme chose en terme de structure (un .so classique sur les unix), mais en terme de compilation globale c'est très différent, car dans le cas de plugins on connait le programme qui utilisera le plugin, et donc on peut avoir les contextes. est-ce moins obscur ?
Qu'appelez vous maintenabilité ? extensibilité du code ? facilité de compréhension pour le maintenir et corriger les bugs ? gestion d'un projet ? outils de debugging ?
si c'est l'aspect maintenance du code, etant un langage de haut niveau gerant tout seul la mémoire, il aura une maintenabilité plus aisée qu'un langage de bas niveau.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet () le 26/09/2007 à 11:58. (lien). Évalué à 3.Ok, merci pour les plugins.
Pour la maintenance, je pensais, par exemple, au fait que dans un projet, les equipes se renouvellent au cours du temps. Un nouvel arrivant doit etre operationnel rapidement pour analyser le programme, le corriger et le faire evoluer. Sans vouloir lancer un troll, le langage Perl n'est pas réputé pour etre facilement maintenable, ceci etant certainement du a sa syntaxe tres consise et le fait qu'"il y a plusieurs facons de le faire".
Un autre aspect est le fait d'apprendre un nouveau langage. Une des raisons pour laquelle Java a aussi bien reussi, c'est que la syntaxe de base est tres proche du C. Un programmeur C qui n'a jamais fait du Java de sa vie comprend rapidement un programme Java ; pas tout le programme bien sur, mais souvent suffisamment pour pouvoir analyser l'algorithme et effectuer une correction. Il y a evidemment d'autres facteurs (Sun poussait et pousse toujours le langage, la richesse de l'environnement) mais cet aspect la est tres important.
Le langage D est vraiment tres bien sur le papier, mieux que C, C++, Java ou C# par exemple ; je precise que je ne lance pas de trolls. Pourquoi ne perce-t-il pas alors ? Peut etre parce qu'il soit sous copyright Digital Mars. Cet aspect "langage non-libre" a été soulevé par un autre intervenant.
Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour (independance par rapport a la plateforme materielle). Je crois que dans Lisaac, il n'y a pas de notion de ByteCode.
Bref, ce que je voulais dire c'est que la reussite ou non de votre projet depend d'un nombre important de facteurs et que la performance par rapport au C n'est pas forcement le plus important. Java s'est trainé une reputation d'escargot pendant des années. Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.
Vous avez fait un super boulot et semblez tres enthousiastes, mais c'est tres facile de garder la tete dans le guidon. Je voulais juste vous faire part de remarques exterieures qui, je l'espere, sont constructives.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay () le 26/09/2007 à 12:05. (lien). Évalué à 4.Puisque vous dites que vous ciblez l'embarqué, certains equipements necessitent une mise-a-jour logicielle. Il y a clairement un avantage a utiliser un langage produisant du ByteCode pour effectuer ces mises-a-jour
euh... HEIN. Il est fou. On se fait chier à produire du code rapide pour avoir la plateforme moins chère possible et il veut mettre une VM ?!
Du bytecode pour l'embarqué, c'est la meilleur de l'année. Surtout pour des mises à jour, c'est encore pire. (ps:je ne vois pas bien le rapport)
Ca s'est bien amélioré mais ca ne l'a pas empéché d'avoir percé.
Java misait sur une autre approche que Lisaac : sa lib pour gagner du temps.
Lisaac vise autre chose. Plus tangible en plus.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet () le 26/09/2007 à 12:26. (lien). Évalué à 4.Le monde de l'embarqué ce ne sont pas que des microcontrolleurs 8 bits.
Un exemple : en TV num, depuis quelques années, il y a de plus en plus de JVM. En gros, l'OS, les drivers et la JVM sont en C et l'application est en Java. Tout ce petit monde peut etre mis-a-jour via la diffusion satellite.
C'est beaucoup plus simple de mettre a jour l'application par ByteCode car la plateforme materielle est abstraite.
La specification J2ME de Java est destinée au monde de l'embarqué. D'autres existent comme STIP.
Il y a meme des specifications Temps-Reel pour Java ; la plus connue (car officielle) est RTSJ (Real-Time Specification Java).
Je rappelle qu'a l'origine Java a été concu pour l'embarqué uniquement, et que la mise-a-jour par ByteCode était un élément important. Le ByteCode a aussi été concu pour etre plus compact qu'un programme deja compilé.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay () le 26/09/2007 à 12:29. (lien). Évalué à 1.Le marché que tu décris ne représente rien en volume par rapport au reste.
Il y a beaucoup de blabla autour de java pour l'embarqué mais très peu d'application réelle. Rien que la RAM nécessaire en plus est un frein.
Sinon, je ne voix pas pourquoi le ByteCode serait plus compact, et de plus, jene voix pas l'interet surtout quand tu as une énorme JVM derrière.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet () le 26/09/2007 à 13:48. (lien). Évalué à 2.Le marché que je décris c'est telephonie mobile (ok il n'y a pas de JVM dans tous les telephones portables) + TV num. Ce ne sont pas des petits marchés. A l'heure actuelle, ce sont deja des millions de machines. Je ne parle pas non plus des autres marchés.
Tous les equipements embarqués n'ont pas les memes contraintes, mais pour certains d'entre eux, le fait de pouvoir mettre a jour l'application sans se preoccuper de la plateforme materielle est clairement un avantage. Ceci est, a mon avis, quelque choses qui va continuer a se developper.
La JVM JamVM (J2SE) annonce un executable (compresse) de 140KB. La JVM MicroJVM (J2ME) annonce une empreinte memoire inferieure a 30 KB.
Le ByteCode est plus compact pour deux raisons:
- la premiere vient de sa conception : en ByteCode Java, si tu mets '0' sur la pile, c'est un seul octet ; sur une machine 32 bits, rien que le nombre tient sur 4 octets ; tout n'est pas comme ca, mais globalement, c'est plus compact
- la seconde raison est que les classes s'appuient beaucoup sur la bibliotheque et que tu peux eventuellement mettre a jour une seule classe ; c'est moins evident si tu veux faire ca avec un programme compilé, surtout sans bibliotheque partagée
Un des interets que le ByteCode soit compact est le temps de telechargement de la mise-a-jour. Le programme tient aussi moins de place en memoire.
Ceci dit, je ne vient pas ici pour dire que Java c'est genial pour l'embarque grace a son ByteCode, surtout que je suis plutot C. Je dis juste que c'est dans certains cas, cela a des avantages. Ceci est valable pour tous les langages generant du ByteCode.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay () le 26/09/2007 à 14:42. (lien). Évalué à 1.Je ne connais plus les chiffres de vente des µp 16 bits et des petits 32 bits arm. Je crois que l'on est pas loin du milliards. C'est sans commune mesure avec un téléphone ou autre.
Tu annonce 30 et 170KB, cela ne fait pas beaucoup sauf que les µP 16 bits on difficilement plus de 64KB de mémoire.
pour le bytcode, certe pour mettre sur la pile, tu utilies un mot d'un octet, et minimum 2 octets pour du x86, mais si tu fais une addition entre 2 nombres ailleurs dans la pile, sur x86, cela prendra toujours 2 octets mais combien en byte code java pour manipuler la pile et mettre les valeurs au bon endroit ?
Concernant la mise à jour de code, tu peux tout à fait patcher du binaire. Il n'y a pas vraiment de différence. La difficulté sera toujours la même : comment gérer les données des classes modifiés.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet () le 26/09/2007 à 15:05. (lien). Évalué à 2.Bon, je crois qu'on a dérivé.
Le monde de l'embarqué est tres vaste, et l'echelle est plus importante que le monde du desktop.
J'essayais juste de faire une critique que je pensais constructive, a savoir qu'il y a une part non-negligeable de l'embarqué ou l'utilisation de ByteCode avait un avantage. Je n'ai pas dis qu'il faut abandonner l'assembleur et le C, juste que le ByteCode est utilisé et que le marché potentiel est tres important, surtout en valeur. Je demandais juste si le fait de pouvoir generer du ByteCode etait une fonctionnalité prévue, car cela a certains avantages, comme le fait d'utiliser des bibliotheques partagées ; je n'ai pas dit non plus que c'etait absolument indispensable.
Pour la manipulation des données et d'apres ce que j'ai vu, tout est serialisé sur disque ou en memoire flash, et on recharge la JVM en relisant ces données. Ce n'est certes pas tres eleguant mais ca a le merite d'etre simple ; en plus si la mise-a-jour a lieu durant la nuit ce n'est generalement pas tres genant pour l'utilisateur. C'est juste une histoire de compromis entre diverses choses, en premier le cout, et en dernier l'elegance technique. Triste réalité n'est-ce-pas ?-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Mildred (Jabber id, page perso, ) le 27/09/2007 à 11:05. (lien). Évalué à 1.Il serait possible éventuellement de faire d'autres backend pour Lisaac, c'est à dire qu'on pourrait cmpiler en C, mais on peut aussi très bien imaginer de compiler pour la JVM ou encore Parrot...
Seulement à l'heure actuelle, les structures C sont un peu partout dans le code du compilateur. Si on veut ajouter un langage ca risque d'être difficile.
-
-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par crumpet () le 27/09/2007 à 16:15. (lien). Évalué à 1.Au fait, j'ai fait un petit essai avec une petite fonction qui prend deux entiers et retourne leur somme:
en C:
int function (int a, int b)
{
return a + b;
}
en Java:
public static int function (int a, int b)
{
return a + b;
}
sur x86, je compile avec optimisations (-O3 -fomit-frame-pointer) et j'obtiens:
0: 8b 44 24 08 mov 0x8(%esp),%eax
4: 03 44 24 04 add 0x4(%esp),%eax
8: c3 ret
soit 9 octets (11 octets avec -O2)
Le ByteCode Java est:
0: iload_0
1: iload_1
2: iadd
3: ireturn
soit 4 octets (on mets les deux parametres sur la pile, on les additionne et on retourne le sommet de la pile).
Ici, il y a un rapport environ de 2 en faveur du ByteCode. Bon ce n'est qu'un exemple, et je ne dis pas que c'est toujours comme ca hein.
J'ai essayé avec la fonction factorielle codée recursivement et j'obtiens un rapport presque de 14 avec -O3 (gloups), plus que 3 avec -O0 et presque 2 avec -O2. Je n'ai pas cherché a faire un truc super-optimisé, mais juste un petit programe classique.
Une fois translaté en langage machine, il n'est pas deraisonnable de penser que le ByteCode occupera au moins la taille occupée par un code equivalent écrit en C, donc le fait que ca soit plus compact n'a pas forcement toujours un interet.-
[^]Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par Nicolas Boulay () le 27/09/2007 à 16:35. (lien). Évalué à 2.essayes -Os pour gcc. Il faudrait voir sur des fonctions plus réaliste, ici, c'est trop court.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.