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 > > > _______________________________________________ > [email protected] 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
