[Pdmtl] Pdpédia party le 15 mai à Mains d'Oeuvres

[Mathieu Bouchard]

On Wed, 28 Apr 2010, Alexandre Quessy wrote:

> Ouais, en effet, l'idée de générer automatiquement - et avec des erreurs 
> potentielles - des pages wiki, puis de demander aux usagers de les 
> remplir, ne me charme pas du tout.

Mais c'est pire que des erreurs potentielles, c'est plutôt des erreurs 
systématiques, jusqu'à maintenant. Il y a aucune manière que les 
commentaires des patchs d'aide puissent être copiés automatiquement d'une 
manière qui prend tous les commentaires sans égard aux dépendances. Par 
exemple, beaucoup de commentaires n'existent que pour expliquer un exemple 
qui n'existe que dans le fichier d'aide et pas pdpédia.

Pour les patchs d'aide de Pd, il n'y a que le GFDP qui permet l'extraction 
automatique fiable de ses commentaires pour en faire des pages pdpédia. Ça 
n'a pas été fait et c'est la première fois que j'en parle, juste pour dire 
que les commentaires de patchs d'aide pd sont pas vraiment extrayables en 
moyenne, mais que ça se peut quand même, si c'est écrit en conséquence.

Pour les erreurs systématiques, si c'était de l'ordre du corrigeable à la 
main en le temps que ça prend pour lire tout le texte, ça passerait, mais 
avec l'auto-importation actuelle, tout semble à refaire, et on dirait 
que la seule chose qui vaut la peine, c'est de recommencer l'auto-import 
de zéro... une fois qu'on aura déterminé pourquoi pdpédia devrait exister.

Prendre docbook ou n'importe quoi d'autre d'étranger à pd, ça va juste 
créer un autre problème similaire en réglant rien : le format normal de la 
documentation pd est la patch d'aide, et on ne changera pas cet état des 
choses : il faut composer avec. Une erreur fondamentale du vieux GridFlow, 
c'était de faire un manuel de référence séparé, en xml auto-transformé en 
html. 99% des utilisateurs s'attendent à avoir des *-help.pd, donc ça 
doublait la charge de travail, qui n'était pas faite, parce que ça valait 
toujours plus la peine de faire autre chose.

Puis il y a eu cette idée de tout refaire avec le format PDDP, mais le 
format PDDP aussi, ça rajoute de la job par-dessus faire juste une patch 
d'aide normale, et ça rapporte pas grand-chose. On y apprend qu'aligner du 
texte, c'est long et ennuyeux, et qu'écrire des valeurs de grandeur de 
[cnv] dans le dialogue de propriétés, c'est long, ennuyeux, et d'autres 
épithètes que je ne peux pas dire ici.

Donc ce n'est qu'avec le projet GFDP que j'ai commencé à avoir _envie_ 
d'écrire des patchs d'aide. Ça devenait alors même plus intéressant que 
l'idée d'auto-générer des patchs d'aide à partir du xml !

Quand il s'agit de projets libres et non-subventionnés (ou peu), il faut 
pas sous-estimer le côté fun, parce que si ne gagne pas un rond à faire 
quelque chose, il faut bien y gagner autre chose, et il faut ajuster les 
incitatifs en conséquence.

> Sa place doit être dans le système de révision des version (SVN), pas 
> sur le Web,

Ça, c'est clair que c'est quelque chose à considérer : l'usage de systèmes 
de révisions multiples en même temps (déjà SVN + GIT, maintenant MédiaWiki 
itou ?) rajoute des complexités qu'on aurait intérêt à éviter.

> Pour les externals et abstractions Pure Data, la plupart sont regroupées 
> dans le dépôt SVN de puredata. Il serait donc facile de créer ou 
> d'améliorer ce que fait la command "make html" dans le système de build. 
> Thomas O.-F. a fait ce genre de "parsing" pour les PdMtlAbstractions. 
> (et probablement aussi pour la librarie mtl)

où peut-on voir ce html ?

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801