(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@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@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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing listPd-dev@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev