[PD] inconsistencies with lib names (was: representning classes and selectors in the wiki)

Roman Haefeli reduzierer at yahoo.de
Thu Sep 13 07:30:57 CEST 2007


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





More information about the Pd-list mailing list