Le 06/04/2016 17:53, Alexandre Torres Porres a écrit :
oups, sorry.
2016-04-06 7:11 GMT-03:00 cyrille henry <ch@chnry.net <mailto:ch@chnry.net>>:
I see many example of the same issues, but not many issues.
ok, an issue (name clashing) that has many examples it is then.
overwriting internals did not change anything in library clash-name problem.
it did introduce the problem of name clashing between objects, being it internal x external, or even between externals themselves - seems it just made things worse.
The way things are, name clashing is up for chance, it's a gamble.
but yes, there is a problem in cyclone.
using cyclone as a libdir solve the name conflict problem
No it does not! Seems you're not grasping the issues I'm raising.
right. it did create one more problem between extern and intern.
it look like cyclone and vanilla dis not mix well together.
yes, right.
If I call [cyclone/line~] it will overwrite vanilla's [line~], and [cyclone/line~] is not compatible to vanilla's - so name clashing and incompatibility issues arise.
This is one thing between internal x external objects. If there was a way to specify [vanilla/line~], them great! Problem solved. But you do not have any control on how to call vanilla line~ once it's been overwritten.
using cyclone as a regular lib solve the weird name, but not conflict.
the case with regular libs, whatever they are, is that you can't specify them when loading a particular object, at least I don't know how to do that. So again you have name clashing when objects aere overwritten.
And I can also remember several other external objects with the same name that aren't compatible - such as "uzi" as an alias of kalashnikov or uzi from cyclone...
they all obsolete since vanilla introduce [until], 10 years ago ;-)
No it's not obsolete as [uzi] has many features [until] doesn't have. See... I get that Not using the externals is "a" solution, and one that I actually thought of, but not the one I was after when raising this issue. My motivations is finding a way to use externals and avoid name clashing, so not using externals is not a valid solution for this issue.
it just makes a lot of sense to me tha Pd allows the user to have some control over what objects and externals to call.
yes, obviously. it's the case when using libdir format, but not when using regular lib. this is bad.
again, you seemed to not have realized that libdir also introduces issues - so it is bad too, and it wasn't before!
according to the mailing list, this feature was introduce in vanilla 0.42, and was briefly discuss 6 years ago.
i did not find any other reference in this list since.
its a good thing to raise - and solve - issues.
i think it take less time to write a 2 object abstraction than sending this kind of mails.
good for you, let me be the one to raise the issues then. I just hope you are not saying I shouldn't bother raising issues I'm having to hopefully getting them sorted out.
and i understand why you are upset with things been like that.
You cannot guarantee that your patches will work as they should anywhere.
the ONLY solution to work everywhere is not to use external.
So far it's true, that's actually part of my point, things needed to change to allow us a way to guarantee it
if you do, the most safe solution is to load pd with -noprefs and load preference per patch.
overwriting internals did not increase this problem, no solve it.
Overwriting internals did increase problems and made new issues arise. At least in Extended and Pd-l2ork I can specify if I want cylone/line~ or vanilla line~ - it'd be nice too if Pd-l2ork offered a way to load a particular external from a specific regular lib or another. With such both features, we'd have a safe and guaranteed solution
I understand that you are upset because it break cyclone, but except that, it's a nice feature (that should only be use wisely)
yeah, but it's not really nice if it introduces issues and losses. and what would you lose if you could specify wether you wanted an object from vanilla or one library or another?
I get it that you do not have personal issues with the way things are, that you are coping with it, but I'm not like that.
ok, i'm sorry i could not help.
usually, it take me 10 years to understand why miller made the right choice ;-)
Hey buddy, I'm open... but I need more than things like:
- Got a problem with externals? Do not use the externals then;
- Yeah, you do have a problem and I don't have a solution, but other than that, the thing you are complaining about is nice.
- I, personally, don't mind the issue, and I think that some workarounds are worth it
- You might not agree it is nice now, and I'm not really trying to prove any point, but maybe if you give it 10 years you might change your mind
cheers
c
I still do not see any advantage in object overwritting, and I see how it is causing name clashes.
cheers
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list