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