GuieA_7 a écrit 704 commentaires

À noter qu'il existe des bibliothèques (libev/libevent de mémoire) qui permettent d'utiliser la meilleure méthode pour chaque système (epoll sur Linux par exemple, mais les autres systèmes ont leur équivalent), ce qui permet d'obtenir un code plus portable.

Sauf que ça s'écrit Ada, pas ADA. Si tu en fais la pub, autant savoir l'écrire. Dommage que Ada ait mis si longtemps à avoir l'équivalent de la STL du C++, et que dans l'ensemble le langage évolue si lentement.

Un tel outil me semble indispensable en libre ; parce que c'est bien beau d'avoir des moteurs JavaScript, des canvas et.. qui déchirent, si au final on doit pondre le contenu à la main ce n'est pas génial. On peut reprocher beaucoup à Flash, mais force est de constater qu'il a permis à des non techniciens (du moins à la base) de faire des choses impossible avec les autres outils, et de voir ainsi apparaître des tas d'idées intéressantes (un peu à l'instar de la scène des développeurs de jeux indépendants).

Je verrai bien la MoFo sortir un tel outil, parce qu'ils ont quand même un paquet de bons techniciens, mais aussi de bons artistes. Et puis ça serait bien dans la continuité de leur travail actuel. Mais bon aucune idée de savoir si c'est dans leurs projets.

Trop génial, sauf que si tu utilises une classe avant de la créer, c'est que
t'es probablement complètement neuneu et que tu devrais changer de métier.
Visiblement tu n'as jamais enendu parlé de Développement Piloté par les Tests (TDD - Tests Driven Development). Dommage, je ne connais rien de mieux pour pondre du code excellent. Alors on se calme avant de traiter les gens de neuneu....

Désolé mais j'ai vu des tas de gens pondre du code de merde, même avec Vim ou Emacs, si si...

[je précise que je ne suis pas spécialement un utilsateur de Java ou Eclipse]

Elle est rapide cette dépêche ; j'ai découvert le jeu ce matin sur le bien connu http://happypenguin.org/ et me suis empressé de le compiler et le tester. Je pensais faire un journal pour dire tout le bien que j'en pense : pour le coup je me suis bien fait griller !!
Le jeu est vraiment bien fait (très pro - mais vu la qualité de Wesnoth on comprend mieux). Ça rappelle vraiment les grands moments de la SuperNes/Megadrive : une véritable ode aux gros pixels qui tâchent ! Le jeu n'est pas hyper original mais il est vraiment efficace.
Je n'ai pas matté le code source, mais le jeu ne prend pas de CPU quand il tourne c'est déjà un certain gage de qualité.
Je ne peux donc que le conseiller à tous ceux qui ne sont pas allergiques aux jeux de plateformes 2D (même ceux qui ont 2 mains gauches comme moi peuvent y prendre du plaisir).

Open source ne se limite certainement au code source dans ma tête. Mais comme je te l'ai dit quand j'ai payé je savais qu'il ne s'agissait que du code, mais que c'était déjà énorme. Le jour où tous les éditeurs de jeu fourniront leur code source, une telle initiative passera inaperçue, mais ça n'est malheureusement pas à l'ordre du jour...
Donc oui l'expression 'XX goes open source' est litigieuse/trompeuse, mais ce n'est pas elle que j'applaudis mais ce que qui est fait (soit la libération du moteur). N'en déduis rien de ma vision du libre.
Allez bonne soirée je m'échappe !

Bon en fait que crois qu'on est d'accord. Un jeu c'est bien moteur + données, et à ce titre Gish n'est pas libre non. Après lorsque la libération a été annoncé, je l'ai lu ici sur LinuxFR ; je ne me rappelle plus les termes exacts mais pour moi il était clair qu'il s'agissait avant tout du code, et j'ai acheté en connaissance de cause.

Après pour l'expression 'XXX goes open source', je ne sais quoi en penser. C'est effectivement assez flou, et même si pour moi source fais référence au code source (et pourtant je suis aussi graphiste et on peut aussi parler de fichiers source genre .xcf ou .blend), je peux comprendre que tu le comprennes autrement.

Ce qui me surprend le plus est la facilité, en tant que pro-libre, avec laquelle vous applaudissez ce genre de sorties : une entreprise souhaite garder le contrôle, à l'opposé de l'idée de l'open-source, et vous applaudissez sans émettre la moindre critique??? Mais que signifie le libre pour vous?

J'ai monté ma propre boite pour pouvoir développer des logiciels libres sans qu'un patron ne me dise quoi faire ; pour ça j'ai fait beaucoup de sacrifices mais j'en suis très content (mais tu es bien placé pour me comprendre). Alors ne me juge pas trop vite : le libre est _très_ important pour moi ça ne fait aucun doute.

Je n'ai pas acheté Word of Goo lors de leur 1ère opération, parce que pour moi le libre est primordial, je me fous de 'ça tourne sous linux x86'. De même, je n'ai acheté le Bundle qu'une fois la libération du code de certains jeux annoncée (et je n'ai encore joué avec aucun des jeux, pas le temps).

Évidemment j'aurai adoré que les données soient sous licence libre ; ça aurait été bien mieux que des données popriétaires. Cependant des données proprio n'ont pas non plus le coté 'malsain' qu'a le code proprio (contrôle de la plateforme, de la durée d'utilisation etc...). J'aime les données libres soit (j'en produis moi même), mais ça ne me choque pas vraiment que je ne puisse pas modifier et revendre les BD que j'achète par exemple.

Donc avoir le code source de jeux encore en vente c'est à 1000 lieux de la production de jeux standard, où c'est plutôt le règne des exclu à une plateforme, DRM et autre chasse aux 'pirates'. Là tu pourra ressortir ton CD de données dans 10 ans et jouer sur ton Hurd pour FreeCPU :)

Donc oui je suis critique et je suis le 1er décu, mais je préfère taper sur le reste de l'industrie du jeu, qui pourrait par exemple libérer les vieux jeux qu'ils ont dans leurs cartons (rahhh FunTracks !!!), et je ne parle même pas de libérér le code de leurs jeux actuels, plutôt que sur ces gens qui vont dans la bonne direction.

Mais finalement, la question qui me trotte le plus dans la tête est : pourquoi avoir mis le moteur du jeu en open-source et pas le jeu entier si le jeu a été rentabilisé par les internautes qui ont payé?

1) Parce que rentabiliser c'est l'objectif minimum pour une entreprise, mais que là ils vont pouvoir continuer à gagner de l'argent en vendant les données. Comme les jeux sont encore d'actualité on peut les comprendre (si c'était des jeux vieux de 15 ans et qui ne rapportent plus rien ça serait encore plus rageant pour nous).

2) Peut être, mais là c'est une hypothèse de ma part, qu'ils veulent garder le contrôle sur l'univers de leur jeu, et qu'ils ne veulent pas que des gens sortent des variantes de leur jeu dénaturant leur univers, que ce soit parce qu'un artiste n'a pas forcément envie qu'un autre change sa vision, ou que d'un point de vue business ils veulent se garder cet univers pour une éventuelle suite par exemple.

Sinon je peux comprendre ta frustration si tu as sincèrement pensé qu'ils libèreraient aussi les données ; mais je pense quand même que la libération du code source va permettre par exemple de porter les jeux sur des architectures/OS exotiques par exemple, et pérenniser l'existence de ces jeux. Alors ne regrettent pas trop d'avoir donné, parce que tu as quand même encouragé une pratique quasi inexistante dans l'industrie du jeu vidéo, même s'il y a encore des progrès à faire.

Il y 2 ans et demi j'ai fait une régie pour un client afin de réaliser une appli de monitoring, plutôt orientée moteur de bateau. La précédente équipe avait codé une application utilisant Kylix je crois, et pour les widgets de monitoring, IOComp. L'équipe s'est lamentablement planté ; ils codaient certes comme des cochons, mais ils semble que les mauvaises performances des bibliothèques que j'ai citées ne soit pas pour rien dans cette échéc (quelle idée d'utiliser des saletés proprio aussi...).
Avec la nouvelle équipe nous sommes partis de zéro, en avons utilisé Qt (non sans avoir testé beaucoup de framework d'IHM). Nous avons notamment utilisé les possibilités de dessin vectoriel de Qt afin de coder des widgets spécifiques: jauges horizontales, verticales, cadrans etc... Le projet a été un succés (mon regret est bien entendu que tout cela reste du proprio), mais un projet tel que GICS aurait été le bienvenu à l'époque.

Tout ça pour dire que je pense que votre projet me semble clairement répondre à un réel besoin. Alors voir tout ça en libre me fait franchement plaisir. Je ne peux donc que vous souhaiter bonne chance pour la suite !!

Je vais quand même envoyer un mail à mon ancienne équipe pour leur indiquer l'existence de votre bibliothèque.

J'aime beaucoup ton commentaire. Mais j'ajouterai quand même qu'une (bonne) école va 'obliger' ses élèves à voir des notions théoriques qu'on irait pas forcément voir tout seul, aussi passionné qu'on puisse être. Par exemple j'ai un pote trés nerd, passionné, libriste et tout qui n'avait jamais entendu parlé de complexité algorithmique malgré son bac+4(pas de bol en plus son école n'était pas bonne et préférait produire des pisseurs de J2E qui ne comprennent pas ce qu'ils font...).

Non, il y a depuis pas mal de temps me semble-t-il un GC dans Python.
D'ailleurs je me demande dans quelle mesure du comptage de référence pour faire le gros du boulot, plus un GC pour les cas problématiques, est une solution meilleure (ou moins bonne) qu'un GC tout seul....

Si ça peut te rassurer, des lecteurs (enfin au moins un) apprécient tes posts quand ils vont à contre courant de l'avis de la majorité....

/me qui espère que Lisaac sera le langage/environnement qui dépote et venant de l'INRIA (parce que déçu par SmartEiffel et OCamL).

A mon avis, une des meilleures choses est la disparition des old-style class ; la cohabitation des 2 styles de classes est vraiment un reliquat inélégant.
Et je suis d'accord, on ne peut que se réjouir de la tendance à mettre des itérateurs là où il y a des copies de liste actuellement.

Ne serait-ce pas Incubation ? (si oui, j'avais bien accroché aussi)

J'avoue avoir été méchant. Je ne l'ai félicité qu'une seule fois ; et j'ai osé émettre un avis sur ce qui me semble être une légère erreur.

Je ne le referai plus, c'est promis ; je n'émettrai à l'avenir plus que des commentaires dithyrambiques. C'est comme ça que les logiciels s'améliorent, en émettant _que_ des encouragements.

<mode sincèrement gentil>
Continue David, c'est du bon boulot.
</mode sincèrement gentil>

[et si David s'est senti agressé, j'en suis vraiment désolé, c'était vraiment pas mon intention. Il faut croire qu'écrire des commentaires quand on a passé une journée de merde c'est pas mon fort]

C'est bien possible, c'est pas moi qui m'en occupons (et pour l'instant on ne compte pas trop sur le web pour attirer les clients - et pourtant ça marche).

Mais MERCI de ta critique.

Je n'ai jamais prétendu être une brute du C++ ; je faisais référence à des gens comme ceux de boost par exemple. Tu sais, ces gros guignols qui s'y connaissent un tout petit peu en templates et méta programmation ; et bien eux non plus ne foutent pas tout dans un seul fichier (pourtant on pourrait certainement trouver des points perfectibles dans leur code, malgré leur maîtrise - parce que c'est de ça dont il s'agit). Alors que toi tu sembles être sûr de toi, parce que ta lib existe depuis 7 ans, donc tu ne peux pas avoir commis une seule erreur (j'entends par là que ce n'est pas un argument technique ça).

[ argument technique oublié dans la précipitation : sinon découper en plusieurs fichiers, ça pourrait aussi apporter en temps de compilation (mais si tu codes en C++ comme un bourrin, tu dois le savoir) ]

Sans rancune.

Merci de ta longue réponse.

Alors non je n'ai pas ton expérience en C++ c'est bien certain. Mais l'argument 'ça existe depuis des années' désolé mais bof bof. Le VB aussi ça existe depuis des années....

Ensuite oui je connais la STL et le principe des templates ; et bien elle n'est pas constituée d'un seul fichier tu m'excuseras. Donc non je n'ai pas la prétention de connaître la meilleure façon de faire , sinon je ne me remettrais pas en question tous les 3 jours. Et si je suis peut-être prétentieux (on est mauvais juge de soi-même), permets moi de te retourner le compliment.

Alors tu fais ce que tu veux, je n'ai droit de regard sur ton travail (je précise que toutes les remarques que j'ai faites je les ai faites sur des souvenirs de précédents journaux ; c'est parce l'air de rien je me suis intéressé à ton travail). Mes critiques se voulaient constructives c'est tout, mais ta 1ère liberté, c'est de ne pas les écouter.

Je ne peux que souhaiter qu'une bonne âme face le plug-in gimp. Voilà.

Je ne veux pas passer pour le donneur de leçons, mais il semble quand même que ton gros fichier .h de plusieurs milliers de lignes, avec en vrac des trucs pour le fenêtrage/affichage, des fonts en dur etc.... embête plus qu'autre chose. Tu avais l'air de penser que c'est le plus simple, et pourtant regarde :
- personne au monde ne fait comme ça (parmi les personnes qui codent bien en tout cas...) ; c'est quand même un indice.
- si le packager pour le plug-in gimp l'a dit, que les dev krita préfèrent partir du code du plug-in Gimp, c'est peut-être un autre indice.
- les dev ne sont pas des imbéciles ; s'ils n'arrivent pas à gérer 3 .cpp qui se courent après, ils peuvent arrêter de coder....

Si ton code était bien séparé entre .h et .cpp, qu'on puisse obtenir une vraie bibliothèque, ça changerait surement des choses (et si comble du bonheur, il y avait en plus une interface en pur C, ça ouvrirait encore d'autres horizons -- même si SWIG gère aussi le C++) : un vrai paquet dans les distribs, des bindings vers d'autres langages (python etc...), un développement pour des plug-in facilité...

Enfin bon, je m'emporte, et je ne t'ai même pas félicité pour ton algo excellent ; mais je trouve dommage qu'il soit si mal mis en valeur.

Je précise que je n'ai rien contre OCaml ni contre les logiciels 'non-industriels' (pour le libriste que je suis ça serait vraiment cracher dans la soupe). Pour en avoir fait un petit peu, c'était effectivement vraiment pas mal. A écouter certains, c'est le meilleur langage du monde et on peut jeter le reste (mais bon je ne suis pas le dernier à précher pour mes outils favoris, je sais ce que c'est), mais j'aimerais quand même la réponse de personnes qui s'y connaissent bien en OCaml à mes quelques questions :
- Si j'en crois la doc, les threads sont lightweight et n'utilisent donc pas les multi-processeurs. Est-ce exact ?
- Toujours en mattant la doc, le chargement dynamique de bibliothèques ne marche qu'en mode bytecode, et pas en mode natif. Là encore, est-ce que je me trompe ?

Parce que si je ne me trompe pas, ça fait quand même 2 trucs assez indispensables qui manquent. Alors, je suis le 1er à m'extasier sur des conceptions super haut niveau ou des algos élégants et performants, mais pour un langage que certains voudraient voir remplacer le C, je trouve ça très handicapant.

Voilà mon objectif n'est absolument pas de dégouter les gens de OCaml (il y a des tas de langage très nuls mais super utilisés, alors un bon langage sous utilisé je vais pas taper dessus en priorité), mais juste de signaler que faire un langage avec des abstractions super bien foutues c'est bien, mais pour pouvoir remplacer les autres langages, il va quand même falloir pouvoir faire au moins autant que ces derniers.

Les API de Vista ne sont dispo que pour Vista ; donc non c'est pas la panacée d'utiliser les fonctions de 'chrooting' différentes de tous les OS pour avoir quelque chose de portable. Mais ça changera peut être dans le futur (remarque que je n'ai pas dit que ce n'était pas possible).

Sinon as tu des infos supplémentaires ?? Peut-on dans Vista 'chrooter' une simple classe par exemple, et pas un thread en entier (il me semble avoir lu que sous win on a des droits avec une granularité au thread près) ??

Un truc que j'adore avec linuxfr c'est qu'on y rencontre des gens vraiment pointus !
Je vais mater ton langage avec attention.

Sinon tu as fini par dire que sans vm le langage devait être sandbox-ready (dans la pratique), donc ce n'est pas l'OS qui assure tout seul le sandboxing (auquel cas le langage n'importerait pas).

(merci encore pour cette discussion fort intéressante)

Merci, je ne connaissais pas les slim binaries ; c'est très intéressant je m'en rappelerais.

Pourtant, tu te contredis légèrement, puisque tu dis 'ca sert à rien' puis 'sauf dans qq cas'. Je pense qu'on va aller dans un monde avec plein de machines très différentes interconnectées (station, pda, téléphone) donc ces quelques cas font que si ça ne marche pas partout, c'est génant (c'est comme dire que si ça marche pour win ça marche presque partout...). Mais bon dans l'ensemble on est assez d'accord au final : on peut se passer de VM la plupart du temps (beaucoup de programmes ne perdraient pas de feature, et gagneraient en perf, à être réécrits dans un langage sans VM par exemple).

Pareil pour le sandboxing : le faire de manière identique sur tous les OS, pour une portion de code (et pas un processus en entier) et à l'heure actuelle, sans java/.NET(/autre?), et bien c'est pas possible. Et que dans l'absolu, ça soit possible, ça ne change au final pas grand chose. Donc je maintiens que si on a besoin de sandboxing (c'est à dire pas souvent, je te l'accorde), pour l'instant la VM est le seul salut.

Quant au remoting, oui j'ai précisé que cétait juste un confort pour le programmeur (la comparaison avec Corba est bonne).

Je précise tout d'abord que je ne suis pas un java/C# zealot, et que je suis bien content que la plupart des applis que j'utilise soient codées en C/C++. Pourtant je pense que tu te trompes ; pas complètement, mais tu te trompes quand même. Je m'explique.

La portabilité (binaire avec bytecode - ou directement avec le source) + le sandboxing, ça peut être très utile, même en utilisant que des Logiciel Libre, même sur un desktop. Par exemple, dans ton browser, y a éventuellement du Java, du javascript, et tu es bien content que ça soit portable et sanbboxé(tu comprend bien que "chrooter" ton browser, c'est pas la panacée). Non je milite pas pour plus de java/javascript sur le web, c'est un exemple. Mais on pourrait en trouver d'autres. Par exemple un genre de BOINC, qui téléchargerait des calculs à faire, mais sans avoir besoin de devoir faire confiance à un binaire qu'on ne télécharge pas grâce à sa distribution. Ou un serveur de jeu, qui enverrait des règles spécifiques à une map. etc...

Donc même dans un environnement libre, avoir du code mobile peut avoir du sens (il suffit de savoir qu'on peut le faire, et les idées viennent !!). Et utiliser l'os pour chrooter toutes ces applis n'est pas une solution viable. Mais bon je t'accorde que toutes les applis n'en ont pas besoin. Et que si besoin est, le coeur de l'appli peut être codé en C par exemple, mais charger à côté une VM pour exécuter uniquement le code mobile.

(ah oui et le remoting c'est pour faire de l'appel de fonctions/méthodes à distance ; ça peut être confortable pour le programmeur ; mais pour l'utilisateur là ça ne change rien).