<div dir="ltr">Many thanks for the clarification, Miller.<div><br></div><div>The challenge I am trying to figure out is a memory leak report that Jonathan shared with me. See:</div><div><br></div><div><a href="https://sourceforge.net/tracker/?func=detail&aid=3605235&group_id=55736&atid=478070">https://sourceforge.net/tracker/?func=detail&aid=3605235&group_id=55736&atid=478070</a><br>
</div><div><br></div><div style>Basically deleting and creating the same object (in this case through script as that is obviously quicker than doing it manually) keeps pd (or pd-l2ork in this case) growing in terms of its memory footprint. I was hoping that closing the patch would free that up but it doesn't...</div>
<div style><br></div><div style>Hence, my little adventure into figuring out why the said call. I am sure there are others as even disabling that call doesn't help much in curbing the growing memory footprint (at least over here).</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 25, 2013 at 11:17 PM, Miller Puckette <span dir="ltr"><<a href="mailto:msp@ucsd.edu" target="_blank">msp@ucsd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't remember why it's there (and perhaps it's no longer necessary) -<br>
but I suspect it had something to do with a subtle problem when deleting<br>
a GOP whose interior got mad wieh there was no rtext for the owning object.<br>
<br>
The rtext eventualy goes away when the window is closed - but perhaps it's<br>
a problem if there's a self-editing patch that creates and deletes<br>
1000s of objects in an open window?<br>
<br>
cheers<br>
Miller<br>
<div><div class="h5"><br>
<br>
On Mon, Feb 25, 2013 at 10:36:46PM -0500, Ivica Ico Bukvic wrote:<br>
> Does anyone know why does the following exist inside the<br>
> glist_delete function inside g_graph.c:<br>
><br>
> /* if we're a drawing command, erase all scalars now,<br>
> before deleting<br>
> it; we'll redraw them once it's deleted below. */<br>
> if (drawcommand)<br>
> canvas_redrawallfortemplate(template_findbyname(canvas_makebindsym(<br>
> glist_getcanvas(x)->gl_name)), 2);<br>
> if (glist_isvisible(canvas))<br>
> gobj_vis(y, x, 0);<br>
> --> if (x->gl_editor && (ob = pd_checkobject(&y->g_pd)))<br>
> --> rtext_new(x, ob);<br>
> if (x->gl_list == y) {<br>
><br>
> That rtext is never freed after that so unless I am missing<br>
> something I see no reason why we would want to do this. Any ideas?<br>
><br>
> --<br>
> Ivica Ico Bukvic, D.M.A<br>
> Composition, Music Technology<br>
> Director, DISIS Interactive Sound & Intermedia Studio<br>
> Director, L2Ork Linux Laptop Orchestra<br>
> Head, ICAT IMPACT Studio<br>
> Virginia Tech<br>
> Department of Music<br>
> Blacksburg, VA 24061-0240<br>
> (540) 231-6139<br>
> (540) 231-5034 (fax)<br>
> <a href="http://disis.music.vt.edu" target="_blank">disis.music.vt.edu</a><br>
> <a href="http://l2ork.music.vt.edu" target="_blank">l2ork.music.vt.edu</a><br>
> <a href="http://ico.bukvic.net" target="_blank">ico.bukvic.net</a><br>
><br>
<br>
</div></div>> _______________________________________________<br>
> Pd-dev mailing list<br>
> <a href="mailto:Pd-dev@iem.at">Pd-dev@iem.at</a><br>
> <a href="http://lists.puredata.info/listinfo/pd-dev" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br>
<br>
</blockquote></div><br></div>