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

[Hans-Christoph Steiner]

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 at iem.at
> http://lists.puredata.info/listinfo/pd-dev




----------------------------------------------------------------------------

                             kill your television