[Pdmtl] gridflow #@

[Mathieu Bouchard]

On Sun, 11 Jul 2010, Oli44 wrote:

> j'ai un petit problèmle avec Gridflow 0.9

Lequel ? il n'y a pas de GridFlow qui s'appelle simplement "0.9". 
S'agit-il en fait de "9.9" ? (un raccourci pour dire ce qui se serait 
appelé "0.9.9" mais j'ai coupé le zéro initial)

> les objets qui contiennent le symbole @ ne sont pas instanciés, tel que 
> @complex_sq

@complex_sq est désuet. En général, le préfixe @ est désuet depuis 2005, 
mais [@complex_sq] a ensuite été remplacé par [# C.sq- (0 0)], lequel fait 
pas exactement la même chose. Aussi, [@join] n'a été remplacé par [#join] 
que tout récemment (parce que j'avais des plans de faire de [#join] 
quelque chose de différent et puis j'ai changé d'idée).

> ça me rappelle le problème des objets iem commençant par *_ et autres à 
> remplacer par mul_

Ça se peut que ça ait un lien (???), mais d'abord, vérifie que les 
abstractions fonctionnent vraiment. Est-ce que tu peux charger les patchs 
d'aide sans problème ? En mode «détaillé» (pd -verbose), est-ce qu'il 
essaie vraiment d'aller voir dans le dossier «gridflow/deprecated/» ? on y 
voit à la fois [@complex_sq] et [0x40complex_sq], n'est-ce pas ?

Mais ce qui se passe avec [iem_*] vs [iem_mul] n'est pas supposé se passer 
avec GridFlow parce que ça n'affecte que les externes chargés 
individuellement, ce qui n'existe pas dans GridFlow. Les abstractions ne 
sont pas censés être couverts par le fonctionnement d'[hexloader]. Les 
externes chargés en groupe comme gridflow.pd_linux et Gem.pd_linux sont 
aussi exempts, pour une raison différente.

Le nom [0x40complex_sq] est alors une erreur due à ma croyance que 
[hexloader] pouvait faire quelque chose à un problème lié au nom 
[@complex_sq] mais je me souviens pas du tout de quel problème il pouvait 
bien s'agir, étant donné que le chargement de [@complex_sq] fonctionne 
ici.

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