Dear list,
I'm trying to make my abstraction library vanilla-compatible, but nevertheless I need to use some externals. Since I didn't keep up with the vanilla progress the last years, I wanted to ask what is the best method to make sure that all externals are loaded:
- use [declare ....]?
- use namespaces such as [list-abs/list1]?
I imagine that for libraries compiled into one external file the best alternative is declare, such as with Gem: [declare -stdlib Gem -stdlib zexy]. But for cases where the objects are separated, is there a conceptual/political/pratical difference between declaring and using namespaces in the object name? (I'm used to namespaces so that I know immediately from which library the object comes, but I can change that)
Adding to that: I'm still using mainly Pd-ext, and trying to branch out to vanilla and purr-data. Which is the best method to try to be compatible with these 3 distributions? E.g. [declare -stdlib Gem -stdlib zexy] works quite well on van+ext, but [declare -stdlib iemmatrix] doesn't in pd-ext; I must add a [iemmatrix] object to load the library. Is this a iemmatrix bug, or the [declare] object from pd-ext is too old?
Also: I imagine that there isn't a problem with repeated declarations? Inside each abstraction there is a [declare], and a patch can always use lots of them.
A suggestion: I can write [declare -stdlib xxxxx], and there will be no error message warning that the xxxxx library doesn't exist. Would it be good to have an error message, or even open deken to search for it?
Best,
Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
writing [cyclone/gate] has two advantages: 1) better documentation, 2) forces the cyclone version to be called and warns if the cyclone version is not found (instead of loading another external/abstraction with the same name which happens to be in the search path)
Christof
Gesendet: Dienstag, 02. Januar 2018 um 09:54 Uhr Von: "João Pais" jmmmpais@gmail.com An: pd-list@mail.iem.at Betreff: [PD] declare vs. namespaces - current best practice
Dear list, I'm trying to make my abstraction library vanilla-compatible, but nevertheless I need to use some externals. Since I didn't keep up with the vanilla progress the last years, I wanted to ask what is the best method to make sure that all externals are loaded:- use [declare ....]?- use namespaces such as [list-abs/list1]? I imagine that for libraries compiled into one external file the best alternative is declare, such as with Gem: [declare -stdlib Gem -stdlib zexy]. But for cases where the objects are separated, is there a conceptual/political/pratical difference between declaring and using namespaces in the object name?(I'm used to namespaces so that I know immediately from which library the object comes, but I can change that) Adding to that: I'm still using mainly Pd-ext, and trying to branch out to vanilla and purr-data. Which is the best method to try to be compatible with these 3 distributions?E.g. [declare -stdlib Gem -stdlib zexy] works quite well on van+ext, but [declare -stdlib iemmatrix] doesn't in pd-ext; I must add a [iemmatrix] object to load the library. Is this a iemmatrix bug, or the [declare] object from pd-ext is too old? Also: I imagine that there isn't a problem with repeated declarations? Inside each abstraction there is a [declare], and a patch can always use lots of them. A suggestion: I can write [declare -stdlib xxxxx], and there will be no error message warning that the xxxxx library doesn't exist. Would it be good to have an error message, or even open deken to search for it? Best, Joao
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
questions
2018-01-02 8:02 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it?
now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205 & https://github.com/pure-data/pure-data/pull/183
cheers, happy 2018
what do you mean by [declare cyclone]?
in case you mean [declare -stdpath cyclone]: a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer) b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "João Pais" jmmmpais@gmail.com, pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
questions 2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D. won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it? now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205%5Bhttps://github.com/pure-da...] & https://github.com/pure-data/pure-data/pull/183%5Bhttps://github.com/pure-da...] cheers, happy 2018
the current situation with namespacing is a bit unsatisfying. let's assume there are libraries 'foo' and 'bar' which both have an object called 'obj'. if both are multi-binary libraries then both objects can be created with [foo/obj] and [bar/obj]. this doesn't work, however, with single-binary libraries. you have to write [obj] and if library 'foo' is loaded first, 'obj' from library 'bar' can never be created.
a solution could be to encourage library writers who favor the single-binary style to add creators with the library name prepended, like
obj_class = class_new(gensym("obj"), (t_newmethod)obj_new, (t_method)obj_free, sizeof(t_obj), 0, A_GIMME, 0); class_addcreator((t_newmethod)obj_new, gensym("foo/obj"), A_GIMME, 0);
so users have a chance to deal with possible name collisions.
IOhannes did this in zexy with [zexy/pack] and [zexy/unpack] (for slightly different reasons), that's where I got this idea.
having no real namespacing for single-binary libraries is actually a bit crazy, given the very generic names of many objects.
Gesendet: Dienstag, 02. Januar 2018 um 16:37 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Alexandre Torres Porres" porres@gmail.com Cc: pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
what do you mean by [declare cyclone]?
in case you mean [declare -stdpath cyclone]: a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer) b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "João Pais" jmmmpais@gmail.com, pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
questions 2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D. won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it? now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205%5Bhttps://github.com/pure-da...] & https://github.com/pure-data/pure-data/pull/183%5Bhttps://github.com/pure-da...] cheers, happy 2018
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Happy 2018 list!!!
IMO [foo/obj] is the “best practice”.
@Christof I'm having inconsistent results for single-binary libs (iemlib). Some obj are working and some not. See pic attached.
[pic attached]
--
Mensaje telepatico asistido por maquinas.
On 1/2/2018 1:01 PM, Christof Ressi wrote:
the current situation with namespacing is a bit unsatisfying. let's assume there are libraries 'foo' and 'bar' which both have an object called 'obj'. if both are multi-binary libraries then both objects can be created with [foo/obj] and [bar/obj]. this doesn't work, however, with single-binary libraries. you have to write [obj] and if library 'foo' is loaded first, 'obj' from library 'bar' can never be created.
a solution could be to encourage library writers who favor the single-binary style to add creators with the library name prepended, like
obj_class = class_new(gensym("obj"), (t_newmethod)obj_new, (t_method)obj_free, sizeof(t_obj), 0, A_GIMME, 0); class_addcreator((t_newmethod)obj_new, gensym("foo/obj"), A_GIMME, 0);
so users have a chance to deal with possible name collisions.
IOhannes did this in zexy with [zexy/pack] and [zexy/unpack] (for slightly different reasons), that's where I got this idea.
having no real namespacing for single-binary libraries is actually a bit crazy, given the very generic names of many objects.
Gesendet: Dienstag, 02. Januar 2018 um 16:37 Uhr Von: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at An: "Alexandre Torres Porres" porres@gmail.commailto:porres@gmail.com Cc: pd-list@mail.iem.atmailto:pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
what do you mean by [declare cyclone]?
in case you mean [declare -stdpath cyclone]: a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer) b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr Von: "Alexandre Torres Porres" porres@gmail.commailto:porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.atmailto:christof.ressi@gmx.at Cc: "João Pais" jmmmpais@gmail.commailto:jmmmpais@gmail.com, pd-list@mail.iem.atmailto:pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
questions
2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>mailto:christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]:Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it?
now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205%5Bhttps://github.com/pure-da...] & https://github.com/pure-data/pure-data/pull/183%5Bhttps://github.com/pure-da...]
cheers, happy 2018
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 01/02/2018 07:34 PM, Lucas Cordiviola wrote:
Happy 2018 list!!!
IMO [foo/obj] is the “best practice”.
i find [list-abs/list-splat] to be certainly bad practice.
i don't think there is one general "best practice" for these kind of things (with the current state of affairs).
I'm having inconsistent results for single-binary libs (iemlib). Some obj are working and some not. See pic attached.
because iemlib, even when compiled as a single-binary is *not only* a single binary, but also comes with a number of abstractions.
with iemlib and some other libs like zexy, but also Gem (which tries to do that for you by magicking), the "best practice" is to load both the library and add the path and then use the objects without a prefix (aka namespace).
fgmrdsa IOhannes
i find [list-abs/list-splat] to be certainly bad practice.
but why?
just to be sure: we're talking about use in libraries. IMHO it's better to be extra careful and add the namespace when possible.
to answer Lucas' question about why both [cyclone/!-~] and [!-~] is working:
looking at the source code, it turns out they have been doing exactly what I just proposed: adding a creator with the prepended library name.
just to give another real world example: someone writes a library and wants [wrap] from zexy (with the additional second inlet). I'm loading both iemlib and zexy on startup and for some reason iemlib's [wrap] happens to take precedence, breaking the library. the library author doesn't have a chance to force the zexy version.
I think this a big problem - which can be solved by what the cyclone maintainers did. This is not so much important for zexy and iemlib (as they are widely known and a library authors will always try to avoid name clashes with them) but for future libraries. There are so many Pd libraries out there and name clashes are almost guaranteed without some sort of namespacing.
Gesendet: Dienstag, 02. Januar 2018 um 19:53 Uhr Von: "IOhannes m zmölnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
On 01/02/2018 07:34 PM, Lucas Cordiviola wrote:
Happy 2018 list!!!
IMO [foo/obj] is the “best practice”.
i find [list-abs/list-splat] to be certainly bad practice.
i don't think there is one general "best practice" for these kind of things (with the current state of affairs).
I'm having inconsistent results for single-binary libs (iemlib). Some obj are working and some not. See pic attached.
because iemlib, even when compiled as a single-binary is *not only* a single binary, but also comes with a number of abstractions.
with iemlib and some other libs like zexy, but also Gem (which tries to do that for you by magicking), the "best practice" is to load both the library and add the path and then use the objects without a prefix (aka namespace).
fgmrdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I agree with Christof, [foo/obj] not only makes sure that that obj is loaded, it also remind you or other one using your patch which library comes from and its name to find it in deken.
--
Mensaje telepatico asistido por maquinas.
On 1/2/2018 4:28 PM, Christof Ressi wrote:
i find [list-abs/list-splat] to be certainly bad practice.
but why?
just to be sure: we're talking about use in libraries. IMHO it's better to be extra careful and add the namespace when possible.
to answer Lucas' question about why both [cyclone/!-~] and [!-~] is working:
looking at the source code, it turns out they have been doing exactly what I just proposed: adding a creator with the prepended library name.
just to give another real world example: someone writes a library and wants [wrap] from zexy (with the additional second inlet). I'm loading both iemlib and zexy on startup and for some reason iemlib's [wrap] happens to take precedence, breaking the library. the library author doesn't have a chance to force the zexy version.
I think this a big problem - which can be solved by what the cyclone maintainers did. This is not so much important for zexy and iemlib (as they are widely known and a library authors will always try to avoid name clashes with them) but for future libraries. There are so many Pd libraries out there and name clashes are almost guaranteed without some sort of namespacing.
Gesendet: Dienstag, 02. Januar 2018 um 19:53 Uhr Von: "IOhannes m zmölnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
On 01/02/2018 07:34 PM, Lucas Cordiviola wrote:
Happy 2018 list!!!
IMO [foo/obj] is the “best practice”.
i find [list-abs/list-splat] to be certainly bad practice.
i don't think there is one general "best practice" for these kind of things (with the current state of affairs).
I'm having inconsistent results for single-binary libs (iemlib). Some obj are working and some not. See pic attached.
because iemlib, even when compiled as a single-binary is *not only* a single binary, but also comes with a number of abstractions.
with iemlib and some other libs like zexy, but also Gem (which tries to do that for you by magicking), the "best practice" is to load both the library and add the path and then use the objects without a prefix (aka namespace).
fgmrdsa IOhannes
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
2018-01-02 12:37 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
what do you mean by [declare cyclone]?
in case you mean [declare -stdpath cyclone]:
I meant adding a library as path or a lib, either in -stdpath / -path / -stdlib / -lib (is there a difference in behaviour between them?)
a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer)
why?
b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "João Pais" jmmmpais@gmail.com, pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
questions
2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]>:Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it?
now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205%5Bhttps: //github.com/pure-data/pure-data/pull/205] & https://github.com/pure- data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
cheers, happy 2018
2018-01-04 18:41 GMT-03:00, Christof Ressi christof.ressi@gmx.at:
(is there a difference in behaviour between them?)
stdlib is relative to the 'standard paths' whereas path is relative to the current patch.
my point is that the user could have their libraries in a totally different place so that none of [declare -path/-stdpath/-lib/-stdlib cyclone] will work.
I see, but this is kinda parallel, and we're currently discussing changes to how the path works, as I referred to in the links I sent before.
What I'm just questioning is wether using [declare] will force and avoid name collisions. I went ahead and made a test to make sure if what I said actually happens.
So, I created a dummy abstraction named gate, put it inside a library that is listed in the path’s preferences, then I took cyclone out of the listed paths.
Then what happens when I call [gate] is that it finds this dummy abstraction instead!
Now, what I did next is I added [declare -path cyclone] (no -stdpath) and [declare] now forces it to find [gate] from cyclone instead.
So, yeah, this is what I said it’d would and should do, so I checked and it does happen for me.
Therefore, using [declare] will avoid name collisions and not the opposite.
cheers
Gesendet: Donnerstag, 04. Januar 2018 um 22:14 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-list@mail.iem.at Betreff: Re: Re: [PD] declare vs. namespaces - current best practice
2018-01-02 12:37 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
what do you mean by [declare cyclone]?
in case you mean [declare -stdpath cyclone]:
I meant adding a library as path or a lib, either in -stdpath / -path / -stdlib / -lib (is there a difference in behaviour between them?)
a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer)
why?
b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "João Pais" jmmmpais@gmail.com, pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
questions
2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>:Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).
IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.
regarding namespaces:
In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example: Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it?
now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205%5Bhttps://github.com/pure-da...] & https://github.com/pure-data/pure-data/pull/183%5Bhttps://github.com/pure-da...]
cheers, happy 2018
how so? please elaborate...
In my example I had a dummy abstraction in a lib listed in the path, but declare made it not call it.
are you saying this only happens cause it is an abstraction?
Because I made the test with a compiled object and I got the same behaviour, no difference!
The compiled object from the lib listed in the path doesn't get called, and the one specified in [declare] gets called instead.
cheers
2018-01-04 20:03 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 01/04/2018 11:56 PM, Alexandre Torres Porres wrote:
Therefore, using [declare] will avoid name collisions and not the
opposite.
only for abstractions.
gfadsmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
The compiled object from the lib listed in the path doesn't get called, and the one specified in [declare] gets called instead.
repeat the test with two abstractions having loading libraries providing the same object. e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd uses a [gate] stub that prints "gate 2". load abs1.pd, after that abs2.pd (either manually, or by putting them into a master patch). observe the console.
fgamdsr IOhannes
ok, that changes things a bit.
It is still true that [declare] will prioritize to first load an object from that specified lib (let's call it lib1), even if there's another one (lib2) with the same object listed in the path. But this only happens if none of these objects have been called before.
So this is still safe if you're sharing a patch to be first opened on its own.
Now, things get hard to control if you've forced to load the object from lib2 beforehand, then try to load the other one from lib1 without a prefix and trying to rely on [declare]. But this also depends wether it is an abstraction or not, and, as I see it, that is inconsistent behaviour.
Not only that, but I could also ask wether this is more of an issue on how Pd handles the object search than how [declare] works.
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I would assume that's what it had to do.
cheers
2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
The compiled object from the lib listed in the path doesn't get called,
and
the one specified in [declare] gets called instead.
repeat the test with two abstractions having loading libraries providing the same object. e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd uses a [gate] stub that prints "gate 2". load abs1.pd, after that abs2.pd (either manually, or by putting them into a master patch). observe the console.
fgamdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On 01/06/2018 04:04 AM, Alexandre Torres Porres wrote:
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
maybe. it would require a complete rewrite of the the object loading, with a hierarchical class loading system. a non-trivial task.
gfamdsr IOhannes
2018-01-06 7:15 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 01/06/2018 04:04 AM, Alexandre Torres Porres wrote:
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
maybe. it would require a complete rewrite of the the object loading, with a hierarchical class loading system. a non-trivial task.
cool, maybe it's time I open a new issue on github and we'll see where that goes
So this is still safe if you're sharing a patch to be first opened on its own.
in other words: it's not safe at all ;-)
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
namespacing by definition involves some kind of extra typing (like it or not) to differentiate entities that otherwise would look the same. the current mechanism of prepending the folder name already supports that, only single-binary libraries are sometimes a problem. cyclone already shows how this can be dealt with effectivly by adding a second creator (e.g. "cyclone/gate") Christof
Gesendet: Samstag, 06. Januar 2018 um 04:04 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
ok, that changes things a bit. It is still true that [declare] will prioritize to first load an object from that specified lib (let's call it lib1), even if there's another one (lib2) with the same object listed in the path. But this only happens if none of these objects have been called before. So this is still safe if you're sharing a patch to be first opened on its own. Now, things get hard to control if you've forced to load the object from lib2 beforehand, then try to load the other one from lib1 without a prefix and trying to rely on [declare]. But this also depends wether it is an abstraction or not, and, as I see it, that is inconsistent behaviour. Not only that, but I could also ask wether this is more of an issue on how Pd handles the object search than how [declare] works. And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it? I would assume that's what it had to do. cheers 2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at]>:On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
The compiled object from the lib listed in the path doesn't get called, and the one specified in [declare] gets called instead.
repeat the test with two abstractions having loading libraries providing the same object. e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd uses a [gate] stub that prints "gate 2". load abs1.pd, after that abs2.pd (either manually, or by putting them into a master patch). observe the console.
fgamdsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
edit: [declare] can (and is) also effectively used as a kind of C++ using directive or python wildcard import - which is sometimes useful but nonetheless eliminates namespacing.
Gesendet: Samstag, 06. Januar 2018 um 11:53 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Alexandre Torres Porres" porres@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
So this is still safe if you're sharing a patch to be first opened on its own.
in other words: it's not safe at all ;-)
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
namespacing by definition involves some kind of extra typing (like it or not) to differentiate entities that otherwise would look the same. the current mechanism of prepending the folder name already supports that, only single-binary libraries are sometimes a problem. cyclone already shows how this can be dealt with effectivly by adding a second creator (e.g. "cyclone/gate") Christof
Gesendet: Samstag, 06. Januar 2018 um 04:04 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
ok, that changes things a bit. It is still true that [declare] will prioritize to first load an object from that specified lib (let's call it lib1), even if there's another one (lib2) with the same object listed in the path. But this only happens if none of these objects have been called before. So this is still safe if you're sharing a patch to be first opened on its own. Now, things get hard to control if you've forced to load the object from lib2 beforehand, then try to load the other one from lib1 without a prefix and trying to rely on [declare]. But this also depends wether it is an abstraction or not, and, as I see it, that is inconsistent behaviour. Not only that, but I could also ask wether this is more of an issue on how Pd handles the object search than how [declare] works. And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it? I would assume that's what it had to do. cheers 2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig <zmoelnig@iem.at[mailto:zmoelnig@iem.at]>:On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
The compiled object from the lib listed in the path doesn't get called, and the one specified in [declare] gets called instead.
repeat the test with two abstractions having loading libraries providing the same object. e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd uses a [gate] stub that prints "gate 2". load abs1.pd, after that abs2.pd (either manually, or by putting them into a master patch). observe the console.
fgamdsr IOhannes
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Well, I suppose one way of forcing the use of cyclone's gate without typing out the entire thing and dealing with this whole namespacing thing is to basically use the -noprefs flag when launching pd (and assuming the people you are distributing the patch to have Pd somewhere in their path which might be a big if, you can send along a shell script that launches pd with that flag for them) and using [declare] to control what gets loaded and what paths are added (which actually might be tricky depending on platform/how their system is set up). And of course not loading the prefs file affects more than just paths/loading...
So maybe now that I type it out this isn't such a simple idea to implement haha, but maybe it could be helpful for some use cases...
Derek
Derek Kwan www.derekxkwan.com
(which actually might be tricky depending on platform/how their system is set up).
exactly, that's why it's better not to make any assumptions. just tell users: "needs zexy, cyclone ..." and it's their responsibility to add the necessary search paths/load libs if necessary.
and again:
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr Von: "Derek Kwan" derek.x.kwan@gmail.com An: "Alexandre Torres Porres" porres@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Well, I suppose one way of forcing the use of cyclone's gate without typing out the entire thing and dealing with this whole namespacing thing is to basically use the -noprefs flag when launching pd (and assuming the people you are distributing the patch to have Pd somewhere in their path which might be a big if, you can send along a shell script that launches pd with that flag for them) and using [declare] to control what gets loaded and what paths are added (which actually might be tricky depending on platform/how their system is set up). And of course not loading the prefs file affects more than just paths/loading...
So maybe now that I type it out this isn't such a simple idea to implement haha, but maybe it could be helpful for some use cases...
Derek
Derek Kwan www.derekxkwan.com
I steel believe that the “best practice” is [foo/obj]. At least for sharing patches. At home or with live-patching is another story.
The only things that needs to get fixed are some single binary libs. To put some random example some objects on iemlib already work with [iemlib/obj] and others don't.
Makes me think that if zexy and iemlib (and other single binary) support [foo/obj] every thing will be under control.
I'm not a Gem user so I don't know if it has potential name clashes
--
Mensaje telepatico asistido por maquinas.
On 1/6/2018 10:41 AM, Christof Ressi wrote:
(which actually might be tricky depending on platform/how their system is set up).
exactly, that's why it's better not to make any assumptions. just tell users: "needs zexy, cyclone ..." and it's their responsibility to add the necessary search paths/load libs if necessary.
and again:
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr Von: "Derek Kwan" derek.x.kwan@gmail.com An: "Alexandre Torres Porres" porres@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-List pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Well, I suppose one way of forcing the use of cyclone's gate without typing out the entire thing and dealing with this whole namespacing thing is to basically use the -noprefs flag when launching pd (and assuming the people you are distributing the patch to have Pd somewhere in their path which might be a big if, you can send along a shell script that launches pd with that flag for them) and using [declare] to control what gets loaded and what paths are added (which actually might be tricky depending on platform/how their system is set up). And of course not loading the prefs file affects more than just paths/loading...
So maybe now that I type it out this isn't such a simple idea to implement haha, but maybe it could be helpful for some use cases...
Derek
Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2018-01-06 13:35 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
I steel believe that the “best practice” is [foo/obj]. At least for sharing patches. At home or with live-patching is another story.
I've been responding to this thread and changing the focus to how declare works and how should it work, but I haven't replied what I think it's the best practice for sharing patches...
so +1 for namespaces
But personally, I hate using them for my own stuff. I don't use [declare] either, cause it still doesn't quite work for me, and we've been discussing ways to improve/enhance it, as I pointed in my first reply here on this thread.
for my own stuff, I just try to rely on as few libraries as I can, and I just don't use objects that have the same name and do different things, so I'm just happy to not bother with any namespace/declare nonsense, I just add the libraries to my path and enjoy them
cheers
The only things that needs to get fixed are some single binary libs. To put some random example some objects on iemlib already work with [iemlib/obj] and others don't.
Makes me think that if zexy and iemlib (and other single binary) support [foo/obj] every thing will be under control.
I'm not a Gem user so I don't know if it has potential name clashes
--
Mensaje telepatico asistido por maquinas.
On 1/6/2018 10:41 AM, Christof Ressi wrote:
(which actually might be tricky depending on platform/how their system
is set up).
exactly, that's why it's better not to make any assumptions. just tell
users: "needs zexy, cyclone ..." and it's their responsibility to add the necessary search paths/load libs if necessary.
and again:
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr Von: "Derek Kwan" derek.x.kwan@gmail.com An: "Alexandre Torres Porres" porres@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-List <
pd-list@lists.iem.at>
Betreff: Re: [PD] declare vs. namespaces - current best practice
And to come back to my first remark here on this thread, if [declare] cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
Well, I suppose one way of forcing the use of cyclone's gate without typing out the entire thing and dealing with this whole namespacing thing is to basically use the -noprefs flag when launching pd (and assuming the people you are distributing the patch to have Pd somewhere in their path which might be a big if, you can send along a shell script that launches pd with that flag for them) and using [declare] to control what gets loaded and what paths are added (which actually might be tricky depending on platform/how their system is set up). And of course not loading the prefs file affects more than just paths/loading...
So maybe now that I type it out this isn't such a simple idea to implement haha, but maybe it could be helpful for some use cases...
Derek
Derek Kwan www.derekxkwan.com
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
2018-01-06 7:53 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
So this is still safe if you're sharing a patch to be first opened on
its own.
in other words: it's not safe at all ;-)
why not? If you first open Pd with a patch that uses [declare], from someone who shared it, it'll be guaranteed that it works! Given that you have the library, of course...
And to come back to my first remark here on this thread, if [declare]
cannot always force a priority, shouldn't it?
I don't think so. [declare]'s job is to add paths to the search path and load libraries. it has nothing to do with namespacing.
imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. how could you possibly force on or the other with declare?
you can't, you can only do that with namespaces, alright, but this is still a pretty specific use case, and I don't understand what it has to do with the idea that [declare] should force a priority, which is something it actually already does as I pointed out...
and ok, it doesn't always do that as we discussed and found out, but then it's just a matter of "fixing" it...
namespacing by definition involves some kind of extra typing (like it or not) to differentiate entities that otherwise would look the same. the current mechanism of prepending the folder name already supports that, only single-binary libraries are sometimes a problem. cyclone already shows how this can be dealt with effectivly by adding a second creator (e.g. "cyclone/gate")
cyclone doesn't have a second creator for "cyclone/gate". It is not a single-binary library, but a mix of things, it has a) abstractions, b) separately compiled objects and c) a single-binary sub pack. For "c" - which is a library named "cyclone" (that loads non alphanumeric objects) - we have a second creator, so, given that you first loaded the "cyclone" (with declare or whatever) you can load an object like >~ as either just [>~] or also as [cyclone/>~].
This way you can force namespaces into single binary packs.
cheers
2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
The compiled object from the lib listed in the path doesn't get called,
and
the one specified in [declare] gets called instead.
repeat the test with two abstractions having loading libraries providing the same object. e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd uses a [gate] stub that prints "gate 2". load abs1.pd, after that abs2.pd (either manually, or by putting them into a master patch). observe the console.
ok, I actually have to say I don't get what this is supposed to test. I just get "gate1" and "gate2" as I would expect and I don't see how it relates to the previous discussion.
Now, since I have already replied to this giving the idea that I understood it and that it made me see things I didn't know, I have to explain that I had found them on my own and just assumed we were talking about the same thing. But now that I actually tried to check it, I don't.
Sorry for the confusion. I'm actually on vacation visiting paradisiac beaches of the brazilian northeast and shouldn't be trying to find time to keep up with this :)
cheers
I think Joao (the OP) is asking how to do in 2018 what he was doing back on the “extended” years. IRRC he shares his lib which uses many other objects from other libs. Now there should be a proper way to do that with the cocktail “Deken, [declare] & namespace”.
Deken - ? (only issue I know is troubles adding path for pkgs that have “-” in its name)
[Declare] - We should review https://github.com/pure-data/pure-data/pull/205 because the proposed:
1: search relatively to the calling patch 2: search the user's global paths 3: search Pd's system paths
Is a good one.
Namespace – Single binary libs should provide a way call [obj] using namespace.
--
Mensaje telepatico asistido por maquinas.
+1
Gesendet: Sonntag, 07. Januar 2018 um 20:58 Uhr Von: "Lucas Cordiviola" lucarda27@hotmail.com An: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
I think Joao (the OP) is asking how to do in 2018 what he was doing back on the “extended” years. IRRC he shares his lib which uses many other objects from other libs. Now there should be a proper way to do that with the cocktail “Deken, [declare] & namespace”.
Deken - ? (only issue I know is troubles adding path for pkgs that have “-” in its name)
[Declare] - We should review https://github.com/pure-data/pure-data/pull/205 because the proposed:
1: search relatively to the calling patch 2: search the user's global paths 3: search Pd's system paths
Is a good one.
Namespace – Single binary libs should provide a way call [obj] using namespace.
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
João Pais jmmmpais@gmail.com writes:
Dear list,
I'm trying to make my abstraction library vanilla-compatible, but nevertheless I need to use some externals. Since I didn't keep up with the vanilla progress the last years, I wanted to ask what is the best method to make sure that all externals are loaded:
- use [declare ....]?
- use namespaces such as [list-abs/list1]?
To jump into this discussion, I used to be a huge believer in doing the [library/object] thing and I still try to do it with libraries that aren't of my own creation because yes, there can be name collions and it's good to take steps to try to avoid it.
On the other hand, it is a lot of typing so when I can afford not to (usually with my own abstraction/external libraries and with my own personal patchese I don't necessarily intend on having other people use), I just forego that whole thing and either do a [declare] or just import the paths in my preferences.
One strategy I try to follow with my own libraries and a strategy I have seen others follow is to try to make the names as unique as possible (which isn't as good as the [library/object] strategy but perhaps good enough) and usually involves sort of prefixing or suffixing for every abstraction/external. In my case, I usually just prefix dk to everything so my bitcrushing abstraction becomes [dkbitcrush~]. Or I've sort of put all my list abstractiosn in their own little library so I prefix everything with pdkl- (pd + dk + l for list) so my mapping abstraction is called [pdkl-map].
Derek
and usually involves sort of prefixing or suffixing for every abstraction/external.
I've also done this in the past. namespacing by prepending the folder name has one advantage, though: it provides you the possibility to choose between the long (safe) and short (unsafe) name. short names are convenient in rapid prototyping while long names are preferable if things ought to be robust.
but after all, it's a matter of taste I guess.
Gesendet: Mittwoch, 03. Januar 2018 um 13:15 Uhr Von: "Derek Kwan" derek.x.kwan@gmail.com An: pd-list@mail.iem.at Betreff: Re: [PD] declare vs. namespaces - current best practice
João Pais jmmmpais@gmail.com writes:
Dear list,
I'm trying to make my abstraction library vanilla-compatible, but nevertheless I need to use some externals. Since I didn't keep up with the vanilla progress the last years, I wanted to ask what is the best method to make sure that all externals are loaded:
- use [declare ....]?
- use namespaces such as [list-abs/list1]?
To jump into this discussion, I used to be a huge believer in doing the [library/object] thing and I still try to do it with libraries that aren't of my own creation because yes, there can be name collions and it's good to take steps to try to avoid it.
On the other hand, it is a lot of typing so when I can afford not to (usually with my own abstraction/external libraries and with my own personal patchese I don't necessarily intend on having other people use), I just forego that whole thing and either do a [declare] or just import the paths in my preferences.
One strategy I try to follow with my own libraries and a strategy I have seen others follow is to try to make the names as unique as possible (which isn't as good as the [library/object] strategy but perhaps good enough) and usually involves sort of prefixing or suffixing for every abstraction/external. In my case, I usually just prefix dk to everything so my bitcrushing abstraction becomes [dkbitcrush~]. Or I've sort of put all my list abstractiosn in their own little library so I prefix everything with pdkl- (pd + dk + l for list) so my mapping abstraction is called [pdkl-map].
Derek
-- Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
"Christof Ressi" christof.ressi@gmx.at writes:
and usually involves sort of prefixing or suffixing for every abstraction/external.
I've also done this in the past. namespacing by prepending the folder name has one advantage, though: it provides you the possibility to choose between the long (safe) and short (unsafe) name. short names are convenient in rapid prototyping while long names are preferable if things ought to be robust.
but after all, it's a matter of taste I guess.
Interesting. I suppose this makes me think about more robust and defined examples of namespacing. Taking python for instance where you can import modules with shorter names with something like "import numpy as np" so you can just type "np.array" instead of "numpy.array" each time or you have the option to dump everything into the global namespace which is similar to the situation we have currently of just importing the path or compiled library wholesale through "from numpy import *".
I'd imagine that implementing a system like this in Pd would be very^999 far from trivial to implement, cause more confusion to the general end-user than it's worth it just because users like me don't want to type [cyclone/*] out every time (and there is already enough confusion about not being able to instantiate anything in Gem/zexy/cyclone/etc. even though they've already installed them onto their computers), and probably break everything which would be a huge no-no..................... but it is interesting to think about =P.
Derek
On Jan 3, 2018 10:24 PM, "Derek Kwan" derek.x.kwan@gmail.com wrote:
"Christof Ressi" christof.ressi@gmx.at writes:
and usually involves sort of prefixing or suffixing for every abstraction/external.
I've also done this in the past. namespacing by prepending the folder name has one advantage, though: it provides you the possibility to choose between the long (safe) and short (unsafe) name. short names are convenient in rapid prototyping while long names are preferable if things ought to be robust.
but after all, it's a matter of taste I guess.
Interesting. I suppose this makes me think about more robust and defined examples of namespacing. Taking python for instance where you can import modules with shorter names with something like "import numpy as np" so you can just type "np.array" instead of "numpy.array" each time or you have the option to dump everything into the global namespace which is similar to the situation we have currently of just importing the path or compiled library wholesale through "from numpy import *".
I'd imagine that implementing a system like this in Pd would be very^999 far from trivial to implement, cause more confusion to the general end-user than it's worth it just because users like me don't want to type [cyclone/*] out every time (and there is already enough confusion about not being able to instantiate anything in Gem/zexy/cyclone/etc. even though they've already installed them onto their computers), and probably break everything which would be a huge no-no..................... but it is interesting to think about =P.
Derek
maybe I'm stretching the topic here, but, how about tab-completion?
-- Derek Kwan www.derekxkwan.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2018-01-02 5:54 GMT-03:00 João Pais jmmmpais@gmail.com:
Also: I imagine that there isn't a problem with repeated declarations? Inside each abstraction there is a [declare], and a patch can always use lots of them.
I don't think there is
A suggestion: I can write [declare -stdlib xxxxx], and there will be no error message warning that the xxxxx library doesn't exist. Would it be good to have an error message, or even open deken to search for it?
added a request https://github.com/pure-data/pure-data/issues/281
-
Alexandre Torres Porres -
Christof Ressi -
Derek Kwan -
IOhannes m zmölnig -
João Pais -
Lucas Cordiviola -
tim vets