On Nov 15, 2005, at 3:26 PM, IOhannes m zmölnig wrote:
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.
Well, I just ran into the problem while getting iemmatrix objects to compile as individual files, funny enough. So I guess you've been thru this already.
The overall idea sounds good, but why not just use HEX translation for just the characters that are not allowed on the filesystems and in C functions? This would keep the filenames and function names human readable. We could do something like HTML entities or C hex with a reserved combo of chars to define a special char, something like 0x then two digits. For example:
[mtx_+] == mtx_0x7e.pd_linux == setup_mtx_0x7e() [osc~] == osc0x7e.pd_linux == setup_osc0x7e
Then to type out "0x" you would just do the hex of "0" and "x" if we really wanted that.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.