On Wed, Feb 04, 2015 at 12:44:24PM +0100, katja wrote:
On Wed, Feb 4, 2015 at 12:03 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
just a word with my debian maintainer hat on:
if Pd-vanilla supported double-precision builds, i would like to make these available for Debian and derivatives as well.
if i made single- and double-precision builds co-installable (which iÃm not sure yet), it would be as "pd" and "pd64", with pd64 using different default configuration (~/.pd64settings) and search paths (/usr/lib/pd64/extra/). and install all (packaged) externals that can be build for double precision into /usr/lib/pd64/extra/, rather than having phat builds.
i don't think we should spend too much time/energy on designing and supporting foolproof phat builds at all (as this is probably impossible without the help from the OS).
Allright, I was just carried away by the prospect of phat / fat-precision binaries. But indeed it's regular practice to keep Pd build and externals together. So the only critical point is install time. If users add external libs in the path of Pd 'by hand' they need to verify the origin anyway. For example one can't add Pd-L2Ork externals to Pd vanilla / extended or vice versa, even though these have the same name and extension.
So what you propose (for the 'non-phat' case) is a protection mechanism to avoid Pd loading a wrong-precision external. That is most important, because a wrong-precision external causes spurious malfunctions, of which segfaulting may not even be the worst because that is at least a clear signal. And a double precision Pd build and process should identify itself as such so you need not guess what precision you're using at any moment. It is perfectly possible to run Pd instances of different precision simultaneously, is what I recall from my experiments in 2011.
Katja
It might be that just building on to the current setup would be least troublesome. In distributions such as the debian packages, everybody could revert to .dll, .pd_darwin, and .pd_linux (which is OK because there would only be one architecture and one float-size per distro) and then a single layer of ad-hoc extents for anyone wanting to distribute fat externs (by which I mean, externs in directories containing .l_arm, .l_i386, .d_ppc, and the rest of the carnival, now to include new ones like .l_ia64_double or something.
As it does now, Pd would search first for the more specific one, then fall back to the more general one.
And, if it's useful, going forward Pd could even add a third possibility which would be to search for .so (linux) or .dylib (mac I think). Why not...
cheers Miller