[PD-dev] nightly builds broken

[Hans-Christoph Steiner]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: implement-PD_BIGORSMALL-with-unions.patch
Type: application/octet-stream
Size: 2905 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20111108/9dda1e07/attachment.obj>
-------------- next part --------------



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 <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/
> 
> 


----------------------------------------------------------------------------

Access to computers should be unlimited and total.  - the hacker ethic