[PD-dev] PDINSTANCE for Pd (was Re: call for discussion double-precision file extension)

[Antoine Rousseau]

(sorry, too long mail polling, your answer came after my previous one)

cases where an external might want to behave differently depending on
> whether PDINSTANCE is defined or not
>

yes you're right... I remember I helped to fix readsf~/writesf~ for
multi-instance / multi-thread context, by adding  *pd_setinstance() *in the
helper threads.
so I agree with your conclusion. Things will have to be prepared
carefully...

Le lun. 4 avr. 2022 à 15:49, Antoine Rousseau <antoine at metalu.net> a écrit :

> ABI break for multi-instance libpd
>>
>
> only externals already compiled for multi-instance would have to be
> recompiled, I think.
> And it wouldn't allow current externals to be used in a multi-instance
> context.
>
> But it would allow a Pd compiled with PDINSTANCE, or a single-instance
> libpd app compiled with PDINSTANCE to load current externals (compiled
> without PDINSTANCE).
>
> Antoine
>
>
>
> Le lun. 4 avr. 2022 à 15:00, Christof Ressi <info at christofressi.com> a
> écrit :
>
>> I was thinking to a way for the transition: we could:
>> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
>> replacement  macros accordingly),
>> - export "hidden" globals s_*
>> - initialize pd_maininstance pd_s_* fields to the global versions.
>>
>> Yes, this would work. Of course, it would be an ABI break for
>> multi-instance libpd, but I think it would be justified. I guess libpd
>> users rarely rely on pre-build externals, and even if they do, I think it's
>> ok to ask them to recompile.
>>
>> We should probably also put the global s_* symbols in a deprecation macro
>> that tells external authors to use gensym() instead.
>>
>> Christof
>> On 04.04.2022 13:55, Antoine Rousseau wrote:
>>
>> I very much agree that in the future Pd (and externals) could be always
>> compiled with PDINSTANCE.
>>
>> I was thinking to a way for the transition: we could:
>> - change the t_pdinstance pd_s_* fields to pointers (and adapt the s_*
>> replacement  macros accordingly),
>> - export "hidden" globals s_*
>> - initialize pd_maininstance pd_s_* fields to the global versions.
>>
>> CURRENT:
>> /* m_pd.h */
>> struct _pdinstance
>> {
>>     t_symbol  pd_s_float;
>> }
>> #define s_float     (pd_this->pd_s_float)
>>
>> /* m_class.c */
>> t_pdinstance *pdinstance_init(t_pdinstance *x)
>> {
>>     dogensym("float",     &x->pd_s_float,    x);
>> }
>>
>> PROPOSAL:
>> /* m_pd.h */
>> struct _pdinstance
>> {
>>     t_symbol  *pd_s_float;
>> }
>> #define s_float     (*(pd_this->pd_s_float))
>>
>> /* m_class.c */
>> #undef s_float
>> t_symbol s_float;
>> t_pdinstance *pdinstance_init(t_pdinstance *x)
>> {
>>     if(x != &pd_maininstance) x->pd_s_float = gensym("float");
>>     else {
>>         dogensym("float",     &s_float,    x);
>>         x->pd_s_float = &s_float;
>> }
>>
>> What do you think?
>>
>> I've tried this (in libpd context) almost successfully, but I've
>> encountered a problem: the s_float as seen from an app linked to libpd
>> seems to be uninitialized.
>> I've tried something simpler:
>> /* m_class.c */
>> float myfloat = 10.0;
>> t_pdinstance *pdinstance_init(t_pdinstance *x)
>> {
>>     myfloat = 20.0;
>>     printf("pdinstance_init::myfloat: %f\n", myfloat);
>> }
>>
>> /* pdtest.c */
>> extern float myfloat;
>> int main()
>> {
>>     libpd_init();
>>     printf("myfloat: %f\n", myfloat);
>> }
>>
>> cc -I../../../libpd_wrapper -I../../../pure-data/src -O3   -c -o pdtest.o
>> pdtest.c
>> gcc -o pdtest pdtest.o ../../../libs/libpd.so
>>
>> $ pdtest
>> pdinstance_init::myfloat: 20.00000
>> myfloat: 10.00000
>>
>> Do you know why pdtest doesn't see the updated value?
>>
>> Le mer. 30 mars 2022 à 23:51, Christof Ressi <info at christofressi.com> a
>> écrit :
>>
>>> AFAICT, the main issue is that multi-instance Pd misses symbols for
>>> certain global variables, most notably  s_float, s_symbol, s_bang, etc.
>>>
>>> The problem is that these are really exported global structs. If they
>>> were *pointers*, we could simply make them point to the corresponding
>>> field in the main Pd instance. But in this case I don't really see a
>>> solution...
>>>
>>> On 30.03.2022 18:07, IOhannes m zmoelnig wrote:
>>> >
>>> > On 3/30/22 17:45, Dan Wilcox wrote:
>>> >> I lean much more on the side that PDINSTANCE is a low-level, per
>>> >> project compile option and not general-purpose. If you are using
>>> >> libpd, then your environment is a bit more custom anyway.
>>> >
>>> > i wonder what the penalty would be to turn on PDINSTANCE on Pd?
>>> >
>>> >
>>> > obviously a problem with externals, but maybe we can come up with some
>>> > clever hack (under the assumption, that Pd (the app) only runs a
>>> > single instance, even if compiled with multi-instance support) to use
>>> > legacy externals - if that is even possible.
>>> >
>>> > apart from that?
>>> >
>>> > fgadrms
>>> > 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
>>>
>>
>> _______________________________________________
>> Pd-dev mailing listPd-dev at lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220404/c60f5a9c/attachment-0001.htm>