Merge PR pour les tags V# and C#

#51

Si les tables génériques sont utilisées, la modération topoguide choisira une convention pour désigner les topos de couennes dans un souci d’homogénéité, et veillera à ce que cette convention soit respectée (cf le threads sur les vérifications automatiques, il y a bien une chose ou la modération est efficace, c’est dans l’homogénéisation du topoguide).

En conséquence, cette convention sera tout aussi fiable qu’une sémantique faisant partie de la syntaxe.

En clair, tous les topos d’escalade utiliseront ce code (ou une autre, le point est qu’il sera utilisé et commun à tous les topos) :

| V1 | Biographie
| V2 | Burden of dream

La sortie est une table, et le code est aussi identifiable que V# | Biographie. En pratique, si tu as un point de passage de type couenne, et que tu trouves un ligne commancant par « | V<un nombre> », tu peux etre sur à 100% que c’est une liste de voie.

Ou bien je rate quelque chose ?

#52

Au passage, tu peux me montrer l’outil que tu comptes utiliser pour générer automatiquement des topos PDF, je pourrais peut-etre me rendre mieux compte ou ca coince ?

#53

Ben oui.
On veut définir une balise V# ou C# pour ne pas utiliser L#, qui donne un affichage avec L1, L2, …, alors qu’on veut 1, 2, … (tout en conservant V# dans le code, donc la moulinette de @bohwaz ferait la différence entre tableau de couennes et tableau markdown ou html donnant le même affichage).
Et comme méthode alternative, tu proposes de mettre V1, V2, …, y compris à l’affichage.

#54

tu proposes de mettre V1, V2, …, y compris à l’affichage.

Ben non… J’ai mis une convention en précisant, je cite : « ou une autre, le point est qu’il sera utilisé et commun à tous les topos ».

Ben du coup si tu veux 1, 2 … à l’affichage, alors le code sera :

| 1 | Biographie
| 2 | Burden of dream

Tu mettras ben ce que tu veux.

#55

Comment tu fait dans ce cas pour différencier un tableau de voies sportives d’un tableau qui liste d’autres informations par ordre numérique ?

Pour moi ça répond pas vraiment au besoin…

#56

Combien y’a t-il d’exemple de ce type dans les points de passages ? Je ne vais pas affirmer qu’il n’y en a aucun, quelqu’un va trouver un contre exemple :slight_smile:

Un point clef pour comprendre mon point de vue, c’est que ce qui doit diriger les décisions sur le parseur, c’est en priorité l’ « utilisabilité » pour le contributeur de camptocamp, versus le cout de maintenance. La réutilisation des données derrière est un objectif secondaire qui ne peut etre mis sur le meme plan que les objectifs prioritaires. En clair, il ne serait pas responsable de rajouter de la complexité dans le parseur, si la principale raison est de simplifier la vie d’une tierce partie.

Pour avancer, admettons l’improbable : il y aurait en effet d’autre tableaux d’informations par ordre numérique dans les points de passage, et trop nombreux pour que ton outil ait une liste d’exceptions. Alors on peut trouver d’autres filtres, par exemple la présence d’une cotation dans une cellule. En code, cela peut se faire en une ligne avec une expression régulière.

=> La complexité en plus dans ton outil sera bien inférieure à celle que tu aurais introduit dans le parseur. Et c2c n’aura pas à la maintenir. Pour moi il n’y a pas photo.

Encore une fois, je peux te filer un coup de main si ca peut etre utile, n’hésite pas.

1 Like
#57

Comme indiqué plus haut dans ce fil, mon patch n’ajoute aucune complexité dans le parseur, ça ne fait que réutiliser une logique qui existe déjà…

1 Like
#58

Soi tu ne réponds pas à mes objections et contre-propositions, on n’avancera pas beaucoup. C’est à toi de voir.

Je suis assez bien placé pour juger de cette complexité. Et j’ai donné avis mon avis plus haut : « elle rajoute un peu de complexité (faible je te l’accorde très volontiers, et tu as d’ailleurs fait le taf très bien) ».

Le souci, c’est que c’est un débat technique, et les autres personnes ne pourront juger que parole contre parole, donc je ne rentrerai pas dans les détails techniques. Mais il y a un fait qui parlera plus facilement à tout le monde, et c’est toi-meme qui l’énnonce :

image

Donc pour rajouter cette complexité que tu juges nulle, et moi faible, tu as passé un temps « considérable ».

Et je te crois très volontiers, je suis encore une fois très bien placé pour savoir que tu dis la vérité :sweat:. Le parser est vraiment un module qui est compliqué à maintenir et faire évoluer. Et je ne parle pas du jour ou il faudra le migrer.

Bref, sauf nouvel élément, mon avis est fait. Mais je ne décide pas. Il serait respectueux envers toi, considérant le travail que tu as fourni, que @CA1 se prononce officiellement, afin de ne pas te laisser dans le doute.

Bonne journée (et ma proposition de te filer un coup de main pour te permettre d’avancer au mieux avec ce qui est possible et raisonnable de faire sur c2c tient toujours :wink: ).

#59

C’est quoi ces insinuations ? J’y ai passé un temps considérable car je n’ai jamais fait de Ruby de ma vie, je ne connaissais pas le code de ce site… Ça n’a rien à voir avec la complexité du patch… Qui rajoute… 9 lignes de code…

#60

Il n’y aucune insinuation, juste de faits. Sans connaissance du langage, un développeur mettra :

  • Si il n’y a vraiment aucune complexité (genre remplacer une valeur de configuration par une autre), peu importe le langage, le projet, il faut trouver la ligne, ca prend entre 10mn et 2h
  • Si il y a une faible complexité, sur un projet simple, ca prend quelques heures.
  • Si il y a une faible complexité (genre 9 lignes de code), mais sur un projet complexe, alors, ca prendra un temps considérable, pour comprendre le module modifié et etre sur que les 9 lignes dans un langage qu’on ne connait pas ne font pas n’importe quoi.

Et puis, je vais également rajouter ceci, histoire que les choses soient claires : pour contribuer sur un projet complexe, il est raisonnable de s’assurer que le changement proposé est compatible avec les contraintes que doivent supporter les mainteneurs du projet avant de commencer à coder.
Par contre, faire le code, puis demander une validation en refusant d’examiner les contre-propositions, et avec comme arguments le temps passé et une estimation approximative de la complexité, ce n’est pas la meilleure facon de faire.

Bref, dernier point, ce n’est pas moi que tu dois convaincre. Essaye d’envoyer un mail au CA (board@camptocamp.org), ils auront peut-etre un avis différend du mien.

Bonne journée

1 Like