-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-10-03 14:28, katja wrote:
On Sun, Oct 2, 2011 at 11:36 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think it makes sense to work off of pure-data.git rather than pd-extended.git since this is a patch targetted at getting into Miller's repo.
Right. Even then, we could add some external libs to work on, starting with zexy and cyclone for example. The question is how to load appropriate executables into local single and double precision test builds of vanilla Pd. A single preference file is shared by all vanilla Pd installations, therefore setting searchpaths via preferences is no option. Each Pd should only load from it's own 'extra' directory. With the extra's included in vanilla Pd, this works
i'm not sure whether i really understand what you are saying here.
however, as long as a double-precision Pd looks into different paths than a single precision Pd, we won't have any problems. however, as soon as a double precision enabled Pd will find such an external in there, it will go kaboom.
possible solutions to the problem that come to my mind are: - - use a different filename suffix for double-precision externals. e.g. bonk~.pd_linux and bonk~.double.pd_linux pro: you can ship single and double precision files in a single zip file con: yet another special suffix
- - use a different setup function name for double precision, e.g. bonk_tilde_setup() vs bink_tilde_dsetup() pro: allows to have both single and double precision objects in a single binary con: needs extra code in each external (esp. if you want to exploit the 'pro' without resorting to C++-templates...) con: code need to be made aware for which width it is compiled
- - use a special exported function in the code, that indicates the width, for which the object was compiled [*] pro: backward compatible, con: needs extra code in each external (could probably done with a macro).
[*] something like: int pd_floattype_compatcheck(int runtimetype) { return runtimetype && COMPILETIMETYPE); } COMPILETIMETYPE would be defined in m_pd.h during load time, before Pd calls the _setup function, it would check for pd_floattype_compatcheck() and call it with runtimetype=COMPILETIMETYPE. if the compatcheck returns!=0, then the external is considered to be compatible with the currently used COMPILETIMETYPE and can thus be safely used. if 0 is returned, the external is incompatible and the setup function is not called at all (and hopefully the search for a compatible external is continued). if there is no pd_floattype_compatcheck() exported, then we really don't know whether we are compatible. i would suggest to assume compatibility, but make Pd issue a warning before it tries to load (and run) the object, so people would have a way to find out what caused the crash. alternatively, one could assume "single precision" if the compatcheck is missing, and refuse to load it in double precision mode.
fine as far as I have seen. I tested bonk~ in single and double precision Pd simultaneously without symbol collision.
which symbols are supposed to collide?
fgmasdr IOhannes