(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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> > [email protected] >>> > https://lists.puredata.info/listinfo/pd-dev >>> >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> https://lists.puredata.info/listinfo/pd-dev >>> >> >> _______________________________________________ >> Pd-dev mailing >> [email protected]https://lists.puredata.info/listinfo/pd-dev >> >> _______________________________________________ >> Pd-dev mailing list >> [email protected] >> https://lists.puredata.info/listinfo/pd-dev >> >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
