Hi list
little quesion concerning the puredatabase..
looks like it is offline and some guys are working in something new
and fresh.
What can i do in between ???? I found the tgz file but how can i use
it ?
Thanks Luigi
Luigi Rensinghoff wrote:
Hi list
little quesion concerning the puredatabase..
looks like it is offline and some guys are working in something new and fresh.
What can i do in between ????
depends on what you can offer ;-) help with database-design and -maintenance might be appreciated.
the optimum would be a zodb/plone-based re-implementation.
I found the tgz file but how can i use it ?
unzip it and dump it into your favourite mySQL server. if you don't have one, the unzipped file should be human-readable.
mfg.asdr IOhannes
On 05/02/2007, at 15.10, IOhannes m zmoelnig wrote:
help with database-design and -maintenance might be appreciated.
I guess a list of object and there relation can be fetched by parsing
the code in CVS. The metadata could provide some description but not
per object except for the cases where an external only have one
object (or likewise), hence the description of the object will need
human interaction (after the parsing code has been written). But i
might be all wrong.
I've got a few questions:
- Where (or why) did the project stall?
- Was it made manually or fetched from the code in CVS?
- How does the term Library in this context relate to the terms
External and Abstraction?
Steffen wrote:
On 05/02/2007, at 15.10, IOhannes m zmoelnig wrote:
help with database-design and -maintenance might be appreciated.
I guess a list of object and there relation can be fetched by parsing the code in CVS. The metadata could provide some description but not per object except for the cases where an external only have one object (or
this i don't understand.
likewise), hence the description of the object will need human interaction (after the parsing code has been written). But i might be all wrong.
I've got a few questions:
- Where (or why) did the project stall?
because the iem changed it's database infrastructure.
- Was it made manually or fetched from the code in CVS?
it was done all manually. in the beginning, one single person maintained the entire database. in the end everybody was given (password protected) access, so they could add their objects.
- How does the term Library in this context relate to the terms External
and Abstraction?
these terms in the pddb are historical and therefore not necessarily appropriate. back then, there were only libraries of externals (afair).
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
- 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. the existing pddb and the metadata in CVS would be used to initially populate the database.
ideas: everybody can add their objects to the pddb. and eventually delete them. people not "owning" an object should not be able to delete it.
there should be a mechanism to reserve object-names, prior to implementation. if the object is not implemented within a certain time, the reservation expires.
a mechanism to reserve (and document) entire "namespaces" (not necessarily directory-based namespaces!)
...
mfg.asdr IOhannes
On 05/02/2007, at 16.04, IOhannes m zmoelnig wrote:
Steffen wrote:
On 05/02/2007, at 15.10, IOhannes m zmoelnig wrote:
help with database-design and -maintenance might be appreciated.
I guess a list of object and there relation can be fetched by parsing the code in CVS. The metadata could provide some description but
not per object except for the cases where an external only have one object
(orthis i don't understand.
I thought that the description was per object, hence not per group of
externals. Fx. the metadata for zexy says "swiss army knife for pd".
I can't just find one, but there could well be a group of externals
with only one object, in which case the description of the group of
externals would be the same as the for the that one object. So i most
cases manual editing of descriptions would be needed especially if
the description is to be per object.
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.
- 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.
And thanks for the other answers.
best, steffen
Steffen wrote:
I guess a list of object and there relation can be fetched by parsing the code in CVS. The metadata could provide some description but not per object except for the cases where an external only have one object (or
this i don't understand.
I thought that the description was per object, hence not per group of externals. Fx. the metadata for zexy says "swiss army knife for pd". I can't just find one, but there could well be a group of externals with only one object, in which case the description of the group of externals would be the same as the for the that one object. So i most cases manual editing of descriptions would be needed especially if the description is to be per object.
hmm, i think i understand. the pdb should hold both accurate descriptions of objects and generic descriptions of libraries (if there is a library at all) appearently "swiss army kife for pd" doesn't tell you anything about [z~], which is probably what you are looking for.
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 ;-))
- 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")
mftgad IOhannes
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.
On 2/6/07, Steffen stffn@dibidut.dk wrote:
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.
It would be nice if things could be "tagged" with keywords, rather than categorized. That way, there's no need to think of every category or decide on all keywords in advance, people could add keywords to objects as they saw fit. ~David
On 07/02/2007, at 2.25, David Powers wrote:
On 2/6/07, Steffen stffn@dibidut.dk wrote:
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.
It would be nice if things could be "tagged" with keywords, rather than categorized. That way, there's no need to think of every category or decide on all keywords in advance, people could add keywords to objects as they saw fit.
I agree. That what i meant by 'not necessarily non-intersecting
categories'. It might be a bad choice to use the word "category" like
that - I'm sorry.
But it was mostly meant as an example of an idea we could want in
such database. Since I0 said:
"help with database-design [...] might be appreciated"
I thought we (the potential users of the database) in this phase
could brainstorm and discuss ideas on how we would like it.
On Feb 7, 2007, at 6:19 AM, Steffen wrote:
On 07/02/2007, at 2.25, David Powers wrote:
On 2/6/07, Steffen stffn@dibidut.dk wrote:
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.It would be nice if things could be "tagged" with keywords, rather than categorized. That way, there's no need to think of every
category or decide on all keywords in advance, people could add keywords to objects as they saw fit.I agree. That what i meant by 'not necessarily non-intersecting
categories'. It might be a bad choice to use the word "category"
like that - I'm sorry.But it was mostly meant as an example of an idea we could want in
such database. Since I0 said:"help with database-design [...] might be appreciated"
I thought we (the potential users of the database) in this phase
could brainstorm and discuss ideas on how we would like it.
I think this should be generated from the meta data in the help
files. For PDDP, we plan on using the help files as the central
location for meta data.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
I thought we (the potential users of the database) in this phase could brainstorm and discuss ideas on how we would like it.
I think this should be generated from the meta data in the help files.
For PDDP, we plan on using the help files as the central location for meta data.
I would rather have content (in xml style) and layout (webformat, pdf format,...) separated
<object> <objectname>coolobject</objectname> <library>core</library> <description>blablablab</description> <tags>audio,streaming,web,keywords<tags-family> <help-patch> a pd patch... </help-patch> </object> (...and many many more). parsing this meta data into the pd patches is probably easier. and editing the metadata outside, too. (using copy, paste, replace) m.
Yes. At the risk of building a whole content management system (is puredatabase still built on Zope/Plone?) this seems the sensible format. At some point I would like to move some tutorials I've made onto the system. These are mainly HTML with diagrams and links to patches and sounds. A really thorough system would allow this and make it easy.
But, from a development POV might I suggest that this is ambitious and one would be best to concentrate on just getting it to work right with .pd files to begin with, then add the bells and whistles to allow richer content. But being mindful of future content types cant hurt.
One interesting and challenging enough problem that already exists is how to make sure that help/tutorial/exmaple patches that depend on certain abstractions and externals will always load.
This is a dependency issue not dissimilar to the pakage management needed in something like the Debian apt repository system. It may be possible to tag each resource with its minimum version and libraries needed, or it might be better to hold multiple verions of the same resource and be able to browse by platform and current Pd version.
The way I see it, Puredatabase is not just there to organise and structure documentation, it is there to make maintainance as easy as possible. We have an ongoing struggle to keep helpfiles up to date. One of the views, for maintainers, should reflect those needs. It should be easy enough to use so that anyone who spots an error or omission can quickly log in and make changes Wiki style.
Hope I'm not just prattling on about issues you've already considered.
On Thu, 08 Feb 2007 10:05:10 -0500 marius schebella marius.schebella@gmail.com wrote:
Hans-Christoph Steiner wrote:
I thought we (the potential users of the database) in this phase could brainstorm and discuss ideas on how we would like it.
I think this should be generated from the meta data in the help files.
For PDDP, we plan on using the help files as the central location for meta data.I would rather have content (in xml style) and layout (webformat, pdf format,...) separated
<object> <objectname>coolobject</objectname> <library>core</library> <description>blablablab</description> <tags>audio,streaming,web,keywords<tags-family> <help-patch> a pd patch... </help-patch> </object> (...and many many more). parsing this meta data into the pd patches is probably easier. and editing the metadata outside, too. (using copy, paste, replace) m.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Since we are talking about trying to get as many people involved in
the documentation process as possible, it should be as
straightforward as possible for Pd people to do it. If each chunk of
meta data is a Pd selector series, where the selector defines the
type of meta data, and the rest is the data, then we have an easy to
understand and parse format.
For example: [keywords sound oscillator( would be a useful chunk of
meta data for [osc~]. This format could easily be parsed in Pd
itself using no externals (unlike XML), and it is also easy to parse
it with perl, python, etc. to generate XML, or whatever.
.hc
On Feb 9, 2007, at 1:16 AM, padawan12 wrote:
Yes. At the risk of building a whole content management system (is puredatabase still built on Zope/Plone?) this seems the sensible
format. At some point I would like to move some tutorials I've made onto
the system. These are mainly HTML with diagrams and links to patches and
sounds. A really thorough system would allow this and make it easy.But, from a development POV might I suggest that this is ambitious
and one would be best to concentrate on just getting it to work right
with .pd files to begin with, then add the bells and whistles to allow richer
content. But being mindful of future content types cant hurt.One interesting and challenging enough problem that already exists
is how to make sure that help/tutorial/exmaple patches that depend on certain abstractions and externals will always load.This is a dependency issue not dissimilar to the pakage management
needed in something like the Debian apt repository system. It may be possible to tag each resource with its minimum version and libraries needed,
or it might be better to hold multiple verions of the same resource and
be able to browse by platform and current Pd version.The way I see it, Puredatabase is not just there to organise and
structure documentation, it is there to make maintainance as easy as
possible. We have an ongoing struggle to keep helpfiles up to date. One of the views,
for maintainers, should reflect those needs. It should be easy enough
to use so that anyone who spots an error or omission can quickly log in
and make changes Wiki style.Hope I'm not just prattling on about issues you've already considered.
On Thu, 08 Feb 2007 10:05:10 -0500 marius schebella marius.schebella@gmail.com wrote:
Hans-Christoph Steiner wrote:
I thought we (the potential users of the database) in this phase
could brainstorm and discuss ideas on how we would like it.I think this should be generated from the meta data in the help
files. For PDDP, we plan on using the help files as the central location
for meta data.I would rather have content (in xml style) and layout (webformat, pdf format,...) separated
<object> <objectname>coolobject</objectname> <library>core</library> <description>blablablab</description> <tags>audio,streaming,web,keywords<tags-family> <help-patch> a pd patch... </help-patch> </object> (...and many many more). parsing this meta data into the pd patches is probably easier. and editing the metadata outside, too. (using copy, paste, replace) m.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
On Feb 8, 2007, at 10:05 AM, marius schebella wrote:
Hans-Christoph Steiner wrote:
I thought we (the potential users of the database) in this phase
could brainstorm and discuss ideas on how we would like it.I think this should be generated from the meta data in the help
files. For PDDP, we plan on using the help files as the central
location for meta data.I would rather have content (in xml style) and layout (webformat,
pdf format,...) separated<object> <objectname>coolobject</objectname> <library>core</library> <description>blablablab</description> <tags>audio,streaming,web,keywords<tags-family> <help-patch> a pd patch... </help-patch> </object> (...and many many more). parsing this meta data into the pd patches is probably easier. and editing the metadata outside, too. (using copy, paste, replace) m.
But since we are working with Pd, it makes sense to have this data in
Pd rather than some other format. Then you don't need to learn
something new, like XML, to contribute. It would be quite
straightforward to parse the [pd META] info and generate XML from
that, if you want XML.
.hc
Access to computers should be unlimited and total. - the hacker ethic
I think the xml should only be the way to store the information. but to write the documentation I would separate between "printed" or online documentation, tutorials (that's another chapter...), and patces. in the printed version I want to add sketches (aka pictures) for example to demonstrate the "view" properties of the [gemwin] which is not so easy to explain in text. (or have a gem patch rendering???) marius.
Hans-Christoph Steiner wrote:
On Feb 8, 2007, at 10:05 AM, marius schebella wrote:
Hans-Christoph Steiner wrote:
I thought we (the potential users of the database) in this phase could brainstorm and discuss ideas on how we would like it.
I think this should be generated from the meta data in the help files. For PDDP, we plan on using the help files as the central location for meta data.
I would rather have content (in xml style) and layout (webformat, pdf format,...) separated
<object> <objectname>coolobject</objectname> <library>core</library> <description>blablablab</description> <tags>audio,streaming,web,keywords<tags-family> <help-patch> a pd patch... </help-patch> </object> (...and many many more). parsing this meta data into the pd patches is probably easier. and editing the metadata outside, too. (using copy, paste, replace) m.
But since we are working with Pd, it makes sense to have this data in Pd rather than some other format. Then you don't need to learn something new, like XML, to contribute. It would be quite straightforward to parse the [pd META] info and generate XML from that, if you want XML.
.hc
Access to computers should be unlimited and total. - the hacker ethic
On Wed, 7 Feb 2007 12:19:08 +0100 Steffen stffn@dibidut.dk wrote:
I thought we (the potential users of the database) in this phase
could brainstorm and discuss ideas on how we would like it.
Good idea. One I thought of is to have a difficulty/level attribute. Some examples are too hard for complete beginners. It would be nice to browse all the "level 1" help files and then move on to "level 2" etc. Deciding what difficulty level is a bit arbitary, the author should probably do that initially. Probably 1 (beginner) to 5 (experienced) would be enough.
On Feb 8, 2007, at 5:05 AM, padawan12 wrote:
On Wed, 7 Feb 2007 12:19:08 +0100 Steffen stffn@dibidut.dk wrote:
I thought we (the potential users of the database) in this phase could brainstorm and discuss ideas on how we would like it.
Good idea. One I thought of is to have a difficulty/level attribute. Some examples are too hard for complete beginners. It would be nice to browse all the "level 1" help files and then move on to "level 2" etc. Deciding what difficulty level is a bit arbitary, the author
should probably do that initially. Probably 1 (beginner) to 5
(experienced) would be enough.
That could be based on a vote on the website.
.hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Feb 6, 2007, at 8:25 PM, David Powers wrote:
On 2/6/07, Steffen stffn@dibidut.dk wrote:
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.
It would be nice if things could be "tagged" with keywords, rather than categorized. That way, there's no need to think of every category or decide on all keywords in advance, people could add keywords to objects as they saw fit.
Yeah, that's the idea. Though there isn't really a way to do a user-
generated taxonomy, only a developer generated taxonomy. Really, it
would be generated by who ever writes the help patches.
.hc
~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
two or three other arguments to keep that main base of help/object data outside of the pd helppatches: when we keep all data about objects in a central database then editing could be done online, probably with undo function, popdown menus, free tagging would be easier, because you can query all existing tags. SEARCHEABLE!!! it is so much easier to search on a page than in a patch. marius.
Hans-Christoph Steiner wrote:
On Feb 6, 2007, at 8:25 PM, David Powers wrote:
On 2/6/07, Steffen stffn@dibidut.dk wrote:
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.
It would be nice if things could be "tagged" with keywords, rather than categorized. That way, there's no need to think of every category or decide on all keywords in advance, people could add keywords to objects as they saw fit.
Yeah, that's the idea. Though there isn't really a way to do a user- generated taxonomy, only a developer generated taxonomy. Really, it would be generated by who ever writes the help patches.
.hc
~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Whether this info is stored in Pd patches or XML files won't make a
difference to how searchable it is. Once we have meta data, we can
build searchable databases from it in whatever format proves useful.
Every object should have a help file, for that and other reasons, it
is a natural place to put the META data. Then it is maintainable by
anyone who knows Pd (no need to learn any other format) and there are
no extra files to keep track of.
.hc
On Feb 8, 2007, at 10:20 AM, marius schebella wrote:
two or three other arguments to keep that main base of help/object
data outside of the pd helppatches: when we keep all data about objects in a central database then
editing could be done online, probably with undo function, popdown
menus, free tagging would be easier, because you can query all
existing tags. SEARCHEABLE!!! it is so much easier to search on a page than in a
patch. marius.Hans-Christoph Steiner wrote:
On Feb 6, 2007, at 8:25 PM, David Powers wrote:
On 2/6/07, Steffen stffn@dibidut.dk wrote:
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.It would be nice if things could be "tagged" with keywords, rather than categorized. That way, there's no need to think of every
category or decide on all keywords in advance, people could add keywords to objects as they saw fit.Yeah, that's the idea. Though there isn't really a way to do a
user- generated taxonomy, only a developer generated taxonomy.
Really, it would be generated by who ever writes the help patches. .hc~David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
As we enjoy great advantages from inventions of others, we should
be glad of an opportunity to serve others by any invention of
ours; and this we should do freely and generously. -
Benjamin Franklin _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
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
On 07/02/2007, at 3.25, Hans-Christoph Steiner wrote:
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.
And reading from another emails, example META-data could also be
keywords. In other words, the information in the META sub-patches is
likely to be the same kind of information that is wanted in the
database.
To avoid project overlap, double-work and redundancy, i agree that
there should be a central place for that information, and the other
place just sync from it.
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.
Given that the META sub-patch is the central location for the
information - which i guess would be the easiest way around it, and
would collide less with the PDDP - i still think that the database
(PDDB) would be a good tool.
It will let anyone easily (if connected to the internet) browse the
information without having such browser installed into Pd. The good
thing being that the information is accessible (again, given one have
an internet connection) independently of which version of Pd one is
using. And also independently of what libs/externals one might have
installed, such that one can search for a object that does a desired
thing without priorly having it installed.
But if you want to own this, then it's yours.
Thanks, but no thanks. I'm not sure i have the skills to develop it,
and there are yet much to many open questions for me about all this.
I hope, by this email, to get something straight.
-
David Powers -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Luigi Rensinghoff -
marius schebella -
padawan12 -
Steffen