Hello,
Yesterday I've committed code to creb and smlib. I have checked that all code compiled, even tested every class's functionality before committing. Even so, all nightly builds are apparently broken due to my commit. I'll now try to find out what went wrong and repair it.
Katja
On Mon, 2011-11-07 at 11:13 +0100, katja wrote:
Hello,
Yesterday I've committed code to creb and smlib. I have checked that all code compiled, even tested every class's functionality before committing. Even so, all nightly builds are apparently broken due to my commit. I'll now try to find out what went wrong and repair it.
FYI: The Windows build was broken even before your commit. It fails at compiling mrpeach/net/tcpclient.
Roman
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
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@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
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.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@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
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.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@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@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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
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.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@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@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
On Tue, Nov 8, 2011 at 1:18 PM, katja katjavetter@gmail.com wrote:
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.
And to correct myself once more: I used PD_FLOAT_PRECISION in Pd-double, not PD_FLOATPRECISION. Sigh...
Katja
On Nov 8, 2011, at 11:17 AM, katja wrote:
On Tue, Nov 8, 2011 at 1:18 PM, katja katjavetter@gmail.com wrote:
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.
And to correct myself once more: I used PD_FLOAT_PRECISION in Pd-double, not PD_FLOATPRECISION. Sigh...
Fixed, and here's the updated patch:
.hc
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
-
Hans-Christoph Steiner -
katja -
Roman Haefeli