[PD] mapping: path setting hell

[Hans-Christoph Steiner]

On Apr 9, 2009, at 2:33 AM, cyrille henry wrote:

>
>
> Hans-Christoph Steiner a écrit :
>> On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:
>>>
>>>
>>> Hans-Christoph Steiner a écrit :
>>>
>>>> Inside of the objects themselves, I use always the [mapping/ 
>>>> reverse] form.  Only in the help patches do I use the [reverse]  
>>>> form.  That convention seemed to make sense at the time, but I am  
>>>> not married to it.
>>>
>>> since all mapping object are in the same directory, using the   
>>> [reverse] form inside the object will still work on pd-extended.
>>> but it will also make the mapping lib more flexible (you'll be  
>>> able to move the objects / copy them in your patch directory ). So  
>>> i see this as a big improvement of the situation.
>>>
>>> do you agree if i change this?
>> Unfortunately, that's not entirely true, otherwise I would say to  
>> change it.  Right now, a binary object will trump ANY abstraction,  
>> even if it is in the same directory.  So if someone loads a binary  
>> object called "reverse", then [reverse] will ALWAYS be that binary,  
>> so matter where you put reverse.pd or how you load it.  [mapping/ 
>> reverse] prevents that.
> name clash are bad.
> curently it's a fact.
> things may change in the future, but now nameclash must be avoid.
>
> since there already are nameclash, it's important for a user to have  
> a full control of the object used.
> i do this by copying abstraction in my patch folder.
> it also allow my patch to work latter, when the abstraction have  
> changed.

Copying the abstraction into the same folder as the project will not  
prevent the problem I described above.  As things are, that's not a  
solution. I think it'll work most of time, like most of these methods  
we discuss back and forth.

The namespace prefix like [mapping/reverse] is also not infallable,  
but it is a lot less likely to be affected by nameclashes, since there  
would have to be both a folder and a file named the same.  It seems to  
me a good starting place.  In any case, nameclashes are an old issue,  
many people have tackled it, I think we can learn from them and make a  
Pd-ish implementation of namespaces/import that is not complicated.

I think we can make a solution that always works.  I am not satisfied  
with just using the current situation.  I've been burned too many  
times in projects and while teaching workshops and classes by name  
conflicts.  The output~ one is a recent example.

.hc


>> This is a perfect case of why we should change the load order in Pd.
> ok.
> change it if you wish. but don't find workaround with solution that  
> work only for you.
>
> sorry if i'm rude, but i'm more and more irritated by this problem.
> c
>
>> I think it should search for all object types in a given path  
>> (i.e. .pd .pd_linux, .pd_lua, etc.)  THEN it should search the next  
>> path.  Currently the opposite happens: it searches .pd_linux in all  
>> paths, then the loaders (i.e. .pd_lua) in all paths, then the  
>> abstractions in all paths.
>> .hc
>> ---------------------------------------------------------------------------- "[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
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list





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

'You people have such restrictive dress for women,’ she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - “Hijab Scene #2", by Mohja Kahf