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

[Hans-Christoph Steiner]

More on actually trying the patch.  I tried to apply it to the HEAD of  
pure-data.git, and one section failed:

pd at debian-lenny-i386 src $ patch -p1 < ../../pd_doubleready/ 
make_Pd_core_0430_double_ready.patch
patching file d_array.c
patching file d_math.c
patching file d_misc.c
Hunk #2 FAILED at 37.
1 out of 2 hunks FAILED -- saving rejects to file d_misc.c.rej

The patch to 'extra' succeeded.

.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



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

Mistrust authority - promote decentralization.  - the hacker ethic