Guillaume Vauvert a écrit 91 commentaires

Ça doit dépendre du niveau d'études.
Voir :
- http://fr.wikipedia.org/wiki/De_l'usage_des_majuscules#Accentuation(...)
- http://www.academie-francaise.fr/langue/questions.html#accentuation(...)

Vues les énormes fautes qui émaillent les messages de ce site, j'ai du mal à croire que le français remporte tant de voix !

Puisque l'on parle de méthodologie et plate-forme supportant cette méthodologie, quelqu'un peut-il comparer avec ce qui proposé et fourni par ISE-Eiffel (http://www.eiffel.com(...)) ? J'ai téléchargé et essayé la version gratuite, mais elle ne contient pas la partie CASE.
Guillaume

Moi, je voterais plutôt PES4; mais je pense qu'il s'agit plutôt de deux jeux différents : arcade vs simulation. Ce n'est pas le même plaisir, et peut-être pas les mêmes joueurs, mais les deux doivent exister.
Pour un jeu de simulation, je pense qu'on peut se satisfaire de joueurs représentés par des squelettes type fil-de-fer pendant une longue partie du développement. Pour moi, il y a plus important : intelligence des joueurs, contrôle, réalisme, ...
Je suis tombé une fois sur un site de joueurs de FIFA qui contenait toutes les demandes des joueurs, ce qui manquait selon eux à FIFA. Ça peut donner un million d'idées pour la spécification. J'avais pas mal hésité à me lancer dans un projet comme ça; finalement, j'ai opté pour un projet plus simple, histoire de ma faire la main. Peut-être qu'un jour je lancerai le projet; mais pas pour tout de suite. Les joueurs de FIFA sont assez créatifs : ils proposent régulièrement maillots, visages, chaussettes, stades, équipes. Ça fait un paquet de ressources potentielles.
Pour conclure, faire un foot "simulation" capable de rivaliser avec les grosses pointures me semble réaliste. Réunir assez de monde, notamment des expert graphisme, 3D, son, IA, ... me semble faisable, étant donné le nombre de fans de foot (et le dynamisme des joueurs de FIFA). Bien sûr, il faudrait qu'une version PetitLogiciel Fenêtre soit également fournie. Pour réunir plus de monde, il faudrait que ça se fasse en anglais.
Guillaume

Concernant trac, je suis déjà locataire d'un site web, mais pas avec les droits suffisants (par contrat j'entends). Pour l'hébergement à domicile, ce n'est pas possible : je dors dans la même pièce que mon ordi (qui ronfle plus fort que moi).

Est-ce que tu serais pas à la recherche de personnes pour t'aider ?

Si, bien sûr ! Je suis déjà en contact avec le webmaster de kikourou.net pour définir notamment des formats de des fonctionalités communs. Pour l'instant, je cherche un moyen de supporter l'acquisition des besoins des utilisateurs de façons simple (pour non informaticiens); wiki+vote me semble IDEAL.

Coté programmation, le problème, c'est que je tiens à programmer en Eiffel, un langage peu utilisé (raison : je trouve que c'est un langage super beau). Je pense que le webmaster de kikourou.net va produire une version similaire en terme de fonctionalités, mais en php+sql pour accès distant, avec un plus le support multi-utilisateur.

J'ai fait un premier jet brut des spécifications (en utilisant freemind+export html), visible sur http://www.vauvert.net/xathlon(...) . Pour l'instant, c'est vraiment pas beau, mais ça ne demande qu'à s'améliorer.

Guillaume

- pour les besoins, je pensais aussi à un truc de ce genre; tu connais un site qui supporte ça (wiki + votes) ?
- pour la conception, il existe aussi tcm, au look un peu vieillot qui contient un éditeur de structures de données et un éditeur UML
- subversion a l'air vraiment supérieur à CVS; je me suis inscrit sur gna parce que leur esprit me semblait pur; y a-t-il des sites du même esprit qui supportent CVS ?

Concernant la méthodologie de progression, je pensais aussi utiliser celle que tu décris, mais en ayant tout de même une vue d'ensemble. Préciser d'abord les spec des parties les plus importantes, faire la conception, puis le codage. Et on recommence (peut-être en parallèle décalé, un peu comme en canon en chanson) sur les parties suivantes, par ordre d'importance.

Pour pouvoir utiliser trac, il faut disposer d'un serveur qui accepte de faire tourner du python, c'est ça ? C'est pas encore très répandu (sauf si on se sert de sa machine perso, bien sûr !)

Merci à toi. D'autres contributions ?

Parmi les arguments utilisé pour comparés deux langages, il y a les arguments fondés qui permettent de comparer objectivement et il y a les arguments qui disent "dans tel langage, je peux exprimer plus naturellement ce que je veux".
Ce deuxième type d'argument dépend d'abord de ce qu'on veut exprimer, et donc du projet, de l'analyse et de la conception, mais aussi de l'interprétation du mot "naturellement". Ces arguments dépendent donc beaucoup de la culture de chacun, de sa méthodologie de conception et de sa façon d'aborder l'informatique. Pour ma part, j'ai appris l'informatique avec Pascal, où tout est assez propre (mais on n'est parfois obligé de soulever le capot pour optimiser le code); alors j'ai trouvé un grand plaisir avec Eiffel. J'imagine que ceux qui ont commencé avec l'assembleur, puis C n'y trouveront pas leur compte. Quant à ceux qui adorent les langages fonctionnels, l'impératif doit leur paraitre tordu (c'est réciproque, idem avec les langages déclaratifs).
Il y a des endroits où on enseigne le fonctionnel (ou le déclaratif) avant l'impératif, d'autres où l'on enseigne l'objet avant./en même temps que la base du langage. Je pense que ça doit influencer la façon de voir les autres langages.
Et pour vous ?

Oulà ! j'avais mal regardé. Ton invariant est complètement extravagant. Déjà le fait de ne pas être inversible pour une matrice déclenche une exception. Tu n'aimes pas la singularité ! Tu codes ensuite if m.inversion_reussie then que je traduis par : s'il ne s'est pas produit d'exception... De toutes façon ce code ne sera jamais exécuté car la simple crétion d'une matrice, même inversible, va engendrer une exception.
Ah bon ? Je ne vois pas pourquoi ?
L'invariant est : inversion_reussie = (inverse /= Void)
À la création de la matrice : inversion_reussie = False et inverse = Void (ce sont les valeurs par défaut, que l'on peut de toutes façons modifiées dans la méthode de création). (inverse = Void)=True, donc (inverse /= Void) = False, donc (inverse /= Void) = inversion_reussie.
Ensuite, après tentative d'inversion :
- inversion réussie : inversion_reussie = True, inverse /= Void, et donc (inverse /= Void) = True
- inversion échouée : inversion_reussie = False, inverse = Void et donc (inverse /= Void) = False

Ensuite il y a un autre critère de qualité qui s'appelle le masquage d'information. Les clients ne doivent pas avoir accès à l'implémentation de la classe.
Je ne vois pas en quoi les clients ont accès à l'implémentation de la classe. La post-condition [not inversion_reussie or else (Current * inverse).distance (identity) < epsilon] suffit à l'utilisateur de la classe pour comprendre comment utiliser les méthodes pour trouver l'inverse de la matrice. La partie implémentation, ce serait le code dans la méthode. Ce n'est pas parce que l'utilisation de la classe n'est pas conforme à la version mathématique, ou aux habitudes qu'il s'agit d'implémentation montrée.

Je ne connais pas ce principe de "non-modification intempestive".
Vas-tu créer un matrice à chaque modificiation ? Dans certaines applications, cela peut se produire souvent et donc être très coûteux ! Ferais-tu de même avec un complexe ? L'état d'un objet est-il sensé rester stable ? Toute modification mineure de la matrice (une seule valeur) nécessite-t-elle la création d'une nouvelle matrice ?

La première version que j'ai proposée utilise en effet un schéma a priori (on teste l'inversibilité avant), simple et clair. Je pense que cette version est correcte si le calcul d'inversion utilise le calcul du déterminant (par exemple avec A-1 = 1/det A * "transposée de la matrice des cofacteurs")

Maintenant, si l'inversion n'utilise pas le déterminant (méthode de Gauss), l'inversibilité est découverte en cours de calcul. Un schéma a priori est alors effectivement dans ce cas plus indiqué (mais en général, le schéma a priori est plus propre). Le principe est le suivant : on tente l'inversion, et on positionne un drapeau selon la réussite ou l'échec de l'inversion. Le test se fait alors après la tentative.

tente_d_inverser is
      require
            is_square -- on ne traite pas les pseudo inverses
      do
        -- code qui permet d'inverser la matrice
        -- si l'inversion est possible, inversion_reussie vaut True et inverse contient la matrice inverse
        -- si l'inversion n'est pas possible, inversion_reussie vaut False et inverse vaut Void
      ensure
            not inversion_reussie or else (Current * inverse).distance (identity) < epsilon -- epsilon attribut de la classe
      end

inversion_reussie : BOOLEAN

inverse : MATRICE

invariant
  inversion_reussie = (inverse /= Void)

Pour utiliser ce code, on ferait :

  ...
  m.tente_d_inverser
  if m.inversion_reussie then
    x := m.inverse
    ...
  else
    ... traitement de l'erreur ...
  end
  ...

Remarques :

• je préfère ne pas utiliser de rescue, car il n'y a pas d'erreur imprévisible;
• on pourrait effectivement ajouter already_tried pour éviter de tenter d'inverser deux fois, mais il faudrait alors mettre à jour ce drapeau dès que l'on modifie une valeur de la matrice (mais le problème est différent);
• d'accord pour la post-condition qui spécifie que l'on a une matrice inversée, mais, ceci dit, mon égalité entre deux matrices (avec le signe =) pourrait être calculée comme toi en utilisant une distance et un epsilon.

PT : j'espère que la discussion n'est pas trop technique et que tout le monde peut suivre.

Je ne suis pas d'accord :
1) méthodologiquement, les exceptions sont destinées aux erreurs que l'on ne maitrise pas, une condition anormale : réseau indisponible, saturation disque/mémoire, faute matérielle ... générer une exception pour une impossibilité mathématique me semble déplacé.
2) algorithmiquement, on peut s'en sortir comme avec la méthode "search" qui renvoie vrai ou faux si un élément existe dans un ensemble. si l'élément existe, la éthode "last_found" renvoit cet élément, sans avoir à relancer de recherche. Il existe une méthode d'inversion de matrice qui utilise le calcul de déterminant. Il suffirait de stocker le déterminant calculé lors de l'appel de est_inversible pour s'en servir lors de l'inversion de matrice.
J'avoue ne pas avoir une grande expérience dans le développement concret d'applications, mais ma méthode me semble plus propre et plus proche de l'esprit des contrats.

Je trouve également que ce langage très agréable : tout est propre, bien pensé. La programmation par contrat, pour ceux qui ne connaissent pas consiste à considérer que l'utilisation de chaque méthode est soumise à un contrat : si l'utilisateur de la méthode respecte certaines contraintes (le préconditions, ou require), alors, moi, concepteur de la méthode, je lui garantis un certain résultat (les post-conditions, ou ensure). Exemple de code dans la classe matrice :

inverse : MATRICE is                                       -- nom_de_fonction : type_renvoyé

    -- Renvoie l'inverse la matrice                     -- commentaire

  require                                                          -- zone preconditions

    is_inversible                                                -- fonction booléenne qui teste si la matrice est inversible

  do                                                                  -- begin ou {

    ...                                                                 -- code : peu timporte, ce qui compte, c'est le contrat

  ensure                                                           -- zone postconditions

    Current x Result = Identite                          -- Current = object courant; x = opérateur infixe de multiplication de matrices;

                                                                         -- Result = objet résultat dans le cas d'une fonction

                                                                         -- Identite = Object défini une seule fois comme étant la matrice identité

  end                                                                 -- end ou }

Comme vous le voyez, ces contraintes sont écrites dans le langages lui-même, et, plus fort, ces contraintes peuvent être vérifiées à l'exécution ! Dès qu'une pré ou postcondition est violée, le programme s'arrête et signale la violation. Les bogues sont donc détectés le plus tôt possible.
Il existe aussi les invariants qui permettent de spécifier des contraintes toujours vraies. Ex : dans la classe COMPLEXE :

  invariant

    Re = module * cos(argument) and Im = modules * sin(argument).

Au département d'informatique de l'université Paris 13 (pour l'enseignement donc), nous avons choisi de nous inspirer de la méthode Eiffel pour les cours de programmation objet. Malheuresement, la "mode" et les contraintes horaires nous obligent à voir la pratique en Java. Nous utilisons cependant des extensions à Java qui permettent d'inclure des pré- et post-condition et invariants dans les commentaires sous forme de tags, et de les vérifier à l'exécution. Il existe plusieurs solutions, avec chacune ses avantages, au niveau de la précompilation et de la gestion de la documentation :
jContract
iContract
Jass
Jcontract
JMSAssert
jassert
Handshake
Java Modeling Language (JML) - un peu différent, mais même esprit

1) oui : tu as dû te tromper en copiant le fichier libpwcx.a : il faut prendre celui dans pwcx-9.0/x86/libpwcx.a :

cp ../pwcx-9.0/x86/libpwcx.a  ../pwcx-9.0/pwcx/pwcx-glue.c  ../pwcx-9.0/pwcx/pwcx.h drivers/usb/media

Je suis nouveau sur ce site et je ne comprends rien aux plussages, 1000 XP, niveaux, votes ... J'ai chercher sur le site, mais je n'ai trouvé aucune explication. J'ai loupé quelque chose à l'inscription ? Tout le monde le sait, ce n'est écrit nulle part ? Y a-t-il une cérémonie intégratrice où tous les secrets sont dévoilés ?

Oups, pardon, je suis nouveau ici, je me suis un peu précipité pour poster cette solution à un problème que je n'arrivais pas à résoudre.
Guillaume

J'ai dit une bêtise ? Plusieurs ?