[PD-dev] proposed fix for objects named with +,-,*,^, etc.

[Hans-Christoph Steiner]

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.