[PD] representning classes and selectors in the wiki

[Hans-Christoph Steiner]

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
>
>
> _______________________________________________
> PD-list at iem.at 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