[PD-dev] [PD] double precision merged

[Lucas Cordiviola]

I have requested this as it will be more simple for me to upload 
double-precision externals builds from my current w64 deken (I have 
uploded (many, almost all) the with sources and pd-lib-builder so it 
shouldn't be hard to have windows32/windows64 double builds)


:)

Mensaje telepatico asistido por maquinas.

On 2/26/2020 11:40 AM, Lucas Cordiviola wrote:
> I have also requested this:
>
> https://lists.puredata.info/pipermail/pd-dev/2019-12/022203.html
>
>
> :)
>
> Mensaje telepatico asistido por maquinas.
>
> On 2/26/2020 9:58 AM, Christof Ressi wrote:
>> I see you point and I think it's a philosophical issue. In 
>> Supercollider, for example, I can't compile a UGen plugin and expect 
>> it to run on both Scsynth and Supernova, I rather have to pass the 
>> correct define ("SUPERNOVA"). Plugins are therefore usually built 
>> twice - with and without "-DSUPERNOVA" - and since they have 
>> different extensions and export different symbols, they can coexist. 
>> I think this could be a solution for Pd as well. If we had some 
>> naming convention for double precision externals, we can then just 
>> built both versions unconditionally and Pd will load the correct 
>> version. This can be automated by pd-lib-builder.
>>
>> Christof
>>
>> On 26.02.2020 13:39, IOhannes m zmoelnig wrote:
>>> On 26.02.20 13:00, Christof Ressi wrote:
>>>> I think I found it :-)
>>> https://github.com/pure-data/pure-data/pull/807#issuecomment-561251729
>>> thanks!
>>>
>>>>> if we want to pass the selected precision on to the entire ecosystem
>>>>> that depends on a given Pd runtime (that is: all externals that are
>>>>> built against a specific version of Pd), than the only solution is to
>>>>> replace the default value for PD_FLOATSIZE in m_pd.h.
>>>> I'm not sure I understand. Why do we have to change the default value?
>>>> If someone wants to compile double precision externals, they just have
>>>> to pass the -DPD_FLOATSIZE=64 to the build system (pd-lib-builder 
>>>> could
>>>>
>>> that's the point.
>>>
>>> i don't want to "compile double precision externals".
>>> i want to compile an external that works with the installed version of
>>> Pd, no matter what endianness, data model or sample-type.
>>>
>>> if the installed Pd has not been produced with a tweaked build
>>> (overriding *FLAGS, using a non-standard compiler,...) then any 
>>> external
>>> that was built via the standard procedure (using default *FLAGS and
>>> compiler,...) should "just work".
>>>
>>> endianness, data model,... are kept consistent by using the "default"
>>> compiler for your environment/OS.
>>>
>>> sample-type is defined via a public header that comes with Pd.
>>> why would it define a value that does not match the Pd runtime that
>>> provides it?
>>>
>>>>> enabling a feature via a configure-flag is (at least for me) a way of
>>>>> saying that "from now on, whatever i do with the so-generated project
>>>>> (Pd) will have this feature enabled".
>>>> I don't see the conflict, to be honest. Also, I don't think there's a
>>>> *practical* difference between setting a configure flag and setting 
>>>> the
>>>> CPPFLAGS variable.
>>> that was my point: it's equally simple to use any of the two methods.
>>> but using CPPFLAGS supposedly tells you that you are now cruising
>>> dangerous waters. (some people might not smell any difference; but if
>>> for them both options are the same, /they/ are not a compelling reason
>>> to prefer one over the other)
>>>
>>>> In your example, both happen at configure time. The
>>>> big advantage of having a configure flag is that it is 
>>>> self-documenting
>>>> ("./configure --help").
>>> yes. that's the advantage.
>>> i don't think it outweighs the drawback though.
>>>
>>>
>>> just to make clear:
>>> i'm not at all opposed to adding a configure flag to select the
>>> precision (whether it's "--enable-double", "--enable-double-precision"
>>> or "--enable-precision=double" doesn't matter though i like the latter
>>> better).
>>> but that flag should be reflected in the public API.
>>>
>>> fgasdrm
>>> IOhannes
>>>
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev