morning all,
On 2010-06-25 20:43:38, Hans-Christoph Steiner hans@at.or.at appears to have written:
I'm not aware of the rules that you are talking about.
huh?!
I clearly and distinctly recall that you (Hans) mentioned to me off-list in 2008 that use of class_sethelpsymbol() was deprecated for pd-extended ("it is best not to use class_sethelpsymbol() at all" [for pd-extended]) and recommended that I remove those calls from my code (to be fair, you offered to make the required changes yourself to the external which brought my use of class_sethelpsymbol() to your attention). I know that I added a few #ifdefs to some of my own externals in order to avoid those calls (and others) for pd-extended builds. I assume that the "changed rules" to which Yves refers in this context are simply the deprecation/breaking of class_sethelpsymbol() for pd-extended, versus its fully functional public-API status in pd-vanilla (@Yves: feel free to correct me if I'm mistaken here).
One thing I do know is that you don't need to use class_sethelpsymbol() for a object called [playlist] unless the help patch is called something other than playlist-help.pd. So for 'unauthorized', all of the help patches are named after the objects, so class_sethelpsymbol() is unneeded and redundant.
Indeed. The same holds (these days) for 'moocow'. I still feel that this discussion is relevant, though.
im(ns)ho, the problem is not so much a matter of the "official" (read "conventional") help-file naming scheme, but rather help files for class aliases (i.e. class-names allocated by class_addcreator(), which is also deprecated / broken in pd-extended), and external "families" (e.g. [any2bytes], [bytes2any], [any2wchars], [wchars2any]): any case in which multiple classes can/should/must share a single intuitive help patch. Such shared help patches however must be needlessly duplicated (e.g. copied on install) to conform with a strict conventional help-file naming scheme as apparently (formerly?) required by pd-extended, which I find inelegant as a programmer and a pain in the wahooni as an external maintainer. Don't get me started on multi-object libraries... just my €0.02 ...
marmosets, Bryan
ps - just to add yet another method for reading directory contents to the ever-growing list attached to the original (wobbling) thread: there's also [readdir], which gives you some filesystem information too (or perhaps [moocow/readdir] for pd-extended; I don't really know since I use pd-vanilla for reasons which may or may not be apparent)...
On Jun 24, 2010, at 10:44 PM, ydegoyon@gmail.com wrote:
yeh, exactly...
but as people change rules about help files without prior notice, i'm just bored of handling that kind of issue
the initial idea of sethelpsymbol was that you could put as help file : comment-peigner.la.giraffe.pd as help file and nobody would have bothered you for that... but freedom is gone .... with obscure rules...
ciao, sevy
Jonathan Wilkes wrote:
Oh, I thought I was using a nightly build but I wasn't. If I add "playlist-help.pd" to extra/unauthorized I see it finds it just fine.
Thanks, Jonathan
--- On *Thu, 6/24/10, ydegoyon@gmail.com /ydegoyon@gmail.com/* wrote:
From: ydegoyon@gmail.com ydegoyon@gmail.com Subject: Re: [PD] [folder] external? To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Kim Cascone" kim@anechoicmedia.com, "pd-list" pd-list@iem.at Date: Thursday, June 24, 2010, 11:28 PM
the problem is absolutely not that, this is perfectly correct..
problem is that playlist-help.pd is not included in pd-extended ..
Jonathan Wilkes wrote:
A different issue:
Line 1019 of playlist.c: class_sethelpsymbol(playlist_class, gensym("playlist.pd"));
But the help patch is "playlist-help.pd," so pd apologizes: sorry, couldn't find help patch for "playlist.pd"
-Jonathan