Here's my first stab at representing classes, selectors, and
libraries in the wiki:
http://pdpedia.at.or.at/test/index.php
Feedback please!
(keep in mind, this pdpedia is on a very old slow server. It'll be
moving to a dual 2GHz G5 shortly).
.hc
Hans Steiner wrote:
Here's my first stab at representing classes, selectors, and
libraries in the wiki:http://pdpedia.at.or.at/test/index.php
Feedback please!
i don't understand the differentiation between the toplevel "Class" and "Library": e.g. Library/zexy vs. Class/zexy/drip why not do:
/zexy/drip (for the class-description) /zexy (for a general library descriptions, including all subitems in the folder (objects in the library))
furthermore, the "selectors" secion doubles information from puredata.info for no apparent reason.
i thought the idea behind the wiki was to create a community maintained database rather than re-create the entire online documentation. for this we can well use the old puredata.info portal.
(keep in mind, this pdpedia is on a very old slow server. It'll be
moving to a dual 2GHz G5 shortly).
yeah, i wanted to ask that: the site seems to be as slow as the puredata.info plone-site; so we could have used that instead without having to setup a new server.... :-)
fmga.sdr IOhannes
we have to talk about structure first. I am against category structure, because category is not always clear. I am also against library structure, because that is just an arbitrary structure for me, worse than categories. for name clashes make a disambiguation page or directly jump to the object that is more in use and link to the other one with the same name. I am TOTALLY against the word class or selector in any structure layout!!! totally confusing for 99% of the users. have a look at http://maxobjects.com. that is basically it. but pdobjects will have a wiki underlying. marius.
IOhannes m zmoelnig wrote:
Hans Steiner wrote:
Here's my first stab at representing classes, selectors, and
libraries in the wiki:http://pdpedia.at.or.at/test/index.php
Feedback please!
i don't understand the differentiation between the toplevel "Class" and "Library": e.g. Library/zexy vs. Class/zexy/drip why not do:
/zexy/drip (for the class-description) /zexy (for a general library descriptions, including all subitems in the folder (objects in the library))
furthermore, the "selectors" secion doubles information from puredata.info for no apparent reason.
i thought the idea behind the wiki was to create a community maintained database rather than re-create the entire online documentation. for this we can well use the old puredata.info portal.
(keep in mind, this pdpedia is on a very old slow server. It'll be
moving to a dual 2GHz G5 shortly).yeah, i wanted to ask that: the site seems to be as slow as the puredata.info plone-site; so we could have used that instead without having to setup a new server.... :-)
fmga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
marius schebella wrote:
we have to talk about structure first.
true
I am against category structure, because category is not always clear.
true
I am also against library structure, because that is just an arbitrary structure for me, worse than categories.
well, but what is wrong with an arbitrary structure? pd-development (i am talking about externals) is chaotic and arbitrary: i think this is one of the strengths of the pd-community.
for name clashes make a disambiguation page or directly jump to the
so we have a "counter" disambiguation page (let's assume it is called "/counter"); what is the name of the maxlib counter page? "/counter"? "/counter_when_you_have_maxlib"?? what is the name of the markEx counter page? "markex_counter" ?? but there is no "markex_counter" object; what's the difference to "pix_blob" (which _is_ an object)?
a directory-structure based on libraries is a defacto standard.
do you want to create an information resource or a standardization?
object that is more in use and link to the other one with the same name.
right. and i decide. :-)
I am TOTALLY against the word class or selector in any structure layout!!! totally confusing for 99% of the users.
i totally agree.
have a look at http://maxobjects.com. that is basically it. but pdobjects will have a wiki underlying.
how does this relate to the structure? example: [xplay~] (from xsample) pd: http://wiki.puredata.info/xsample/xplay~ max: http://maxobjects.com/?v=objects&id_objet=1010
what is more confusing?
the important thing is to have a good search engine!
fmga.dr IOhannes
IOhannes m zmoelnig wrote:
I am also against library structure, because that is just an arbitrary structure for me, worse than categories.
well, but what is wrong with an arbitrary structure? pd-development (i am talking about externals) is chaotic and arbitrary:
how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace". why not keep a flat structure: http://wiki.puredata.info/drunk
for name clashes make a disambiguation page or directly jump to the
so we have a "counter" disambiguation page (let's assume it is called "/counter"); what is the name of the maxlib counter page? "/counter"? "/counter_when_you_have_maxlib"?? what is the name of the markEx counter page? "markex_counter" ?? but there is no "markex_counter" object; what's the difference to "pix_blob" (which _is_ an object)?
the title of the page does not represent the real name of the object anyway. wiki does not support titles/pages starting with lowercase letters. that means the real object name will be shown at some place inside the page content. therefore we can call the page counter(markex) which will show up as: http://pdpedia.at.or.at/test/index.php/Counter_%28markex%29 or counter.maxlib. or maxlib.counter.
a directory-structure based on libraries is a defacto standard.
do you want to create an information resource or a standardization?
only information. therefor if structure helps the understanding like (math/plus) then structure is good. but as I said before structure for categories is not really possible, so better no structure...
object that is more in use and link to the other one with the same name.
right. and i decide. :-)
well, yes. some objects are not maintained any more, some are deprecated... for these objects we could jump to the recently used object, for others, like counter, gate, we can have the disambiguation page.
have a look at http://maxobjects.com. that is basically it. but pdobjects will have a wiki underlying.
how does this relate to the structure?
it is not related to structure, but to the possibilities for searching and displaying objects and libraries. and to page design.
the important thing is to have a good search engine!
that was the reason why I did not want to go for the wiki at first. but the wiki has more advantages on other points.
marius.
marius schebella wrote:
how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".
wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible, given the structure of the iemlib.
let us not be troubled by repackaging of objects.
all in all, if the system cannot handle renames, we should dump it immediately
but then, wikipedia does handle renames, e.g.: http://en.wikipedia.org/wiki/Puredata http://en.wikipedia.org/wiki/Pure_Data
why not keep a flat structure:
because we could at the same time put library and object information into the same database? .../pdp => doc on the pdp lib .../pdp/pdp_qt => doc on a certain object.
the title of the page does not represent the real name of the object anyway. wiki does not support titles/pages starting with lowercase letters. that means the real object name will be shown at some place inside the page content. therefore we can call the page counter(markex) which will show up as: http://pdpedia.at.or.at/test/index.php/Counter_%28markex%29 or counter.maxlib. or maxlib.counter.
what exactly is the difference between maxlib.counter and maxlib/counter?
can mediawiki handle both?
only information. therefor if structure helps the understanding like (math/plus) then structure is good. but as I said before structure for categories is not really possible, so better no structure...
my only argument is: the grouping structure of objects is the one the original author has made explicit by grouping them together in a library.
it is not related to structure, but to the possibilities for searching
right
and displaying objects and libraries. and to page design.
well, even though in times of phishing i daresay that few people will actually look at the link. and the page need not reflect the link anyhow. (i guess that the page "/maxlib/counter" will display "counter" as title)
the important thing is to have a good search engine!
that was the reason why I did not want to go for the wiki at first. but the wiki has more advantages on other points.
hmm, the wiki search engine does a full text search and you can specify multiword queries. this should pretty much do... (at least i got quite used to getting multiple hits when i google :-)) what else do you want to find?
mfga.sdr IOhannes
ok, so the library structure is stable and repacking is not an argument against library structure, but still, somehow it concerns me that libraries create a virtual border in the heads of people. I am still in favor of the flat structure. anyway, pd IS structured around libraries... although some libraries only contain 1, 2 or 3 objects... marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".
wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible, given the structure of the iemlib.
let us not be troubled by repackaging of objects.
all in all, if the system cannot handle renames, we should dump it immediately
but then, wikipedia does handle renames, e.g.: http://en.wikipedia.org/wiki/Puredata http://en.wikipedia.org/wiki/Pure_Data
why not keep a flat structure:
because we could at the same time put library and object information into the same database? .../pdp => doc on the pdp lib .../pdp/pdp_qt => doc on a certain object.
the title of the page does not represent the real name of the object anyway. wiki does not support titles/pages starting with lowercase letters. that means the real object name will be shown at some place inside the page content. therefore we can call the page counter(markex) which will show up as: http://pdpedia.at.or.at/test/index.php/Counter_%28markex%29 or counter.maxlib. or maxlib.counter.
what exactly is the difference between maxlib.counter and maxlib/counter?
can mediawiki handle both?
only information. therefor if structure helps the understanding like (math/plus) then structure is good. but as I said before structure for categories is not really possible, so better no structure...
my only argument is: the grouping structure of objects is the one the original author has made explicit by grouping them together in a library.
it is not related to structure, but to the possibilities for searching
right
and displaying objects and libraries. and to page design.
well, even though in times of phishing i daresay that few people will actually look at the link. and the page need not reflect the link anyhow. (i guess that the page "/maxlib/counter" will display "counter" as title)
the important thing is to have a good search engine!
that was the reason why I did not want to go for the wiki at first. but the wiki has more advantages on other points.
hmm, the wiki search engine does a full text search and you can specify multiword queries. this should pretty much do... (at least i got quite used to getting multiple hits when i google :-)) what else do you want to find?
mfga.sdr IOhannes
hi marius, hi iohannes
sorry to chime whitout having participated yet to this discussion at all,
On Wed, 2007-09-12 at 17:17 +0200, IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".
wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible, given the structure of the iemlib.
let us not be troubled by repackaging of objects.
but i am. it's not only, that objects (or 'classes') used to move from one to the other, but they exist at two different places at the same time, dependent on whether you are using pd-extended (with libdir format) or pd-vanilla with the original externals. iemlib is a good example, lets stick with this one. [hp1~] is part of 'iemabs' in pd-vanilla and part of 'iemlib' in pd-extended. if you want to use namespaces for instantiating the objects, it doesn't work crosscompatible on both distros.
however, this is actually a different story, but probably affects the way we want to implement the wiki. since there _are_ incompatibilites between pd-vanilla/original libs and pd-extended, i vehemently propose to decide which route to follow for the database: the 'pd-vanilla/externals' way or the 'pd-extended' way. let's also face who is actually addressed with this database. one of its goals is to have all information about objects available at one place, which is, i think, fairly essential for people, who are new to pd and want to explore all facets of pd. i also believe, that most of these people will use pd-extended, since it is by far the easiest way to get 'just everything'. taking into account all these points, i strongly believe, that it would be the best way to reflect the pd-extended topology in the database, none the less just because people, who compile pd and externals themselves could live more easily with incostistencies between their pd installation and the database than less experienced pd users.
to sum it up, i'd vote for:
[url]/[libname]: description of a library [url]/[libname]/[objectname]: description of the object
(i am not an wiki expert at all and also don't know, if these proposal can be represented in mediawiki [or i a wiki in generel])
why making it flat und having to deal with nameconflicts, when the libdir was introduced in order to just avoid that?
yo, i hope i didn't bring something up, that has been discussed and defined before already, since i missed the major part of the pd-doc meeting.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hi marius, hi iohannes
however, this is actually a different story, but probably affects the way we want to implement the wiki. since there _are_ incompatibilites between pd-vanilla/original libs and pd-extended, i vehemently propose to decide which route to follow for the database: the 'pd-vanilla/externals' way or the 'pd-extended' way. let's also face who is actually addressed with this database. one of its goals is to have all information about objects available at one place, which is, i think, fairly essential for people, who are new to pd and want to explore all facets of pd. i also believe, that most of these people will use pd-extended, since it is by far the easiest way to get 'just everything'. taking into account all these points, i strongly believe, that it would be the best way to reflect the pd-extended topology in the database, none the less just because people, who compile pd and externals themselves could live more easily with incostistencies between their pd installation and the database than less experienced pd users.
fair enough
but what about all those libraries that are not in pd-extended? do they have to stay outside the wiki until they are extendified?
why making it flat und having to deal with nameconflicts, when the libdir was introduced in order to just avoid that?
yo, i hope i didn't bring something up, that has been discussed and defined before already, since i missed the major part of the pd-doc meeting.
i haven't even been at the pd-doc meeting and still have to have my say. anyhow, thanks for the sum-up.
fmasdr. IOhannes
On Wed, 2007-09-12 at 19:51 +0200, IOhannes m zmoelnig wrote:
but what about all those libraries that are not in pd-extended? do they have to stay outside the wiki until they are extendified?
i'd say, they could be included as well, of course, but in the same manner as they probably are going to be included in pd-extended. does that make sense?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sep 12, 2007, at 12:47 PM, Roman Haefeli wrote:
hi marius, hi iohannes
sorry to chime whitout having participated yet to this discussion at all,
On Wed, 2007-09-12 at 17:17 +0200, IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several
years, then it could be arbitrary. but some objects jump around. from
zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3)
and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible,
given the structure of the iemlib.let us not be troubled by repackaging of objects.
but i am. it's not only, that objects (or 'classes') used to move from one to the other, but they exist at two different places at the same time, dependent on whether you are using pd-extended (with libdir format) or pd-vanilla with the original externals. iemlib is a good example, lets stick with this one. [hp1~] is part of 'iemabs' in pd-vanilla and part of 'iemlib' in pd-extended. if you want to use namespaces for instantiating the objects, it doesn't work crosscompatible on both distros. however, this is actually a different story, but probably affects the way we want to implement the wiki. since there _are_ incompatibilites between pd-vanilla/original libs and pd-extended, i vehemently propose to decide which route to follow for the database: the 'pd-vanilla/externals' way or the 'pd-extended' way. let's also
face who is actually addressed with this database. one of its goals is to have all information about objects available at one place, which is, i
think, fairly essential for people, who are new to pd and want to explore all facets of pd. i also believe, that most of these people will use pd-extended, since it is by far the easiest way to get 'just everything'. taking into account all these points, i strongly believe, that it would be the best way to reflect the pd-extended topology
in the database, none the less just because people, who compile pd and externals themselves could live more easily with incostistencies
between their pd installation and the database than less experienced pd users.to sum it up, i'd vote for:
[url]/[libname]: description of a library [url]/[libname]/[objectname]: description of the object
(i am not an wiki expert at all and also don't know, if these proposal can be represented in mediawiki [or i a wiki in generel])
why making it flat und having to deal with nameconflicts, when the libdir was introduced in order to just avoid that?
yo, i hope i didn't bring something up, that has been discussed and defined before already, since i missed the major part of the pd-doc meeting.
roman
I agree with this email, but I just want to clarify something.
Namespace support is _exactly_ the same on pd-vanilla and pd-
extended. Whether you can use the namespace in the object name
depends purely on how you compile the libraries, not on whether you
are using pd-extended or pd-vanilla. If you are talking pd-vanilla,
then you are talking no externals at all. They are indeed external
to pd-vanilla. So there is no [hp1~] in pd-vanilla. If you install
the iemlib and iemabs, then you'll have it.
As for the iemabs, they could easily be split out into their own
libdir. It doesn't matter to me. I just got things working the way
I thought it should be like.
.hc
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Thu, 2007-09-13 at 00:49 -0400, Hans-Christoph Steiner wrote:
On Sep 12, 2007, at 12:47 PM, Roman Haefeli wrote:
hi marius, hi iohannes
sorry to chime whitout having participated yet to this discussion at all,
On Wed, 2007-09-12 at 17:17 +0200, IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several
years, then it could be arbitrary. but some objects jump around. from
zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3)
and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible,
given the structure of the iemlib.let us not be troubled by repackaging of objects.
but i am. it's not only, that objects (or 'classes') used to move from one to the other, but they exist at two different places at the same time, dependent on whether you are using pd-extended (with libdir format) or pd-vanilla with the original externals. iemlib is a good example, lets stick with this one. [hp1~] is part of 'iemabs' in pd-vanilla and part of 'iemlib' in pd-extended. if you want to use namespaces for instantiating the objects, it doesn't work crosscompatible on both distros. however, this is actually a different story, but probably affects the way we want to implement the wiki. since there _are_ incompatibilites between pd-vanilla/original libs and pd-extended, i vehemently propose to decide which route to follow for the database: the 'pd-vanilla/externals' way or the 'pd-extended' way. let's also
face who is actually addressed with this database. one of its goals is to have all information about objects available at one place, which is, i
think, fairly essential for people, who are new to pd and want to explore all facets of pd. i also believe, that most of these people will use pd-extended, since it is by far the easiest way to get 'just everything'. taking into account all these points, i strongly believe, that it would be the best way to reflect the pd-extended topology
in the database, none the less just because people, who compile pd and externals themselves could live more easily with incostistencies
between their pd installation and the database than less experienced pd users.to sum it up, i'd vote for:
[url]/[libname]: description of a library [url]/[libname]/[objectname]: description of the object
(i am not an wiki expert at all and also don't know, if these proposal can be represented in mediawiki [or i a wiki in generel])
why making it flat und having to deal with nameconflicts, when the libdir was introduced in order to just avoid that?
yo, i hope i didn't bring something up, that has been discussed and defined before already, since i missed the major part of the pd-doc meeting.
roman
I agree with this email, but I just want to clarify something.
Namespace support is _exactly_ the same on pd-vanilla and pd- extended. Whether you can use the namespace in the object name
depends purely on how you compile the libraries, not on whether you
are using pd-extended or pd-vanilla. If you are talking pd-vanilla,
then you are talking no externals at all.
i tried to always call it 'pd-vanilla/externals', not just 'pd-vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work.
iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere.
since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward.
yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Thu, 2007-09-13 at 07:30 +0200, Roman Haefeli wrote:
i tried to always call it 'pd-vanilla/externals', not just 'pd-vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work.
iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere.
since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward.
yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency.
some people could probably find it a bit nasty, that a guy like me, who haven't contributed not a single line of code to the cvs yet, does make such proposals. please excuse me for that (i'm already a bit tired and have had some beers). however, the church of consistency will be founded.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sep 13, 2007, at 2:02 AM, Roman Haefeli wrote:
On Thu, 2007-09-13 at 07:30 +0200, Roman Haefeli wrote:
i tried to always call it 'pd-vanilla/externals', not just 'pd- vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is
described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work.iemlib is a special case, because there is not only the
inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in
order to create a patch, that works on both, it's required to have a
[declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere.since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward.
yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also
some advantages compared to the old standard (am i right here?), let's
skip the old way of creating externals. i thirst for consistency,
really. i am going to found the church of consistency.some people could probably find it a bit nasty, that a guy like me,
who haven't contributed not a single line of code to the cvs yet, does
make such proposals. please excuse me for that (i'm already a bit tired and have had some beers). however, the church of consistency will be founded.
I'll only forgive you if you fix it! ;)
.hc
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i tried to always call it 'pd-vanilla/externals', not just 'pd-vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work.
Currently for Pd-extended it's kind of opaque or mysterious how externals or libraries got their namesspace names. As all the objects need to be in their own directory to not overwrite each others nameclashes, it was natural to takes directory names from CVS and then somehow the directory names got promoted to namespaces, even when the original authors never intended to use their CVS-directory names as namespace. Iemlib is one example, list-abs is another.
Who makes the decision about what words to use as namespace prefixes? The author of the library? Pd-list? Everone on her/his own? Hans?
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sep 13, 2007, at 2:17 AM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i tried to always call it 'pd-vanilla/externals', not just 'pd- vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is
described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work.Currently for Pd-extended it's kind of opaque or mysterious how externals or libraries got their namesspace names. As all the objects need to be in their own directory to not overwrite each others nameclashes, it was natural to takes directory names from CVS and then somehow the directory names got promoted to namespaces, even when the original authors never intended to use their CVS-directory names as namespace. Iemlib is one example, list-abs is another.
Who makes the decision about what words to use as namespace prefixes? The author of the library? Pd-list? Everone on her/his own? Hans?
What happened is that when there were libs that I thought should be
included in Pd-extended, but I had to do the work myself to include
them, I hacked it together. It seems quite apparent now, I made some
bad decisions. Feel free to correct them :-D. (And if you haven't
noticed yet, I'm all about big, toothy grins :-D ).
I think going forward, the author should name her library and that
name should be used for the namespace prefix. There are some rules
that should apply, like no special characters in library names, all
lowercase, etc. I also hope that when people are deciding what to
call their library, they will consult the list. But it is inevitable
that some people won't, so our system should be flexible enough to
support that, not without limits tho.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Sep 13, 2007, at 1:30 AM, Roman Haefeli wrote:
On Thu, 2007-09-13 at 00:49 -0400, Hans-Christoph Steiner wrote:
On Sep 12, 2007, at 12:47 PM, Roman Haefeli wrote:
hi marius, hi iohannes
sorry to chime whitout having participated yet to this discussion at all,
On Wed, 2007-09-12 at 17:17 +0200, IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is
really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package
"iemlib1" to the meta-package "iemlib". i thought this would be impossible, given the structure of the iemlib.let us not be troubled by repackaging of objects.
but i am. it's not only, that objects (or 'classes') used to move
from one to the other, but they exist at two different places at the same time, dependent on whether you are using pd-extended (with libdir format) or pd-vanilla with the original externals. iemlib is a good example, lets stick with this one. [hp1~] is part of 'iemabs' in pd-vanilla and part of 'iemlib' in pd-extended. if you want to use namespaces for instantiating the objects, it doesn't work crosscompatible on both distros. however, this is actually a different story, but probably affects
the way we want to implement the wiki. since there _are_
incompatibilites between pd-vanilla/original libs and pd-extended, i vehemently
propose to decide which route to follow for the database: the 'pd-vanilla/externals' way or the 'pd-extended' way. let's also face who is actually addressed with this database. one of its goals is to
have all information about objects available at one place, which is, i think, fairly essential for people, who are new to pd and want to
explore all facets of pd. i also believe, that most of these people will use pd-extended, since it is by far the easiest way to get 'just everything'. taking into account all these points, i strongly
believe, that it would be the best way to reflect the pd-extended topology in the database, none the less just because people, who compile pd and externals themselves could live more easily with incostistencies between their pd installation and the database than less experienced pd
users.to sum it up, i'd vote for:
[url]/[libname]: description of a library [url]/[libname]/[objectname]: description of the object
(i am not an wiki expert at all and also don't know, if these
proposal can be represented in mediawiki [or i a wiki in generel])why making it flat und having to deal with nameconflicts, when the libdir was introduced in order to just avoid that?
yo, i hope i didn't bring something up, that has been discussed and defined before already, since i missed the major part of the pd-doc meeting.
roman
I agree with this email, but I just want to clarify something. Namespace support is _exactly_ the same on pd-vanilla and pd- extended. Whether you can use the namespace in the object name depends purely on how you compile the libraries, not on whether you are using pd-extended or pd-vanilla. If you are talking pd-vanilla, then you are talking no externals at all.
i tried to always call it 'pd-vanilla/externals', not just 'pd- vanilla', in order to make clear, that i am using pd-vanilla and compiling the externals myself. anyway, if i compile the externals how it is
described in the README, that comes with the externals, and which i call the 'original way' to compile them, i get one library containing several objects, where namespaces don't work.
Again, this is up to the person building them. For example, the
externals that come with Pd in the "extra" folder are built in both
ways. bonk~, fiddle~ are built as single files. The exprs are all
built into one file. Some libraries (ggee, unauthorized) have been
built as single-class-single-file single well before Pd-extended.
iemlib is a special case, because there is not only the
inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in
order to create a patch, that works on both, it's required to have a
[declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere.since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward.
yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency.
Sounds like the iemlibs should be should be split up in Pd-extended,
then it would be consistent. Any volunteers?
.hc
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
On Thu, 2007-09-13 at 11:14 -0400, Hans-Christoph Steiner wrote:
Again, this is up to the person building them. For example, the
externals that come with Pd in the "extra" folder are built in both
ways. bonk~, fiddle~ are built as single files. The exprs are all
built into one file. Some libraries (ggee, unauthorized) have been
built as single-class-single-file single well before Pd-extended.iemlib is a special case, because there is not only the
inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in
order to create a patch, that works on both, it's required to have a
[declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere.since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward.
yo, lets make it simple: shouldn't the one or the other be skipped in cvs? since the libdir is more widely used, i assume, and has also some advantages compared to the old standard (am i right here?), let's skip the old way of creating externals. i thirst for consistency, really. i am going to found the church of consistency.
Sounds like the iemlibs should be should be split up in Pd-extended,
then it would be consistent. Any volunteers?
this not what i was proposing. i was rather referring to this:
Again, this is up to the person building them.
why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sep 13, 2007, at 1:40 PM, Roman Haefeli wrote:
On Thu, 2007-09-13 at 11:14 -0400, Hans-Christoph Steiner wrote:
Again, this is up to the person building them. For example, the externals that come with Pd in the "extra" folder are built in both ways. bonk~, fiddle~ are built as single files. The exprs are all built into one file. Some libraries (ggee, unauthorized) have been built as single-class-single-file single well before Pd-extended.
iemlib is a special case, because there is not only the inconsistency of having namespaces in pd-extended and not having them in 'pd-vanilla/externals', but also different names of libraries. in order to create a patch, that works on both, it's required to have a [declare] with the all these flags: -stdpath iemabs -stdpath iemlib -stdlib iemlib1 -stdlib iemlib2 -stdlib iem_t3_lib just to get iemlib working everywhere.
since [declare] doesn't output an error, when not finding a lib or a path, this can be handled this way, though it is a bit awkward.
yo, lets make it simple: shouldn't the one or the other be
skipped in cvs? since the libdir is more widely used, i assume, and has also
some advantages compared to the old standard (am i right here?), let's
skip the old way of creating externals. i thirst for consistency,
really. i am going to found the church of consistency.Sounds like the iemlibs should be should be split up in Pd-extended, then it would be consistent. Any volunteers?
this not what i was proposing. i was rather referring to this:
Again, this is up to the person building them.
why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why
does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes
and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not.
I am totally with you in spirit, but the issues are social, not
technical. I think that we should purge all old build systems
(they'd still be archived in CVS) and replace them all with a
standard build system. But unfortunately, it has been a very
political issue in the past, so the cruft remained. It seems that
things have changed on the social front somewhat, so maybe now this
could be done.
Are you volunteering to lead the charge? :-D
.hc
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote:
Again, this is up to the person building them.
why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why
does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes
and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not.I am totally with you in spirit, but the issues are social, not
technical. I think that we should purge all old build systems
(they'd still be archived in CVS) and replace them all with a
standard build system. But unfortunately, it has been a very
political issue in the past, so the cruft remained. It seems that
things have changed on the social front somewhat, so maybe now this
could be done.Are you volunteering to lead the charge? :-D
actually i would like to do so, but i have some concerns. first, as i mentioned a few times before, i've never written a line of c code or a makefile or a config-file. my knowledge about this is very limited. and i am not a pd-cvs dev myself and thus do not feel like making my hands dirty on files which have been written and developped carefully by others. and still if i would feel to be able to do it, i would request an admission first from the original author for each library before doing it.
if it's only about deleting makefiles/configures and probably editing the readmes and all pd-cvs people agree, i would do it.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote:
Again, this is up to the person building them.
why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why
does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes
and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not.I am totally with you in spirit, but the issues are social, not
technical. I think that we should purge all old build systems
(they'd still be archived in CVS) and replace them all with a
standard build system. But unfortunately, it has been a very
political issue in the past, so the cruft remained. It seems that
things have changed on the social front somewhat, so maybe now this
could be done.Are you volunteering to lead the charge? :-D
actually i would like to do so, but i have some concerns. first, as i mentioned a few times before, i've never written a line of c code or a makefile or a config-file. my knowledge about this is very limited. and i am not a pd-cvs dev myself and thus do not feel like making my hands dirty on files which have been written and developped carefully by others. and still if i would feel to be able to do it, i would request an admission first from the original author for each library before doing it.
if it's only about deleting makefiles/configures and probably editing the readmes and all pd-cvs people agree, i would do it.
As I see it, it's not about that at all. Basically it's a social and not a technical issue. Namespaces aren't something, that can be enforced technically ATM. They are a convention: Nothing can stop a user to add the directory of some classes to the Pd search path or alternatively put them into a directory and use that dir as a namespace.
Let me explain this taking pdmtl as an (extreme) example: pdmtl can be used with a double namespace: [pdmtl/list/op] but that's not the way the pdmtl people suggest to use it: IIRC you're supposed to use [list/op] instead, as that is, what the help files use. But then, if you do this, pdmtl grabs a whole bunch of possible prefixes, namely these:
2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems, generate, gui, init, input, list, midi, mix, musical, number, random, sample, scale, seq, sf, synth, table, timing, transform
So more than 30 possible prefix names are taken by pdmtl.
The important thing to note here is: This doesn't have anything to do with the way, pdmtl is installed, it's only a matter of how the Pd search path is configured! How to configure the search path is a matter of conventions, and I'm convinced, that as long as the Pd community doesn't agree on conventions, it is not possible to solve.
Frank Barknecht _ ______footils.org_ __goto10.org__
You will be happy to know that the pdmtl abstractions have given up (for a couple of months now) the [pdmtl/list/op] style of naming it's abstractions.
By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea. The ideal solution would be to add alternate names to many externals (like zexy's length could have one additional line of code that would instantiate it with list.length, by registering "list.length" as: class_addcreator((t_newmethod)length_new, gensym("list.length")... But then you would need an editor in chief that would decide what objects get what alternate names. I think the best would be to hold an election for the "editor in chief" that would make all the needed changes.
But honestly I do not think this is going to happen as there are many issues that this thread has already enumerated. In my own opinion, I would say "give up" and find another solution. That's what we did :)
Tom
On 9/15/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Fri, 2007-09-14 at 00:14 -0400, Hans-Christoph Steiner wrote:
Again, this is up to the person building them.
why? what is the benefit of it, when your decision creates inconistencies? since everything seems to be hostet in cvs, why does cvs still support two ways of compiling them? i'd like to know from the devs, if there is any good reason to keep the old makefiles/readmes and stuff in cvs. if people finally would find only one makefile/readme: byebye inconistencies. it automatically wouldn't make a difference anymore, whether you are an pd-extended user or not.
I am totally with you in spirit, but the issues are social, not technical. I think that we should purge all old build systems (they'd still be archived in CVS) and replace them all with a standard build system. But unfortunately, it has been a very political issue in the past, so the cruft remained. It seems that things have changed on the social front somewhat, so maybe now this could be done.
Are you volunteering to lead the charge? :-D
actually i would like to do so, but i have some concerns. first, as i mentioned a few times before, i've never written a line of c code or a makefile or a config-file. my knowledge about this is very limited. and i am not a pd-cvs dev myself and thus do not feel like making my hands dirty on files which have been written and developped carefully by others. and still if i would feel to be able to do it, i would request an admission first from the original author for each library before doing it.
if it's only about deleting makefiles/configures and probably editing the readmes and all pd-cvs people agree, i would do it.
As I see it, it's not about that at all. Basically it's a social and not a technical issue. Namespaces aren't something, that can be enforced technically ATM. They are a convention: Nothing can stop a user to add the directory of some classes to the Pd search path or alternatively put them into a directory and use that dir as a namespace.
Let me explain this taking pdmtl as an (extreme) example: pdmtl can be used with a double namespace: [pdmtl/list/op] but that's not the way the pdmtl people suggest to use it: IIRC you're supposed to use [list/op] instead, as that is, what the help files use. But then, if you do this, pdmtl grabs a whole bunch of possible prefixes, namely these:
2d, 3d, anal, convert, count, data, examples, file, flow, fx, gems, generate, gui, init, input, list, midi, mix, musical, number, random, sample, scale, seq, sf, synth, table, timing, transform
So more than 30 possible prefix names are taken by pdmtl.
The important thing to note here is: This doesn't have anything to do with the way, pdmtl is installed, it's only a matter of how the Pd search path is configured! How to configure the search path is a matter of conventions, and I'm convinced, that as long as the Pd community doesn't agree on conventions, it is not possible to solve.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 2007-09-15 at 11:01 -0400, Thomas O Fredericks wrote:
I would say "give up"
hm.... it seems the only thing i can do here is to become religious and a follower of the church of consistency and wait until all have become members of this church.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
You will be happy to know that the pdmtl abstractions have given up (for a couple of months now) the [pdmtl/list/op] style of naming it's abstractions.
In favour of [list/op]? That's what I wrote. Or did I miss something?
By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea.
Yes. And no, too. I believe, there should be several standard, function-based namespaces. Kind of like pdmtl internally is, but in my opinion, classes in these "STD"-library should have implementations without any dependencies besides Pd core objects. At least that's the guideline I tried with the [list]-abs: Abstractions in that library must not use externals *at all*. (See the end of this mail for my reasoning.)
Then, as an additional layer, versions of these classes could be provided, that do use externals. So there would be two [list/drip] implementations: One using only [list ...], another using [drip] from Zexy for speed reasons. This could then shadow the purepd-version, when Zexy is available, for example in pd-extended. In fact, I'm already using many of these external-enhanced variations of [list]-abs locally.
This way, patches using [list/drip] would run everywhere, even without Zexy. Being dependency-free they could be used by everyone regardless of how this everyone has his/her system and search path configured.
The ideal solution would be to add alternate names to many externals (like zexy's length could have one additional line of code that would instantiate it with list.length, by registering "list.length" as: class_addcreator((t_newmethod)length_new, gensym("list.length")...
I don't really understand which problem alternate names would solve?
But then you would need an editor in chief that would decide what objects get what alternate names. I think the best would be to hold an election for the "editor in chief" that would make all the needed changes.
But honestly I do not think this is going to happen as there are many issues that this thread has already enumerated. In my own opinion, I would say "give up" and find another solution. That's what we did :)
I honestly believe that without an "editor in chief" (which would be a group of editors or a voting process or a document with guidelines or ...) the nameclash and path setup problem for external classes isn't possible to solve. I learned that lesson from looking at how Python, Java, C/C++ and everyone else is giving away standard class namespaces and keywords.
So far we have one "editor in chief" and that is Miller Puckette who decides, what's in Pd-vanilla. Miller is the only constant, that's why Pd-vanilla IMO is the only working base assumption for a "STD"-library as I suggested above.
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
By building the pdmtl abstractions layer, users do not have to care about namespaces anymore (anyways, I don't), as all externals/libraries are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea.
Yes. And no, too.
Oops, forgot to explain why "yes and no". Namespaces based on author/vendor solve nameclashes: "cxc_counter", "maxlib_counter", "cyclone_counter". Namespaces based on functionality don't: Which one of the three above should become "math/counter"?
I think, a STD-library of Pd objects should of course be based on functional namespaces, while vendor-namespaces could be used to let various independent vendors do their own thing without creating conflicts with each other.
All an "editor in chief" would need to do is keep a list of which vendor names are already taken. The "editor in chief" could then be a simple Wiki page on puredata.info. Or not even that, if vendor namespaces are based on things like DNS-names as plists in OS-X.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sep 16, 2007, at 5:59 AM, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
By building the pdmtl abstractions layer, users do not have to
care about namespaces anymore (anyways, I don't), as all externals/libraries
are treated as hidden code to the end user. I still believe that having namespaces based on authors is a bad idea.Yes. And no, too.
Oops, forgot to explain why "yes and no". Namespaces based on author/vendor solve nameclashes: "cxc_counter", "maxlib_counter", "cyclone_counter". Namespaces based on functionality don't: Which one of the three above should become "math/counter"?
I think, a STD-library of Pd objects should of course be based on functional namespaces, while vendor-namespaces could be used to let various independent vendors do their own thing without creating conflicts with each other.
All an "editor in chief" would need to do is keep a list of which vendor names are already taken. The "editor in chief" could then be a simple Wiki page on puredata.info. Or not even that, if vendor namespaces are based on things like DNS-names as plists in OS-X.
Call me an anarchist, but I believe that we can do it without an
editor-in-chief. It just takes some communication and mutual
respect. We've gotten this far with the whole Pd-extended collection
without an editor-in-chief.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Call me an anarchist, but I believe that we can do it without an
editor-in-chief. It just takes some communication and mutual
respect. We've gotten this far with the whole Pd-extended collection
without an editor-in-chief.
Unless one considers you to be the pd-extended editor-in-chief. ;)
An editor-in-chief wouldn't need to be a real person. A wiki page or a textfile in cvs/svn would be enough plus some simple rules. Registering a namespace name would be as simple as writing the name one wants to use plus a contact in there.
Possible simple rules could be:
Additionaly rules could be:
Only remaning issue would be that generic/functional names like "math" or "std" or "pd" are tricky, because they might be needed for a real std-namespace later. Vendor-based names like "footils" are easier in this regard, but mnemonics are worse.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sep 17, 2007, at 12:21 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Call me an anarchist, but I believe that we can do it without an editor-in-chief. It just takes some communication and mutual respect. We've gotten this far with the whole Pd-extended collection without an editor-in-chief.
Unless one considers you to be the pd-extended editor-in-chief. ;)
Yeah... I think that's part of the problem with Pd-extended, that I
have been the de facto editor-in-chief. I think it'll work much
better as more people get involved. I can't keep up on the details
of everyone's libs... :D
An editor-in-chief wouldn't need to be a real person. A wiki page or a textfile in cvs/svn would be enough plus some simple rules. Registering a namespace name would be as simple as writing the name one wants to use plus a contact in there.
Possible simple rules could be:
- announcements should go to pd-dev before registering.
- otherwise first come, first serve.
- everthing that starts with "NAME/" is reserved to the registered project.
- every class that is registered should always be used with "NAME/".
Additionaly rules could be:
- NAMES must start with letter or digit and be all lowercase.
- NAMES starting with an _underscore are for private use (and cannot be registered)
Only remaning issue would be that generic/functional names like "math" or "std" or "pd" are tricky, because they might be needed for a real std-namespace later. Vendor-based names like "footils" are easier in this regard, but mnemonics are worse.
This all sounds excellent, I think this is exactly what would work
well. As for choosing standard namespace names, I think that we
should follow the lazy consensus rule, with required discussion,
i.e., standard lib names should not be automatically accepted unless
there is discussion.
In order for things to get done, I think we need "project leads",
which have similar duties to an editor-in-chief, but I think it
should be more like a community organizer who focuses on organizing
things like the rules for a given library. A key difference would be
that a project lead would not have the complete authority of a editor-
in-chief. The mob that is the Pd community would always have some
say if we want. :)
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This all sounds excellent, I think this is exactly what would work
well. As for choosing standard namespace names, I think that we
should follow the lazy consensus rule, with required discussion,
i.e., standard lib names should not be automatically accepted unless
there is discussion.
I think there is need for discussion when it comes to the classes in standard lib names, as I think, that the std-namespace(s) require(s) a more elaborated style guide/specification.
Two issues come to my mind immediatly. One is that the behaviour of every of these std-objects needs to be discussed before they are finally released into the wild to avoid future complications and possibly incompatible changes and conflicting interfaces like we have with [counter]. (Matju probably would wisely recommend to add tests as well.)
Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the "purepd" or list-abs collections).
That's not because I don't like externals or would want to convince everyone to never touch an external, it's just that a std-library for a programming language should be self-contained. For example if you install Python, a Python programmer can rely on the fact, that all the modules delivered with the core-Python will definitely work. It's still possible to use additional Python modules, but of course none of the core-python modules depends on third-party modules like pyode etc.
Pd distributions like pd-extended or the packages included in the various Linux-distributions may still opt to ship optimized implementations of the std-library classes that use externals. I've already mentioned as an example two versions of [list-drip]: one using no externals as in list-abs and one just wrapping [zexy/drip]. Pd-extended could include the [list-drip] with [zexy/drip] as default, users of e.g. PDa would maybe use the list-abs version. However as a guideline I believe, that every std-class should have a purepd implementation, otherwise it should not be included in that namespace.
As a side note I may add that finding solutions to some tricky problems under the additional restriction to only use builtin objects is a very satisfying experience. It makes you feel like a Master Of The Universe(tm) ;-)
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo,
Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the "purepd" or list-abs collections).
as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that follows from it)
fma.dsr IOhannes
Hallo!
as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that follows from it)
As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport.
But as the others convinced me at the pd conv I don't think that this will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)
LG Georg
Georg Holzmann wrote:
Hallo!
as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that follows from it)
As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport.
that is obviously the idea of the stdlib maintainers.
nevertheless, it assumes that the auther of a certain object would happily give up "their" object and either maintain a stdlibized version or withdraw from maintaining the object alltogether (and someone else maintains the stdlibized version)
i guess, the 1st option is the one we would want to see happen.
nevertheless i have some doubts: often, objects can not simply be "moved" into the stdlib, but they should follow some "standard" (hence the name!) design principles (of the interface). but changing the interface of an object is a heavy modification, which needs a lot of social competence) (i am pretty sure that there are lots of ideas how to make objects in zexy more "consistent" with other objects, however i have spend a lot of time in designing the API (at least for some of them :-))
Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is not necessarily a social permission.
mfgad.sr IOhannes
On Sep 18, 2007, at 9:43 AM, IOhannes m zmoelnig wrote:
Georg Holzmann wrote:
Hallo!
as far as i have understood it, the standard library wants to
duplicate externals: e.g. an object that allows interfacing with the serial
port would be a copy of iem/comport that is named hardware/comport (or
whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that
follows from it)As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport.
that is obviously the idea of the stdlib maintainers.
nevertheless, it assumes that the auther of a certain object would happily give up "their" object and either maintain a stdlibized
version or withdraw from maintaining the object alltogether (and someone else maintains the stdlibized version)i guess, the 1st option is the one we would want to see happen.
nevertheless i have some doubts: often, objects can not simply be "moved" into the stdlib, but they should follow some "standard" (hence the name!) design principles (of the interface). but changing the interface of an object is a heavy modification, which needs a lot of social competence) (i am pretty sure that there are lots of ideas how to make objects in zexy more "consistent" with other objects, however i have spend a
lot of time in designing the API (at least for some of them :-))
They key difference would be that each stdlib would have a
standardized interface, and each objectclass would conform to that
interface. For example, there could be an 'io' standard lib.
Everything in that lib would respond to [open(, [close(, etc. in the
same way, the first inlet would behave similarly, and the first
outlet would be the data in the form of lists, and the second outlet
would be status info in the form of lists.
So no, I don't think we should just copy over existing code without
change. Instead, we should use existing code when it's useful, but
focus on having a clean and consistent interface for each library.
Then the old "author's name" libraries, like iem, zexy, ggee, etc.
would remain in place for backwards compatibility.
Pd-externals are usually FLOSS. this gives us the technical permission to duplicate the code. it is
not necessarily a social permission.
Why use a free license then? That just needlessly complicates
things. If someone doesn't want people freely using their code, then
they should say so overtly. Not, "my license says you can use my
code, but if you do, then I'll get mad and work against you".
.hc
mfgad.sr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
On Tue, 18 Sep 2007, Hans-Christoph Steiner wrote:
They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists.
That's also called an "interface", a "protocol", a "contract", or an "abstract class".
For example, if I have [comport], [tcpsocket] and [file] classes, all three of which implement the io protocol, then any of those three can be called "an io object", or "an object of the io class", and each of those three's helpfiles can refer to the io protocol help file instead of copy-pasting each other, and then you have help files about classes that are not implementations and which you can't instantiate because they only exist documentation-wise, and that's alright. That's a direction that I advocate for PDDP.
This concept is independent from namespaces. It has to, to some extent, because often a class will implement multiple protocols. Even in the io department, you can split the io interface into "readable", "writable", "seekable", etc.; then it's better to have the namespace go with a category of classes that are related by their protocol relationships, but don't necessarily all implement a same single protocol.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport.
Yes, that would be the idea for binaries in the std-lib.
But as the others convinced me at the pd conv I don't think that this will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)
Depends on how you define "this": I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther ("flatspace" in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions).
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sep 18, 2007, at 11:04 AM, Frank Barknecht wrote:
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
As far as I undestood it the code of e.g. comport would go in this standard lib (e.g. to hardware/comport) but should not duplicate the code - instead the iem/comport code should be obsolete and now maintained in hardware/comport.
Yes, that would be the idea for binaries in the std-lib.
But as the others convinced me at the pd conv I don't think that this will happen soon (and "soon" in pd time means maybe 8-10 years ... ;)
Depends on how you define "this": I don't think that every external has to move over to stdlib immediately, if at all. comport would be a good example for an external that could stay outside the stdlib for the next 8-10 years without any bigger problems, as it is an object with a rather specific purpose. [drip] OTOH would be a candidate to take immediately. The old build-system by Guenther ("flatspace" in pd-extended) already showed the how the whole stdlib could be built as far as externals are concerned, and abstractions are dead easy to handle (as long as they are core-Pd-abstractions).
It's all a matter of perspective. I use [comport] all the time and
really want a [io/serial] that is based on comport, but has a clean,
standardized interface in common with all IO objects (i.e. same basic
messages, inlets, outlets, etc.). I have never used [drip], so it
doesn't matter to me whether that was included now or in 10 years.
Whether iem/comport is maintained is also a non-issue. If someone
wants to do the work to maintain both, why stop them?
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
On Sep 18, 2007, at 8:23 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo,
Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the "purepd" or list-abs collections).
as far as i have understood it, the standard library wants to
duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or
whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that follows from it)
They key difference would be that each stdlib would have a
standardized interface, and each objectclass would conform to that
interface. For example, there could be an 'io' standard lib.
Everything in that lib would respond to [open(, [close(, etc. in the
same way, the first inlet would behave similarly, and the first
outlet would be the data in the form of lists, and the second outlet
would be status info in the form of lists.
So no, I don't think we should just copy over existing code without
change. Instead, we should use existing code when it's useful, but
focus on having a clean and consistent interface for each library.
Then the old "author's name" libraries, like iem, zexy, ggee, etc.
would remain in place for backwards compatibility.
.hc
fma.dsr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Hans-Christoph Steiner wrote:
On Sep 18, 2007, at 8:23 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo,
Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the "purepd" or list-abs collections).
as far as i have understood it, the standard library wants to duplicate externals: e.g. an object that allows interfacing with the serial port would be a copy of iem/comport that is named hardware/comport (or whatever). thus it would not rely on "3rd party" externals, but on stdlib "internal" libraries. (with duplicate code and everything that follows from it)
They key difference would be that each stdlib would have a standardized interface, and each objectclass would conform to that interface. For example, there could be an 'io' standard lib. Everything in that lib would respond to [open(, [close(, etc. in the same way, the first inlet would behave similarly, and the first outlet would be the data in the form of lists, and the second outlet would be status info in the form of lists.
So no, I don't think we should just copy over existing code without change. Instead, we should use existing code when it's useful, but focus on having a clean and consistent interface for each library.
thats what i meant with "duplicate externals"
mfga.dr IOhannes
On Sep 18, 2007, at 6:26 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
This all sounds excellent, I think this is exactly what would work well. As for choosing standard namespace names, I think that we should follow the lazy consensus rule, with required discussion, i.e., standard lib names should not be automatically accepted unless there is discussion.
I think there is need for discussion when it comes to the classes in standard lib names, as I think, that the std-namespace(s) require(s) a more elaborated style guide/specification.
Two issues come to my mind immediatly. One is that the behaviour of every of these std-objects needs to be discussed before they are finally released into the wild to avoid future complications and possibly incompatible changes and conflicting interfaces like we have with [counter]. (Matju probably would wisely recommend to add tests as well.)
Another issue would be the use of objects not in Pd core in such a standard library. In my opinion and for reasons I mentioned several times during the last days a Pd-std-library should work without third-party externals (like the "purepd" or list-abs collections).
That's not because I don't like externals or would want to convince everyone to never touch an external, it's just that a std-library for a programming language should be self-contained. For example if you install Python, a Python programmer can rely on the fact, that all the modules delivered with the core-Python will definitely work. It's still possible to use additional Python modules, but of course none of the core-python modules depends on third-party modules like pyode etc.
Pd distributions like pd-extended or the packages included in the various Linux-distributions may still opt to ship optimized implementations of the std-library classes that use externals. I've already mentioned as an example two versions of [list-drip]: one using no externals as in list-abs and one just wrapping [zexy/drip]. Pd-extended could include the [list-drip] with [zexy/drip] as default, users of e.g. PDa would maybe use the list-abs version. However as a guideline I believe, that every std-class should have a purepd implementation, otherwise it should not be included in that namespace.
As a side note I may add that finding solutions to some tricky problems under the additional restriction to only use builtin objects is a very satisfying experience. It makes you feel like a Master Of The Universe(tm) ;-)
We would not have Gem, PDP, PiDiP, hid, ann, pdogg, streaming, theora/
speex/mp3 externals, etc. if we did not allow externals to use non-
core libraries. Instead of arbitrary restrictions, we should make an
environment where people can count on having the libraries they need
in the same place on every machine. This is a key thing about Java,
Debian, etc. and this is the core purpose of Pd-extended.
I think it's a good idea to try to use the core functions over other
libraries, but it would needlessly restrict possibilities of what
people can do with Pd to limit which libraries can be used.
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
We would not have Gem, PDP, PiDiP, hid, ann, pdogg, streaming, theora/ speex/mp3 externals, etc. if we did not allow externals to use non- core libraries.
Nowhere did I say that. All I'm suggesting is, that a std-library of externals and abstractions must be self-contained: It must include everything that is needed to run it (except Pd). Add to that that ideally this lib would also run on pure-Pd, abstractions must use only core objects or externals from the std-lib itself, nothing else.
Note that I don't see the std-lib as a pd-distribution itself. It's not meant to be a duplicate of what pd-extended does. Pd-extended could include the stdlib, but not define what the stdlib is.
Instead of arbitrary restrictions, we should make an
environment where people can count on having the libraries they need
in the same place on every machine. This is a key thing about Java,
Debian, etc. and this is the core purpose of Pd-extended.
I don't think a std-library can be restricted to one pd-distribution only. This would be the same as if Python's os-module would only run on Debian. Wouldn't be a problem to me, but it would be for many others.
Frank Barknecht _ ______footils.org_ __goto10.org__
Marius and I had a powwow about the pdpedia structure of the pages,
and I think we are in agreement with this proposal. Here's the outline:
http://pdpedia.at.or.at/test/index.php/Main_Page
object names, the canonical page for each object would be the
'mylibrary/myobject' format, then there would also be a 'myobject'
page, which would be a redirect or a disambiguation page, depending
on the circumstance.
wikipedia. Then for things that need disambiguation, there would be
things tacked on, like wikipedia, like 'float (selector)'.
lowercase. The problem is that wikipedia doesn't use mediawiki that
way, so it might have strange problems. We'll see...
pdpedia. Libraries that are not in Pd-extended should follow the
same naming scheme, i.e. mylibrary/myobject.
.hc
On Sep 12, 2007, at 11:17 AM, IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several
years, then it could be arbitrary. but some objects jump around. from
zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible,
given the structure of the iemlib.let us not be troubled by repackaging of objects.
all in all, if the system cannot handle renames, we should dump it immediately
but then, wikipedia does handle renames, e.g.: http://en.wikipedia.org/wiki/Puredata http://en.wikipedia.org/wiki/Pure_Data
why not keep a flat structure:
because we could at the same time put library and object information into the same database? .../pdp => doc on the pdp lib .../pdp/pdp_qt => doc on a certain object.
the title of the page does not represent the real name of the object anyway. wiki does not support titles/pages starting with lowercase letters. that means the real object name will be shown at some place inside the page content. therefore we can call the page counter (markex) which will show up as: http://pdpedia.at.or.at/test/index.php/Counter_%28markex%29 or counter.maxlib. or maxlib.counter.
what exactly is the difference between maxlib.counter and maxlib/ counter?
can mediawiki handle both?
only information. therefor if structure helps the understanding like (math/plus) then structure is good. but as I said before structure
for categories is not really possible, so better no structure...my only argument is: the grouping structure of objects is the one the original author has made explicit by grouping them together in a
library.it is not related to structure, but to the possibilities for
searchingright
and displaying objects and libraries. and to page design.
well, even though in times of phishing i daresay that few people will actually look at the link. and the page need not reflect the link anyhow. (i guess that the page "/maxlib/counter" will display "counter" as
title)the important thing is to have a good search engine!
that was the reason why I did not want to go for the wiki at
first. but the wiki has more advantages on other points.hmm, the wiki search engine does a full text search and you can
specify multiword queries. this should pretty much do... (at least i got quite used to getting multiple hits when i google :-)) what else do you want to find?mfga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
Marius and I had a powwow about the pdpedia structure of the pages,
and I think we are in agreement with this proposal. Here's the outline:http://pdpedia.at.or.at/test/index.php/Main_Page
- Basically, it's as much like wikipedia as possible. For class/
object names, the canonical page for each object would be the
'mylibrary/myobject' format, then there would also be a 'myobject'
page, which would be a redirect or a disambiguation page, depending
on the circumstance.
- about caps, I figured out how to make mediawiki keep things all
lowercase. The problem is that wikipedia doesn't use mediawiki that
way, so it might have strange problems. We'll see...
- like roman said, I think that all things Pd are welcome in the
pdpedia. Libraries that are not in Pd-extended should follow the
same naming scheme, i.e. mylibrary/myobject.
looks great to me.
fmgasd.r IOhannes
Hans-Christoph Steiner wrote:
- like roman said, I think that all things Pd are welcome in the
pdpedia. Libraries that are not in Pd-extended should follow the
same naming scheme, i.e. mylibrary/myobject.
what happened to this scheme? has it just been forgotten at the import process, or has it been deprecated in favour of myobject_(mylibrary)?
and how can i find the different counters?
mfga.dsr IOhannes
it turned out to be easier to drop it (at least for the beginning - it still can be implemented with redirects). the double entries will be distinguished by disambiguation pages and the myobject_(mylibrary) scheme. here is a list of candidates for disambiguation pages (so far). has to be done menually... not mentioned are the object that appear in flatspace and another library...
OBJECTCLASS / LIBRARY / WIKINAME
<~ cyclone (signal smaller than) (cyclone) <~ zexy (signal smaller than) (zexy)
~ cyclone (signal greater than) (cyclone) ~ zexy (signal greater than) (zexy)
==~ cyclone ==~ (cyclone) ==~ zexy ==~ abs~ markex abs~ (markex) abs~ zexy abs~ (zexy) abs~ creb abs~ (creb) atan2~ ggee atan2~ (ggee) atan2~ cyclone (sickle) atan2~ (cyclone) average maxlib average (maxlib) average markex average (markex) avg~ cyclone (sickle) avg~ (cyclone) avg~ zexy avg~ (zexy) borax maxlib borax (maxlib) Borax cyclone (hammer) Borax (cyclone) change vanilla change (vanilla) change markex change (markex) clip vanilla clip (vanilla) Clip cyclone (hammer) Clip (cyclone) clip~ vanilla clip~ (vanilla) Clip~ cyclone (sickle) Clip~ (cyclone) counter cyclone (hammer) counter (cyclone) counter markex counter (markex) gate iemlib gate (iemlib) gate cyclone (hammer) gate (cyclone) line~ vanilla line~ (vanilla) Line~ cyclone (sickle) Line~ (cyclone) mean cyclone (hammer) mean (cyclone) mean zexy mean (zexy) prob mjlib prob (mjlib) prob cyclone (hammer) prob (cyclone) reson~ cyclone (sickle) reson~ (cyclone) reson~ markex reson~ (markex) scale maxlib scale (maxlib) scale gem scale (gem) Scope~ cyclone (sickle) Scope~ (cyclone) scope~ vanilla scope~ (vanilla) sinh ggee sinh (ggee) sinh cyclone (hammer) sinh (cyclone) Snapshot~ cyclone (sickle) Snapshot~ (cyclone) snapshot~ vanilla snapshot~ (snapshot) speedlim cyclone (hammer) speedlim (cyclone) speedlim maxlib speedlim (maxlib) speedlim iemlib speedlim (iemlib) split maxlib split (maxlib) split cyclone (hammer) split (cyclone) split iemlib split (iemlib) urn maxlib urn (maxlib) urn cyclone (hammer) urn (cyclone) urn zexy urn (zexy)
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
- like roman said, I think that all things Pd are welcome in the
pdpedia. Libraries that are not in Pd-extended should follow the
same naming scheme, i.e. mylibrary/myobject.what happened to this scheme? has it just been forgotten at the import process, or has it been deprecated in favour of myobject_(mylibrary)?
and how can i find the different counters?
mfga.dsr IOhannes
Hallo, marius schebella hat gesagt: // marius schebella wrote:
the double entries will be distinguished by disambiguation pages and the myobject_(mylibrary) scheme. here is a list of candidates for disambiguation pages (so far). has to be done menually...
Idea: An interesting thing to do cross-references would be objects, that behave the same, but possibly are called differently. For example the abstraction [urne] from rtc-lib is a vanilla-Pd clone of [urn] from Cyclone, but it's different from [urn] in Zexy. Some way to point user to these things could be nice.
Frank Barknecht _ ______footils.org__
I agree. To cross-reference you can just add the link to the objectclass page or use "what links here", which would give you all internal wiki connections. to gather information like this is part of the pdpedia process. I am trying to do some pages every week, and I think other people will also start contributing. still, it will take some time until pdpedia will have more quality... marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
the double entries will be distinguished by disambiguation pages and the myobject_(mylibrary) scheme. here is a list of candidates for disambiguation pages (so far). has to be done menually...
Idea: An interesting thing to do cross-references would be objects, that behave the same, but possibly are called differently. For example the abstraction [urne] from rtc-lib is a vanilla-Pd clone of [urn] from Cyclone, but it's different from [urn] in Zexy. Some way to point user to these things could be nice.
Ciao
On Oct 8, 2007, at 11:31 AM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
the double entries will be distinguished by disambiguation pages
and the myobject_(mylibrary) scheme. here is a list of candidates for disambiguation pages (so far). has to be done menually...Idea: An interesting thing to do cross-references would be objects, that behave the same, but possibly are called differently. For example the abstraction [urne] from rtc-lib is a vanilla-Pd clone of [urn] from Cyclone, but it's different from [urn] in Zexy. Some way to point user to these things could be nice.
Yes, that would be nice, please contribute! :D
.hc
Ciao
Frank Barknecht _
______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Oct 8, 2007, at 6:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
- like roman said, I think that all things Pd are welcome in the
pdpedia. Libraries that are not in Pd-extended should follow the
same naming scheme, i.e. mylibrary/myobject.what happened to this scheme? has it just been forgotten at the import process, or has it been
deprecated in favour of myobject_(mylibrary)?
Since mediawiki is built around the myobject_(mylibrary) idea, we
decided to use that as the canonical page name. Then things like
alphasort in category pages work nicely. For the mylibrary/myobject
name format, those can easily be redirect pages. I supposed those
should all be created via a script...
and how can i find the different counters?
Searching for "counter" works pretty well (unfortunately, "Go" is the
default when you hit enter):
http://wiki.puredata.info/en/Special:Search? search=counter&fulltext=Search
Here's an example of how it can work:
http://wiki.puredata.info/en/counter http://wiki.puredata.info/en/counter_%28cyclone%29 http://wiki.puredata.info/en/counter_%28markex%29 http://wiki.puredata.info/en/cyclone/counter
.hc
mfga.dsr IOhannes
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
Hans-Christoph Steiner wrote:
On Oct 8, 2007, at 6:00 AM, IOhannes m zmoelnig wrote:
and how can i find the different counters?
Searching for "counter" works pretty well (unfortunately, "Go" is the
default when you hit enter):
i see. what does "Go" mean?
http://wiki.puredata.info/en/Special:Search? search=counter&fulltext=Search
Here's an example of how it can work:
ah ok, now the disambiguation is here. last time i tried it was only the cyclone object, and the "search" (or was it "go"?) just returned that page, so i only got that object.
ah cool. i guess creating these pages and redirecting to <object>_(<library>) has to be done manually?
mfg.adsr IOhannes
On Oct 9, 2007, at 12:57 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Oct 8, 2007, at 6:00 AM, IOhannes m zmoelnig wrote:
and how can i find the different counters?
Searching for "counter" works pretty well (unfortunately, "Go" is
the default when you hit enter):i see. what does "Go" mean?
http://wiki.puredata.info/en/Special:Search?
search=counter&fulltext=Search Here's an example of how it can work: http://wiki.puredata.info/en/counterah ok, now the disambiguation is here. last time i tried it was
only the cyclone object, and the "search" (or was it "go"?) just
returned that page, so i only got that object.ah cool. i guess creating these pages and redirecting to <object>_ (<library>) has to be done manually?
mfg.adsr IOhannes
I can be done via a script and an import. Currently, you need ssh
access to run an import. Since pdpedia is on an IDMI/Poly server,
IDMI accounts have shell access, but I can't give out others. That
means Marius and I have import access.
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hi. I haven't been too active with Pd lately, but I just got a P5 glove and a new idea, so back I come. I'm very happy to see this discussion. All I have to add is that, if there is a good search engine, I'll love it. Personally, when I'm looking for a particular external, or to find an external for a particular purpose, I don't bother wading through categories. Perhaps a search that is able to filter for .dll, .c, UNIX executables, etc.? Or to search for libraries that contain a particular object. I'm burned on Google, it gives me too much. I wonder if that might be improved if, in tandem with creating new references, some of the old ones would be taken offline, or even just tagged with links to more recent resources.
-Chuckk
On 9/13/07, Hans-Christoph Steiner hans@eds.org wrote:
Marius and I had a powwow about the pdpedia structure of the pages, and I think we are in agreement with this proposal. Here's the outline:
http://pdpedia.at.or.at/test/index.php/Main_Page
- Basically, it's as much like wikipedia as possible. For class/
object names, the canonical page for each object would be the 'mylibrary/myobject' format, then there would also be a 'myobject' page, which would be a redirect or a disambiguation page, depending on the circumstance.
- Everything else would go into the same room namespace, like
wikipedia. Then for things that need disambiguation, there would be things tacked on, like wikipedia, like 'float (selector)'.
- about caps, I figured out how to make mediawiki keep things all
lowercase. The problem is that wikipedia doesn't use mediawiki that way, so it might have strange problems. We'll see...
- like roman said, I think that all things Pd are welcome in the
pdpedia. Libraries that are not in Pd-extended should follow the same naming scheme, i.e. mylibrary/myobject.
.hc
On Sep 12, 2007, at 11:17 AM, IOhannes m zmoelnig wrote:
marius schebella wrote:
how stable is the library structure? if it is stable over several years, then it could be arbitrary. but some objects jump around. from zexy to iem (mtx?), from iemlib1 to iemlib (don't know if that is really the case...) from iemlib to puredata core (gui)... from everywhere to "flatspace".
wow: zexy had the matrix objects for several years (they first appeared therein in 2001; and they vanished by 2005) iemmatrix has the matrix objects for several years too (2005-today)
iemlib consists of 3 binary libraries (iemlib1, iemlib2, iem_t3) and a collection of abstractions; this has not changed since i know this library (which is quite some time) i don't know which object has moved from the sub-package "iemlib1" to the meta-package "iemlib". i thought this would be impossible, given the structure of the iemlib.
let us not be troubled by repackaging of objects.
all in all, if the system cannot handle renames, we should dump it immediately
but then, wikipedia does handle renames, e.g.: http://en.wikipedia.org/wiki/Puredata http://en.wikipedia.org/wiki/Pure_Data
why not keep a flat structure:
because we could at the same time put library and object information into the same database? .../pdp => doc on the pdp lib .../pdp/pdp_qt => doc on a certain object.
the title of the page does not represent the real name of the object anyway. wiki does not support titles/pages starting with lowercase letters. that means the real object name will be shown at some place inside the page content. therefore we can call the page counter (markex) which will show up as: http://pdpedia.at.or.at/test/index.php/Counter_%28markex%29 or counter.maxlib. or maxlib.counter.
what exactly is the difference between maxlib.counter and maxlib/ counter?
can mediawiki handle both?
only information. therefor if structure helps the understanding like (math/plus) then structure is good. but as I said before structure for categories is not really possible, so better no structure...
my only argument is: the grouping structure of objects is the one the original author has made explicit by grouping them together in a library.
it is not related to structure, but to the possibilities for searching
right
and displaying objects and libraries. and to page design.
well, even though in times of phishing i daresay that few people will actually look at the link. and the page need not reflect the link anyhow. (i guess that the page "/maxlib/counter" will display "counter" as title)
the important thing is to have a good search engine!
that was the reason why I did not want to go for the wiki at first. but the wiki has more advantages on other points.
hmm, the wiki search engine does a full text search and you can specify multiword queries. this should pretty much do... (at least i got quite used to getting multiple hits when i google :-)) what else do you want to find?
mfga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/09/2007, at 16.57, marius schebella wrote:
well, yes. some objects are not maintained any more, some are deprecated... for these objects we could jump to the recently used object, for others, like counter, gate, we can have the
disambiguation page.
I suggest a disambiguation page in any case. Reason: To not hide the
fact that other objects with the same name exist in a "see also"
section. - There are several reasons for that.
Also the information (not maintained, deprecated, most used, etc) can
be put in the disambiguation page together with the lib name.
On Wed, 12 Sep 2007, marius schebella wrote:
I am TOTALLY against the word class or selector in any structure layout!!! totally confusing for 99% of the users.
Because all users are totally unwilling to learn any new concept! that's why they go read on pdpedia, isn't it?
gahh.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada