[PD-dev] double precision Pd: .patch files, tests and benchmarks

IOhannes m zmoelnig zmoelnig at iem.at
Mon Oct 3 15:12:08 CEST 2011


-----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 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6JtKUACgkQkX2Xpv6ydvTZZgCgu8d045+iv0ju7wvgSTefJBXa
ZfMAoIh2eVZ2uwgh7e5gkjU+itRw3IlT
=vbHJ
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20111003/30d98431/attachment.bin>


More information about the Pd-dev mailing list