[PD] Fw: Re: stale pointers after object creation (was Re: pix_data issue)

[Christof Ressi]

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 at gmx.at>
> An: pd-list <pd-list at iem.at>
> Cc: "Miller Puckette" <msp at 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 at gmail.com>
> > An: pd-list at 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 at 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 at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> >
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpointer-issue.pd
Type: application/octet-stream
Size: 1668 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180228/b58a2654/attachment-0001.obj>