[PD] using namespace prefixes in a vanilla setup

[Hans-Christoph Steiner]

On May 6, 2009, at 1:54 AM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> On May 5, 2009, at 12:09 PM, Steffen Juul wrote:
>>>
>>> On 02/05/2009, at 3.31, Hans-Christoph Steiner wrote:
>>>
>>>> So here's the solution i came up with, you
>>>> make a 'lib' folder in your project, stick the libraries as folders
>>>> in
>>>> 'lib', then use [declare -path lib].  Here's an example:
>>>>
>>>> http://puredata.info/Members/hans/vanilla_libdir.tar.bz2
>>>
>>> But what about "sorry, couldn't find help patch for "mapping/
>>> curve.pd"" ?
>>
>>
>> I should have said, due to bugs in [declare], this only works on GNU/
>> Linux.  Since Miller uses Linux, I was assuming that its the  
>> reference
>> platform in terms of how [declare] works.  It currently works
>> differently/less on Mac OS X, for example.
>
> What are these differences? In our RjDj sprints, most people use OS- 
> X with no
> problems, and on Linux, the help files still aren't found either -  
> which is a
> known issue of directory prefixes since ages: You have to set the  
> help-path as
> well.

Ah yes, sorry there was a little crack smoking on my part. There are  
so many myriad details to the current arrangement, I forgot some.   I  
don't think the outstanding bugs in declare were affecting this issue:

https://sourceforge.net/tracker/index.php?func=detail&aid=1714473&group_id=55736&atid=478070
https://sourceforge.net/tracker/index.php?func=detail&aid=1828573&group_id=55736&atid=478070
https://sourceforge.net/tracker/index.php?func=detail&aid=1917574&group_id=55736&atid=478072

So help files work with the namespace prefixes with .pd_linux objects,  
but not with abstractions. This is how IOhannes organized Gem in Pd- 
extended and it works well there.  For example, consider these files  
in the same setup as the original vanilla_libdir example:

lib/cyclone/prepend.pd_linux
lib/cyclone/prepend-help.pd
lib/mapping/local_min.pd
lib/mapping/local_min-help.pd

Then [declare -path lib]
[cyclone/prepend]
[mapping/local_min]

The help patch will work for the binary external [cyclone/prepend] but  
not for the abstraction [mapping/local_min].  For the libdir loader,  
it sets the helppath so this will work with loading libdirs as  
libraries with the help patches embedded.

>>> But if libraries have complicated interdependencies or assume  
>>> certain
>>> global
>>> path layouts, then this approach fails, which was the case with the
>>> old mapping
>>> files, at least partly.
>>
>> Part of my point with this examples is to show that you can have a
>> simple setup while using namespace prefixes in the project,  
>> libraries as
>> folders, and in the libraries that a project uses.  I couldn't find  
>> any
>> issues with the setup illustrated in that tarball, have you found  
>> some?
>
> "mapping" still assumes that it is installed in a subdirectory  
> called "mapping"
> whose parent is in the search path. It's not possible for a user to  
> just drop
> the patches from "mapping" into her project folder directly or into a
> differently named subdir made know with declare. A user has to  
> mimick the
> directory layout set in mapping. And do so for purepd as well.  
> That's not a
> problem with the tarball, it just a - deliberate - restriction of  
> "mapping".

Well, its not really a 'mapping' question so much as a question of  
using folders as libraries.  This is to address a very real and  
problematic issue caused by the fact that a binary external will  
_always_ override an abstraction of the same name, no matter what the  
setup.  In the interest of making the libraries like 'mapping' and  
'purepd' function in as many setups as possible, organizing them to  
use namespace prefixes is the only existing method that I know of for  
dealing with this issue.  For me the key question is how to make this  
organization work easily for people on multiple setups.

To quote previous emails to describe this issue:
http://lists.puredata.info/pipermail/pd-dev/2009-04/013432.html

 >> With abstractions the situation is worse.  If you make your  you  
make your
 >> abstraction called [threshold] and include it in the same folder as
 >> your project.  Then you use a patch that uses smlib's [threshold]
 >> and close it.  Reopen your patch and [threshold] will be the smlib
 >> one, _not_ your threshold.pd.  Or say Miller adds [threshold] to Pd-
 >> vanilla, same story, except there is no way to ever load your
 >> threshold.pd, unless you stick into a folder and call it [myfolder/
 >> threshold].

.hc


>
>
> Ciao
> -- 
> Frank
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



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

Mistrust authority - promote decentralization.  - the hacker ethic