-----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-----
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
