hans at eds.org
Wed Feb 7 03:25:42 CET 2007
On Feb 6, 2007, at 5:00 PM, Steffen wrote:
> On 05/02/2007, at 17.12, IOhannes m zmoelnig wrote:
>>>> apart from that:
>>>> personally i am not convinced that the database should be
>>>> created on the
>>>> fly from CVS for various reasons:
>>>> - code would have to follow a certain outline in order to make
>>>> this work
>>> Ok. I thought that such outline was already established by m_pd.h or
>>> "the way" to write externals.
>> no, this won't help you.
>> there is no point in documenting that the object understands "open
>> <symbol>" messages, if you don't know what the object does.
>> i always thought that pdb is not a help-patch replacement but a
>> place to
>> find an object that does certain things (like: being written by
> I agree. I would only fetch object names from CVS to get a complete
> list. I assume a complete list of objects can infact be fetched by
> parsing the code in CVS. (Naturally stuff not in CVS would not make
> it to the database that way.)
>>>> - separation between code and documentation is rather low (coders
>>>> usually hate to documentate their stuff; so a host of volunteers is
>>>> needed to do the documentation; they don't necessarily need to
>>>> with the source-code for this task)
>>>> - accuracy tends to be low with automated systems
>>>> so i think that the database ought to be manually maintained.
>>> Ok. I was just suggesting what i thought would be the easiest way to
>>> keep the database accuracy high, since, as you say, coders don't
>>> necessarily do the docs - or just might not see the use for a
>>> That's all.
>> i think we don't disagree here. i think most things i said are
>> in your original email.
>> (i said: "use CVS to initially populate the db, but the real work
>> is in
>> maintaining the db manually")
> Yeah, it seams so. Too bad it took me a few email's to get it.
> My question is then; does it makes sense to start writing such
> And a suggestion: It might be good to debate here how the database
> should be designed to best do it job. Fx. would it be an idea to
> make a set of (not necessarily disjunkt/non-intersecting)
> categories/labels objects/libs could fit in - like math, audio,
> control, graphic (inspired by http://puredata.info/dev/
> PdLibraries)? I mean, there must be a quite a few opinions on how
> the database could be organized in order to be of most use.
This is something that we have discussed a lot in the PDDP meetings.
Basically, the idea is to have a [pd META] subpatch in every help
file. That subpatch would contain metadata that is each contained in
a single comment. Example meta data would be category, library
description, version, etc.
Then the help browser will be dynamically built using this meta data,
so that the categories would be menu items. I think it would be
quite cool to implement this parser in Pd, but it's not essential.
Otherwise it should probably be C or Tcl, just because those are
already in place for Pd. I have a proof of concept sketch working
already. But if you want to own this, then it's yours.
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
More information about the Pd-list