search

hpi-swa / MessageSendRecorder

Tracing tool for Squeak/Smalltalk. Includes a debugger-like browser for records.
MIT License
10 stars 2 forks source link

Stuff accepted in code pane is swallowed without confirmation #6

Open LinqLover opened 4 years ago

LinqLover commented 4 years ago

Steps to reproduce

  1. Record some message sends and open a record browser on them
  2. Select a method from the stack list
  3. Make some code changes to the code pane
  4. Accept it

Expected behavior

One of the following options should apply:

  1. The code pane is read-only
  2. When accepting the code, the method is recompiled but after that, the old code is loaded again (preferred option)
  3. When accepting the code, a message tells you that this is not possible
  4. Accepting the code is impossible and the orange triangle will stay after hitting <cmd>s.

Actual behavior

The code is replaced with the original method source, and the changes are lost.

marceltaeumel commented 4 years ago

I would prefer option (3) or (4) because users should remain able write into the code pane. Why would you want to edit/compile/change actual source code in the system through that tool (option (2))?

LinqLover commented 4 years ago

I'm not sure, but we support this in the debugger, too (at least I believe I proposed something like this to the inbox some time ago). The MSR tries to behave and look like a debugger in many scenarios, doesn't it? I'm thinking of a situation where I am using an MSR to find some bug and as soon as I found it in some method, I'm fixing it immediately before closing the MSR again. In this scenario, it would save me some seconds if I didn't need to copy-paste my changes into a regular browser to accept them there.

marceltaeumel commented 4 years ago

At least in the debugger, you can change a method to then influcence the onward stepping behavior. Is there such a use case for MSR? You can actually develop a system through debugging because the use is looking at present information. MSR shows you a past run.

LinqLover commented 4 years ago

I'm often thinking of the MSR as a "timeless debugging tool", so I would inspect the records of a complex operation in order to find a bug. Such a bug could also include situations where I realize "ah, this cannot work, I have to pass an additional parameter here"! So to fix the bug, I would add the parameter to a method and fix its sender, and if I am using an MSR at this moment, it would be most easy for me to use it for adding that method.

However, this is only a rare use case from my point of view, so option 3 or 4 would also not be that bad ... :-)

marceltaeumel commented 4 years ago

I'm often thinking of the MSR as a "timeless debugging tool"

That's dangerous. That assumption might lead to a misunderstanding of references-vs-copies of arguments etc. Well, maybe you find a way to spawn an actual debugger at a certain point. From there you could modify the source code.