it's cool cyrille, sorry if I was too upset and harsh by the way :) Well, I actually seem to have found a trick... testing it right now! Stay tuned...
2016-04-06 14:36 GMT-03:00 cyrille henry <[email protected]>: > > > Le 06/04/2016 17:53, Alexandre Torres Porres a écrit : > >> >> >> 2016-04-06 7:11 GMT-03:00 cyrille henry <[email protected] <mailto: >> [email protected]>>: >> >> 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. >> > oups, sorry. > right. it did create one more problem between extern and intern. > it look like cyclone and vanilla dis not mix well together. > > > >> 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! >> > yes, right. > > 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. > > >> 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. >> > its a good thing to raise - and solve - issues. > > >> 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. >> > and i understand why you are upset with things been like that. > > > >> 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 >> > ok, i'm sorry i could not help. > > cheers > c > > > > >> I still do not see any advantage in object overwritting, and I see how it >> is causing name clashes. >> >> cheers >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
