Hans-Christoph Steiner wrote:
So I am able to get objects with +, -, *, and ^ in the name to compile as individual files, I was not able to get objects with / in the name to work, plus they might cause problems with geiger namespaces (i.e. [libname/object]). But the only problem left is the setup functions.
AFAIK you are not allowed to have setup functions named mtx_+_setup(), mtx_-_setup() , etc. So if pd would translate the symbols to a word, like "mtx_plus_setup", like it does for ~, then this whole thing would work.
Currently, there is a little workaround for objects with aliases. If you load [mtx_sub], for example, then you can load [mtx_-] since [mtx_sub] will generate the symbol "mtx_-", etc.
oh indeed!
so this is the 3rd mail on this topic. i really think it is a minor but important issue, that's why i didn't understand why everybody ignored my first 2 mails...(so that's why i am a bit sarcastic here)
anyhow i'll repeat what i have written: i think, that the "replacing '~' by 'tilde'" is a very clumsy approach. there is no real reason, why "mtx_plus_setup()" is better than "mtx_add_setup()" or anything else (both are human-readable; none is generic) the real problem i see is, that while we might find "good" replacements for +,-,*,^,,,. we will not find a replacement for "etc".
furthermore, there are certain character which cannot be used for filenames on certain filesystems (e.g. "||~.pd" as found in zexy is not a valid filename on w32)
i thus proposed (and propose again), to have additional (optional) setup functions (and filenames) which are encoded in a way, that is "safe".
simplest thing would be, to encode every character with in hexadecimal: e.g. the external [||~] would be in a file "7c7c7e.pd_linux" and would have a setup-function "setupHEX_7c7c7e()"
other things like [mtx_+] could be in a file "mtx_+.pd_linux" and still have a setup-function "setupHEX_6d74785f2b()"
i use a different scheme for the setup-function name, to avoid conflicts with normal setup-functions (just imagine, somebody made an object that is really called [7a7b]; additionally C-functions must not start with numbers)
i admit that the hex-encoding is inefficient (in terms of bits) and non-readable by humans. however, it is very simple and consistent.
what do you think?
mfg.a.dsr IOhannes