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.
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,
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
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
