GuieA_7 a écrit 695 commentaires

"set([])" peut être écrit simplement "set()". En fait, pour aller plus loin :

[...]
  subjects = set([])
  g = Graph()
  g.parse(rdf, format=fmt)
  for subject in g.subjects() :
    subjects.add(subject)

  for subject in sorted(subjects) :
  [...]

pourrait être plus court:

[...]
  g = Graph()
  g.parse(rdf, format=fmt)

  for subject in sorted(set(g.subjects())) :
  [...]

OK, merci pour ta réponse ; je comprends mieux et je suis bien d'accord (vu mon activité ça semble évident).

tu fais passer le message "un éditeur ne peut pas faire de libre"

Désolé si je n'ai pas été clair, mais en me présentant comme un éditeur de logiciel libre, je ne pensais pas que c'est le message qui passerait.

tu as sans doute loupé http://linuxfr.org/news/lisez-en-liberte-avec-teabook-open-reader

En effet, malgré mon assiduité sur LinuxFr je n'avais pas lu cette intéressante dépêche. Mais sauf si j'ai loupé un truc :
- le modèle de TEA est un subtile mélange de mes points 1 & 3 (et c'est bien), ce qui ne remet pas en cause en ma conception du business autour du libre.
- l'expression "à licence" n'était pas très claire ; avec le recul j'imagine que ça s'opposait juste à "logiciel développé pour un client et auquel on cède le copyright". Désolé si tout le monde avait compris ça sauf moi.

Je remets la citation initiale

Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.

Alors j'ai peut-être mal interprété le "sous licence" (qui ne veut pas dire grand chose au final), mais je l'ai interprété comme "licence payante". Et je n'ai peut être pas saisi ce que tu voulais dire, mais j'ai l'impression que tu dis la même chose que moi. Dans tes exemples, je vois des boites qui gagnent de l'argent grâce :

1. aux services autour de leur produit (services payants, pas la licence).
2. à la vente de versions propriétaires bâties au dessus de leur version libre (d'où ma remarque sur un produit pas entièrement libre, c'est bien le propriétaire qui rapporte de l'argent au final)
3. à leur activité principale, pas lié à ce logiciel, mais qui est libéré gracieusement (ce qui est très bien hein).

Donc CrEv n'a l'air de parler ni de 1 ni de 3, et 2 n'est pas entièrement libre, ce que je disais.

Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.

Dommage que ton modèle soit incompatible avec la création de logiciels libres (ou du moins entièrement libres, certaines briques pourraient l'être). J'ai cela dit déjà entendu parlé de boites faisant des logiciels libres, mais qu'elles ne distribuaient (et donc leurs sources) qu'à leurs clients ; ce système ne marche qu'avec des logiciel de niche je dirais. En tout cas c'est assez éloigné de ma vision idéale de diffusion de la connaissance ; après ce n'est pas le but de tous les libristes, j'en suis conscient.

En tant qu'éditeur de logiciel libre, je pense arriver à combiner:
- une vison produit 'originale', pas une commande bizarre de la part d'un seul client (même si cette vision est amené a évoluée en fonction des retours des utilisateurs, heureusement).
- du service (développement, formation, déploiement, hébergement, conseil…), rémunérateur.

Je suis même régulièrement amené à sortir du cadre de l'informatique pure, genre préparation d'un stand sur un salon (banderole, goodies …) ; ça ne fait pas de moi un meilleur programmeur mais c'est intéressant aussi (pour aller dans ton sens de l'ouverture d'esprit).

Coté univers et aspect graphique, le coté retro de Nikki me touche et me plaît beaucoup, je me doute que ça ne fonctionne pas pour tout le monde, mais moi j'aime bien le retro/pixelisé/8bit assumé.

J'ai des goûts éclectiques (même si j'ai un faible pour la 3D "cell shadée"), et les graphismes rétro savent toucher le vieux joueur que je suis : SuperMeatBoy, Fez, JamesTown, Megaman 9… J'avais bien aimé Frogatto, dont le moteur est libre (je crois qu'il y a un éditeur aussi).

D'ailleurs je n'ai pas critiqué les graphismes de Nikki. Le sprite du personnage est sympa en effet ; après la direction artistique n'est pas bien profonde non plus.

Je pense depuis longtemps que vendre des jeux vidéos dont le code (moteur) serait libre, et les données propriétaires, serait tout à fait viable. Le succès des Indie Bundles, dépourvu de DRM le prouve : ils sont facilement piratables (puisque pas de protection), pourtant dans l'ensemble les gens sont prêts à payer pour de bons jeux. Que le moteur 'nu' soit libre n'y changerait donc rien.

Autant sur des logiciels classiques, à la durée de vie longue, la liberté du code a prouvé ses avantages du point de vue technique, autant sur les jeux tout reste à faire pour convaincre les créateurs. Les joueurs se tapent de la liberté du code et ne vont donc pas boycotter les jeux propriétaires. Il faut donc compter sur de rares créateurs de jeux sensibles au libre pour essayer de démonter que ça apporte quelque chose financièrement (si c'est le cas), car le fait que ça ne coûte rien de libérer ne suffit pas à motiver il faut croire (mais les mentalités peuvent évoluer).

C'est donc vraiment enthousiaste que j'ai accueilli Nikki and the Robots. Le business model me semblait proche de la perfection : un jeu libre complet (code et données), et des données payantes supplémentaires (pour moi la perfection serait de libérer toutes les données à un certain moment, mais je chipote). Mais voilà, c'est là que le bât blesse : le jeu me parait très faible. Je n'ai testé que les niveaux libres, mais ils sont censés me donner envie d'acheter le reste, et ce n'est vraiment pas le cas (malheureusement) : je ne me suis pas amusé, le principe de base n'est pas bien folichon, et le game design, qui aurait pu rattraper cet état de fait, n'est pas du tout inspiré . Peut être que ce n'est pas le cas des niveaux payants, non faits par les joueurs, mais dans ce cas il aurait fallu en libérer quelques uns pour montrer ce que le jeu a dans le ventre.

Donc je suis le premier à le déplorer, parce que l'intention derrière ce jeu est très sympathique, mais dire qu'un jeu très médiocre ne s'est pas bien vendu ne permet pas de dire que c'est la faute du business model. Notez bien que des jeux médiocres peuvent très bien se vendre (pub toussa), et de très bons ne pas trouver leur public ; mais rien à voir avec la licence.

Aux alentours de 2004 (oui c'est loin), dans ma boite on s'est beaucoup intéressé aux moteurs 3D libres. On a du passé la plupart en revue ; aucun d'eux n'étaient parfait évidemment, mais en gros seul Ogre était dénué de grosse lacune rédhibitoire, notamment grâce à son approche généraliste très versatile. Presque 10 ans après, la plupart de ces moteurs ont périclité et ont fini dans l'oubli, alors que de son côté le développement de Ogre est très actif.
Il est notamment utilisé dans le très bon TorchLignt (qu'on retrouve dans le dernier Indie Bundle) et TorchLight2 qui vient de sortir (et recueille lui aussi de très bonnes critiques). Je ne sais pas si d'autres moteurs 3D libres sont utilisés dans des jeux commerciaux à succès (j'exclue les moteurs de Id Software, qui deviennent libres bien après leur succès).
Une autre chose appréciable est que Ogre a toujours eu un script d'export pour Blender de qualité ; mais je ne sais pas si c'est vrai depuis Blender 2.50+.
Je pense que Ogre est très populaire, et ça explique sûrement aussi beaucoup le nombre de critiques qu'on va trouver sur lui (parce il est utilisé par plein de monde ; les moteurs inconnus au bataillon, personne ne va les critiquer). Ce qui ne veut pas dire qu'il est exempt de défaut, ou que les critiques sont infondées. J'imagine que son approche généraliste fait qu'il est surement bien moins bon qu'un moteur spécial FPS si on veut faire un FPS par exemple.

PS: je serai vraiment curieux de voir émerger un moteur 3D (libre) en Go, ça serait intéressant je pense.

Resident Evil (une femme, dans le jeu vidéo ce n'était pas le cas)

Pas du tout ; rien que dans le 1er épisode du jeu tu peux jouer une femme (Jill Valentine) ou un homme (Chris Redfield), et avoir 2 aventures un peu différentes. Et puis les films Resident Evil c'est de la bonne grosse merde, tu aurais pu prendre un autre exemple :) (y a plein d'héroïnes mémorables dans les films de Ghibli)

Wikipedia indique sur la page du jeu que le code source a été libéré en 2011 ; la révision relative à cette annonce date du 23 Mars 2012. Donc ça date un peu, mais ça n'est pas un preuve très solide non plus. De son côté le site de Pandemic est fermé depuis 2009, et celui d'Activision pas bien intéressant.

Ok merci pour ta réponse.

Wait and see…

C'est toi qui as des doutes ou tu as lu des trucs là dessus (c'est une vraie question) ?

Sierra et/ou Valve libére le code de Won (même si c'est obselete maintenant) ? Douteux

Si j'ai bien compris, ce qui as été libéré c'est juste le client, c'est pour ça que le multijoueur ne fonctionne pas.

les fichiers commencent toujours par un header proprio (Copyright 1997-1999 Pandemic Studios, Dark Reign II)

Ce n'est pas spécialement un header proprio ; même dans un code libre les différents fichiers peuvent avoir un copyright différent, mais tous placés sous une même licence (pas forcément répétée dans tous les headers).

les assets sous forme d'archive compressé
aucune modification depuis 2011

En effet l'effort pour rendre la libération propre n'a peut être pas été suffisant.

Bon j'ai vu la news passer sur slashdot (et j'ai un peu regardé histoire de faire un eu plus qu'un journal bookmark), donc Activision l'a surement vu passer. Ce ne sont pas des tendres et les choses devraient être mise au clair rapidement. J'espère que cette libération n'était pas du flan.

Rah mais quel boulet je n'ai pas relu mon titre : s/Drak/Dark
Si un gentil modo pouvait corriger. Merci d'avance.

Je n'ai jamais dit que ça me dérangeait d'ajouter des mots clés ; j'ai juste dit qu'en Python il y avait une alternative sympa à if !('id' in plop), et qui ne nécessite pas de mots clés supplémentaire ; c'est tout.

unless 'id' in plop
# …

En python on pourra certes l'écrire comme ça :

if not 'id' in plop:
  # ...

mais aussi comme ça :

if 'id' not in plop:
  # ...

qui me semble assez proche de ton envie d'expressivité, et sans ajouter de mot clé.

s/immuable/immuables/ :)

J'ai fait mon Jean-Claude Van Damme, mais j'ai préféré utiliser le terme anglais pour éviter les confusions (d'où les guillemets et le non accord).

Ça doit même être dans le tutoriel de Guido Van Rossum (je regarderai). C'est pourquoi il est conseillé de toujours utiliser des objets "immutable" en tant que valeur par défaut. Quand je forme des débutants, je présente ça comme un écueil classique.

Merci de sourcer à ma place ! :)

Personnellement, je dirais que le management ne l'a probablement pas entendu de cette oreille

Oui c'est exactement ce que je pense ; tout Michel Ancel qu'il est, il ne fait pas tout ce qu'il veut (et puis à quel point était-il à fond derrière cette libération, difficile a savoir). Dommage, vraiment dommage.

D'ailleurs à propos de Rayman Origins, Michel Ancel (son créateur) avait dit dans une interview l'année dernière qu'il envisageait de libérer le moteur du jeu (et les outils associés me semble-t-il). Ça me ferait bien fait plaisir (c'est un moteur 2D utilisant efficacement les cartes graphiques modernes), et c'était très étonnant de la part d'Ubisoft. Malheureusement pour le moment j'ai eu raison de ne pas m'emballer parce que rien à l'horizon à ma connaissance.

En plus il y a une petite typo :
tampon de buffer hiérarchique -> tampon de profondeur hiérarchique

Tu parles de quoi?

Cette remarque ne t'était pas forcément destinée. Mais un certain nombre de techos affirment qu'ils pourraient très bien faire des logiciels qui poutrent, être 10 fois plus productifs, si seulement les imbéciles de décideurs prenaient le risque de leur faire confiance (et je suis d'accord hein, les dirigeants n'y connaissent souvent pas grand chose en technique, ils savent juste ce qu'est la vente). Sauf que parmi ces techos justement, très peu iront se mettre en danger justement, et continueront à faire ce que les décideurs leur disent de faire ; comme quoi il n'y a pas que les décideurs qui n'aiment pas les risques, c'est assez naturel en fait.

Pou caricaturer, je dirais qu'aux USA des techos montent leur boite, en France ce sont les commerciaux qui le font.

je n'ai jamais entendu personne faire ce reproche à Python sur un forum, en dehors de la communauté Python.

Peut-être que tu bosses beaucoup au lieu de mouler :) , mais si, le GIL est un défaut de Python souvent cité (sur LinuxFR par exemple). Même pour les gens qui aiment Python, comme moi, oui c'est clairement un défaut. Ce n'est pas pour rien qu'il y a :

• Stackless un fork de CPython qui propose un système sans GIL (je crois) avec envoi de messages.
• multiprocessing, un module de la lib standard qui pallie vaguement ce problème en simplifiant les apps avec plusieurs processus.
• plein de gens déçus que pypy (la nouvelle vm avec JIT) ait gardé le GIL ; il y a cependant un groupe de travail qui bosse sur la Software Transactionnal Memory.

Aujourd'hui, je pense que le problème principal est d'améliorer l'accessibilité d'OCaml, en faisant des livres pour débutants, des tutoriaux en ligne (voir http://try.ocamlpro.com/), en améliorant les outils de développement (un bon mode Eclipse) et le support Windows (la version 4.00 imminente devrait avoir deux installeurs pour Windows concurrents, alors que la version précédente en avait zéro !).

Oui entièrement d'accord. Ce n'est surement pas le genre de trucs qui motive les gens de l'INRIA, mais il faudra en passer par là pour populariser Ocaml.
En fait ma question sur les performances, notamment ce qu'il faudrait améliorer, était plus de la curiosité technique qu'autre chose. Tu ne réponds pas à cette partie, mais si tu ne sais pas trop ce n'est pas grave (alors que pour Python c'est assez facile de comprendre ce qui est lent), je profitais juste de la chance de parler à quelqu'un qui met les mains dans le cœur d'Ocaml.

OCaml ne fait pas beaucoup d'optimisations en comparaison, et a donc pas mal de marge de progression.

Est-ce que des optimisations sont prévues, ou est-ce qu'au vue des ressources humaines ce n'est pas une priorité ?
Est-ce qu'utiliser LLVM pourrait améliorer les performances ? Ou est-ce que la majorité des optimisations devraient de toutes les façons avoir lieu au niveau du frontend (en évitant des copies par exemple) ?

Depuis quelques années (mais c'est pas hyper vieux non plus), la VM Erlang gère le SMP ; je ne connais pas la politique exacte des threads, mais j'imagine que c'est un pool de threads, avec un thread par core, et comme tu dis des threads légers par dessus (vu qu'Erlang encourage la création de dizaines de 'processus erlang', ça serait bête de créer un thread système pour chacun). J'imagine qu'avant il fallait lancer une VM par core 'à la main' pour exploiter son hard au maximum.

OK, merci pour les précisions. En tout cas je serais ravi de lire une dépêche présentant ces softs libres (et je ne pense pas être le seul), ça éduquerait les geeks incultes que nous sommes. :)