I think the solution is quite easy, PD_FLOATSIZE was introduced in a patch from IOhannes "implement PD_BIGORSMALL() with unions". This patch is not yet included by Miller in pure-data.git. I think we should update that patch in Pd-extended, changing PD_FLOATSIZE to PD_FLOATPRECISION. IOhannes?
.hc On Nov 8, 2011, at 7:18 AM, katja wrote: > Today's autobuilds are broken again, still due to my double-precision > commit! Sorry sorry. The real cause lies here: > > There is a small but crucial difference in the API between Pd-extended > and Pd-double. In Pd-extended, float precision is defined with > PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be > resolved before we can continue developing the external libs against > Pd-double. > > In retrospect, it seems rather illogical to have these different macro > names, so you may wonder how this came about. When I started rewriting > Pd core code last summer to make it ready for double precision, there > was only PD_FLOATTYPE which could be defined 'float' or 'double'. I > soon found that the preprocessor could not do string comparison, and a > numeric definition was needed to do conditional checks at compile > time. I opted for PD_FLOATPRECISION, to be set at 32 or 64 for the > number of bits. Around the same time, IOhannes introduced a macro > PD_FLOATSIZE (to be set at 32 or 64) in Pd-extended when he rewrote > PD_BIGORSMALL as an inline function. > > Yes, it is quite stupid that two nights of broken builds were needed > to bring back these different macro's to mind. How should we resolve > this? I'd like to stay with PD_FLOATPRECISION for it's unambiguity > (size normally refers to number of bytes, not bits), but on the other > hand, PD_FLOATSIZE may already be used by developers of external libs > in the meantime. If we can not solve this today, I will undo my > changes to creb for the moment, to no longer block the builds. > > Katja > > > > > On Mon, Nov 7, 2011 at 5:08 PM, Hans-Christoph Steiner <[email protected]> wrote: >> >> No big thing, we all break the build sometimes :) Thanks for the quick fix. >> As long as you follow up the next day, don't worry too much about breaking >> the build. Its only really a problem when we go more than a couple days >> without builds. But yes, it is better to not break the build ;) >> >> .hc >> >> On Nov 7, 2011, at 6:51 AM, katja wrote: >> >>> Found my mistake, affecting single precision i386 and x86_64 builds. >>> It is repaired now. I'll refine my procedures to make sure a mistake >>> like this won't happen again. Apologies for the inconvenience caused >>> by it. >>> >>> Katja >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> ---------------------------------------------------------------------------- >> >> "Making boring techno music is really easy with modern tools, but with live >> coding, boring techno is much harder." - Chris McCormick >> >> >> >> >> > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev ---------------------------------------------------------------------------- http://at.or.at/hans/ _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
