Ok, I chatted with IOhannes on #dataflow. He agreed, so I pushed this change to the pd-extended.git, so tomorrow's builds should have it.
IOhannes, I could find where you posted this patch, perhaps its not on the patch tracker yet. In any case attached is the updated version: .hc
implement-PD_BIGORSMALL-with-unions.patch
Description: Binary data
On Nov 8, 2011, at 10:37 AM, Hans-Christoph Steiner wrote: > > 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/ > > ---------------------------------------------------------------------------- Access to computers should be unlimited and total. - the hacker ethic
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
