howdy, as a remaining extended 0.42-5 user, I'm just now realizing how vanilla works when loading externals with the same name as a vanilla object or some other preloaded library - I have to say it was a surprise to see that it's different that how extended works, and that it doesn't seem like a good idea...
Anyway, you see, I got here zexy 2.2.6 (as a library) and cyclone (individual binaries but also has the nettles library) on vanilla 0.46-7 - both external libraries have abs~ (which is also a vanilla object) or an object like [>~] (part of nettles in cyclone). Both zexy and nettles are loaded via startup.
So funny stuff can happen... like, vanilla's abs~ is overwritten by zexy's and renamed to abs~_aliased, but if I call cyclone's abs~ specifying its folder as [cyclone/abs~], it overwrites zexy's abs~ and it is never possible to call zexy's abs~ ever again...
Ok, in the case of abs~ I think it should be removed from both cyclone and zexy, because it's not only that they share the same name between each other and a vanilla object, but they all do the same thing as the internal object... so it's completely redundanct - but this is another issue. One way or another, it helps illustrating my point.
So, moving on to the case of [>~], we see from previous discussions that they need to be loaded as libraries for sanity's sake. But then I can never specify which [>~] I want - if both are via startup or declare, I can never be sure or control which one I'm specifying as either >~ or >~_aliased...
The point is: perhaps there could be a better way to force vanilla to load an internal object?
Or if not a vanilla object, perhaps that could be a way to specify and object inside one external library or another?
The way things are, it's all just really out of control and I can think of many scenarios where patches need to be edited when loaded because of what's going on in that particular machine, such as what patch had been opened before, etc... I know this probably has been discussed for ages and many people had already thought about it... I also know I have NO clue on the technical details and what has already been done, but I would like to ask and suggest things.
What would make sense to me is that vanilla objects would always prevail and be called with priority. This is how things were in Extended (and now pd-l2ork I guess) - externals with the same name as a vanilla objects could only be called only if explicitly specified.
In the case of cyclone's [line~] it's easy to specify if you wan cyclone's version or not by specifying the folder [cyclone/line~]
But the problem is when you're using a library, because you seemingly can't specify a given loaded external library when instantiating an object... such as [zexy/<~] or [nettles/<~] - and yes, they are different, by the way, before anyones asks ;)
So, in short, all could be sorted and taken care if:
1- vanilla objects are never overwritten 2- external objects can be specified by a path even if they are loaded as a library with declare or via the startup (ex: zexy/<~ or nettles/<~)
cheers
hello,
overwriting a vanilla object is relatively new feature. Newer than last pd-extended, that's why it did not make it to extended. pd-l2ork is more recent, so i guess it use all latest vanilla feature. I think the aim is to be able to create object that are more optimized than native one. Or that add functionalities. Of course, one can use this feature to completely break pd.
"rm -rf /" is a command that will completely break your computer, but it will not be remove from your OS, because no one sane would try it. it's the same for pd : no one sane would write a [+] object that did not add number. but it's possible to develop a [+] object that add number and string.
there is no problem overwriting a vanilla object as long as you keep compatibilities. if you don't keep vanilla compatibilities, chances are that no one will use your externals, since it will cause more problem than anything else. So, i don't see any problem overwriting vanilla objects, as long as object developers don't do anything stupid.
anyhow, it make sens to be able to load zexy/<~ or nettles/<~ even if zexy and nettles are loaded as a lib. but [<~] is not vanilla, so this is an other discussion than vanilla object being overwritten.
and for this specific object, what make more sense to me is to use a small abstraction made around tabread~ and a 2 points table. 100% vanilla. 0% trouble.
cheers cyrille
Le 06/04/2016 00:51, Alexandre Torres Porres a écrit :
howdy, as a remaining extended 0.42-5 user, I'm just now realizing how vanilla works when loading externals with the same name as a vanilla object or some other preloaded library - I have to say it was a surprise to see that it's different that how extended works, and that it doesn't seem like a good idea...
Anyway, you see, I got here zexy 2.2.6 (as a library) and cyclone (individual binaries but also has the nettles library) on vanilla 0.46-7 - both external libraries have abs~ (which is also a vanilla object) or an object like [>~] (part of nettles in cyclone). Both zexy and nettles are loaded via startup.
So funny stuff can happen... like, vanilla's abs~ is overwritten by zexy's and renamed to abs~_aliased, but if I call cyclone's abs~ specifying its folder as [cyclone/abs~], it overwrites zexy's abs~ and it is never possible to call zexy's abs~ ever again...
Ok, in the case of abs~ I think it should be removed from both cyclone and zexy, because it's not only that they share the same name between each other and a vanilla object, but they all do the same thing as the internal object... so it's completely redundanct - but this is another issue. One way or another, it helps illustrating my point.
So, moving on to the case of [>~], we see from previous discussions that they need to be loaded as libraries for sanity's sake. But then I can never specify which [>~] I want - if both are via startup or declare, I can never be sure or control which one I'm specifying as either >~ or >~_aliased...
The point is: perhaps there could be a better way to force vanilla to load an internal object?
Or if not a vanilla object, perhaps that could be a way to specify and object inside one external library or another?
The way things are, it's all just really out of control and I can think of many scenarios where patches need to be edited when loaded because of what's going on in that particular machine, such as what patch had been opened before, etc... I know this probably has been discussed for ages and many people had already thought about it... I also know I have NO clue on the technical details and what has already been done, but I would like to ask and suggest things.
What would make sense to me is that vanilla objects would always prevail and be called with priority. This is how things were in Extended (and now pd-l2ork I guess) - externals with the same name as a vanilla objects could only be called only if explicitly specified.
In the case of cyclone's [line~] it's easy to specify if you wan cyclone's version or not by specifying the folder [cyclone/line~]
But the problem is when you're using a library, because you seemingly can't specify a given loaded external library when instantiating an object... such as [zexy/<~] or [nettles/<~] - and yes, they are different, by the way, before anyones asks ;)
So, in short, all could be sorted and taken care if:
1- vanilla objects are never overwritten 2- external objects can be specified by a path even if they are loaded as a library with declare or via the startup (ex: zexy/<~ or nettles/<~)
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2016-04-05 20:37 GMT-03:00 cyrille henry ch@chnry.net:
pd-l2ork is more recent, so i guess it use all latest vanilla feature.
not really, seems pd-l2ork hasn't been kept up to date to any specific vanilla versio, like extended used to, so it's definitely a forkk per se. And for what I tried, pd-l2ork behaves like extended 0.42-5, what I'm using as a basis for comparison. I also tried vanilla 0.42-5 and saw that it already have the overwriting feature, so I assumed is something they didn't want in extended (0.43 still didn't have the overwritting, huh?).
I think the aim is to be able to create object that are more optimized than native one. Or that add functionalities.
Seems not healthy in any way. If you want to make a better pd, well, you can chose different names for externals, or really just fork it.
In general, I don't see any good reason to have externals with the same name as vanilla internals, other than max/msp clones like good old cyclone
- but the way to deal with in extended worked fine, if you want line~ that
is compatible to max, use cyclone/line~
Of course, one can use this feature to completely break pd.
yep
it's possible to develop a [+] object that add number and string.
also possible to give it another name, or even to call [+] in a way that is not overwritting an internal.
there is no problem overwriting a vanilla object as long as you keep compatibilities.
well, for one, cyclone/line~ is not compatible.
So, i don't see any problem overwriting vanilla objects, as long as object developers don't do anything stupid.
well, I pointed some existing issues that lies outside what you pictured... and there is also other issues besides internals.
anyhow, it make sens to be able to load zexy/<~ or nettles/<~ even if zexy and nettles are loaded as a lib. but [<~] is not vanilla, so this is an other discussion than vanilla object being overwritten.
another discussion, but quite parallel and that arise from the same matter.
and for this specific object, what make more sense to me is to use a small
abstraction made around tabread~ and a 2 points table. 100% vanilla. 0% trouble.
well, it really makes sense to me not to bother to think of a vanilla abstraction to substitute 2 existing externals that I already have...
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...
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.
Way things are now, we have NO control whatsoever and this is bad. You cannot guarantee that your patches will work as they should anywhere. It would be good to attack this problem by actually allowing control to the user, instead of being happy with laboring workarounds that don't really solve anything and might even create more hassle...
I can think of many options to allow control to the user. Not allowing vanilla objects to be overwritten is one. Allowing a user to choose an object from a specific library os another. Both would solve this... and seems like the best solution to me. On the other hand, I cannot think, yet, of any good reason to leave things the way they are.
cheers
Le 06/04/2016 06:09, Alexandre Torres Porres a écrit :
So, i don't see any problem overwriting vanilla objects, as long as object developers don't do anything stupid.well, I pointed some existing issues that lies outside what you pictured... and there is also other issues besides internals.
I see many example of the same issues, but not many issues.
overwriting internals did not change anything in library clash-name problem.
but yes, there is a problem in cyclone. using cyclone as a libdir solve the name conflict problem, but not "weird" name object. using cyclone as a regular lib solve the weird name, but not conflict.
well, it really makes sense to me not to bother to think of a vanilla abstraction to substitute 2 existing externals that I already have...
i think it take less time to write a 2 object abstraction than sending this kind of mails.
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 ;-)
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.
Way things are now, we have NO control whatsoever and this is bad.
they have control : load a lib if you want to use it. did not load it if you did not want to.
You cannot guarantee that your patches will work as they should anywhere. the ONLY solution to work everywhere is not to use external. 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.
It would be good to attack this problem by actually allowing control to the user, instead of being happy with laboring workarounds that don't really solve anything and might even create more hassle...
I understand that you are upset because it break cyclone, but except that, it's a nice feature (that should only be use wisely)
I can think of many options to allow control to the user. Not allowing vanilla objects to be overwritten is one. Allowing a user to choose an object from a specific library os another. Both would solve this... and seems like the best solution to me. On the other hand, I cannot think, yet, of any good reason to leave things the way they are.
usually, it take me 10 years to understand why miller made the right choice ;-)
cheers c
cheers
2016-04-06 7:11 GMT-03:00 cyrille henry 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.
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!
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.
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.
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
I still do not see any advantage in object overwritting, and I see how it is causing name clashes.
cheers
Le 06/04/2016 17:53, Alexandre Torres Porres a écrit :
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 problemNo 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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 ch@chnry.net:
Le 06/04/2016 17:53, Alexandre Torres Porres a écrit :
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-nameproblem.
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 problemNo 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 thesame 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 havesome control over what objects and externals to call.
yes, obviously. it's the case when using libdir format, but not whenusing 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 thansending 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 shouldanywhere. 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 andload 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, butexcept 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 rightchoice ;-)
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
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
Here's a workaround to call [cyclone/line~] in pd-vanilla without overwritting vanilla's [line~]
First, a little history...
Seems cyclone was first designed with First Capital letters object names to avoid name clashing, such as [Line~], this was present in Extended up to version Pd-Extended 0.42-5 (cyclone's version was then 0.1alpha 55).
In Pd Extended 0.43 (and cyclone 0.1 alpha 56), cyclone also included two aliases for Line~ and other name clahsing objects, so it could instantiate also as only "line~". But the thing is that vanilla's [line~] would have priority and never be overwritten. Using [cyclone/line~] here would allow you to call cyclone's [line~] without screwing with vanilla's.
What I found out is that cyclone, in this version, also carries another alias "cyclone/line~"
this does not call a line~ object inside the cyclone folder, but calls "cyclone/line~" inside cyclone.
So I supressed the "line~" alias and kept me with "Line~" (original object name) and "cyclone/line~" (alias), then tested on vanilla 0.46-7 64 bits and 32 bits.
Now, if I call [Line~] on vanilla, it loads cylone's line~ without overwritting vanilla's [line~]. And I can also call it as [cyclone/line~] that vanilla's [line~] keeps intact and not overwritten!
I tested the same compiled object in Pd Extended 0.42-5 (I don't use 0.43) and it worked fine as well.
Thus, a quick immediate fix for this is changing the alias inside cyclone... seems like a workaround, but doesn't look that good I have to say...
Besides cyclone, I don't know why anyone else would create externals with the same name as a vanilla internal...
I still think that overwritting and renaming to "x_aliased" is not a good idea.
The incapacity to specify objects inside regular libs is an old thing, I think it could be a nice feature request.
cheers
2016-04-06 14:51 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
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 ch@chnry.net:
Le 06/04/2016 17:53, Alexandre Torres Porres a écrit :
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-nameproblem.
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 problemNo 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 notconflict.
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 thesame 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 tohave some control over what objects and externals to call.
yes, obviously. it's the case when using libdir format, but not whenusing 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 thansending 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 shouldanywhere. 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 andload 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, butexcept 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 rightchoice ;-)
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
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
regarding a workaround between zexy's <~ and cyclone's I can also think of a workaround
in Max/MSP there are alphanumeric versions of those objects, such as [greaterthan~]. So they can be compiled as single objects, allowing someone to specify it as cyclone/greaterthan~ if needed/desired.
these would solve clashing issues I found with cyclone and vanilla/zexy
but other overwritting potential issues remain
cheers
2016-04-06 15:44 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Here's a workaround to call [cyclone/line~] in pd-vanilla without overwritting vanilla's [line~]
First, a little history...
Seems cyclone was first designed with First Capital letters object names to avoid name clashing, such as [Line~], this was present in Extended up to version Pd-Extended 0.42-5 (cyclone's version was then 0.1alpha 55).
In Pd Extended 0.43 (and cyclone 0.1 alpha 56), cyclone also included two aliases for Line~ and other name clahsing objects, so it could instantiate also as only "line~". But the thing is that vanilla's [line~] would have priority and never be overwritten. Using [cyclone/line~] here would allow you to call cyclone's [line~] without screwing with vanilla's.
What I found out is that cyclone, in this version, also carries another alias "cyclone/line~"
this does not call a line~ object inside the cyclone folder, but calls "cyclone/line~" inside cyclone.
So I supressed the "line~" alias and kept me with "Line~" (original object name) and "cyclone/line~" (alias), then tested on vanilla 0.46-7 64 bits and 32 bits.
Now, if I call [Line~] on vanilla, it loads cylone's line~ without overwritting vanilla's [line~]. And I can also call it as [cyclone/line~] that vanilla's [line~] keeps intact and not overwritten!
I tested the same compiled object in Pd Extended 0.42-5 (I don't use 0.43) and it worked fine as well.
Thus, a quick immediate fix for this is changing the alias inside cyclone... seems like a workaround, but doesn't look that good I have to say...
Besides cyclone, I don't know why anyone else would create externals with the same name as a vanilla internal...
I still think that overwritting and renaming to "x_aliased" is not a good idea.
The incapacity to specify objects inside regular libs is an old thing, I think it could be a nice feature request.
cheers
2016-04-06 14:51 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
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 ch@chnry.net:
Le 06/04/2016 17:53, Alexandre Torres Porres a écrit :
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-nameproblem.
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 problemNo 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 notconflict.
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 thesame 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 tohave some control over what objects and externals to call.
yes, obviously. it's the case when using libdir format, but notwhen 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 thansending 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 shouldanywhere. 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 andload 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, butexcept 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 theright 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
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
Le 06/04/2016 19:51, Alexandre Torres Porres a écrit :
it's cool cyrille, sorry if I was too upset and harsh by the way :)
no problem! cheers c
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 <ch@chnry.net mailto:ch@chnry.net>:
Le 06/04/2016 17:53, Alexandre Torres Porres a écrit : 2016-04-06 7:11 GMT-03:00 cyrille henry <ch@chnry.net <mailto:ch@chnry.net> <mailto: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. 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 _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, Apr 6, 2016 at 11:53 AM, Alexandre Torres Porres porres@gmail.com wrote:
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
I still do not see any advantage in object overwritting, and I see how it is causing name clashes.
I propose that the following two rules for naming Pd externeals will solve all your problems: 1 The name MUST begin with a lowercase alphabetical ASCII character (a-z). Subsequent characters may be lowercase ASCII, numbers (0-9) or underscore (_). DSP objects MUST have a trailing tilde (~) character. 2. The name MUST be unique among Pd externals.
Martin
-
Alexandre Torres Porres -
cyrille henry -
Martin Peach