Hi Miller, I think there may be a memory leak regarding [setsize] and your new text field. The user is initializing and potentially populating many t_binbufs through word_init after they enlarge an array with [setsize]. But if they set a smaller size with [setsize] it doesn't look like you are freeing those t_binbufs.
I noticed this while reworking your old DT_LIST field to create canvases as data fields. I do [struct test canvas foo bar], which reads an abstraction name bar.pd (if it exists) into a binbuf associated with the corresponding struct. Then when I create a scalar, it evaluates that t_binbuf which creates a hidden toplevel "bar.pd" canvas. The fun comes when using the "canvas foo bar" field in a template for an array field-- then I can use [setsize] to create a massive number of abstractions at once. But when I decrease the array size my abstractions linger until I "vis" them and close them.
So I'm guessing it's the same problem with DT_TEXT, no?
-Jonathan
Sure enough... thanks.
M
On Mon, Nov 10, 2014 at 06:16:47PM -0800, Jonathan Wilkes via Pd-list wrote:
Hi Miller, I think there may be a memory leak regarding [setsize] and your new text field. The user is initializing and potentially populating many t_binbufs through word_init after they enlarge an array with [setsize]. But if they set a smaller size with [setsize] it doesn't look like you are freeing those t_binbufs.
I noticed this while reworking your old DT_LIST field to create canvases as data fields. I do [struct test canvas foo bar], which reads an abstraction name bar.pd (if it exists) into a binbuf associated with the corresponding struct. Then when I create a scalar, it evaluates that t_binbuf which creates a hidden toplevel "bar.pd" canvas. The fun comes when using the "canvas foo bar" field in a template for an array field-- then I can use [setsize] to create a massive number of abstractions at once. But when I decrease the array size my abstractions linger until I "vis" them and close them.
So I'm guessing it's the same problem with DT_TEXT, no?
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One amorphous question:
With my canvas field, I can keep track of the canvas associated with a scalar by getting a pointer to that scalar (or to an array).
But inside that canvas itself, how would I find/generate a gpointer to the scalar (or array) that's associated with me? I was thinking about pd_bind, but the fact that the t_word might be inside an array seems like it complicates things a bit. With such an association that canvas could, for example, sample a tilde object's output and use that to set the "y" field for the associated scalar. Then you could create a scalar and have it animate itself while outputting audio, all without having to traverse a glist.
-Jonathan
On Tuesday, November 11, 2014 12:01 PM, Miller Puckette msp@ucsd.edu wrote:
Sure enough... thanks.
M
On Mon, Nov 10, 2014 at 06:16:47PM -0800, Jonathan Wilkes via Pd-list wrote:
Hi Miller, I think there may be a memory leak regarding [setsize] and your new text field. The user is initializing and potentially populating many t_binbufs through word_init after they enlarge an array with [setsize]. But if they set a smaller size with [setsize] it doesn't look like you are freeing those t_binbufs.
I noticed this while reworking your old DT_LIST field to create canvases as data fields. I do [struct test canvas foo bar], which reads an abstraction name bar.pd (if it exists) into a binbuf associated with the corresponding struct. Then when I create a scalar, it evaluates that t_binbuf which creates a hidden toplevel "bar.pd" canvas. The fun comes when using the "canvas foo bar" field in a template for an array field-- then I can use [setsize] to create a massive number of abstractions at once. But when I decrease the array size my abstractions linger until I "vis" them and close them.
So I'm guessing it's the same problem with DT_TEXT, no?
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Jonathan Wilkes -
Miller Puckette