GuieA_7 a écrit 689 commentaires

Pourquoi? Du point de vue de l'acheteur non codeur, pwivateur sans DRM ou libre, c'est la même chose.

Oui, mais du point de vue du développeur/éditeur (celui qui prend des risques donc), ce n'est pas pareil. Dès que le jeu va être un peu connu, des parasites peuvent apparaître et vendre le jeu rebrandé. C'est vrai pour le jeu proprio sans DRM ou pour le jeu libre, mais dans le 1er cas il y a des recours, dans le second c'est explicitement autorisé. Or comme tu l'as dit toi-même, les joueurs s'en fichent, en tout cas aujourd'hui, que le jeu soit libre.

Bilan, le fait de faire un jeu libre apportent des soucis supplémentaires (moins de protections contre les parasites, même si on ne peut pas s'en débarrasser dans tous les cas), mais pas de ventes supplémentaires. D'un point de vue strictement économique c'est malheureusement compréhensible.

Personnellement je pense être un libriste plus que convaincu (j'ai fait beaucoup d'effort pour aujourd'hui vivre de mon logiciel libre, travailler pour une boîte classique qui fait du proprio aurait été bien plus facile et rémunérateur), pourtant même moi je ne prendrai pas le risque de faire un jeu entièrement libre si c'était pour en vivre. En revanche j'opterai pour des assets proprios:

• soit pendant la période de commercialisation (j'entends par là quelques années tout au plus).
• soit pourquoi pas une campagne de financement participatif dont l'objectif serait la libération des assets (à la manière de l'OpenBundle, histoire de voir ce que les libristes sont vraiment prêt à donner pour avoir des assets libres.

Le 4ème lien fait mention de "CreamCRM" => CremeCRM.

Très bonne question.

Si ça ne tenait qu'à moi, on serait déjà passé à Python 3. Mais :

• on tient à ce que Creme soit installable facilement sur une Debian stable ; parce que c'est ce qu'on a sur nos infrastructures, mais aussi que ça représente assez objectivement l'inverse du bleeding-edge, donc ça sera installable à peu près partout.
• je souhaite passer à Python 3.3 au minimum, parce qu'en dessous ça semble plus pénible de migrer depuis Python 2 ; or la Debian 7 vient avec Python 3.2.

Donc on ne passera à Python 3 qu'avec la prochaine Debian stable ; et encore pas immédiatement, vu que par exemple Creme 1.4 tourne sur Python 2.6 car on a encore des Debian 6 sur certains serveurs, et on ne demandera Python 2.7 qu'avec Creme 1.5 (j'ai déjà pas mal de patches en préparation). Ça n'est donc pas pour tout de suite, mais ça va arriver, et ce n'est pas l'envie qui manque !

Je pense qu'on sautera le pas directement, on ne gérera pas à la fois Python 2 & 3, car pour un logiciel "final" (pas une bibliothèque) ça n'a pas beaucoup d’intérêt (en plus de nécessiter plus de travail). Je verrai bien ce passage à l'occasion de Creme 2.0, mais rien n'est décidé à ce niveau.

Sinon dans nos dépendances en effet rien n'est bloquant techniquement à part pygraphviz, mais c'est une dépendance très dispensable, qui pose déjà des problèmes (pas installable sous Windows), et dont je me débarrasserai quand j'aurai le temps.

Merci pour les liens.
J'avoue n'avoir rien compris au PDF sur LRA, il m'a l'air destiné au gens connaissant bien le fonctionnement interne et les nomenclatures de GCC. Tant pis.

En revanche le lien sur REE était sympa. Voici un résumé pour les lecteurs pressés :
Dans certaines situations le compilateur génère des instructions inutiles (car le boulot a en fait déjà été fait), ou bien 2 instructions qui peuvent être fusionnées en une seule. C'est notamment le cas sur x86-64 lorsqu'une valeur 32bits est chargée dans un registre 64bits, et que le processeur étend implicitement cette valeur avec des 0 dans les 32 autres bits (d'où le nom "extension instructions"). Cette passe va donc éliminer les instructions inutiles ou bien fusionner 2 instructions. Le gain de performance est apparemment assez faible sur les processeurs avec ré-ordonnancement dynamique, mais peuvent aller jusqu'à 10% sur Atom par exemple.

dans sans avoir à suivre les autres directives

Le backend AArch64 profite également de l'activation de la passe d'optimisation

Outre les nombreux changements liéS

Sinon très bonne dépêche ; j'aurai bien aimé une petite explication pour REE (Redundant extension elimination) et LRA (local register allocator), ça m'avait l'air intéressant.

Pour la peine, est-ce qu'ils n'auraient pas gagné en perf en faisant une distinction entre int et Integer comme en Java ?

Ça marche en Java (et C#) grâce au typage statique ; le langage sait s'il faut convertir un int en Integer (ou l'inverse) car il connaît le type des variables et celui des paramètres des méthodes. Mais comment faire en Python ? Ta fonction "def foo(a): […]" comment peut elle savoir si elle reçoit de la part de l'appelant un int ou un *PyObject (au sens C) ? Tout repose sur le fait que les variables sont toutes des *PyObjects, et qu'ensuite on applique le duck typing.

A noter quand même :

• Dans CPython, y a pas mal d'endroits où la VM prend des raccourcis quand elle rencontre des types de base. Par exemple avec "if a:", la méthode __nonzero__/__bool__ de "a" n'est pas appelée en cherchant dans la virtual table lorsque Python s'aperçoit que "a" est un *PyInteger ou une *PyList par exemple, car en pratique on appelle rarement "if" sur des instances classes utilisateur. Python reste évidemment lent, mais il le serait beaucoup plus s'il était codé naïvement.
• PyPy est capable de générer du code machine travaillant avec des simples int lorsqu'il s'aperçoit que c'est possible et pertinent ; par exemple il va utiliser une version spécialisée de liste si elle ne contient que des *PyInteger.

Non ça ne marche pas (mais c'était drôle quand même). Il se trouve que dans CPython (mais a priori c'est une question d'implémentation, ce n'est pas portable), les entiers jusqu'à 256 sont des singletons (ils sont pré-alloués en plus me semble-t-il). Chez moi (Python 2.7.6):

> a = 256
> b = 256
> a is b
True

Mais

> a = 257
> b = 257
> a is b
False

Donc on n'a pas "==" et "is" qui sont équivalents de manière général (et donc pas avec "0xdeadbeef" en particulier).

Il y a un problème avec ton 2ème exemple. On rentre dans le bloc else d'un for (ou d'un while) à la fin de l'itération, sauf si on est sorti avec un break justement. Ton bloc else ne peux donc pas être le traitement d'erreur tel que présenté.

Sans parler des cas très pointus où le GC va permettre, en défragmentant le tas, d'améliorer la localité des données et ainsi améliorer les performances (parce qu'il faut quand même que cet avantage surpasse l'inconvénient qu'est l'arrêt de la tâche), un GC pallie le problème des cycles de références, qui vont engendrer des fuites mémoires même avec des pointeurs intelligents. C'est pour ça par exemple qu'avec CPython ou en PHP, il y a un GC qui s'occupe des cas problématiques (les cycles donc), même si le refcounting fait la majorité du boulot.

Sinon sinma a bien répondu juste au dessus je pense, à savoir que le GC est par tâche, et ne s'occupe que des références qui le concernent, ce qui fait qu'on est loin d'un langage entièrement sous GC.

Je rajouterai que:

• le runtime est entièrement remplaçable/supprimable : zero.rs est utilisé par les gens qui font des noyaux et enlève le runtime classique et la possibilité d'un GC.
• la bibliothèque standard n'utilise pas le GC (ni de refcounting je crois).

Du coup la logique du "tu payes pour ce que tu utilises" est vraiment poussée loin.

En même temps il s'agit dans tous ces cas d'exprimer f(n+1) grâce à f(n), c'est conceptuellement très proche. Après quelle est la manière la plus efficace de l'enseigner; je ne sais pas. Mon prof en prépa qui nous a enseigné la récursivité, a immédiatement fait le rapprochement avec la récurrence et ça marchait bien, mais il y sûrement d'autres approches possibles. Tant que c'est bien enseigné ça me va.

Pourtant on voit ça pour le bac, il me semble. Faire des dérivées de logarithmes et d'exponentielles, j'en ai fait en Bac STL Chimie, il doit bien y en avoir des restes dans toutes les filières à vocation scientifique, non ?

Les gens qui atterrissent en BTS info ont, j'ai l'impression, souvent du mal avec la théorie, sinon ils seraient allés en IUT/prépa/Fac. Je ne serais pas étonné qu'ils sachent trouver le bouton 'log' sur leur calculatrice pour appliquer une formule, mais trouver une complexité algorithmique nécessitera sûrement un rappel.

Malgré un passage par Math Sup, je n'ai pas le souvenir du concept de récurrence (mais c'était il y a 15 ans). Mais ça ne m'a pas empêché de comprendre immédiatement le concept des fonctions (programmatiques) récursives. D'ailleurs, peut-être que la factorielle est une fonction (mathématique) récurrente ?

Tu n'a jamais fait de démonstration par récurrence ? J'ai fait une prépa de 1999 à 2001 et c'était au programme ; en fait je suis même à peu prêt sûr de l'avoir vu aussi au lycée en S. Peut-être que ça t'a aidé à comprendre au début la récursivité (que tu utilises encore régulièrement j'imagine) même si tu l'as oublié depuis.

Je suis bien d'accord qu'il faut des bases, c'est pourquoi je suis un fervent opposant à la mode d'enseigner la programmation par le Basic à la mode (en ce moment c'est Python).

Je suis partagé à ce sujet. Pas mal de hackers de talent, ou moi, ont commencé par le Basic, qui leur a fait découvrir la joie de faire un programme qui vit sous ses yeux ; au final le goût de la rigueur, de la théorie, vient avec le temps (tout comme j'estime n'avoir fait des Maths qu'en prépa, avant c'était du bricolage avec des nombres). Les gens qui ne s'orienteront pas vers l'info auront vite tout oublié de toutes les façons (mais peut-être que l’informatique leur paraîtra moins mystérieuse, ce qui est déjà bien), et dans les filières info d'autres langages seront enseignés. Mais on s'écarte du débat :)

ce sont les carences en orthographes et grammaires qui sont les plus graves.

Je suis d'accord, mais le problème c'est que ces carences auraient du être éradiquées bien avant, genre au collège. Que ce soit au BTS de corriger ça indique un vrai problème, et ce n'est pas au BTS de le faire ; le français est indispensable dans toutes les filières, et ce bien avant le lycée.

néceçaires

tu parlais d'ortaugraf c'est ça ? :)

je ne vois pas plus utile

Savoir ce qu'est un logarithme ou un polynôme pour comprendre la notion de complexité algorithmique me semble indispensable (et je sais d'expérience que les gens sortant de BTS ne savent pas ça en général). Et même avant ça, comprendre la notion de récurrence aide à saisir comment raisonner avec la récursivité ; ça me semble assez basique et pourtant c'est une carence répandue. Si on veut faire des programmes un tant soit peu correct, il faut faire un minimum de théorie. Des tas de non informaticiens pondent le logiciel interne (boiteux) de leur entreprise en Windev, mais sans aucune approche scientifique ça va être difficile aux gens sortant de BTS de se démarquer des premiers.

Si ma mémoire ne me fait pas défaut, on peut lancer Blender en lui donnant en paramètre un script Python à exécuter immédiatement, ce qui permet de faire basiquement ce que tu demandes.

Après je ne sais pas si l'API Python actuelle (2.50+) permettrait d'attendre des commandes (activement ou passivement), venant d'un pipe/fichier/socket, afin de piloter plus finement, et interactivement, Blender depuis une console classique. Je suis à peu près sûr en revanche que cela n'était pas possible avec la vielle API (2.49 et avant).

Dans mon Gimp (2.6), dans Filtres/Flou tu as un effet 'Pixéliser', qui semble faire ce que tu veux.

Python, ruby, C, C++ : erreurs dans les calculs simplissimes ex 0.1 + 0.7 = 0.79999999

Dans ces langages, les nombres à virgule flottante sont mappées sur ceux gérés par le processeur (avec les erreurs inhérentes à ce type de données), et on les utilise pour des questions de performances quand les erreurs sont acceptables (ex: 3D), et c'est très bien comme ça.
Maintenant en Python par exemple tu as dans la bibliothèque standard (donc ça fait partie du langage) le type Decimal qui fait ce que tu veux ; pour les autres des bibliothèques qui font la même chose existent j'imagine.

Dans Django (framework web python) ce type Decimal est fourni de base pour les modèles sauvés en base de données. On s'en sert dans CremeCRM pour la facturation par exemple, et ça fonctionne nickel.

Maintenant les logiciels de gestion ne sont franchement pas les plus exigeants de manière générale, dans le sens où n'importe quel langage que tu apprécie peut faire l'affaire, et les problèmes que tu cites semble être des détails tout à fait anodins. Aucun des langages n'est parfait, mais une chose est sûre, si tu en créé un il sera bien plus mauvais que n'importe lequel des langages que tu as cités.

Je ne suis pas vraiment d'accord avec toi, mais ton commentaire est constructif cette fois, ça va être intéressant de discuter.

Les chances que cela soit de l'incompetence technique sont infinitesimales.

(Je ne peux pas trop en dire, mon identité n'étant pas un secret) tu sous-estimes le fait que dans nos instances dirigeantes (ou à la tête de grandes entreprise, je côtoie les deux) :

• des tas de gens agissent pour leur propre intérêt, pas le bien commun, quitte à couler un projet qui marche pour se faire mousser, ou à l'inverse mettre en avant une solution boiteuse en échange de service, par exemple.
• je ne sais pas si c'est typiquement français, mais ici on voit peu de techniciens dans les sphères dirigeantes. Les hiérarchies ont un niveau technique très faible, et se font facilement rouler par des roublards (des gens de leur staff aux dents longues par exemple), ou bien prennent des décisions techniques aberrantes par orgueil (ils pensent y comprendre quelque chose).

Ces choix sont dans l'enorme majorite des cas des compromis apres reflexion, de rares fois des choix evidents, et tres rarement une decision totalement stupide.

Je suis d'accord pour le compromis (en technique il est toujours question de compromis).

Mais surtout même les décisions stupides le sont rarement assez pour être fatales, ça ne veut pas dire que c'était de bonnes décisions pour autant. Par exemple un de nos ex-prospects, une école faisant partie d'un groupe d'écoles, c'était fait imposer un logiciel par ledit groupe. Ce logiciel avait été choisi car c'était le leader du secteur global, mais l'école ne l'utilisait pas, car il ne correspondait pas vraiment au besoin. L'école s'est ensuite fait imposer en remplacement un second logiciel (le leader au niveau des écoles), mais là encore il n'était pas très pertinent et restait inutilisé. Mais bon au final les gens s'en sortait quand même avec du bon vieux papier (et sûrement des fichiers excel). Je pense que cet exemple n'est pas isolé.

Mais cette habitude qu'on certains ici de mettre au pilori automatiquement toute decision qui va dans le sens de MS, sans rien savoir de la situation sinon leurs prejuges pourris, est vraiment a vomir.

Oui j'ai aussi horreur des fanboys/hateboys de tous bords, mais de manière générale je trouve que le MS-bashing se fait moinser rapidement. Et dans le cas qui nous intéresse on a quand même des gens qui sont partis en masse, dégoûtés par leur hiérarchie, et ici en France les mauvais techniciens préfère généralement rester planqués. Je ne peux tout de même pas me prononcer sur la prétendue incompétence de l'armée, mais on a plus d'arguments factuels que s'il s'agissait d'un simple MS-bashing je trouve.

Ce qui est drôle c'est ce que tu fais exactement ce que tu dénonces, à savoir affirmer de manière arrogante. Si encore tu avais dit "ce n'est pas forcément de l'incompétence".

Des gens en interne nous donnent un témoignage ; leurs avis n'est pas pour autant 100% objectif, mais ils connaissent à priori mieux le dossier que toi. Tu affirmes que ça ne peut pas être de l'incompétence, comme si ça n'arrivait jamais qu'une hiérarchie n'ayant pas de compétence technique prenne des décisions techniques (à l'encontre de leur staff) ; personnellement je l'ai vu plusieurs fois.

Ça me fait un peu penser aux Exceptions (sans les problèmes de sûreté) mais la syntaxe est quand même assez différente et… perturbante. Ça me parait plus souple que les exceptions, mais à voir à l’utilisation.

Si ça ressemble visuellement aux Exceptions, la sémantique est assez différente, puisqu'il manque la fonctionnalité la plus puissante (mais aussi la plus controversée), à savoir la remontée au travers de la pile (et donc des appels de fonctions). En effet dans Rust, le gestionnaire de conditions est exécuté à l'endroit du raise, et ne constitue pas une autre façon de sortir de la fonction.

Bien utilisée, la remontée dans la pile permet d'écrire du code court et d'éviter pas mal de code boilerplate. Malheureusement ce comportement casse la sémantique de Rust, qui ne pourrait plus fournir ses garanties.

Je suis assez sceptique sur l'utilité des conditions, parce que si le discours est qu'on peut coder le comportement que l'on veut face à une erreur, j'ai l'impression qu'il faudrait plus ou moins penser à tous les comportements possibles, afin que la signature du handler permette dans les faits de gérer l'erreur comme on le veut. Je me dis que dans la pratique on va peut-être la plupart du temps finir par gérer l'erreur d'une manière figée et retourner un Option/Result.

Mais j'espère me tromper, et je vais faire confiance aux développeurs de Rust qui ont fait du super boulot pour le reste, donc y a pas de raisons ! Et Rust possède à côté d'autres outils permettant d'éviter le boilerplate.

Mon précédant jeu est en "pause" ; le choix de notre moteur 3D (JME) s'est avéré mauvais à l'usage ; ça a beaucoup ralenti le développement, et la motivation est partie. Mais j'ai attaqué un jeu un peu moins ambitieux depuis (avec Ogre), dans lequel je peux réutiliser en grande partie mes assets ; je vais essayer d'avancer substantiellement pendant mes vacances.

Autant GIMP peut clairement me servir pour SàT (icônes, tutos, etc), autant Blender c'est juste pour le plaisir

Il y a quelques années j'avais utilisé Blender pour faire des icônes avec un rendu assez réaliste pour un prototype client, et ça marchait plutôt bien. Avec un peu d'imagination ça peut être un outil très utile pour de la 2D ; on pourrait aussi imaginer des avatars sous la forme de sprites animés etc….

Il me semble que dans une autre vie tu as eu droit à une formation Blender… :)
Mais le problème c'est que son IHM a beaucoup changé depuis quelques années (pour le plus grand bien), et que quand on en a pas fait depuis longtemps le retour peut être difficile.

Sinon, tu as l'intention de mettre de la 3D dans SàT, ou c'est pour autre chose ?

Hum c'est quand même loin d'être aussi simple. Phil Fish n'est pas un dev, c'est le créateur de Fez, il code, fait les graphismes, le game design et le level design, et à plein temps. Même si Fez était fini à 50%, la communauté du libre a-t-elle des Phil Fish en puissance pour faire les 50% manquants ? Je dirais non malheureusement, sinon il y aurait des tas de jeux libres de la trempe de Fez.

Il ne suffit de balancer un truc pas fini en libre pour qu'une armée de volontaires arrivent et fassent un produit fini. D'ailleurs il y a des jeux libres qui finissent dans l'oubli faute de volontaires (genre Wormux) ; et je pense que si tu laissais tomber Newton Adventure aujourd'hui, personne ne le continuerait avec la même dévotion que toi (le jour où il aura une grosse communauté de fans ça sera différent).

Certains projets font des choses superbes avec bien bien bien moins que ça

Effectivement le projet que tu pointes demande très peu je trouve. Mais dans le cas de 0 A.D, il faut à mon avis prendre en compte que le jeu au final est libre et gratuit. Un jeu propriétaire kickstarté est vendu lorsque son développement est terminé ; le financement sert à payer les développeurs pendant le développement initial avec des petits salaires, et ils se rattrapent (si ça marche évidemment) par la suite en vendant leur jeu. Ce n'est pas le cas pour 0 A.D.

En tout cas va falloir qu'ils communiquent mieux s'ils veulent se donner une chance. À la fois sur leur indiegogo et en faisant de la promo extérieure (sites de JV et d'actus du libre)

Oui, vu la qualité du jeu et le peu d'argent récolté pour le moment il semble qu'il faille améliorer la communication du projet. Mais il est clair que l'aspect libre ne touchera qu'une petite frange de joueurs malheureusement.

Je sais bien que les joueurs libristes sont une niche, mais j'espère que cette niche peut quand même financer la création de jeux de qualité.

Tout d'abord même si je n'ai pas encore pris le temps de tester ton jeu, il a l'air très sympathique.

En revanche, même si j'imagine qu'on t'a déjà fait la remarque, comment comptes-tu gérer la ressemblance visuelle avec Pokemon ?? Que soit ce qui semble être une Pokeball au pixel prêt, l'interface des combats où même le sprite des héros, la similarité avec la licence de Nintendo est flagrante.

Tant que ton jeu restera confidentiel ça ne sera pas un problème, mais s'il devient un peu connu (ce qu'on ne peut que te souhaiter), tu vas avoir des ennuis, big N n'étant franchement pas aussi gentil que ses mascottes. D'autant que tu dis vouloir faire de l'argent avec ton jeu.

Tu parles de beta testeur, pour un jeu en pre-alpha ; tu cherches un alpha testeur ? Au final, dans ta tête, à combien de pour-cents évalues-tu la finition du jeu ? Parce qu'en phase de beta (classiquement en tout cas) le jeu est proche du résultat final, mais là à mon avis il va falloir au moins repenser l'habillage du jeu (ce qui fait beaucoup de boulot).

Faire un jeu où des personnes peuvent capturer des créatures et les faire combattre, ça n'est pas un problème, il y en a déjà un certain nombre. Mais il va falloir trouver un univers qui s'éloigne un minimum de Pokemon. Je ne sais pas, remplaces les pokeballs par un aspirateur à monstres, une épuisette magique, des cartes à jouer mystiques ; fais des créatures inspirées des Korrigans, des Yôkai (bon pour ce dernier j'ai vu un jeu qui va bientôt sortir et qui le fait), des dragons, ou des objets du quotidiens (ce ne sont que des exemples trouvés en 10 minutes hein).

Je n'ai pas encore joué, mais y a-t-il des mécaniques qu'on ne trouve pas (à ma connaissance, j'ai juste fait un épisode GameBoy il y a 15 ans) dans ton inspiration originale ? Comme le fait de fusionner 2 monstres, qu'ils aient des caractéristiques uniques (genre 2 Marmottes Infernales de niveau 36 qui ne seraient pas identiques), des blessures persistantes etc…

En tout cas bon courage pour la suite.

try:
    prev_feed = loaded_feeds[url]
except KeyError:
    prev_feed = None

prev_feed = loaded_feeds.get(url)

if not list(set(item['taglist']) & set(feed['wotags'])):

if not set(item['taglist']) & set(feed['wotags']):

if item["updated_parsed"] == None:

if item["updated_parsed"] is None:
voire:
if item["updated_parsed"]:

(pas équivalent si jamais __eq__ ou __bool__ a été définit, mais je crois que là c'est bon).

Le gros avantage c'est que tu sais que cette méthode n'a pas d'effet de bord. Seul ton code accède à ce dont il est le seul à avoir besoin.

Tout à fait d'accord, vu que tu répète ce que j'ai dit (peut être pas assez clairement ?). Cette fois, le hack était très peu risqué et avait d'énormes retombées en terme d'élégance dans le reste de l'application, notamment en permettant d'économiser beaucoup de lignes de code. Mais d'autres fois le compromis est beaucoup moins favorable, et je vais faire autrement. En technique, on est sans arrêt dans le compromis.

Mais dans le fond on est d'accord je pense, donc pas la peine de chipoter pendant 3 heures.

Je ne connais pas les refinements de ruby, mais les classes d'extension de C# d'après ce que l'on voit dans le lien plus haut ne permet que d'ajouter des choses, donc les collisions se voient déjà bien mieux.

Je ne ferai pas de journaux sur Rust en disant que j'ai hâte de m'y essayer si je pensais que l'approche dynamique de Python était l'alpha et l'oméga.