GuieA_7 a écrit 704 commentaires

peut t'on comparer l'équipe gambas ... a celle d python ... elle est égale a celle de python après ses 10 premières années ...

C'était une boutade hein, je me doute que l'équipe de Gambas est petite et a mieux à faire. Ceci dit le typage statique de Gambas faciliterait peut-être la compilation, comparé à des langages comme JavaScript ou Python (mais ça reste un gros travail).

On est systématiquement mis au défit et comparé aux gros du moment.

Ah ben ça c'est tout à fait normal. Du moment que tu dis aux gens d'utiliser ton logiciel, ils vont forcément se demander pourquoi le tien et pas un autre. C'est d'autant plus vrai pour un langage de programmation : il est assez facile de changer de navigateur Web ou de lecteur multimédia, mais quand on se lie à un langage cela a plus de conséquences. Ce n'est pas pour rien qu'il y a des tas de langages (libres) de qualité avec une faible communauté.

Comme le disait Benoit, l'important c'est la maitrise de l'outil, sa compréhention, son adaptabilité. C'est a ce jeu que gambas est bon.
Ce qui est bon aussi, c'est l'ide, pas forcément révolutionnaire mais de plus en plus complète et j'oserais a ce titre dire unique dans le monde du libre.

Il faudrait peut-être rentrer plus dans les détails sur ces qualités (être "vendeur", ce n'est pas péjoratif).

• En quoi un utilisateur de Gambas maîtrise plus Gambas q'un utilisateur Python maîtrise Python ?
• Qu'entends-tu par "adaptabilité" par exemple ? Tu parles de modifier l'interpréteur lui-même ?
• Pour l'IDE, quelles sont ces qualités par rapport à QtDesigner (pour ne citer que la référence libre) ?

Pour ce qui est de la vitesse d'excution, a l'affichage en gui on attend moins un programme gb qu'un py. Voila un ressenti :-)

Pour avoir fait du python embarqué temps réel, je dirais que la façon de coder importe plus que le langage. Par exemple un langage rapide ne dispense pas de jouer avec l’asynchronisme pour rendre une application vraiment réactive.

... mais on aime ça! :)

Je me suis amusé avec le premier benchmark, dont voici le code original :

#!/usr/bin/python

n = 500000
x = 0.2

def t(x):
    mu = 10.0
    pu = 0.0
    pol = [0] * 100
    r = range(0,100)

    for i in range(0,n):
        for j in r:
            pol[j] = mu = (mu + 2.0) / 2.0
        su = 0.0
        for j in r:
            su = x * su + pol[j]
        pu = pu + su
    return pu

for i in range(0,10):
  print t(x)

J'ai fait de très mineures modifications histoire que ça soit plus pythonique :

#!/usr/bin/python

n = 500000
x = 0.2

def t(x):
    mu = 10.0
    pu = 0.0
    pol = [0] * 100
    r = range(0, 100)

    for i in xrange(0, n): #Ici xrange pour pas allouer une grosse liste pour rien
        for j in r:
            pol[j] = mu = (mu + 2.0) / 2.0

        su = 0.0
        
        for val in pol: #ici j'itère sur la liste histoire de ne pas passer inutilement par un indice
            su = x * su + val

        pu += su # += pour faire bô

    return pu

for i in range(0, 10):
    print t(x)

Je passe sur ma machine de 231.824s à 209.599s, soit presque 10% de gain. Gambas reste donc bien plus rapide, ce qui montre bien que le typage statique permet des optimisations intéressantes, même avec un simple interpréteur.

Puis j'ai rajouté ceci après le shebang:

try:
    import psyco
    psyco.full()
except ImportError:
    print 'No "psyco" module'

Et (après avoir installé Psyco !) le code s'exécute en 84.306s, soit presque 3 fois plus rapidement. Évidemment Psyco c'est que x86 et plus trop maintenu, mais ça donne une idée de ce qu'on va avoir avec PyPy qui est annoncé comme 5 fois plus rapide que CPython.

L'équipe de Gambas relèvera-t-elle le défi en implémentant du JIT (le suspens est à son comble) ?? :)

J'en profite au passage pour féliciter ladite équipe pour son travail.

Comme le dit Zenitram au dessus, tu oppose libre et commercial, mais ce sont 2 concept orthogonaux. La double licence TrollTech, c'était libre vs propriétaire. Du moment que tu fais du libre, tu n'empêche pas les concurrents de faire du commercial ; tu peux juste les empêcher de faire du propriétaire (licences *GPL), mais même pas les obliger à contribuer avec toi.

Encore une fois la protection du code, pour nous qui vendons du service, n'est pas une problématique. Les mauvais payeurs sont un problème par exemple, pas les "voleurs" de code.

Mais admettons que tu n'aies pas fait la confusion propriétaire/commercial ; il est clair que TrollTech était confronté à un problème de business model dans le libre : ils pouvaient difficilement vendre du service autour de Qt. Ils en vendaient (support etc...), mais leurs utilisateurs sont des techniciens et n'en pas souvent besoin. Et c'est encore plus un problème dans le cas de produit pour le grand public ; il est clair qu'on ne peut transposer le modèle propriétaire classique dans le monde du libre, et c'est bien embêtant. Les réponses changent donc en fonction du type de logiciel ; mais encore une fois, pour beaucoup la "non-protection" n'est pas gênante.

Oui la question est intéressante. Une première réponse et après au dodo.

• Faire du libre est déjà pour nous une démarche militante. Ce n'est pas une volonté issue d'une étude de marché pointue qui nous aurait démontré que dans notre cas c'est plus rémunérateur ; évidemment il n'est pas question non plus de partir au casse-pipe. Mais avant nous faisions de l'intégration VTiger (un autre CRM libre), et on a bien vu que sur ce marché très concurrentiel, en travaillant sérieusement nous arrivions à gagner notre vie.

• La concurrence est déjà rude, et les CRM libres s'en sortent plutôt bien ; ça ne ferait qu'un concurrent de plus au final.

• Pour le moment en tout cas, le fait que notre boite soit jeune et petite est le plus gros problème pour lutter face aux gros ; le fait de faire du proprio n'y changerait pas forcément grand chose (c'est discutable toutefois, car on aurait du coup peut-être accepté des financements qu'on refuse justement pour pouvoir garder le contrôle et rester libres). Du coup que des gens utilisent notre soft serait plutôt synonyme de publicité.

• On a écrit la moindre des lignes de Creme, alors quand il faut le customiser nous sommes efficaces forcément. Si nous n'arrivons pas à nous démarquer face à un concurrent faisant du Creme "sauvage" c'est que nous devons nous améliorer (mais oui c'est plus rude que de vivre de rentes comme avec le proprio).

Au final je dirais que ce problème d'auto concurrence est un peu une chimère, mais c'est vrai c'est LA question que nous posent les gens habitués au monde propriétaire. À part nous empêcher un jour d'ériger un monopole (ce qui est une bonne chose, ils ne sont pas souhaitables), ça n'est pas un gros problème.

Le jeu vidéo n'a jamais été notre activité (un jour peut être...), juste une occupation pendant le temps libre (entre 2 contrats par exemple) pour certains d'entre nous. Ça continue donc doucement en tâche de fond.
Mais tu le saurais si tu avais levé le nez de ton clavier à faire du Haskell, parce qu'on faisait du CRM depuis longtemps quand tu étais là.
Ahlala ces jeunes....

Je l'ai évoqué dans mes réponses parce que c'est en effet une leçon à retenir, et que ça explique les dates (création en 2005, mais Creme n'a débuté qu'en 2008-2009). Pour être franc j'ai essayé d'être synthétique pour ne pas pondre des réponses exagérément longues, et éventuellement compléter dans les commentaires si les gens sont vraiment intéressés par la question.

Il y aurait surement des tas d'anecdotes porteuses de leçons à raconter ; par exemple il est amusant de noter que durant ce projet je m'étais mis à Blender, et au Python pour le scripter, et que bien plus tard cette expérience m'a fait briller en entretien, et que j'ai même "contaminé" mes collègues (puisque Creme est en Python).

Quand ils font référence à la grosse quantité de R&D qu'ils ont fait, je suppose qu'ils parlent d'un gros truc de 3D qui était impressionnant à l'époque, mais qu'ils n'ont pas vendu (?).

Qu'on a pas amené à un niveau vendable surtout. Mais je ne suis pas rentré dans les détails pour cette partie parce que ça n'a pas grand intérêt avec le sujet.

N'hésitez pas à me corriger si j'ai réécrit l'histoire

Non c'est tout à fait ça.

Si en 2004 on leur avait dit qu'ils éditeraient un jour un logiciel de Relation Client, je pense qu'ils auraient bien rigolé :)

Sûrement ; mais en ce qui me concerne j'ai pensé assez tôt qu'on trouverait notre voie au détours du chemin sans savoir ce qu'elle serait. En revanche la plupart de nos camarades pensaient qu'on allait crever rapidement et renier nos idéaux, et là c'est nous qui leur donnons tort !

C'est pas très "logiciel libre" de dire que la licence importe peu tant que le logiciel et les services associés sont de qualité [...]

Je pense qu'au fond on est d'accord, et je vais faire de la rhétorique plus qu'autre chose, mais dans un contexte d'entreprise, je dirais: au contraire.
En effet, vu qu'on gagnerai tout autant en faisant du proprio (ou peut être moins ou peut être beaucoup plus, mais c'est difficile à dire sans machine à remonter le temps), faire du libre dans ses conditions témoigne d'une réelle envie militante.

A contrario, lorsqu'une grosse boite faisant habituellement du proprio, se met à faire de l'"Aupenne Source" car elle répond à un appel d'offre l'exigeant, le côté militant est beaucoup moins évident ! Je serai content lorsque tous les clients auront ce genre d'exigences, mais ce n'est pas pour tout de suite, alors il est important que les gens croyant au libre proposent des solutions de qualité dès maintenant.

Même si mes clients se fichent d'être libres, tant pis ils le seront quand même !

Certains clients ont quand même des données "sensibles" (top secret et compagnie), et pour cela s'héberger en interne, en faisant attention aux connexions venant de l'extérieur, a du sens. Mais c'est vrai que même dans les entreprises ayant un service informatique, ce dernier est souvent très occupé et bien content de ne pas gérer un logiciel de plus.

Ne confondrais tu pas un CRM avec un CMS ?

Mail parti.

PS: c'était sympa les messages privés du vieux DLFP ; j'espère qu'ils reviendront un jour.

MrJmad et moi-même (ainsi que 2 autres associés) avons monté une boite à la sortie de l'école, il y a 6 ans. Nous y développons notamment ce logiciel, tout ce qui a de plus libre. On a des utilisateurs et on en vit, mais après on ne peut pas dire qu'on ait une communauté, pour le moment en tout cas. Si ça vous intéresse malgré tout, on répondra avec plaisir.

J'ai pas mal utilisé E16 il y a une dizaine d'années, et j'en garde un très bon souvenir ; je me rappelle aussi d'un Linux Mag qui annonçait la sortie très prochaine de E17. Dix ans plus tard on comprend bien que ce n'est pas encore pour tout de suite malheureusement...

Ton commentaire est riche d'informations, mais certains points me font tiquer.

• Tu comptes sur Intel, mais après Meego, LiMo et compagnie, on attend encore quelque chose de substantielle venant de chez eux. Pendant ce temps, bonne ou mauvaise chose, Android cartonne.
• Tu reproches aux développeurs d'applications leur manque d'audace. Mais bon à force de casser les bases tous les 2 mois depuis 10 ans, il ne faut pas s'étonner que les dev abandonnent bien vite. Je comprends le côté perfectionniste ; je suis pareil mais vu que je vis de mon application, et bien j'ai du faire des concessions sur ce point, et poser des échéances. Au final c'est sympa aussi.
• Les artistes ne risquent pas d'arriver en masse sur un projet aussi underground, il ne faut pas rêver. Étant plus ou moins graphiste, je dirais que faire des graphismes qui ne seront vus que par les 3 geeks qui téléchargeront la version SVN d'une application qui ne marchera plus dans 6 mois n'est pas très motivant. Au contraire, un truc comme MineCraft par exemple, avec ses toutes ses imperfections, mais qui marche là maintenant, s'est construit une jolie communauté, et voit l'apparition de pleins de créateurs en herbe (c'est le 1er exemple qui m'est passé par l'esprit, allez savoir pourquoi...).

Je ne sais pas pour la 3D, mais en 2D, si tu regardes bien, beaucoup de jeux libres reprennent des images issues d'OpenGameArt.

Y a-t-il dans le lots des jeux "aboutis" ? J'entends par là des jeux auxquels par exemple des gens se foutant du libre et qui s'y connaissent un minimum en jeux joueraient (pour peu qu'on leur montre). Ce n'est pas tant que l'avis des non libristes m'intéresse spécialement, mais ça permet d'avoir un avis purement technique ; tous ceux qui utilisent Firefox ne sont pas des libristes, et c'est parce que Firefox est tout simplement bon. Je dis ça sans méchanceté aucune ; j'ai moi même commencé un jeuavec un pote depuis des années, et je sais bien que personne ne s'y amusera avant longtemps (mis à a part nous à le faire !), parce que c'est long et difficile de garder la motivation. Je pense à des jeux de la qualité de Wesnoth ou Hedgewars par exemple.

On est loin de l'animation de sprite là :-) Mais sinon il ya SVG pour ça

Si tu as regardé mon lien tu as pu voir que j'adore le SVG (il n'y a pas beaucoup de tarés qui font leurs textures en SVG !); je travaille souvent en vectoriel même si le travail final doit être du bitmap (je dois être le seul à fournir ses sources SVG pour ses contributions à Hedgewars malheureusement). Je ne suis pas sûr qu'on puisse faire tout un jeu (un "vrai") rien qu'avec du SVG ; mais dans la pratique si je pouvais avoir les animations dans Inkscape ça serait déjà bien, parce que je les attends depuis longtemps !

Il existe aussi des outils de création de jeux complets comme Game Editor.

Je ne connaissais pas ça a l'air sympa merci.

Ok avec l'explication je comprends un mieux ta frustration. Ton commentaire m’inspire plusieurs réflexions :

• Je n'ai évidemment jamais dit que "ma" technique était la panacée. Ce n'est qu'un hack, mais parfois je pense qu'il faut être pragmatique et accepter de faire un hack en 3 minutes mais qui marche plutôt bien, même si le perfectionniste qui est en nous en prend un coup !

• Le format MNG me semblait pas trop mal (je ne le connais pas bien cependant), mais on ne peut pas dire qu'il soit très connu ou populaire.

• Avoir un outil d'animation commun serait évidemment très bien. Après, la création d'un jeu restera beaucoup de boulot et ce n'est que la partie émergée de l'iceberg. Un outil de création entièrement intégré (comme pour Flash) serait encore bien mieux ; et même la il y aurait toujours de quoi faire mieux etc... Tout ça pour dire que que n'est qu'un minuscule problème à mon avis (ce qui ne veut pas dire que ça ne vaut pas la peine de se pencher dessus hein).

• Malgré tout le respect que je peux avoir pour OpenGameArt, je crois malheureusement que pour les graphismes ce genre d'initiative n'est pas très efficace (mais j'espère me tromper) . Pour les sons ça marche bien, car primo depuis qu'on sait faire du son qualité CD on n'a plus vraiment de gros progrès technique à faire, deuxio même si avoir un set sonore spécifique est préférable, avec un set "réaliste" et un set "cartoon" génériques doit sûrement couvrir beaucoup de besoins. Mais pour les graphismes, la réutilisabilité est vraiment faible au final : si je cherche des modèles 3D très détaillés pour de l'heroic fantasy, des modèles 3D lowpoly de SF ou des sprites en 3D isométriques d'heroic fantasy ne me sont pas utiles du tout. Je ne connais pas de jeu libre vraiment abouti utilisant OpenGameArt.

• Une idée à la con : quelqu'un qui poste une image animée sur OpenGameArt, et qui a donc conscience du manque d'information de timing, pourrait toujours l'indiquer dans le nom du fichier, genre hero__100ms.png (il faut que le timing soit toujours le même entre les frames, mais c'est bien souvent le cas).

Désolé si je t'ennuie, je peux être loquace sur des sujets qui me passionnent. Bonne journée :)

Qu'est ce qui est lourd ?

Autant la technique de la grosse image avec toutes les resources d'un niveau est chiante à faire : il faut agencer les différentes frames de tailles différentes en gachant le moins de place possible. Mais cette technique est très dispensable et ce n'est pas celle que je te conseillais.

En revanche faire un sprite animé en 32x32 avec 4 frames avec une image de 128x32 (ou 32x128 peu importe) par exemple, c'est franchement pipeau, tant au niveau du code qu'au niveau du graphisme.

Au niveau des formats 3D c'est bien plus le bordel et la tout le monde fait un peu à sa sauce.

En plus il n'y a pas de canal aplha, donc tes sprites vont être tout aliasés. La technique classique consiste à mettre les différentes frames les une à côté des autres dans une image png, et le timing soit dans ton code s'il est toujours identique pour tes différentes animations, ou dans un autre fichier de resource pour faire plus propre. C'est fait comme ça pour les particules animées des décors de Hedgewars par exemple.

En 2002, j'ai fait un stage dans une boite de jeux vidéos (GameBoy et GBA principalement) et tous les sprites d'un niveau (donc N sprites pour une animation) étaient agencés dans une même grosse image PNG (c'est un outil interne qui pondait ladite png) ; c'est une technique ultra classique sur ces petites plateforme, et c'est peut être même une exigence (les sprites sont gérés en hardware et une partie de la mémoire leur est donc consacrée).

Je n'y connais rien en architecture, mais il semble qu'il existe des gens se servant réellement de Blender pour en faire. J'ai vu passé en effet passé des articles sur Blender en archi, mais à titre personnel des gens faisant de l'archi m'ont contacté pour savoir si je comptais porter mes scripts Blender2.49 vers Blender2.5X/2.6X.

Sinon est'il prévu une conception 3D volumique plutôt que surfacique (facettes) ? C'est quelque chose qui me manque beaucoup, je suis habité à travailler avec un logiciel de CAO et même si le rendu final est beaucoup moins bon que dans Blender je n'ai jamais a dire combien de faces à une sphère.

Blender a été dès le début pensé pour faire des films d'animation, et s'oriente donc vers de la 3D 'artistique' (et lorgne du côté de 3DSMax ou Maya par exemple, voire même ZBrush par certains aspects). Il est très versatile, et on peut se contenter d'utiliser une sous partie de ses fonctionnalités bien sûr, comme juste faire des rendus statiques, ou créer des modèles 3D pour des jeux. En revanche, il n'a jamais été destiné à faire de la CAO ; même dans le monde proprio on n'utilise pas 3DSMax et AutoCAD pour les mêmes travaux, car c'est assez différent au final.
Personnellement j'utilise Blender, et je n'ai pas eu l'impression qu'il s'alourdissait au fil du temps ; au contraire il y a quelques années les squelettes on été bien optimisé par exemple. Je suis avec un laptop de 2009 + CG Intel et ça roule pas mal ; bon après je ne fais que des modèles de quelques milliers de polygones.
Encore une fois ça ne remplace pas un outils de CAO, mais dans Blender quand on ne veut pas se soucier du nombre de facettes, on passe par exemple par des surfaces de subdivison (SubSurf) dont on peut préciser un paramétrage différent pour l'affichage temps réel et le rendu.

Au contraire, je pense que la comparaison avec le LL est plus intéressante si justement on utilise les différentes facettes du bio, le LL ayant lui même bien des facettes.
Par exemple :

• celui qui code sur son temps libre <=> celui qui a son potager bio dans son jardin qui fait profiter les amis.
• la petite boite qui fait du libre parce qu'elle aime le libre mais qui pense aussi que c'est économiquement viable <=> le petit agriculteur qui fait du bio parce qu'il en a marre d'empoisonner les gens et qui pense qu'il y a un marché pour ça.
• la grosse boite qui utilise l'étiquette "Open source" à l'occasion, qui respecte les licences libres, mais pas vraiment l'esprit qu'il y a derrière <=> la grosse boite qui fout l'étiquette "Bio" sur ses emballages parce que ça fait vendre.

Évidemment ma liste n'est pas exhaustive (il y a des petites boites d'escrocs, et des grosses boites à peu prés respectables etc...) mais l'idée est là.

J'aime bien le style graphisme typé NES, même si perfectible comme dit dans un autre commentaire. Le retro-gaming est bien dans l'air du temps ; j'avais vu des images d'un jeu indépendant (et dont le nom m'échappe), où au fur et à mesure des upgrades les graphismes passent du 8-bits monochrome style GameBoy au 8-Bits style NES, puis 16-bits etc... Vu le peu de sprites de GeneticInvasion ça serait imaginable.
On peut aussi imaginer avoir plusieurs front-ends. Si vous en faîtes un en 3D je veux bien faire vos graphismes (je me débrouille bien avec Blender).

Bonne continuation.

Avec ma 2ème solution (le Firefox tuné), on obtient une espèce de client lourd. Pour peu qu'on fasse tourner le serveur sur un port autre que 80 (pas sûr de toutes les façons que Python tournera avec le IIS périmé de rigueur, il faudra donc un serveur web à côté), et on obtient un ensemble qui n'est pas du web, genre client lourd, serveur dédié et protocole propriétaire ; même pas la peine de taper sur IE. Après tout dans ce genre d'entreprise les clients lourds propriétaires ont la cote je pense.

Nous n'avons jamais eu à mettre une telle solution en place, donc je ne vais pas te dire que ça passera auprès de tous les DSI, parce que je n'en sait rien. On travaille avec une boite de la grande distribution (mais sur un autre projet), et les décisions totalement illogiques sont légions ; aussi je ne vais pas me lancer dans de grande conjecture, tellement le hasard a l'air d'être la règle.

Et puis s'ils préfèrent payer plus cher pour avoir moins bien, et bien on va dire que ça fait tourner le commerce, même si ça ne me réjouis pas plus que ça…

En effet nos clients vont de TPE de 3 personnes à des PME de millers personnes, mais pas (encore) de grand compte. Mais là encore différentes solutions sont envisageables, en plus de faire payer au client les semaines à adapter Creme à son butineur préhistorique bien sûr. Par exemple :

• Firewall applicatif qui briderait Firefox pour qu'il n'aille que sur le Creme de l'entreprise (ça doit être possible, mais je ne suis pas spécialiste).
• On modifie un Firefox pour qu'il n'aille que sur Creme, on en profite pour cacher la barre d'adresse et on appelle ça CremeBrowser (nous l'avons déjà fait, avec Firefox Portable, sans renommer le programme toutefois).
• Utiliser ChromeFrame (et coder le peu qu'il faut pour que Creme passe nickel sous Chrome bien sûr).

J'espère que ma réponse t'éclaire un peu.

J'ai précisé ce point dans la dépêche pour éviter des désillusions aux utilisateurs n'ayant pas le choix de leur navigateur. Mais Creme tourne de mieux en mieux dans les navigateurs qui améliorent leur gestion des standards ; par exemple des comportements étranges dans Chrome ont ensuite disparu dans la version majeure suivante (soit 2 semaines plus tard :) ). Et même IE9 ne s'en sort pas trop mal, comme quoi...
Ceci dit, dans la pratique nos clients ne rechignent pas à installer Firefox, quitte à continuer à utiliser IE à côté. Peut-être cela posera-t-il problème un jour, mais le cas ne s'est pas encore présenté.

(désolé pour le temps de réponse je me suis pris la maintenance dans la tête et j'ai perdu mon premier commentaire)

...abrégé en LotR bien sûr (du coup le rapport avec les trolls devient encore plus évident).