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@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
