GuieA_7 a écrit 695 commentaires

Je ne sais pas si c'est de la bêtise ou de la méchanceté (les 2 n'étant pas mutuellement exclusifs), mais tes commentaires sont vraiment toxiques.

J'imagine que cracher sur le travail des autres ça t'aide à te sentir malin. C'est sûr que c'est plus facile que de venir nous présenter ton propre travail ; toi qui fait sûrement passer l’intérêt des utilisateurs avant le tien (et ce même lorsque c'est sur ton temps libre évidemment), ça doit être bien pourtant. Mais je suis à peu près sûr que ça n'arrivera pas…

(et oui désolé linuxfr je ne t'ai pas écouté et j'ai nourri le troll)

On fait ça ! Cela sera l'occasion de savoir qui tes enfants ont le plus écouté, Nabila ou toi. Qui sait, tu pourrais être agréablement surpris :)

on peut citer […] Enlightenment dont les dev sont à l'écoute des besoins des utilisateurs

Va vraiment falloir retrouver et tabasser les utilisateurs qui ont demandé à ce que E17 sorte avec 10 ans de retard et sans appli :)

Bon j'aurai sûrement beaucoup de choses à répondre, mais comme on semble au final tout à fait d'accord, cela serait inutile.

Juste une chose : les gens de ma génération on toujours vécu en entendant "c'est la crise" ; alors pour nous au final cela ne veut pas forcément dire grand chose. Il est normal que tu t'inquiètes en voyant tes enfants vivre dans un monde où trouver du travail (par exemple) est bien plus difficile qu'à l'époque où toi tu as commencé.

C'est fondamentalement humain que tu vois en premier lieu ce qu'on a perdu, et que ce qu'on a gagné soit juste du bonus. Mais au final je pense que la plupart des gens [*] ont en fait toutes les cartes en main pour vivre heureux, mais qu'il faille faire l'effort de s'en rendre compte. Les média en véhiculant l'image que la "réussite" (j'ai vraiment horreur de ce terme) ça soit l'argent facile et rapide et la célébrité ont à mon avis une grande part de responsabilité dans ce problème ; mais je refuse de tout leur mettre sur le dos car chacun a aussi la possibilité de réfléchir par soi-même, et donc c'est la solution de facilité de dire "c'est leur faute ils ont qu'à dire des trucs intelligents pour que nous n'ayons pas besoin de réfléchir".

[*] parce que oui évidement qu'il y a de la vraie misère en France. Mais les vrais miséreux, même s'ils seront toujours trop nombreux ne sont heureusement que très peu. Beaucoup de pauvres ont un logement avec l'électricité, l'eau courante, un frigo pas trop vide, Internet, une télé… Si les richesses étaient mieux réparties (et c'est le problème) leur vie n'en serait que meilleure certainement, mais on est (heureusement) bien loin des 'Misérables', et les gens ont au final bien trop à perdre pour prendre la fourche et le fusil et faire la révolution (je ne veux surtout pas dire "y a des gens qui meurent alors taisez vous", juste "ce n'est pas grave si à 50 ans vous n'avez pas une Rollex" :) ).

Y a vraiment encore ici des gens pour tenir ce genre de discours digne du bistrot du coin ? (à moins que ça ne soit de l'humour ; si c'est le cas désolé)

Je pense qu'il y a 3000 ans les vieux disaient déjà des plus jeunes qu'ils étaient stupides/fainéants/superficiels/…

Alors que bien sûr tous les gens de ta génération sont intelligents/travailleurs/honnêtes ; du coup c'est à se demander pourquoi la planète est dans cet état.

j'ai 34 ans (j'imagine tu en as un peu plus), et déjà à mon époque la plupart des gens se passionnaient pour des trucs stupides de jeunes et des people à 2 balles. Et désolé mais à l'époque Sheila et compagnie c'était pas non plus super intellectuel. Et dans ma famille ceux qui consomment le plus des ragots people, ce sont des personnes âgées (je doute que ça soit les lycéens qui fassent vivre 'France dimanche'…).

Tu as visiblement choisi ton confort et celui de ta famille comme principale priorité, et il n'y a vraiment rien de mal à ça (devine quoi ? la plupart des gens font ça). Mais du coup, en tant qu'informaticien, si tu trouves que les boites d'informatique sont toute naze, et bien c'est aussi de ta faute ; pas entièrement de ta faute évidemment, ta faute de manière infinitésimale, mais non nulle. Si tous les informaticiens comptent sur le fait que d'autres montent des boites par exemple, et bien ce sont effectivement des non-informaticiens qui montent des boites (des financiers par exemple). Et de la même manière que toi tu ne joueras pas l'avenir de ta famille sur un coup de poker en changeant de travail, et bien personne ne va venir monter une boite à 200 mètres de ta maison et te proposer de doubler ton salaire pour un travail à mi-temps sur un passionnant logiciel libre.

Voila j'ai créé la fiche sur alternativeto.net (une belle façon de passer son samedi matin :) ). Elle est en attente de validation.

Je précise tout de suite, je suis le développeur principal de CremeCRM, histoire qu'il n'y ait pas d’ambiguïté.

Mon collègue/associé/ami a récemment mis à jour le tutoriel pour pouvoir installer la dernière version (la 1.5 pour laquelle je n'ai pas encore pris le temps de faire une dépêche…):
http://www.cremecrm.com/forum/viewtopic.php?f=14&t=617&p=886#p886

Autant installer Creme n'est pas forcément complètement trivial, autant le tutoriel détaille même l'installation de Django. Si tu n'arrives toujours pas à installer Django avec ça, il faudra se poser des questions ! :)

le CRM doit être sous licence GPL;

Affero GPL v3.
Il n'y a pas de version communautaire opposée à une version commerciale ; tout est libre.
En fait on va même plus loin puisque même si tu choisissais d'utiliser notre version SaaS, tu peux récupérer quand tu le souhaites ton code ET tes données ; on peut aussi installer sur ton propre serveur par exemple.

le CRM ne doit être qu'un CRM et le faire bien (ce qui correspond à la philosophie UNIX sur les logiciels, donc "exit" les solutions ERP proposant un module CRM)

C'est le cas ; bon après CRM ça peut vouloir dire beaucoup de chose. Par exemple entre un CRM pour les TPE et un CRM pour les grands comptes il va y avoir un grande différence, et je pense qu'il va falloir un peu préciser tes besoins pour trouver le CRM de tes rêves de toutes les façons.

si possible, mais ce n'est pas une obligation, avoir des applications ANDROID et iOS pour y accéder à distance

En temps que webapp, Creme a toujours été accessible depuis les mobiles. Mais comme ce n'était pas forcément aussi confortable que possible, la 1.5 vient avec une interface pour les téléphones (qui n'empêche pas d'accéder à l'interface classique) (mais pas de version déconnectée si c'était la question):
http://www.cremecrm.com/forum/viewtopic.php?f=14&t=614

l'interface doit être traduite en français;

C'est le cas.

Si tu as des questions, il y a notre forum ou même notre chan IRC (#cremecrm sur Freenode).

Bon week-end !

mais oui Windows est une daube à côté.

Je trouve ça assez "dangereux" ce genre de propos. Alors oui les Windows 9*/millenium étaient des gros tas de boue plantogènes bien loin de l'état de l'art ; ceci dit les desktops Linux de la même époque, même s'ils s'appuyaient sur un noyau de qualité n'étaient pas vraiment assez conviviaux pour être confiés à M. et Mme Michu (des années plus tard je devais encore recourir très souvent au terminal et je ne parle pas de développement) ; certes microsoft avait déjà un budget conséquent, mais si ce n'est pas vraiment la question.

De nos jours, d'un côté comme de l'autre on a un OS qui plante rarement et un environnement perfectible mais qui fait à peu prêt son taff. Alors oui j'utilise exclusivement (personnellement et professionnellement) Linux depuis plus de 10 ans, et j'en suis très content, mais quand j'ai sauté le pas c'était pour avoir un système libre (et de qualité), pas un système qui soit intrinsèquement supérieur à tous les niveaux (parce que ce n'est pas le cas).

Du coup si tu dis à des gens qui utilisent windows, et pour qui ça marche plutôt bien, que c'est de la daube à côté de Linux, ils vont s'attendre à débarquer dans un monde merveilleux, qui fait tout au moins aussi bien que windows (sur tous les points, même ceux qui ne dépendent pas vraiment de Linux) sans les trucs qu'ils n'aiment pas. Et du coup ils courent juste à la grosse déception.

Et après ils viennent pleurer ici en majuscule :)

Enfin, Ogre3D v2.1 à refondu la gestion du matériel (au sens 3D, pas au sens matériel de l'ordinateur)

En fait ce que tu appelles "matériel 3D" s'appelle plutôt "matériau" (métal, bois, pierre…) donc pas de confusion possible.

Si tu es un novice en programmation tout court, je te conseillerai dans un premier de ne pas chercher à découper ton code en plusieurs fichiers, et plutôt à comprendre les notions fondamentales (variables, types, structures de contrôle, classes, fonctions …), quitte à d'abord tout mettre dans un seul fichier. De toutes les façons tes premiers programmes seront très simples, et tu ne vas pas te lancer dans quelques chose de trop ambitieux sans avoir bien compris les bases.

Mais bon revenons à ta question, qui nécessite quelques explications préliminaires:

Lorsque tu fais import foo, 'foo' doit être :

1. à l'endroit où sont présents les libs Python de ton système.
2. dans le même module que ton fichier courant.

Pour connaître les chemins où va chercher python tu peux faire dans une console python:

import sys
sys.path

En fait le problème du point 2, c'est qu'un de tes propres fichiers peut masquer un module standard (ex: tu crées un fichier 'math.py'). C'est pourquoi à partir de Python3, la façon 2 disparaît, et tu peux du coup faire :

from math import cos # la c'est la lib standard
from .math import ta_fonction_a_toi # ton propre math.py

Note que tu peux utiliser ce comportement en Python2 en mettant from __future__ import absolute_import au début de tes fichiers.

Attention si tu veux utiliser des imports relatifs ('from .math import ') tu devras lancer ton script avec l'option '-m' (et sans le '.py') pour le considérer comme un module.

Du coup pour ta question, et ben soit :

• tu mets complement/ dans le même module.
• tu le mets avec les libs installées classiquement (genre dans ton virtualenv histoire de pas péter ton système).
• tu modifies l'environnement Python (ce que fait virtualenv au final), genre comme ça.

Il y a quelques années on associait me semble-t-il généralement Perl6 avec la VM Parrot. Ce n'est visiblement plus le cas ; en allant sur leur site, il semble pourtant que le projet soit encore bien actif, avec une 7.4.0 sortie il y a 15 jours. Bien que je n'ai jamais trop cru en ce projet, je le trouvais quand même intéressant.

Quelqu'un aurait-il des informations sur la relation entre les 2 projets du coup ?

Fichier __init__:
Ce fichier est présent dans tous les répertoires qui doivent être identifiés comme des modules python (je crois qu'on peut s'en passer dans les dernières versions de Python3).

Imaginons tu aies un un module de dessin gfx.py ; avec le temps celui-ci grossit pas mal et tu veux le découper ; tu crées alors un répertoire gfx/ dans lequel tu mets un __init__.py, et les autres fonctionnalités découpées (circle.py, square.py …). Le code présent dans __init__.py sera exécuté dès lors que tu vas faire un import gfx
Si tu veux accéder au code de dessin tu pourras faire (entre autres):

from gfx import foo # ca c'est pour le code dans gfx/__init__.py

from gfx import square # ensuite tu pourra faire square.Square(...)

from gfx.square import Square # ensuite tu pourra faire Square(...)

L’intérêt de mettre un from square import Square dans gfx/__init__.py c'est de pouvoir écrire directement :

from gfx import Square

L'idée étant de remonter les symboles les plus utiles par exemples, mais ce n'est pas du tout obligatoire.

chaque developpement python , faut il créer un environnement virtuel ou c'est crée directement par python ?

Je ne suis pas sûr de comprendre la question. De base Python va utiliser l'environnement de ton shell, et va alors chercher les libs installées par ta distro (ou 'pip' lancé sans virtualenv). Le problème c'est quand les libs fournies par ta distro n'ont pas la version que tu souhaites ; ou pire que tu veux faire cohabiter des softs utilisant des versions différentes des mêmes libs. Du coup ça dépend que ce que tu veux !
Si tu veux utiliser/suivre les versions des libs de ta distro (pour être inclus un jour dedans par exemple), ben tu ne vas pas utiliser de virtualenv pour ton soft. Si tu t'en tapes et que tu veux des versions plus récentes, alors oui un virtualenv sera sûrement indiqué (histoire de ne pas foutre la grouille dans ton système). Et si tu distribues ton soft, donne au moins le moyen d'installer les bonnes versions des libs (fichier requirements.txt que tu peux donner directement à manger à pip).

y a t-il une difference entre windows et linux en dev

Il me semble que faire des virtualenv sous windows est encore un peu compliqué, mais que ça évolue dans le bon sens. Et sous windows il faudra un peu de taff pour avoir un shell/terminal de qualité ; de plus, en pratique un certain nombre de packages Python ne sont pas testés sous windows, ou ne marche pas du tout avec (mais ce n'est pas une majorité hein).

Oui évidemment, je citais C++ pour l'exemple.

La "solution" adoptée par un certain nombre de langages (ex: Java, C#) va être d'interdire tout simplement l'héritage multiple ; ça évite de tomber sur le problème, mais du coup ça prive aussi d'un outil qui peut s'avérer puissant. Je n'ai pas vraiment d'avis sur le fait que cela soit une bonne ou une mauvaise solution.

De la la même manière la "solution" de Rust au problème est de mettre une restriction, en s'appuyant visiblement sur des écueils rencontrés avec Haskell. Il s'agit la aussi d'un compromis (un peu comme toujours en technique certes).

mais la problématique est bien : quelle méthode sera appelé en cas de double définition

C'est en ça que je trouvais que sémantiquement ça se ressemble. Mais mon commentaire était vague c'est vrai.
Je crois qu'on est d'accord en fait.

Ça explique tout merci.
Dans l'esprit ça ressemble au problème des héritages en diamant de C++ par exemple.

Merci à vous 2 pour vos réponses de qualitay.

Allez zou distribution de +1

Il me semble que seules la crate définissant WordCount et la crate définissant String pouvaient implémenter le trait pour String, tout autre crate n'en a pas le droit.

Si c'est le cas, alors je me suis un peu emporté ! À vérifier donc.

Par contre tu peux bien implémenter WordCount pour un type défini dans ton propre code.

Ah ben oui forcément, sinon ça va être difficile de faire des API ! Parce que définir dans ton code une classe avec une interface d'un autre package c'est un peu le truc de base.

La subtilité étant de pouvoir étendre des types définis ailleurs (comme bool), vu qu'étendre ses propres types ça tombe sous le sens.
En revanche oui, à vérifier si on peut étendre dans C un type défini dans A avec un trait défini dans B, j'ai peut être dit des bêtises pour ce cas ; le lien que j'ai donné au dessus (sur http://blog.rust-lang.org) ne parle pas d'une telle restriction, mais ce n'est pas une documentation exhaustive non plus…

Oui tout à fait, mais les traits vont quand même un cran plus loin.

Les méthodes d'extensions comme les traits permettent de dire : à partir de maintenant, les String ont la méthode wordCount() ; sans cela tu devrais, dans ton code, appeler une méthode statique prenant une String en paramètre (d'ailleurs comme l'explique ton lien il s'agit principalement de sucre syntaxique qui fait cet appel statique à ta place).

En revanche, les traits permettent aussi de faire la chose suivante :
si un code tiers définit le trait WordCount (ayant une méthode wordCount()), ainsi que des fonctions manipulant des objets implémentant ce trait, je peux dans mon propre code dire que les String (définies dans la bibliothèque standard que je ne peux/veux pas modifier) implémentent ce trait, et donc appeler les fonctions de ce code en lui passant directement des String. Ce n'est pas possible en C# de dire que maintenant String implémente l'interface IWordCount.

En C#, tu devrais soit :

• dériver de String dans une classe WordCountableString (bon en l'occurrence les String ne sont pas dérivables en C#, mais avec une autre classe ça aurait pu être une possibilité).
• créé une classe proxy WordCountableString qui wrappe un objet String.

Mais du coup si du code tiers te génère des objets String, tu devras construire un objet WordCountableString correspondant pour pouvoir les passer aux méthodes attendant des IWordCount ; ce qui alourdit à la fois le code et l'exécution (à cause d'objets supplémentaires 'inutiles').

Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).

À moins que je n'ai pas compris ce que tu voulais dire, tu te trompes. Dans ce très bon lien sur les traits (que j'avais déjà donné plus haut) on peut lire :

Unlike interfaces in languages like Java, C# or Scala, new traits can be implemented for existing types (as with Hash above). That means abstractions can be created after-the-fact, and applied to existing libraries.

Il faut certes déclarer explicitement que le type existant implémente bien ton propre Trait, mais il n y a pas besoin de modifier la bibliothèque standard pour ça, tu le fais dans ton propre code.

Ok merci pour ta réponse ça explique bien des choses.

OpenRTS est 100% original (pas de risque de conflit avec une licence existante), et sa licence MIT ne l'oppose pas à un usage commercial.

• Spring a depuis longtemps laissé tomber le 'T.A.' de son nom, donc je pense qu'un studio qui lui adjoindrait des assets originaux n'aurait aucun risque de conflit de licence je pense.
• Attention à ne pas opposer libre et commercial. Un jeu peut tout à fait être libre et commercial. Il peut aussi avoir un moteur libre (sous licence GPL par exemple dans le cas de Spring), des assets propriétaire et être commercial. Après on est bien d'accord une licence MIT sera sûrement plus attractive en pratique, les studios rechignant classiquement même s'il faut juste libérer leur moteur.

Je n'ai jamais prétendu le contraire ; C++ évolue sans casser la compatibilité et c'est très bien au vue du nombre de logiciels écrits en C++. Mais du coup C++ se traînera toujours certains boulets, malgré toutes ses évolutions.

Rust apporte une solution à bon nombre de ces boulets ; ça ne veut pas dire qu'il est parfait. On peut même être sûr que s'il est toujours utilisé dans 30 ans (ce qui n'est pas gagné encore une fois), on aura largement eu le temps de lui déceler des tas de boulet à lui aussi.

Après tu as tout à fait le droit de douter de l'intérêt de Rust. Mais les arguments à base de "C++ c'est utilisé depuis 30 ans dans des millions de logiciels nananère" ne sont pas franchement très intéressants. Oui c'est vrai la popularité de C++ est un avantage sur tous pleins d'aspects ; mais bon ici on est sur linuxfr, on en connaît plein des logiciels géniaux qui ne sont pas hyper connus, mais qui arrivent à vivre depuis longtemps (tout le monde ici connaît Blender , pourtant c'est loin d'être le cas de tous les graphistes).

Je n'ai vu personne sur le thread dire qu'il fallait réécrire tous les logiciels C++ en Rust ; et pour une bonne raison c'est que ça serait stupide. En revanche pour un nouveau logiciel (et des logiciels libres qui manquent ben y en a des tas), cela peut être un choix intéressant.

En fait depuis le début j'ai l'impression que quand les gens écrivent "Rust est peut-être le C++ du futur", tu lis "le C++ c'est de la merde, et les devs C++ sont des idiots" : ce n'est absolument pas le cas ! Les créateurs de Rust ont beaucoup pratiqué le C++, l'aiment et suivent de près ses évolutions ; ils sont confrontés aux mêmes problèmes, et les solutions du C++ sont très réfléchies.

Déjà bravo pour le travail accompli ; il y a un mois j'avais vu passé le projet sur FreeGamer, et la vidéo de l'éditeur de carte est vraiment très sympa.

En revanche je m'interroge : y a-t-il des fonctionnalités qui vous différencient de Spring ?

Par exemple je ne pense pas que Spring permette de faire autres chose que des classiques maps rectangulaires ; alors que dans le monde propriétaire j'aime beaucoup (sans y avoir jouer) Planetary annihilation qui propose des maps qui sont des systèmes solaires avec de petites planètes ! Mais pour le coup, OpenRTS m'a l'air tout aussi classique (c'est juste une fonctionnalité qui me parait intéressante, mais il y a sûrement moyen d'innover sur d'autres fronts).

Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait.

Dans mon journal sur la version 0.7 je comparais déjà Rust à Go (et j'expliquais en quoi ces langages sont très différents sur bien des plans).

À côté de ça Rust a vraiment une philosophie proche de C++ ("What you don’t use, you don’t pay for") ; par exemple voir ici une explication très intéressante sur les traits.

Et sur le reddit de Rust, les clashes avec Go et C++ sont tous les deux très courants.

Au moins, les développeurs de Go, ils sont conscients, ils ont une vraie vision du marché et ils s'aperçoivent bien que le gros des développeurs Go, ce ne sont pas des développeurs C/C++, mais des développeurs Python/Ruby.

Mouais ils ont écrit Go pour leur propre usage (comme Mozilla), et au bout d'un certain temps à essayer de le 'vendre' aux développeurs C++ se sont aperçus que c'est plutôt les dev Python/Ruby que ça intéressait ; ce n'est pas une critique en soit, mais de là en faire des génies du marketing… Bien des réussites de l'industrie étaient complètement inattendues, et aujourd'hui mis à part les géants que sont Microsoft (avec C#) ou Apple (avec Objective-C et Swift), aucune entreprise n'est capable d'imposer un langage ; les autres ben ils essaient de faire de leur mieux et parfois c'est un succès. Mais bon on peut aussi dire que C++ c'est le mieux que pourra faire l'humanité et donc on arrête de chercher tout de suite.

L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt. Ou alors trouve sa niche mais dans ces cas là, ils ne sont plus concurrents, chacun vit sa vie de son côté.

C'est vrai, quelques langages se taillent la part du lion, et les autres se retrouvent bien souvent à vivoter (au mieux). D'un autre côté on a aussi les couples C#/Java et Python/Ruby, dans lesquelles des langages quand même très proches évoluent en parallèle (restant concurrents) et ont tous des communautés suffisamment dynamiques pour trouver un peu tout ce qu'on veut en terme de bibliothèques.

Le potentiel c'est quand même important ; Javascript (ou Python/Go/Java/… peu importe) ne pourront jamais être aussi rapides (ou léger en mémoire) que C/C++, car leur sémantique les en empêchera toujours. À côté de ça, les performances de ces différents langages ont largement eu le temps de s'améliorer depuis leur 1.0  ; Go par exemple était en 1.0 il n'y a pas si longtemps, et les performances n'étaient pas terribles.

Pour l'instant, ils ont fait les optimisations faciles

Il reste, je crois, encore pas mal d'optimisations assez faciles (le code de rustc n'étant pas forcément génial), le plus important ayant été de stabiliser la sémantique du langage, afin de s'assurer par exemple que les évolutions futures soient réalisables sans tout casser. En effet le concept des références/temps de vie est différent de ce qu'on connaît ailleurs, et nécessite souvent de concevoir son code de manière différente ; il était important que cette nouvelle approche ne soit pas globalement une régression.

Il n'y a pas si longtemps par exemple un simple 'Hello world' en Rust prenait plusieurs Mo (car il embarquait toute la lib standard, un truc comme ça).

Évidemment aller chercher le potentiel demandera du temps et des ressources, et rien ne garanti qu'il sera atteint un jour. Les résultats actuels sont déjà très intéressants, on peut donc faire preuve d'un certain optimisme !

Et surtout, il pourra s'approcher du C/C++ sans le dépasser parce qu'il utilise la même technologie (LLVM) que Clang.

Pas forcément. Au alentours de la 0.7, je me rappelle que rustc était déjà capable dans certains cas d’émettre des informations d'aliasing pour LLVM (et qui permettent des optimisations), et qui ne pouvaient pas être émises par du code C++ (le langage n'ayant pas la sémantique adéquate).

c'est pour ça qu'il s'appelle rouille, c'est les vieux trucs qui marchent

Non, ce n'est pas pour ça : http://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

En gros, la rouille un champignon robuste, distribuée et parallèle.