[PD-dev] [PD] more about float limitation

[Miller Puckette]

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 at 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