[PD] Obscure pd externals in search path shadow .pd files in current working directory

[Hans-Christoph Steiner]

This is addressed in the Pd-extended distribution.  Every library is  
compiled so that each class is compiled as it's own file (i.e.  
[counter] = counter.pd_linux) instead of having multiple classes in  
one file.

Functional namespaces already exist in Pd.  This feature is used  
extensively in Pd-extended.  It's based on directory names, then  
the / is the separator.  The 'libdir' format allows a directory of  
objects to act like a library.

There has been quite a bit of discussion about this topic over the  
years, search the archive if you are interested.

.hc


On Aug 31, 2007, at 3:09 PM, Julius Smith wrote:

> Hi All,
>
> In figuring out why seqdemo.pd did not work (in the cool
> faust/tools/faust2pd/examples distribution), I discovered that the  
> local
> file ./seq.pd was being shadowed
> by /usr/lib/pd/extra/cyclone/seq.pd_linux.  It appears that, due to
> search order, all externals, wherever they may reside in the search
> path, take precedence over .pd files, even those in the current  
> working
> directory.  It seems to me both externals and subpatches in the cwd
> should take precedence over the rest of the search path. Also, I would
> expect subpatches to take precedence over externals in the same
> directory (with a warning about the shadowing printed to the console).
>
> My workaround, by the way, was to rename seq.pd to seqr. pd in the
> seqdemo directory.
>
> Cheers,
> Julius
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli