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

[Hans-Christoph Steiner]

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