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.
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
