I think for now, we'll just have Pd-extended-like monolithic builds which will be easy to use on their own and will include enough libraries to be useful. They can be run standalone, and if need be, we can disable things like ~/pd-externals quite easily.
These kinds of deployment issues really need a lot of real world data to be correctly solved, so I think its not worth going to deep into it until we get some builds out there for people to use.
.hc
On Oct 3, 2011, at 11:44 AM, 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.
- Pd looks for a setup symbol when trying to load an external binary.
- A loaded external calls an exported function in Pd.
- 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, I have not seen symbol collision happen though I've often ran them simultaneously. I understand that theoretically it's not guaranteed that it won't happen, that's also the reason why it is generally recommended to only export truly global symbols. However I think it is not really a concern, as there is normally no reason to run single and double precision Pd together, apart from testing purposes.
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.
Actually I think we have time to find and implement a solution because during the double precision development and test period we do not depend on it. If only we find a good way to point different Pd installations to subdirs in their own 'extra' for loading externals. What I meant to say in my previous mail is, that external executables like bonk~ are found from the proper location because Pd apparently 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.
Katja
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
kill your television