and how come underline works just fine?

Because Pd's loader mechanism searches for the symbol "${libname}_setup", where "${libname}" is the name of the library being loaded. If you make sure that "${libname}" is drawn from the set of characters thatcan appear in a C function name, then users will be able to load your object in all the ways that Pd provides (using declare, using an absolute path name, etc.) If instead you use characters that cannot appear in a C function name, you either limit the ways that users can load that library or require complicated workarounds like hexloader in order to make the library generally loadable.

What other easy options do I have besides "_"?

Why do you want to avoid using an underscore? -Jonathan

Well, here's what I have, an object named [allpass.rev~]

I compiled a file name "allpass.rev~.pd_darwin", I have a allpass.rev~-help.pd, all works fine here in the mac, and all I had to do was having a setup_allpass0x2erev_tilde() function in the code.

Now, what am I missing? Is this not gonna work elsewhere? Say, Windows, Linux?

cheers

2017-10-17 16:41 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:

On 10/17/2017 07:44 PM, Jonathan Wilkes via Pd-list wrote:

...

...

and how come underline works just fine?

Because Pd's loader mechanism searches for the symbol "${libname}_setup", where "${libname}" is the name of the library being loaded. If you make sure that "${libname}" is drawn from the set of characters

thatcan appear in a C function name, then users will be able to load your object

...

in all the ways that Pd provides (using declare, using an absolute path

name,

...

etc.) If instead you use characters that cannot appear in a C function name,

you

...

either limit the ways that users can load that library or require

complicated

...

workarounds like hexloader in order to make the library generally

loadable.

...

for what it is worth, hexloader is not *very* complicated.

what most people seem to forget is, that hexloader really consists of two parts, solving two different problems:

• allowing file names that would otherwise be forbidden (by the

underlying filesystem)

• allowing setup functions names that would otherwise be forbidden (by

the C-standard)

the allowed characters in C functions are well defined, e.g. [1] the allowed characters in filenames are filesystem dependent, but a good overview can be found at [2].

both problems are somewhat similar, as they try to encode the forbidden characters into something not forbidden. they both use the same method: replacing the forbidden characters with a hex-representation.

now the good news is, that if your object name only falls into one category, then you only need to deal with that part.

the part of the hexloader implementation that is built into Pd, only tackles the 2nd problem (function names). since C function names are much more restrictive than file names, this usually covers most problems (though obviously not all).

so, if you want an external that contains characters allowed on the filesystem but forbidden as (part of) a function name, you only need to provide a hexloadable name for the setup function, and don't have to worry about ugly filenames that nobody understands.

furthermore, you don't even need to remember the way those hexloadable setup function name is to be constructed. simply compile your external into "foo.bar.pd_linux", start Pd with "-verbose" and try to instantiate [foo.bar]. Pd will fail to load the external (as it cannot find and call the setup function), but will display the setup name it tried to find when setting the log-level to "all".

...

...

What other easy options do I have besides "_"?

Why do you want to avoid using an underscore?

+1

gamdsr IOhannes

[1] http://www.c4learn.com/c-programming/c-variable-nameing-rules/ [2] https://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list

well, just tested in windows and linux and it worked :)

2017-10-17 17:23 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:

why should it not work?

I dunno, that's why I asked, it wasn't clear it'd be fine without hexloader

why do you think you are missing something?

I usually do that, cause I'm not a programmer

...

Why do you want to avoid using an underscore?

+1

I just don't like it, I prefer much more to be able to use the "." option

cheers and thanks for the help

2017-10-17 17:45 GMT-02:00 Jonathan Wilkes jancsika@yahoo.com:

...

Well, here's what I have, an object named [allpass.rev~]

As a practical matter, I still don't understand why you are trying to use "." instead of "_".

not trying anymore, I succeeded, so it seems.

and I already said it's just a matter of personal preference, not much else to add

I also see this pattern here and there, so I'm not coming up with this, would anyone have something against using "."?

cheers

...

why do you think you are missing something?

I usually do that, cause I'm not a programmer

[...]

I also see this pattern here and there, so I'm

not coming up with this, would anyone have something

against using "."?

You said above you are not a programmer above, so I'll

thrown in a programming perspective in the hopes that

it's useful to you:

Your preference complicates the source

code for no significant usability gain.

The relationship between [foo_bar] and foo_bar_setup is

easy to see, whereas the one between [foo.bar] and

setup_fooOx2ebar is not.

If the "." character were used in a library name because it

represents a well-known mathematical operator that would

be one thing. But using it for personal preference at the

expense of code readability isn't a worthwhile tradeoff

from the standpoint of maintainability.

It's possible you saw the pattern in an abstraction

library where this issue doesn't come up.

Also-- I used an uppercase "o" instead of a zero just

to drive the readability point home.

Best, Jonathan

cheers