Hans, there's so many externals in pd-double giving weird output, I couldn't believe it's all wrong in the code. So I searched for a class which is definitely double-ready and which can act as a test class for the build of the lib where it is part of. For cyclone [mean] can do this, see attached patch. It's code is double-ready and does not depend on anything else than m_pd.h. Still it's output makes no sense in pd-double.
Apparently, the build rules for the external classes do not include the PD_FLOAT_PRECISION definition..
For this reason, it is at the moment not opportune to announce pd-double ready for testing. If people would really start testing now, a tsunami of bug reports could follow, many of which boil down to this single wrong macro definition. We better avoid such needless administrative hassle.
Katja
p.s.
I was talking about the Pd-0.43.1-double-20111009-macosx106-x86_64.dmg build, which has double precision core. The build in Pd-0.43.1-double-20111010-macosx106-x86_64.dmg crashes at startup on OSX 10.5:
Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0
Dyld Error Message: unknown required load command 0x80000022
Indeed, its true. That's a tricky problem. I think I got it right this time, I just pushed my commit to github. Basically, I made it so PD_FLOAT_PRECISION is set in m_pd.h based on the bitness of the build, but can be overridden by externally setting PD_FLOAT_PRECISION. So the ./configure flags just serve to force either 64-bit double or 32- bit float, but by default it'll use double on __LP64__ or _WIN64, and float on anything else.
Having this in the m_pd.h header will mean that it'll automatically apply to the externals too, unless overridden.
.hc
On Oct 10, 2011, at 7:33 AM, katja wrote:
Hans, there's so many externals in pd-double giving weird output, I couldn't believe it's all wrong in the code. So I searched for a class which is definitely double-ready and which can act as a test class for the build of the lib where it is part of. For cyclone [mean] can do this, see attached patch. It's code is double-ready and does not depend on anything else than m_pd.h. Still it's output makes no sense in pd-double.
Apparently, the build rules for the external classes do not include the PD_FLOAT_PRECISION definition..
For this reason, it is at the moment not opportune to announce pd-double ready for testing. If people would really start testing now, a tsunami of bug reports could follow, many of which boil down to this single wrong macro definition. We better avoid such needless administrative hassle.
Katja
p.s.
I was talking about the Pd-0.43.1-double-20111009-macosx106-x86_64.dmg build, which has double precision core. The build in Pd-0.43.1-double-20111010-macosx106-x86_64.dmg crashes at startup on OSX 10.5:
Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0
Dyld Error Message: unknown required load command 0x80000022 <mean-test.pd.zip>_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
On Mon, Oct 10, 2011 at 6:35 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Indeed, its true. That's a tricky problem. I think I got it right this time, I just pushed my commit to github. Basically, I made it so PD_FLOAT_PRECISION is set in m_pd.h based on the bitness of the build, but can be overridden by externally setting PD_FLOAT_PRECISION. So the ./configure flags just serve to force either 64-bit double or 32-bit float, but by default it'll use double on __LP64__ or _WIN64, and float on anything else.
Hans, today's autobuild sources still do not have your bitness solution included.
When setting '--enable-double-precision' in the makefile for the package, the libs are still single precision. Therefore, it is at the moment not possible to set the precision at will (only for the core and that is not so useful in this context). Maybe it is best to have precision always dependent on the build's bitness? Hmm that me be a point of heavy debate, later. Anyway I should probably upgrade my OSX to 10.6 in order to develop and test double precision pd.
Katja
On Oct 13, 2011, at 10:59 AM, katja wrote:
On Mon, Oct 10, 2011 at 6:35 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Indeed, its true. That's a tricky problem. I think I got it right this time, I just pushed my commit to github. Basically, I made it so PD_FLOAT_PRECISION is set in m_pd.h based on the bitness of the build, but can be overridden by externally setting PD_FLOAT_PRECISION. So the ./configure flags just serve to force either 64-bit double or 32- bit float, but by default it'll use double on __LP64__ or _WIN64, and float on anything else.
Hans, today's autobuild sources still do not have your bitness solution included.
When setting '--enable-double-precision' in the makefile for the package, the libs are still single precision. Therefore, it is at the moment not possible to set the precision at will (only for the core and that is not so useful in this context). Maybe it is best to have precision always dependent on the build's bitness? Hmm that me be a point of heavy debate, later. Anyway I should probably upgrade my OSX to 10.6 in order to develop and test double precision pd.
Arg, for some reason its not updating on the rsync master. I just manually updated. But you can always do:
cd pd-double/pd git pull cd .. svn up
And that should bring everything up-to-date on your machine. I'll try to fix the auto-updating...
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
-
Hans-Christoph Steiner -
katja