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