I guess this is mainly for the Pd devs,
Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free.
Initially, I designed a workaround where pd_free is enqueued on the guiqueue and invoked a bit later ensuring that it is called after the tree navigation has ended. This works in most cases but not all. Intermittently this will crash Pd when using Jonathan's Nav abstraction which closes the current patch and also opens a new patch (navigation abstraction would be used to go between help files always keeping only one patch open at a time). Attached is Jonathan's abstraction.
So, now I started investigating further and it seems that canvas_vis(x,0) closes the patch without any problems and without having to delay anything but this is not enough in and of itself to actually deallocate the actual t_canvas x and other instantiated objects associated with the canvas. So, how could one go about to implement this feature?
Ico
On 11/19/2011 05:39 PM, Ivica Ico Bukvic wrote:
I guess this is mainly for the Pd devs,
Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free.
Initially, I designed a workaround where pd_free is enqueued on the guiqueue and invoked a bit later ensuring that it is called after the tree navigation has ended. This works in most cases but not all. Intermittently this will crash Pd when using Jonathan's Nav abstraction which closes the current patch and also opens a new patch (navigation abstraction would be used to go between help files always keeping only one patch open at a time). Attached is Jonathan's abstraction.
So, now I started investigating further and it seems that canvas_vis(x,0) closes the patch without any problems and without having to delay anything but this is not enough in and of itself to actually deallocate the actual t_canvas x and other instantiated objects associated with the canvas. So, how could one go about to implement this feature?
you could just use [canvasdelete] from iemguts. send a "bang" to [canvasdelete] and it will delete itself sand a "bang" to [canvasdelete 1] and it will delete the containing abstraction.
that is, it will not close an opened patch (es opposed to an abstraction contained within a patch), but it should be simple to add this functionality to the existing framework.
famsdr IOhannes
-
IOhannes zmölnig -
Ivica Ico Bukvic