OK, I see that the refcount is not per scalar but per glist (in t_gstub) so if I understand correctly it's not possible to selectively invalidate gpointers only for the deleted scalars.
also I have to correct myself: adding scalars doesn't invalidate pointers.
so the remaining problem is adding/deleting non-scalar objects. do you consider this a bug or is this by design? if it's a bug I'll make a PR to fix it. I attached a simple test case to illustrate the problem.
Christof
Gesendet: Mittwoch, 28. Februar 2018 um 13:54 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: pd-list pd-list@iem.at Cc: "Miller Puckette" msp@ucsd.edu Betreff: Re: [PD] stale pointers after object creation (was Re: pix_data issue)
I noticed this issue ca. one year ago when I started working on a complex project with data structures which involved dynamically adding/deleting objects to/from a canvas. I even submitted a bug report: https://sourceforge.net/p/pure-data/bugs/1282/
since I've recently started doing a couple a PRs, this is something I want to investigate too.
to explain the problem quickly:
a glist (list of graphical objects) is internally implemented as a linked list. usually, a big advantage of a linked lists is that adding/deleting elements won't touch other elements (especially doesn't move them in memory, like it can happen with dynamically sized arrays). I don't see why adding/deleting graphical objects should invalidate any gpointers - apart from those which pointed to the deleted element(s).
I guess it's meant as a means to keep Pd pointers safe - but what situation does it try it prevent? and why are gpointers also invalidated if you add/delete "normal" text objects which are not scalars (and so no gpointer could possibly point to it)?
any pointers (no pun intended) to the reasons behind this desigin decision are highly appreciated :-)
Gesendet: Mittwoch, 28. Februar 2018 um 12:17 Uhr Von: Fede camarafede@gmail.com An: pd-list@lists.iem.at Betreff: [PD] stale pointers after object creation (was Re: pix_data issue)
Ok, so it is a combination of editing the canvas and pointer memory
i don’t think it has to do with saving. also, i don’t think it would relate to the previous pix_data pointer issue
Here’s a patch
On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] objects when using pointers?
that sounds very fishy to. do you have a patch that exposes the forget-on-save behaviour of [array] or [text]?
gfmdasr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list