Code corrupted in SEdit

[pamoroso]

Over the past week or so, in two cases SEdit apparently corrupted the code of functions I was editing. Here is what happened in both cases.

After editing a Common Lisp function for some time, I executed the Done command by pressing Ctrl-X in SEdit. Then at a XCL Exec I called the function to test it but the calls didn't seem to do anything despite the function containing several expressions. However, the still open SEdit showed the full code.

In the first occurrence of the issue I saved the program with MAKEFILE, examined the file with SEE, and only the first one or two sexps showed up in the function. I can't remember how many sexps.

The issue happened a second time when editing this function of Insphex:

This is what the function looked like shortly before and after the corruption. I took the screenshot after pressing Ctrl-X in SEdit and evaluating a few test calls. The calls returned just the docstring and did nothing else. Printing the function with PP at an Exec confirmed the function contained only the docstring despite SEdit still showing the full code as in the screenshot

Both times I didn't lose any work and retyping the code was just a minor inconvenience, as the functions were short and I had taken screenshots. And in both cases I'm positive I didn't delete any code or do anything that could result in the code being changed.

I can't reproduce the issue, so this is a heads up in case you notice anything unusual. I use Medley Online 2024-04-22 02:03:43.

[rmkaplan]

I have also seen this or something like it from time to time, for years, but I haven’t been able to pin it down. It isn’t specific to commonlisp functions, although the smashing for commonlisp functions may occur in a slightly different way from however Interlisp functions are smashed. It think it has to do with the edit date stuff (FIXEDITDATE), but again I haven’t been able to figure it out. Whatever the cause of the smashing, it is also a separate problem that you don’t see what happened if you continue to look at the function in the open SEDIT window (that is, you finished the edit ^X, but you didn’t close the window M^X and reopen). If the function has changed in some way (e.g. a date was inserted), that change is not reflected on the screen unless you close and reopen. SEDIT is not notified to redisplay. Edit date may be one culprit. But anything that modifies the function while it is stilll shown in the window may also screw things up. I am very suspicious of the changes that DWIM makes, for example. If you misspell a locally bound variable, you might get a DWIM message nicely asking whether or not you want to approve a candidate spelling correction. I don’t think the SEDIT window reliably changes if you say yes, even though (I think) the list structure defining the running function has been modified.

…

On May 11, 2024, at 11:00 AM, Paolo Amoroso ***@***.***> wrote: Over the past week or so, in two cases SEdit apparently corrupted the code of functions I was editing. Here is what happened in both cases. After editing a Common Lisp function for some time, I executed the Done command by pressing Ctrl-X in SEdit. Then at a XCL Exec I called the function to test it but the calls didn't seem to do anything despite the function containing several expressions. However, the still open SEdit showed the full code. In the first occurrence of the issue I saved the program with MAKEFILE, examined the file with SEE, and only the first one or two sexps showed up in the function. I can't remember how many sexps. The issue happened a second time when editing this function of Insphex <https://github.com/pamoroso/insphex>: corrupted-sedit-code.png (view on web) <https://github.com/Interlisp/medley/assets/10342479/cbd2169c-7bd7-45a3-b39a-c178bfa6d526> This is what the function looked like shortly before and after the corruption. I took the screenshot after pressing Ctrl-X in SEdit and evaluating a few test calls. The calls returned just the docstring and did nothing else. Printing the function with PP at an Exec confirmed the function contained only the docstring despite SEdit still showing the full code as in the screenshot Both times I didn't lose any work and retyping the code was just a minor inconvenience, as the functions were short and I had taken screenshots. And in both cases I'm positive I didn't delete any code or do anything that could result in the code being changed. I can't reproduce the issue, so this is a heads up in case you notice anything unusual. I use Medley Online 2024-04-22 02:03:43. — Reply to this email directly, view it on GitHub <#1708>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOZBDSTZKFINQIBS3LZBZMC3AVCNFSM6AAAAABHSDF4IKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4TCMBRGE2TONY>. You are receiving this because you are subscribed to this thread.

[masinter]

there are some differet problems with the way insertion of time stamps interact with SEdit that I've known about for a while. One problem is the interaction of MARKASCHANGED, which is the main entry for noting that something has happened to the source code, is used to trigger the insertion of the time stamp in the definition, and also telling SEdit to refresh its view. The problem is that inserting the timestamp should be noted as a change but there is special code to avert a recursion which leaves the displayed function not matching the current one. This was kind of OK back when there was one timestamp in the function, but we changed the code to preserve the old timestamp.
I think the timestamps now are ugly and it isn't a good "modernization" -- if we're modernizing, we should preserve edit history some other way.

A second problem that is a little baffling, but I don't know anyone else would care, is when I'm running with EDITMODE(TELETYPE). It's a quick and efficient way to edit Lisp code but pretty archane. When there are some SEdit windows open and MARKASCHANGED is called, MARKASCHANGED tries to find matching SEdit windows to tell them to update their display. But it does this by calling "the editor" which "steals the TTY" (assign input to the SEdit process) in a way that it isn't clear which process should get it back.

DWIM has different problems, especially in Common Lisp. Getting DWIM and UNDO to work for Common Lisp is a goal that was left unfinished.... there was a warning in one of the Medley release notes about this. Clearly a misspelled variable that hasn't been proclaimed SPECIAL should only match against the lexically available symbols or dynamically bound variables.

DWIM does try to MARKASCHANGED any functions it corrects but this change may not affect the source definition because the definers DEFUN, DEFVARIABLE, eetc. all call REMOVE-INTERLISP-COMMENTS to remove (IL:* ...) Interlisp style comments before actually installing the result into the SYMBOL-FUNCTION cell.
That means that the executing code may or may not actually contain the DWIM'd fix.

For reasons I don't understand, Medley explicitly copies the code being evaluated so that DWIM won't change history. Having DWIM change the history to match the correction was kind of a feature.

[pamoroso]

Over a long DandeGUI coding session I edited a few functions and macros with SEdit, called MAKEFILE, and realized the latest additions had not been saved to the symbolic file. I made the missing changes again and called MAKEFILE which failed because of a stack overflow that didn't end or crash the Medley session. This time the file was nuked, i.e. it had length 0 and contained no data.

I lost no code though as I had taken snapshots of the unsaved code. Restoring the previous version of the file and retyping the unsaved code allowed me to recover everything.

[nbriggs]

I hope you're using {DSK}... files not {UNIX}... files -- so it should never lose an old version. I would generally use (FILES?) to see what needs to be done to existing files, and (CLEANUP) to prompt for where to put items that are not on any file, and write the files and compile/reload them.

[pamoroso]

Yes, that's basically my workflow. In addition I make copies of new code and prior to leaving a session I double check CLEANUP saved all the changes.