[PD] mapping: path setting hell
Hans-Christoph Steiner
hans at eds.org
Fri Apr 10 04:42:48 CEST 2009
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
More information about the Pd-list
mailing list