Hey Katja,
I was just reviewing the double precision patches for the extra/ section of pure-data. I think we should try to get Miller to accept the 'extra/' fixes into pure-data.git now. It seems to me that almost all of these changes are just float --> t_float, which are really no-brainers that would be really difficult to imagine causing problems. Plus judging by all the tests you have written, it looks like your code is already pretty well tested.
There are only a couple changes in this patch that are not no-brainers. The first is in sigmund~.c, it looks like you just moved up the #ifdef PD and #ifdef MSP blocks to the top of the file. Seems harmless enough. Then there are a couple places where the code is using 'f' to force single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x) { if (x->x_useloudness) growth += qrsqrt(qrsqrt( - power/(h->h_mask[oldmaskphase] + 1.0e-15))) - 1.f; - else growth += power/(h->h_mask[oldmaskphase] + 1.0e-15) - 1.f; + power/(h->h_mask[oldmaskphase] + 1.0e-15))) - 1.; + else growth += power/(h->h_mask[oldmaskphase] + 1.0e-15) - 1.; } if (!x->x_willattack && countup >= x->x_masktime) maskpow *= x->x_maskdecay;
And cases where there are added typedefs which I don't really understand what's going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.000000000 +0200 +++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.000000000 +0200 @@ -37,6 +37,7 @@ #else /* MSP */ #include "ext.h" #include "z_dsp.h" +typedef float t_float; // t_float is from m_pd.h #endif
#include "fts_to_pd.h" --- extra_original/fiddle~/fiddle~.c 2010-04-26 00:27:35.000000000 +0200 +++ extra_double_ready/fiddle~/fiddle~.c 2011-09-06 11:36:28.000000000 +0200 @@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0; #endif /* MSP */
#ifdef MSP -#define t_floatarg double #include "ext.h" #include "z_dsp.h" #include "fft_mayer.proto.h" - +typedef float t_float; +typedef double t_floatarg; #endif /* MSP */
#include <math.h> --- extra_original/loop~/loop~.c 2010-07-28 22:55:17.000000000 +0200 +++ extra_double_ready/loop~/loop~.c 2011-09-06 11:33:54.000000000 +0200 @@ -14,7 +14,8 @@ This file is downloadable from http://ww #ifdef PD #include "m_pd.h" #else -#define t_sample float +typedef float t_float; +typedef float t_sample; #endif
--- extra_original/pd~/pd~.c 2010-07-28 22:55:17.000000000 +0200 +++ extra_double_ready/pd~/pd~.c 2011-09-06 11:38:12.000000000 +0200 @@ -26,7 +26,7 @@ #include "ext_support.h" #include "ext_proto.h" #include "ext_obex.h" - +typedef float t_float; typedef double t_floatarg; #define w_symbol w_sym #define A_SYMBOL A_SYM
.hc
----------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Tue, Nov 8, 2011 at 9:04 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Hey Katja,
I was just reviewing the double precision patches for the extra/ section of pure-data. I think we should try to get Miller to accept the 'extra/' fixes into pure-data.git now. It seems to me that almost all of these changes are just float --> t_float, which are really no-brainers that would be really difficult to imagine causing problems. Plus judging by all the tests you have written, it looks like your code is already pretty well tested.
In fact I only tested rewritten core functions intensively (on OSX and Linux), for the extra's I just had a peek at the helpfiles so far, and checked that there was no ridiculous output during normal use. So, I'm not sure if it is wise to submit a patch file now. But I will try to answer your questions below, one by one.
There are only a couple changes in this patch that are not no-brainers. The first is in sigmund~.c, it looks like you just moved up the #ifdef PD and #ifdef MSP blocks to the top of the file. Seems harmless enough.
These blocks had to move up because t_float was otherwise not known by the compiler, for the first part of the code. It is now no longer the case that the first part can be used without modification in an arbitrary application, like it used to be the case. An application programmer using this code for anything else than Pd/MaxMsp, should define t_float in another way. A comment could be added to mention that t_float may be float or double?
Then there are a couple places where the code is using 'f' to force single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x) { if (x->x_useloudness) growth += qrsqrt(qrsqrt(
- power/(h->h_mask[oldmaskphase] + 1.0e-15))) - 1.f;
- else growth += power/(h->h_mask[oldmaskphase] + 1.0e-15) - 1.f;
- power/(h->h_mask[oldmaskphase] + 1.0e-15))) - 1.;
- else growth += power/(h->h_mask[oldmaskphase] + 1.0e-15) - 1.;
} if (!x->x_willattack && countup >= x->x_masktime) maskpow *= x->x_maskdecay;
I removed float suffixes consistently from code which I came across. In the case of 1., 2. etc. this is of no consequence for the actual value, but for other numbers it is. For example a float 0.001 cast to double precision becomes 0.0010000000474974513, while the double could be precise almost up to it's last digit. There's a nice online applet 'IEEE 754 Converter' on http://www.h-schmidt.net/FloatApplet/IEEE754.html, showing such rounding effects. One could use the float suffix to make sure no redundant typecasts are done, but in the case of code compilable for single and double precision, it has no advantage to force single precision.
I have seen it stated on internet that something like 'float f = 1.0' cannot be compiled in C++, it should be 'float f = 1.0f'. However, in practice I've not met such problems with C++. Hope this is true on any platform (otherwise we're stuck).
And cases where there are added typedefs which I don't really understand what's going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.000000000 +0200 +++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.000000000 +0200 @@ -37,6 +37,7 @@ #else /* MSP */ #include "ext.h" #include "z_dsp.h" +typedef float t_float; // t_float is from m_pd.h #endif
#include "fts_to_pd.h" --- extra_original/fiddle~/fiddle~.c 2010-04-26 00:27:35.000000000 +0200 +++ extra_double_ready/fiddle~/fiddle~.c 2011-09-06 11:36:28.000000000 +0200 @@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0; #endif /* MSP */
#ifdef MSP -#define t_floatarg double #include "ext.h" #include "z_dsp.h" #include "fft_mayer.proto.h"
+typedef float t_float; +typedef double t_floatarg; #endif /* MSP */
#include <math.h> --- extra_original/loop~/loop~.c 2010-07-28 22:55:17.000000000 +0200 +++ extra_double_ready/loop~/loop~.c 2011-09-06 11:33:54.000000000 +0200 @@ -14,7 +14,8 @@ This file is downloadable from http://ww #ifdef PD #include "m_pd.h" #else -#define t_sample float +typedef float t_float; +typedef float t_sample; #endif
--- extra_original/pd~/pd~.c 2010-07-28 22:55:17.000000000 +0200 +++ extra_double_ready/pd~/pd~.c 2011-09-06 11:38:12.000000000 +0200 @@ -26,7 +26,7 @@ #include "ext_support.h" #include "ext_proto.h" #include "ext_obex.h"
+typedef float t_float; typedef double t_floatarg; #define w_symbol w_sym #define A_SYMBOL A_SYM
Ah these typedefs are nonsense indeed, t_float and t_floatarg are defined in msp's zdsp.h as well, at least since Max/Msp5, earlier versions I don't know.
Katja
On Nov 8, 2011, at 8:32 PM, katja wrote:
On Tue, Nov 8, 2011 at 9:04 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Hey Katja,
I was just reviewing the double precision patches for the extra/ section of pure-data. I think we should try to get Miller to accept the 'extra/' fixes into pure-data.git now. It seems to me that almost all of these changes are just float --> t_float, which are really no-brainers that would be really difficult to imagine causing problems. Plus judging by all the tests you have written, it looks like your code is already pretty well tested.
In fact I only tested rewritten core functions intensively (on OSX and Linux), for the extra's I just had a peek at the helpfiles so far, and checked that there was no ridiculous output during normal use. So, I'm not sure if it is wise to submit a patch file now. But I will try to answer your questions below, one by one.
There are only a couple changes in this patch that are not no-brainers. The first is in sigmund~.c, it looks like you just moved up the #ifdef PD and #ifdef MSP blocks to the top of the file. Seems harmless enough.
These blocks had to move up because t_float was otherwise not known by the compiler, for the first part of the code. It is now no longer the case that the first part can be used without modification in an arbitrary application, like it used to be the case. An application programmer using this code for anything else than Pd/MaxMsp, should define t_float in another way. A comment could be added to mention that t_float may be float or double?
Then there are a couple places where the code is using 'f' to force single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x) { if (x->x_useloudness) growth += qrsqrt(qrsqrt(
power/(h->h_mask[oldmaskphase] + 1.0e-15))) - 1.f;else growth += power/(h->h_mask[oldmaskphase] + 1.0e-15) - 1.f;
power/(h->h_mask[oldmaskphase] + 1.0e-15))) - 1.;else growth += power/(h->h_mask[oldmaskphase] + 1.0e-15) - 1.; } if (!x->x_willattack && countup >= x->x_masktime) maskpow *= x->x_maskdecay;I removed float suffixes consistently from code which I came across. In the case of 1., 2. etc. this is of no consequence for the actual value, but for other numbers it is. For example a float 0.001 cast to double precision becomes 0.0010000000474974513, while the double could be precise almost up to it's last digit. There's a nice online applet 'IEEE 754 Converter' on http://www.h-schmidt.net/FloatApplet/IEEE754.html, showing such rounding effects. One could use the float suffix to make sure no redundant typecasts are done, but in the case of code compilable for single and double precision, it has no advantage to force single precision.
I have seen it stated on internet that something like 'float f = 1.0' cannot be compiled in C++, it should be 'float f = 1.0f'. However, in practice I've not met such problems with C++. Hope this is true on any platform (otherwise we're stuck).
And cases where there are added typedefs which I don't really understand what's going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.000000000 +0200 +++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.000000000 +0200 @@ -37,6 +37,7 @@ #else /* MSP */ #include "ext.h" #include "z_dsp.h" +typedef float t_float; // t_float is from m_pd.h #endif
#include "fts_to_pd.h" --- extra_original/fiddle~/fiddle~.c 2010-04-26 00:27:35.000000000 +0200 +++ extra_double_ready/fiddle~/fiddle~.c 2011-09-06 11:36:28.000000000 +0200 @@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0; #endif /* MSP */
#ifdef MSP -#define t_floatarg double #include "ext.h" #include "z_dsp.h" #include "fft_mayer.proto.h"
+typedef float t_float; +typedef double t_floatarg; #endif /* MSP */
#include <math.h> --- extra_original/loop~/loop~.c 2010-07-28 22:55:17.000000000 +0200 +++ extra_double_ready/loop~/loop~.c 2011-09-06 11:33:54.000000000 +0200 @@ -14,7 +14,8 @@ This file is downloadable from http://ww #ifdef PD #include "m_pd.h" #else -#define t_sample float +typedef float t_float; +typedef float t_sample; #endif
--- extra_original/pd~/pd~.c 2010-07-28 22:55:17.000000000 +0200 +++ extra_double_ready/pd~/pd~.c 2011-09-06 11:38:12.000000000 +0200 @@ -26,7 +26,7 @@ #include "ext_support.h" #include "ext_proto.h" #include "ext_obex.h"
+typedef float t_float; typedef double t_floatarg; #define w_symbol w_sym #define A_SYMBOL A_SYM
Ah these typedefs are nonsense indeed, t_float and t_floatarg are defined in msp's zdsp.h as well, at least since Max/Msp5, earlier versions I don't know.
Ah I see, they are for Max/MSP only? I didn't notice that before. So I guess the thing to do would be for you do make adjustments in the pd-double.git, then we can rebase into a patch for just extra and submit it for Miller. I think these changes are worth getting into pure-data.git now since in 0.42 Miller already went thru the core source code to make sure all of the t_float and t_sample types were used where they made sense.
.hc
----------------------------------------------------------------------------
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
On Wed, Nov 9, 2011 at 4:58 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Ah these typedefs are nonsense indeed, t_float and t_floatarg are defined in msp's zdsp.h as well, at least since Max/Msp5, earlier versions I don't know.
Ah I see, they are for Max/MSP only? I didn't notice that before. So I guess the thing to do would be for you do make adjustments in the pd-double.git, then we can rebase into a patch for just extra and submit it for Miller. I think these changes are worth getting into pure-data.git now since in 0.42 Miller already went thru the core source code to make sure all of the t_float and t_sample types were used where they made sense.
Checked it once more, t_float and t_sample are defined in zdsp.h at least in Max/Msp version 4.6 and 5 (not t_floatarg however, a float argument is always a double in Max/Msp). Since zdsp.h is included in all cases, I should leave t_float and t_sample typedefs out indeed. I'll do the adjustments in pd-double.git. Remarkably, t_float is not defined in the max-includes (for non-signal classes) in Max/Msp.
So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_sample<>t_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git?
Katja
On Nov 9, 2011, at 11:14 AM, katja wrote:
On Wed, Nov 9, 2011 at 4:58 AM, Hans-Christoph Steiner hans@at.or.at wrote:
Ah these typedefs are nonsense indeed, t_float and t_floatarg are defined in msp's zdsp.h as well, at least since Max/Msp5, earlier versions I don't know.
Ah I see, they are for Max/MSP only? I didn't notice that before. So I guess the thing to do would be for you do make adjustments in the pd-double.git, then we can rebase into a patch for just extra and submit it for Miller. I think these changes are worth getting into pure-data.git now since in 0.42 Miller already went thru the core source code to make sure all of the t_float and t_sample types were used where they made sense.
Checked it once more, t_float and t_sample are defined in zdsp.h at least in Max/Msp version 4.6 and 5 (not t_floatarg however, a float argument is always a double in Max/Msp). Since zdsp.h is included in all cases, I should leave t_float and t_sample typedefs out indeed. I'll do the adjustments in pd-double.git. Remarkably, t_float is not defined in the max-includes (for non-signal classes) in Max/Msp.
So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_sample<>t_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git?
I think we should submit the current changes now since they will get things building at double-precision at least. Then further fixes can be submitted later.
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
On Wed, Nov 9, 2011 at 5:51 PM, Hans-Christoph Steiner hans@at.or.at wrote:
So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_sample<>t_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git?
I think we should submit the current changes now since they will get things building at double-precision at least. Then further fixes can be submitted later.
Ok, now done like this: whenever it's straightforward to implement t_sample, I do so, but in complicated cases where it's too time consuming I leave it for later.
When doing a last check on the 'extra' objects, I ran into a problem with the install as done by the new build system. (Though Pd core works without install, the extra's do not, so a regular or local install must be done to test the objects.) The [pd~] object can not be loaded, it says:
pd~: can't stat /usr/local/lib/pd/pd
This seems unrelated to the double-ready code, because pure-data.git shows exactly the same issue when built with the new build system. Also, these builds both show:
soundfiler_read: ../doc/sound/voice.wav: No such file or directory
while the file is certainly located in /usr/local/doc/sound/ and pd is running from /usr/local/bin/. With local build, same problem. Using the old build system for a local build, these issues did never appear. Neither with packaged builds.
All stuff in 'extra' is checked now, apart from [pd~]. So I'd suggest:
- I push the changes to pd-double - could the old build system be brought back into pd-double, for convenience? - only when [pd~] is verified to work, let's submit patch for pure-data.git
Katja
On Nov 9, 2011, at 6:46 PM, katja wrote:
On Wed, Nov 9, 2011 at 5:51 PM, Hans-Christoph Steiner hans@at.or.at wrote:
So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_sample<>t_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git?
I think we should submit the current changes now since they will get things building at double-precision at least. Then further fixes can be submitted later.
Ok, now done like this: whenever it's straightforward to implement t_sample, I do so, but in complicated cases where it's too time consuming I leave it for later.
When doing a last check on the 'extra' objects, I ran into a problem with the install as done by the new build system. (Though Pd core works without install, the extra's do not, so a regular or local install must be done to test the objects.) The [pd~] object can not be loaded, it says:
pd~: can't stat /usr/local/lib/pd/pd
This seems unrelated to the double-ready code, because pure-data.git shows exactly the same issue when built with the new build system. Also, these builds both show:
soundfiler_read: ../doc/sound/voice.wav: No such file or directory
while the file is certainly located in /usr/local/doc/sound/ and pd is running from /usr/local/bin/. With local build, same problem. Using the old build system for a local build, these issues did never appear. Neither with packaged builds.
All stuff in 'extra' is checked now, apart from [pd~]. So I'd suggest:
- I push the changes to pd-double
- could the old build system be brought back into pd-double, for convenience?
- only when [pd~] is verified to work, let's submit patch for pure-data.git
Even better would be to fix the new build system. One of the reasons I removed extra/ from Pd-extended and made it a separate library is because of the brokenness of the build system.
IOhannes, since you wrote the current build system in extra/, could you tackle this? It doesn't work on Mac OS X, it creates .la and .lo files, but not .pd_darwin. I also seem to remember no MinGW support.
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-10 16:26, Hans-Christoph Steiner wrote:
Even better would be to fix the new build system. One of the reasons I removed extra/ from Pd-extended and made it a separate library is because of the brokenness of the build system.
IOhannes, since you wrote the current build system in extra/, could you tackle this? It doesn't work on Mac OS X, it creates .la and .lo files, but not .pd_darwin. I also seem to remember no MinGW support.
on OSX, it creates .d_fat files. at least that is what i get on jenkins [1]
there's also a mingw branch on my github clone of pd-vanilla [1], that fixes a number of build issues on mingw, e.g. linking with g++ when building asio. (though, iirc, it still doesn't produce dlls for the externals)
fgmasdr IOhannes
[1] https://160.79.59.149:8443/job/pure-data/all=macosx106/ws/pure-data/usr/loca...
[2] https://github.com/umlaeute/pd-vanilla/tree/mingw
On Nov 10, 2011, at 11:05 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-10 16:26, Hans-Christoph Steiner wrote:
Even better would be to fix the new build system. One of the reasons I removed extra/ from Pd-extended and made it a separate library is because of the brokenness of the build system.
IOhannes, since you wrote the current build system in extra/, could you tackle this? It doesn't work on Mac OS X, it creates .la and .lo files, but not .pd_darwin. I also seem to remember no MinGW support.
on OSX, it creates .d_fat files. at least that is what i get on jenkins [1]
That is 'make install' doing that, not 'make'. 'make install' is only supposed to install the files, not generate them. And it should really use .pd_darwin. There is no reason to have multiple file endings in Mac OS X, the universal file format handles that.
.hc
there's also a mingw branch on my github clone of pd-vanilla [1], that fixes a number of build issues on mingw, e.g. linking with g++ when building asio. (though, iirc, it still doesn't produce dlls for the externals)
fgmasdr IOhannes
[1] https://160.79.59.149:8443/job/pure-data/all=macosx106/ws/pure-data/usr/loca...
[2] https://github.com/umlaeute/pd-vanilla/tree/mingw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk679kIACgkQkX2Xpv6ydvSCHACgqJFcLcNHAVbBZoF9R55nKBPK YFQAoMepV8dfHzpJqf5zTLNhbJwajRXX =ZhZ8 -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-10 17:57, Hans-Christoph Steiner wrote:
That is 'make install' doing that, not 'make'. 'make install' is only supposed to install the files, not generate them.
indeed. "make" generated the .d_fat files, and "make install" copied them to location i pointed you too, so you can see that the files have been generated.
And it should really use .pd_darwin. There is no reason to have multiple file endings in Mac OS X, the universal file format handles that.
indeed there is no reason, hence i use .d_fat which i think has been the default for Pd for years.
fgamndr IOhannes
On Nov 10, 2011, at 12:16 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-10 17:57, Hans-Christoph Steiner wrote:
That is 'make install' doing that, not 'make'. 'make install' is only supposed to install the files, not generate them.
indeed. "make" generated the .d_fat files, and "make install" copied them to location i pointed you too, so you can see that the files have been generated.
There are no .d_fat files here: https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/
or here:
https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/bonk~/
Only pd~.d_fat gets generated by 'make'. Shall I file a bug report?
And it should really use .pd_darwin. There is no reason to have multiple file endings in Mac OS X, the universal file format handles that.
indeed there is no reason, hence i use .d_fat which i think has been the default for Pd for years.
Currently the only thing that is released as .d_fat is the Pd vanilla extra files. Everything else uses .pd_darwin, even Gem ;)
.hc
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-10 18:21, Hans-Christoph Steiner wrote:
On Nov 10, 2011, at 12:16 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-10 17:57, Hans-Christoph Steiner wrote:
That is 'make install' doing that, not 'make'. 'make install' is only supposed to install the files, not generate them.
indeed. "make" generated the .d_fat files, and "make install" copied them to location i pointed you too, so you can see that the files have been generated.
There are no .d_fat files here: https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/
or here:
https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/bonk~/
https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/bonk~/.libs/
Only pd~.d_fat gets generated by 'make'. Shall I file a bug report?
And it should really use .pd_darwin. There is no reason to have multiple file endings in Mac OS X, the universal file format handles that.
indeed there is no reason, hence i use .d_fat which i think has been the default for Pd for years.
Currently the only thing that is released as .d_fat is the Pd vanilla extra files. Everything else uses .pd_darwin, even Gem ;)
the build system was done for Pd-vanilla, therefore the extension used by Pd vanilla was chosen. i usually try to avoid smuggling ideological things into the code base by means of a side-effect of another patch.
fgamsdr IOhannes
On Thu, Nov 10, 2011 at 4:26 PM, Hans-Christoph Steiner hans@at.or.at wrote:
Even better would be to fix the new build system. One of the reasons I removed extra/ from Pd-extended and made it a separate library is because of the brokenness of the build system.
For the moment, I abuse the Pd-extended package build system to produce a properly working vanilla Pd-double. The target 'darwin_app_core' seems to build pd-extended/extra/, or in my case pd-double/extra/. Not pd-svn/externals/extra/, I know because this code does not yet compile in double precision. O yeah, there's one thing to remember when hacking this way: the script changes the PD_TEST_VERSION definition in m_pd.h.
Via this build, using the regular helpfiles, I've checked that all 'extra' objects appear to work normally in double precision now. A single precision build was checked earlier. I've pushed the latest changes to the pd-double github. Since all changes to the extra's are fairly trivial (float to t_float or t_sample mostly), I don't think that more detailed tests are needed here for single precision case. For double precision, the [expr] family should be tested more thoroughly someday, but this need not prevent us from submitting a patch for pure-data.git now.
Katja
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
katja