On Wed, Nov 9, 2011 at 5:51 PM, Hans-Christoph Steiner hans@at.or.at wrote:
So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_sample<>t_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git?
I think we should submit the current changes now since they will get things building at double-precision at least. Then further fixes can be submitted later.
Ok, now done like this: whenever it's straightforward to implement t_sample, I do so, but in complicated cases where it's too time consuming I leave it for later.
When doing a last check on the 'extra' objects, I ran into a problem with the install as done by the new build system. (Though Pd core works without install, the extra's do not, so a regular or local install must be done to test the objects.) The [pd~] object can not be loaded, it says:
pd~: can't stat /usr/local/lib/pd/pd
This seems unrelated to the double-ready code, because pure-data.git shows exactly the same issue when built with the new build system. Also, these builds both show:
soundfiler_read: ../doc/sound/voice.wav: No such file or directory
while the file is certainly located in /usr/local/doc/sound/ and pd is running from /usr/local/bin/. With local build, same problem. Using the old build system for a local build, these issues did never appear. Neither with packaged builds.
All stuff in 'extra' is checked now, apart from [pd~]. So I'd suggest:
- I push the changes to pd-double - could the old build system be brought back into pd-double, for convenience? - only when [pd~] is verified to work, let's submit patch for pure-data.git
Katja