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