On Nov 16, 2005, at 4:31 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
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.
actually my problem was rather with zexy, since i have currently no plans to split iemmatrix into individual files (the plans are rather in the opposite direction: bundle functionality into "helper-files") (sorry about that...)
Too late, I already did. ;) Check externals/build/src. What do you mean by helper files?
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.
this seems to be ok. so which characters should be escaped then? everything but [a-zA-Z0-9_] ? (i would suggest an implicit definition rather than an explicit one, since you never know...)
I totally agree, keep it flexible and open. [a-zA-Z0-9_] sounds good to me.
It would be nice to have filenames and setup functions treated separately, so that filenames would remain human-readable. Filenames would only need to substitute:
["/*?<>|:]
Here's a little breakdown of the relevant filesystems:
http://www.comentum.com/File-Systems-HFS-FAT-UFS.html
.hc
________________________________________________________________________ ____