On Oct 21, 2011, at 7:43 AM, katja wrote:
Starting on October 20, nightly builds tagged as pd-double are really built in double precision. All earlier builds were single precision or a mix of single and double.
In double precision, only Linux builds succeed, partly. From the logs, you can see gcc exiting with an error when compiling creb. The package contains everything which was built before creb: the Pd core and a few external libs. On OSX, no package is produced at all. It will take considerable time before all libs will even compile in double precision, since all fixes have to be properly tested before commit.
As long as you are willing to follow up on issues as they are found, I think it works best to commit much more frequently. That allows others to see, test, and fix your code. The one thing that a commit must do is build. Always make sure it builds before committing (I know I know, sometimes I forget too ;). You don't need to guarantee that you've fixed every bug before committing. Committing more frequently means that we can share the development more.
I think I a good workflow for Pd-double would be to commit things that fix the build, you think will work, and have tested somewhat. Make a note of those, and as we get a testing framework in place, we can start putting automatic tests in place. We can always revert changes in SVN, if need be.
In the meantime, double precision Pd builds were prematurely announced on puredata.info on Otober 4. We have two weeks of wrecked pd-double builds on the autobuild pages, but the pd-double announcement is already leading it's own viral life, see for example an aside in this thread (Pd forum):
http://puredata.hurleur.com/sujet-6287-filter-object-bug-iemlib
I am now looking for a way to better manage info and support on this topic. The double-readiness of pd core code is a modest achievement, a seed from which double-precision-enabled Pd / Pd-extended will hopefully grow. This perspective may be easily be overshadowed by reports of disappointment when pd users can not find executables, or even worse, test the wrecked builds. An early conclusion will be that double-precision Pd is a pathetic failure, and this may in turn discourage further development.
I think the key is getting as much info out as possible, and letting people know what they are getting involved in. I agree, we should not call the pd-double builds anything like a release, far from it. They are development builds, just like the nightly builds of Pd-extended. As long as that is clear, then it is good to publish as much as possible to anyone who wants to get easily get involved in testing and development. Also known as "release early, release often".
Would it be possible to have double-precision vanilla Pd builds produced for all OS'ses, and make them available via puredata.info? I can include test- and demo-patches, and we could set up a place to collect such patches from users. This would be a positive way to get a taste of double-precision Pd. The nightly pd-double builds instead, are at the moment only useful for hardcore testers, devs and maintainers, they can not help in promoting the topic among pd users.
Its definitely possible. For GNU/Linux, just release a tarball of the git, or just tell people to 'git clone'. For Mac OS X, you can do:
cd packages/darwin_app make install
And you'll have a build/Pd-double.app that is only the core, no libs. Then zip that up and post it. For Windows it would be possible to add a target in packages/win32_inno/Makefile to make a core-only .zip.
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.