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
somebody ;-))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
interfere 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
database. That's all.i think we don't disagree here. i think most things i said are
implicit 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
"parser"?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.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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