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

Antoine Rousseau antoine at metalu.net
Mon Apr 4 15:49:13 CEST 2022


>
> 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/89ee1ed2/attachment-0001.htm>


More information about the Pd-dev mailing list