Thomas Grill wrote:
Hi all,
as a by-product, it is very likely that the (discussed) namespacing-mechanism ([zexy::abs~] vs. [Gem::abs~]) would have to be implemented anyway.
Please!! Let's not use :: as the : is reserved in MacOS and then i can't emulate the namespace features for Max. Let's use . which is already common.
ok !
i've made some minor changes to the pd-sources (namely m_imp.h, s_loader.c, m_class.c) to allow namespaces when loading libraries.
they are attached.
the namespace-delimiter is "::" for now, but it can easily be changed via the "#define NAMESPACE" line in m_imp.h i am still not sure of if macOS-X allows the typing of ":" inside pd. if not, we might have to change it to "." or something. i really do not like the idea of "." since it is a filename delimiter.
anyhow: explanation with zexy:: the zexy class [list2symbol] is declared (in the zexy-code) with class_new("list2symbol") it has an alternative name [l2s] class_addcreator("l2s") when the patched pd loads zexy, the primary name of the class becomes "zexy::list2symbol" following alternatives (creators) are also created: "list2symbol" "zexy::l2s" "l2s"
this shouldn't really break anything, but enable the explicit use of an external inside an object.
a side-effect: zexy includes a "tabread4"-class, which is unusable since pd>0.32, because miller has finally imcluded it in pd. with the patched pd, it is possible to load zexy's version with [zexy::tabread4] (which gives a warning about being obsolete) and the native version with just [tabread4].
generally, native pd object-classes are left alone.
the helpsymbol (pd-patch) is not affected by the patch.
i think it might be a good idea to include it into pd, since it might bring a (final ?) solution to the namespace thread. (of course it might not prove optimal, but which solution would be ? i think this is the cleanest solution from a programmers point of view)
anyhow, i have only tested it on linux, it might prove problematic under macOS(?) and windows. is it true, that the native-objects in pd are loaded from the pd.dll under win ? we might (but not necessarily must) get a problem then with "pd::object"
mfg.casd.asdf IOhannes
diff pd-0.35-0_namespace/src/m_class.c pd-0.35-0/src/m_class.c 18,24d17 < #ifdef NAMESPACE < static char *library_name = 0; < void set_library_name(char *libname){ < library_name=libname; < } < #endif < 151,153d143 < #ifdef NAMESPACE < t_symbol *S=gensym(s->s_name); < #endif 176,187d165 < < #ifdef NAMESPACE < if (library_name){ < char namespacename[MAXPDSTRING]; < namespacename[0]='\0'; < strcat(namespacename, library_name); < strcat(namespacename, NAMESPACE); < strcat(namespacename, s->s_name); < s=gensym(namespacename); < } < #endif < 207,209d184 < #ifdef NAMESPACE < c->c_name = c->c_helpname = S; < #else 211d185 < #endif 232,240d205 < < #ifdef NAMESPACE < // like a class_addcreator < if (library_name){ < class_addmethod(pd_objectmaker, (t_method)newmethod, S, < vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]); < } < #endif < 271d235 < 274,286d237 < < #ifdef NAMESPACE < if (library_name){ < char namespacename[MAXPDSTRING]; < namespacename[0]='\0'; < strcat(namespacename, library_name); < strcat(namespacename, NAMESPACE); < strcat(namespacename, s->s_name); < s=gensym(namespacename); < } < class_addmethod(pd_objectmaker, (t_method)newmethod, s, < vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]); < #endif diff pd-0.35-0_namespace/src/m_imp.h pd-0.35-0/src/m_imp.h 52,57d51 < // IOhannes : added namespace support for libraries < #define NAMESPACE "::" < #ifdef NAMESPACE < void set_library_name(char *libname); < #endif < diff pd-0.35-0_namespace/src/s_loader.c pd-0.35-0/src/s_loader.c 131,133d130 < #ifdef NAMESPACE < set_library_name(classname); < #endif
hi IOhannes and all,
it is a nice code, and takes us one step forward, even if a small one. However, if this encouraged people to use names of existing externs for their redefined versions -- on the ground of ``always being able to use a qualified name'' -- it would be a very bad thing, causing confusion, and making many patches hard to reuse...
So, I really do not know, if this is going to be a real step forward, or just a fuel keeping this thread alive for some more time?
In the comments below I assume the former...
IOhannes zmoelnig wrote: ...
i've made some minor changes to the pd-sources (namely m_imp.h, s_loader.c, m_class.c) to allow namespaces when loading libraries.
please do not call this feature `namespaces'. From just being able to use a qualified name it does not follow that we would have namespaces in Pd -- in the sense of a ``use zexy'' (or similar) declaration, rules of visibility, etc.
...
when the patched pd loads zexy, the primary name of the class becomes "zexy::list2symbol"
in your patch c->c_name and c->c_helpname == "list2symbol" (see below)
...
(of course it might not prove optimal, but which solution would be ? i think this is the cleanest solution from a programmers point of view)
ok, but there is a (confused) user's pov too...
...
diff pd-0.35-0_namespace/src/m_class.c pd-0.35-0/src/m_class.c 18,24d17 < #ifdef NAMESPACE
should be > (-R is needed)
...
207,209d184 < #ifdef NAMESPACE < c->c_name = c->c_helpname = S;
S == "list2symbol", not "zexy::list2symbol"
...
232,240d205 < < #ifdef NAMESPACE < // like a class_addcreator < if (library_name){ < class_addmethod(pd_objectmaker, (t_method)newmethod, S, < vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]);
please, use ``if (library_name && newmethod)'' here, otherwise a proxy's name would crash Pd if put in an object box.
Krzysztof
Krzysztof Czaja wrote:
hi IOhannes and all,
So, I really do not know, if this is going to be a real step forward, or just a fuel keeping this thread alive for some more time?
neither do i know. however, i would like this thread to be finished sometimes and that is why i did write some code. it was hacked quite fast without real stress tests and the idea seemed ok to me.
i just don't want this question to pop up every other week
However, if this encouraged people to use names of existing externs for their redefined versions -- on the ground of ``always being able to use a qualified name'' -- it would be a very bad thing, causing confusion, and making many patches hard to reuse...
confusion starts right now:: i (having slept little) cannot think of really bad scenarios. let's try: xy uses zexy and labels all used zexy-classes with the qualifier "zexy::" sometimes later someone decides to enhance zexy and makes his own (more or less compatible) version called "hexen" when xy decides to upgrade from zexy to hexen he would have to reprogram all his references to the library-objects ! xy could use searchnreplace (not that bad, but some work)
another try: xx uses ggext compiled as a big library and consequently uses the "ggext::" qualifier. by pure chance, one rainy day xx compiles ggext as a collection of separate externals. everything is broken
my aim was, just to allow (!) the using of qualified names. if i do load 2 libraries providing the same class-names i have to use some mechanism to access the objects. i do not encourage the use of qualified names when writing patches. i do encourage the use of them when name-clashes arise.
In the comments below I assume the former...
please do not call this feature `namespaces'. From just being
ok ! "qualified names" it be then
(of course it might not prove optimal, but which solution would be ? i think this is the cleanest solution from a programmers point of view)
ok, but there is a (confused) user's pov too...
"programmer" meaning "someone programming in the graphical language of pd"
by the way, somehow i am now convinced that "." would be a better delimiter 8-) there is a new patch-file (hopefully more unified than last time) that applies Krzysztof's changes (thanks), uses "." as delimiter and fixes the bug "/my/long/path/to/externs/library::object" to "library::object" (without this we could then have concurrent versions of a single library running at the same time ....)
mfg..sd IOhannes
Krzysztof
-
IOhannes zmoelnig -
Krzysztof Czaja