[PD-dev] nightly builds broken

[katja]

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 <hans at at.or.at> 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
>> Pd-dev at iem.at
>> 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
>
>
>
>
>