Au programme, un serveur totalement écrit en Lua, extensible par un mécanisme de greffons, qui gère le format maildir++, les utilisateurs virtuels par SQL, une authentification SMTP simple, un fichier de configuration lisible...
Précision importante, Tethys est bien sûr Open Source en licence GPL3. Le premier exemple d'utilisation grand public de Tethys, le site d'emails temporaires MailCatch.com. Tethys est un serveur SMTP tout jeune, environ un an depuis sa conception et quelques semaines depuis sa première release. Son histoire est simple : l'auteur voulait un serveur mail qui lui permette de gérer facilement des utilisateurs virtuels (non-Unix) dans une base SQL et ne pas avoir à s'embêter avec un système de configuration peu attrayant. Ayant essayé plusieurs systèmes, il fut déçu et étant un fervent adepte de Lua il décida d'écrire le sien dans ce langage. Un an après, voici les premiers résultats.
Pour le moment Tethys tourne donc depuis un an, maintenant sans soucis, en tant que serveur mail principal de l'auteur. Il est aussi à la base du service anti-spam MailCatch.com qui fournit un service de mails temporaires et qui est en quelque sorte la « preuve » de la viabilité du serveur. Étant tout jeune, il a besoin de notoriété pour avancer (notamment des testeurs divers et variés) et d'une floppée de greffons pour faire "mieux que les grands".
Aller plus loin
- Tethys SMTP Serveur (91 clics)
- MailCatch (EN) (8 clics)
- MailCatch (FR) (54 clics)
- Lua (6 clics)
# Lua rocks !
Posté par téthis . Évalué à 7.
Et étant donné mon pseudo... :D
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
# Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
# Performance
Posté par Amaury . Évalué à 5.
C'est un point important histoire de ne pas se retrouver à la ramasse si le traffic smtp augmente.
[^] # Re: Performance
Posté par DarkGod . Évalué à 2.
Sinon pour la question du traffic je dois bien avouer que je n'en sais rien, je n'ai pas pu faire de test ultra poussés pour le moment. C'est d'ailleur une des raison pour lequeles j'ai créé mailcatch, comme ca je vais avoir du traffic et voir comment ca tient :)
Si des gens veulent m'aider en fesant des tests de cahrge, je suis preneur aussi!
[^] # Re: Performance
Posté par Amaury . Évalué à 4.
[^] # Re: Performance
Posté par DarkGod . Évalué à 2.
# A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à -4.
(1) Point positif : l'obligation de devoir contribuer en retour, par ex, si modification, attire des contributions et "soude" encore plus, d'une certaine manière, la communauté => force d'attraction
(2) Point négatif : le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion.
Sous un autre angle, je pense que la GPL est attractive pour les passionnés (Linux à ces débuts), genre, presque "groupe commando", ou pour les plans business genre "licence duale" (Asterisk, MySQL...). Mais si la poussée "passion" ou "business" n'est pas assez forte pour atteindre la v1.0 et une certaine taille de communauté/visibilité, je pense qu'il faut préférer plutôt la dissémination, avec une licence genre BSD.
A titre personnel, je n'aime généralement pas la licence GPL, encore moins les licences duales GPL, je préfère la licence LGPL, voire éventuellement jouer encore plus la carte de la dissémination à la BSD. En tout cas, perso, pour un projet comme celui-ci avec un langage exotique comme Lua, j'aurais préféfé une licence BSD...
Quels sont vos avis entre (1) et (2) ?
Merci
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 4.
J'argumente (point positif, point négatif).
Je donne mon avis, mais j'insiste en disant bien qu'il n'est que perso.
Comme je n'ai pas d'avis bien tranché sur le sujet, que je suis curieux, et que je ne vois pas la réalité en noir et blanc, je serais ravi, vraiment, d'avoir l'avis d'autres personnes.
Ou tu vois un troll ?
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
C'est absurde.
Un codeur ne cherche pas des codeurs à tout prix. Si des codeurs arrivent et ne veulent pas de la GPL, c'est qu'ils ne veulent pas partager de code. Donc, il n'y a aucun intérêt de travailler avec eux.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 0.
En résumé, cela donne bien : "le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion."
[^] # Re: A propos de la licence GPL
Posté par FabienC . Évalué à 2.
qu'est ce qui te force à contribuer sur les parties de code que tu ne veux pas avec la GPL ?
[^] # Re: A propos de la licence GPL
Posté par Raphaël SurcouF (site web personnel) . Évalué à 9.
[^] # Re: A propos de la licence GPL
Posté par Raphaël SurcouF (site web personnel) . Évalué à 5.
En quoi impose-t-elle de contribuer au projet original ? L'auteur original sera libre de reprendre ou non tes modifications si elles ont été publiées.
Ce qui limite l'entrée des logiciels placés sous GPL, c'est plutôt la mauvaise image de licence « virale » voire « communiste » qui fait peur sans raisons.
Si la véritable raison est plutôt « on n'a pas envie de fournir les sources des logiciels qu'on distribue mais on a envie de tirer partie des logiciels libres pour faciliter notre développement », dans ce cas, ce serait déjà plus honnête que d'attaquer frontalement la GPL. Les développeurs qui choississent la GPL en connaissance de cause le font justement pour éviter cela. Certains, comme ceux du projet Wine, l'ont fait après avoir vu ce que ça donnait.
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 2.
Ceci étant, conformément à mon post initial, je ne cherche nullement à attaquer la GPL !
Je suis PRO-logiciel libre, je m'interrogeais "à voix haute" sur la meilleure manière "d'assurer la diffusion" d'un logiciel libre. En *caricaturant* : choc frontal (GPL) ou diffusion rampante (BSD) ? Les deux, je crois.
Merci pour l'exemple Wine.
[^] # Re: A propos de la licence GPL
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Quand je vois des groupes qui se restreignent à l'emploi de certains équipement ou logiciels uniquement pour des raisons d'actionnariats ou de partenariats, c'est du même acabit : l'aspect technique passe en second plan.
[^] # Re: A propos de la licence GPL
Posté par Putifuto . Évalué à 3.
Le fameux syndrome du "tout pour ma gueule" ou encore "vas-y file moi ton code, c'est pour faire du pognon sur ton dos".
Heureusement qu'il y a des gens qui ont une vision plus large que cette simpliste version d'égoïsme.
La GPL existe uniquement pour montrer aux gens qui cherchent juste du code source à intégrer qu'on attend un retour. Pas financier comme dans le monde proprio mais un partage de connaissances. Et tant pis si ça défrise tes capitalistes fainéants de patrons.
Si le monde était parfait, tout le monde coderait en BSD et distribueraient les modifications, et un communisme humaniste régnerait sur la terre pour le bonheur de tous. Mais le monde n'est pas parfait. Il y a donc la GPL.
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
=> oui, mais note que ce retour des choses, ce juste retour des choses, il est aussi possible de l'obtenir avec la LGPL...
Je ne cherche pas ici à aller contre la GPL, car c'est une licence tout à fait honorable, qui a son utilité.
Cette histoire est compliquée :
- les développeurs ont peur que l'on utilise leur soft sur leur dos, i.e. sans un juste retour des choses,
- les "patrons" ont peur, pour des raisons de licence, de devoir livrer en open source le code qui les fait vivre.
Bref, il y a de la peur des 2 cotés.
Ce que je pense, c'est que la GPL, dans c-e-r-t-a-i-n-s cas, c'est un peu agiter le chiffon rouge qui va conforter les uns, énerver les autres et tout le monde va, en fait, au final, y perdre. Alors qu'il existe d'autres licences, tout aussi honorables, qui vont permettre à tout le monde d'y gagner plus, en mode gagnant-gagnant.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Si tu regardes les faits. La GPL a construit des écosystèmes complet avec Linux et ses distributions. Les BSD-like ont beaucoup moins de succès : ils ont surtout des projets qui ont marché mais sans que l'écosystème suive derrière.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
Je pourrais aussi citer, dans une moindre mesure, la LGPL avec JBoss et JOnAS.
A ce que je sache la EPL et la LGPL impliquent aussi un juste retour des choses du moment que l'on modifie le code correspondant. Et effrayent moins les industriels qui, du coup, participent à l'écosystème. Et des contribs du monde industriel à Eclipse, il y en a eu bcq !
Je ne vois pas le monde en binaire, GPL versus BSD.
Encore une fois, il y a pleins d'autres licences.
Je ne crois pas que le succès d'Eclipse (de par son archi à plugin) aurait eu le même succès avec la GPL.
D'où mon discours depuis le début : à chaque fois, il faut voir quelle est la licence qui convient le mieux.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je pourrais aussi citer, dans une moindre mesure, la LGPL avec JBoss et JOnAS.
Tu me site 3 projets qui ont réussi mais qui sont loin d'être au niveau de réussite de la GPL. 15 millions de ligne de code, cela n'est même pas Linux entier. Alors si tu compares à une distribution...
Je ne vois pas le monde en binaire, GPL versus BSD. Encore une fois, il y a pleins d'autres licences.
Sauf que si ce sont des licences libres, et qu'elle revienne soit à une BSD soit à la GPL (la licence SUN par exemple)
Je ne crois pas que le succès d'Eclipse (de par son archi à plugin) aurait eu le même succès avec la GPL.
D'où mon discours depuis le début : à chaque fois, il faut voir quelle est la licence qui convient le mieux.
Disons que Eclipse comblait un manque. Souvent les plugin ne sont pas libre non plus, donc je ne prends pas ça pour un succès du libre.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par Thibault (site web personnel) . Évalué à 2.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Mais cela m'étonnerait beaucoup que Eclipse est 15 millions de ligne de code.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 2.
Vu l'évolution d'Eclipse, les donations importantes de code réalisées depuis, je ne dois pas être loin du compte en estimant le nombre de lignes de code à 15 millions, vu le spectre couvert par tous les projets : http://www.eclipse.org/projects/listofprojects.php
Pour donner un ordre d'idée, la livraison de code initial d'IBM pour le projet WTP (bien avant la 1.0, alors que l'on doit être pas loin de la 3.0 maintenant) faisait environ 80 Mo (doc inclus). La compilation du code source livré prenait, from scratch, plus de 2 heures sur une bonne machine de build.
Après recherche, j'ai sous-estimé le nombre de lignes de code.
D'après http://www.eclipse.org/org/press-release/20070627_europarelease.php : la release Europa qui inclut 21 des projets Eclipse pesait 17 millions de lignes de code en juin 2007 ; sachant que cette release n'inclut pas tous les projets Eclipse.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais si on prends KDE, il prends aussi des heures à calculer.
Disons aussi que la taille du code n'est pas représentatif du dynamisme d'un projet. Les derniers chiffres pour linux, c'est 1000 contributeurs, 100 sociétés, 3600 lignes de codes ajoutés par jour.
Je veux bien que Eclipse soit un succès mais bon...
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 2.
Et je trouve que cela n'est pas très fair play de ta part que de prendre un des sujets secondaires que j'ai cité ici à titre indicatif (pour rappel, le sujet principal étant le nombre de lignes de code) pour le mettre au premier plan et me "tirer dessus".
Disons aussi que la taille du code n'est pas représentatif du dynamisme d'un projet. Les derniers chiffres pour linux, c'est 1000 contributeurs, 100 sociétés, 3600 lignes de codes ajoutés par jour.
Juste pour info, on peut trouver les chiffres pour Eclipse (ou plutôt qques chiffres pour Eclipse) dans la présentation EclipseCon suivante : http://www.eclipsecon.org/2008/index.php?page=sub/&id=19(...) - notamment dans le slide 46.
Je veux bien que Eclipse soit un succès mais bon...
;-)
Mouais, j'ai plutôt l'impression que tu commences à troller à ce propos. OK, hier, pour la comparaison de chiffres, maintenant tu me sors cette histoire du nombre de contributeurs et de société, et demain je-ne-sais-quoi. OK, c'est très bien, mais on s'éloigne (pour rien) du sujet initial qui était, quand même, il faut le rappeler, que la GPL est une très bonne licence, très utile, je n'en doute pas, mais qu'elle n'est pas la seule et que d'autres écosystèmes se sont batis et fonctionnent bien autour d'autres licences. Une des preuves : Eclipse.
Sur ce, tchao !
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est toi qui a parlé des lignes de code comme mesures du succès. Linux est en effet 2 à 3 fois plus petit que Eclipse. Mais mon exemple concernait Linux dans son environnement : une distribution Linux.
Ensuite, j'ai rajouté que le nombre de ligne de code n'est pas forcément un bon repère surtout pour un OS où l'on recherche la légerté et un IDE dont le code non utilisé n'a pas d'impact.
D'aprés ta slide 46, Eclispe, c'est une trentaine de boite et 11 millions de lignes de code. Si tu compares cela à tout ce qui veut s'appeler "Gnu", il y a de la marge.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ohnoes . Évalué à 6.
C'est du java, l'une des plus grandes horreurs verbeuses de notre siècle. Le cobol d'aujourd'hui. C'est facile en Java d'écrire des milliers de lignes de code qui en feraient un quart dans un langage un peu plus décent. ilsPoussentMêmeLeViceJusqu'auxNomsDesMéthodes().
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'était un fud trés efficace de certain commerciaux qui expliquait que si on laissait rentrer du code GPL tout le code de la boite devait devenir GPL. C'est parfaitement absurde, mais c'est le propre du FUD.
Comment veux tu que des partisans dela GPL réagissent à tes propos qui ne sont que dû qu'à la méconnaissance du sujet ? Ce n'est pas parce que ta boite est frileuse/réactionnaire/mal informé que cela doit rentrer en ligne de compte pour un projet.
"avoir envie de contribuer (seulement) les parties de code que l'on veut."
J'espère que tu puisse comprendre que c'est parfaitement inacceptable pour nombre de codeurs du libre. Vous utilisez un code que vous n'avez pas codé et vous refuser le seul retour exigé : les améliorations (et encore, cela n'est à fournir qu'à vos clients).
En résumé, cela donne bien : "le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion."
Je crois que pas mal de codeurs te répondront "rien à foutre". Ils ont rien à gagner et tout à perdre avec des gens comme ta boite... Réutiliser du code libre, ce n'est pas faire l'aumône à son développeur...
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 0.
Que pas mal de codeurs du libre préfèrent la GPL, c'est très bien. JE NE JUGE PAS. Je les comprends.
Mon post initial était : en tant que développeur PRO-logiciel libre, je m'interrogeais "à voix haute" sur la meilleure manière "d'assurer la diffusion" d'un logiciel libre. En *caricaturant* : choc frontal/pilonnage (GPL) ou diffusion rampante/encerclement (BSD) ? Genre, Linux et Apache+Eclipse. Les deux, je crois, et c'est très bien.
Comme le choix d'une licence, c'est "presque" comme un gout perso, je m'arrêterais là dans mon "petit sondage" relatif au succès-du-logiciel-libre-par-rapport-aux-licences.
Merci.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est vrai que cela change de lire "vous avez le droit de faire ceux-ci ou cela" alors qu'avec une licence proprio, tout est interdit de base.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par BAud (site web personnel) . Évalué à 4.
àmha, il faudrait aussi faire gérer aux acheteurs et au juridique tout ce qui est licence libre : cela permettrait de recenser ce qui est effectivement utilisé (c'est parfois fait tant bien que mal avec tout ce qui est proprio, pourquoi ne pas le faire avec ce qui est libre aussi...), cela ferait sans nul doute grandement apprécier la simplicité des licences du libre en terme d'utilisation et de gestion, par rapport à l'imbroglio sans nom côté proprio.
[^] # Re: A propos de la licence GPL
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
L'intérêt est de pouvoir utiliser tous les modules du langage sans se poser la moindre question.
Je ne sais pas sous quelle licence est le CPAN de LUA.
[^] # Même licence que le langage
Posté par Kerro . Évalué à 2.
Je ne comprends pas pourquoi tu préfères utiliser la même licence que le langage. Quel est ton raisonnement ou ton ressenti ?
Si un projet est codé en Perl ET en C. Je prends quoi comme licence ?
Celle de Perl, celle de GCC ?
[^] # Re: Même licence que le langage
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
gcc utilise la lgpl pour la libc qui se lie donc avec n'importe quoi.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par - - . Évalué à -6.
on en à rien à fiche d'un énième débat sur la GPL.
lisez les archives et cessez de polluer.
-
à titre personnel votre avis personnel est une nuisance
-
la GPL a maintes fois prouvés sa viabiltié commerciale, que cela soit pour IBM , SUN, NOKIA, APPLE ou MYSQL AB
un point c'est tout !
et mon avis, personnel, subjectif etc: c'est que je me contrefice des projets sous licences bsd tel freebsd, openbsd. le seul projet BSD professionnel et utile industriellement est openssh.
pour le reste, lachez nous, et retournez vous passionner sur les licences MIT, X11, APL, APL2, GPL3, BSD, EULA propriétaires, CPL, MSPL, etc.
MERCI !
(non, pas du tout énervé, juste fa-ti-gué et las-sé de ce genre de contributeurs)
[^] # Re: A propos de la licence GPL
Posté par TeXitoi (site web personnel) . Évalué à 4.
[^] # Re: A propos de la licence GPL
Posté par kemar . Évalué à 3.
Et quand on est fatigué... on zappe et on passe au troll suivant ;)
[^] # Re: A propos de la licence GPL
Posté par Gof (site web personnel) . Évalué à 6.
La GPL n'oblige pas strictement de contribuer en retour. Des utilisateurs peuvent très bien ne pas publier les modifs qu'ils ont fait sur leur serveur qu'ils ont en production et qui serait super plus efficasse que le serveur officiel.
> Point négatif : le risque d'être impacté par la licence GPL éloigne certains
> utilisateurs et possibles contributeurs
La BSD attirerait peut être plus les développeurs qui voudrais forker le serveur pour en faire un truc proprio amélioré et le distribuer(vendre?). Mais est-ce ce que les développeurs originaux veulent ?
[^] # Re: A propos de la licence GPL
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
Néanmoins sur un plan business, on peut compter sur l'intégration du projet dans un packaging plus vaste/intéressant/facile/etc... c'est à la mode ce genre de business pour proposer aux PME de se passer du cauchemar Exchange !
D'où un choix GPL ma foi intéressant pour à peu près tous AMHA (le LGPL serait peut-être plus judicieux pour répondre à tous tes arguments).
mes 2 cents...
[^] # Re: A propos de la licence GPL
Posté par Julien . Évalué à 1.
A priori, c'est le cas en GPLv2 et c'est une des grosses différences de la GPLv3.
[^] # Re: A propos de la licence GPL
Posté par Philippe F (site web personnel) . Évalué à 8.
Je partage l'avis de l'auteur du fil de discussion. Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
Par exemple readline ( http://tiswww.case.edu/php/chet/readline/rltop.html ). On ne peut pas utiliser la bibliothèque fournissant readline si ne fait pas un programme sous GPL. C'est un choix de l'auteur que je peux comprendre, mais je trouve que c'est plus une perte pour le logiciel libre et les logiciels commerciaux qu'autre chose. Je m'explique :
- readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser. Si un projet non GPL envisage d'utiliser readline, je doute qu'il décide de devenir GPL juste pour ça, readline n'est pas en soi un élément de motivation suffisant. On peut imaginer que pour des lib plus importantes, genre Qt, l'auteur se pose la question du changement de licence mais pour readline, faut arrêter de rigoler.
- du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas. Je pense que readline si situe juste à la limite du truc un peu chiant à développer, dont on peut se passer mais qui est très bien à avoir. Si c'est pas facile à utiliser, il y a peu de chances que un auteur se donne la peine de redévelopper readline dans une autre licence. Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas.
Si j'avais été l'auteur de readline, je l'aurai mis en BSD.
En tant qu'auteur de logiciel, j'aime que mes logiciels soient diffusés au maximum, et ça ne me pose pas de problème que certains d'entre eux soient utilisés par des entreprises, qui ne me reversent ni argent, ni contribution à mon logiciel, ni contribution au logiciel libre en général. Ca me suffit de savoir que mon logiciel leur a été utile.
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à -1.
Merci pour ces propos clairs et nets, et qui font écho à ce que je voulais dire.
L'exemple de "readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser [...] du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas [...] Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas."
=> c'est EXACTEMENT ça !
Je vais donner un autre exemple.
Depuis qques semaines, je cherche à créer mon propre projet open source Java sur Swing. J'ai tout d'abord recherché ce qui se faisait sur SourceForge pour éviter de réinventer la roue et éventuellement, me joindre à un projet open source existant.
Bon, je n'ai pas trouvé ce que je souhaitais, mais les projets qui m'intéressaient le plus étaient des projets GPL. Cette licence ne m'intéresse pas, mais là n'est pas le plus important. Le plus important, c'est que les 3 à 4 projets Swing intéressants trouvés sur SourceForge étaient... morts !
IMHO, ils étaient morts en partie à cause de la licence GPL. C'est une licence qui a son utilité, mais mal choisie, i.e. choisie pour un projet qui tient plus de la librairie comme "readline" que d'un projet qui fait sens comme un tout (ex, LimeWire), cette licence a, je crois, participé au fait que ces projets se sont retrouvés dans une impasse (idem "readline").
Et souvent, quand je scrute SourceForge, j'apercois plusieurs petits projets GPL morts, morts en partie à cause du mauvais choix de la licence GPL par rapport au type de projets en question. Et ces logiciels libres qui se retrouvent dans le mur, je trouve cela bien dommage.
C'est ce que je veux dire depuis mon post initial ici.
[^] # Re: A propos de la licence GPL
Posté par Philippe F (site web personnel) . Évalué à 9.
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 1.
A le choix des dvp est ridicule parce qu'ils veulent un certain truc, mais pas forcément dominer le monde...
Je note...
(Un raccourci rapide serait "ne pas vouloir dominer le monde est ridicule").
Puis pour une lib, tu peux toujours t'en sortir en linkant en dynamique et en créant une lib proprio avec la même api (que la lib proprio marche ou pas c'est pas grave).
-> on peut pas te dire que ton programme est gpl vu qu'il est fait pour tourner avec ta lib proprio (elle proprio).
Le fait de réutiliser l'API de readline n'est pas interdit par la GPL, ni l'utilisation d'un truc comme LD_PRELOAD ou autre...
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
""
Puis pour une lib, tu peux toujours t'en sortir en linkant en dynamique et en créant une lib proprio avec la même api (que la lib proprio marche ou pas c'est pas grave).
-> on peut pas te dire que ton programme est gpl vu qu'il est fait pour tourner avec ta lib proprio (elle proprio).
""
=> je ne crois pas que ce soit compatible avec la GPL (sauf erreur) et moins encore avec l'interprétation des avocats de MySQL par ex...
Mais c'est un domaine sujet à interprétation (outch). Bjorn, le directeur technique de la fondation Eclipse, exprime ses doutes, ses interrogations ici à propos de l'usage de la licence GPL pour MySQL : http://eclipse-projects.blogspot.com/2005/09/commercial-open-source.html - compliquée cette affaire, même pour un directeur technique dans le domaine de l'open source...
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 1.
On va prendre un cas simple :
J'ai fait une lib de pthreads en GPL.
Attaque donc tous les programmes proprio qui tourne sous linux en utilisant les pthreads alors ... (linkage dynamique)
Moi je pense pas que tu vas réussir à gagner, mais on sait jamais.
(Next step, je fait une librairie avec l'API de windows en GPL. J'attaque MS lui même \o/).
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Attaque donc tous les programmes proprio qui tourne sous linux en utilisant les pthreads alors ... (linkage dynamique)
On s'en fout ici que le link sois dynamique. Les pthreads implémentent la norme posix. D'ailleurs, tout le monde s'en fout on est passé à NPTL depuis quelques années.
(Next step, je fait une librairie avec l'API de windows en GPL. J'attaque MS lui même \o/).
C'est toi qui réutilise le code là, pas MS....
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 1.
Ou ais je dis le contraire ?
A nulle part ... d'ailleur je l'ai même précisé dans mon arguments explicitant ce que je disais (commentaire un peu plus bas):
je me cite :
Donc le gars qui a fait la lib proprio qui a copié l'api de la lib gpl (ou inversement!) ou tout simplement suivi une norme
Donc on est bien d'accord : copier une API (que cela vienne d'une norme ou d'un programme GPL) n'est pas suffisant pour contrevenir à la GPL.
Donc le linkage dynamique d'un soft d'une licence X avec une lib en GPL devrait être autorisé.
Non?
C'est toi qui réutilise le code là, pas MS....
JE NE REUTILISE PAS DE CODE.
Je copie une API. Toute la nuance est là.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Non?
Non. Le fait que le link est dynamique ne change rien à l'histoire.
Pour que tu puisses choisir ta licence pour une lib liée à de la GPL, il faut démontrer que le soft GPL en question est optionnel.
La technique d'écrire un soft proprio qui copie les API est possible et légal (c'est l'inverse de lesstif pour motif). Par contre, écrire un truc qui marchouille pour dans les faits utiliser uniquement la lib GPL et pouvoir dire: regardez j'ai un bout de machin pas GPL avec la même api. Cela s'appelle prendre le juge pour un con. Ils n'aiment pas en général...
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 0.
Ben je peut faire une lib proprio avec la même api (même si la lib proprio marche moyen voir pratiquement pas).
Rien n'interdis de diffuser un programme proprio qui plante, non ? (ie tu diffuse le soft avec la lib qui plantouille).
Cela s'appelle prendre le juge pour un con. Ils n'aiment pas en général...
Je ne serais pas aussi catégorique que toi
Rien n'oblige à fournir un programme qui marche à ce que je sache, si ?
Tu peux le faire pour une bonne raison : tu travaille toujours sur ta lib proprio.
a moins que le release early release often soit interdit dans ton pays ?
[^] # Re: A propos de la licence GPL
Posté par Troy McClure (site web personnel) . Évalué à 2.
Je ne comprends pas comment tu peux suggèrer ce genre de trucs... Encourager les gens à contourner l'esprit de la gpl sur linuxfr c'est quand même un peu bizarre.
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 1.
L'esprit de la GPL c'est "tu modifie mon truc, tu l'améliore, tu me reverse les modifs".
Pas "tu fait un truc qui a strictement rien a voir mais tu ose me linker dynamiquement (comme la libc, malloc, des pthreads) alors tu dois tout me redonner".
Perso, je suis même pour considérer que le linkage dynamique ne devrais pas être considérer comme une distribution.
Exemple con :
Deux lib, une gpl, l'autre proprio, avec la même api et abi.
(ex donné plus haut).
Donc le gars qui a fait la lib proprio qui a copié l'api de la lib gpl (ou inversement!) ou tout simplement suivi une norme ... ne respecte rien sous pretexte qu'il a essayé de faire une lib qui pouvait convenir à plusieurs personnes, et qui peut s'interfacer avec des logiciels qui n'ont pas été prévu initialement pour ? (ou qui ont été prévu pour suivre une norme définissant une api précise)
(vive LD_PRELOAD).
Bordel, il viendra a PERSONNE l'idée que sous pretexte il y a une lib pthreads sous GPL que tous les programmes qui utilisent l'api POSIX pthread doivent etre sous GPL ?
Parce que d'après ce que tu me dis, considérer le contraire c'est contourner l'esprit de la GPL...
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si tu construits une application qui n'utilise que MySQL, tu dois respecter leur licence. Si tu construits une application qui a besoin d'une base de données relationnelle, tu peux lui mettre la licence que tu veux.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 1.
Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
Et je suis désolé, mais pour moi ce n'est pas un travail dérivé si linké en dynamique. (car on peut utiliser d'autres lib que celle GPL si l'on souhaite. vive Ld_PRELOAD)
Sinon n'importe quel programme qui utilise pthread devra être sous gpl.
C'est à ça que je répondais.
Si tu construits une application qui n'utilise que MySQL, tu dois respecter leur licence. Si tu construits une application qui a besoin d'une base de données relationnelle, tu peux lui mettre la licence que tu veux.
Et tu te connecte comment à ta bd MySQL si tu as juste besoin d'un SGBDR ? Obligé de faire un fork puis faire un execvp ou un truc comme ça ? Ou tu utilise une de leur API (et tu peux aussi proposer de te connecter à postgresql, oracle, db2, ...) avec une lib de mysql(postgresql, oracle et db2) linké dynamiquement ?
Perso je sais pas trop comment marche les connecteurs aux DB donc si ça se trouve c'est pas du tout comme ça. Mais si il faut linker dynamiquement le connecteur, ben .. ça résoud pas le problème.
Et dire "ouais si ça dépend de mysql c'est pas bon, si ca dépend d'un SGBDR c'est bon" : tu le définis comment que ça dépend ou pas, si dans les deux cas tu as le connecteur qui est linké dynamiquement ? Par l'opération du saint esprit ?
[ps on ne parle pas là de rajouter une table ou modifier du code à mysql, mais bel et bien d'utiliser une api publique et de linker le code en dynamique, comme si j'utilisais pthread ou malloc ou ...)
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 2.
Cf. mon post plus bas pour cette histoire d'API, mon post qui commence par "Cette histoire de lib est un peu plus compliquée que cela...."
Pour te connecter à MySQL, si tu utilises un connecteur ODBC sous Microsoft ou JDBC en Java, à ce stade, tu n'es pas impacté par la licence GPL, même si le driver (la lib du connecteur) est en GPL. Pourquoi ? Parce que ODBC et JDBC sont des API de Microsoft et de SUN non-GPL et tu t'interfaces en fait avec elles (même si elles sont implémentées "par derrière" par un soft GPL).
Ensuite, il y a d'autes critères à prendre en compte.
Si tu utilises du SQL standard, à mon avis, tu n'es pas impacté par la licence GPL. Car tu ne dépend que du standard SQL, et pas de MySQL.
Si tu utilises des fonctionnalités particulières du SQL de MySQL => tu es par contre impacté par la licence GPL car tu dépend bien de particularités de MySQL propre à MySQL.
C'est comme cela que je c-o-m-p-r-e-n-d-s a-c-t-u-e-l-l-e-m-e-n-t les choses.
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 2.
Cf. mon post plus bas pour cette histoire d'API, mon post qui commence par "Cette histoire de lib est un peu plus compliquée que cela...."
Merci pour tes posts instructifs ;)
Mais quelques chose m'ennui quand même.
tu considère que copier une API non normé est "un produit dérivé" (je n'ai pas les bases juridiques ou autre pour appuyer dans un sens ou dans l'autre).
Si on sort une norme à partir d'une API d'un soft, la licence GPL qui s'appliquait ne s'applique plus ?
Si on sort un produit proprio, qu'on met l'api en publique, et que la GPL la copie. Le soft GPL peut nous attaquer en disant que c'est nous qui avons copié le soft ?
Une API est elle soumise au droit d'auteur aussi ? N'y a t'il pas des cas totalement triviaux dans les API ? (le but d'une API est d'être un minimum simple et cohérente. Il n'est donc pas impossible de se retrouver avec un certain nombre de fonction avec des noms et des paramètres identiques).
Une API ne peut elle pas faire partie du "droit à la citation"/"Fair use" ?
(si je copie un printf("toto\n"); dans un programme GPL, il y a assez peu de chance que l'on considère cela comme une violation manifeste du droit d'auteur).
enfin pour terminer :
Si tu utilises du SQL standard, à mon avis, tu n'es pas impacté par la licence GPL. Car tu ne dépend que du standard SQL, et pas de MySQL.
Si tu utilises des fonctionnalités particulières du SQL de MySQL => tu es par contre impacté par la licence GPL car tu dépend bien de particularités de MySQL propre à MySQL.
Donc si j'utilise un fork pour me connecter à la DB et j'envoie une requete sql spécifique mysql, je serais selon toi soumis à la GPL ?
Perso je pense pas (ie la reqûete est une donnée fournies, pas du code pour moi).
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
My pleasure ;-)
Mais quelques chose m'ennui quand même.
tu considère que copier une API non normé est "un produit dérivé" (je n'ai pas les bases juridiques ou autre pour appuyer dans un sens ou dans l'autre).
Oui, c'est ce que je considère actuellement, tjrs d'après ce que j'ai compris.
Si on sort une norme à partir d'une API d'un soft, la licence GPL qui s'appliquait ne s'applique plus ?
D'après ma réponse plus haut, je considère que la licence GPL continue à s'appliquer. Mais je ne suis pas avocat, hein !
Si on sort un produit proprio, qu'on met l'api en publique, et que la GPL la copie. Le soft GPL peut nous attaquer en disant que c'est nous qui avons copié le soft ?
2 petites précisions :
(a) l'API en question étant devenue publique, déjà, on ne peut pas dire que "la GPL la copie". Le soft sous GPL utilise simplement cette API.
(b) il faut savoir ce que veut dire mettre une API en publique. Si c'est utiliser une licence libre, il faut savoir qu'il existe des licences libres incompatibles : la licence Apache, par ex, est incompatible avec la GPL v2 et pas avec la GPL v3 (cf. http://www.gnu.org/licenses/license-list.fr.html ).
Donc, si un soft GPL utilise l'API publique :
(1) il faut déterminer si ce soft a déjà le droit de le faire, cf. (b)
(2) si (1) est ok, il n'y a pas conflit tant que le soft en question ne clame pas avoir le copyright/copyleft de l'API. Sinon, a priori, il s'agit grosso modo d'un conflit d'antériorité.
// Aparté-début :
D'après ce que j'ai compris, ce qui prime, d'une certaine manière, avant les licences, c'est la notion de copyright. Si tu disposes du copyright de ton logiciel libre, tu peux en changer de licence !
C'est pour moi à la base des licences duales. Si tu disposes du copyright, même pour un soft en GPL, tu as le "pouvoir" de relicencer ton soft sous une autre licence. D'où les licences duales. D'où le fait que IONA, pour un de ces projets open source, demandait aux contributeurs de céder à IONA le copyright : les développeurs externes étaient impactés par la licence open source, tandis que IONA, en interne, non, car ils possédaient du copyright. Enfin, c'est comme cela que je l'ai compris.
J'aimerais bien avoir l'avis, un de ces jours, d'un avocat là-dessus, sur le rapport copyright/licence. Histoire de vérifier ce que j'ai fini par comprendre...
// Aparté-fin.
Une API est elle soumise au droit d'auteur aussi ? N'y a t'il pas des cas totalement triviaux dans les API ? (le but d'une API est d'être un minimum simple et cohérente. Il n'est donc pas impossible de se retrouver avec un certain nombre de fonction avec des noms et des paramètres identiques).
Une API ne peut elle pas faire partie du "droit à la citation"/"Fair use" ?
(si je copie un printf("toto\n"); dans un programme GPL, il y a assez peu de chance que l'on considère cela comme une violation manifeste du droit d'auteur).
Bonnes questions. Je ne sais pas comment cela se passe pour les cas totalement triviaux !
Donc si j'utilise un fork pour me connecter à la DB et j'envoie une requete sql spécifique mysql, je serais selon toi soumis à la GPL ?
Perso je pense pas (ie la reqûete est une donnée fournies, pas du code pour moi).
Cette histoire de base de données GPL me casse encore plus la tête que pour les autres cas.
J'ai quand même un peu l'impression que MySQL joue aussi de son coté du FUD. Et qu'il y a au fond du FUD des 2 cotés...
Disons que si je n'utilise que du SQL standard, je suis certain de ne pas être impacté par la GPL.
Maintenant, si j'utilise une fonctionnalité spéciale de MySQL, j'ai dit précédemment que j'imaginais être impacté par la GPL, mais je n'en suis plus (si) sûr.
Ton post m'a fait réfléchir. J'ai relu le post de Bjorn, directeur technique de la fondation Eclipse : http://eclipse-projects.blogspot.com/2005/09/commercial-open(...)
Lui aussi s'emmelle les pinceaux ! Il clame bien qu'il n'est pas avocat.
Le seul commentateur du post de Bjorn indique que l'utilisation d'une base relationnelle GPL n'induit pas une "contamination" GPL car ce n'est pas créer un produit dérivé, mais utiliser un outil pour ce qu'il est. Par contre, en utilisant une base objet, oui, on est contaminé par la GPL.
Mais comme le dit ce commentateur, à l'instar de Bjorn : "And, of course, I'm not a layer too. Use at your own risk"
Maintenant, les avocats de MySQL pourraient éventuellement répliquer sur la définition d'une base relationnelle. Au sens large, MySQL est une base relationnelle. Au sens sans doute le plus restrictif, c'est sans doute un soft qui accepte telle ou telle norme SQL, et donc, sous cet angle, les extensions MySQL ne sont pas relationnelles, et sont bien spécifiques GPL. Sous cet angle encore, si tu fais un fork et envoie une requete sql spécifique mysql, comme je considère perso qu'une requête, c'est aussi du code, je dirais que oui, tu es impacté par la GPL.
Encore une fois, je ne suis pas avocat.
Nicolas écrivait plus haut : "Les licences proprio sont infiniment plus longue et complexe que la GPL." Mais vu qu'il ajoutait ensuite "qu'avec une licence proprio, tout est interdit de base", au final, c'était plutôt le contraire : les licences proprio apparaissent moins compliquées. De fait, perso, je n'ai pas encore de vision totalement claire de la GPL.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
La définition d'un produit dérivé est: "ton nouveau produit est-il autonome ou a-t-il besoin d'un autre morceau pour fonctionner" ?
Si il faut absolument MySQL pour le faire fonctionner, tu es un produit dérivé. Si tu peux utiliser n'importe quel aure db, tu es considéré comme autonome.
Dans le cas de MySQL, on parle de relation client/Serveur et même pas de link dynamique.
Concernant les pthreads c'est un mauvais exemple car il implémente juste une norme (posix).
On retrouve le concept sur les drivers Nvidia qui sont légaux dans linux car avant tout développé pour windows et pas uniquement pour linux.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
"
(1) Tu réponds à un problème juridique par un problème technique.
(2) La définition d'un produit dérivé est: "ton nouveau produit est-il autonome ou a-t-il besoin d'un autre morceau pour fonctionner" ?
"
(1) oui, je réponds à un pb juridique par un pb technique (à un moment donné, il faut bien revenir à la réalité, et on fait bien de la technique)
(2) avec ta phrase (2), toi aussi tu te places sur le plan technique. Comment tu sais si un produit est autonome ou a besoin d'un autre pour fonctionner, sans te placer au bout du compte sur le plan technique ?
Bref, j'ai l'impression que l'on parle de la même choses, mais avec des mots différents ;-)
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Disons que c'est tellement basique et vue de tellement haut que je n'appelle pas cela de la téchnique (link dynamique) mais du bon sens (indépendances de morceau).
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par briaeros007 . Évalué à 1.
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 3.
(cas-1) tu pars des API de SUN. Et tu utilises une implémentation GPL de ces API => tu n'es pas impacté par la licence GPL car tu t'interfaces, tu te linkes avec les API de SUN.
(cas-2) tu pars des API d'un logiciel GPL (j'entends ici une API définie par ce logiciel, une API non standard, non normée). Du moment que tu utilises ou copies cette API pour en faire un produit dérivé, tu t'interfaces avec cette API ou un de ses produits dérivés => tu es impacté par la licence GPL.
De fait, la bonne réponse est : cela dépend.
La réponse n'est pas apportée par le fait de se linker, mais de là d'où tu pars (l'API en question), i.e. la notion de produit dérivé.
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 2.
b) Si tu es sous Linux, et tu te linkes avec une des spécificités non normées de Linux => tu es impacté par la GPL.
Dans la majorité des cas, on doit être dans (a). Maintenant, j'ai dans l'idée que certaines personnes doivent éventuellement se retrouver, sans le savoir, dans le cas (b), en toute bonne foi, en se disant que si IBM, par ex, fait du business avec Linux et sans en être forcément impacté par la licence GPL, ils doivent pouvoir aussi le faire.
[^] # Re: A propos de la licence GPL
Posté par kemar . Évalué à 1.
Au risque de dire une bêtise, il me semble que la LGPL a précisément été inventée pour éviter ce genre de problème. À confirmer...
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La lgpl pousse à la réutilisation de lib mais pas à la contribution.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
readline n'est pas un petit projet.
C'est d'ailleurs un des principaux exemples de la FSF d'utilisation de la GPL au lieu de la LGPL, il site en général le nom des projets qui sont passés en libre "grâce" à readline.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par kemar . Évalué à 1.
Personnellement, je comprends qu'un développeur ne veuille pas passer ses propres projets sous GPL selon ce qu'il compte en faire, mais je ne comprends pas en quoi la GPL pourrait nuire à l'utilisateur. Je n'ai jamais entendu parlé d'une restriction ou obligation le concernant.
En fait, la principale dualité entre GPL et BSD tient au fait que la GPL ajoute une sécurité pour le développeur qui stipule que son projet ne peut être redistribué sous une autre licence sans passer par lui.
À moins que ce soit un développeur désireux de reprendre le projet à son compte que tu appelles utilisateur...
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
Oui, c'est cela. Je n'ai pas été très précis dans mon 1er essai de formalisation de l'impact-des-licences-sur-la-viabilité-et-la-visibilité-des-projets-open-source.
[^] # Re: A propos de la licence GPL
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . Évalué à 1.
Il fallait lire :
"
(2) Point négatif : le risque d'être impacté par la licence GPL éloigne certains développeurs-utilisateurs et possibles contributeurs => force de répulsion.
"
# Différences entre Lua et OCaml ?
Posté par ddevito (site web personnel) . Évalué à 1.
Est-ce que qqu'un qui connaitrait les 2 langages (on peut tjrs réver) peut préciser ici les différences entre les 2 ?
Merci
Soyons fou : quid d'une traduction (grandement automatique ? semi-automatique ?) de Lua vers OCaml par ex ?
[^] # Re: Différences entre Lua et OCaml ?
Posté par Mildred (site web personnel) . Évalué à 4.
Les tables sont la seule structure de donnée du langage. Cela peut être utilisé comme un vecteur (on indexe par des entiers, les accès sont optimisés), comme un tableau associatif, comme une structure, comme un ensemble (les clefs sont les éléments de l'ensemble, les valeurs sont juste là pour indiquer si l'élément est présent ou non).
Et pour étendre les tables, on a ce qu'on appelle les métatables. Ce sont des tables attachées à des objets (généralement des tables, mais pas forcément). Les fonctions stockées à des index particuliers de la métatable permettent de modifier un comportement par défaut.
Par exemple, si la métatable d'un objet contient un objet à l'index "__index", alors lorsqu'on execute obj.key (qui en passant est juste un raccourci syntaxique pour obj["key"]), la fonction (mataméthode) sera appelée avec les paramètres obj et "key", et son résultat sera le résultat de l'expression obj.key.
Cela permet entre autre d'implémenter des modèles orientés objets dans le langage. Car à la base Lua ne propose aucun modèle objet. Cela vient avec des bibliothèques extérieures comme LOOP http://loop.luaforge.net.
[^] # Re: Différences entre Lua et OCaml ?
Posté par loufoque . Évalué à 10.
Si tu dois penser que tous les langages qui ont les fonctions en tant que first-class citicizens sont similaire à OCaml, alors 95% des langages de programmation le sont.
Une différence fondamentale entre Lua et OCaml c'est que déjà Lua est typé avec du duck-typing, alors que OCaml c'est du typage statique avec inférence et polymorphisme paramétrique.
[^] # Re: Différences entre Lua et OCaml ?
Posté par seginus . Évalué à 10.
[^] # Re: Différences entre Lua et OCaml ?
Posté par Larry Cow . Évalué à 10.
Ou bien polymorphisme paramétrique?
[^] # Re: Différences entre Lua et OCaml ?
Posté par TeXitoi (site web personnel) . Évalué à 6.
- aucune verification de typage n'est nécessaire à l'exécution, ce qui fait gagner du temps à l'exécution.
- La vérification est faite à la compilation, donc si les types utilisés sont incohérents, le code ne compile pas, contrairement au typage dynamique, où une exception est levé à l'exécution.
inférence de type : il n'y a pas besoin de donner les types des variables, le compilateur les infèrent à partir du code. Par exemple :
let f n = string_of_int nLe compilateur va trouver tout seul que le type de n est entier et que le type de retour de la fonction est chaîne de caractères.polymorphisme paramétrique : C'est la possibilité pour un type d'englober un ensemble de type, avec des paramètres permettant une réutilisation du type plus loin. Par exemple :
let to_list n = [n]la fonction to_list prend un paramètre (qui peut être de n'importe quel type) et le transforme en une liste de type "liste d'éléments du type du paramètre. Le fait que la fonction puisse prendre un paramètre de n'importe quel type est le polymorphisme, le fait de pouvoir exprimer le type de la fonction grâce au type du paramètre est le paramétrique. Le code au dessus a pour type :'a -> 'a listce qui signifie une fonction prenant comme paramètre un paramètre de n'importe quelle type que l'on appelle 'a, et qui retourne une liste de type liste de 'a.[^] # Re: Différences entre Lua et OCaml ?
Posté par Stéphane Davy . Évalué à 3.
[^] # Re: Différences entre Lua et OCaml ?
Posté par caouis . Évalué à 2.
mais tu trouvera plus d'information en anglais.
sinon il n'y a pas beaucoup de livre la dessus le seul que je connaisse c'est celui la : http://www.cis.upenn.edu/~bcpierce/tapl/
# Euh !
Posté par Laurent Besson (site web personnel) . Évalué à -1.
Le polymorphisme statique avec inférence paramétrique de type age !
...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.