[PD-dev] nightly builds broken
Hans-Christoph Steiner
hans at at.or.at
Tue Nov 8 16:37:07 CET 2011
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 <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
>>
>>
>>
>>
>>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
http://at.or.at/hans/
More information about the Pd-dev
mailing list