<div dir="ltr"><div>Hi Jonathan,</div><div><br></div><div>I'm amazed that undo/redo works as well as it does, with everything that's going on in a complex system like Pd.</div><div><br></div><div>For now, it seems that certain operations just have to clear the undo history, to prevent crashes further down the road. Maybe also warn the user about this the first time a patch calls any of these operations.</div><div><br></div><div>Albert</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
It appears that dynamic patching nnd the undo system are irreconcilable.<br>
<br>
For example-- Suppose you do this:<br>
<br>
[namecanvas foo]<br>
<br>
[obj 20 20 clip(<br>
|<br>
[send foo]<br>
<br>
Whenever you click the message box, a new object will be created but<br>
without any undo history.<br>
<br>
That's probably desirable behavior, as we don't want a bunch of<br>
dynamically created gumming up the undo system.<br>
<br>
However, the undo system is based off object indices. So by inserting<br>
"[clip]" into a glist we corrupt that system. You can see this if<br>
dynamic patching in the middle of other editing actions. Doing undo<br>
then redo will put the patch in a corrupt state because the indices<br>
will be off by one due to the "[clip]" object that the undo system<br>
didn't expect.<br>
<br>
I don't know any clean way to deal with this. But it affects more than<br>
dynamic patching:<br>
<br>
[pointer(<br>
|<br>
[canvasinfo]<br>
|<br>
[20 20 $1(<br>
|<br>
[append some_scalar x y]<br>
<br>
Same problem there, as well as:<br>
<br>
[pointer(<br>
|<br>
[canvasinfo]<br>
|<br>
[next, delete(<br>
|<br>
[pointer some-scalar]<br>
<br>
Each one breaks the assumptions of the undo system and undo/redo<br>
actions can have wrong indices.<br>
<br>
Even more pressing-- now that we've got pointer delete method, the<br>
undo system can have an out-of-bounds index and crash when it tries to<br>
deference a null pointer.<br>
<br>
Any ideas on how to approach this?<br>
<br>
-Jonathan<br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email: <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a>, web: <a href="https://agraef.github.io/" target="_blank">https://agraef.github.io/</a></div></div></div></div></div></div>