[PD-dev] [PD] double precision merged

[Lucas Cordiviola]

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