<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 31, 2020 at 5:34 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">
What I mean is how do we differentiate between dynamic patching and a)<br>
loading a patch or b) regular patching through<br>
the g_editor.c event callbacks?<br></blockquote><div><br></div><div>Hmm yes, you're right. But after loading a patch its undo history should be empty anyway, right? (This assumes that the undo history is being kept locally in each patch, if not then all this becomes much harder.) So then we just need to distinguish dynamic patching from the g_editor.c event callbacks, in which case the necessary breadcrumbs could possibly be provided by the undo engine, or by those callbacks themselves. Yeah, it won't be pretty I'm afraid. :(<br></div><div><br> </div><div>Albert</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example, there are no breadcrumbs left in canvas_obj to tell the<br>
difference. And I'd hate to add a bunch more globals<br>
to track "is_loading_stuff", "is_editing_stuff", "is_dynamically_patching", etc.<br>
<br>
-Jonathan<br>
<br>
><br>
> Albert<br>
><br>
>> > On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
>> >><br>
>> >> 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><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > 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/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><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><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><br>
><br>
><br>
><br>
> --<br>
> 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/" rel="noreferrer" target="_blank">https://agraef.github.io/</a><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><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></div>