On Oct 3, 2011, at 12:00 PM, Charles Henry wrote:
On Mon, Oct 3, 2011 at 10:19 AM, IOhannes m zmoelnig
<[email protected]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2011-10-03 16:31, Hans-Christoph Steiner wrote:
These all sound like good ideas to try. My only concern is that we
might let the deployment issues distract from the issues at hand
about
getting it actually working first.
i'm definitely with you here.
what is still missing in terms of "getting it actually working
first"?
afaict, katja's patches do make pd itself double-precision ready (the
patches might have to be reviewed as far as coding-style is concerned
though)
otoh, i wouldn't start "porting" externals before we have a
deployment
strategy.
one important thing missing right now, is how to compile Pd in a
given
precision without having to edit m_pd.h
technically i think that the define stuff and the like should go
into a
separate file "types.h" (probably "m_types.h") which is generated
from
m_types.h.in during configure time, and which is included by m_pd.h
(which should remain non-generated)
the question is, what miller would think of such a thing.
Would you prefer to set the types at configure time through a file--or
for example by adding a -DDOUBLE compiler flag? The affected
locations of code defining the types could just use #ifdef DOUBLE
In either case, the configure option seems necessary. It still seems
an open question how best to offer the double-precision types to
externals developers.
In some cases, the setup() function allocates memory, which needs to
be aware of the data type size.
Otherwise, memory for signals is allocated through Pd's DSP graph
generation routines, so that only changes to externals is to compile
perform routines with the given data type.
Adding additional methods seems unnecessary--unless specific
performance problems can be avoided.
Wouldn't setting t_sample, t_float, and t_int to 64-bit or 32-bit in
m_pd.h combined with sizeof() be enough for this?
.hc
In terms of packaging, I can see having 64-bit distros run
double-precision Pd for all packages, and 32-bit distros run single
precision. That should cover the bulk of situations, the other
situations can be covered by custom builds. Having all the 64-bit
packages use double-precision Pd is of course going to happen
after a
while, once we have the bugs worked out. Here I can see an
advantage of
the monolithic Pd-extended package: its an easy, self-contained
test bed.
definitely, the traditional Pd-extended will have an easier time
here.
nevertheless, the advent of ~/pd-externals for the user has made
things
significantly more complicated in terms of "just works".
fgmasdr
IOhannes
I don't anticipate any problems with running 64-bit Pd on a 32-bit
system, in principle, just as long as the correct data types are set
for pointers (same size as t_int) and signals (size of t_sample)
differently.
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
