GuieA_7 a écrit 675 commentaires

Tu évoques un sentiment de supériorité

Désolé si c'est l'impression que ça donne, mais ce n'était pas mon intention et je ne vois pas du tout de laquelle de mes phrases tu parles. Peux-tu préciser où ?

Rien n'empèche toutefois de redessiner un décor à sa sauce ou de s'inspirer du style d'un auteur.

C'est vite dit ; avec la tendance actuelle de tout verrouiller au nom de la sacro-sainte propriété intellectuelle (concept au final très récent à l'échelle de l'histoire—on créait déjà des tas choses formidables avant ça) notre système a au contraire des tas de façons de nous empêcher de faire des choses. Ce qui est stupide vu que la création pure n'existe pas, et les œuvres sont toujours ce qu'elles sont uniquement grâce aux œuvres précédentes (que l'inspiration soit consciente ou non, assumée ou non).

alors c'est qu'il considère que son décor est autant une partie intégrante de son travail que ses personnages.

Tu sors ma phrase de son contexte. Je parle des auteurs qui se réfugient derrière "mon personnage iconique reconnaissable par les enfants ne doit pas dire des horreurs" (et je propose de tester dans quelle mesure c'est un prétexte ou pas selon les cas), et tu m'expliques qu'il existe des auteurs qui vont dire explicitement "je ne libère rien c'est un tout" ; je le sais très bien mais en quoi ça nous avance ?

Certes, mais là se pose la question de la rémunération du travail […]

Il se trouve que j'ai posé la question de l'impact économique dans le premier commentaire de ce journal, donc oui je pense que la question est intéressante. Et la réponse de Boulet est "pas d'impact économique significatif".

Du coup l'aspect économique n'étant pas bloquant (selon lui), je m'intéresse à un autre aspect dans ce thread.

La plupart des artistes n'ont pas le melon suffisamment gros pour penser de manière aussi condescendante.

La plupart des artistes ne se sont sûrement pas posé la question du libre car le libre reste une philosophie/approche récente en ce qui concerne l'art. Mais ici on s'intéresse à ceux qui se sont posé la question.

Il y a aussi une distinction entre adapter à sa sauce des morceaux d'une œuvre (inspiration, hommage) et reprendre des bouts de travaux complets (plagiat).

Si un artiste A libère une œuvre #1 (c'est un acte volontaire) et qu'un artiste B réutilise ladite œuvre dans le respect de la licence libre pour créer une nouvelle œuvre, cette dernière est une œuvre collaborative avec pour auteurs A & B, et il n'est nullement question que ça soit caché. Ce n'est en aucun cas un plagiat, on modifie une œuvre pour en créer une nouvelle avec l'accord du créateur originel ; c'est le principe du libre.

Maintenant une licence libre peut être violée tout comme une licence propriétaire, cela n'est pas un problème spécifique au libre.

Le chara-design n'est qu'une partie de l'œuvre, pas plus importante que le reste.

Tout dépend de ce qu'on entend par "important".

Dans un précédant débat sur l'art libre (désolé j'aurai peut-être du plus expliciter), un argument contre le libre et qui ressemble à ce qui est dit plus haut sur la protection des marques était du genre:

"J'ai créé un super-héros, CastorMan, qui a des milliers de fans et qui véhicule des valeurs positives de tolérance et d'entre-aide ; je ne veux pas que des gens puissent profiter de la notoriété de mon personnage pour diffuser des messages haineux."

Du coup, de la même manière que Firefox protège sa marque (on ne peut pas prétendre être le FireFox officiel et surfer sur sa notoriété) mais ouvre au final tout le reste, je me demande dans quel mesure un artiste serait prêt à libérer tout ce qu'il y autour de ses personnages iconiques.

Évidemment que ça poserait des soucis en pratique de gérer des licence différentes pour les personnages principaux et pour le reste ; mais je trouvais que c'était une question "philosophique" intéressante à poser à un artiste qui serait dans cette optique. Par exemple s'il refuse théoriquement de libérer une case avec un décor "passe-partout" (sans les héros dont la libération poserait problème selon lui), alors c'est que cette histoire de protection de marque/héros est un prétexte.

Désolé si je n'avais pas été clair.

Tu as tout à fait raison, c'est potentiellement difficile de réutiliser des bouts d'une œuvre pour en faire une autre…

…mais ça ne change rien à mon propos. Dans le cas qui nous intéresse, l'approche libre c'est de dire "Voila mon travail, vous pouvez en faire ce que vous voulez [*], ça vous sera peut-être utile" ; et dire "je ne libère pas parce que de toute les façons ne vois pas comment vous pourriez vous en resservir" est juste un prétexte. Si c'est difficilement réutilisable tant pis ; toute la beauté de la chose est que si quelqu'un trouve une façon de s'en resservir, il le pourra. Par exemple, une case de BD avec un joli décor pourrait servir de (base à une) jaquette d'album de musique.

[*] dans les limites imposées par la licence évidemment.

Le libre n'est pas tout à fait à l'opposé de ça, non. Linux, Firefox, Libreoffice, Nextcloud, Dolibarr par exemple sont des marques déposées. C'est la même démarche que de protéger ses personnages.

Si demain les créateurs de Firefox ferment le code source en disant que le libre c'est intéressant mais qu'il faut bien qu'ils protègent leur marque, on ne pourra pas dire qu'ils sont favorables au libre et ne font que protéger leur image.

Boulet serait-il prêt à libérer ses scénarios et le graphisme des décors, et garder le graphisme de ses héros sous licence propriétaire, afin qu'on ne puisse pas se servir de son image pour porter un autre message tout en libérant un maximum de chose ? Seul lui a la réponse évidemment (je ne vais pas faire de procès d'intention), qui permettrait de savoir à quel point il est sincère.

Pour lui ça ne peut pas avoir d'impact significatif (à terme visible) sur la situation (catastrophique) des auteurs.

En même temps l'art libre, de même que le logiciel libre, n'a jamais eu la prétention d'améliorer la situation (financière on imagine bien) de leurs créateurs ; le libre concerne avant tout celui qui reçoit. Le vaccin contre le cancer ne va pas non plus améliorer la situation financière des auteurs de BD, ce n'est pas anecdotique pour autant…

La question est plutôt de savoir si, dans la mesure où le business model est différent, cela peut avoir un impact négatif sur leur situation ; et vu ce qu'il avait dit auparavant ça ne serait pas étonnant qu'il le pense. Car si ce n'est pas le cas ça veut dire qu'un auteur peut sans problème donner plus/mieux à son public.

Ne t'inquiète pas tu ne seras pas le dernier élève ingénieur à finir un projet avec des nuits de 4 heures de sommeil.
Si tu ne comprends vraiment pas ce qu'on te demande, alors une deuxième année te sera nécessaire, ce n'est pas honteux.
Et si tu bloques juste sur des points précis, alors reviens avec des questions précises ; savoir s'exprimer et expliquer des problèmes techniques fait partie du boulot d'ingénieur.

Bon courage.

Soit tu déclares ta fonction comme prenant un seul paramètre (un tuple) et tu l'appelles avec 1 seul paramètre:

def get_row_size(args):  # <=== pas de '*'
   # ...

get_row_size(sys.argv)

Soit tu déclares ta fonction comme prenant N paramètres, et tu l'appelles en "explosant" le tuple :

def get_row_size(*args):
   # ...

get_row_size(*sys.argv)  # <== remarque le '*'

Actuellement tu mélanges les 2, et ta fonction reçoit bien un seul argument (seul args[0] ne provoquera pas d'erreur, et sera un tuple avec tous tes arguments).

Quelques remarques:

• Ce n'est pas très propre que ton programme plante salement si on ne lui passe pas assez d'argument. Tu es censé faire un if len(args) > 3 avant de faire un args[3] par exemple.
• Comme vérifier tous les arguments c'est pénible, tu peux regarder du côté de argparse qui générera de belles erreurs et un message de doc sur les arguments
• Attention tu parles de "4eme élément" en écrivant args[4] ; il s'agit bien du 5ème élément (vu que les indices commencent à 0).

j'ai déjà utilisé des conditions pour arrêter la boucle principale et commencer la boucle draw mais je crois que c'est pas la bonne solution

En effet ce n'est pas la bonne approche ; il suffit d'imaginer que tu veuilles avoir plusieurs sprites animés en même temps, et que le joueur puisse continuer d'interagir pendant ces animations (exemple: un vaisseau ennemi explose pendant que tu continues à diriger le tien) pour voir que ton approche ne fonctionne pas du tout.

Pour chacun de tes sprites tu dois avoir, d'une manière ou d'une autre, un machine à états finis (exemples d'état pour un personnage: attente, marche, saut, touché…) ; pour chacun des états tu vas avoir une animation[*] , qui peut être cyclique (ex: marche) ou pas (ex: mort). Dans les informations liées à ton sprite, tu stockes à quelle frame de ton animation tu te trouves, ainsi que le timing du moment où tu as commencé à afficher cette frame.

Ta boucle principale va continue à tourner à l'infini, demander à tous tes sprites de se draw(). Pour chaque sprite tu vas regarder si le temps depuis l'affichage de la dernière frame est suffisamment grand pour passer à la frame suivante. Par exemple, si tu fais du 60 images par seconde, et que la frame précédente date de plus de 1/60 secondes, tu passes à la frame suivante de son animation.

Note que l'état de tes sprites va conditionner d'autres choses que simplement leur animation ; par exemple si ton personnage est dans l'état "marche" et que le joueur appuie sur le bouton de saut, le personnage passe dans l'état "saut" ; mais s'il était déjà dans l'état "saut", ça ne fera rien (s'il n'y a pas de double saut évidemment).

J'espère avoir été clair.

[*] une liste d'images donc. En générale ça sera plutôt une seule image (sprites sheet) avec les différentes étapes (frame) de l'animation côte à côte, et selon l'étape de l'animation tu n'affiches que la sous-partie de l'image qui va bien.

Tout à fait, et je me suis bien gardé de vendre du rêve avec un hypothétique langage 100% sécurisé. Mais la meilleure solution (pas parfaite évidemment) reste la diversité ; qu'on n'utilise pas tous le même noyau sur le même processeur, avec la même libC compilé avec le même compilateur, la même bibliothèque cryptographique ou le même algorithme de chiffrement. Donc avoir, par exemple, des logiciels en Ada sur OpenBSD/PC, et d'autres en Rust sur Linux/ARM, ou en Haskell sur Haiku/Power9. Rien qui n'évite les catastrophes certes, mais rien qui ne suggère que 99% et 1% soit la même chose.

Le problème c'est qu'il est très difficile, même pour des programmeurs compétents, de faire un logiciel un tant soit peu ambitieux en C sans qu'il y ait dedans des erreurs mineures ayant des conséquences majeures (buffer overflow et compagnie).

Si tu as 99% de chances d'avoir des failles de sécurité avec un langage, et 1% avec un autre (toutes choses étant égales par ailleurs), alors dire que ça revient au même car des failles sont possibles dans les 2 cas serait loin d'être très pertinent.

Très bonne dépêche. J'attends la suite avec impatience.

PHP n’est pas un problème la plupart du temps : PHP est rapide, vraiment rapide ; la plupart des optimisations que j’ai obtenues étaient liées à la façon dont je gérais les flux et leur contenu ainsi qu’aux requêtes dans la BDD ; passer à PHP 7 puis aux versions suivantes a un peu amélioré les performances, mais le gain a été négligeable par rapport à ce qui a découlé des autres changements réalisés dans le code.

Du coup je dirai plutôt "PHP est lent, mais ce n'est pas forcément un problème/visible" (et c'est pareil pour Perl/Python/Ruby…). Même si un bout de code pourrait être potentiellement 100 fois plus rapide, ce n'est pas gênant s'il s'exécute "instantanément". Comme tu le dis c'est surtout l'architecture qui va être prégnante dans bien des cas (comme ici).

J’ai l’impression que beaucoup de projets accordent trop d’importance au principe DRY — Don’t Repeat Yourself). Parfois il n’est pas nécessaire d’importer une bibliothèque entière, écrire une fonction qui correspond exactement à la situation peut faire l’affaire. Il est préférable de garder aussi peu de dépendances que possible.

Le fait de choisir de se lier à une bibliothèque ou d'écrire une fonction spécifique n'a rien à voir avec le "Don’t Repeat Yourself" (qui va consister à trouver et factoriser les motifs récurrent de ton code). Tu parles peut-être de "Not Invented Here" ?

et peut‐être la plus importante de toutes : Keep It Simple!

Ça c'est une réflexion personnelle ; une chose me dérange avec l'expression KISS, c'est que c'est très subjectif. Des tas de gens s'en réclament, tout en lui faisant dire des choses très différentes. C'est un peu comme se réclamer d'utiliser "le bon sens" ; au final tout le monde pense avoir le bon, et pourtant tout le monde ne pense pas pareil.

Par exemple, tu n'as pas mis en place l'architecture la plus simple possible (ce qui selon une certaine interprétation du KISS serait une violation du principe) ; tu as créé une architecture suffisamment complexe pour que ça marche bien en fonction des critères qui te semblaient importants (performances, sécurité…). Après on est d'accord, avoir un code le plus simple possible pour un niveau de fonctionnalité donné est clairement une vertu.

Si les experts pour un outil sont déjà rares et concentrés dans peu de boites, la mutualisation est plus ou moins déjà faite! Il ne reste que les bénéfices des actionnaires, ce qui représente moins qu'on l'imagine, du coup il y a peu à gagner économiquement parlant et les clients ne veulent pas devenir gestionnaires de projets logiciels.

C'est vrai, mais reste le risque qu'avec un unique logiciel propriétaire dans un domaine, que l'éditeur se mettent à augmenter les prix des licences sans aucune "vraie" raison (il le peut, c'est tout, car les clients/utilisateurs sont dépendants). Et plus le logiciel va être vieux/gros/complexe/puissant, plus l'écriture d'un logiciel concurrent (et éventuellement libre) va être compliqué, car il va falloir beaucoup d'effort et de temps pour être au niveau, et donc la dépendance va se renforcer au fil du temps.

Il me semble que c'est plutôt pour faire des interfaces de jeux vidéos (donc plutôt à l'intérieur d'un contexte OpenGL par exemple) plutôt que des interfaces classiques de bureau.

Ceci dit les TK classiques (Qt/GTK/…), le Web (où l'IHM est un document qu'on va manipuler par JS) et les jeux vidéos se sont beaucoup inspirés les uns des autres. Par exemple, dans les TK on a vu apparaître des scene graphes inspirés directement du jeu vidéo.

Du coup, on peut imaginer un TK qui permette à la fois de faire des applications classiques de bureau et faire son rendu dans un contexte 3D (en fait ça c'est déjà possible), et qui soit suffisamment puissant pour faire des applications de bureau complexes (ex: LibreOffice) tout en permettant de faire des Widgets avec des rendus très fantaisistes et des animations poussées. Et là pour le coup ça n'existe pas à ma connaissance, et ce n'est peut-être pas possible de faire un tel grand écart de manière satisfaisante. L'avenir nous le dira peut-être.

J'ai hésité à en parler car c'est, il me semble, pour le moment uniquement pour Redox, donc très confidentiel, et donc difficile d'avoir des retours sur sa qualité.

Mais au final c'est bien que tu l'aies cité.

Oui, c'est interdit de base, mais c'est faisable avec un peu de unsafe. En pratique c'est fait par la bibliothèque standard qui fournit moult collections/algorithmes (là où par exemple celle de Go va plutôt fournir des outils haut niveau pour web, mail etc…) qui vont se charger de ça (à savoir faire le très peu de unsafe nécessaires pour avoir de bonnes performances) et du code classique sera bien souvent avec 0 bloc unsafe.

J'aimerai aussi voir un ToolKit de GUI native écrit en Rust ; peut-être pourrait-il utiliser une approche différente de ce qu'on trouve en Qt/GTK. Non pas parce que ce sont de mauvais projets, mais parce que si c'est pour avoir la même approche, autant juste avoir des bindings.

Je ne sais pas quel est l'état du binding GTK pour Rust, mais en l'occurrence quand je m'y intéressais au final pour une GUI en Ada, le mieux était aussi son binding GTK ; ce qui ne remet pas en cause l'utilisabilité de Ada pour autant.

En revanche depuis le temps, mis à part l'IDE libre pour Ada (Gnat), je n'ai jamais croisé de programme de bureau en Ada ; là encore ça ne remet pas en cause les grandes qualités du langage. Mais vu son âge, il y a peu de chance que cela change ; parce qu'il a largement eu le temps de devenir populaire, et que ça n'est pas arrivé (que ce soit pour de bonnes ou de mauvaises raisons).

C'est la force de Rust d'avoir réussi à faire collaborer l'approche fonctionnelle de OCaml/Haskell (pour le typage entre autres) avec une gestion fine des ressources (potentiellement bas niveau). Cette dernière va venir d'autre langage comme Cyclone (l'emprunt de référence notamment) ou C++ (les réflexions sur les closures dans les dernières versions ont été suivies de près par la communauté Rust ; principalement sur la politique de capture de l'environnement—copie contre référence). On trouve d'autres inspirations, et c'est une bonne chose que d'être aller chercher les qualités un peu partout ; par exemple python a inspiré certain élément de syntaxe. Donc le changement de paradigme n'est pas la seule chose importante ; sinon Ocaml avait déjà réussi à unifier impératif et fonctionnel.

À noter que l'inspiration va dans les 2 sens ; par exemple ce papier sur une possible gestion des ressources dans les langages fonctionnels (ici testée dans Ocaml) :
http://lambda-the-ultimate.org/node/5511

j'ajouterai que pour certains Rustafariens, la principale intérêt de faire du Rust ne vient même pas du langage lui-même mais de son environnement, avec cargo et crates.io.

Force est de constater qu'ils ont joué exclusivement avec des distributions "pré-machées" et […]

En même temps s'il y a (c'est un exemple) 100 fois plus d'utilisateurs de Debian que de Slackware, il n'y a rien d'étonnant à ce qu'il y ait 100 fois plus d’incompétents sous Debian. Il y aura aussi 100 fois plus de projets cool basés sur Debian, mais ça tu le mettras sous le tapis car ça ne sert pas ton propos…

Je suis contre l'idée d'une note (et encore plus de seulement une note), mais plutôt une liste de points factuels et vérifiables. Les notes sont pratiques car très synthétiques, mais elles cachent en effet beaucoup trop les nuances sous-jacentes, et vont alors être bien souvent trop subjectives.

Ça serait sûrement perfectible (qu'est-ce qui ne l'est pas ?), mais on nous a parlé de boites qui ne fournissent pas de makefile ou cachent des dépendances propriétaires (ce qui dans mon échelle de valeurs libriste est plus grave que les chemins en dur, pour reprendre ton exemple), mais on attend toujours des exemples.

Je me suis peut-être mal exprimé ; ou tu as lu trop vite. Je réessaie.
Il y a sûrement des gens qui font plus ou moins semblant que faire du libre (ou dont les pratiques derrière annihilent au moins une partie des 4 libertés). Ça serait une bonne chose d'avoir une liste de ces mauvais acteurs.

L'idée n'était pas de taire ces noms (vu que je demande moi aussi des exemples) pour ne pas faire peur aux décideurs, mais plutôt d'avoir une liste de logiciels/boîtes à éviter (liste qui pourrait servir entre autres à rassurer des décideurs sur leur choix, qu'ils viennent eux-même ici ou pas).

J'avoue j'aimerai aussi des exemples concrets. Certes en faisant attention à ce qu'on dit (pas de procès d'intention), j'aimerai éviter aux admins LinuxFR le stress d'une nouvelle mise en demeure, mais des exemples de softs avec des pratiques douteuses à priori constatées.

Parce que c'est déjà difficile de faire passer le message du "logiciel libre c'est bien" aux décideurs ; mais si en plus on rajoute un "attention il y a des arnaques, mais vous devrez vous plonger dans la technique pour les débusquer", ça rend la chose impossible.

Et enfin, j'aurais envie de m'attarder sur le côté théorique plutôt que pratique. Trio propose un nouveau paradigme de programmation, une évolution. Ce n'est pas lié à Python, même si sa proposition concrète est faite avec. Mais qu'est-ce que ça peut donner dans d'autres langage ? Après tout, certains langages possèdent suffisamment de souplesse pour obtenir peu ou prou le même résultat.

Comme dit dans l'article de base, le concept appelé 'nursery' dans Trio n'est pas complètement nouveau (Trio apporte cependant quelques subtilités/variations), et se retrouve plus ou moins ailleurs. Il y a par exemple la lib Rayon pour Rust qui adopte un peu la même approche je crois.

Edit: c'est au commentaire de Glandos que je voulais répondre.

C'est bien le problème ; c'est souvent une mauvaise idée, mais pas toujours. Aussi il vaut mieux dans un premier temps rester sur quelque chose de haut niveau ; d'autant plus que les langages essaient de garder la compatibilité et donc enlever une fonctionnalité utilisée par plein de programmes n'est pas forcément possible (donc on doit garder une erreur de conception ad vitam). Mais à l'usage on voit bien que des entraves aux contraintes s'avèrent "nécessaires" (puisque les performances peuvent être une fonctionnalité).

Par exemple en Rust les contraintes haut niveau amènent des garanties mémoires qu'on n'a pas en C, et certaines optimisations deviennent alors possibles (le compilateur C ne peut pas prendre certaines décisions optimisantes car il pourrait créer des bugs). Mais à côté de ça on a les blocs unsafe qui permettent dans de rares occasions de faire des optimisations qui seraient vues comme des erreurs par le compilateur. Il est évidemment conseillé de s'en servir le moins possible  ; et au final c'est surtout les libs de base (genre les collections) qui vont s'en servir, les programmes classiques s'en passent très bien.

Dans l'absolu tous les langages ont ce genre de déverrouillage des contraintes, vu qu'ils permettent tous de s'interfacer avec du code C. C'est bien souvent pour pouvoir réutiliser du code (ça aurait été faisable dans le langage haut niveau, mais ça prendrait des ressources), mais c'est c'est souvent assumé qu'on va faire une partie critique au niveau performances en C (ou C++, Rust etc…).

Tout à fait. Mais après le diable se cache dans les détails ; sinon antre 2 langages avec la même approche (ex: impératif objet, fonctionnel pur…), celui plus haut niveau serait toujours intrinsèquement le meilleur. Mais pour des questions de performances notamment, ce n'est pas vraiment le cas [*]. L'article en parle lorsqu'il dit que break/continue on été ajoutés à l'idée de base des for/while ; et de même manière ce genre de compromis arrive dans sa propre bibliothèque.

Donc on sait que dans l'absolu on peut toujours faire mieux en rajoutant de la sémantique ; mais il y a une infinité de façon de le faire et reste a trouver les meilleures façons (ce qui est donc difficile).

[*] en pratique on va essayer quand même essayer d'écrire le plus possible dans le langage de plus haut niveau.

J'ai lu l'article de base de l'auteur de Trio il y a quelques jours et je pense qu'il va influencer ma pensée pour le reste de ma vie de codeur. Ce n'est pas tellement la présentation de Trio qui est importante (la lib est sûrement très bien, ce n'est pas la question) mais la réflexion de fond sur la conception des programmes.

C'est très amusant de voir comment l'instruction GOTO est passé d'indispensable ("si on met des contraintes dessus on limite la conception") à inutile/dangereux (les structures de contrôle ajoutent certes des contraintes mais en fait apportent de nouvelles perspectives) ; et que pour la programmation concurrente on en est encore dans la phase 1 (on va naturellement penser que les contraintes vont être des limites).