La célébrissime WTFPL… 
+2
-0
Acid, le lisp-like de la communauté !
Créons notre langage de programmation ! Pour le fun !
je ne savais pas qu'elle était connue dans le mileu.
+0
-0
Et tout aussi peu valable en France que la MIT. 
Après, je pense que le plus simple est encore de laisser chaque répo choisir sa licence, en fonction de ceux qui y contribuent. Quant à la spec, elle sera sous une licence de type documentation, donc c’est encore un autre problème.
+2
-1
Et tout aussi peu valable en France que la MIT.
Tout à fait d'accord. Pour les specs on peut peut-être opter pour du Copyleft.
+0
-0
J'ai une petite question au niveau du workflow git : étant donné que je suis le mainteneur du repo C++, puis-je y pusher directement mes modifs ? Naturellement, je dirais qu'il est plus logique de faire des PR, et ainsi séparer ma fonction de mainteneur de ma fonction de dév. Qu'en pensez-vous ?
+0
-0
Je pense que tu peux commit directement que tu est seul/peu nombreux. Sa va paraître étrange que tu valides directement tes propres PR. non ?
+0
-0
Certes. Mais après (courte) réflexion, je vais tout de même faire comme ça, pour push ru le repo central que lorsqu'une fonctionnnalité est prête.
Autre question : comment vous faîtes pour vous motiver quand vous ne voulez pas écrire les tests unitaires ? 
+0
-0
Bon je m'ennuie donc je vais faire une implémentation en Haskell. A moins qu'il y ait du nouveau sur l'implémentation Python.
+0
-0
Au pire, tu fais en sorte qu'il y ait du nouveau sur l'implémentation Python.
+0
-0
J'aimerais bien mais faudrait laisser du travail aux autres aussi
En plus je dois attendre the_new_sky pour faire quoi que ce soit, vu qu'il se charge de la traduction de l'AST.
+0
-0
Étant donné que ce que je souhaite faire semble bloquer l'avancement, je peux tout simplement y contribuer plus, tard. Je n'ai actuellement pas le temps de coder donc n'hésite pas à implémenter ce que tu as besoin.
+0
-0
Non je ne suis pas pressé
Prends tout ton temps, je suis déjà parti sur l'implémentation Haskell de toute façon.
Je ne vais pas beaucoup contribuer davantage, sinon ça pourrait empêcher d'autres membres de contribuer (ce qui va à l'encontre du projet initial, à savoir de faire un langage de la communauté).
Je me suis mal exprimé, mais prends vraiment tout ton temps. Sauf si un autre membre souhaite contribuer bien entendu.
+1
-0
(j'ai rajouté the_new_sky en Une)
+2
-2
Salut, je me posais une question : dans un projet comme celui-ci, est-il intéressant de mettre en place une politique d'intégration continue (tests + code coverage) ? Je commence à penser que non, pour deux raisons :
- j'ai la flemme de mettre ça en place
- surtout, je n'ai pas envie d'ennuyer les débutants avec ça.
Etes-vous d'accord avec ce choix d'y renoncer ?
+0
-1
Je pense que les tests sont indispensables sur un compilateur. D'autant que c'est le genre de programme sur lesquels ils sont les plus faciles à écrire.
+2
-0
Ça peut être formateur pour le débutants, mais je serai incapable de mettre ça en place seul.
+0
-0
Oh c'est très simple en réalité. Sans aller jusqu'à configurer un serveur d'intégration continue, tu peux simplement mettre en place un répertoire de tests que tu écris en python avec pytest.
Pour ce qui est d'une vraie CI (travis, tox & co), c'est overkill pour l'instant. Du moment qu'il y a des tests avec une bibliothèque un peu standard, ce sera toujours possible de configurer quelque chose de plus gros par la suite.
+0
-0
Je pense que les tests sont indispensables sur un compilateur. D'autant que c'est le genre de programme sur lesquels ils sont les plus faciles à écrire.
Ok, c'est noté !
Pour ce qui est d'une vraie CI (travis, tox & co), c'est overkill pour l'instant. Du moment qu'il y a des tests avec une bibliothèque un peu standard, ce sera toujours possible de configurer quelque chose de plus gros par la suite.
Personnellement, je vais tout de même mettre en place un simili de serveur de CI, qui compilera, exécutera tous les tests, et générera la doc.
+0
-0
Et tout aussi peu valable en France que la MIT.
Oh 
Quid de son homologue sa traduction française la PLRÀB ?
+2
-0
Non plus. Le problème, c’est que la licence est trop vide, il manque des choses.
Un contrat de cession de droits de propriété intellectuelle (les licences logicielles en font partie) dans lequel il n’est pas précisé :
- pendant combien de temps les droits sont cédés (ça peut être pendant toute la durée des droits patrimoniaux) ;
- sur quel territoire les droits sont cédés (ça peut être dans le monde entier) ;
- la liste suffisamment détaillée des droits cédés,
est interdit par les articles L131-1 et L131-3 du Code de la propriété intellectuelle.
En outre, s’il existe un rapport fournisseur-consommateur entre les deux parties du contrat (pour une licence de logiciel, ça correspond généralement au cas où l’auteur vend son logiciel, donc ça ne concerne pas Acid) :
- la loi Toubon de 1994 interdit que le contrat soit rédigé dans une autre langue que le français ;
- l’article L132-1 du Code de la consommation et l’article 1386-15 du Code civil (notez que ces deux codes vont être profondément remaniés au 1er octobre 2016, et que ces articles porteront alors les numéros L212-1 et 1245-14) interdisent à la partie fournisseur de se dédouaner de toute responsabilité et garantie en cas de problème avec son produit (genre, au hasard, la licence MIT qui passe plus de lignes à refuser de se mouiller qu’à céder des droits…).
Voilà, avec ça, vous saurez reconnaître une licence valide en France d’une licence que vous devrez laisser aux Anglo-saxons…
+6
-1
Salut, à votre avis, est-il gênant de considérer des tokens comme des entités et non pas des valeurs ? Ça me paraîtrait bizarre, quand même…
+0
-0
Connectez-vous pour pouvoir poster un message.
Connexion
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte