hexloader

Current release: hexloader 1.6
Released 2015-08-17 — tested with pd 0.41, pd 0.42, pd 0.43, pd 0.44, pd 0.45, pd 0.46
a long outstanding release
Experimental releases
Upcoming and alpha/beta/candidate releases
- Alpha releases should only be used for testing and development.
- Beta releases and Release Candidates are normally released for production testing, but should not be used on mission-critical sites.
- Always install on a separate test server first, and make sure you have proper backups before installing.
Project Description
- Project resources
the problem
when dealing with abstractions and single-file externals, we have a 1-to-1 correspondence between an objectclass and a file.
examples:
- the
[expr]
object matches an external "./expr.pd_linux" - the[zexy/nop~]
object matches an abstraction "./zexy/nop~.pd"
general:
- the object
[<name>]
matches a file<name>.$EXT
when dealing with externals, the name of the objectclass is also to be found in the setup function within the external
example:
to load the "expr" external, Pd will look for a function
"expr_setup()" within the file "./expr.pd_linux"
general:
the external "
this works fine, as long as there are no special characters involved:
according to the above scheme, when loading the external "expr~"
Pd should actually be looking for expr~_setup()
within the file "./expr~.pd_linux";
unfortunately, the C-language (wherein most externals are written) does not
allow function-names to use any characters other than "a-zA-Z0-9_".
therefore the name "expr~_setup()" is invalid; therefore, Pd handles the case of the trailing "~" in a special way: it actually expands the "~" to "_tilde" and looks for "expr_tilde_setup()"
general:
the object [<name>~]
corresponds to an external "
unfortunately this doesn't work well for a larger number of characters forbidden in C-functionames.
example:
how should the setupfunction for an objectclass [~<~] be named?
additionally, several filesystems have problems with certain characters.
for instance, you cannot use the character >
on FAT32 filesystems.
but how do you then create a file for the objectclass [>~]
?
a solution
one solution is to just forbid objects with weird (non alphanumerical) names. pretty frustrating
another solution
use libraries with valid names that hold objects with weird names
a better solution
another solution is to translate the forbidden characters into allowed ones.
for instance, every ASCII-character can be called by it's name (e.g. a
) as
well as by it's numeric value "97" (or in hex: "0x61")
the here-proposed solution is, to replace every illegal character by it's
hexadecimal representation (in lowercase).
examples:
[>]
corresponds to the file "0x3e.pd"[>~]
corresponds to the file "0x3e0x7e.pd" or to "0x3e~.pd"[a>b]
corresponds to the file "a0x3eb.pd"
the same system can be applied to the setup-functions: examples: [a>b] has a setupfunction "a0x3eb_setup()" CAVEAT: C also forbids to start function names with numeric values. therefore, this is a nono: [>]'s setupfunction would be "0x3e_setup()" (ILLEGAL) we can simply fix this by putting the "setup()" in front: [>] has a setupfunction "setup_0x3e()"