[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