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 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