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

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-10-03 17:44, katja wrote:
> Thanks IOhannes for all your comments and suggestions.
> 
> I just realized that there are several ways in which identical symbols
> for different function definitions could cause a problem and I did not
> distinguish them.
> 
> 1. Pd looks for a setup symbol when trying to load an external binary.
> 2. A loaded external calls an exported function in Pd.
> 3. Pd calls an exported function in Pd
> 
> Case 2. and 3. can only lead to symbol collision when a single
> precision and double precision Pd are running simultaneously. So far,

how is that going to happen?
by "running simultaneously", do you mean something like this?
$ pd32 &
$ pd64

i think all modern OSs will protect the memory (including loaded
libraries) of an application from other applications.
e.g. if i happen to have a library with an exported symbol "sqrt" which
viciously returns the (x+1) rather than sqrt(x), and i start an
application that links to this library (thus making use of the "bad"
sqrt()), this will not magically make Excel forget it's math.

the problem might obivously appear, if Pd would actually create a
libpd.so providing all the exported functions, and pd32 / pd64 would
make heavy use of those.
in which case, pd32 might get a double-precision libpd.so, and thus be
not single precision any more.

but this is really not a problem of running the single and double
precision on the same machine, but installing them on the same machine.

> 
> For case 1., protection is needed indeed. As IOhannes' list of
> possible approaches indicates, it's not a trivial intervention. I've
> also been thinking of a mechanism where Pd 'probes' a class at load
> time in order to find it's float type before instantiating any object.
> Rather it creates a private test instance for that purpose and tries
> to solicit output and check the size. To program this is not trivial
> either, if possible at all, but the advantage would be that it does
> not have consequence for class code.


i cannot really think of a way to do that.
if we only consider signals, we could do some tests (as the object has a
well defined interface to acquire and output "numbers"), though i fail
to see how we could validate these tests, without knowing what the
object is actually supposed to do.
if we consider message objects as well, i don't even know how to
"properly" send a message that might reveal something useful.

> knows they are in it's own extra dir, wherever the installation may be
> located. I do not know where this path is set but we need an option to
> add more dirs to that local  path without using preferences.

i don't see how this would help.
whether those paths can be modified via preferences or only via startup
flags, doesn't really matter. if we want them to not be editable at all,
i don't see the point in adding them.

people do use the preferences to add paths to find their libraries.
if those paths contain libraries expecting the wrong precision we have a
problem.


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

iEYEARECAAYFAk6J3RQACgkQkX2Xpv6ydvSxlgCfSWr1xxFrd/VQ/13lgARF88EL
Qk0An22WlbXva6O/Q3YWasMn/57M+XK6
=OVlg
-----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/9020d646/attachment-0001.bin>